네트워크 공격 방어

Linux 커널 관점의 네트워크 공격 방어를 다룹니다. SYN/UDP/ICMP flooding 방어 기법과 rate limit 정책, syncookie 메커니즘, conntrack 기반 탐지 전략, 장애/침해 사고 시 관측 지표와 대응 절차까지 실무 중심으로 정리합니다. IPSec/WireGuard VPN은 IPSec & xfrm, WireGuard 문서를, Netlink는 Netlink 심화 문서를 참조하세요.

전제 조건: 네트워크 스택과 커널 보안 문서를 먼저 읽으세요. 보안 네트워킹은 정책 결정 경로와 실제 암복호화/필터 경로를 함께 보아야 운영 사고를 줄일 수 있습니다.
일상 비유: 이 주제는 출입 통제와 봉인 검사와 비슷합니다. 패킷을 통과시키기 전에 규칙 검사와 신원 확인을 거치듯이, 정책과 데이터 경로의 결합이 핵심입니다.

핵심 요약

  • 패킷 수명주기 — ingress, 처리, egress 경로를 연결합니다.
  • 큐/버퍼 모델 — sk_buff와 큐 지점의 역할을 분리합니다.
  • 정책/데이터 분리 — 제어 평면과 데이터 평면을 구분합니다.
  • 성능 지표 — PPS, 지연, 드롭 원인을 함께 분석합니다.
  • 오프로딩 경계 — NIC/XDP/DPDK 경계를 명확히 유지합니다.

단계별 이해

  1. 경로 고정
    문제가 발생한 ingress/egress 지점을 먼저 특정합니다.
  2. 큐 관찰
    백로그와 드롭 위치를 계측합니다.
  3. 정책 반영 확인
    라우팅/필터 변경이 데이터 경로에 반영됐는지 봅니다.
  4. 부하 검증
    실제 트래픽 패턴에서 재현성을 확인합니다.
관련 문서: 네트워크 보안 주제가 확장되어 다음 독립 문서로 분리되었습니다:
  • IPSec & xfrm — IPSec, ESP/AH, IKEv2, xfrm 프레임워크 상세
  • WireGuard VPN — Noise 프로토콜, Cryptokey Routing, 커널 구현
이 문서는 Flooding 방어에 집중합니다. Netlink 심화는 Netlink 심화 문서를 참고하세요.

네트워크 Flooding 공격과 커널 방어

네트워크 Flooding은 대량의 패킷을 보내 시스템 자원을 고갈시키는 DoS 공격 유형입니다. Linux 커널은 다양한 계층에서 방어 메커니즘을 내장하고 있습니다.

Ingress XDP/BPF Netfilter TCP/UDP Socket/App 조기 드롭 rate limit SYN Cookie 여러 계층에서 순차적으로 차단할수록 CPU와 메모리 소모가 줄어듭니다.

SYN Flood 방어

TCP SYN Flood는 대량의 SYN 패킷으로 서버의 SYN 큐(반개방 연결 큐)를 포화시킵니다:

/* 커널 SYN Flood 방어 체계 */

/* 1단계: SYN 큐 관리 */
/* net.ipv4.tcp_max_syn_backlog = 4096
 *   SYN 큐 크기. 초과 시 새 SYN 거부 또는 SYN Cookie 발동
 *
 * 2단계: SYN Cookie (앞서 상세 설명)
 * net.ipv4.tcp_syncookies = 1
 *   큐 overflow 시 상태 저장 없이 SYN+ACK 응답
 *   → 서버 메모리 소비 없이 연결 수립 가능
 *
 * 3단계: SYN 재전송 제한
 * net.ipv4.tcp_synack_retries = 5
 *   SYN+ACK 재전송 횟수 (5 → ~63초 후 포기)
 *   → 공격 시 2~3으로 감소 권장
 *
 * 4단계: Netfilter rate limiting
 */

/* net/ipv4/tcp_input.c — SYN 수신 처리 */
int tcp_conn_request(struct request_sock_ops *rsk_ops,
                     const struct tcp_request_sock_ops *af_ops,
                     struct sock *sk, struct sk_buff *skb)
{
    /* SYN 큐 overflow 확인 */
    if (inet_csk_reqsk_queue_is_full(sk)) {
        if (!net->ipv4.sysctl_tcp_syncookies) {
            /* SYN Cookie 미활성 → SYN 드롭 */
            goto drop;
        }
        want_cookie = true;
        /* SYN Cookie 모드: request_sock 할당 없이 진행 */
    }
    /* ... */
}

UDP Flood 방어

/* UDP Flood: 닫힌 포트로 대량 UDP 전송 → ICMP 응답 생성 부하 */

/* 방어 1: ICMP Rate Limiting */
/* net.ipv4.icmp_ratelimit = 1000 (ms)
 *   → ICMP 에러 메시지 전송 빈도 제한 (기본 1초에 1번)
 * net.ipv4.icmp_ratemask = 6168
 *   → rate limit 적용 대상 ICMP 타입 마스크
 */

/* 방어 2: conntrack 기반 차단 */
/* iptables -A INPUT -p udp -m state --state NEW -m recent \
 *   --set --name UDP_FLOOD
 * iptables -A INPUT -p udp -m state --state NEW -m recent \
 *   --update --seconds 1 --hitcount 20 --name UDP_FLOOD -j DROP
 */

