디도스 공격 사례로 배우는 서버 대응 방법

서버가 느려졌다는 연락을 받으면 먼저 CPU 사용률부터 보는 운영자가 많습니다. 저도 초반에는 그랬습니다. 그런데 디도스 공격 사례를 뜯어보면 서버 사양보다 앞단 회선이나 웹 요청 처리 과정에서 먼저 병목이 생기는 경우가 있습니다. 어느 구간이 막혔는지에 따라 대응도 달라집니다.

2020년 AWS 사례는 회선 용량을 보여준다

AWS Shield가 발표한 2020년 1분기 보고서에는 최대 2.3Tbps의 CLDAP 반사 공격이 기록돼 있습니다. 공격자가 피해자의 주소를 출발지로 꾸며 외부 서버에 요청을 보내고, 그 응답이 피해자 쪽으로 쏟아지는 방식입니다. 여기서 봐야 할 수치는 초당 요청 건수가 아니라 초당 들어오는 데이터량입니다. 웹서버 설정을 바꿔도 회선 앞에서 트래픽이 막히면 방문자는 접속할 수 없습니다.

이 규모를 개인 사이트의 방어 기준으로 삼을 필요는 없습니다. AWS 보고서에서도 같은 분기 네트워크 공격 규모의 99백분위 값은 43Gbps였습니다. 작은 사이트가 수십 Gbps를 직접 받아낼 서버를 마련하는 건 현실적이지 않습니다. 서버 증설보다 호스팅 업체의 디도스 방어 범위, 상위 회선에서 차단할 수 있는지, 차단 요청을 어디로 보내야 하는지를 먼저 확인하는 편이 맞습니다.

2023년 구글 사례는 요청 처리량을 보여준다

구글 클라우드는 2023년 8월 HTTP/2 Rapid Reset 공격에서 초당 최대 3억 9,800만 건의 요청을 관측했다고 밝혔습니다. 요청을 보낸 직후 취소하는 동작을 반복해 처리 부담을 만드는 방식입니다. 클라우드플레어도 같은 공격 유형에서 초당 2억 100만 건을 넘는 사례를 공개했습니다. 앞의 AWS 사례와 단위가 다릅니다. Tbps는 데이터가 얼마나 밀려오는지, rps는 요청이 얼마나 자주 들어오는지를 가리킵니다.

운영 화면에서도 이 차이는 드러납니다. 네트워크 사용량은 평소와 비슷한데 요청 수가 치솟고, 프록시나 웹서버의 연결 수와 오류가 늘 수 있습니다. 특히 로그인, 검색처럼 처리 비용이 큰 경로에 요청이 집중되면 작은 트래픽으로도 애플리케이션과 데이터베이스가 밀립니다. HTTP/2를 쓰는 서버라면 관련 소프트웨어 패치 상태도 확인해야 합니다. 단순히 대역폭이 남아 있다는 이유로 공격을 배제하면 진단이 늦어집니다.

장애가 났을 때 확인할 순서

첫 5분에는 장애 범위부터 가릅니다. DNS 조회가 되는지, 특정 지역이나 통신사에서만 실패하는지, 첫 화면과 로그인 같은 동적 화면이 함께 느린지 확인합니다. 동시에 호스팅 관리 화면에서 네트워크 유입량, 초당 요청 수, 상태 코드 비율, CPU와 메모리, 데이터베이스 연결 수를 봅니다. 이때 평소 같은 시간대 수치와 비교해야 합니다. 방문자가 갑자기 늘어난 날의 정상 트래픽을 공격으로 오인할 수 있습니다.

유입 대역폭이 회선 한계에 가깝다면 호스팅 업체에 상위망 차단이나 방어 서비스 적용 상태를 확인합니다.
대역폭은 낮은데 특정 경로의 요청과 오류가 늘었다면 캐시, 경로별 요청 제한, 웹 방화벽 규칙을 점검합니다.
요청 수가 평소와 비슷하다면 최근 배포, 데이터베이스 지연, 디스크 공간과 인증서 상태도 함께 확인합니다.

차단 규칙은 작은 범위부터 적용하고 정상 방문자의 오류율을 같이 봐야 합니다. 국가 전체나 넓은 주소 대역을 급히 막으면 공격보다 운영 장애가 커질 수 있습니다. 원본 서버 주소가 외부에 그대로 노출돼 있으면 앞단 방어 서비스를 켜도 공격이 원본으로 직접 들어올 수 있으니, 우회 경로가 없는지도 살핍니다.

평소 트래픽과 방어 비용은 따로 계산한다

평소 사양은 숫자로 계산할 수 있습니다. 예를 들어 초당 20건의 요청에 평균 응답 크기가 100KB라면 응답 데이터만 초당 약 2MB, 비트로는 약 16Mbps입니다. 초당 200건이면 약 160Mbps가 됩니다. 실제 용량 산정에는 이미지 전송, 캐시 적중률, 요청별 처리 시간, 순간 최대치를 더해야 합니다. 월 방문자 수만 보고 VPS 크기를 고르는 것보다 이 계산이 쓸모 있습니다.

다만 디도스 방어 용량은 평소 트래픽의 몇 배라는 식으로 계산하기 어렵습니다. 공격은 방문자 증가와 다른 패턴으로 들어옵니다. 작은 블로그라면 처음부터 비싼 전용 장비를 계약하기보다 호스팅에 포함된 방어 기능과 캐시를 확인하고, 연락 절차를 문서로 남기는 쪽이 실용적입니다. 또 요청이 늘면 종량제 트래픽 비용도 커질 수 있으므로 사용량 알림과 과금 기준을 확인해 둬야 합니다.

백업도 별개로 챙깁니다. 백업은 디도스 트래픽을 막지 못하지만, 대응 중 설정을 잘못 바꾸거나 장애가 겹쳤을 때 복구 시간을 줄입니다. 서버 밖에 보관한 백업을 실제로 복원해 보고, DNS와 방화벽 설정을 되돌리는 절차까지 적어 두면 좋습니다. 14년 동안 운영하며 느낀 건 큰 서버 한 대보다 평소 수치와 연락 경로, 되돌릴 수 있는 설정이 장애 시간을 더 많이 줄여 준다는 점입니다.