네트워크 공격 방어

리눅스 커널 관점에서 DoS/DDoS를 방어하는 핵심은 대역폭보다 먼저 상태(state) 예산과 CPU 예산을 보호하는 것입니다. 이 문서는 SYN Flood, UDP/ICMP 증폭, conntrack 고갈, Slowloris 계열, IP 스푸핑과 L2 위변조를 커널 수신 경로에 맞춰 정리하고, XDP, nftables/SYNPROXY, TCP backlog, conntrack, 관측 지표와 사고 대응 절차를 실무 관점에서 묶어 설명합니다. VPN 암호화는 IPSec & xfrm, WireGuard 문서를 따로 보세요.

위협 모델 먼저 잡기

같은 DDoS처럼 보여도 커널 입장에서 고갈되는 자원은 다릅니다. 대충 "패킷이 많다"로 묶으면 잘못된 계층에 방어를 걸게 됩니다. 커널 방어는 어떤 상태가 만들어지기 전에 끊을 수 있는가를 기준으로 설계해야 합니다.

수신 경로 병목을 알아야 방어가 맞습니다

패킷은 NIC RX 링에서 시작해 NAPI poll, softnet backlog, Netfilter/conntrack, TCP/UDP 스택, 소켓 큐, 애플리케이션 worker까지 올라갑니다. 공격이 어느 단계에서 CPU와 메모리를 태우는지 보지 않으면, 늦은 계층에서 비싼 검사를 하다가 이미 무너진 뒤에야 드롭하게 됩니다.

RSS, RPS, RFS, Flow Limit으로 고 PPS를 분산합니다

고 PPS 공격은 평균 CPU 사용률보다 어느 큐와 어느 CPU가 과열되는지가 더 중요합니다. 리눅스 커널 문서는 RSS를 하드웨어 큐 분산, RPS를 소프트웨어 기반 RSS, RFS를 애플리케이션 CPU locality 강화, Flow Limit를 backlog가 절반을 넘었을 때 큰 flow를 먼저 억제하는 장치로 설명합니다. 이 네 가지는 서로 대체하는 기능이 아니라 계층이 다른 도구입니다.

# 1. 하드웨어 RX 큐와 IRQ 분포 확인
ethtool -x eth0
grep eth0 /proc/interrupts

# 2. NIC 큐 수가 CPU 수보다 적을 때 RPS 활성화 예시
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo f > /sys/class/net/eth0/queues/rx-1/rps_cpus

# 3. RFS 활성화: 전역 엔트리 + 큐별 엔트리
sysctl -w net.core.rps_sock_flow_entries=32768
echo 16384 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
echo 16384 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt

# 4. Flow Limit 활성화: backlog가 절반을 넘을 때 큰 flow 억제
sysctl -w net.core.flow_limit_cpu_bitmap=f
sysctl -w net.core.netdev_max_backlog=4096

# 5. 특정 포트를 별도 RSS context로 분리하는 ethtool 예시
ethtool -X eth0 hfunc toeplitz context new
ethtool -x eth0 context 1
ethtool -X eth0 equal 2 context 1
ethtool -N eth0 flow-type tcp6 dst-port 22 context 1

SYN Flood: backlog가 어디서 차는지 구분해야 합니다

SYN Flood는 TCP가 3-way handshake를 완료하기 전까지 잠깐 저장하는 상태를 겨냥합니다. 여기서 자주 헷갈리는 것이 listen backlog와 SYN backlog의 차이입니다.

• listen(backlog)와 somaxconn — 애플리케이션이 accept() 하기 전 완료된 연결이 대기하는 accept queue 상한입니다. 현재 커널 문서는 somaxconn 기본값을 4096으로 설명합니다.
• tcp_max_syn_backlog — 아직 ACK를 받지 못한 SYN_RECV 요청을 기억하는 per-listener 한도입니다.
• tcp_synack_retries — 커널 문서 기준 기본값 5이며, 현재 RTO 정책에서 마지막 재전송까지 약 31초, 최종 타임아웃까지 약 63초가 걸릴 수 있습니다.
• tcp_syncookies — SYN backlog overflow 시 request_sock를 만들지 않고 cookie 기반으로 ACK를 검증합니다. 커널 문서도 이것을 "정상 과부하 튜닝용"이 아니라 공격 대응용 비상 모드로 취급하라고 강하게 경고합니다.
• tcp_abort_on_overflow — accept가 너무 느릴 때 연결을 reset으로 끊습니다. 문서도 "정말 확신할 때만" 켜라고 합니다.

/* net/ipv4/tcp_ipv4.c + tcp_input.c 경로를 읽기 쉽게 줄인 의사 코드 */
int tcp_v4_rcv(struct sk_buff *skb)
{
    /* 1. LISTEN 소켓이면 새 연결 요청 처리 */
    if (sk_state(skb) == TCP_LISTEN)
        return tcp_conn_request(...);
}

int tcp_conn_request(..., struct sock *sk, struct sk_buff *skb)
{
    bool want_cookie = false;

    /* 2. SYN backlog가 꽉 찼는지 확인 */
    if (inet_csk_reqsk_queue_is_full(sk)) {
        if (!READ_ONCE(net->ipv4.sysctl_tcp_syncookies))
            goto drop;
        want_cookie = true;
    }

    /* 3. 정상 경로면 request_sock를 만들고 SYN+ACK 전송 */
    if (!want_cookie)
        inet_csk_reqsk_queue_hash_add(sk, req, timeout);

    /* 4. cookie 경로면 상태를 저장하지 않고 ISN에 쿠키 부호화 */
    if (want_cookie)
        isn = cookie_v4_init_sequence(sk, skb, ...);

    /* 5. 최종 ACK가 오면 cookie 검증 후 child socket 생성 */
    return tcp_v4_send_synack(sk, skb, ...);
drop:
    return 0;
}

