중국발 TCP DDoS 공격 대응 방법 – 방화벽, IPS 실무에서 방어 경험 공유

by

저는 현재 정보보안 업무를 담당하고 있고 침해사고 대응팀에 속해있는데요. 얼마전 중국발 DDOS 문제로 며칠을 고생한적이 있었는데요. 오늘은 실제 경험했던 DDOS 방어 사례에 대해 누군가에게는 도움이될수 있도록 정리해보는 시간을 갖도록 하겠습니다.

 

초기 DDOS 공격에 대해 현장에서 대응했을 때 저는 보통 모니터 알람이 울리면 곧바로 NetFlow·IDS·웹로그·서버 리소스 지표를 동시에 켜 놓고 트래픽 패턴을 들여다봤습니다. 초기 증상은 대개 “서비스 지연/연결 실패” 형태로 나타났고, 패킷 플래그 비율과 세션 생성 속도를 살펴보며 해당 장애가 TCP 계열의 DDoS(주로 SYN flood나 연결 고갈형)임을 빠르게 판별했습니다. 소스 IP 분포를 확인했더니 중국 쪽 대역이 대부분을 차지할 때가 많아 바로 GeoIP 차단을 떠올렸지만, 곧바로 고객·비즈니스 영향(정상 사용자 차단 위험)을 계산해 임시 차단 여부를 신중하게 결정했습니다.

 

바로 적용 가능한 실무 조치(상단 방화벽 / 서버 / IPS 등)

 

1) 경계 방화벽에서 즉시 적용할 규칙들

  • DDOS SYN flood 기본 방어

    • 리눅스 커널:

      # SYN cookie 활성화
      sysctl -w net.ipv4.tcp_syncookies=1
      # syn backlog 수치 확인/조정
      sysctl -w net.ipv4.tcp_max_syn_backlog=4096

    • iptables 예시 (현장 튜닝값은 트래픽 특성에 맞게 조절):

      iptables -N SYN_FLOOD
      iptables -A INPUT -p tcp --syn -j SYN_FLOOD
      iptables -A SYN_FLOOD -m limit --limit 20/s --limit-burst 40 -j RETURN
      iptables -A SYN_FLOOD -j DROP

    • 설명: 초당 SYN 허용량을 제한해 연결 폭주를 완화. 정상 피크를 모니터해 숫자 조정 필요.

  • 동시 연결 수 제한 & conntrack 관리

    • conntrack 테이블 초과로 방화벽이 다운되는 사례가 흔함. conntrack max 및 timeout을 낮추고, 필요 없는 프로토콜의 conntrack은 비활성화합니다.

      sysctl -w net.netfilter.nf_conntrack_max=200000
      sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300

  • GeoIP 임시 차단(비용·영향이 큰 결정)

    • 중국 IP가 압도적일 때는 geoip deny로 차단. 단, B2B나 현지 사용자가 있으면 큰 피해 발생하므로 운영중인 서비스의 고객 분포 확인 후 적용.

 

2) DDOS IPS에서의 세부 조치

  • 비정상 플래그/패턴 기반 차단: SYN만 반복, SYN+FIN 같은 비정상 조합을 시그니처로 막습니다.

  • 화이트리스트 우선시: 내부·파트너 IP, 모니터링/헬스체크 IP는 화이트리스트로 등록해 오탐을 줄입니다.

  • 세션 생성율 제한: 단일 소스/대역의 초당 세션 생성 제한을 설정하면 봇넷의 동시 접속을 억제할 수 있습니다.

 

3) 서버(TCP 스택) 튜닝 — 서비스 레벨 방어

  • tcp_syncookies=1, somaxconn와 tcp_max_syn_backlog 증가로 서버 소켓 대기열을 보호합니다.

  • 웹서버(nginx) 설정 예:

    keepalive_timeout 5;
    worker_connections 4096;
    client_header_timeout 10;

  • 설명: Keepalive를 줄여 불필요한 연결을 빨리 정리하고, worker 수·백로그를 늘려 정상 요청 수용성을 향상시킵니다.

 

