모두
모두콘텐츠
얼마 전 접속 장애를 겪은 운영자가 디도스 공격을 의심하며 VPS부터 두 배 큰 것으로 바꾸려 했다. 로그를 보니 요청량은 평소와 비슷했고, 데이터베이스 연결이 꽉 찬 게 원인이었다. 서버가 느려졌다는 사실만으로 공격을 단정하면 복구 순서가 꼬인다. 디도스 공격 대응은 먼저 어디가 막혔는지 확인하는 일부터 시작한다.
공격인지 먼저 가려낸다
외부에서 사이트가 열리는지 확인한 뒤 같은 시간대의 요청 수, 응답 시간, 5xx 오류, CPU와 메모리, 네트워크 사용량을 나란히 본다. 분당 요청이 평소 300건에서 3만 건으로 뛰고 특정 경로에 몰렸다면 의심할 만하다. 반대로 요청 수는 그대로인데 5xx만 늘었다면 애플리케이션 오류나 데이터베이스 장애를 먼저 봐야 한다. 유입이 늘어도 캐시가 처리하고 원본 서버가 멀쩡하다면 서비스 장애와는 구분해서 판단한다.
로그에서는 요청이 몰린 경로, 요청 방식, 응답 코드, 접속 출처의 분포를 확인한다. 로그인이나 검색처럼 매번 서버 작업이 필요한 경로에 요청이 몰리는지, 정적 파일까지 고르게 늘었는지가 중요하다. 출처 IP 몇 개만 보고 차단하기는 어렵다. 실제 공격은 여러 출처로 분산될 수 있고, 회사나 통신사 망에서는 정상 이용자 여럿이 같은 공인 IP를 쓴다.
막힌 위치에 맞춰 조치한다
HTTP 요청이 애플리케이션을 압박한다면 CDN 캐시와 웹 방화벽에서 먼저 줄인다. 이미지와 변경이 적은 페이지는 캐시하고, 로그인·검색·비싼 조회 경로에는 평소 이용량을 기준으로 속도 제한을 건다. 예를 들어 로그인 요청이 평소 분당 수십 건이라면 해당 경로에만 제한을 시험할 수 있다. 전체 사이트에 같은 수치를 적용하면 행사나 공지 직후 정상 방문자까지 막힌다. 처음에는 탐지 기록과 차단 결과를 보며 조정하는 편이 안전하다.
회선이나 호스팅 업체 앞단에서 트래픽이 이미 포화됐다면 서버 방화벽 규칙만 추가해도 소용없다. 패킷이 서버에 도착하기 전에 회선이 찼기 때문이다. 이때는 호스팅 업체나 네트워크 사업자에 공격 시각, 대상 IP, 대략적인 트래픽 규모와 패킷 유형을 전달하고 상위망 차단·우회 기능을 요청한다. UDP나 TCP 연결 공격도 웹 방화벽만으로 해결된다고 가정하면 안 된다. 업체가 어느 계층까지 방어하는지 계약 내용과 운영 안내를 확인해야 한다.
프록시를 붙였다면 원본 서버도 보호한다
CDN을 켰는데 원본 서버 IP로 직접 접속할 수 있으면 공격자는 CDN을 건너뛸 수 있다. 원본 방화벽은 사용하는 프록시의 접속 대역에서 들어오는 웹 요청만 허용하고, 관리 접속은 별도의 허용 경로로 제한한다. 이 설정 전에는 프록시와 원본 사이의 연결, 인증서, 관리 접속 경로를 확인해야 한다. 순서를 바꾸면 운영자까지 서버에서 잠길 수 있다.
오래된 DNS 기록이나 별도 서비스가 원본 IP를 드러내는지도 점검한다. 다만 IP를 바꾸는 것만으로 끝났다고 판단하면 곤란하다. 이전 주소가 계속 열려 있거나 새 주소가 다시 노출되면 우회 경로가 남는다. 캐시를 늘릴 때도 로그인 상태별 화면과 개인 정보가 섞인 응답은 제외해야 한다. 장애를 막으려다 다른 이용자의 화면을 보여주는 사고가 더 크다.
복구 후에는 다음 대응 시간을 줄인다
공격 중에는 규칙을 한꺼번에 바꾸지 말고 적용 시각과 효과를 기록한다. 차단 뒤 원본 요청량과 5xx가 줄었는지, 정상 이용자의 로그인·결제가 되는지 함께 확인한다. 공격이 잦아든 뒤에는 임시로 강화한 규칙을 다시 검토한다. 계속 유지하면 정상 방문이 많은 날 장애 원인이 될 수 있다.
평소에는 정상 시간대의 분당 요청 수와 최대 동시 접속, 원본 CPU·메모리 사용률을 남겨 두는 게 좋다. 기준선이 있어야 공격과 인기 게시물 유입을 빨리 구별한다. 백업은 디도스를 막아 주지 않지만, 장애 중 설정을 잘못 바꾸거나 급히 이전할 때 복구할 수단이 된다. 설정 파일과 데이터베이스의 백업 시각, 복원 절차도 실제로 확인해 둬야 한다.
비용은 평소 트래픽과 장애 허용 시간을 기준으로 계산한다. 작은 사이트라면 무료 또는 저가 CDN 기능과 호스팅 업체의 기본 방어로 충분할 수 있다. 반면 접속 중단 비용이 크거나 원본을 직접 겨냥한 공격이 반복된다면 상위망 방어 범위와 지원 응답 시간을 비용에 포함해야 한다. 서버 사양을 올리기 전에 트래픽이 어느 지점까지 왔는지부터 보는 습관이 결국 가장 많은 시간을 아껴 준다.