# nftables SYNPROXY 예시
# 공식 nftables manpage 예시 구조를 Linux 서버 환경에 맞게 정리한 것

sysctl -w net.netfilter.nf_conntrack_tcp_loose=0

nft add table ip raw
nft 'add chain ip raw prerouting { type filter hook prerouting priority raw; policy accept; }'
nft add rule ip raw prerouting tcp flags syn notrack

nft add table ip filter
nft 'add chain ip filter input { type filter hook input priority filter; policy accept; }'
nft add rule ip filter input ct state invalid,untracked synproxy mss 1460 wscale 9 timestamp sack-perm
nft add rule ip filter input ct state invalid drop

# 서버 자체 보호용 최소 확인
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_synack_retries=3
sysctl -w net.core.somaxconn=8192

UDP/ICMP Flood와 반사·증폭 공격

UDP Flood는 TCP처럼 handshake 상태를 만들지 않기 때문에 "가볍다"고 오해하기 쉽지만, 실제 운영에서는 높은 PPS, 닫힌 포트 ICMP 응답 생성, conntrack 엔트리 남발, 애플리케이션 파서 비용 때문에 빠르게 CPU를 태웁니다. 특히 DNS, NTP, SSDP 같은 반사·증폭 계열은 상대적으로 작은 송신량으로 큰 응답을 유도할 수 있습니다.

# ICMP 응답 예산 보호
sysctl -w net.ipv4.icmp_ratelimit=1000
sysctl -w net.ipv4.icmp_msgs_per_sec=1000
sysctl -w net.ipv4.icmp_msgs_burst=50
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

# UDP / ICMP 속도 제한 예시
nft add table inet ddos
nft 'add chain inet ddos input { type filter hook input priority filter; policy accept; }'
nft add rule inet ddos input udp dport { 53, 123, 1900, 11211 } meter amp4 '{ ip saddr timeout 10s limit rate over 200/second }' drop
nft add rule inet ddos input ip protocol icmp icmp type echo-request meter ping4 '{ ip saddr timeout 10s limit rate over 20/second }' drop
nft add rule inet ddos input ct state invalid drop

# 서비스가 conntrack/NAT를 정말 필요로 하지 않는 앞단이라면 raw 훅에서 notrack 검토
# 단, notrack는 stateful firewall/NAT 관측을 우회하므로 적용 범위를 매우 좁게 잡아야 함

conntrack 고갈은 전체 서비스에 전염됩니다

nf_conntrack는 특정 서비스 하나의 큐가 아니라 호스트 또는 네임스페이스 전체에서 공유되는 상태 자원입니다. 그래서 한 서비스로 들어오는 flood가 전혀 관계없는 다른 서비스의 새 연결까지 실패하게 만들 수 있습니다. 특히 UDP spray, spoofed SYN, fragment 폭탄은 짧은 시간에 많은 엔트리를 만들고, timeout이 길면 메모리 점유가 길어집니다.

# 현재 conntrack 상태 점검
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_buckets
conntrack -S

# 공격 시 자주 보는 보수적 조정 예시
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=30
sysctl -w net.netfilter.nf_conntrack_udp_timeout=15
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60
sysctl -w net.netfilter.nf_conntrack_log_invalid=6
sysctl -w net.netfilter.nf_conntrack_acct=1

# state가 불필요한 아주 제한된 트래픽만 raw에서 notrack
# nft add table inet raw
# nft 'add chain inet raw prerouting { type filter hook prerouting priority raw; policy accept; }'
# nft add rule inet raw prerouting ip protocol icmp notrack
# 위 예시는 "가능한 문법" 예시일 뿐이며, 실제 운영에선 NAT/정책 우회 영향을 반드시 검토해야 합니다.

조각화와 재조립 큐도 별도 자원 예산입니다

fragment flood는 대역폭이 아주 크지 않아도 미완성 재조립 큐와 긴 timeout을 이용해 메모리를 오래 점유할 수 있습니다. 조각이 충분히 모이지 않으면 상위 계층까지 가지 못한 채 재조립 버퍼만 남습니다. 서비스가 실제로 큰 UDP, 터널, 특수 장비 트래픽을 얼마나 쓰는지 모른 채 threshold만 올리면 공격 표면도 같이 커집니다.

# 현재 fragment / reassembly 관련 값 확인
sysctl net.ipv4.ipfrag_high_thresh
sysctl net.ipv4.ipfrag_time
sysctl net.ipv4.ipfrag_max_dist
sysctl net.ipv6.ip6frag_high_thresh
sysctl net.ipv6.ip6frag_time
sysctl net.netfilter.nf_conntrack_frag6_high_thresh
sysctl net.netfilter.nf_conntrack_frag6_low_thresh
sysctl net.netfilter.nf_conntrack_frag6_timeout

# 공격 시 자주 시도하는 보수적 조정 예시
sysctl -w net.ipv4.ipfrag_time=15
sysctl -w net.ipv4.ipfrag_max_dist=64
sysctl -w net.ipv6.ip6frag_time=15
sysctl -w net.netfilter.nf_conntrack_frag6_timeout=30

# 서비스가 조각화를 거의 쓰지 않는다면 fragment 비율 자체를 관측 경보로 올리는 편이 안전
nstat -az IpReasmReqds IpReasmOKs IpReasmFails

XDP, nftables, conntrack을 계층적으로 써야 합니다

방어를 잘하는 시스템은 "모든 검사를 한 군데서 많이" 하지 않습니다. 보통은 다음 순서가 좋습니다.

