DDoS 공격 대응 방법: 탐지부터 복구까지 6단계
- DDoS는 공격 계층을 먼저 구분해야 대응 수단을 정할 수 있습니다.
- 초기에는 서비스 유지와 트래픽 우회가 원인 분석보다 우선입니다.
- WAF·CDN·레이트 리밋은 평상시 기준선과 함께 설정해야 합니다.
DDoS 공격을 받았다면 무엇부터 해야 할까요?
DDoS(Distributed Denial of Service)는 여러 장비나 출발지를 이용해 대량의 패킷·요청을 보내 서비스 이용을 방해하는 공격입니다. 공격 중에는 서버를 재시작하거나 로그만 살피는 것보다 공격 트래픽이 원본 서버에 닿기 전에 흡수·차단하고, 정상 사용자의 핵심 기능을 유지하는 일이 먼저입니다.
대응은 공격이 발생한 계층에 따라 달라집니다. UDP 반사, SYN 플러드처럼 회선·연결 자원을 소진하는 L3·L4 공격은 네트워크 사업자나 클라우드 DDoS 방어 서비스의 도움이 필요할 수 있습니다. 반면 로그인, 검색, 주문 API에 반복 요청을 보내는 L7 공격은 CDN, WAF(웹 애플리케이션 방화벽), 레이트 리밋과 애플리케이션 캐시가 핵심입니다.
아래 절차는 자체 서버와 클라우드 환경 모두에 적용할 수 있는 사고 대응 흐름입니다. 특정 IP를 성급히 차단하면 NAT 환경의 정상 고객까지 막을 수 있으므로, 단일 지표가 아니라 요청 경로·URI·응답 코드·국가·세션 행동을 함께 확인해야 합니다.
핵심 원칙: 공격 대응의 첫 목표는 공격자를 추적하는 일이 아니라 정상 사용자가 핵심 페이지와 API를 계속 이용하게 만드는 것입니다. 원본 서버 IP 노출 여부와 CDN·WAF 우회 경로부터 확인하세요.
먼저 공격 유형과 영향 범위를 구분하세요
L3·L4와 L7 공격은 관측 지점이 다릅니다
OSI 계층에서 L3는 IP 패킷, L4는 TCP·UDP 연결, L7은 HTTP 같은 애플리케이션 요청을 뜻합니다. L3·L4 공격은 대역폭, 초당 패킷 수(PPS), 새 연결 수가 급증하는 양상으로 나타납니다. L7 공격은 전체 트래픽이 아주 크지 않아도 로그인·검색·결제처럼 처리 비용이 높은 주소에 요청이 집중되어 CPU, 데이터베이스 연결, 응답 시간이 악화될 수 있습니다.
| 관측 신호 | 의심 계층 | 우선 대응 |
|---|---|---|
| 회선 사용량·PPS 급증 | L3·L4 | 사업자·클라우드 스크러빙 요청 |
| SYN 연결 증가, 연결 테이블 포화 | L4 | 연결 제한, 로드밸런서 보호 |
| 특정 URI·API 요청 급증 | L7 | WAF 규칙, 레이트 리밋, 캐시 |
| 정상 브라우저 흐름 없는 반복 호출 | L7 | 챌린지·봇 정책·토큰 검증 |
영향도는 사용자 기능 기준으로 판정합니다
모니터링 화면의 트래픽 증가만으로 장애 여부를 판단하지 말고, 외부에서 핵심 화면이 열리는지와 주요 API의 오류율·지연 시간을 확인합니다. 읽기 전용 페이지는 캐시로 유지되지만 로그인이나 주문 저장이 실패한다면 별도 우선순위로 다뤄야 합니다. 평소 트래픽 기준선을 확보해 두면 단순 캠페인 유입과 공격을 가르는 데 유리합니다.
DDoS 공격 대응 6단계
1단계: 사고를 선언하고 관측 정보를 한곳에 모읍니다
온콜 담당자, 인프라 담당자, 애플리케이션 담당자, 고객 안내 담당자의 연락 경로를 열고 단일 상황 채널을 만듭니다. 시작 시각, 영향 서비스, 지역·ASN(자율 시스템 번호), 상위 URI, 초당 요청 수, 오류율, CDN·로드밸런서·서버 로그의 시간대를 같은 시간 기준으로 기록합니다. 담당자가 중복으로 규칙을 바꾸지 않도록 변경 책임자도 한 명 정합니다.
- 외부 상태 페이지 또는 별도 네트워크에서 서비스 접속 상태를 확인합니다.
- CDN, WAF, 로드밸런서, 호스트의 대시보드에서 급증 지표를 캡처합니다.
- 영향받은 도메인·API·원본 IP·배포 버전을 사고 기록에 남깁니다.
2단계: 원본 서버 우회 경로를 닫고 엣지에서 흡수합니다
웹 서비스라면 DNS가 CDN 또는 보호형 로드밸런서를 가리키는지 확인하고, 원본 서버 방화벽은 CDN·로드밸런서의 허용된 출발지에서만 인바운드 연결을 받도록 제한합니다. 원본 IP가 공개 DNS, 과거 이메일, 저장소 설정, 직접 접속용 서브도메인에 남아 있으면 공격자는 보호 계층을 우회할 수 있습니다. 관리용 SSH·원격 관리 포트도 공인 인터넷 전체에 노출하지 말고 VPN 또는 고정 관리망으로 제한합니다.
3단계: 공격 특성에 맞는 임시 규칙을 적용합니다
L7 공격에는 특정 URI별 요청 제한, 비정상 User-Agent·헤더 조합 차단, 봇 챌린지, 국가·네트워크 단위 제어를 조합합니다. 정상 고객이 많은 로그인 페이지에 과도한 CAPTCHA를 일괄 적용하면 전환 손실이 생길 수 있으므로, 먼저 짧은 시간 창의 레이트 리밋과 반복 실패 패턴을 적용하는 편이 안전합니다. L3·L4 대용량 공격은 회선 앞단에서 처리해야 하므로 호스팅사·통신사 또는 클라우드 사업자의 긴급 완화 절차로 즉시 에스컬레이션합니다.
- 캐시 가능한 정적 파일과 공개 조회 API의 캐시 TTL을 일시적으로 조정합니다.
- 비핵심 기능, 무거운 검색, 대량 내보내기 작업은 임시 제한을 검토합니다.
- 인증·결제·관리 API는 허용 트래픽을 별도로 측정해 일괄 차단을 피합니다.
4단계: 애플리케이션 병목을 분리해 정상 요청을 살립니다
공격 요청이 데이터베이스까지 도달한다면 엣지 차단만으로 충분하지 않을 수 있습니다. 읽기 요청은 캐시, 큐, 읽기 복제본으로 분산하고, 비용이 큰 검색·정렬·파일 변환 API에는 요청당 작업량 제한과 타임아웃을 둡니다. 연결 풀 고갈, 자동 확장 지연, 로그 저장량 증가도 함께 점검합니다. 다만 공격 중 데이터베이스 스키마 변경이나 대규모 배포는 복구를 어렵게 할 수 있으므로, 긴급 변경은 되돌릴 방법을 준비한 뒤 최소 범위로 적용합니다.
5단계: 차단 효과를 수치로 검증하고 규칙을 조정합니다
규칙 적용 뒤에는 차단 건수만 보지 말고 정상 사용자 기준의 성공률, p95 응답 시간, 4xx·5xx 비율, 결제·로그인 완료율을 전후 비교합니다. 공격자가 URI나 출발지를 바꾸면 이전 규칙이 효과를 잃을 수 있습니다. 팀이 정한 관측 주기로 측정값을 갱신하고, 자동 알림이 없다면 오류율과 지연 시간 조건을 운영 알림으로 연결해 재발 탐지를 빠르게 만듭니다.
6단계: 안정화 뒤 증적을 보존하고 재발 방어를 반영합니다
트래픽이 줄었다고 즉시 모든 임시 제한을 해제하지 말고, 충분한 관측 기간을 거쳐 단계적으로 완화합니다. WAF 로그, 방화벽 이벤트, 패킷 요약, 설정 변경 이력, 장애 공지 시각을 보존해 사후 분석에 사용합니다. 공격 벡터, 우회된 경로, 차단으로 발생한 정상 사용자 영향, 의사결정 시간을 검토하고 런북과 자동화 규칙을 갱신합니다.
주의: 공격 중 원본 IP를 공개한 채 서버 증설만 하는 방식은 비용과 부하를 함께 키울 수 있습니다. 엣지 보호, 우회 경로 차단, 정상 서비스 지표 확인을 병행해야 합니다.
평상시에 준비할 DDoS 방어 구성
보호 계층을 한 겹이 아니라 흐름으로 설계합니다
기본 구조는 인터넷 사용자 → CDN·DDoS 보호 서비스 → WAF → 로드밸런서 → 애플리케이션 → 데이터베이스처럼 원본으로 갈수록 접근을 좁히는 방식입니다. CDN은 정적 콘텐츠와 캐시 가능한 응답을 엣지에서 제공해 원본 부하를 줄이고, WAF는 HTTP 규칙을 적용하며, 로드밸런서는 정상 연결을 분산합니다. 각각이 완전한 대체재는 아니므로 서비스 특성에 맞게 조합해야 합니다.
런북과 권한은 실제 장애 전에 검증합니다
보안 담당자만 WAF를 수정할 수 있는데 야간 온콜은 권한이 없다면 대응이 지연됩니다. 비상 권한 승인 절차, 사업자 지원 연락처, 도메인·원본 IP 목록, 롤백 방법을 런북에 문서화하세요. 분기 또는 배포 전 점검 때 제한 규칙을 스테이징 환경에서 시험하고, 정상 모바일 앱·파트너 API·검색 엔진 크롤러가 오차단되지 않는지도 확인해야 합니다.
- 원본 서버는 CDN·로드밸런서 외 직접 접근을 허용하지 않습니다.
- 핵심 API마다 정상 트래픽 범위와 급증 알림 기준을 정의합니다.
- 로그 보관 기간과 접근 권한을 정해 사고 증적이 사라지지 않게 합니다.
- 상태 페이지와 고객 공지 템플릿을 사전에 준비합니다.
피해야 할 대응 실수와 예외 상황
IP 차단만으로 끝내지 마세요
분산 공격은 출발지 IP가 계속 바뀌며, 프록시·NAT·모바일망 때문에 한 IP에 정상 사용자도 섞일 수 있습니다. IP 차단은 명확한 악성 패턴이 있을 때 짧은 만료 시간을 두고 적용하며, URI·세션·요청 빈도·행동 패턴 중심의 규칙을 함께 사용합니다.
장애와 공격을 혼동하지 마세요
새 배포의 무한 재시도, 외부 결제사 지연, 잘못된 크롤러 설정도 DDoS처럼 보일 수 있습니다. 요청량, 요청 성공 여부, 릴리스 시각, 외부 의존성 상태를 교차 확인해야 합니다. 공격으로 판단되더라도 법적 대응이나 신고가 필요할 수 있으므로, 임의로 로그를 수정하거나 삭제하지 말고 조직의 보안·법무 절차에 따라 증적을 보존합니다.
자주 묻는 질문
Q. DDoS 공격 중 서버를 재시작하면 해결되나요?
대부분의 경우 근본 해결책이 아닙니다. 공격 트래픽이 계속 유입되면 재시작 후에도 자원이 다시 소진될 수 있으므로, 먼저 CDN·WAF·네트워크 사업자 측에서 유입을 줄여야 합니다.
Q. CDN을 사용하면 DDoS를 모두 막을 수 있나요?
CDN은 정적 콘텐츠와 캐시 가능한 요청을 흡수하는 데 도움이 되지만, 원본 IP가 노출됐거나 동적 API를 겨냥한 공격에는 별도 WAF 규칙, 레이트 리밋, 원본 방화벽 정책이 필요합니다.
Q. 레이트 리밋은 어느 정도로 설정해야 하나요?
모든 서비스에 적용되는 단일 값은 없습니다. 실제 사용자와 파트너 API의 평상시 요청 분포, 로그인·검색 같은 기능별 특성, 모바일 앱의 재시도 동작을 측정한 뒤 기능별로 설정하고 오차단 지표를 함께 관찰해야 합니다.
Q. 공격 여부를 확인하기 위해 어떤 로그를 봐야 하나요?
CDN·WAF 접근 로그, 로드밸런서 요청 로그, 웹 서버 오류 로그, 네트워크 흐름 로그를 같은 시간대에 비교하세요. URI별 요청 수, 응답 코드, 국가·ASN, 새 연결 수, 원본 서버 CPU·메모리·연결 풀 상태가 유용합니다.