4) 상위망 / ISP와의 협업

  • BGP RTBH(Remote Triggered Blackholing): 특정 피해 IP 또는 공격 대상에 대한 경로를 상위 ISP에 블랙홀로 걸어달라 요청(서비스 일시중단을 감수할 수 있을 때 유용).

  • 스크러빙 서비스 연계: 공격 트래픽이 클 때는 트래픽을 클라우드 스크러빙(예: Anycast 프론트엔드 + 필터링)으로 전환해 정상 트래픽만 전달받습니다. 비용과 개인정보 이슈를 사전 합의해 둡니다.

 

실전 플레이북(누가·무엇·언제)

 

  1. 탐지(0–5분): 알람·NetFlow로 트래픽 급증 확인 → 소스 분포(국가·AS), 포트, TCP 플래그 파악.

  2. 초기 차단(5–20분): 임계치 이하일 때는 방화벽에서 SYN rate-limit·conntrack 조정·GeoIP 차단 시작.

  3. 확장 완화(20–60분): 효과 미미 시 IPS 룰 강화, 상위 ISP에 RTBH 요청 또는 트래픽을 스크러빙 서비스로 리다이렉션.

  4. 정상화·포렌식(1일 이내): pcap/NetFlow 저장, 공격 패턴 분석, IPS 시그니처 업데이트, 고객 영향 분석.

  5. 사후조치(1주 이내): 플레이북·임계치 재정비, 파트너(Hosting/ISP)와 개선계약 체결.

 

익명화된 사례(교육용)

 

  • 사례 A — 연결 고갈형 SYN flood
    한 e-커머스 사이트는 출근 시간대에 연결 불가 알람이 떴습니다. 분석 결과 소스 IP의 80%가 중국 ISP 대역에 몰려 있었고, SYN 패킷 비율이 95%에 달했습니다. 초동으로 경계 FW에서 SYN rate-limit와 tcp_syncookies=1을 적용해 서버 부하를 낮췄고, 동시에 상위 ISP에 RTBH를 요청해 공격 트래픽을 차단했습니다. 이후 트래픽을 스크러빙 서비스로 옮겨 정상 트래픽만 복원했고, 사후 분석으로는 취약한 IoT를 이용한 봇넷이 주원인이었습니다.

  • 사례 B — 분산 반사 공격(설명 목적)
    UDP 기반 반사(예: memcached)가 아닌 TCP 증폭은 아니었지만, 대형 CDN과 협업해 Anycast 기반으로 분산 흡수 후 필터링으로 해결한 사례가 일반적입니다. 이 경우 로컬 필터로는 한계가 있어 클라우드 스크럽으로 전환한 뒤 서비스가 안정화되었습니다.

 

운영상 주의점(현장에서 자주 보는 함정)

 

  • 과도한 GeoIP 차단으로 인한 비즈니스 피해: 담당자가 긴급 대응 중 고객 불만 폭주로 복구에 추가 리스크 발생.

  • conntrack/TCP 튜닝의 과도 적용: 타임아웃을 너무 낮추면 정상 장기 연결 서비스(웹소켓 등)에 영향.

  • 로그 미비로 인한 미확인 대응: pcap·NetFlow를 즉시 수집하지 않으면 공격 근원 분석 불가.

 

핵심 요약

 

  • 초동에는 가시성 확보와 경계 규칙(특히 SYN rate-limit, conntrack 관리)이 가장 빠른 효과를 냅니다.

  • 공격이 크고 분산되면 ISP 협업(BGP RTBH) 또는 스크러빙 서비스로 트래픽을 옮겨 흡수하는 것이 현실적 방어입니다.

  • 모든 조치는 오탐·비즈니스 영향을 고려해 단계적으로 적용하고, 사건 후에는 로그·PCAP 기반으로 시그니처와 플레이북을 보강해야 합니다.