1. XDP — 명백히 버릴 패킷을 가장 먼저 드롭합니다. spoofed source, 알려진 반사 포트, 비정상 헤더, 매우 단순한 rate limiting이 여기 적합합니다.
2. nftables raw/prerouting — notrack 여부를 결정하고, 값싼 매치와 set/meter로 더 줄입니다.
3. nftables filter/input + conntrack — 살아남은 패킷에만 stateful 정책을 적용합니다.
4. TCP/애플리케이션 — syncookie, SYNPROXY, TCP_DEFER_ACCEPT, reverse proxy timeout으로 마지막 상태 예산을 보호합니다.

커널 XDP 문서는 redirect 경로를 세 단계로 설명합니다. bpf_redirect()/bpf_redirect_map()이 대상 정보를 per-CPU 구조체에 넣고, 드라이버가 xdp_do_redirect()로 enqueue한 뒤, NAPI poll 종료 전 xdp_do_flush()를 호출해 실제 전송을 완료합니다. 이 구조는 flood 방어에서 드롭만 아니라 격리에도 중요합니다. 예를 들어 공격 의심 트래픽을 AF_XDP나 cpumap으로 분리해 분석할 수 있습니다.

/* XDP에서 source별 간단한 토큰 버킷을 적용하는 의사 코드 */
struct rate_key {
    __u32 saddr;
    __u16 dport;
    __u8 proto;
};

struct rate_val {
    __u64 window_ns;
    __u32 packets;
};

SEC("xdp")
int ddos_guard(struct xdp_md *ctx)
{
    if (!parse_ipv4_udp(ctx, &iph, &uh))
        return XDP_PASS;

    if (uh->dest == bpf_htons(53) || uh->dest == bpf_htons(123)) {
        key.saddr = iph->saddr;
        key.dport = uh->dest;
        key.proto = iph->protocol;

        val = bpf_map_lookup_elem(&rate_map, &key);
        if (over_limit(val, bpf_ktime_get_ns()))
            return XDP_DROP;
    }

    return XDP_PASS;
}

Slowloris 계열은 패킷보다 연결 점유 시간이 문제입니다

Slowloris, Slow POST, Slow Read 류 공격은 "패킷이 매우 많다"기보다 오래 붙잡고 놓지 않는 연결을 이용합니다. 그래서 XDP나 단순 PPS 제한은 거의 안 듣고, 소켓 수, accept loop, 워커 스레드, 애플리케이션 요청 timeout이 핵심이 됩니다. 커널이 할 수 있는 일과 애플리케이션이 해야 하는 일을 분리해서 봐야 합니다.

# 커널 쪽에서 먼저 보는 값
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_abort_on_overflow

# listener queue 관찰
ss -lnt
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPBacklogDrop

# 애플리케이션은 별도로 header/read timeout, keepalive timeout을 짧게 가져가야 함
# Slowloris는 커널 한 군데만 만져서 해결되지 않습니다.

스푸핑과 L2 위변조는 ingress filtering이 기본입니다

IP 스푸핑이 허용되면 UDP 증폭과 SYN Flood의 추적과 정책 적용이 모두 어려워집니다. 커널의 rp_filter는 RFC 3704가 설명하는 strict/loose reverse path filtering 개념과 대응됩니다. 커널 문서는 strict mode(1)가 DDoS 방어를 위해 권장되지만, 비대칭 라우팅이나 복잡한 멀티홈 환경이면 loose mode(2)가 더 적절할 수 있다고 설명합니다.

# 스푸핑 방어 시작점
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1

# 비대칭 경로 / 멀티홈이면 loose mode 고려
sysctl -w net.ipv4.conf.eth0.rp_filter=2

# 같은 서브넷 다중 NIC 환경
sysctl -w net.ipv4.conf.all.arp_filter=1

# 매우 중요한 피어는 정적 neighbor 사용도 검토
ip neigh add 10.0.0.1 lladdr aa:bb:cc:dd:ee:ff nud permanent dev eth0

관측 지표: 어디가 먼저 무너지는지 바로 보이게 만들기

방어는 규칙보다 계측이 먼저입니다. 카운터가 없으면 "좋아진 것 같다" 수준에서 멈춥니다. 커널에서 바로 볼 수 있는 지표를 병목별로 묶으면 다음과 같습니다.

# 1. SYN Flood / listener 관측
nstat -az TcpExtSyncookiesSent TcpExtSyncookiesRecv TcpExtSyncookiesFailed \
          TcpExtListenOverflows TcpExtListenDrops \
          TcpExtTCPReqQFullDoCookies TcpExtTCPReqQFullDrop

# 2. conntrack 압력
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
conntrack -S

# 3. 소프트웨어 수신 큐 병목
watch -n 1 'cat /proc/net/softnet_stat'

# 4. XDP redirect / 예외 추적
perf record -a -e xdp:xdp_redirect_err -e xdp:xdp_redirect_map_err -e xdp:xdp_exception -e xdp:xdp_devmap_xmit

# 5. 드라이버 카운터
watch -n 1 'ethtool -S eth0 | grep -E "rx_packets|rx_dropped|rx_errors|rx_missed"'

사고 대응 절차

1. 공격 형태를 분리합니다. bps보다 pps, TCP SYN 비율, UDP 대상 포트, ICMP 타입, 소스 분산 정도를 먼저 봅니다.
2. 병목 카운터를 고정합니다. softnet_stat, nstat, nf_conntrack_count, ethtool -S 중 어디가 가장 먼저 증가하는지 찍습니다.
3. 차단 계층을 앞당깁니다. input 훅에서 버티지 말고 XDP, raw, prerouting으로 옮길 수 있으면 옮깁니다.
4. 상태를 줄입니다. SYNPROXY, syncookies, notrack, timeout 단축으로 메모리 체류 시간을 줄입니다.
5. 정상 트래픽 손실을 검증합니다. health check, 실제 사용자 경로, TLS handshake, DNS 질의 등 핵심 정상 트래픽을 동시에 확인합니다.
6. 임시 규칙을 영속 정책으로 정리합니다. 공격 중 급히 넣은 drop rule은 사후에 범위, 만료 시간, 모니터링과 함께 다시 설계합니다.

