디도스 공격 개념을 운영 기준으로 이해하는 방법

몇 년 전 작은 쇼핑몰이 느려졌다는 연락을 받고 접속 기록부터 봤습니다. 평소보다 방문자는 조금 늘었는데, 로그인 요청만 초당 수백 건씩 들어오고 있었습니다. 회선 사용량은 낮았지만 서버의 작업 프로세스가 꽉 찼죠. 디도스는 트래픽 그래프가 크게 치솟을 때만 의심할 일이 아닙니다.

디도스는 어느 자원을 막느냐로 이해하면 쉽다

디도스 공격 개념은 여러 출처에서 요청이나 패킷을 보내 서비스가 정상 이용자를 처리하지 못하게 만드는 것입니다. 운영할 때는 공격 이름보다 무엇이 먼저 한계에 닿는지 보는 편이 유용합니다. 회선이 막힐 수도 있고, 서버의 연결 처리 능력이나 로그인 페이지의 데이터베이스 조회가 먼저 버틸 수 없게 될 수도 있습니다.

예를 들어 100Mbps 회선은 단순 환산하면 초당 약 12.5MB를 전송합니다. 응답 한 건이 200KB라면 이론상 초당 60건 남짓이지만, 실제 처리량은 통신 오버헤드와 다른 요청 때문에 더 낮습니다. 반대로 로그인 요청은 전송량이 작아도 비밀번호 검증과 데이터베이스 조회에 시간이 걸립니다. 그래서 회선 사용률이 10%인데 사이트가 멈추는 일도 생깁니다.

공격 출처가 여럿이라는 점도 중요합니다. 정상적인 이용자와 공격 요청이 섞이면 한 주소만 차단해서 끝나지 않습니다. 공격에 동원된 기기나 중계 경로가 바뀌기도 합니다. 서버 한 대의 방화벽 규칙만으로 대응할 수 있는 범위를 먼저 가늠해야 합니다.

회선 공격과 웹 요청 공격은 대응 위치가 다르다

대량의 패킷으로 회선을 채우는 공격은 서버 앞단에서 걸러야 합니다. 100Mbps 회선으로 1Gbps가 들어오면 서버에서 패킷을 버리도록 설정해도 이미 회선은 막혀 있습니다. 이때는 호스팅 업체나 회선 사업자의 차단·우회 기능이 필요합니다. 업체가 제공하는 보호 용량과 초과 시 처리 방식은 요금제 이름보다 먼저 확인할 항목입니다.

연결을 맺는 과정만 반복해서 연결 대기 공간을 소모시키는 공격도 있습니다. 이 경우 네트워크 대역폭과 함께 연결 수, 연결 상태, 재전송량을 봅니다. 웹 페이지나 검색·로그인 같은 기능을 반복 호출하는 공격은 웹 요청 단계에서 나타납니다. 웹 방화벽과 요청 빈도 제한이 도움이 되지만, 모든 요청에 같은 제한을 걸면 정상 이용자까지 막힙니다.

특히 회사나 학교처럼 여러 사람이 하나의 외부 주소를 공유하는 곳은 주소별 요청 제한에 걸리기 쉽습니다. 로그인은 계정과 경로를 함께 보고, 공개 페이지는 캐시가 가능한지 살피는 식으로 기준을 나눠야 합니다. 공격 중 급히 제한값을 낮췄다면 정상 주문이나 로그인 성공률도 같이 확인해야 합니다.

장애가 났을 때 확인하는 순서

우선 외부에서 접속이 되는지, 서버 내부에서는 응답하는지 나눠 봅니다. 외부만 안 되고 회선 사용량이 상한에 붙어 있다면 상위 네트워크 문제를 의심할 수 있습니다. 내부에서도 느리다면 CPU, 메모리, 디스크 대기 시간, 웹서버 연결 수와 데이터베이스 연결 수를 확인합니다. 한 지표만 보고 디도스라고 단정하면 디스크 부족이나 잘못된 배포를 놓치기 쉽습니다.

그다음 평소 같은 시간대와 요청 수를 비교합니다. 요청이 몰린 경로, 응답 코드, 평균 응답 시간, 출처 분포를 같이 봅니다. 방문자 수가 늘면서 상품 페이지가 고르게 조회된다면 행사나 검색 노출의 영향일 수 있습니다. 반면 세션 없이 로그인이나 검색 요청만 급증하고 오류율이 함께 오른다면 비정상 요청을 더 의심할 만합니다. 이 차이는 접속 기록을 남겨 둬야 확인할 수 있습니다.

운영 중이라면 변경 사항도 함께 확인합니다. 배포 직후 쿼리가 느려져 요청이 쌓이면 공격처럼 보일 수 있습니다. 최근 배포 시각, 캐시 적중률, 데이터베이스의 느린 쿼리를 대조하면 원인을 좁히는 데 도움이 됩니다. 시간이 급해도 관측값을 몇 분간 보존해 두면 업체에 차단을 요청할 때 설명이 훨씬 정확해집니다.

작은 사이트라면 비용보다 복구 절차부터

방어 상품을 바로 올리기 전에 정상 트래픽의 기준을 잡는 게 좋습니다. 평소와 행사일의 초당 요청 수, 최대 동시 연결 수, 전송량을 기록하면 어느 구간부터 보호가 필요한지 계산할 수 있습니다. 정적 페이지 위주의 작은 사이트라면 캐시와 기본 요청 제한만으로 버티는 구간도 많습니다. 다만 회선 자체가 포화되는 공격은 저렴한 서버를 더 큰 서버로 바꿔도 해결되지 않습니다.

장애 대응 절차는 짧게라도 적어 두는 편이 낫습니다. 누가 호스팅 업체에 연락할지, 어떤 지표를 전달할지, 긴급 차단을 언제 해제할지 정해 둡니다. 설정을 급히 바꾼 뒤 원래 값으로 돌리는 절차도 필요합니다. 백업은 디도스 패킷을 막아 주지 않지만, 대응 중 설정을 잘못 바꾸거나 다른 장애가 겹쳤을 때 복구 시간을 줄여 줍니다. 복원 시험을 한 적 없는 백업은 실제 복구 시간을 예측하기 어렵습니다.

제가 작은 사이트를 운영할 때 가장 먼저 챙기는 건 비싼 방어 요금제가 아니라 평소 수치, 접속 기록, 업체 연락 경로입니다. 어느 자원이 막혔는지 알아야 필요한 곳에만 비용을 쓸 수 있고, 정상 이용자를 덜 불편하게 만들 수 있습니다.