“DDoS 방어 서비스를 사용하면 공격이 막힌다”는 건 알지만, 어떤 원리로 수백 Gbps의 공격 트래픽 속에서 정상 사용자만 골라내는지 궁금했던 적이 있으신가요? 이 글에서는 DDoS 방어의 핵심 메커니즘을 단계별로 설명합니다.

---

다계층 방어 구조

DDoS 방어는 한 가지 기술로 해결되지 않습니다. 공격 트래픽이 서버에 도달하기까지 여러 계층을 거치면서 단계적으로 걸러지는 다계층(Multi-layer) 방어 구조가 핵심입니다.

방어 계층	역할	차단 대상
ISP / 상위 네트워크	대용량 볼류메트릭 공격 차단	UDP Flood, ICMP Flood, DNS Amplification
스크러빙 센터	정밀 트래픽 분석 및 필터링	SYN Flood, 프로토콜 이상, 봇 트래픽
서버 레벨	잔여 공격 차단, 세밀한 제어	Slowloris, HTTP Flood, 비정상 요청

각 단계를 통과할 때마다 공격 트래픽이 제거되어, 최종적으로 서버에는 정상 트래픽만 도달합니다.

---

1단계 — ISP / 상위 네트워크 방어

서버가 위치한 데이터센터의 상위 네트워크(ISP)에서 수행하는 방어입니다. 대용량 트래픽 공격을 가장 먼저 걸러냅니다.

BGP Blackhole Routing

공격이 감지되면 해당 IP로 향하는 트래픽을 네트워크 경계에서 모두 폐기(Blackhole) 하는 방식입니다.

정상적인 라우팅:
  인터넷 → ISP → 데이터센터 → 서버 (공격 트래픽도 함께 도달)

BGP Blackhole 적용 후:
  인터넷 → ISP → /dev/null (트래픽 전체 폐기)

• 장점: 수백 Gbps 공격도 즉시 차단 가능
• 단점: 정상 트래픽도 함께 차단됨 — 서비스 중단과 같은 효과
• 용도: 공격 규모가 너무 커서 다른 방어가 불가능할 때 최후의 수단

BGP Flowspec

Blackhole보다 정밀한 방식입니다. 특정 프로토콜, 포트, 패킷 크기 등을 기준으로 필터링 규칙을 동적으로 배포합니다.

예시 Flowspec 규칙:
  목적지: 203.0.113.10
  프로토콜: UDP
  포트: != 53 (DNS 제외)
  동작: DROP

→ 해당 IP로 오는 UDP 트래픽 중 DNS 외 전부 차단
→ 정상적인 DNS 응답은 통과

ACL 기반 필터링

라우터/스위치 레벨에서 출발지 IP, 프로토콜, 포트 기반으로 패킷을 차단합니다.

# 일반적인 ACL 필터 예시 (Cisco IOS 형식)
access-list 101 deny udp any host 203.0.113.10 eq 80
access-list 101 deny icmp any any echo
access-list 101 permit ip any any

---

2단계 — 스크러빙 센터

DDoS 방어의 핵심 기술입니다. 공격 트래픽과 정상 트래픽을 분리(Scrubbing) 하여, 정상 트래픽만 오리진 서버로 전달합니다.

동작 과정

1) 트래픽 우회(Diversion)

공격이 감지되면 서버로 향하는 트래픽을 스크러빙 센터로 우회시킵니다.

평상시:
  사용자 → ISP → 데이터센터 → 서버

공격 감지 시:
  사용자 → ISP → [스크러빙 센터] → 데이터센터 → 서버

우회 방법은 크게 두 가지입니다:

• BGP 경로 변경: 서버 IP의 라우팅 경로를 스크러빙 센터로 변경
• DNS 변경: 도메인이 스크러빙 센터의 IP를 가리키도록 변경 (프록시 방식)

2) 심층 패킷 분석(DPI)