권장 하드닝 체크리스트

• SYN 서비스는 somaxconn, 애플리케이션 backlog, tcp_max_syn_backlog, tcp_syncookies를 함께 점검합니다.
• 대량 PPS 방어는 가능하면 XDP 또는 그에 준하는 더 앞단 장비로 옮깁니다.
• NIC queue가 CPU보다 적거나 한 queue만 과열되면 RSS만 보지 말고 RPS, RFS, Flow Limit을 함께 검토합니다.
• nftables에서는 set/meter/counter를 적극 사용하고, state가 필요 없는 흐름만 제한적으로 notrack 합니다.
• nf_conntrack_count와 nf_conntrack_max는 반드시 메트릭으로 수집합니다.
• fragment를 실제로 쓰는 서비스가 적다면 ipfrag_*, ip6frag_*, nf_conntrack_frag6_* 값과 IpReasm* 카운터를 같이 관찰합니다.
• 비대칭 경로가 아니라면 rp_filter=1을 기본으로 검토하고, 멀티홈이면 2로 완화합니다.
• Slowloris 대응은 커널보다 애플리케이션 timeout과 reverse proxy 정책이 주력임을 문서화합니다.
• nstat의 SyncookiesSent, ListenOverflows, TCPReqQFullDoCookies를 대시보드에 올립니다.
• XDP를 쓰면 xdp_exception, xdp_redirect_err tracepoint까지 수집해 조용한 실패를 막습니다.

SYN Flood 커널 처리 경로와 syncookie 메커니즘

SYN Flood 공격이 커널 내부에서 어떤 함수 경로를 타는지 정확히 아는 것이 방어의 시작입니다. TCP 리스너로 SYN 패킷이 도착하면 tcp_v4_rcv() → tcp_v4_do_rcv() → tcp_rcv_state_process() → tcp_conn_request() 경로를 거칩니다. 이 경로에서 tcp_syn_flood_action()이 syncookie 발동 여부를 결정하는 핵심 게이트입니다.

/* net/ipv4/tcp_input.c — tcp_syn_flood_action() 핵심 로직 */
static bool tcp_syn_flood_action(const struct sock *sk,
                                  const char *proto)
{
    const char *msg = "Sending cookies";
    bool want_cookie = false;
    struct listen_sock *lopt;

    /* sysctl tcp_syncookies 값 확인 */
    if (READ_ONCE(net->ipv4.sysctl_tcp_syncookies) != 2) {
        /* 2가 아니면(=1) overflow 시에만 syncookie 발동 */
        lopt = inet_csk(sk)->icsk_accept_queue.listen_opt;
        if (!lopt->qlen_young)
            return false;
    }

    /* syncookies=2 이면 항상 cookie 모드 */
    want_cookie = true;
    NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDOCOOKIES);

    /* rate-limited 경고 로그 출력 */
    if (!net->ipv4.sysctl_tcp_syncookies)
        msg = "Dropping request";
    net_info_ratelimited("%s: Possible SYN flooding on port %d. %s.\n",
                         proto, sk->sk_num, msg);

    return want_cookie;
}

/* net/ipv4/syncookies.c — cookie_v4_init_sequence() 핵심 */
__u32 cookie_v4_init_sequence(const struct sk_buff *skb,
                              __u16 *mssp)
{
    const struct iphdr *iph = ip_hdr(skb);
    const struct tcphdr *th = tcp_hdr(skb);
    int mssind;

    /* MSS를 4개 슬롯 중 하나로 양자화 */
    const __u16 msstab[] = { 536, 1300, 1440, 1460 };
    mssind = cookie_mss_index(*mssp, msstab);

    /* ISN = HMAC(saddr, daddr, sport, dport, count) | mssind */
    return secure_tcp_syn_cookie(iph->saddr, iph->daddr,
                                  th->source, th->dest,
                                  ntohl(th->seq),
                                  mssind);
}

SYN Flood 관측과 대응 순서

SYN Flood 공격이 의심될 때 커널 카운터를 읽는 순서가 중요합니다. 먼저 SyncookiesSent가 증가하는지 확인하고, 다음으로 ListenOverflows와 ListenDrops를 비교합니다. 두 값이 함께 오르면 accept queue 문제이고, SyncookiesSent만 오르면 SYN backlog 문제입니다.

# SYN Flood 단계별 진단 순서

# 1단계: syncookie 발동 여부 확인
nstat -az TcpExtSyncookiesSent TcpExtSyncookiesRecv TcpExtSyncookiesFailed
# SyncookiesSent > 0 → SYN backlog overflow 발생 중
# SyncookiesFailed > 0 → 위조된 ACK나 만료된 cookie

# 2단계: accept queue overflow 확인
nstat -az TcpExtListenOverflows TcpExtListenDrops
# ListenOverflows > 0 → accept queue가 가득 참
# 애플리케이션의 accept() 속도가 느린 것

# 3단계: 어느 리스너가 압력을 받는지 확인
ss -lnt | awk 'NR>1 && $2>0 {print}'
# Recv-Q > 0 인 리스너가 accept queue 압력을 받는 것

# 4단계: SYN 소스 분포 확인
conntrack -L -p tcp --state SYN_RECV 2>/dev/null | \
    awk '{for(i=1;i<=NF;i++) if($i~/^src=/) print $i}' | \
    sort | uniq -c | sort -rn | head -20

