모두
모두콘텐츠
얼마 전 사이트가 느려졌다며 디도스부터 의심하는 연락을 받았다. 접속 기록을 보니 요청량은 평소와 비슷했고, 데이터베이스의 느린 쿼리 하나가 작업 대기열을 채우고 있었다. 반대로 CPU 사용률은 낮은데 회선이 먼저 막혀 사이트가 죽는 경우도 있다. 디도스 공격 잡는법은 차단 버튼을 찾는 일보다 어디가 막혔는지 확인하는 일에서 시작한다.
공격인지 먼저 숫자로 구분한다
장애가 시작된 시각을 잡고 전후 10~15분의 요청 수, 전송량, 응답 시간, 오류 비율을 비교한다. 평소 초당 20건이던 요청이 1,500건으로 뛰었다면 눈에 띄는 변화다. 다만 요청 증가만으로 공격이라고 단정하면 안 된다. 검색 유입이나 행사 때문에 실제 방문자가 늘 수도 있다.
웹서버 접속 기록에서 같은 경로가 반복되는지, 특정 국가나 대역에 요청이 몰리는지, 정상 화면을 거의 보지 않고 로그인·검색·API만 두드리는지 확인한다. 같은 시각의 CPU, 메모리, 데이터베이스 연결 수와 호스팅 회선 사용량도 함께 본다. 요청 수는 크게 늘지 않았는데 5xx 오류와 데이터베이스 대기만 증가했다면 애플리케이션 장애부터 점검할 차례다.
- 회선 사용량이 한계에 닿았다면 대량 트래픽 공격 가능성을 본다.
- 회선은 여유가 있지만 특정 경로의 요청과 응답 시간이 급증했다면 웹 계층 공격을 의심한다.
- 요청량이 평소와 비슷하다면 배포 변경, 디스크 용량, 데이터베이스 상태를 먼저 확인한다.
회선이 막혔다면 호스팅 업체부터 부른다
대량 패킷이 서버 앞 회선을 이미 채웠다면 서버 안의 방화벽으로 차단해도 방문자는 접속하기 어렵다. 패킷이 방화벽에 도착하기 전에 병목이 생기기 때문이다. 이때는 호스팅 업체나 인터넷 회선 사업자에게 공격 시작 시각, 대상 주소, 대략적인 유입량을 전달하고 상위망 차단이나 디도스 완화 기능을 요청한다. 계약에 그런 기능이 포함됐는지도 확인해야 한다.
급하다고 서버 사양부터 올리지는 않는다. 예를 들어 서버 CPU가 20%인데 회선이 포화됐다면 CPU를 두 배로 늘려도 막힌 구간은 그대로다. 대상 서버를 다른 곳으로 옮길 때도 기존 주소가 계속 노출돼 있으면 공격이 따라올 수 있다. 이전에는 새 서버의 접속 제한과 서비스 점검 순서를 먼저 잡아야 한다.
웹 요청이 몰리면 비싼 경로부터 보호한다
회선은 버티는데 검색 결과나 로그인 요청 때문에 서버가 밀린다면 해당 경로를 먼저 보호한다. CDN의 캐시로 이미지·문서 같은 정적 요청을 원본 서버에서 떼어내고, 웹 방화벽과 요청 속도 제한을 검색·로그인·API 경로별로 적용한다. 전체 사이트에 같은 제한을 걸면 정상 이용자까지 막기 쉽다.
숫자는 평소 최대치에서 출발한다. 정상 운영 때 로그인 요청이 분당 30건 이하라면 처음부터 분당 5건으로 자르는 식의 설정은 위험하다. 한 회사나 통신사 이용자가 같은 공인 IP를 공유할 수도 있어서 IP 하나만 기준으로 삼는 규칙은 오탐이 난다. 우선 기록만 남기는 모드나 짧은 적용 구간으로 시작해 차단 건수와 실제 로그인 실패 신고를 같이 본다.
캐시가 되는 페이지와 안 되는 페이지도 구분한다. 이미지 요청을 캐시해도 매번 데이터베이스를 조회하는 검색 요청은 그대로 남는다. 공격자가 매번 다른 검색어를 보내면 캐시 적중률이 떨어질 수도 있다. 이런 경로는 요청 제한과 함께 쿼리 비용, 작업 시간 제한, 동시 처리 수를 점검하는 편이 낫다.
원본 서버 우회와 복구 절차를 확인한다
CDN을 붙였는데도 원본 서버 주소로 직접 접속할 수 있으면 공격자가 보호 구간을 우회한다. 원본 방화벽에서는 CDN이나 필요한 관리 경로에서 오는 연결만 허용하고, 관리자 접속은 별도 접근 경로로 남긴다. 차단 규칙을 바꿀 때는 관리자가 스스로 서버에서 잠기지 않도록 현재 접속과 복구 수단을 확인한다.
차단 뒤에는 메인 화면 한 번만 열어보고 끝내지 않는다. 로그인, 결제, 검색, 관리자 화면처럼 캐시가 적용되지 않는 경로를 확인하고 4xx·5xx 오류율, 응답 시간, 원본 서버 요청량을 지켜본다. 공격이 잦아들면 임시 규칙을 하나씩 완화하면서 정상 이용자가 막혔는지 확인한다. 장애 시각의 설정과 접속 기록도 남겨야 다음에 같은 패턴을 빨리 찾는다.
백업은 디도스를 막아주지 않지만, 공격 중 급하게 설정을 바꾸다 서비스나 데이터를 손상시켰을 때 복구 시간을 줄여준다. 평소에는 최근 백업이 실제로 복원되는지, 관리 계정과 호스팅 업체 연락 경로가 살아 있는지 확인해 두는 게 좋다. 작은 사이트라면 고가 요금제보다 평소 트래픽 기준선, 기본 차단 기능, 복구 가능한 백업을 갖추는 쪽이 먼저라고 본다.