스크러빙 센터에 도착한 트래픽은 패킷 단위로 정밀 분석됩니다.

분석 항목:
├── 프로토콜 유효성 — TCP 핸드셰이크가 정상적인가?
├── 페이로드 패턴 — 알려진 공격 시그니처와 일치하는가?
├── 통계적 이상 — 평소 대비 트래픽 패턴이 비정상인가?
├── IP 평판 — 이 IP가 봇넷에 속한 것으로 알려져 있는가?
└── 행위 분석 — 실제 브라우저/클라이언트 행위와 일치하는가?

3) 필터링 및 전달(Injection)

분석 결과에 따라 악성 트래픽은 폐기하고, 정상 트래픽만 GRE 터널이나 직접 연결을 통해 오리진 서버로 전달합니다.

---

3단계 — 서버 레벨 방어

상위 단계에서 대부분의 공격이 걸러지지만, 서버 자체에서도 추가 방어를 설정해야 합니다. 특히 L7(애플리케이션) 공격은 정상 요청과 구분이 어려워 서버 레벨 방어가 중요합니다.

SYN Cookie — SYN Flood 방어의 핵심

SYN Flood는 TCP 3-way 핸드셰이크를 악용한 공격입니다. 공격자가 대량의 SYN 패킷을 보내고 ACK를 보내지 않으면, 서버의 연결 테이블이 가득 차서 정상 접속이 불가능해집니다.

SYN Cookie의 원리:

일반적인 TCP 핸드셰이크:
  클라이언트 → SYN → 서버 (서버가 연결 정보를 메모리에 저장)
  서버 → SYN-ACK → 클라이언트
  클라이언트 → ACK → 서버 (연결 성립)

SYN Cookie 적용 시:
  클라이언트 → SYN → 서버 (메모리에 저장하지 않음!)
  서버 → SYN-ACK → 클라이언트
    └→ 시퀀스 번호에 연결 정보를 암호화하여 포함 (= Cookie)
  클라이언트 → ACK → 서버
    └→ 서버가 ACK의 시퀀스 번호에서 연결 정보를 복원
    └→ 정상 ACK가 돌아온 경우에만 연결 성립

핵심은 ACK가 돌아올 때까지 서버 메모리를 전혀 사용하지 않는다는 것입니다. 공격자가 아무리 많은 SYN을 보내도 메모리가 고갈되지 않습니다.

# Linux에서 SYN Cookie 활성화
sysctl -w net.ipv4.tcp_syncookies=1

# 영구 적용
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
sysctl -p

Connection Tracking 제한

Linux의 conntrack은 모든 네트워크 연결을 추적합니다. DDoS 공격 시 이 테이블이 가득 차면 정상 연결도 거부됩니다.

# 현재 conntrack 사용량 확인
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# 최대값 상향 (메모리에 여유가 있을 때)
sysctl -w net.netfilter.nf_conntrack_max=1048576

# 연결 추적 타임아웃 단축
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

iptables Rate Limiting

동일 IP에서 과도한 요청을 보내는 경우 iptables로 제한할 수 있습니다.

# 동일 IP에서 초당 새 연결 20개 제한
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 20/s --limit-burst 40 -j ACCEPT

# 비정상 패킷 차단
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Nginx Rate Limiting

L7 공격에 대한 방어입니다. 동일 IP에서 과도한 HTTP 요청을 제한합니다.

# /etc/nginx/nginx.conf
http {
    # 요청 속도 제한 존 정의 (IP당 초당 10요청)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;

    # 연결 수 제한 존 정의 (IP당 동시 연결 20개)
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    server {
        # 요청 속도 제한 적용 (burst 허용 20개, 초과 시 지연 없이 거부)
        limit_req zone=req_limit burst=20 nodelay;

        # 동시 연결 수 제한
        limit_conn conn_limit 20;

        # 요청 본문 크기 제한 (Slowloris 변형 방어)
        client_body_timeout 10s;
        client_header_timeout 10s;
        client_max_body_size 1m;
    }
}