# 5단계: 대응 — backlog 확대 + syncookie 활성 확인
sysctl -w net.ipv4.tcp_max_syn_backlog=16384
sysctl -w net.core.somaxconn=16384
sysctl -w net.ipv4.tcp_syncookies=1

request_sock 메모리 구조

SYN Flood가 노리는 request_sock는 per-listener 해시 테이블에 저장됩니다. 각 request_sock는 약 256바이트를 차지하며, tcp_max_syn_backlog 개수만큼 할당될 수 있습니다. 공격 시 이 메모리와 해시 조회 비용이 동시에 증가합니다.

/* include/net/request_sock.h — request_sock 핵심 필드 */
struct request_sock {
    struct sock_common     __req_common;
    struct request_sock   *dl_next;
    u16                    mss;
    u8                     num_retrans;
    u8                     syncookie:1;   /* cookie 경로 여부 */
    u8                     num_timeout:7;
    u32                    ts_recent;
    struct timer_list      rsk_timer;     /* SYN+ACK 재전송 타이머 */
    const struct request_sock_ops *rsk_ops;
    struct sock           *sk;            /* 부모 listen socket */
    struct saved_syn      *saved_syn;
};

/* 공격 시 request_sock 해시 체인이 길어지면:
 * 1. 조회 시간 O(n) 증가
 * 2. SYN+ACK 재전송 타이머가 CPU를 소모
 * 3. 메모리 사용량 = max_syn_backlog × sizeof(request_sock) */

SYNPROXY 아키텍처와 conntrack 연동

SYNPROXY는 방화벽이 백엔드 대신 TCP 3-way handshake를 먼저 완료하는 방어 기법입니다. 커널의 nf_synproxy_core 모듈이 핵심이며, Netfilter의 UNTRACKED 상태와 conntrack을 정교하게 연동합니다. 백엔드 서버는 검증된 연결만 받으므로 SYN backlog와 request_sock가 완전히 보호됩니다.

# SYNPROXY 전체 설정 예시 (nftables)
# 1단계: 전제 조건 — tcp_loose 비활성화
sysctl -w net.netfilter.nf_conntrack_tcp_loose=0

# 2단계: raw 테이블에서 SYN을 NOTRACK 처리
nft add table ip raw
nft 'add chain ip raw prerouting { type filter hook prerouting priority raw; policy accept; }'
nft add rule ip raw prerouting tcp dport 80 tcp flags syn notrack

# 3단계: filter 테이블에서 SYNPROXY 적용
nft add table ip filter
nft 'add chain ip filter input { type filter hook input priority filter; policy accept; }'
nft add rule ip filter input ct state invalid,untracked \
    synproxy mss 1460 wscale 9 timestamp sack-perm
nft add rule ip filter input ct state invalid drop

# 4단계: 검증 확인
conntrack -L -p tcp --state SYN_SENT  # 백엔드 방향 SYN만 보여야 정상
nft list ruleset -a                    # counter 확인

rp_filter: Reverse Path Filtering으로 스푸핑 차단

rp_filter(Reverse Path Filter)는 수신 패킷의 소스 주소가 해당 인터페이스로 라우팅 가능한지 검증하여 IP 스푸핑을 차단합니다. RFC 3704의 BCP 38을 커널에서 구현한 것으로, strict 모드와 loose 모드의 동작 차이를 정확히 이해해야 비대칭 라우팅 환경에서 오탐을 피할 수 있습니다.

/* net/ipv4/fib_frontend.c — __fib_validate_source() 핵심 로직 */
static int __fib_validate_source(struct sk_buff *skb,
                                  __be32 src, __be32 dst,
                                  u8 tos, int oif,
                                  struct net_device *dev,
                                  int rpf, struct in_device *idev)
{
    struct fib_result res;
    int ret;

    /* src 주소로 FIB lookup 수행 */
    ret = fib_lookup(net, &fl4, &res, 0);
    if (ret)
        goto last_resort;  /* 경로 없음 → drop */

    /* strict mode: 수신 dev와 FIB 결과 dev 비교 */
    if (rpf == 1) {
        if (res.fi->fib_dev != dev)
            ret = -EXDEV;  /* 인터페이스 불일치 → drop */
    }
    /* loose mode: 경로 존재 여부만 확인 (dev 비교 안 함) */

    return ret;
}

rp_filter 실전 설정 예시

# 시나리오 1: 단일 업링크 서버 — strict 권장
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1

# 시나리오 2: BGP 멀티홈 — loose 사용
sysctl -w net.ipv4.conf.all.rp_filter=0     # all을 0으로 해야 개별 인터페이스 설정 가능
sysctl -w net.ipv4.conf.eth0.rp_filter=2    # 외부 인터페이스는 loose
sysctl -w net.ipv4.conf.eth1.rp_filter=2    # 두 번째 업링크도 loose
sysctl -w net.ipv4.conf.eth2.rp_filter=1    # 내부 인터페이스는 strict

# 시나리오 3: VRF 환경 — VRF master에서 설정
sysctl -w net.ipv4.conf.vrf-mgmt.rp_filter=1
sysctl -w net.ipv4.conf.vrf-prod.rp_filter=2

# 드롭 카운터 확인 (rp_filter에 의한 드롭)
nstat -az IpInAddrErrors  # rp_filter 드롭 시 증가

# 진단: 특정 소스가 rp_filter에 걸리는지 확인
ip route get 10.0.1.5 from 0.0.0.0 iif eth0  # FIB 경로 확인

TCP 보안 파라미터 하드닝