/* 방어 3: XDP 레벨 조기 드롭 (가장 효과적) */
/* BPF 프로그램에서 특정 패턴의 UDP 패킷을 XDP_DROP
 * → 네트워크 스택 진입 전 NIC 드라이버 수준에서 차단
 * → 수백만 pps 처리 가능 */

ICMP Flood 방어

/* ICMP Flood (Ping Flood / Smurf Attack) */

/* 방어 1: ICMP Echo 응답 비활성화 (극단적) */
/* net.ipv4.icmp_echo_ignore_all = 1
 *   → 모든 ping 무시 (모니터링 도구에 영향)
 */

/* 방어 2: 브로드캐스트 Echo 무시 (Smurf 공격 방어) */
/* net.ipv4.icmp_echo_ignore_broadcasts = 1  (기본 활성)
 *   → 브로드캐스트/멀티캐스트 ICMP Echo Request 무시
 *   → Smurf 증폭 공격의 반사체 역할 방지
 */

/* 방어 3: Rate Limiting */
/* net.ipv4.icmp_ratelimit = 1000
 * → ICMP 응답 전송 빈도 제한 */

/* 방어 4: bogus ICMP 응답 차단 */
/* net.ipv4.icmp_ignore_bogus_error_responses = 1  (기본 활성)
 *   → 비정상적인 ICMP 에러 응답 무시 (로그 오염 방지)
 */

ARP Flood / ARP Spoofing 방어

/* ARP Spoofing: 위조된 ARP Reply로 MAC-IP 매핑 변조 */
/* ARP Flood: 대량 ARP Request로 ARP 캐시 오염 */

/* 방어 1: ARP 필터링 */
/* net.ipv4.conf.all.arp_filter = 1
 *   → 수신 인터페이스의 IP와 매칭되는 ARP만 응답
 */

/* 방어 2: Reverse Path Filtering (BCP38) */
/* net.ipv4.conf.all.rp_filter = 1
 *   → 소스 IP의 역방향 라우팅 검증
 *   → IP 스푸핑 패킷 차단 (소스 IP 위변조 감지)
 *   0: 비활성, 1: strict, 2: loose
 */

/* 방어 3: Static ARP 엔트리 */
/* ip neigh add 10.0.0.1 lladdr aa:bb:cc:dd:ee:ff nud permanent dev eth0 */

/* 방어 4: Dynamic ARP Inspection (스위치 레벨)
 *   커널 측: ebtables로 ARP 필터링 가능
 *   ebtables -A INPUT --protocol arp --arp-ip-src ! 10.0.0.0/24 -j DROP
 */

종합 Flooding 방어 체계

계층방어 기법처리 위치성능
L2 (Driver/XDP) XDP BPF 프로그램 (XDP_DROP) NIC 드라이버 내부 수천만 pps 처리 가능
L3 (Netfilter) nftables/iptables rate limit, conntrack PREROUTING/INPUT 수백만 pps
L4 (TCP) SYN Cookie, SYN 큐 크기, 재전송 제한 TCP 스택 커널 내장
L4 (UDP) ICMP rate limit, conntrack, BPF UDP/ICMP 스택 커널 내장
Application SO_REUSEPORT + BPF steering, backpressure 소켓 계층 애플리케이션 의존 
# 실시간 Flooding 탐지 및 모니터링

# 1. 인터페이스 패킷 카운터 모니터링
watch -n 1 'ethtool -S eth0 | grep -E "rx_packets|rx_dropped|rx_errors"'

# 2. conntrack 테이블 상태 확인
conntrack -C        # 현재 엔트리 수
conntrack -S        # 통계 (drop 카운터 확인)

# 3. SYN 큐 상태 확인
ss -tnl | awk '{print $2, $3, $4}'  # Recv-Q, Send-Q, Local Address
# Recv-Q가 큰 값이면 accept 큐 포화 의심

# 4. softnet_stat으로 드롭 확인
cat /proc/net/softnet_stat
# 두 번째 컬럼이 0이 아니면 → softirq 처리 과부하 (패킷 드롭)
# 세 번째 컬럼이 0이 아니면 → time_squeeze (budget 부족)

# 5. nftables rate limit 설정 예시
nft add rule inet filter input ip protocol icmp limit rate 10/second accept
nft add rule inet filter input ip protocol icmp drop
nft add rule inet filter input tcp flags syn limit rate 100/second accept
nft add rule inet filter input tcp flags syn drop
⚠️

XDP 기반 방어의 중요성: 대규모 DDoS(수백Gbps)에서는 Netfilter 수준 방어로는 CPU가 포화됩니다. XDP는 NIC 드라이버 내에서(또는 HW offload로 NIC 자체에서) 패킷을 처리하므로, 커널 네트워크 스택 진입 전에 차단이 가능합니다. Cloudflare, Facebook 등이 XDP 기반 DDoS 방어를 실전에 적용하고 있습니다. 자세한 내용은 BPF/XDP 페이지를 참고하세요.

Netlink 프로토콜 심화 내용(rtnetlink, genetlink, AF_NETLINK 소켓, 메시지 형식, 커널 API 등)은 Netlink 심화 문서에서 상세히 다룹니다.

Unix Domain Socket

Unix Domain Socket(AF_UNIX) 심화 내용(소켓 생성, SCM_RIGHTS 파일 디스크립터 전달, 추상 네임스페이스, 보안 모델 등)은 향후 Unix Domain Socket 심화 문서에서 다룰 예정입니다.

네트워크 보안과 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.