---

BGP Anycast — 대규모 방어의 핵심 인프라

전 세계에 분산된 여러 지점에서 동일한 IP 주소를 광고하여, 사용자(또는 공격자)의 트래픽이 가장 가까운 지점으로 자동 라우팅되게 하는 기술입니다.

Anycast 없이:
  모든 공격 트래픽 → 서버 1대로 집중 → 대역폭 초과 → 서비스 다운

Anycast 적용:
  공격 트래픽 → 전 세계 PoP(Point of Presence)으로 분산
  ├→ 도쿄 PoP: 30Gbps 처리
  ├→ 싱가포르 PoP: 25Gbps 처리
  ├→ LA PoP: 20Gbps 처리
  └→ 프랑크푸르트 PoP: 25Gbps 처리
  총 100Gbps 공격이 4곳으로 분산 → 각 지점에서 처리 가능

Cloudflare, Akamai 같은 대형 DDoS 방어 업체가 수십 Tbps 규모의 공격을 방어할 수 있는 이유가 바로 이 Anycast 네트워크 덕분입니다.

---

L7 방어 — 봇과 사람을 구분하는 원리

L3/L4 공격은 패킷 수준에서 비교적 쉽게 구분할 수 있지만, L7 공격은 정상적인 HTTP 요청과 동일한 형태를 띠기 때문에 구분이 어렵습니다.

JavaScript Challenge

사용자의 브라우저에 JavaScript를 실행시켜, 실제 브라우저인지 확인합니다.

1. 서버가 JavaScript 챌린지 페이지 응답
2. 정상 브라우저: JS 실행 → 계산 결과 전송 → 통과
3. 봇/스크립트: JS 실행 불가 → 차단

행위 기반 분석 (Behavioral Analysis)

정상 사용자와 봇의 행동 패턴 차이를 분석합니다.

행위	정상 사용자	봇/공격
요청 간격	불규칙적	매우 일정
마우스 이동	자연스러운 곡선	없음 또는 직선
쿠키/세션	유지	없거나 비정상
User-Agent	일관된 브라우저 정보	무작위 또는 비어 있음
요청 순서	HTML → CSS → JS → 이미지	HTML만 반복

Rate Limiting + IP 평판

• 동일 IP에서 비정상적으로 많은 요청 → 속도 제한 후 차단
• 알려진 봇넷 IP, TOR 출구 노드, 데이터센터 IP 등을 평판 DB로 관리
• 평판이 낮은 IP에 더 강한 검증 적용

---

방어 방식 비교 요약

방어 방식	방어 가능 공격	장점	단점
BGP Blackhole	모든 볼류메트릭	즉시 적용, 간단	정상 트래픽도 차단
BGP Flowspec	L3/L4	선별적 차단 가능	ISP 지원 필요
스크러빙 센터	L3/L4/L7	정밀 분석, 정상 트래픽 보존	비용, 지연 추가
SYN Cookie	SYN Flood	서버 자체 적용 가능	TCP 옵션 일부 제한
Rate Limiting	L7 Flood	간단한 설정	오탐 가능성
JS Challenge	L7 봇 공격	높은 정확도	JS 미지원 클라이언트 차단

---

마무리

DDoS 방어의 핵심은 단일 솔루션이 아닌 다계층 구조에 있습니다. 상위 네트워크에서 대용량 공격을 흡수하고, 스크러빙 센터에서 정밀 필터링하며, 서버 레벨에서 잔여 공격을 처리하는 구조가 효과적입니다.

직접 모든 방어를 구축하기보다는, 네트워크 단 방어가 기본 제공되는 호스팅을 선택하는 것이 현실적입니다. TCP-80.NET은 모든 서버에 L3/L4 네트워크 공격 차단을 기본 무료 제공하며, L7 공격 방어가 필요한 경우 전용 DDoS 방어 서비스를 추가할 수 있습니다.