디도스 공격을 받았을 때 대응하는 방법

얼마 전 방문자가 갑자기 늘었다는 연락을 받고 서버를 확인했는데, 실제 방문자는 거의 그대로였습니다. 짧은 시간에 같은 경로로 요청이 몰리면서 웹서버 연결 수만 치솟은 상황이었죠. 이런 때 서버 사양부터 올리면 비용은 늘고 장애는 그대로일 수 있습니다. 디도스 공격은 어디가 먼저 막혔는지 확인한 뒤 그 지점의 앞단에서 처리해야 합니다.

먼저 트래픽이 막힌 지점을 찾는다

확인 순서는 외부 접속 상태, 회선 사용량, 웹서버 연결 수, 응답 시간, CPU와 메모리입니다. 접속 자체가 끊기고 회선 사용량이 한도에 붙어 있다면 네트워크 구간을 의심합니다. 웹서버까지 요청은 들어오는데 특정 화면에서만 응답이 늦다면 애플리케이션이나 데이터베이스가 먼저 한계에 닿았을 수 있습니다. CPU가 낮다고 공격이 아닌 것은 아닙니다. 서버 앞 회선이 이미 포화됐다면 CPU에는 처리할 요청이 도착하지 않습니다.

평소 수치와 비교해야 판단이 빠릅니다. 예를 들어 평상시 초당 요청이 30건, 최고 100건 정도인 사이트가 갑자기 3,000건을 받는다면 요청 경로와 응답 코드를 함께 봅니다. 정상적인 행사 유입도 급증할 수 있지만, 같은 주소에 요청이 집중되고 403·429·5xx 응답이 급격히 늘면 대응이 필요합니다. 접속 IP 하나만 보고 차단하지는 않습니다. 통신사 공유망이나 회사망에서는 정상 방문자 여러 명이 같은 IP로 보일 수 있습니다.

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

서버의 네트워크 대역폭이 100Mbps인데 그보다 큰 트래픽이 들어오면 서버 방화벽 규칙을 잘 만들어도 소용이 없습니다. 패킷이 방화벽에 닿기 전에 회선이 막히기 때문입니다. 이 경우 호스팅 업체나 상위 네트워크 사업자에 공격 시각, 대상 IP, 사용량 그래프를 전달하고 상위 구간의 차단·우회 지원을 요청해야 합니다. 계약한 요금제에 디도스 완화가 포함되는지, 공격 중 임시 차단 정책은 무엇인지도 같이 확인합니다.

반면 웹 요청이 특정 검색·로그인·장바구니 경로에 몰린다면 CDN 캐시, 웹 방화벽, 요청 빈도 제한을 먼저 검토합니다. 정적 파일을 캐시하면 원본 서버가 처리할 요청이 줄어듭니다. 로그인처럼 캐시할 수 없는 경로는 경로별 제한이 필요합니다. 다만 전체 사이트에 일률적으로 낮은 제한을 걸면 정상 사용자까지 막힙니다. 먼저 평소 최고 요청량과 실제 이용 흐름을 보고 기준을 잡고, 차단 기록과 정상 사용자의 오류 제보를 함께 확인해야 합니다.

급할 때 바꾸는 설정에도 순서가 있다

실제 장애가 나면 우선 공격 시작 시각과 영향을 받는 경로를 기록합니다. 그다음 호스팅 업체의 장애 공지와 회선 상태를 확인하고, 웹서버 접근 로그에서 요청량·응답 코드·요청 경로를 봅니다. 특정 경로가 원인이라면 그 경로부터 제한하고, 변경 직후 정상 접속과 관리자 기능을 직접 확인합니다. CISA의 대응 안내도 트래픽과 서버 자원 상태를 함께 분석한 뒤 완화 조치를 적용하고 효과를 확인하도록 권합니다.

CDN이나 웹 방화벽을 켰다면 원본 서버로 직접 접속하는 경로도 점검합니다. 원본 IP가 공개된 채 누구나 접속할 수 있으면 공격 트래픽이 보호 구간을 우회할 수 있습니다. 원본에는 허용된 중계 구간과 관리 접속만 열어 두는 식으로 접근 범위를 좁힙니다. 이때 관리자 접속 경로를 먼저 확보하고 방화벽 규칙을 적용해야 스스로 서버에 접속하지 못하는 일을 피할 수 있습니다.

서버를 재시작하거나 IP를 바꾸는 일은 원인을 확인한 뒤에 결정합니다. 재시작은 밀린 연결을 잠시 비울 수 있어도 계속 들어오는 공격을 멈추지는 못합니다. IP 변경 역시 DNS 전파와 기존 연결 때문에 즉시 효과가 보장되지 않습니다. 변경 시각과 이전 설정을 남겨 두면 정상 트래픽이 막혔을 때 되돌리기 쉽습니다.

평소 비용은 공격 규모가 아니라 서비스 규모에 맞춘다

작은 블로그라면 처음부터 비싼 서버나 전용 방어 상품을 살 필요는 없습니다. 정적 자산 캐시, 기본 방화벽 기능, 접속 로그 보관, 호스팅 업체의 대응 범위를 먼저 확인하는 편이 낫습니다. 반대로 예약·결제가 멈추면 손실이 큰 사이트라면 지원 연락 경로와 대응 시간, 추가 요금 조건까지 계약 전에 따져야 합니다. ‘무제한 트래픽’이라는 문구만으로 공격 중 서비스가 유지된다고 판단하면 곤란합니다.

백업도 챙겨야 하지만 백업이 디도스 트래픽을 막아 주지는 않습니다. 공격 중 급히 설정을 바꾸다가 서비스를 망가뜨렸을 때 복구하는 수단에 가깝습니다. 설정 파일과 데이터베이스 백업을 분리해 보관하고, 복원 절차를 한 번 실행해 보는 이유입니다. 저는 평소 요청량 그래프 한 장, 로그 보관, 업체 연락 방법이 준비된 사이트가 막연히 큰 서버만 쓰는 사이트보다 장애에 더 침착하게 대응한다고 봅니다.