TCP 스택의 보안 관련 sysctl 파라미터는 개별적으로 보면 간단하지만, 조합에 따라 보안과 성능에 큰 차이가 납니다. 여기서는 tcp_syncookies, tcp_timestamps, tcp_rfc1337, tcp_tw_reuse 등의 상호작용을 정리합니다.

# TCP 보안 하드닝 권장 설정
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_rfc1337=1
sysctl -w net.ipv4.tcp_synack_retries=3
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=8192
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.tcp_max_tw_buckets=200000

# challenge ACK limit — CVE-2016-5696 대응
sysctl -w net.ipv4.tcp_challenge_ack_limit=999999999

# tcp_tw_reuse — timestamp와 함께 사용해야 안전
sysctl -w net.ipv4.tcp_tw_reuse=2  # loopback만 재사용 (기본값)

# 확인
sysctl -a | grep -E 'tcp_(syncookies|timestamps|rfc1337|synack_retries|max_syn|tw_reuse|challenge_ack|fin_timeout)'

Netfilter 보안 기능과 conntrack 상태 추적

Netfilter는 단순한 패킷 필터가 아니라 conntrack 상태 머신, ct helper(ALG), set/meter, flowtable 등 다양한 보안 기능을 제공합니다. 이 기능들을 보안 관점에서 올바르게 사용하려면 각 기능의 공격 표면과 성능 영향을 이해해야 합니다.

# ct helper 보안: 자동 할당 비활성화 (명시적 할당만 허용)
sysctl -w net.netfilter.nf_conntrack_helper=0

# 명시적 ct helper 할당 (nftables)
nft add ct helper inet filter ftp-helper '{ type "ftp" protocol tcp; }'
nft add rule inet filter input tcp dport 21 ct helper set ftp-helper

# INVALID 패킷 반드시 drop
nft add rule inet filter input ct state invalid drop
nft add rule inet filter forward ct state invalid drop

# 서비스별 ct timeout 분리
nft add ct timeout inet filter aggressive-timeout '{ protocol udp; l3proto ip; policy = { unreplied : 10, replied : 30 }; }'
nft add rule inet filter prerouting udp dport 53 ct timeout set aggressive-timeout

# INVALID 로그 활성화 (디버깅용)
sysctl -w net.netfilter.nf_conntrack_log_invalid=6  # TCP만

DDoS 완화 커널 경로: rate limiting, early drop, XDP 방어

DDoS 공격을 커널에서 완화하는 전략은 가능한 한 앞단에서, 가능한 한 적은 비용으로 드롭하는 것입니다. XDP → TC ingress → raw/prerouting → filter/input 순서로 방어 계층을 구성하면, 각 계층에서 걸러지지 않은 트래픽만 다음 계층으로 넘어갑니다.

/* XDP에서 SYN cookie를 직접 처리하는 패턴 (의사 코드) */
SEC("xdp")
int xdp_syn_cookie(struct xdp_md *ctx)
{
    struct ethhdr *eth;
    struct iphdr *iph;
    struct tcphdr *th;

    if (!parse_headers(ctx, &eth, &iph, &th))
        return XDP_PASS;

    /* SYN만 처리 (SYN+ACK, ACK는 통과) */
    if (!(th->syn && !th->ack))
        return XDP_PASS;

    /* per-source SYN rate 확인 */
    struct rate_info *ri = bpf_map_lookup_elem(&syn_rate, &iph->saddr);
    if (ri && ri->count > SYN_RATE_LIMIT)
        return XDP_DROP;

    /* XDP에서 SYN+ACK 생성 (bpf_xdp_adjust_head 사용) */
    /* cookie ISN 부호화: hash(saddr,daddr,sport,dport,secret) */
    generate_syn_ack_cookie(ctx, eth, iph, th);

    return XDP_TX;  /* SYN+ACK를 같은 인터페이스로 전송 */
}

XDP SYN cookie vs 커널 syncookie 비교

최근 커널(5.19+)에서는 XDP 레벨에서 직접 SYN cookie를 처리하는 기능이 추가되었습니다. 이는 기존 TCP 스택의 syncookie와 비교하여 sk_buff 생성 자체를 회피하므로 훨씬 높은 PPS를 처리할 수 있습니다.

DDoS 방어 계층별 비용 분석

각 방어 계층에서 패킷 하나를 처리하는 데 소요되는 CPU 사이클과 메모리 접근 횟수는 크게 다릅니다. 이 차이를 이해하면 방어 규칙의 최적 배치를 결정할 수 있습니다.

# nftables 동적 차단 리스트 (meter + set)
nft add table inet ddos
nft 'add chain inet ddos input { type filter hook input priority filter; policy accept; }'

# per-source SYN rate limit: 초당 100개 초과 시 drop
nft add rule inet ddos input tcp flags syn \
    meter syn_flood '{ ip saddr timeout 30s limit rate over 100/second }' drop

# 동적 차단 set: 과도한 소스를 자동으로 차단 리스트에 추가
nft add set inet ddos blocklist '{ type ipv4_addr; timeout 5m; }'
nft add rule inet ddos input ip saddr @blocklist drop
nft add rule inet ddos input tcp flags syn \
    meter syn_detect '{ ip saddr timeout 10s limit rate over 500/second }' \
    add @blocklist '{ ip saddr timeout 5m }'

# 확인
nft list set inet ddos blocklist
nft list meter inet ddos syn_flood

네트워크 네임스페이스와 컨테이너 네트워크 격리

네트워크 네임스페이스는 Linux 커널의 핵심 격리 메커니즘으로, 각 네임스페이스가 독립적인 네트워크 스택(인터페이스, 라우팅 테이블, iptables/nftables 규칙, conntrack 테이블, 소켓)을 가집니다. 컨테이너 환경에서는 이 격리가 보안의 기본이지만, veth pair를 통한 통신과 bridge 구성에서 보안 허점이 생길 수 있습니다.

