AVAILABILITY · DETECTION · MITIGATIONDDoS의 역할과 동작 원리
DoS(Denial of Service)는 회선·네트워크 장비·서버·애플리케이션의 제한된 자원을 소진시켜 정상 사용자가 서비스를 이용하지 못하게 만드는 가용성 공격입니다. DDoS는 Botnet 등 여러 출발지에서 동시에 트래픽을 보내므로 단일 IP 차단만으로 대응하기 어렵습니다.
DDoS 방어의 목표는 공격 패킷을 많이 버리는 것이 아니라 공격 중에도 정상 사용자가 업무를 계속하게 하는 것입니다. 정상 트래픽도 공격과 같은 프로토콜·주소를 사용할 수 있으므로 탐지와 완화 과정에는 오탐과 과차단 위험이 항상 있습니다.
정상 사용자Bot ABot BBot C
→→그림 해설 · 정상 사용자와 공격 트래픽이 같은 서비스로 들어오므로, 공격만 줄이는 것이 아니라 정상 사용자의 가용성을 유지했는지 함께 판정합니다.
01DDoS는 무엇을 고갈시키는가
공격은 한 가지 숫자로 구분되지 않습니다. Volumetric 공격은 UDP·ICMP 같은 대량 트래픽으로 회선 대역폭을 채우고, Protocol·State Exhaustion 공격은 SYN flood처럼 방화벽·로드밸런서·서버의 연결 상태와 처리 큐를 소진합니다. Application 공격은 정상과 비슷한 HTTP 요청으로 느린 API·검색·로그인 같은 비싼 기능을 반복 호출합니다.
- Volumetric: BPS·PPS, 인터페이스 사용률, 드롭과 상위 회선 포화를 확인합니다.
- Protocol·State: SYN 비율, CPS, half-open·세션 테이블, 재전송을 확인합니다.
- Application: 요청률뿐 아니라 URL·응답 코드·서버 CPU·DB 연결·p95 지연을 확인합니다.
- Slowloris·R.U.D.Y. 같은 Slow HTTP 공격은 헤더나 본문을 매우 느리게 보내 연결 슬롯을 오래 점유하므로 낮은 PPS만 보고 정상으로 판단하면 안 됩니다.
DRDoS · 반사·증폭 공격
DRDoS(Distributed Reflection Denial of Service)는 공격자가 출발지 IP를 피해자 주소로 위조해 제3자의 공개 UDP 서비스에 요청하고, 그 응답이 피해자에게 향하게 하는 공격입니다. 작은 요청보다 큰 응답이 돌아오면 반사와 함께 증폭이 발생합니다. 피해자는 공격자의 실제 주소가 아니라 정상 서버처럼 보이는 반사 서버 주소를 보게 될 수 있습니다.
- 구조를 공격자 → 반사·증폭 서버 → 피해 서비스로 구분해 읽습니다.
- DNS·NTP·SSDP·CLDAP·Memcached 같은 UDP 기반 서비스가 대표적인 반사·증폭 벡터로 알려져 있습니다.
- 피해 구간의 차단만으로 회선이 이미 포화될 수 있으므로 통신사·CDN·스크러빙 센터와 상위 구간 대응이 필요할 수 있습니다.
- 반사 서버를 무작정 차단하지 말고 목적 포트, 응답 특성, 정상 업무 사용 여부와 패킷 캡처를 함께 확인합니다.
왜 정상 사용자도 함께 차단되는가
공격 트래픽과 정상 트래픽은 같은 80·443 포트와 유사한 HTTP 요청을 사용할 수 있습니다. 대형 이벤트, 티켓 예매, 로그인 집중, 앱 업데이트, 재시도 폭증 같은 Flash Crowd도 짧은 시간에는 공격처럼 보입니다. 특히 여러 사용자가 하나의 NAT·프록시·CDN 주소를 공유할 때 출발지 IP 단위 차단은 다수의 정상 사용자를 한꺼번에 막을 수 있습니다.
- 오탐은 정상 흐름을 공격으로 탐지한 것이고, 과차단은 완화 범위가 넓어 정상 사용자까지 차단한 결과입니다.
- 방어가 또 다른 장애가 되지 않도록 정상 사용자의 성공률·p95 지연·4xx/5xx·재전송·업무 기능을 동시에 봅니다.
- 공격량이 줄었다는 사실만으로 성공을 선언하지 않고, 제한 적용 전·후 같은 정상 요청을 회귀시험합니다.
- 예외는 전체 방어 해제가 아니라 인증 사용자·필수 API·신뢰 구간 등 필요한 범위로 최소화합니다.
기준선과 임계치·지속 시간
평상시 평균 하나만으로 임계치를 정하면 업무 피크를 공격으로 오인합니다. 평시·요일·시간대·이벤트 기간의 PPS, BPS, CPS, 동시 세션과 서비스 성공률을 나누어 보관하고, 초과량과 지속 시간, 반복성, 출발지·프로토콜 분포를 함께 판정해야 합니다.
- 짧은 burst를 즉시 차단하면 정상 이벤트를 막고, 인정 시간이 지나치게 길면 공격 대응이 늦어집니다.
- 자동 완화가 시작되는 조건과 정상화 후 해제되는 조건을 모두 정의합니다.
- 임계치는 장비 한계가 아니라 실제 서비스가 허용할 수 있는 지연과 오류율까지 반영합니다.
- 절대 임계치와 기준선 대비 변화율을 함께 사용해 계절성·이벤트 변화를 보정합니다.
단계별 완화와 종료 판단
처음부터 전체 차단을 적용하지 않습니다. Observe·Alert로 공격 벡터와 병목을 확인하고, 특정 목적지·프로토콜·행위에 Rate Limit·ACL·Challenge를 좁게 적용합니다. 로컬 회선이나 장비 용량을 넘으면 통신사·CDN·클라우드 스크러빙에 우회·정제를 요청합니다. RTBH는 목적지 전체를 버릴 수 있으므로 최후 수단과 영향 범위를 명확히 해야 합니다.
- 탐지 → 벡터별 제한 → 상위 스크러빙 → 정상 사용자 검증 순서와 담당자를 정합니다.
- 임시 차단과 영구 튜닝을 분리하고 적용·변경·해제 시각을 연·월·일과 타임존까지 기록합니다.
- 완화 중에는 공격 PPS뿐 아니라 회선, 세션, CPU, 큐, 응답률과 사용자 오류를 한 화면에서 비교합니다.
- 공격 종료 후 정책을 해제하고 정상 피크가 다시 통과하는지 확인한 뒤 사후 기준선과 오탐 사례를 반영합니다.