# 컨테이너 네임스페이스 보안 설정 예시

# 1. 호스트에서 컨테이너 간 bridge 트래픽 제어
sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.bridge.bridge-nf-call-ip6tables=1

# 2. 컨테이너 NS 내부 하드닝
ip netns exec container1 sysctl -w net.ipv4.conf.all.rp_filter=1
ip netns exec container1 sysctl -w net.ipv4.conf.all.accept_redirects=0
ip netns exec container1 sysctl -w net.ipv4.conf.all.send_redirects=0
ip netns exec container1 sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

# 3. veth에 BPF 정책 적용 (TC ingress)
tc qdisc add dev veth-host-1 clsact
tc filter add dev veth-host-1 ingress bpf da obj container_policy.o sec classifier

# 4. 컨테이너별 conntrack 제한
ip netns exec container1 sysctl -w net.netfilter.nf_conntrack_max=65536

# 5. 네임스페이스 확인
ip netns list
ip netns exec container1 ip link show
ip netns exec container1 ss -lnt

컨테이너 탈출 방지와 네트워크 격리 강화

컨테이너 네트워크 격리는 네임스페이스만으로 완전하지 않습니다. capability 제한, seccomp 필터, AppArmor/SELinux 정책이 함께 적용되어야 네트워크 관련 syscall 남용을 막을 수 있습니다.

# Docker 컨테이너 네트워크 보안 실행 예시
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE \
    --security-opt no-new-privileges \
    --sysctl net.ipv4.conf.all.rp_filter=1 \
    --sysctl net.ipv4.conf.all.accept_redirects=0 \
    --sysctl net.ipv4.icmp_echo_ignore_broadcasts=1 \
    --network bridge \
    my-app:latest

# Kubernetes NetworkPolicy 예시 (YAML)
# apiVersion: networking.k8s.io/v1
# kind: NetworkPolicy
# spec:
#   podSelector: {matchLabels: {app: web}}
#   policyTypes: [Ingress, Egress]
#   ingress:
#   - from: [{podSelector: {matchLabels: {app: frontend}}}]
#     ports: [{protocol: TCP, port: 8080}]

소켓 보안: SO_BINDTODEVICE, SO_MARK, cgroup BPF

소켓 수준의 보안 옵션은 네트워크 정책을 프로세스와 연결 단위로 적용할 수 있게 합니다. SO_BINDTODEVICE로 특정 인터페이스에만 바인딩하고, SO_MARK로 패킷에 fwmark를 설정하여 nftables/라우팅 정책과 연동하며, cgroup BPF로 프로세스 그룹별 네트워크 접근을 제어합니다.

/* SO_BINDTODEVICE 사용 예시 */
int bind_to_device(int sockfd, const char *ifname)
{
    /* CAP_NET_RAW 권한 필요 */
    return setsockopt(sockfd, SOL_SOCKET, SO_BINDTODEVICE,
                      ifname, strlen(ifname) + 1);
}

/* SO_MARK 사용 예시 */
int set_fwmark(int sockfd, uint32_t mark)
{
    /* CAP_NET_ADMIN 권한 필요 */
    return setsockopt(sockfd, SOL_SOCKET, SO_MARK,
                      &mark, sizeof(mark));
}

/* cgroup BPF: 소켓 연결 제어 (의사 코드) */
SEC("cgroup/connect4")
int cg_connect4(struct bpf_sock_addr *ctx)
{
    /* 특정 IP 대역으로의 연결만 허용 */
    if ((ctx->user_ip4 & bpf_htonl(0xFFFF0000)) !=
        bpf_htonl(0x0A000000))  /* 10.0.0.0/16만 허용 */
        return 0;  /* 차단 */

    return 1;  /* 허용 */
}

cgroup BPF 네트워크 제어 상세

cgroup BPF는 프로세스 그룹 단위로 네트워크 접근을 제어하는 강력한 메커니즘입니다. BPF_CGROUP_INET_INGRESS, BPF_CGROUP_INET_EGRESS, BPF_CGROUP_INET4_CONNECT, BPF_CGROUP_INET4_BIND 등 다양한 attach point에서 BPF 프로그램을 실행할 수 있습니다.

# cgroup BPF 프로그램 attach 예시

# 1. cgroup 생성
mkdir -p /sys/fs/cgroup/net_restricted

# 2. BPF 프로그램 컴파일
clang -O2 -target bpf -c cgroup_net_policy.c -o cgroup_net_policy.o

# 3. BPF 프로그램 attach
bpftool cgroup attach /sys/fs/cgroup/net_restricted connect4 \
    pinned /sys/fs/bpf/cgroup_connect4

# 4. 프로세스를 해당 cgroup에 배치
echo $PID > /sys/fs/cgroup/net_restricted/cgroup.procs

# 5. 현재 attach된 BPF 프로그램 확인
bpftool cgroup show /sys/fs/cgroup/net_restricted

ftrace/bpftrace로 네트워크 보안 모니터링

네트워크 보안 이벤트를 실시간으로 추적하려면 커널의 tracing 인프라를 활용해야 합니다. ftrace의 kprobe/tracepoint와 bpftrace를 사용하면 conntrack 엔트리 생성/삭제, SYN backlog 상태, XDP 드롭, Netfilter 규칙 매칭 등을 프로덕션 환경에서도 안전하게 관찰할 수 있습니다.

# 1. ftrace: tcp_syn_flood_action 호출 추적
echo 1 > /sys/kernel/debug/tracing/events/tcp/tcp_bad_csum/enable
echo 'p:syn_flood tcp_syn_flood_action' > /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/syn_flood/enable
cat /sys/kernel/debug/tracing/trace_pipe

# 2. bpftrace: SYN 수신 rate 관측
bpftrace -e '
tracepoint:tcp:tcp_receive_reset {
    @rst[args->saddr] = count();
}
interval:s:5 { print(@rst); clear(@rst); }
'

# 3. bpftrace: conntrack 엔트리 생성 추적
bpftrace -e '
kprobe:__nf_conntrack_alloc {
    @ct_alloc = count();
}
kprobe:nf_conntrack_free {
    @ct_free = count();
}
interval:s:10 {
    printf("alloc: %d, free: %d\n", @ct_alloc, @ct_free);
    clear(@ct_alloc); clear(@ct_free);
}
'

# 4. bpftrace: XDP 드롭 카운터 추적
bpftrace -e '
tracepoint:xdp:xdp_bulk_tx {
    @xdp_act[args->action] = count();
}
interval:s:5 { print(@xdp_act); clear(@xdp_act); }
'

# 5. conntrack 이벤트 실시간 모니터링
conntrack -E -e NEW,DESTROY -p tcp --dport 80

# 6. bpftrace: nftables drop 원인 분석
bpftrace -e '
kprobe:nf_hook_slow {
    @hook[arg1] = count();
}
interval:s:10 { print(@hook); clear(@hook); }
'

# 7. perf: Netfilter/conntrack CPU 프로파일링
perf record -g -a -e cycles -- sleep 30
perf report --sort=dso,comm

네트워크 보안 종합 체크리스트

지금까지 다룬 커널 네트워크 보안 설정을 운영 환경에 적용할 때 빠짐없이 확인해야 할 체크리스트입니다. 서버 역할(웹 서버, 라우터/방화벽, 컨테이너 호스트)에 따라 강조되는 항목이 다릅니다.

# 네트워크 보안 종합 검증 스크립트
#!/bin/bash

echo "=== TCP 하드닝 ==="
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_timestamps \
       net.ipv4.tcp_rfc1337 net.ipv4.tcp_synack_retries \
       net.ipv4.tcp_fin_timeout net.ipv4.tcp_max_syn_backlog \
       net.core.somaxconn

echo "=== IP 스푸핑 방지 ==="
sysctl net.ipv4.conf.all.rp_filter \
       net.ipv4.conf.all.accept_redirects \
       net.ipv4.conf.all.send_redirects

echo "=== conntrack 상태 ==="
sysctl net.netfilter.nf_conntrack_max \
       net.netfilter.nf_conntrack_helper \
       net.netfilter.nf_conntrack_tcp_loose
cat /proc/sys/net/netfilter/nf_conntrack_count

echo "=== ICMP 보호 ==="
sysctl net.ipv4.icmp_echo_ignore_broadcasts \
       net.ipv4.icmp_ratelimit \
       net.ipv4.icmp_ignore_bogus_error_responses

echo "=== TCP backlog 관측 ==="
nstat -az TcpExtSyncookiesSent TcpExtListenOverflows \
          TcpExtListenDrops TcpExtTCPReqQFullDoCookies

echo "=== NIC 드롭 ==="
for iface in $(ls /sys/class/net/ | grep -v lo); do
    echo "--- $iface ---"
    ethtool -S $iface 2>/dev/null | grep -E 'rx_dropped|rx_errors|rx_missed'
done

echo "=== listener 상태 ==="
ss -lnt

sysctl 영속화 템플릿

# /etc/sysctl.d/99-network-security.conf
# 네트워크 보안 하드닝 — 서버 프로파일

# === TCP 하드닝 ===
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 200000
net.ipv4.tcp_challenge_ack_limit = 999999999

# === IP 스푸핑 방지 ===
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.log_martians = 1

# === ICMP 보호 ===
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_ratelimit = 1000

# === conntrack ===
net.netfilter.nf_conntrack_helper = 0
net.netfilter.nf_conntrack_tcp_loose = 0

# === IPv6 ===
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_ra = 0

관련 문서

• BPF/eBPF/XDP — XDP_DROP, redirect, AF_XDP와 조기 차단
• eBPF 기반 보안 정책 — BPF 방화벽과 identity 기반 정책
• Netfilter — nftables, conntrack, hook 우선순위
• conntrack 헬퍼 — timeout, helper, ctnetlink 운영
• TCP 프로토콜 심화 — tcp_sock, 상태 머신, backlog 관련 내부 구조
• NAPI — poll budget, softirq, RX 경로 계측
• Network Device 드라이버 — RSS, NAPI, RX/TX 링, XDP
• 네트워크 스택 — 전체 수신/송신 경로 복습
• 커널 보안 — 전체 시스템 보안 맥락
• IPSec & xfrm — 암호화 터널과 방화벽 경계
• WireGuard — 현대 VPN

참고자료

• Linux Kernel Documentation: IP Sysctl — tcp_syncookies, tcp_max_syn_backlog, somaxconn, icmp_*, rp_filter, arp_filter
• Linux Kernel Documentation: Netfilter Conntrack Sysctl — nf_conntrack_max, nf_conntrack_count, timeout, fragment 메모리 제한
• Linux Kernel Documentation: Scaling in the Linux Networking Stack — RSS, RPS, RFS, XPS, Flow Limit
• Linux Kernel Documentation: XDP Redirect — XDP_REDIRECT, xdp_do_redirect(), xdp_do_flush(), tracepoint
• nftables Manpage — synproxy, notrack, limit, meter 문법
• RFC 4987 — TCP SYN flooding attack와 countermeasure 분석
• RFC 3704 — ingress filtering과 strict/loose reverse path forwarding
• Linux man-pages: tcp(7) — TCP_DEFER_ACCEPT, TCP socket 옵션