NGFW 하드웨어 오프로드

차세대 방화벽(NGFW) 하드웨어 오프로드 아키텍처, Fast/Slow/Exception 경로, Stateful 방화벽·NAT·ACL·QoS·터널·IPSec 오프로드, 상용 NGFW 비교, Linux 커널 기반 NGFW 파이프라인, 세션 오프로드 결정 트리 종합 가이드

초보자 가이드

공항 보안에 비유한 NGFW 오프로드

NGFW 하드웨어 오프로드는 공항 보안 검색에 비유할 수 있습니다:

• 첫 방문 승객 (첫 패킷) — 신분증 확인, 수하물 X-ray, 금속 탐지기를 모두 거칩니다 (Slow Path = 전체 Netfilter + DPI 검사)
• TSA PreCheck 승객 (확립된 세션) — 이미 검증되었으므로 간소화된 경로로 빠르게 통과합니다 (Fast Path = flowtable/eSwitch HW 오프로드)
• 수상한 행동 감지 (Exception Path) — 이미 검증된 승객이라도 이상 행동 시 다시 전체 검사를 받습니다 (TCP RST, 프로토콜 변경, ALG)

NGFW의 핵심 과제는 보안 수준을 유지하면서 첫 패킷 검사가 끝난 세션을 얼마나 빠르게 처리할 수 있는가입니다. 하드웨어 오프로드는 이 "PreCheck 경로"를 NIC/SmartNIC 칩에서 직접 처리하여 CPU 부하를 극적으로 줄입니다.

단계별 이해

선수 지식 수준 가이드

핵심 용어 정리

NGFW HW 오프로드 개요

NGFW의 정의

차세대 방화벽(Next-Generation Firewall, NGFW)은 전통적인 L3/L4 패킷 필터링 방화벽에 다음 기능을 통합한 보안 장비입니다:

• Deep Packet Inspection (DPI) — L7 애플리케이션 프로토콜 분석
• Application Identification (App-ID) — 포트 번호가 아닌 실제 애플리케이션 식별
• Intrusion Prevention System (IPS) — 시그니처 기반 공격 탐지/차단
• SSL/TLS Inspection — 암호화된 트래픽 복호화 후 검사
• Stateful Session Tracking — conntrack 기반 연결 상태 추적
• URL Filtering / Threat Intelligence — 평판 기반 차단

이러한 기능은 패킷당 처리 비용을 크게 증가시키므로, 하드웨어 오프로드를 통해 검증이 완료된 세션의 후속 패킷을 CPU를 거치지 않고 직접 전달하는 것이 성능의 핵심입니다.

NGFW 세대별 진화

5세대의 핵심 차이점은 프로그래머블 오프로드입니다. 기존 ASIC은 벤더가 설계한 고정 파이프라인만 지원했지만, SmartNIC/DPU는 TC flower, eBPF, P4 등으로 오프로드 로직을 사용자가 정의할 수 있습니다.

NGFW 배치 모델

NGFW는 네트워크 내 위치와 동작 방식에 따라 여러 배치 모델이 있으며, 각 모델에서 HW offload의 적용 범위가 달라집니다:

전통 FW vs NGFW 비교

오프로드 필요성

NGFW에서 모든 패킷을 CPU에서 처리하면 다음과 같은 병목이 발생합니다:

• DPI 처리량: Suricata/Snort 단일 코어 처리량은 약 1~5 Gbps
• CPS (Connections Per Second): conntrack NEW + DPI 첫 분류까지 코어당 수만~수십만 CPS
• 메모리 대역폭: 패킷 데이터 + conntrack 테이블 + DPI 시그니처 DB 접근

100Gbps 이상 인터페이스에서 NGFW를 운영하려면, ESTABLISHED 세션의 후속 패킷을 하드웨어에서 처리하고 CPU는 NEW 세션과 예외 상황에만 집중해야 합니다.

트래픽 프로파일과 오프로드 효과

실제 네트워크 트래픽에서 세션의 특성을 분석하면 오프로드의 효과를 정량적으로 이해할 수 있습니다:

핵심 인사이트: 세션 수로는 단수명 세션이 압도적이지만, 실제 트래픽 볼륨(바이트)의 80%는 소수의 장수명 세션이 차지합니다. 이 장수명 세션을 HW offload하면 전체 CPU 부하의 대부분을 해소할 수 있습니다.

NGFW 핵심 성능 지표

NGFW 성능을 평가할 때 반드시 구분해야 하는 핵심 메트릭입니다. 벤더 데이터시트는 대부분 "방화벽 처리량"만 강조하지만, 실제 NGFW 성능은 모든 보안 기능을 활성화한 상태에서 측정해야 합니다:

데이터 플레인 아키텍처

Fast Path (HW + SW)

Fast Path는 이미 보안 검사가 완료된 세션의 후속 패킷을 최소 비용으로 전달하는 경로입니다. 두 가지 수준이 있습니다:

HW Fast Path (eSwitch FDB)

eSwitch의 switchdev 모드에서 TC flower 규칙으로 ct_state +est +trk 매칭 후 FDB(Forwarding Database) 룰을 NIC 하드웨어에 설치합니다. 패킷이 NIC에 도착하면 CPU를 거치지 않고 직접 전달됩니다.

HW Fast Path의 동작을 단계별로 보면:

1. 패킷 도착: 이더넷 프레임이 NIC의 RX 큐에 도달
2. eSwitch FDB lookup: NIC 내장 하드웨어가 5-tuple + ct_state로 FDB 테이블을 검색
3. 매칭 시 HW 처리: NAT rewrite (IP/Port/Checksum), TTL 감소, 터널 encap/decap, VLAN push/pop
4. 직접 TX: 처리된 패킷이 대상 포트의 TX 큐로 직접 전달 (DMA to DMA, CPU interrupt 없음)

• 수행: L2/L3/L4 헤더 매칭, NAT rewrite (SNAT/DNAT), VLAN push/pop, 터널 encap/decap (VXLAN/GRE/Geneve), conntrack 상태 확인
• 미수행: DPI 재검사, TCP window 검증, 시퀀스 번호 추적, ALG 프로토콜 파싱, IP 단편화 처리
• 처리량: NIC 라인레이트 (25/50/100/200Gbps)

SW Fast Path (nf_flowtable)

nf_flowtable은 커널 소프트웨어에서 conntrack을 bypass하고 직접 L3 forwarding을 수행합니다. HW offload가 불가능한 경우(예: NIC 미지원, 복잡한 NAT, 특정 터널)의 폴백 경로입니다.

SW Fast Path는 커널의 Netfilter ingress 훅(priority -10)에서 동작하여, 일반 Netfilter 체인(PREROUTING → FORWARD → POSTROUTING)을 완전히 건너뜁니다. 이를 통해 nftables 규칙 평가, conntrack 상세 추적, NFQUEUE 전달 등의 오버헤드를 제거합니다.

• 수행: conntrack bypass, L3 forwarding, NAT rewrite, TTL 감소, 통계 카운터
• 미수행: Netfilter 훅 체인, DPI, TCP 상태 머신 상세 추적
• 처리량: 코어당 약 10~40Gbps (패킷 크기 의존)

Fast Path 전환의 커널 내부 흐름

패킷이 Fast Path로 처리되는 과정을 커널 코드 수준에서 살펴보면:

/* net/netfilter/nf_flow_table_ip.c */
/* flowtable ingress 훅에서 호출되는 핵심 함수 */
static unsigned int
nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb,
                        const struct nf_hook_state *state)
{
    struct flow_offload_tuple_rhash *tuplehash;
    struct nf_flowtable *flow_table = priv;
    struct flow_offload_tuple tuple = {};
    enum flow_offload_tuple_dir dir;
    struct flow_offload *flow;

    /* 1. skb에서 5-tuple 추출 */
    if (nf_flow_tuple_ip(skb, state->in, &tuple) < 0)
        return NF_ACCEPT;  /* 추출 실패 → Slow Path */

    /* 2. flowtable에서 lookup */
    tuplehash = flow_offload_lookup(flow_table, &tuple);
    if (!tuplehash)
        return NF_ACCEPT;  /* 미등록 플로우 → Slow Path */

    flow = container_of(tuplehash, struct flow_offload,
                        tuplehash[dir]);

    /* 3. TEARDOWN 상태면 Slow Path로 복귀 */
    if (flow_offload_stale_flow(flow))
        return NF_ACCEPT;

    /* 4. NAT rewrite 적용 */
    if (flow->flags & FLOW_OFFLOAD_SNAT)
        nf_flow_snat_ip(skb, thoff, ...);
    if (flow->flags & FLOW_OFFLOAD_DNAT)
        nf_flow_dnat_ip(skb, thoff, ...);

    /* 5. TTL 감소 + routing 적용 */
    ip_decrease_ttl(iph);
    skb_dst_set_noref(skb, &rt->dst);

    /* 6. 직접 전달 (Netfilter 훅 체인 건너뜀) */
    ip_output(state->net, state->sk, skb);
    return NF_STOLEN;  /* skb 소유권 가져감 → 훅 종료 */
}

flow_offload 구조체

/* include/net/netfilter/nf_flow_table.h */
struct flow_offload_tuple {
    union {
        struct in_addr   src_v4;   /* IPv4 소스 주소 */
        struct in6_addr  src_v6;   /* IPv6 소스 주소 */
    };
    union {
        struct in_addr   dst_v4;
        struct in6_addr  dst_v6;
    };
    struct {
        __be16  src;  /* 소스 포트 */
        __be16  dst;  /* 목적지 포트 */
    } port;
    u8      l3proto;    /* AF_INET / AF_INET6 */
    u8      l4proto;    /* IPPROTO_TCP / IPPROTO_UDP */
    struct dst_entry  *dst_cache; /* 라우팅 캐시 */
    int     iifidx;     /* ingress 인터페이스 인덱스 */
    int     oifidx;     /* egress 인터페이스 인덱스 */
};

struct flow_offload {
    struct flow_offload_tuple_rhash tuplehash[2]; /* [ORIGINAL] + [REPLY] */
    struct nf_conn  *ct;         /* 대응하는 conntrack 엔트리 */
    unsigned long    flags;      /* SNAT, DNAT, TEARDOWN 등 */
    u32              timeout;    /* GC 타임아웃 (jiffies) */
};

하나의 flow_offload는 양방향 플로우를 나타냅니다. tuplehash[0]은 ORIGINAL 방향, tuplehash[1]은 REPLY 방향의 5-tuple을 저장합니다. NAT가 적용된 경우 두 방향의 IP/포트가 다릅니다.

Slow Path (전체 검사)

새로운 연결의 첫 패킷(또는 아직 DPI 분류가 완료되지 않은 초기 패킷)은 전체 보안 파이프라인을 통과합니다. Slow Path는 NGFW의 보안 정밀도를 담당하며, 여기서의 결정이 세션의 나머지 수명 동안의 처리 방식을 결정합니다.

Slow Path에서의 패킷 처리 시간은 일반적으로 100us~5ms 범위입니다. DPI 엔진의 시그니처 수, 패킷 페이로드 크기, CPU 캐시 히트율에 따라 달라집니다.

처리 순서:

1. Ingress ACL — nftables/TC filter 기반 정적 규칙 (IP/Port/Protocol 매칭)
2. conntrack — 연결 추적 테이블에 NEW 엔트리 생성 또는 기존 상태 갱신
3. NAT — SNAT/DNAT/MASQUERADE 주소 변환
4. NFQUEUE — DPI 엔진으로 패킷 전달 (NFQUEUE & DPI 엔진 통합)
5. DPI / App-ID — 프로토콜 분류, 시그니처 매칭, 애플리케이션 식별
6. IPS — 시그니처 기반 공격 탐지
7. Verdict — ACCEPT/DROP/QUEUE 최종 판정

CPS 병목: Slow Path의 처리량은 주로 초당 새 연결(CPS)으로 측정됩니다. DPI 엔진에 따라 코어당 10K~100K CPS 범위이며, 이는 NGFW의 실질적 성능 한계를 결정합니다.

Slow Path 커널 호출 체인

/* Slow Path에서 새 패킷이 거치는 커널 함수 호출 순서 */

/* 1. PREROUTING: conntrack 입구 */
nf_conntrack_in()
  → resolve_normal_ct()
    → nf_conntrack_find_get()    /* 해시 테이블에서 기존 ct 검색 */
    → init_conntrack()            /* 미발견 시 NEW ct 생성 */
      → __nf_conntrack_alloc()   /* slab에서 nf_conn 할당 */
      → nf_ct_helper_find()      /* ALG 헬퍼 자동 할당 (SIP/FTP 등) */

/* 2. FORWARD: nftables 체인 평가 */
nft_do_chain()
  → nft_lookup_eval()            /* set/map 기반 ACL 매칭 */
  → nft_ct_eval()                /* ct state 조건 평가 */
  → nft_queue_eval()             /* NFQUEUE verdict → DPI 전달 */

/* 3. NFQUEUE: 유저스페이스 DPI 전달 */
nf_queue()
  → nf_queue_entry_get_refs()    /* 참조 카운터 증가 */
  → nfnetlink_queue_enqueue()    /* netlink 소켓으로 전달 */
  /* ... Suricata/nDPI가 패킷을 분석 ... */
  → nf_reinject()                /* verdict 반환 후 재주입 */

/* 4. POSTROUTING: NAT 적용 */
nf_nat_ipv4_out()
  → nf_nat_packet()
    → nf_nat_manip_pkt()         /* SNAT/DNAT 주소 변환 */

/* 5. 전송 */
ip_output()
  → ip_finish_output()
    → neigh_output()             /* L2 헤더 추가 후 NIC TX */

CPS 병목 분석

NGFW에서 Slow Path의 CPS가 전체 성능을 제한하는 원인을 세분화하면:

DPI가 전체 Slow Path 비용의 70~90%를 차지합니다. 따라서 DPI 완료 후 세션을 즉시 Fast Path로 전환하는 것이 핵심 최적화입니다.

Exception Path

이미 오프로드된 세션이라도 다음 경우에는 Fast Path에서 CPU로 복귀합니다:

• ALG 프로토콜 — FTP DATA, SIP RTP, H.323 등 동적 포트 할당이 필요한 프로토콜 (conntrack 헬퍼 & ALG)
• IP Fragment — 단편화된 패킷은 재조립 후 검사 필요
• ICMP Error — Destination Unreachable, TTL Exceeded 등 원래 세션의 상태 갱신 필요
• 정책 변경 재분류 — 관리자가 정책을 변경하면 기존 오프로드 플로우를 삭제하고 재평가
• TCP RST/FIN — 연결 종료 → flowtable GC → HW rule 삭제
• 바이트/패킷 임계치 — 보안 정책에 따라 주기적 샘플링을 위해 복귀

Exception Path 처리의 커널 내부

Exception Path의 핵심은 flow_offload_stale_flow() 검사와 HW trap 메커니즘입니다:

/* net/netfilter/nf_flow_table_core.c */
static bool flow_offload_stale_flow(struct flow_offload *flow)
{
    /* TEARDOWN 플래그: TCP FIN/RST 수신 시 설정 */
    if (flow->flags & FLOW_OFFLOAD_TEARDOWN)
        return true;

    /* DYING 플래그: GC에 의해 만료 대기 중 */
    if (flow->flags & FLOW_OFFLOAD_DYING)
        return true;

    /* conntrack이 삭제된 경우 */
    if (!nf_ct_is_confirmed(flow->ct))
        return true;

    return false;
}

/* GC 워커: 주기적으로 만료된 플로우 정리 */
static void nf_flow_offload_gc_step(struct nf_flowtable *flow_table)
{
    struct flow_offload_tuple_rhash *tuplehash;
    struct rhashtable_iter hti;

    rhashtable_walk_enter(&flow_table->rhashtable, &hti);
    rhashtable_walk_start(&hti);

    while ((tuplehash = rhashtable_walk_next(&hti))) {
        struct flow_offload *flow = ...;
        if (nf_flow_has_expired(flow) ||
            nf_ct_is_dying(flow->ct)) {
            /* HW rule 삭제 → 카운터 동기화 → ct 삭제 */
            flow_offload_teardown(flow);
            nf_flow_offload_del(flow_table, flow);
        }
    }
}

ALG 프로토콜의 Exception 처리

FTP, SIP, H.323 등 ALG(Application Level Gateway) 프로토콜은 제어 채널에서 동적으로 데이터 채널 포트를 협상합니다. 이 과정에서 conntrack helper가 페이로드를 파싱해야 하므로 오프로드가 불가능합니다.

세션 오프로드 생명주기

첫 패킷 처리

TCP SYN 또는 첫 UDP 패킷이 도착하면 다음 과정을 거칩니다:

1. conntrack NEW — nf_conntrack_in()에서 새 conntrack 엔트리 생성
2. 전체 Netfilter 훅 — PREROUTING → FORWARD → POSTROUTING 체인의 모든 규칙 평가
3. NFQUEUE 전달 — DPI 엔진(Suricata, nDPI 등)이 패킷을 수신하여 프로토콜 분석 시작
4. App-ID 분류 — 첫 패킷만으로 부족하면 DPI 엔진이 추가 패킷 요청 (보통 3~10패킷)
5. Verdict 반환 — DPI 엔진이 ACCEPT 또는 DROP verdict를 반환

이 단계에서 오프로드는 발생하지 않습니다. 모든 검사가 완료될 때까지 Slow Path에 머뭅니다.

첫 패킷 conntrack 처리 상세

/* net/netfilter/nf_conntrack_core.c - 새 연결 생성 */
static struct nf_conntrack_tuple_hash *
init_conntrack(struct net *net, struct nf_conn *tmpl,
               const struct nf_conntrack_tuple *tuple,
               struct sk_buff *skb)
{
    struct nf_conn *ct;

    /* conntrack_max 초과 시 early drop (LRU) */
    if (nf_conntrack_max &&
        atomic_read(&net->ct.count) >= nf_conntrack_max) {
        if (!early_drop(net, hash))
            return ERR_PTR(-ENOMEM);  /* DROP: 테이블 가득 참 */
    }

    /* nf_conn 구조체 할당 (slab 캐시) */
    ct = __nf_conntrack_alloc(net, zone, tuple, ...);

    /* L4 프로토콜별 초기 상태 설정 */
    /* TCP: SYN_SENT, UDP: UNREPLIED */
    l4proto->new(ct, skb, dataoff);

    /* ALG helper 자동 할당 (포트 기반) */
    if (net->ct.sysctl_auto_assign_helper)
        nf_ct_helper_find(ct, tuple);

    /* unconfirmed list에 추가 (아직 해시에 삽입하지 않음) */
    /* POSTROUTING에서 confirm되면 해시 테이블에 삽입 */
    nf_ct_add_to_unconfirmed_list(ct);

    return &ct->tuplehash[IP_CT_DIR_ORIGINAL];
}

DPI 엔진의 패킷 분류 과정

NFQUEUE를 통해 유저스페이스 DPI 엔진(Suricata/nDPI)에 전달된 패킷의 분류 과정입니다:

일반적으로 3~10개 패킷이면 App-ID 분류가 완료됩니다. TLS 1.3에서 Encrypted Client Hello(ECH)가 사용되면 SNI가 암호화되어 더 많은 패킷이 필요하거나, SSL 복호화 없이는 분류가 불가능합니다.

ESTABLISHED 전환

TCP 3-way handshake가 완료되면 conntrack 상태가 ESTABLISHED로 전환됩니다. 이 시점에서 오프로드 여부를 결정합니다.

오프로드 결정 기준 4가지:

1. DPI 분류 완료 — App-ID가 결정되고 ALLOW verdict가 나왔는가?
2. ALG 프로토콜 아닌가 — FTP/SIP/H.323 등 동적 포트 할당이 필요한 프로토콜은 오프로드 불가
3. IP 단편화 아닌가 — 단편화된 패킷 스트림은 오프로드 불가
4. HW 지원 여부 — NIC/SmartNIC이 해당 플로우의 오프로드를 지원하는가? (터널 타입, NAT 유형 등)

오프로드 등록 커널 코드

nftables에서 flow add @ft가 실행되면 내부적으로 다음이 호출됩니다:

/* net/netfilter/nft_flow_offload.c */
static void nft_flow_offload_eval(const struct nft_expr *expr,
                                   struct nft_regs *regs,
                                   const struct nft_pktinfo *pkt)
{
    struct nf_conn *ct;
    enum ip_conntrack_info ctinfo;

    ct = nf_ct_get(pkt->skb, &ctinfo);

    /* 오프로드 가능 조건 확인 */
    if (nf_ct_is_dying(ct))
        goto err;
    if (nf_ct_helper(ct))        /* ALG helper 있으면 불가 */
        goto err;

    /* flow_offload 구조체 생성 */
    struct flow_offload *flow = flow_offload_alloc(ct);

    /* 라우팅 캐시 설정 */
    flow_offload_route_init(flow, &route);

    /* flowtable 해시에 등록 */
    flow_offload_add(&ft->ft, flow);

    /* HW offload 플래그가 있으면 NIC에도 등록 */
    if (ft->ft.flags & NF_FLOWTABLE_HW_OFFLOAD)
        nf_flow_offload_hw_add(net, flow, ct);
        /* → TC flower ct 규칙 → NIC eSwitch FDB 삽입 */
}

nf_flow_offload_hw_add()는 내부적으로 TC flower API를 호출하여 eSwitch에 FDB 규칙을 삽입합니다. 이 과정은 워크큐에서 비동기적으로 수행되므로, HW 규칙 설치까지 수 밀리초의 지연이 발생할 수 있습니다. 이 사이에 도착하는 패킷은 SW flowtable에서 처리됩니다.

오프로드 결정 트리

오프로드 해제

오프로드된 세션은 다음 상황에서 해제됩니다:

1. TCP FIN/RST — 연결 종료 신호가 감지되면 flowtable에서 DYING 상태로 전환
2. GC 타이머 — nf_flow_offload_gc_step()이 주기적으로 만료된 엔트리 정리
3. HW rule 삭제 — nf_flow_offload_hw_del()이 eSwitch FDB 규칙을 제거
4. conntrack 삭제 — 관련 conntrack 엔트리도 정리하여 리소스 해제

/* flowtable 오프로드 해제 흐름 */
TCP FIN/RST 수신
  → flow_offload_teardown()       /* FLOW_OFFLOAD_TEARDOWN 플래그 설정 */
    → nf_flow_offload_gc_step()   /* GC 워크큐가 DYING 플로우 정리 */
      → nf_flow_table_offload_del() /* HW rule 삭제 (TC flower del) */
        → nf_ct_delete()          /* conntrack 엔트리 삭제 */

GC 메커니즘 상세

flowtable의 Garbage Collection은 두 가지 메커니즘으로 동작합니다:

HW 카운터 동기화: HW offload된 플로우가 삭제될 때, NIC에서 처리된 패킷/바이트 카운터를 SW 카운터에 동기화합니다. 이를 통해 conntrack -L이나 nft list counter에서 정확한 통계를 확인할 수 있습니다.

/* HW 카운터 동기화 (net/netfilter/nf_flow_table_offload.c) */
static void nf_flow_offload_stats(struct flow_offload *flow,
                                    struct flow_stats *stats)
{
    struct nf_conn_acct *acct = nf_conn_acct_find(flow->ct);

    /* HW에서 읽어온 패킷/바이트 카운터를 conntrack에 반영 */
    atomic64_add(stats[0].pkts, &acct->counter[IP_CT_DIR_ORIGINAL].packets);
    atomic64_add(stats[0].bytes, &acct->counter[IP_CT_DIR_ORIGINAL].bytes);
    atomic64_add(stats[1].pkts, &acct->counter[IP_CT_DIR_REPLY].packets);
    atomic64_add(stats[1].bytes, &acct->counter[IP_CT_DIR_REPLY].bytes);

    /* 타임스탬프 갱신 → GC 타임아웃 리셋 */
    flow->timeout = nf_flowtable_time_stamp + flow_offload_get_timeout(flow);
}

Stateful 방화벽 오프로드

ACL HW 오프로드

TC flower를 사용하여 ct_state 매칭과 함께 ACL 규칙을 eSwitch에 설치할 수 있습니다. 이를 통해 conntrack 상태 기반 방화벽 규칙이 하드웨어에서 직접 평가됩니다.

# eSwitch switchdev 모드에서 TC flower ct 규칙 예시
# 1. ct zone 설정 및 conntrack 추적 시작
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

# 2. ESTABLISHED+TRACKED 세션 → HW offload forward
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 \
  action mirred egress redirect dev eth1_rep0

# 3. NEW+TRACKED 세션 → CPU (Slow Path)
tc filter add dev eth0_rep0 ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass # CPU로 전달하여 전체 검사

# 4. INVALID → DROP
tc filter add dev eth0_rep0 ingress prio 4 \
  protocol ip flower \
  ct_state +trk+inv \
  action drop

conntrack HW 오프로드

NF_FLOWTABLE_HW_OFFLOAD 플래그가 활성화되면, flowtable에 등록된 플로우가 NIC 하드웨어의 conntrack 테이블에도 설치됩니다.

# flowtable HW offload 활성화
nft add flowtable inet filter ft \
  { hook ingress priority 0\; devices = { eth0, eth1 }\; \
    flags offload\; }

# forward chain에서 established 세션을 flowtable으로 등록
nft add rule inet filter forward \
  ct state established \
  flow add @ft

# 오프로드 상태 실시간 확인
conntrack -L --status OFFLOAD
# 출력 예:
# tcp  6 300 ESTABLISHED src=10.0.0.1 dst=192.168.1.1
#   sport=45678 dport=443 [OFFLOAD] mark=0 use=2

HW offload 내부 메커니즘

flowtable HW offload는 다음 과정으로 NIC에 규칙을 설치합니다:

/* HW offload 규칙 설치 흐름 */
nf_flow_offload_hw_add()
  → nf_flow_offload_tuple()
    → flow_offload_mangle()      /* NAT rewrite 액션 구성 */
    → flow_action_entry_set()    /* TC flow_action 구조체 채움 */
  → nf_flow_table_offload_add()
    → flow_block_cb()            /* NIC 드라이버 콜백 호출 */
      → mlx5e_tc_offload_fdb_rules()  /* mlx5: FDB rule 삽입 */
      → ice_tc_flower_action()         /* ice: TC flower 규칙 */

NIC 드라이버는 FLOW_BLOCK_BIND/FLOW_BLOCK_UNBIND 이벤트를 통해 flowtable과 연결됩니다. 드라이버가 지원하지 않는 플로우 타입(예: 특수 NAT, 미지원 터널)에 대해서는 -EOPNOTSUPP를 반환하고, 이 경우 SW flowtable에서만 처리됩니다.

HW conntrack의 한계:

• TCP window 검증 — HW에서는 TCP 윈도우/시퀀스 번호의 유효성을 검증하지 않습니다. 이를 악용한 공격(out-of-window injection)에 대해서는 주기적 샘플링으로 대응합니다.
• conntrack 테이블 크기 — NIC HW의 flow table 크기가 제한적 (수만~수십만 엔트리). 초과 시 SW flowtable로 폴백합니다.
• NAT 변환 복잡도 — CGNAT(Many-to-one NAT)이나 복잡한 NAT 매핑은 HW에서 지원하지 않을 수 있습니다.
• 프로토콜 제한 — TCP와 UDP만 HW offload 가능. ICMP, GRE, SCTP 등은 SW 처리
• IPv6 지원 — NIC에 따라 IPv6 CT offload 미지원 가능. 지원 여부는 ethtool -k에서 확인

conntrack HW offload 호환성 매트릭스

NAT 오프로드

SNAT/DNAT 주소 변환은 flowtable과 eSwitch 모두에서 오프로드할 수 있습니다. (NAT 아키텍처 참고)

NAT 오프로드의 커널 구현

flowtable NAT offload는 conntrack의 NAT 정보를 flow_offload 구조체에 복사하여, 이후 패킷을 conntrack 없이 직접 변환합니다:

/* net/netfilter/nf_flow_table_ip.c - NAT 오프로드 적용 */
static int nf_flow_nat_ip(const struct flow_offload *flow,
                           struct sk_buff *skb,
                           unsigned int thoff,
                           enum flow_offload_tuple_dir dir)
{
    struct iphdr *iph = ip_hdr(skb);

    /* SNAT: 소스 IP/포트 교체 */
    if (flow->flags & FLOW_OFFLOAD_SNAT) {
        /* ORIGINAL 방향: src → NAT 주소로 변경 */
        /* REPLY 방향: dst → 원래 주소로 복원 */
        nf_flow_snat_port(skb, thoff,
            flow->tuplehash[!dir].tuple.src_v4.s_addr,
            flow->tuplehash[!dir].tuple.port.src);
        /* IP 체크섬 + L4 체크섬 재계산 */
        csum_replace4(&iph->check, iph->saddr, new_addr);
    }

    /* DNAT: 목적지 IP/포트 교체 (위와 유사) */
    if (flow->flags & FLOW_OFFLOAD_DNAT)
        nf_flow_dnat_port(skb, thoff, ...);

    return 0;
}

CGNAT 대규모 NAT 시나리오

통신사(ISP) 환경의 CGNAT(Carrier-Grade NAT)에서는 수만 개의 내부 IP를 소수의 공인 IP로 변환합니다. 이 경우:

• 포트 풀 관리: 각 공인 IP당 ~64K 포트를 내부 IP에 분배. 포트 소진 시 새 연결 불가
• HW NAT의 한계: 일부 NIC은 한정된 NAT 매핑 테이블만 지원 (수만 엔트리). 초과 시 SW 폴백
• Deterministic NAT: 포트 범위를 사전 할당하여 로깅 부하 감소. nft add map으로 구현 가능

# CGNAT nftables 설정 예시
table ip cgnat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;

        # 내부 대역별 공인 IP 분배 (Deterministic NAT)
        ip saddr 100.64.0.0/24 snat to 203.0.113.1:1024-32767
        ip saddr 100.64.1.0/24 snat to 203.0.113.1:32768-65535
        ip saddr 100.64.2.0/24 snat to 203.0.113.2:1024-32767

        # 폴백: 나머지 → 공인 IP 풀에서 동적 할당
        ip saddr 100.64.0.0/10 snat to 203.0.113.1-203.0.113.10
    }
}

# CGNAT 세션도 flowtable 오프로드 적용
nft add rule ip cgnat forward \
  ct state established flow add @ft

QoS/터널/IPSec 오프로드

DSCP/QoS 오프로드

TC flower로 DSCP 필드를 매칭하고 QoS 큐에 매핑하는 규칙을 eSwitch에 설치할 수 있습니다.

# DSCP EF (46) → TC 큐 0 (높은 우선순위)
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ip_tos 0xb8/0xfc \
  action skbedit priority 0

# DSCP AF11 (10) → TC 큐 2 (낮은 우선순위)
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ip_tos 0x28/0xfc \
  action skbedit priority 2

DSCP/QoS 매핑 상세

NGFW에서 QoS는 보안 정책과 연계됩니다. DPI 결과(App-ID)에 따라 DSCP 값을 재마킹하고, HW QoS 큐에 매핑하는 패턴입니다:

# NGFW에서 DPI 결과 기반 DSCP 재마킹
# nftables에서 App-ID → DSCP 매핑 (DPI 엔진이 ct mark에 App-ID 기록)
table inet qos_mark {
    map app_dscp {
        type mark : verdict
        elements = {
            0x0001 : accept,    # VoIP → DSCP EF (DPI에서 이미 마킹)
            0x0002 : accept,    # Video → DSCP AF41
            0x0003 : accept,    # Web → DSCP AF11
        }
    }

    chain forward {
        type filter hook forward priority 50; policy accept;
        # DPI 엔진이 ct mark에 기록한 App-ID → DSCP 재마킹
        ct mark 0x0001 ip dscp set ef
        ct mark 0x0002 ip dscp set af41
        ct mark 0x0003 ip dscp set af11
    }
}

# HW QoS 큐 설정 (TC MQPRIO)
tc qdisc add dev eth0 root mqprio \
  num_tc 4 map 3 3 2 2 1 1 0 0 0 0 0 0 0 0 0 0 \
  queues 1@0 1@1 2@2 4@4 hw 1

터널 오프로드

NGFW에서 터널은 두 가지 역할을 합니다: 사이트 간 VPN과 오버레이 네트워크. eSwitch는 다음 터널 타입의 encap/decap을 하드웨어에서 수행합니다:

• VXLAN — L2 over UDP 캡슐화, 가장 널리 지원
• GRE — IP over IP 캡슐화 (GRE 프로토콜)
• Geneve — 유연한 TLV 옵션을 지원하는 현대적 터널

터널 + NGFW 오프로드 결합

터널 decap → 내부 패킷 DPI → 오프로드의 전체 흐름을 TC flower로 구성합니다:

# VXLAN 터널 디바이스 생성
ip link add vxlan0 type vxlan id 100 \
  local 10.0.0.1 dport 4789 nolearning external

# eSwitch에서 VXLAN decap + conntrack + forward 규칙
# chain 0: 외부 헤더로 VXLAN 매칭 → decap
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  enc_dst_ip 10.0.0.1 enc_dst_port 4789 enc_key_id 100 \
  action tunnel_key unset pipe \
  action goto chain 1

# chain 1: decap된 내부 패킷에 conntrack 적용
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state -trk \
  action ct zone 1 pipe \
  action goto chain 2

# chain 2: EST → HW forward, NEW → CPU
tc filter add dev eth0_rep0 ingress chain 2 prio 1 \
  protocol ip flower ct_state +trk+est \
  action ct zone 1 nat pipe \
  action mirred egress redirect dev eth1_rep0

tc filter add dev eth0_rep0 ingress chain 2 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass # CPU → nftables → NFQUEUE → DPI

IPSec 인라인 크립토 오프로드

IPSec & xfrm의 HW 오프로드를 NGFW 파이프라인에 통합하면, 암호화/복호화를 NIC에서 수행하고 평문 패킷만 DPI 엔진에 전달할 수 있습니다.

# IPSec crypto offload 활성화 (xfrm)
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  enc 'aes' 0x$(head -c 16 /dev/urandom | xxd -p) \
  offload dev eth0 dir out

IPSec 오프로드 모드 비교

NGFW와의 통합 포인트: IPSec 수신 시 NIC이 복호화를 수행하고, 평문(decrypted) 패킷이 커널에 전달됩니다. 이 평문 패킷에 대해 conntrack → flowtable → DPI 파이프라인이 정상 작동합니다. 송신 시에는 flowtable이 평문 패킷을 NIC에 전달하고, NIC이 ESP 캡슐화와 암호화를 인라인으로 수행합니다.

# IPSec + flowtable NGFW 조합 설정
# 1. xfrm SA에 crypto offload 설정
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir out

ip xfrm state add src 10.0.0.2 dst 10.0.0.1 \
  proto esp spi 0x1002 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir in

# 2. xfrm 정책
ip xfrm policy add src 10.1.0.0/24 dst 10.2.0.0/24 \
  dir out tmpl src 10.0.0.1 dst 10.0.0.2 \
  proto esp reqid 1 mode tunnel

# 3. flowtable에서 decrypted 패킷 오프로드
nft add flowtable inet ngfw ft_ipsec \
  { hook ingress priority 0\; devices = { eth0 }\; flags offload\; }

nft add rule inet ngfw forward \
  ct state established \
  ipsec in reqid 1 \
  flow add @ft_ipsec accept

# 확인: IPSec HW 오프로드 상태
ip xfrm state show | grep -A1 offload
ethtool -S eth0 | grep ipsec

NGFW에서 VXLAN 오버레이 + 보안 통합

데이터센터 NGFW에서 VXLAN 오버레이 네트워크와 보안 검사를 통합하는 아키텍처입니다. eSwitch가 VXLAN 터널의 encap/decap을 하드웨어에서 수행하고, 내부 패킷에 대해 conntrack + DPI를 적용합니다.

# VXLAN + NGFW 통합 구성 (eSwitch offload)

# 1. VXLAN 터널 엔드포인트 생성
ip link add vxlan100 type vxlan id 100 \
  local 10.0.0.1 dport 4789 nolearning external

# 2. nftables에서 decap된 내부 트래픽에 NGFW 정책 적용
table inet vxlan_ngfw {
    flowtable ft_vxlan {
        hook ingress priority 0
        devices = { vxlan100, eth1 }
        flags offload
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid drop

        # VXLAN 내부 트래픽: EST → offload
        iifname "vxlan100" ct state established,related \
            flow add @ft_vxlan accept

        # VXLAN 내부 트래픽: NEW → DPI
        iifname "vxlan100" ct state new \
            queue num 0-3 fanout

        # 내부 → VXLAN: EST → offload
        oifname "vxlan100" ct state established,related \
            flow add @ft_vxlan accept
    }
}

# 3. eSwitch에서 VXLAN + conntrack 통합 규칙
# 외부 헤더로 VXLAN 패킷 식별 → decap → conntrack → forward
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  enc_dst_ip 10.0.0.1 enc_dst_port 4789 enc_key_id 100 \
  action tunnel_key unset pipe \
  action ct zone 2 pipe \
  action goto chain 1

# chain 1에서 EST/NEW 분기 (위 §8 패턴과 동일)
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state +trk+est \
  action ct zone 2 nat pipe \
  action mirred egress redirect dev eth1_rep0

tc filter add dev eth0_rep0 ingress chain 1 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass

상용 NGFW HW 아키텍처

Fortinet NP7 / SP5

Fortinet FortiGate는 자체 ASIC 칩을 사용하여 데이터 플레인을 가속합니다:

• NP7 (Network Processor) — 200Gbps L4 처리, HW session offload, IPSec/VXLAN/GRE 인라인 처리. Session table에 ESTABLISHED 세션을 등록하면 이후 패킷이 NP7에서 직접 전달됩니다.
• SP5 (Security Processor) — SSL/TLS 가속, IPS 시그니처 매칭 보조. CPU에서 DPI를 수행하되 SP5가 암호화/복호화를 전담합니다.
• CP9 (Content Processor) — AV/IPS/DLP 패턴 매칭 가속.

NP7 세션 오프로드 프로세스

FortiGate에서 세션이 NP7으로 오프로드되는 과정:

1. 첫 패킷: CPU(IPS Engine)가 수신 → conntrack + UTM(IPS/AV/App Control) 전체 검사
2. 세션 수립: 검사 통과 시 CPU가 ISF(Iterate Session Filter)에 오프로드 결정 쿼리
3. NP7 등록: session_offload_add() → NP7 Session Table에 5-tuple + NAT 정보 + QoS 태그 기록
4. 후속 패킷: NP7 ASIC이 Session Table lookup → NAT rewrite → QoS → forwarding (CPU bypass)
5. 세션 종료: TCP FIN/RST → NP7이 CPU에 알림 → Session Table 삭제 → 통계 동기화

# FortiGate 진단 명령
diagnose npu np7 session-stats         # NP7 오프로드 세션 통계
diagnose npu np7 sse-stats all         # Session Search Engine 통계
diagnose npu np7 port-list             # NP7 포트 매핑 확인
diagnose sys session filter dport 443  # 특정 포트 세션 확인
get system performance firewall statistics # 전체 성능 통계

# NP7 오프로드 비율 확인
diagnose npu np7 session-stats
# 출력 예:
# NP7 offload sessions: 1,234,567
# CPU sessions: 12,345
# Offload ratio: 99.0%

# 특정 세션의 오프로드 상태 확인
diagnose sys session filter src 10.0.0.1
diagnose sys session list
# 출력에서 npu_state=offloaded 확인

Palo Alto Networks FPGA

Palo Alto PA 시리즈는 FPGA 기반 SP3 (Security Processing) 아키텍처를 사용합니다:

• Single-Pass Parallel Processing — 패킷이 한 번의 통과로 FW, App-ID, IPS, URL 필터링을 병렬 처리
• NPC (Network Processing Card) — 고성능 모델에 추가 가능한 데이터 플레인 카드
• FE (Forwarding Engine) FPGA — 세션 테이블 lookup, NAT rewrite를 FPGA에서 처리
• CPU 코어에서 App-ID/DPI를 처리하되, FPGA가 세션 설정과 패킷 전달을 가속

Single-Pass 아키텍처 상세

Palo Alto의 핵심 차별점은 Single-Pass Parallel Processing (SP3) 아키텍처입니다:

FE FPGA의 역할: FPGA는 패킷 분류(5-tuple lookup), 세션 테이블 검색, 디캡슐레이션, NAT rewrite를 수행합니다. CPU는 App-ID 엔진만 실행하므로, FPGA가 처리할 수 있는 세션(이미 분류된 ESTABLISHED)은 CPU를 완전히 bypass합니다.

# Palo Alto CLI 진단 명령
show running resource-monitor           # CPU/메모리/세션 사용률
show session all filter state active    # 활성 세션 목록
show session info                       # 세션 통계 (CPS, CC)
show counter global filter delta yes \
  packet-filter yes                     # 실시간 카운터
debug dataplane packet-diag set filter \
  match src 10.0.0.1                    # 특정 IP 패킷 추적

Check Point SecureXL / Maestro

Check Point는 소프트웨어 기반 가속 아키텍처를 사용합니다:

• SecureXL — 커널 레벨 가속. Accept Template(ESTABLISHED 세션 direct forward)과 Drop Template(미리 차단 목록)으로 CPU 부하를 줄입니다.
• CoreXL — 멀티코어 병렬 처리. SND(Secure Network Distributor)가 RSS처럼 코어 간 패킷을 분배합니다.
• Maestro HyperScale — 여러 Security Gateway를 하나의 논리 장비로 클러스터링하여 수평 확장

SecureXL 처리 경로 상세

SecureXL은 3가지 처리 경로(Accelerated Path, Medium Path, Firewall Path)로 패킷을 분류합니다:

Accept Template은 Linux conntrack의 ESTABLISHED + flowtable 개념과 유사합니다. conntrack이 세션 상태를 추적하고, Accept Template이 검사가 완료된 세션의 5-tuple을 커널 가속 테이블에 등록합니다. Drop Template은 이미 DROP 판정이 난 소스 IP/포트를 캐시하여, 동일한 악성 트래픽이 재전송될 때 CPU까지 가지 않고 즉시 DROP합니다.

CoreXL / SND 아키텍처

Check Point의 멀티코어 아키텍처는 Linux의 RSS/RPS와 유사하지만 보안에 최적화되어 있습니다:

• SND (Secure Network Distributor) — 전용 코어가 NIC에서 패킷을 수신하여 CoreXL 인스턴스에 분배. CPU affinity 기반으로 세션을 고정 코어에 할당
• CoreXL FW Instance — 각 코어가 독립적인 FW 인스턴스를 실행. 세션 테이블은 공유하되, 처리는 병렬
• Multi-Queue — SND가 NIC의 RSS 큐를 활용하여 하드웨어 수준 분산

# Check Point 진단 명령 (Gaia OS)
fwaccel stat                            # SecureXL 가속 통계
fwaccel stats -s                        # 경로별 패킷/바이트 통계
fwaccel conns                           # Accept Template 연결 수
fw ctl multik stat                      # CoreXL 인스턴스별 통계
cpview                                  # 실시간 성능 모니터 (TUI)

# SecureXL 비활성화/활성화 (성능 비교 테스트)
fwaccel off     # 가속 비활성화 → 전체 Firewall Path
fwaccel on      # 가속 재활성화

# 특정 세션의 처리 경로 확인
fw ctl zdebug + drop    # 디버그 로그

Juniper Express Path

Juniper SRX 시리즈의 Express Path는 세션의 첫 패킷만 flow daemon이 처리하고, 이후 패킷은 NPU(Network Processing Unit)에서 직접 전달합니다:

• Express Path — 확립된 세션의 패킷을 flowd를 bypass하여 NP에서 forwarding
• Services Offload Engine — IPSec, NAT를 전용 엔진에서 처리

Express Path 동작 원리

Juniper SRX의 패킷 처리 아키텍처:

1. NP (Network Processor): 모든 패킷의 1차 수신. 세션 테이블에서 lookup
2. Express Path 히트: 기존 세션 매칭 → NP에서 직접 forwarding + NAT rewrite (flowd bypass)
3. Express Path 미스: 새 세션 → flowd(flow daemon)로 전달 → 정책 평가 + IPS/AppID
4. 세션 설치: flowd가 정책 통과 시 세션을 NP Express Path 테이블에 등록

# Juniper SRX 진단 명령
show security flow statistics           # 플로우 통계 (Express Path 비율)
show security monitoring fpc 0          # FPC별 세션/처리량
show security flow session              # 세션 테이블
show security flow session summary      # 세션 요약 (활성/최대)

# Express Path 상태 확인
show pfe statistics traffic
# express-path-packets, slow-path-packets 비교

# Services Offload Engine 상태
show chassis fpc pic-status

Linux 커널 기반 NGFW

Linux 커널과 오픈소스 도구를 조합하여 NGFW를 구축하는 접근법입니다:

• nftables + NFQUEUE + Suricata — 커널 네이티브 방화벽 + 유저스페이스 DPI
• nf_flowtable + SmartNIC — HW offload 가속
• VPP 기반 대안 — FD.io VPP의 유저스페이스 데이터 플레인으로 Netfilter 대신 패킷 처리

Linux NGFW 스택 구성

Linux 커널 기반 NGFW를 상용 수준으로 구축하기 위한 전체 스택:

VPP 기반 NGFW 데이터 플레인

FD.io VPP를 사용하면 커널 Netfilter 대신 유저스페이스에서 패킷 처리하여 더 높은 성능을 달성합니다:

• 장점: 벡터 패킷 처리(batch), DPDK 기반 NIC 접근, 커널 overhead 제거 → 단일 코어 40Gbps+
• 단점: 커널 네트워크 스택(conntrack, nftables, flowtable)을 사용할 수 없음. VPP 자체 ACL/NAT 플러그인 사용
• 하이브리드 접근: VPP가 Fast Path를 처리하고, 새 세션만 TAP 인터페이스를 통해 커널/Suricata로 전달

# VPP 기반 NGFW 설정 예시
# /etc/vpp/startup.conf
dpdk {
  dev 0000:03:00.0 { name eth0 }
  dev 0000:03:00.1 { name eth1 }
}

# VPP CLI에서 ACL + session 설정
vppctl acl-plugin acl add permit+reflect \
  src 10.0.0.0/8 dst 0.0.0.0/0 proto tcp
vppctl set acl-plugin interface eth0 input acl 0

# 새 세션만 TAP으로 전달 (DPI)
vppctl create tap id 0
vppctl set interface state tap0 up

상용 vs Linux NGFW 선택 기준

성능 비교 벤치마크 (참고 수치)

다음은 공개된 데이터시트와 독립 벤치마크(NSS Labs, RFC 9411 기반)에서 추출한 참고 수치입니다. 실제 환경에서는 정책 복잡도, 트래픽 믹스, DPI 시그니처 수에 따라 크게 달라집니다:

Linux NGFW의 NGFW 처리량은 Suricata DPI에 의해 제한되지만, FW 처리량(L4 stateful)에서는 SmartNIC HW offload로 상용 제품에 필적하는 성능을 달성합니다. 핵심은 오프로드 비율을 높여 DPI 부하를 최소화하는 것입니다.

커널 NGFW 빌딩 블록

Linux 커널에서 NGFW를 구축할 때 사용하는 주요 서브시스템과 NGFW 기능 간의 매핑입니다. 각 서브시스템은 독립적으로 발전해 왔지만, NGFW에서는 이들을 하나의 통합 파이프라인으로 결합해야 합니다. 이 절에서는 각 서브시스템의 역할과 연동 포인트를 정리합니다.

드라이버 오프로드 계약 (ndo_setup_tc)

NIC 드라이버가 TC flower offload를 지원하기 위해 구현해야 하는 인터페이스입니다. NGFW 파이프라인의 HW offload는 이 계약에 의존합니다. (Network Device 드라이버 참고)

/* include/linux/netdevice.h */
struct net_device_ops {
    /* TC flower offload 진입점 */
    int (*ndo_setup_tc)(struct net_device *dev,
                        enum tc_setup_type type,
                        void *type_data);
};

/* 드라이버가 처리해야 하는 TC 타입 */
enum tc_setup_type {
    TC_SETUP_QDISC_MQPRIO,   /* MQPRIO QoS 큐 설정 */
    TC_SETUP_CLSFLOWER,       /* TC flower 분류기 규칙 */
    TC_SETUP_FT,              /* flowtable offload */
    TC_SETUP_BLOCK,           /* 블록 바인딩 (CT offload) */
};

/* CLSFLOWER 콜백에서 처리하는 명령 */
enum tc_fl_command {
    TC_CLSFLOWER_REPLACE,    /* 규칙 추가/교체 */
    TC_CLSFLOWER_DESTROY,    /* 규칙 삭제 */
    TC_CLSFLOWER_STATS,      /* HW 카운터 읽기 */
};

nf_flowtable 내부 구조

/* include/net/netfilter/nf_flow_table.h */
struct nf_flowtable {
    struct list_head   list;        /* flowtable 전역 리스트 */
    struct rhashtable  rhashtable;  /* 5-tuple 해시 테이블 */
    int                priority;    /* Netfilter 훅 우선순위 */
    unsigned int       flags;       /* NF_FLOWTABLE_HW_OFFLOAD 등 */
    struct nf_flowtable_type *type;
    struct delayed_work gc_work;    /* GC 워크큐 */
    struct flow_block  flow_block;  /* HW offload 블록 */
    struct mutex       flow_block_lock;
    possible_net_t     net;
};

/* rhashtable 파라미터: 자동 크기 조절 */
static const struct rhashtable_params nf_flow_offload_rhash_params = {
    .head_offset     = offsetof(struct flow_offload_tuple_rhash, node),
    .key_offset      = offsetof(struct flow_offload_tuple_rhash, tuple),
    .key_len         = sizeof(struct flow_offload_tuple),
    .automatic_shrinking = true,  /* 엔트리 감소 시 자동 축소 */
};

flowtable은 rhashtable(Resizable Hash Table)을 사용합니다. 엔트리 수에 따라 버킷이 자동으로 확장/축소되며, RCU 기반 읽기로 lock-free lookup을 보장합니다. 이는 NGFW에서 높은 CPS 환경에서도 Fast Path lookup의 일관된 성능을 유지하는 핵심입니다.

핵심 커널 API 흐름

/* NGFW 파이프라인의 커널 API 호출 흐름 (개념도) */

/* 1. 패킷 수신 → Netfilter PREROUTING 훅 */
nf_hook(NFPROTO_IPV4, NF_INET_PRE_ROUTING, skb);

/* 2. conntrack: 세션 추적 */
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (ctinfo == IP_CT_NEW) {
    /* 새 세션 → Slow Path: 전체 규칙 평가 */
    nft_do_chain(chain, skb);  /* nftables 규칙 평가 */
    nf_queue(skb, queue_num);  /* NFQUEUE → DPI 엔진 */
}

/* 3. flowtable: ESTABLISHED 세션 Fast Path */
if (ctinfo == IP_CT_ESTABLISHED) {
    struct flow_offload *flow = flow_offload_lookup(ft, skb);
    if (flow) {
        /* Fast Path: conntrack bypass → 직접 전달 */
        nf_flow_offload_ip_hook(skb);  /* NAT rewrite + forward */
        return NF_STOLEN;  /* Netfilter 훅 체인 종료 */
    }
}

/* 4. HW offload 등록 */
flow_offload_add(ft, flow);
if (ft->flags & NF_FLOWTABLE_HW_OFFLOAD)
    nf_flow_offload_hw_add(net, flow, ct);  /* eSwitch FDB rule 설치 */

NFQUEUE 연동 API

DPI 엔진이 NFQUEUE에서 패킷을 수신하고 verdict를 반환하는 과정의 유저스페이스 API입니다:

/* libnetfilter_queue를 사용한 DPI 엔진 기본 구조 */
#include <libnetfilter_queue/libnetfilter_queue.h>

static int nfq_callback(struct nfq_q_handle *qh,
                        struct nfgenmsg *nfmsg,
                        struct nfq_data *nfa,
                        void *data)
{
    struct nfqnl_msg_packet_hdr *ph;
    unsigned char *payload;
    int payload_len;
    uint32_t id;

    ph = nfq_get_msg_packet_hdr(nfa);
    id = ntohl(ph->packet_id);
    payload_len = nfq_get_payload(nfa, &payload);

    /* DPI 분석 수행 */
    int verdict = analyze_packet(payload, payload_len);

    /* verdict 반환: NF_ACCEPT 또는 NF_DROP */
    if (verdict == DPI_ALLOW)
        return nfq_set_verdict(qh, id, NF_ACCEPT, 0, NULL);
    else
        return nfq_set_verdict(qh, id, NF_DROP, 0, NULL);
}

/* 메인 루프: NFQUEUE 수신 + DPI 콜백 */
int main(void)
{
    struct nfq_handle *h = nfq_open();
    struct nfq_q_handle *qh = nfq_create_queue(h, 0,
                                                 &nfq_callback, NULL);

    /* 배치 verdict 활성화 (성능 향상) */
    nfq_set_queue_flags(qh, NFQA_CFG_F_GSO, NFQA_CFG_F_GSO);

    /* 소켓에서 패킷 수신 루프 */
    int fd = nfq_fd(h);
    char buf[65536];
    int rv;
    while ((rv = recv(fd, buf, sizeof(buf), 0)) > 0)
        nfq_handle_packet(h, buf, rv);

    return 0;
}

오프로드 구현 패턴

Suricata NFQUEUE 통합 설정

Suricata를 NGFW의 DPI/IPS 엔진으로 사용할 때의 최적화된 설정입니다:

# /etc/suricata/suricata.yaml (NGFW 최적화)

# NFQUEUE 모드 설정
nfq:
  mode: repeat          # verdict 후 재주입 (NFQUEUE → nftables 계속)
  repeat-mark: 1        # 재주입된 패킷 마킹 (중복 큐잉 방지)
  repeat-mask: 1
  bypass: yes           # Suricata 과부하 시 패킷 bypass (가용성 우선)
  fail-open: yes        # Suricata 장애 시 패킷 통과 (HA 환경)
  batchcount: 20        # 배치 verdict (성능 향상)

# 멀티 스레드 설정 (CPU 코어 4~16개 환경)
threading:
  set-cpu-affinity: yes
  cpu-affinity:
    - management-cpu-set:
        cpu: [ 0 ]
    - receive-cpu-set:
        cpu: [ 1, 2, 3, 4 ]    # NFQUEUE 수신 스레드
    - worker-cpu-set:
        cpu: [ 5, 6, 7, 8, 9, 10, 11, 12 ]  # 분석 워커

# App-Layer 프로토콜 분석 (NGFW App-ID)
app-layer:
  protocols:
    tls:
      enabled: yes
      detection-ports:
        dp: 443, 8443
      ja3-fingerprints: yes   # JA3/JA3S 핑거프린트 (TLS 분류)
    http:
      enabled: yes
      server-body-limit: 1mb  # DLP를 위한 바디 검사 한계
    dns:
      enabled: yes
    smb:
      enabled: yes
    ssh:
      enabled: yes
      hassh: yes              # HASSH 핑거프린트

# 플로우 타임아웃 (flowtable과 동기화)
flow-timeouts:
  default:
    new: 30
    established: 300          # nf_flowtable_tcp_timeout과 일치
    closed: 10
    bypassed: 300             # bypass된 세션 (오프로드됨)
  tcp:
    new: 60
    established: 600
    closed: 60

# bypass 설정 (오프로드 연동)
stream:
  bypass: yes                 # 분류 완료 후 스트림 바이패스
  max-sessions: 1000000       # 최대 동시 세션

nftables NGFW 설정

완전한 nftables 규칙셋으로 NGFW 데이터 플레인을 구성하는 예시입니다. flowtable으로 ESTABLISHED 세션을 오프로드하고, NEW 세션은 NFQUEUE로 DPI 검사를 수행합니다.

#!/usr/sbin/nft -f
# NGFW nftables 규칙셋 (flowtable + NFQUEUE DPI)

table inet ngfw {
    # flowtable 정의 (HW offload 활성화)
    flowtable ft {
        hook ingress priority 0
        devices = { eth0, eth1 }
        flags offload  # NF_FLOWTABLE_HW_OFFLOAD
    }

    # forward chain: NGFW 핵심 파이프라인
    chain forward {
        type filter hook forward priority 0; policy drop;

        # 1. INVALID 패킷 즉시 DROP
        ct state invalid drop

        # 2. ESTABLISHED/RELATED → flowtable offload
        ct state established,related flow add @ft accept

        # 3. NEW 세션 → 기본 ACL 통과 후 NFQUEUE로 DPI
        ct state new ip protocol tcp \
            tcp dport { 80, 443, 8080, 8443 } \
            queue num 0-3 fanout  # 4개 DPI 워커로 분산

        ct state new ip protocol udp \
            udp dport { 53, 443 } \
            queue num 0-3 fanout

        # 4. 허용된 ICMP
        ct state new icmp type { echo-request, echo-reply } accept

        # 5. 나머지 NEW → DROP (기본 정책)
    }

    # input chain: 관리 인터페이스 보호
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iifname "lo" accept
        tcp dport 22 accept  # SSH 관리
    }
}

TC flower ACL 오프로드

eSwitch switchdev 모드에서 TC flower를 사용하여 ACL 규칙을 하드웨어에 직접 설치합니다. 이 방식은 nftables의 SW 경로와 병행하여, NEW 패킷은 CPU(nftables → NFQUEUE → DPI)에서 처리하고 ESTABLISHED 패킷은 eSwitch HW에서 직접 전달합니다.

# 1. eSwitch switchdev 모드 전환
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# 2. VF representor에서 hw-tc-offload 활성화
ethtool -K eth0_rep0 hw-tc-offload on

# 3. conntrack zone 설정 + 추적 시작
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

# 4. EST+TRK → NAT + forward (HW offload)
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 nat \
  action mirred egress redirect dev eth1_rep0

# 5. NEW+TRK → pass to CPU (Slow Path)
tc filter add dev eth0_rep0 ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass

# 6. 특정 IP 대역 차단 (HW에서 DROP)
tc filter add dev eth0_rep0 ingress prio 0 \
  protocol ip flower \
  src_ip 192.168.100.0/24 \
  action drop

DPI 오프로드 바이패스 패턴

DPI 엔진이 세션을 분류하면 이후 패킷은 NFQUEUE를 bypass해야 합니다. eBPF map을 활용한 캐시 패턴입니다:

eBPF DPI 결과 캐시 (완전한 구현)

/* dpi_cache.bpf.c — eBPF DPI 결과 캐시 프로그램 */
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/udp.h>

/* 5-tuple 플로우 키 */
struct flow_key {
    __be32 src_ip;
    __be32 dst_ip;
    __be16 src_port;
    __be16 dst_port;
    __u8   protocol;
    __u8   pad[3];
};

/* DPI 결과 값 */
struct dpi_result {
    __u32 verdict;      /* 0=ACCEPT, 1=DROP, 2=CONTINUE */
    __u32 app_id;       /* 애플리케이션 ID (DPI 엔진이 설정) */
    __u64 timestamp;    /* 마지막 갱신 (nsec) */
    __u64 bytes;        /* 바이트 카운터 (샘플링용) */
};

/* LRU 해시 맵: 자동으로 가장 오래된 엔트리 퇴출 */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 500000);
    __type(key, struct flow_key);
    __type(value, struct dpi_result);
} dpi_cache SEC(".maps");

/* 통계 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 4);
    __type(key, __u32);
    __type(value, __u64);
} stats SEC(".maps");
/* stats[0]=cache_hit, stats[1]=cache_miss,
   stats[2]=bypass_accept, stats[3]=bypass_drop */

static __always_inline int
extract_flow_key(struct __sk_buff *skb, struct flow_key *key)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct iphdr *iph = data + sizeof(struct ethhdr);

    if ((void *)(iph + 1) > data_end)
        return -1;

    key->src_ip = iph->saddr;
    key->dst_ip = iph->daddr;
    key->protocol = iph->protocol;

    if (iph->protocol == IPPROTO_TCP) {
        struct tcphdr *tcph = (void *)iph + (iph->ihl * 4);
        if ((void *)(tcph + 1) > data_end) return -1;
        key->src_port = tcph->source;
        key->dst_port = tcph->dest;
    } else if (iph->protocol == IPPROTO_UDP) {
        struct udphdr *udph = (void *)iph + (iph->ihl * 4);
        if ((void *)(udph + 1) > data_end) return -1;
        key->src_port = udph->source;
        key->dst_port = udph->dest;
    }
    return 0;
}

SEC("netfilter")
int dpi_bypass(struct bpf_nf_ctx *ctx)
{
    struct flow_key key = {};
    __u32 idx;
    __u64 *counter;

    if (extract_flow_key(ctx->skb, &key) < 0)
        return NF_ACCEPT;

    struct dpi_result *result = bpf_map_lookup_elem(&dpi_cache, &key);
    if (result) {
        /* 캐시 히트 */
        idx = 0; counter = bpf_map_lookup_elem(&stats, &idx);
        if (counter) (*counter)++;

        /* 바이트 카운터 갱신 (샘플링 판단용) */
        __sync_fetch_and_add(&result->bytes, ctx->skb->len);

        /* 10MB 초과 시 캐시 무효화 → 재검사 */
        if (result->bytes > 10485760) {
            bpf_map_delete_elem(&dpi_cache, &key);
            return NF_ACCEPT;  /* NFQUEUE로 전달 */
        }

        if (result->verdict == 0) {
            idx = 2; counter = bpf_map_lookup_elem(&stats, &idx);
            if (counter) (*counter)++;
            return NF_ACCEPT;   /* DPI ALLOW → bypass */
        } else if (result->verdict == 1) {
            idx = 3; counter = bpf_map_lookup_elem(&stats, &idx);
            if (counter) (*counter)++;
            return NF_DROP;     /* DPI DROP → 즉시 차단 */
        }
    }
    /* 캐시 미스 → NFQUEUE로 전달 (DPI 검사) */
    idx = 1; counter = bpf_map_lookup_elem(&stats, &idx);
    if (counter) (*counter)++;
    return NF_ACCEPT;
}

char _license[] SEC("license") = "GPL";

DPI 엔진에서 eBPF 맵 업데이트

Suricata의 output 플러그인에서 verdict를 eBPF 맵에 기록합니다:

/* Suricata output 플러그인 (유저스페이스): verdict를 eBPF 맵에 기록 */
#include <bpf/libbpf.h>
#include <bpf/bpf.h>

int map_fd;  /* bpf_obj_get()으로 pinned map 열기 */

void update_dpi_cache(struct Packet *p, int verdict)
{
    struct flow_key key = {
        .src_ip   = p->src.addr_data32[0],
        .dst_ip   = p->dst.addr_data32[0],
        .src_port = p->sp,
        .dst_port = p->dp,
        .protocol = p->proto,
    };
    struct dpi_result result = {
        .verdict   = (verdict == VERDICT_PASS) ? 0 : 1,
        .app_id    = p->flow->alproto,
        .timestamp = get_timestamp_ns(),
        .bytes     = 0,
    };

    bpf_map_update_elem(map_fd, &key, &result, BPF_ANY);

    /* 역방향 플로우도 등록 (양방향 캐시) */
    struct flow_key rev_key = {
        .src_ip = key.dst_ip, .dst_ip = key.src_ip,
        .src_port = key.dst_port, .dst_port = key.src_port,
        .protocol = key.protocol,
    };
    bpf_map_update_elem(map_fd, &rev_key, &result, BPF_ANY);
}

# eBPF 프로그램 로드 및 nftables 연동
# 1. 컴파일
clang -O2 -target bpf -c dpi_cache.bpf.c -o dpi_cache.bpf.o

# 2. 로드 및 맵 핀닝
bpftool prog load dpi_cache.bpf.o /sys/fs/bpf/dpi_bypass \
  type netfilter

# 3. nftables에서 eBPF 프로그램 연결
# (nftables 커널 5.18+에서 BPF verdict 지원)
nft add rule inet ngfw forward \
  ct state new \
  meta mark != 0xff \
  queue num 0-3 fanout  # BPF 캐시 미스만 NFQUEUE로 전달

# 4. 캐시 통계 확인
bpftool map dump pinned /sys/fs/bpf/dpi_bypass/stats
# key: 0  value (per-cpu): [12345, 12340, ...]  ← cache_hit
# key: 1  value (per-cpu): [567, 570, ...]      ← cache_miss

NGFW 시스템 서비스 구성

Linux NGFW를 프로덕션에 배포하기 위한 systemd 서비스 구성입니다:

# /etc/systemd/system/ngfw-nftables.service
[Unit]
Description=NGFW nftables Rules
Before=suricata.service
After=network-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/nftables-ngfw.conf
ExecReload=/usr/sbin/nft -f /etc/nftables-ngfw.conf
ExecStop=/usr/sbin/nft flush ruleset

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/ngfw-eswitch.service
[Unit]
Description=NGFW eSwitch TC flower Rules
After=ngfw-nftables.service
Requires=ngfw-nftables.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/usr/bin/devlink dev eswitch set pci/0000:03:00.0 mode switchdev
ExecStartPre=/usr/bin/sleep 2
ExecStartPre=/usr/sbin/ethtool -K eth0_rep0 hw-tc-offload on
ExecStart=/usr/local/bin/ngfw-tc-rules.sh
ExecStop=/usr/sbin/tc filter del dev eth0_rep0 ingress

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/ngfw-tuning.service
[Unit]
Description=NGFW Kernel Tuning
Before=ngfw-nftables.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '\
  sysctl -w net.netfilter.nf_conntrack_max=2000000; \
  sysctl -w net.netfilter.nf_conntrack_buckets=500000; \
  sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300; \
  sysctl -w net.netfilter.nf_flowtable_tcp_timeout=300; \
  sysctl -w net.core.optmem_max=81920; \
  sysctl -w net.core.netdev_budget=600; \
  sysctl -w net.core.netdev_max_backlog=10000; \
  sysctl -w net.ipv4.ip_forward=1; \
  ethtool -C eth0 rx-usecs 50 rx-frames 64 adaptive-rx on; \
  ethtool -G eth0 rx 4096 tx 4096; \
  /usr/local/bin/set_irq_affinity.sh 0-3 eth0 \
'

[Install]
WantedBy=multi-user.target

# 서비스 활성화 및 시작 순서
systemctl enable ngfw-tuning ngfw-nftables ngfw-eswitch
systemctl enable suricata conntrackd

# 시작 순서: tuning → nftables → eswitch → suricata → conntrackd
systemctl start ngfw-tuning
systemctl start ngfw-nftables
systemctl start ngfw-eswitch
systemctl start suricata
systemctl start conntrackd

# 상태 확인
systemctl status ngfw-nftables ngfw-eswitch suricata conntrackd

멀티 테이블 파이프라인

TC chain을 사용하여 다단계 매칭 파이프라인을 구성합니다:

# chain 0: conntrack 추적 및 분기
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower ct_state -trk \
  action ct zone 1 pipe \
  action goto chain 1

# chain 1: 상태 기반 분기
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state +trk+est \
  action goto chain 2  # ESTABLISHED → Fast Path chain

tc filter add dev eth0_rep0 ingress chain 1 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass  # NEW → CPU (Slow Path)

# chain 2: Fast Path (NAT + forward)
tc filter add dev eth0_rep0 ingress chain 2 prio 1 \
  protocol ip flower \
  action ct zone 1 nat \
  action mirred egress redirect dev eth1_rep0

XDP DDoS Pre-filter 패턴

NGFW의 가장 앞단에서 XDP를 사용하여 DDoS/스캔 트래픽을 CPU 부하 없이 처리합니다. 이 패턴은 conntrack 테이블 포화를 방지하는 핵심 방어선입니다.

/* xdp_ddos_filter.c — NGFW XDP DDoS Pre-filter */
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>

/* 차단 IP 세트 (관리 도구에서 동적 업데이트) */
struct {
    __uint(type, BPF_MAP_TYPE_LPM_TRIE);
    __uint(max_entries, 100000);
    __uint(map_flags, BPF_F_NO_PREALLOC);
    __type(key, struct lpm_key);
    __type(value, __u32);
} blocklist SEC(".maps");

/* SYN flood 속도 제한 (per-source IP) */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);
    __type(key, __be32);      /* source IP */
    __type(value, __u64);     /* timestamp + count */
} syn_rate SEC(".maps");

SEC("xdp")
int xdp_ddos_filter(struct xdp_md *ctx)
{
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_DROP;
    if (eth->h_proto != __constant_htons(ETH_P_IP)) return XDP_PASS;

    struct iphdr *iph = (void *)(eth + 1);
    if ((void *)(iph + 1) > data_end) return XDP_DROP;

    /* 1. IP 차단 리스트 확인 (LPM Trie: CIDR 매칭) */
    struct lpm_key key = { .prefixlen = 32, .addr = iph->saddr };
    if (bpf_map_lookup_elem(&blocklist, &key))
        return XDP_DROP;  /* 차단 IP → 즉시 DROP (최소 지연) */

    /* 2. SYN flood 감지 (TCP SYN 패킷만) */
    if (iph->protocol == IPPROTO_TCP) {
        struct tcphdr *tcph = (void *)iph + (iph->ihl * 4);
        if ((void *)(tcph + 1) > data_end) return XDP_DROP;

        if (tcph->syn && !tcph->ack) {
            /* SYN 속도 제한: 소스 IP당 초당 100 SYN */
            __u64 *rate = bpf_map_lookup_elem(&syn_rate, &iph->saddr);
            __u64 now = bpf_ktime_get_ns();
            if (rate) {
                __u64 last = *rate & 0xFFFFFFFF00000000ULL;
                __u32 count = *rate & 0xFFFFFFFF;
                if (now - last < 1000000000ULL) { /* 1초 이내 */
                    if (count > 100)
                        return XDP_DROP; /* 속도 초과 → DROP */
                    *rate = last | (count + 1);
                } else {
                    *rate = (now & 0xFFFFFFFF00000000ULL) | 1;
                }
            } else {
                __u64 val = (now & 0xFFFFFFFF00000000ULL) | 1;
                bpf_map_update_elem(&syn_rate, &iph->saddr, &val, BPF_ANY);
            }
        }
    }

    return XDP_PASS;  /* 정상 → 커널 네트워크 스택으로 전달 */
}

char _license[] SEC("license") = "GPL";

# XDP DDoS 필터 운영 명령
# 프로그램 로드
ip link set dev eth0 xdp obj xdp_ddos_filter.o sec xdp

# IP 차단 리스트 관리 (bpftool)
bpftool map update pinned /sys/fs/bpf/xdp_ddos/blocklist \
  key hex 20 00 00 00 c0 a8 64 00 \
  value hex 01 00 00 00  # 192.168.100.0/32 차단

# SYN flood 상위 공격자 확인
bpftool map dump pinned /sys/fs/bpf/xdp_ddos/syn_rate | \
  sort -t: -k2 -rn | head -20

# XDP 통계 확인
ip -s link show dev eth0 | grep -A5 xdp

conntrackd HA (세션 동기화)

Active-Standby NGFW 클러스터에서 failover 시 기존 세션을 유지하려면 conntrack 테이블을 실시간 동기화해야 합니다:

# /etc/conntrackd/conntrackd.conf (NGFW HA)
Sync {
    Mode FTFW {          # Fault Tolerant (ack 기반 신뢰성)
        DisableExternalCache Off
        CommitTimeout 1800
        PurgeTimeout 5
    }

    # 동기화 프로토콜
    Multicast {
        IPv4_address 225.0.0.50
        Group 3780
        IPv4_interface 192.168.100.1  # HA 전용 인터페이스
        Interface eth2
        SndSocketBuffer 1249280
        RcvSocketBuffer 1249280
        Checksum on
    }
}

General {
    Nice -20                  # 높은 우선순위
    HashSize 32768
    HashLimit 131072          # 최대 동기화 엔트리

    # 동기화 대상 필터 (flowtable 오프로드 세션 포함)
    Filter From Kernelspace {
        Protocol Accept {
            TCP
            UDP
        }
        Address Ignore {
            IPv4_address 127.0.0.1   # 로컬 제외
            IPv4_address 224.0.0.0/4 # 멀티캐스트 제외
        }
    }
}

# HA failover 스크립트 (Keepalived notify 스크립트)
#!/bin/bash
# /usr/local/bin/ngfw-failover.sh

case "$1" in
  "MASTER")
    # Active 전환: flowtable HW offload 재등록
    conntrackd -c           # 외부 캐시 → 커널 동기화
    conntrackd -k           # 커널 conntrack 동기화 요청

    # eSwitch FDB 규칙 재설치 (기존 EST 세션)
    nft flush flowtable inet ngfw ft
    nft add flowtable inet ngfw ft \
      { hook ingress priority 0\; devices = { eth0, eth1 }\; flags offload\; }

    # 기존 conntrack의 EST 세션을 flowtable에 재등록
    # (자동으로 다음 패킷이 도착하면 flow add @ft에 의해 등록됨)
    ;;
  "BACKUP")
    # Standby 전환: HW offload 정리
    conntrackd -f           # 외부 캐시 플러시
    nft flush flowtable inet ngfw ft
    ;;
esac

보안 vs 오프로드 트레이드오프

트레이드오프 모델

NGFW에서 가장 중요한 설계 결정은 어느 수준의 보안 검사를 활성화하고, 어느 지점에서 오프로드할 것인가입니다. 이 결정이 전체 시스템의 처리량을 결정합니다.

보안 기능을 추가할수록 오프로드 가능한 트래픽 비율이 줄어듭니다. 대략적인 모델:

• L4 ACL만 — 오프로드 비율 ~95%. 거의 모든 ESTABLISHED 세션이 Fast Path
• +IPS — 오프로드 비율 ~80%. 첫 패킷 IPS 검사 후 ALLOW된 세션만 오프로드
• +SSL Inspection — 오프로드 비율 ~40%. SSL 복호화가 필요한 세션은 CPU에서 처리
• +Full DPI + 주기적 재검사 — 오프로드 비율 ~20%. 지속적 모니터링이 필요한 세션

오프로드 비율 측정

# conntrack 전체 세션 수
conntrack -C

# flowtable 오프로드된 세션 수
conntrack -L -p tcp --state ESTABLISHED | wc -l

# flowtable 통계 (nftables)
nft list flowtable inet ngfw ft

# ethtool HW offload 카운터
ethtool -S eth0 | grep offload

# 오프로드 비율 계산
# ratio = (flowtable_sessions / total_established) * 100

위협 회피 대응

공격자가 오프로드 메커니즘을 악용하여 검사를 회피할 수 있는 시나리오와 대응:

주기적 샘플링 구현

오프로드된 세션에 대한 주기적 재검사(sampling)는 위협 회피를 방지하는 핵심 메커니즘입니다:

# nftables에서 바이트 기반 샘플링 구현
table inet ngfw_sampling {
    chain forward {
        type filter hook forward priority -50; policy accept;

        # 오프로드된 세션의 패킷이 N번째마다 CPU로 복귀
        # (flowtable timeout이 만료되면 자동으로 이 체인을 거침)

        # 10MB 이상 전송된 세션 → DPI 재검사
        ct state established \
            ct bytes gt 10485760 \
            ct mark != 0xfe \
            queue num 4 bypass  # 재검사용 별도 큐

        # 1시간 이상 지속된 세션 → 재분류
        ct state established \
            ct original packets gt 100000 \
            ct mark != 0xfe \
            queue num 4 bypass

        # 재검사 완료 마킹 (중복 방지)
        ct state established ct mark 0xfe accept
    }
}

정책 설계 가이드

Zone-based 오프로드 정책 매트릭스

네트워크 Zone 간 트래픽 특성에 따라 오프로드 수준을 차별화합니다:

nftables Zone 구현 예시

# Zone-based NGFW nftables 설정
table inet ngfw_zones {
    # Zone별 flowtable (오프로드 수준 차별화)
    flowtable ft_trust {
        hook ingress priority 0
        devices = { eth0 }    # 내부 네트워크
        flags offload          # HW offload 활성화
    }

    flowtable ft_untrust {
        hook ingress priority 0
        devices = { eth1 }    # 인터넷 연결
        # flags offload 미설정 → SW offload만
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid drop

        # Trust → Trust: 즉시 HW offload (DPI 건너뜀)
        iifname "eth0" oifname "eth0" \
            ct state established,related \
            flow add @ft_trust accept

        # Trust → Untrust: DPI 검사 후 SW offload
        iifname "eth0" oifname "eth1" \
            ct state established,related \
            flow add @ft_untrust accept

        # Untrust → DMZ: 반드시 DPI 검사
        iifname "eth1" oifname "eth2" \
            ct state new \
            queue num 0-3 fanout

        # Untrust → DMZ: DPI 완료 후에만 offload
        iifname "eth1" oifname "eth2" \
            ct state established ct mark 0xff \
            flow add @ft_untrust accept
    }
}

오프로드 비율 정량 모델

NGFW의 전체 처리량은 Fast Path와 Slow Path의 가중 합으로 모델링됩니다:

이 모델에서 Slow Path 처리량(DPI 성능)보다 오프로드 비율을 높이는 것이 전체 성능에 훨씬 큰 영향을 미칩니다. 오프로드 비율 1% 향상은 Slow Path 성능 20% 향상과 동등한 효과를 가집니다.

보안 수준별 성능 영향 시뮬레이션

• 오프로드 우선 정책: 내부 트래픽, 신뢰된 애플리케이션은 빠른 오프로드
• 보안 우선 정책: 인터넷 트래픽, 알 수 없는 프로토콜은 DPI 유지
• 하이브리드 접근: 세션 시작 시 DPI 검사 → 분류 완료 후 오프로드 → 주기적 샘플링

성능 튜닝과 벤치마크

RFC 9411 메트릭

NGFW 성능 측정에 사용되는 주요 메트릭 (RFC 9411 — Benchmarking Methodology for Network Security Device Performance):

• CPS (Connections Per Second) — 초당 새 TCP/UDP 연결 수립 수. Slow Path 성능의 핵심 지표
• CC (Concurrent Connections) — 동시 유지 가능한 세션 수. conntrack 테이블 + flowtable 크기
• Throughput — 총 데이터 처리량 (bps). Fast Path + Slow Path 합산
• Latency — 패킷 지연. Fast Path <10us, Slow Path >100us (DPI 포함)
• Offload Ratio — Fast Path로 처리되는 트래픽 비율

IRQ Affinity / NUMA 최적화

NGFW에서 CPU 코어 할당은 성능에 결정적입니다. NIC IRQ, Netfilter, DPI 엔진을 올바른 NUMA 노드와 코어에 배치해야 합니다:

# NUMA 토폴로지 확인
lscpu | grep -E "NUMA|Socket|Core"
# NUMA node0 CPU(s): 0-7    (NIC PCI 슬롯과 같은 노드)
# NUMA node1 CPU(s): 8-15

# NIC의 NUMA 노드 확인
cat /sys/class/net/eth0/device/numa_node
# 0  ← NIC이 NUMA 노드 0에 연결

# IRQ Affinity: NIC IRQ를 같은 NUMA 노드 코어에 바인딩
# eth0의 IRQ 번호 확인
grep eth0 /proc/interrupts | awk '{print $1}' | tr -d ':'
# IRQ 42, 43, 44, 45 (4개 큐)

# 각 IRQ를 NUMA node0 코어에 1:1 바인딩
echo 1 > /proc/irq/42/smp_affinity   # CPU 0
echo 2 > /proc/irq/43/smp_affinity   # CPU 1
echo 4 > /proc/irq/44/smp_affinity   # CPU 2
echo 8 > /proc/irq/45/smp_affinity   # CPU 3

# 또는: mlx5/ice 드라이버의 set_irq_affinity 스크립트
/usr/sbin/set_irq_affinity_cpulist.sh 0-3 eth0

NGFW 코어 배치 가이드

CPS/처리량/지연 최적화

# ===== 1. conntrack 최적화 =====
sysctl -w net.netfilter.nf_conntrack_max=2000000
sysctl -w net.netfilter.nf_conntrack_buckets=500000
# 해시 충돌 최소화: buckets ≥ max/4

# conntrack 타임아웃 단축 (빠른 리소스 회수)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=30

# ===== 2. flowtable 최적화 =====
sysctl -w net.netfilter.nf_flowtable_tcp_timeout=300
sysctl -w net.netfilter.nf_flowtable_udp_timeout=30

# ===== 3. NFQUEUE 최적화 =====
sysctl -w net.core.optmem_max=81920
# NFQUEUE 소켓 버퍼 증가 → 버스트 트래픽 대응
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

# ===== 4. NIC RSS/ethtool 최적화 =====
# RSS 큐를 IRQ affinity 코어 수에 맞춤
ethtool -L eth0 combined 4

# Interrupt Coalescing (배치 처리로 IRQ 빈도 감소)
ethtool -C eth0 rx-usecs 50 rx-frames 64 \
  tx-usecs 50 tx-frames 64 adaptive-rx on

# Ring Buffer 크기 증가 (버스트 흡수)
ethtool -G eth0 rx 4096 tx 4096

# HW offload 기능 활성화
ethtool -K eth0 hw-tc-offload on
ethtool -K eth0 ntuple on

# ===== 5. XDP DDoS pre-filter =====
ip link set dev eth0 xdp obj xdp_ddos_filter.o sec xdp

# ===== 6. eSwitch 최적화 =====
devlink dev eswitch set pci/0000:03:00.0 mode switchdev
devlink dev eswitch set pci/0000:03:00.0 inline-mode transport

# ===== 7. 커널 파라미터 =====
sysctl -w net.core.netdev_budget=600
sysctl -w net.core.netdev_max_backlog=10000
sysctl -w net.ipv4.ip_forward=1

# NAPI busy_poll (지연 최소화)
sysctl -w net.core.busy_read=50
sysctl -w net.core.busy_poll=50

ethtool Interrupt Coalescing 상세

NGFW에서 Interrupt Coalescing은 처리량과 지연 사이의 균형을 결정합니다:

벤치마크 방법론 (RFC 9411)

NGFW 성능을 올바르게 측정하기 위한 RFC 9411 기반 방법론입니다:

# TRex를 사용한 NGFW 벤치마크 예시

# 1. CPS 측정 (TCP SYN flood → 세션 수립률 측정)
./t-rex-64 -f cap2/http_simple.yaml \
  --duration 60 --multiplier 100000 \
  --latency 1000

# 2. 처리량 측정 (기존 세션에 대량 트래픽)
./t-rex-64 -f cap2/imix_64_594_1518.yaml \
  --duration 120 --multiplier 1 \
  --astf  # Application-layer TRex

# 3. 결과에서 Fast Path / Slow Path 분리 확인
# TRex 실행 중 DUT에서:
conntrack -C                          # 전체 세션 수
conntrack -L --status OFFLOAD | wc -l # 오프로드 세션
ethtool -S eth0 | grep tx_packets_phy # HW 처리 패킷

패킷 크기별 성능 특성

NGFW 성능은 패킷 크기에 크게 의존합니다. 작은 패킷은 PPS(초당 패킷)에 의해, 큰 패킷은 BPS(초당 비트)에 의해 제한됩니다:

IMIX(Internet Mix)는 실제 인터넷 트래픽을 모사한 혼합 패킷 크기 분포입니다 (7:4:1 비율로 64B:594B:1518B). NGFW 벤치마크에서는 IMIX 또는 HTTP 애플리케이션 트래픽을 사용하는 것이 실제 환경에 가장 가깝습니다.

성능 최적화 체크리스트

진단과 모니터링

모니터링 아키텍처

NGFW의 각 구성 요소에서 메트릭을 수집하여 중앙 모니터링 시스템으로 전달하는 아키텍처입니다:

핵심 알림 규칙

flowtable 진단

# flowtable 오프로드 상태 확인
nft list flowtable inet ngfw ft

# conntrack 테이블에서 offloaded 세션 확인
conntrack -L --status OFFLOAD

# conntrack 이벤트 실시간 모니터
conntrack -E -e NEW,DESTROY

# TC flower 오프로드 규칙 통계
tc -s filter show dev eth0_rep0 ingress

# eSwitch FDB 규칙 확인
tc -s filter show dev eth0_rep0 ingress chain 0

# ethtool 오프로드 카운터
ethtool -S eth0 | grep -E '(offload|flower|ct)'

# devlink 트랩 (오프로드 실패 원인)
devlink trap show pci/0000:03:00.0

bpftrace / perf 진단

# flowtable offload 이벤트 추적
bpftrace -e 'kprobe:nf_flow_offload_add { printf("flow offload add: %s\n", comm); }'

# conntrack NEW 이벤트 빈도 측정 (CPS 추정)
bpftrace -e 'kprobe:__nf_conntrack_alloc { @cps = count(); }
             interval:s:1 { printf("CPS: %d\n", @cps); clear(@cps); }'

# NFQUEUE 지연 측정
perf probe -a 'nf_queue_entry_get_refs'
perf stat -e probe:nf_queue_entry_get_refs -a sleep 10

# Netfilter 훅 처리 시간 분포
bpftrace -e 'kprobe:nf_hook_slow { @start[tid] = nsecs; }
             kretprobe:nf_hook_slow /@start[tid]/ {
               @latency_us = hist((nsecs - @start[tid]) / 1000);
               delete(@start[tid]);
             }'

Prometheus 메트릭 수집

NGFW의 성능을 지속적으로 모니터링하기 위한 주요 메트릭과 수집 방법입니다:

#!/bin/bash
# /usr/local/bin/ngfw-metrics.sh
# node_exporter textfile collector용 메트릭 생성

METRICS_DIR="/var/lib/node_exporter/textfile_collector"

{
  # conntrack 메트릭
  ct_count=$(conntrack -C 2>/dev/null || echo 0)
  ct_max=$(sysctl -n net.netfilter.nf_conntrack_max)
  echo "ngfw_conntrack_entries $ct_count"
  echo "ngfw_conntrack_max $ct_max"
  echo "ngfw_conntrack_utilization $(echo "scale=4; $ct_count/$ct_max" | bc)"

  # flowtable 오프로드 세션 수
  offloaded=$(conntrack -L --status OFFLOAD 2>/dev/null | wc -l)
  echo "ngfw_flowtable_offloaded_sessions $offloaded"

  # 오프로드 비율
  established=$(conntrack -L -p tcp --state ESTABLISHED 2>/dev/null | wc -l)
  if [ "$established" -gt 0 ]; then
    ratio=$(echo "scale=4; $offloaded/$established" | bc)
    echo "ngfw_offload_ratio $ratio"
  fi

  # NIC HW offload 카운터 (mlx5)
  for stat in tx_packets_phy rx_packets_phy \
              rx_vport_rdma_unicast_packets \
              tx_vport_rdma_unicast_packets; do
    val=$(ethtool -S eth0 2>/dev/null | grep "$stat" | awk '{print $2}')
    [ -n "$val" ] && echo "ngfw_nic_${stat} $val"
  done

  # TC flower 규칙 수
  tc_rules=$(tc -s filter show dev eth0_rep0 ingress 2>/dev/null | grep -c "filter")
  echo "ngfw_tc_flower_rules $tc_rules"

  # NFQUEUE 드롭 (과부하 지표)
  nfq_drops=$(cat /proc/net/netfilter/nfnetlink_queue 2>/dev/null | \
    awk '{sum+=$5} END {print sum+0}')
  echo "ngfw_nfqueue_drops $nfq_drops"

} > "$METRICS_DIR/ngfw.prom.$$"
mv "$METRICS_DIR/ngfw.prom.$$" "$METRICS_DIR/ngfw.prom"

실시간 성능 대시보드 스크립트

#!/bin/bash
# /usr/local/bin/ngfw-dashboard.sh — 실시간 NGFW 상태
watch -n 1 '
echo "===== NGFW Status ====="
echo ""
echo "--- Conntrack ---"
printf "  Entries:    %s / %s\n" $(conntrack -C) $(sysctl -n net.netfilter.nf_conntrack_max)
printf "  Offloaded:  %s\n" $(conntrack -L --status OFFLOAD 2>/dev/null | wc -l)
echo ""
echo "--- Flowtable ---"
nft list flowtable inet ngfw ft 2>/dev/null | tail -5
echo ""
echo "--- TC flower (HW rules) ---"
tc -s filter show dev eth0_rep0 ingress 2>/dev/null | \
  grep -E "(filter|action|Sent)" | head -20
echo ""
echo "--- NIC Offload Stats ---"
ethtool -S eth0 2>/dev/null | grep -E "(offload|flower|ct)" | head -10
echo ""
echo "--- NFQUEUE ---"
cat /proc/net/netfilter/nfnetlink_queue 2>/dev/null
'

트러블슈팅 체크리스트

자주 발생하는 문제와 해결

디버깅용 커널 트레이싱

# flowtable 이벤트 전체 추적 (디버깅 시에만 사용)
# 주의: 프로덕션에서는 성능 영향 있음

# 1. ftrace로 flowtable 함수 추적
echo 'nf_flow_offload*' > /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
cat /sys/kernel/debug/tracing/trace_pipe | head -100
echo 0 > /sys/kernel/debug/tracing/tracing_on

# 2. perf로 Netfilter 훅 프로파일링
perf top -g -e cycles:k --filter='nf_*'

# 3. bpftrace: flowtable HW offload 성공/실패 추적
bpftrace -e '
kprobe:nf_flow_offload_hw_add {
    printf("HW add: ct=%p\n", arg2);
}
kretprobe:nf_flow_offload_hw_add /retval != 0/ {
    printf("HW add FAILED: err=%d\n", retval);
}
kprobe:nf_flow_offload_hw_del {
    printf("HW del: flow=%p\n", arg1);
}'

# 4. conntrack 이벤트와 flowtable 이벤트 상관관계 추적
bpftrace -e '
kprobe:nf_conntrack_in {
    @ct_in = count();
}
kprobe:nf_flow_offload_ip_hook {
    @flow_hit = count();
}
interval:s:5 {
    printf("conntrack_in: %d, flow_hit: %d, ratio: ",
           @ct_in, @flow_hit);
    printf("%d%%\n",
           @flow_hit * 100 / (@ct_in + @flow_hit + 1));
    clear(@ct_in); clear(@flow_hit);
}'

커널 설정

커널 버전 요구사항

NGFW HW offload의 각 기능에 필요한 최소 커널 버전입니다:

필수 CONFIG_* 옵션

# Netfilter / conntrack
CONFIG_NF_CONNTRACK=y
CONFIG_NF_TABLES=y
CONFIG_NF_TABLES_INET=y
CONFIG_NFT_FLOW_OFFLOAD=y        # flowtable offload 지원
CONFIG_NF_FLOW_TABLE=y            # nf_flowtable 코어
CONFIG_NF_FLOW_TABLE_INET=y
CONFIG_NETFILTER_NETLINK_QUEUE=y  # NFQUEUE

# HW offload (eSwitch/TC)
CONFIG_NET_SWITCHDEV=y            # switchdev 프레임워크
CONFIG_NET_CLS_FLOWER=y           # TC flower classifier
CONFIG_NET_ACT_CT=y               # TC conntrack action
CONFIG_NET_ACT_MIRRED=y           # TC mirred (redirect)
CONFIG_NET_ACT_PEDIT=y            # TC packet edit
CONFIG_NET_ACT_TUNNEL_KEY=y       # TC tunnel encap/decap

# NIC 드라이버 (예: NVIDIA ConnectX)
CONFIG_MLX5_CORE=y
CONFIG_MLX5_ESWITCH=y
CONFIG_MLX5_TC_CT=y               # mlx5 CT offload

# XDP
CONFIG_XDP_SOCKETS=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y

# IPSec HW offload
CONFIG_XFRM=y
CONFIG_XFRM_OFFLOAD=y
CONFIG_INET_ESP_OFFLOAD=y

# conntrack 헬퍼 (ALG 프로토콜)
CONFIG_NF_CONNTRACK_FTP=m       # FTP ALG
CONFIG_NF_CONNTRACK_SIP=m       # SIP ALG
CONFIG_NF_CONNTRACK_H323=m      # H.323 ALG
CONFIG_NF_CONNTRACK_TFTP=m      # TFTP ALG
CONFIG_NF_CONNTRACK_PPTP=m      # PPTP ALG
CONFIG_NF_CT_NETLINK=y          # conntrackd 통신

# NAT 관련
CONFIG_NF_NAT=y
CONFIG_NF_NAT_MASQUERADE=y
CONFIG_NFT_NAT=y
CONFIG_NFT_MASQ=y

# NFQUEUE 관련
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NFT_QUEUE=y              # nft queue 표현식

# Intel E810 드라이버 (대안 NIC)
CONFIG_ICE=y
CONFIG_ICE_SWITCHDEV=y          # ice eSwitch 지원

# QoS 관련
CONFIG_NET_SCH_HTB=y            # HTB qdisc
CONFIG_NET_SCH_FQ_CODEL=y       # fq_codel (AQM)
CONFIG_NET_SCH_MQPRIO=y         # HW QoS 큐 매핑
CONFIG_NET_SCH_INGRESS=y        # TC ingress qdisc

모듈 로딩 순서와 검증

NGFW 관련 커널 모듈은 의존성 순서대로 로드해야 합니다. 다음은 systemd 서비스 이전에 실행할 모듈 로딩 스크립트입니다:

#!/bin/bash
# /usr/local/sbin/ngfw-modules-load.sh
# NGFW 커널 모듈 로딩 (의존성 순서)

set -e

# 1단계: 기본 Netfilter 프레임워크
modprobe nf_conntrack
modprobe nf_tables
modprobe nft_chain_nat
modprobe nft_ct              # nft ct 표현식

# 2단계: flowtable 오프로드
modprobe nf_flow_table
modprobe nf_flow_table_inet
modprobe nft_flow_offload    # nft flow offload 표현식

# 3단계: NFQUEUE (DPI 엔진 연동)
modprobe nfnetlink_queue
modprobe nft_queue           # nft queue 표현식

# 4단계: TC offload 프레임워크
modprobe act_ct              # TC conntrack action
modprobe act_mirred          # TC redirect action
modprobe act_pedit           # TC packet edit
modprobe cls_flower          # TC flower classifier

# 5단계: conntrack 헬퍼 (필요한 ALG만 선택 로드)
# modprobe nf_conntrack_ftp
# modprobe nf_conntrack_sip

# 6단계: IPSec offload (필요시)
# modprobe esp4_offload
# modprobe esp6_offload

echo "NGFW modules loaded successfully"

모듈 로딩 후 다음 명령으로 검증합니다:

# 모듈 로딩 확인
lsmod | grep -E "nf_flow|nft_flow|nf_conntrack|cls_flower|act_ct"

# 기대 출력 예시:
# nft_flow_offload     20480  1
# nf_flow_table_inet   16384  1 nft_flow_offload
# nf_flow_table        36864  1 nf_flow_table_inet
# nf_conntrack        172032  5 nf_flow_table,nft_ct,...
# cls_flower           40960  0
# act_ct               20480  0

# dmesg에서 초기화 로그 확인
dmesg | grep -iE "flow.table|conntrack|switchdev"

# NIC eSwitch 상태 확인
devlink dev eswitch show pci/0000:03:00.0 2>/dev/null || echo "eSwitch not available"

# NIC hw-tc-offload 기능 확인
ethtool -k eth0 | grep hw-tc-offload

커널 부트 파라미터

# /etc/default/grub의 GRUB_CMDLINE_LINUX에 추가
# NGFW 최적화 커널 부트 파라미터

# IOMMU (SmartNIC SR-IOV/eSwitch 필수)
intel_iommu=on iommu=pt

# CPU 격리: 데이터 플레인 코어를 커널 스케줄러에서 분리
isolcpus=4-11                  # Suricata 전용 코어 격리
nohz_full=4-11                 # 격리 코어의 타이머 틱 제거
rcu_nocbs=4-11                 # RCU 콜백을 다른 코어에서 실행

# Hugepages (VPP/DPDK 사용 시)
default_hugepagesz=1G hugepagesz=1G hugepages=4

# NIC MMIO 매핑 최적화
pci=assign-busses              # PCI 버스 재할당

# 네트워크 스택 최적화
net.ifnames=0                  # 예측 가능한 인터페이스 이름 비활성화 (선택)

sysctl 튜닝 파라미터

운영 가이드

NGFW 초기 배포 절차

Linux 기반 NGFW를 처음부터 배포하는 단계별 가이드입니다:

일상 운영 명령 요약

# ===== 상태 확인 =====
# 전체 NGFW 상태 요약
echo "=== conntrack ===" && conntrack -C && \
echo "=== offloaded ===" && conntrack -L --status OFFLOAD 2>/dev/null | wc -l && \
echo "=== nft flowtable ===" && nft list flowtable inet ngfw ft 2>/dev/null && \
echo "=== suricata ===" && systemctl is-active suricata

# ===== 긴급 대응 =====
# DDoS 감지 시 XDP 긴급 필터 적용
ip link set dev eth0 xdp obj /usr/local/lib/xdp/emergency_block.o sec xdp

# conntrack 테이블 긴급 정리 (가득 참 상황)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=60
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=5
conntrack -F  # 전체 플러시 (주의: 모든 세션 끊김)

# 특정 IP 긴급 차단
nft add element inet ngfw blocklist { 203.0.113.50 }

# ===== 정책 변경 =====
# 규칙 변경 시 기존 오프로드 세션 재평가
nft flush flowtable inet ngfw ft  # flowtable 초기화
# 이후 패킷이 도착하면 자동으로 새 규칙에 따라 재등록

# nftables 규칙 리로드 (서비스 무중단)
systemctl reload ngfw-nftables

# ===== 유지보수 =====
# Suricata 시그니처 업데이트
suricata-update
systemctl reload suricata

# NIC 펌웨어 업데이트 (다운타임 필요)
mlxfwmanager --online-activate

장애 복구 시나리오

업그레이드/롤백 절차

NGFW 커널이나 NIC 펌웨어 업그레이드 시 무중단 또는 최소 중단을 위한 절차입니다:

# ===== 안전한 커널 업그레이드 절차 (HA 구성) =====

# 1단계: Standby 노드에서 먼저 업그레이드
conntrackd -n  # Standby 역할 확인

# 2단계: 새 커널 설치
dnf install kernel-6.6.x  # 또는 dpkg -i linux-image-6.6.x

# 3단계: Standby 재부팅 (Active가 트래픽 처리 중)
reboot

# 4단계: 재부팅 후 검증
uname -r                    # 새 커널 버전 확인
lsmod | grep nf_flow_table  # 모듈 로딩 확인
conntrackd -s               # HA 동기화 상태 확인
suricatasc -c uptime        # Suricata 정상 기동 확인

# 5단계: Failover → 이 노드를 Active로 승격
conntrackd -c commit        # 캐시된 세션 커밋
conntrackd -k               # Active 역할 요청

# 6단계: 구 Active 노드도 동일 절차로 업그레이드

로그 관리와 감사

NGFW는 보안 장비이므로 로그 관리가 법적 요구사항일 수 있습니다. 주요 로그 소스와 관리 방안입니다:

# /etc/rsyslog.d/ngfw.conf — NGFW 로그 분리 저장
# nftables LOG 타겟 로그
:msg, contains, "NGFW_" /var/log/ngfw/firewall.log
& stop

# conntrackd 로그
:programname, isequal, "conntrackd" /var/log/ngfw/conntrackd.log
& stop

# logrotate 설정
# /etc/logrotate.d/ngfw
# /var/log/ngfw/*.log {
#     daily
#     rotate 90
#     compress
#     delaycompress
#     missingok
#     notifempty
#     sharedscripts
#     postrotate
#         systemctl reload rsyslog
#     endscript
# }

용량 계획

NGFW 장비의 리소스 소요를 사전에 계획하기 위한 가이드입니다:

QUIC/TLS 1.3과 NGFW 오프로드

QUIC 프로토콜과 TLS 1.3의 Encrypted Client Hello(ECH)는 기존 NGFW의 DPI 기반 트래픽 분류 체계를 근본적으로 무력화합니다. 이 섹션에서는 QUIC/ECH 환경에서 NGFW 오프로드를 유지하기 위한 전략을 분석합니다.

QUIC 프로토콜이 NGFW에 미치는 영향

QUIC(RFC 9000)은 UDP 기반에 TLS 1.3 암호화를 내장한 전송 프로토콜입니다. 기존 TCP+TLS 스택과 비교하면 NGFW에 다음과 같은 도전을 제시합니다:

• UDP 기반 + 내장 TLS 1.3 암호화 — 전통적 DPI가 페이로드를 전혀 볼 수 없으며, TCP처럼 핸드셰이크 시퀀스로 상태를 추적할 수 없습니다
• Connection ID 기반 경로 — 5-tuple(src/dst IP + port + proto)이 변경되어도 CID만 유지되면 세션이 계속됩니다. 이는 conntrack의 5-tuple 기반 추적과 근본적으로 충돌합니다
• 0-RTT 재연결 — 이전 세션의 PSK를 사용하여 첫 패킷부터 암호화된 데이터를 전송하므로, conntrack의 NEW 세션 탐지가 어렵습니다
• Connection Migration — 모바일 환경에서 Wi-Fi↔LTE 전환 시 IP가 변경되어도 QUIC 세션이 유지되므로 flowtable 5-tuple 키가 무효화됩니다

QUIC 트래픽 탐지와 분류

QUIC 패킷은 첫 번째 바이트(Header Form bit)로 Long Header와 Short Header를 구분합니다. NGFW에서는 Initial Packet의 Long Header를 분석하여 QUIC 연결을 식별합니다.

• Initial Packet: 첫 번째 바이트의 최상위 비트 = 1 (Long Header), 다음 2비트가 패킷 타입(00 = Initial)
• Version 필드: 바이트 오프셋 1~4에 위치. QUIC v1은 0x00000001, QUIC v2는 0x6b3343cf
• Short Header: 첫 번째 바이트의 최상위 비트 = 0 → 연결 확립 후 데이터 패킷

nftables에서 QUIC 트래픽을 탐지하고 분류하는 규칙 예시입니다:

#!/usr/sbin/nft -f
# QUIC 트래픽 탐지 및 분류 nftables 규칙

table inet quic_detect {
    # QUIC Initial Packet 탐지 set (rate limiting용)
    set quic_new_conn {
        type ipv4_addr . inet_service
        flags dynamic,timeout
        timeout 30s
    }

    chain forward {
        type filter hook forward priority 0; policy accept;

        # UDP 443 트래픽 필터링
        udp dport 443 jump quic_classify

        # UDP 443 + UDP 80 (alt-svc 기반 QUIC 업그레이드)
        udp dport 80 @th,0,8 & 0x80 == 0x80 jump quic_classify
    }

    chain quic_classify {
        # Long Header 판별: 첫 번째 바이트 bit7 = 1
        @th,0,8 & 0x80 == 0x00 jump quic_short_header

        # QUIC v1 Initial Packet: first_byte & 0xF0 == 0xC0, version == 0x00000001
        @th,0,8 & 0xF0 == 0xC0 @th,8,32 == 0x00000001 \
            jump quic_initial

        # QUIC v2 Initial: version == 0x6b3343cf
        @th,0,8 & 0xF0 == 0xC0 @th,8,32 == 0x6b3343cf \
            jump quic_initial

        # 0-RTT Packet (재연결): first_byte & 0xF0 == 0xD0
        @th,0,8 & 0xF0 == 0xD0 \
            log prefix "QUIC-0RTT: " counter

        # Handshake Packet: first_byte & 0xF0 == 0xE0
        @th,0,8 & 0xF0 == 0xE0 counter accept
    }

    chain quic_initial {
        # 새 QUIC 연결 rate limiting (DDoS 방어)
        update @quic_new_conn { ip saddr . udp dport } \
            limit rate over 100/second burst 50 packets drop

        # 로깅 후 Slow Path로 전달 (DPI 검사)
        log prefix "QUIC-NEW: " counter accept
    }

    chain quic_short_header {
        # Short Header: 이미 확립된 QUIC 세션
        # conntrack EST 상태이면 flowtable으로 오프로드 가능
        ct state established flow add @ft counter accept
        ct state established counter accept
    }
}

TLS 1.3 Encrypted Client Hello (ECH)

TLS 1.3의 ECH(RFC 9460 초안)는 Client Hello 메시지 내의 SNI(Server Name Indication)를 완전히 암호화합니다. ECH 이전에는 TLS 핸드셰이크의 Client Hello에서 SNI를 평문으로 읽어 URL Filtering과 트래픽 분류에 활용할 수 있었지만, ECH가 활성화되면 이 방법이 완전히 무력화됩니다.

• ECH 동작 원리: 클라이언트가 DNS HTTPS 레코드에서 서버의 공개키를 받아 Client Hello의 핵심 정보(SNI 포함)를 암호화합니다
• Outer SNI vs Inner SNI: ECH는 "외부 SNI"(CDN/프록시 도메인)만 노출하고, 실제 목적지 SNI는 암호화된 "내부 SNI"에 포함됩니다
• JA4 핑거프린팅: ECH 환경에서 대안으로 TLS 핸드셰이크의 구조적 특성(cipher suite 순서, extension 조합, ALPN 목록)으로 클라이언트/애플리케이션을 식별합니다

QUIC/ECH 환경의 NGFW 전략

QUIC과 ECH가 확산되는 환경에서 NGFW의 트래픽 가시성을 유지하기 위한 4가지 전략을 분석합니다:

전략 1: QUIC 차단/제어 (정책적 접근)

• UDP 443을 차단하여 클라이언트가 TCP+TLS로 폴백하도록 유도
• 기업 환경에서 가장 단순하고 효과적인 방법
• 단점: HTTP/3 성능 이점 상실, 일부 서비스 호환성 문제

전략 2: 초기 핸드셰이크 기반 분류 후 오프로드

• QUIC Initial Packet의 가시 정보(SNI, Version, DCID 길이)로 1차 분류
• 분류 후 ALLOW된 세션의 Short Header 패킷을 conntrack 기반 오프로드
• 5-tuple 변경(Connection Migration) 시 오프로드 해제

전략 3: DNS 기반 사전 분류 (DoH/DoT 제어)

• DNS 응답을 분석하여 IP→도메인 매핑 테이블 구축
• DoH(DNS over HTTPS)를 차단하고 내부 DNS 서버만 허용
• DNS RPZ(Response Policy Zone)로 카테고리 기반 사전 차단

전략 4: 엔드포인트 기반 (QUIC Client Hello 파싱)

• 엔드포인트 에이전트가 애플리케이션 수준에서 QUIC 세션 정보를 NGFW에 전달
• SASE(Secure Access Service Edge) 모델: 클라이언트-사이드 터널로 가시성 확보
• QUIC Initial Packet의 CRYPTO 프레임에서 Client Hello를 파싱 (복호화 가능)

다음은 nftables + Suricata를 조합하여 QUIC을 처리하는 종합 규칙 예시입니다:

#!/usr/sbin/nft -f
# QUIC/ECH 대응 NGFW nftables 규칙 (전략 1+2+3 조합)

table inet ngfw_quic {
    # 정책별 QUIC 처리 모드
    # 0: block (TCP fallback 유도)
    # 1: inspect (Initial만 DPI)
    # 2: allow (분류 후 오프로드)

    # DNS 기반 IP→카테고리 매핑 (외부 스크립트로 갱신)
    set dns_blocked_ips {
        type ipv4_addr
        flags interval
        # 예: DNS RPZ에서 차단 도메인의 IP를 자동 추가
    }

    set quic_allowed_dsts {
        type ipv4_addr
        flags interval
        # 예: 업무용 SaaS IP 대역 (QUIC 허용)
    }

    flowtable ft {
        hook ingress priority 0;
        devices = { eth0, eth1 };
        flags offload;
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # 1. conntrack EST 세션 → flowtable 오프로드
        ct state established,related flow add @ft counter accept

        # 2. DNS 기반 사전 차단 (전략 3)
        ip daddr @dns_blocked_ips counter drop

        # 3. QUIC 처리 (UDP 443)
        udp dport 443 jump quic_policy

        # 4. 일반 TCP/TLS → DPI (NFQUEUE)
        tcp dport 443 ct state new \
            queue num 0-3 fanout,bypass

        # 5. 기타 허용 규칙
        ct state established,related accept
    }

    chain quic_policy {
        # 허용된 목적지 → QUIC 허용 (오프로드 대상)
        ip daddr @quic_allowed_dsts accept

        # 나머지 QUIC → 정책에 따라 처리
        # 전략 1: 차단하여 TCP fallback 유도
        # icmp type port-unreachable 응답으로 빠른 fallback
        reject with icmpx port-unreachable

        # 전략 2를 사용할 경우 (위 reject 대신):
        # @th,0,8 & 0x80 == 0x80 queue num 4-5 fanout,bypass
        # @th,0,8 & 0x80 == 0x00 ct state established accept
    }
}

# Suricata QUIC 탐지 규칙 (suricata.rules에 추가)
# QUIC Initial Packet 탐지 (App-Layer)
alert quic $HOME_NET any -> $EXTERNAL_NET 443 \
  (msg:"QUIC Initial Packet detected"; \
   quic.version; content:"|00 00 00 01|"; \
   sid:3000001; rev:1;)

# QUIC 0-RTT 재연결 탐지 (Early Data 위험)
alert quic $HOME_NET any -> $EXTERNAL_NET 443 \
  (msg:"QUIC 0-RTT Early Data"; \
   quic.header.type; content:"|01|"; \
   sid:3000002; rev:1;)

# JA4 핑거프린트 기반 브라우저 식별 예시
alert tls $HOME_NET any -> $EXTERNAL_NET 443 \
  (msg:"TLS JA4 - Chrome Browser detected"; \
   ja4.hash; content:"t13d1516h2"; startswith; \
   sid:3000003; rev:1;)

멀티 테넌트 NGFW 아키텍처

클라우드 환경과 MSSP(Managed Security Service Provider)에서는 단일 NGFW 인스턴스에서 다수의 테넌트(고객/VPC/네임스페이스)를 격리하여 운영해야 합니다. 이 섹션에서는 Linux 커널의 격리 메커니즘을 활용한 멀티 테넌트 NGFW 아키텍처를 분석합니다.

멀티 테넌시 격리 모델

Linux 커널에서 제공하는 네트워크 격리 기술을 NGFW 관점에서 비교합니다:

conntrack zone 기반 테넌트 격리

conntrack zone은 동일 커널 내에서 conntrack 테이블을 논리적으로 분리하는 가장 효율적인 방법입니다. 각 테넌트에 고유한 zone ID를 할당하면 동일한 5-tuple을 가진 세션도 충돌 없이 독립적으로 추적됩니다.

#!/usr/sbin/nft -f
# 멀티 테넌트 conntrack zone 설정
# 테넌트 A: zone 100, 테넌트 B: zone 200

table inet multi_tenant {
    # 테넌트별 독립 flowtable
    flowtable ft_tenant_a {
        hook ingress priority 0;
        devices = { eth0, eth1 };
        flags offload;
    }

    flowtable ft_tenant_b {
        hook ingress priority 0;
        devices = { eth0, eth2 };
        flags offload;
    }

    # 테넌트 분류 체인 (ingress에서 mark 설정)
    chain prerouting {
        type filter hook prerouting priority -150; policy accept;

        # 서브넷 기반 테넌트 분류
        ip saddr 10.100.0.0/16 meta mark set 100
        ip saddr 10.200.0.0/16 meta mark set 200

        # VLAN 기반 테넌트 분류 (대안)
        # vlan id 100 meta mark set 100
        # vlan id 200 meta mark set 200

        # mark → conntrack zone 매핑
        meta mark 100 ct zone set 100
        meta mark 200 ct zone set 200
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # 테넌트 A: zone 100의 EST 세션 → 전용 flowtable
        meta mark 100 ct zone 100 ct state established \
            flow add @ft_tenant_a counter accept

        # 테넌트 B: zone 200의 EST 세션 → 전용 flowtable
        meta mark 200 ct zone 200 ct state established \
            flow add @ft_tenant_b counter accept

        # 새 세션: 테넌트별 DPI 큐 분리
        meta mark 100 ct zone 100 ct state new \
            queue num 0-3 fanout,bypass

        meta mark 200 ct zone 200 ct state new \
            queue num 4-7 fanout,bypass

        # RELATED 세션 허용
        ct state related accept
    }
}

TC flower에서도 conntrack zone을 지정하여 HW 수준의 테넌트 격리를 구현할 수 있습니다:

# TC flower: 테넌트별 conntrack zone + HW offload

# 테넌트 A (VF0, zone 100): untracked → ct zone 100 시작
tc filter add dev enp4s0f0v0 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 100

# 테넌트 A: EST → HW forward to uplink
tc filter add dev enp4s0f0v0 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  ct_zone 100 \
  action ct zone 100 \
  action mirred egress redirect dev enp4s0f0

# 테넌트 B (VF1, zone 200): untracked → ct zone 200 시작
tc filter add dev enp4s0f0v1 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 200

# 테넌트 B: EST → HW forward to uplink
tc filter add dev enp4s0f0v1 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  ct_zone 200 \
  action ct zone 200 \
  action mirred egress redirect dev enp4s0f0

# 테넌트별 conntrack 상태 확인
conntrack -L --zone 100  # 테넌트 A 세션
conntrack -L --zone 200  # 테넌트 B 세션

VRF + eSwitch VF 기반 격리

VRF(Virtual Routing and Forwarding)는 L3 라우팅을 테넌트별로 완전 격리합니다. eSwitch의 VF representor와 결합하면 HW 수준의 라우팅 + 방화벽 격리가 가능합니다.

#!/bin/bash
# VRF + eSwitch VF 기반 멀티 테넌트 설정

# 1. VRF 생성 (테넌트별)
ip link add vrf-tenant-a type vrf table 100
ip link set vrf-tenant-a up
ip link add vrf-tenant-b type vrf table 200
ip link set vrf-tenant-b up

# 2. VF representor를 VRF에 바인딩
ip link set enp4s0f0v0 master vrf-tenant-a
ip link set enp4s0f0v1 master vrf-tenant-b

# 3. 업링크 서브인터페이스를 VRF에 바인딩
ip link add link enp4s0f0 name enp4s0f0.100 type vlan id 100
ip link set enp4s0f0.100 master vrf-tenant-a
ip addr add 10.100.0.1/24 dev enp4s0f0.100

ip link add link enp4s0f0 name enp4s0f0.200 type vlan id 200
ip link set enp4s0f0.200 master vrf-tenant-b
ip addr add 10.200.0.1/24 dev enp4s0f0.200

# 4. VRF별 라우팅 테이블
ip route add default via 10.100.0.254 table 100
ip route add default via 10.200.0.254 table 200

# 5. sysctl: VRF별 forwarding 활성화
sysctl -w net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.conf.vrf-tenant-a.forwarding=1
sysctl -w net.ipv4.conf.vrf-tenant-b.forwarding=1

#!/usr/sbin/nft -f
# VRF 기반 테넌트별 nftables 방화벽 + flowtable

table inet vrf_ngfw {
    flowtable ft_a {
        hook ingress priority 0;
        devices = { enp4s0f0v0, enp4s0f0.100 };
        flags offload;
    }

    flowtable ft_b {
        hook ingress priority 0;
        devices = { enp4s0f0v1, enp4s0f0.200 };
        flags offload;
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # VRF 인터페이스로 테넌트 구분
        iifname "enp4s0f0v0" jump tenant_a_rules
        iifname "enp4s0f0v1" jump tenant_b_rules

        # 반환 트래픽
        oifname "enp4s0f0v0" ct state established,related accept
        oifname "enp4s0f0v1" ct state established,related accept
    }

    chain tenant_a_rules {
        # 테넌트 A 보안 정책
        ct state established flow add @ft_a counter accept
        ct state new tcp dport { 80, 443 } accept
        ct state new udp dport 53 accept
        counter drop
    }

    chain tenant_b_rules {
        # 테넌트 B 보안 정책 (더 제한적)
        ct state established flow add @ft_b counter accept
        ct state new tcp dport 443 accept
        counter drop
    }
}

Kubernetes 환경의 NGFW

Kubernetes에서는 CNI(Container Network Interface) 플러그인이 Pod 간 네트워킹을 관리합니다. NGFW 기능을 K8s 환경에 통합하려면 CNI의 데이터 플레인과 flowtable offload의 호환성을 고려해야 합니다.

eBPF 기반 차세대 NGFW

eBPF(extended Berkeley Packet Filter)는 커널 내에서 안전하게 실행되는 프로그램을 통해 네트워크 패킷 처리를 프로그래밍할 수 있는 기술입니다. 전통적인 nftables/iptables 기반 방화벽을 넘어, eBPF는 더 유연하고 고성능인 NGFW 파이프라인을 구현할 수 있게 합니다.

eBPF NGFW의 장점과 한계

BPF netfilter 프로그램 (커널 6.4+)

Linux 커널 6.4에서 도입된 BPF_PROG_TYPE_NETFILTER는 Netfilter 훅 포인트에 BPF 프로그램을 직접 연결할 수 있게 합니다. 이를 통해 nftables 규칙 대신 BPF 프로그램으로 방화벽 로직을 구현할 수 있습니다.

/* BPF netfilter 프로그램 예시 — 세션 추적 + 오프로드 결정 */
/* 커널 6.4+ 필요, libbpf 사용 */

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/netfilter.h>

/* conntrack kfunc 선언 (커널 6.4+) */
extern struct nf_conn *
bpf_xdp_ct_lookup(struct xdp_md *ctx,
                  struct bpf_sock_tuple *tuple, u32 len,
                  struct bpf_ct_opts *opts, u32 opts_len) __ksym;
extern void
bpf_ct_release(struct nf_conn *ct) __ksym;

/* 세션별 DPI 결과를 저장하는 BPF 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);
    __type(key, struct flow_key);    /* 5-tuple */
    __type(value, struct flow_info);  /* DPI 결과 + 상태 */
} flow_map SEC(".maps");

/* DPI 완료 + ALLOW된 세션을 기록하는 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 500000);
    __type(key, struct flow_key);
    __type(value, __u64);  /* 오프로드 타임스탬프 */
} offload_map SEC(".maps");

/* 통계 카운터 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 4);  /* 0:pass, 1:drop, 2:offload, 3:dpi */
    __type(key, __u32);
    __type(value, __u64);
} stats SEC(".maps");

struct flow_key {
    __be32 saddr;
    __be32 daddr;
    __be16 sport;
    __be16 dport;
    __u8   proto;
};

struct flow_info {
    __u32 app_id;        /* DPI 분류 결과 */
    __u32 verdict;       /* 0=pending, 1=allow, 2=deny */
    __u64 pkt_count;     /* 패킷 수 */
    __u64 byte_count;    /* 바이트 수 */
    __u64 last_seen;     /* 마지막 패킷 타임스탬프 */
};

SEC("netfilter")
int ngfw_filter(struct bpf_nf_ctx *ctx)
{
    struct sk_buff *skb = ctx->skb;
    struct flow_key key = {};
    struct flow_info *info;
    __u32 stat_key;

    /* 5-tuple 추출 */
    if (extract_flow_key(skb, &key) < 0)
        return NF_ACCEPT;

    /* flow_map에서 기존 세션 조회 */
    info = bpf_map_lookup_elem(&flow_map, &key);

    if (!info) {
        /* 새 세션: flow_map에 등록하고 DPI로 전달 */
        struct flow_info new_info = {
            .verdict = 0,  /* pending */
            .pkt_count = 1,
        };
        bpf_map_update_elem(&flow_map, &key, &new_info, BPF_ANY);
        stat_key = 3;  /* DPI로 전달 */
        update_stats(&stats, stat_key);
        return NF_ACCEPT;  /* Slow Path로 진행 */
    }

    /* DPI 결과에 따른 처리 */
    switch (info->verdict) {
    case 1:  /* ALLOW */
        info->pkt_count++;
        info->byte_count += skb->len;
        info->last_seen = bpf_ktime_get_ns();

        /* 10패킷 이상이면 오프로드 대상으로 마킹 */
        if (info->pkt_count > 10 &&
            !bpf_map_lookup_elem(&offload_map, &key)) {
            __u64 ts = bpf_ktime_get_ns();
            bpf_map_update_elem(&offload_map, &key, &ts, BPF_ANY);
            stat_key = 2;
            update_stats(&stats, stat_key);
        }

        stat_key = 0;
        update_stats(&stats, stat_key);
        return NF_ACCEPT;

    case 2:  /* DENY */
        stat_key = 1;
        update_stats(&stats, stat_key);
        return NF_DROP;

    default:  /* PENDING — 아직 DPI 진행 중 */
        info->pkt_count++;
        return NF_ACCEPT;
    }
}

char _license[] SEC("license") = "GPL";

Cilium의 eBPF 방화벽 아키텍처

Cilium은 Kubernetes 환경에서 가장 널리 사용되는 eBPF 기반 CNI + 방화벽 솔루션입니다. 커널의 nf_conntrack과 nftables를 사용하지 않고, eBPF 맵으로 자체 conntrack과 정책 엔진을 구현합니다.

Cilium의 데이터 플레인 파이프라인은 다음과 같은 순서로 실행됩니다:

• 1단계 — XDP pre-filter: 인입 트래픽에서 명백한 공격(SYN flood, 잘못된 패킷)을 드라이버 수준에서 차단
• 2단계 — tc-bpf ingress: 목적지 Pod의 identity를 lookup하고, CT map에서 기존 세션을 조회
• 3단계 — Policy 평가: source identity + destination identity 조합으로 policy map에서 ALLOW/DENY 판정
• 4단계 — CT update: 새 세션이면 CT map에 엔트리 생성, 기존 세션이면 카운터와 타임스탬프 갱신
• 5단계 — NAT/LB: ClusterIP → Pod IP 변환, NodePort → Pod IP 변환
• 6단계 — redirect: bpf_redirect_peer()로 veth 피어를 통해 목적지 Pod에 직접 전달 (네트워크 스택 우회)

/* Cilium CT map 구조 (간소화) */
/* bpf/lib/conntrack.h 참고 */

struct ct_entry {
    __u64 rx_packets;        /* 수신 패킷 수 */
    __u64 rx_bytes;          /* 수신 바이트 */
    __u64 tx_packets;        /* 송신 패킷 수 */
    __u64 tx_bytes;          /* 송신 바이트 */
    __u32 lifetime;          /* 남은 수명 (초) */
    __u16 rx_closing:1;      /* FIN 수신 */
    __u16 tx_closing:1;      /* FIN 송신 */
    __u16 nat46:1;           /* NAT46 변환 */
    __u16 lb_loopback:1;     /* LB 루프백 */
    __u16 seen_non_syn:1;    /* SYN 이후 패킷 확인 */
    __u16 node_port:1;       /* NodePort 플래그 */
    __u8  rev_nat_index;     /* 역NAT 인덱스 */
    __u8  slave;             /* LB backend 슬롯 */
    __u16 ifindex;           /* 출력 인터페이스 */
    __u32 src_sec_id;        /* 소스 보안 identity */
};

/* CT GC (Garbage Collection) — 유저스페이스 에이전트 */
/* cilium-agent가 주기적으로 CT map을 순회하며 만료 엔트리 삭제 */
/* GC 주기: 기본 12초, conntrack-gc-interval 옵션으로 조절 */
/* GC 전략: */
/*   1. lifetime이 0인 엔트리 삭제 */
/*   2. TCP FIN/RST 후 grace period 만료 엔트리 삭제 */
/*   3. NAT map의 orphan 엔트리 정리 */

tc-bpf vs XDP vs BPF netfilter 비교

eBPF 기반 NGFW를 구현할 때 사용할 수 있는 3가지 BPF 프로그램 타입의 특성을 비교합니다:

각 BPF 타입의 NGFW에서의 역할을 종합하면:

• XDP: 최전방에서 볼륨 공격(SYN flood, UDP flood, amplification)을 드라이버 수준에서 차단합니다. skb 할당 전에 처리하므로 CPU 오버헤드가 최소입니다.
• tc-bpf: 메인 방화벽 엔진으로 작동합니다. conntrack 조회, 정책 평가, NAT, 라우팅/redirect를 모두 처리합니다. Cilium/Calico의 핵심 데이터 플레인입니다.
• BPF netfilter: 기존 nftables 인프라를 유지하면서 특정 훅에 BPF 로직을 삽입합니다. 커스텀 DPI 로직이나 복잡한 verdict 결정에 적합합니다.

흔한 실수와 안티패턴

NGFW 오프로드를 구현할 때 자주 발생하는 실수와 안티패턴 10가지를 정리합니다. 각 실수에 대한 증상, 원인, 올바른 해결 방법을 포함합니다.

실수 1: flowtable에 flags offload 누락

# ❌ 잘못된 설정: flags offload 누락
nft add flowtable inet filter ft \
  { hook ingress priority 0; devices = { eth0, eth1 }; }
# → SW fast path만 동작, HW offload 없음

# ✅ 올바른 설정
nft add flowtable inet filter ft \
  { hook ingress priority 0; devices = { eth0, eth1 }; \
    flags offload; }

# 검증: HW offload 확인
conntrack -L --status OFFLOAD 2>/dev/null | wc -l
# 0이면 HW offload 동작하지 않음

# NIC 지원 여부 확인
ethtool -k eth0 | grep hw-tc-offload
# hw-tc-offload: on → HW offload 가능

실수 2: nf_conntrack_max 부족

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

# ❌ 기본값(65536)은 NGFW에 부족
# 증상: dmesg에 "nf_conntrack: table full, dropping packet" 출력
dmesg | grep "table full"

# ✅ 예상 동시 세션의 1.5배로 설정
# 예: 동시 세션 200K 예상 → 300K으로 설정
sysctl -w net.netfilter.nf_conntrack_max=300000

# 해시 테이블 크기도 함께 조정 (max / 4 권장)
# 부팅 시 모듈 파라미터로 설정 (런타임 변경 불가)
echo "options nf_conntrack hashsize=75000" > \
  /etc/modprobe.d/nf_conntrack.conf

# 메모리 계산: 300K × ~320 bytes = ~96 MB
# 영구 설정
echo "net.netfilter.nf_conntrack_max = 300000" >> /etc/sysctl.d/99-ngfw.conf

실수 3: NFQUEUE fail-open 미설정

# ❌ 잘못된 설정: bypass 없음
# Suricata가 죽으면 모든 트래픽이 DROP됨
nft add rule inet filter forward \
  ct state new queue num 0

# ✅ 올바른 설정: bypass 옵션으로 fail-open
nft add rule inet filter forward \
  ct state new queue num 0-3 fanout,bypass

# fanout: 여러 NFQUEUE에 분산 (Suricata 멀티스레드)
# bypass: NFQUEUE가 비어있으면 자동으로 ACCEPT

# 검증: Suricata 프로세스 상태 확인
ss -nlp | grep suricata
# Suricata가 NFQUEUE를 바인딩하고 있는지 확인

# Suricata 설정 (suricata.yaml)
# nfqueue:
#   mode: accept   ← fail-open (NFQUEUE 바인딩 해제 시 accept)
#   fail-open: yes

실수 4: flowtable timeout > conntrack timeout

# ❌ 위험: conntrack timeout이 먼저 만료되면
# conntrack 엔트리 삭제 → flowtable 엔트리 고아화
# → HW에 유령 규칙 잔존 → 보안 위험

# conntrack timeout 확인
sysctl net.netfilter.nf_conntrack_tcp_timeout_established
# 기본: 432000 (5일)

# ✅ flowtable timeout은 conntrack timeout보다 짧게
# flowtable 기본 timeout: 30초 (자동 갱신)
# 문제가 되는 경우: conntrack timeout을 짧게 줄인 경우
# 예: UDP conntrack timeout을 30초로 줄이면
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60
# flowtable aging은 이보다 짧은 주기로 동작해야 함

# HW flow 엔트리 상태 확인 (mlx5)
tc -s filter show dev eth0 ingress
# → 각 규칙의 packets/bytes 카운터 확인
# 카운터가 오래 정지된 규칙 = 유령 플로우 의심

실수 5: ALG 프로토콜 무조건 오프로드

# ❌ 잘못된 설정: 모든 EST 세션을 무조건 오프로드
nft add rule inet filter forward \
  ct state established flow add @ft

# ✅ 올바른 설정: ALG helper가 있는 세션은 제외
nft add rule inet filter forward \
  ct state established \
  ct helper "" \
  flow add @ft

# ct helper ""는 helper가 없는 세션만 매칭
# FTP, SIP, H.323 등 ALG 세션은 항상 Slow Path 유지

# 현재 ALG helper가 할당된 세션 확인
conntrack -L | grep helper
# 예: tcp  6 300 ESTABLISHED ... helper=ftp

실수 6: eSwitch switchdev 전환 시 VF 미재설정

# ❌ 잘못된 순서: VF가 바인딩된 상태에서 switchdev 전환
# 결과: 전환 실패 또는 VF가 legacy 모드에 잔류

# ✅ 올바른 순서
# 1. VF unbind (모든 VF)
for vf in /sys/bus/pci/devices/0000:04:00.0/virtfn*; do
    pci_addr=$(basename $(readlink $vf))
    echo $pci_addr > /sys/bus/pci/drivers/mlx5_core/unbind 2>/dev/null
done

# 2. switchdev 모드 전환
devlink dev eswitch set pci/0000:04:00.0 mode switchdev

# 3. VF rebind
for vf in /sys/bus/pci/devices/0000:04:00.0/virtfn*; do
    pci_addr=$(basename $(readlink $vf))
    echo $pci_addr > /sys/bus/pci/drivers/mlx5_core/bind 2>/dev/null
done

# 4. 검증
devlink dev eswitch show pci/0000:04:00.0
# mode switchdev inline-mode transport encap-mode basic

# VF representor 확인
ip link show | grep "enp4s0f0v"

실수 7: IRQ affinity 미설정

# 증상: mpstat으로 확인하면 CPU0만 100%, 나머지 idle
mpstat -P ALL 1

# 현재 IRQ 분포 확인
cat /proc/interrupts | grep eth0

# ✅ IRQ affinity 자동 설정 스크립트
# Mellanox NIC의 경우
if [ -x /usr/sbin/mlnx_affinity ]; then
    /usr/sbin/mlnx_affinity
fi

# 수동 설정: RX 큐별 IRQ를 별도 코어에 바인딩
# 예: 8개 RX 큐를 CPU 0-7에 각각 바인딩
for i in $(seq 0 7); do
    irq=$(grep "eth0-$i" /proc/interrupts | awk '{print $1}' | tr -d ':')
    echo $((1 << $i)) > /proc/irq/$irq/smp_affinity
done

# irqbalance 서비스 비활성화 (NGFW에서는 수동 제어 권장)
systemctl stop irqbalance
systemctl disable irqbalance

# RPS (Receive Packet Steering) 설정 (SW fallback)
echo "ff" > /sys/class/net/eth0/queues/rx-0/rps_cpus

실수 8: XDP + NFQUEUE 순서 실수

# ❌ 문제: XDP에서 DPI 대상까지 DROP
# XDP는 Netfilter 이전에 실행되므로
# XDP에서 DROP한 패킷은 NFQUEUE(DPI)에 도달 불가

# ✅ 올바른 설계:
# XDP: 명백한 공격만 차단 (rate limit, blocklist)
# Netfilter/NFQUEUE: DPI 대상 패킷 처리

# XDP에서 DPI 대상 트래픽은 반드시 XDP_PASS
# XDP 프로그램 내 분류 로직:
#   blocklist match → XDP_DROP
#   rate limit 초과 → XDP_DROP
#   그 외 모두 → XDP_PASS (Netfilter로 진행)

# XDP 프로그램 로드
ip link set dev eth0 xdpgeneric obj xdp_prefilter.o sec xdp

# XDP 통계 확인 (DROP된 패킷이 의도한 것인지 검증)
bpftool prog show
bpftool map dump name xdp_stats_map

실수 9: conntrackd 동기화 없이 HA failover

# ❌ conntrackd 없이 VRRP failover 시:
# 모든 기존 세션이 새 마스터에서 NEW로 처리
# → DPI 재검사, flowtable 재등록 → 수초간 성능 저하

# ✅ conntrackd 설정 (/etc/conntrackd/conntrackd.conf)
# Sync {
#     Mode FTFW {            ← Fault Tolerant, Full Write
#         ResendQueueSize 131072
#         PurgeTimeout 60
#     }
#     UDP {
#         IPv4_address 10.0.0.1
#         IPv4_Destination_Address 10.0.0.2
#         Port 3780
#         Interface eth2      ← 동기화 전용 인터페이스
#     }
# }

# conntrackd 시작
systemctl start conntrackd

# VRRP failover 스크립트에 추가
# /etc/keepalived/notify_master.sh:
conntrackd -C /etc/conntrackd/conntrackd.conf -c  # 커밋
conntrackd -C /etc/conntrackd/conntrackd.conf -f  # 플러시
conntrackd -C /etc/conntrackd/conntrackd.conf -R  # 수신 테이블 복원

# 동기화 상태 확인
conntrackd -s
# cache-internal: 150000 entries
# cache-external: 148500 entries  ← 피어와 거의 동기

실수 10: HW flow table 크기 초과 무시

# NIC별 HW flow table 최대 엔트리
# Mellanox CX-6 Dx: ~1M flows
# Intel E810: ~64K flows
# Broadcom P2100: ~500K flows

# ❌ HW 테이블 초과 시 증상:
# - dmesg: "mlx5_core: Failed to add TC flower rule (-ENOSPC)"
# - 새 오프로드 실패 → SW flowtable 폴백 → 성능 급락
# - 기존 HW 규칙은 유지되지만 새 세션은 모두 SW 처리

# ✅ 모니터링 설정
# Prometheus exporter를 위한 HW flow 사용률 체크 스크립트

# 현재 HW offload 세션 수
hw_flows=$(conntrack -L --status OFFLOAD 2>/dev/null | wc -l)
echo "ngfw_hw_flows_current $hw_flows"

# TC filter 통계
tc -s filter show dev eth0 ingress | grep -c "in_hw"
# in_hw = HW에 설치된 규칙 수

# 알림 임계값: HW 한계의 80%에서 경고
hw_max=1000000  # CX-6 Dx
threshold=$(( hw_max * 80 / 100 ))
if [ $hw_flows -gt $threshold ]; then
    logger -p daemon.warning "NGFW: HW flow table usage $hw_flows/$hw_max (${threshold} threshold)"
fi

실습 가이드

이 섹션에서는 실제 Linux 환경에서 NGFW 오프로드를 단계별로 구현하는 실습을 제공합니다. 네트워크 네임스페이스를 활용하여 물리 장비 없이도 핵심 개념을 실험할 수 있습니다.

실습 환경 구성

Lab 1 — 기본 flowtable 오프로드

네트워크 네임스페이스로 라우터를 구성하고, nftables flowtable을 설정한 후 성능을 측정합니다.

#!/bin/bash
# Lab 1: 기본 flowtable 오프로드 실습
# 토폴로지: [client] ---veth--- [router] ---veth--- [server]

set -e

# ============ 1. 네임스페이스 생성 ============
ip netns add client
ip netns add router
ip netns add server

# ============ 2. veth 쌍 생성 ============
# client ↔ router
ip link add c-eth0 type veth peer name r-eth0
ip link set c-eth0 netns client
ip link set r-eth0 netns router

# router ↔ server
ip link add r-eth1 type veth peer name s-eth0
ip link set r-eth1 netns router
ip link set s-eth0 netns server

# ============ 3. IP 설정 ============
# client: 10.0.1.0/24
ip netns exec client ip addr add 10.0.1.10/24 dev c-eth0
ip netns exec client ip link set c-eth0 up
ip netns exec client ip link set lo up
ip netns exec client ip route add default via 10.0.1.1

# router: 게이트웨이
ip netns exec router ip addr add 10.0.1.1/24 dev r-eth0
ip netns exec router ip addr add 10.0.2.1/24 dev r-eth1
ip netns exec router ip link set r-eth0 up
ip netns exec router ip link set r-eth1 up
ip netns exec router ip link set lo up
ip netns exec router sysctl -w net.ipv4.ip_forward=1

# server: 10.0.2.0/24
ip netns exec server ip addr add 10.0.2.20/24 dev s-eth0
ip netns exec server ip link set s-eth0 up
ip netns exec server ip link set lo up
ip netns exec server ip route add default via 10.0.2.1

# ============ 4. 연결 테스트 ============
ip netns exec client ping -c 2 10.0.2.20

echo "=== 네트워크 설정 완료 ==="

# ============ 5. nftables flowtable 설정 (router) ============

ip netns exec router nft -f - <<'EOF'
flush ruleset

table inet ngfw_lab {
    flowtable ft {
        hook ingress priority 0;
        devices = { r-eth0, r-eth1 };
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # ESTABLISHED 세션 → flowtable (SW offload)
        ct state established,related flow add @ft counter accept

        # 새 세션 허용 (테스트용 전체 허용)
        ct state new counter accept

        # INVALID 차단
        ct state invalid counter drop
    }

    # NAT (옵션: SNAT 테스트)
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "r-eth1" masquerade
    }
}
EOF

echo "=== nftables 설정 완료 ==="

# ============ 6. 성능 측정 ============

# server에서 iperf3 서버 시작
ip netns exec server iperf3 -s -D

# client에서 iperf3 테스트 (10초, TCP)
echo "=== flowtable 활성 상태 성능 ==="
ip netns exec client iperf3 -c 10.0.2.20 -t 10

# ============ 7. 오프로드 확인 ============

# conntrack 상태 확인 (router)
ip netns exec router conntrack -L
# 예상 출력:
# tcp  6 300 ESTABLISHED src=10.0.1.10 dst=10.0.2.20
#   sport=45678 dport=5201 [OFFLOAD] ...

# flowtable 엔트리 확인
ip netns exec router conntrack -L --status ASSURED
# OFFLOAD 상태가 표시되면 SW flowtable에서 처리 중

# nftables 카운터 확인
ip netns exec router nft list ruleset
# forward chain의 counter: 첫 몇 패킷만 카운트
# (나머지는 flowtable에서 바이패스)

# ============ 8. flowtable 비활성 비교 ============

# flowtable 규칙 제거
ip netns exec router nft delete rule inet ngfw_lab forward handle $(
  ip netns exec router nft -a list chain inet ngfw_lab forward | \
  grep "flow add" | awk '{print $NF}'
)

echo "=== flowtable 비활성 상태 성능 ==="
ip netns exec client iperf3 -c 10.0.2.20 -t 10

# 두 결과 비교: flowtable 활성 시 처리량 향상 확인

# ============ 정리 스크립트 ============
ip netns exec server pkill iperf3 2>/dev/null
ip netns del client
ip netns del router
ip netns del server
echo "=== Lab 1 정리 완료 ==="

Lab 2 — NFQUEUE + Suricata DPI 통합

Lab 1의 환경에 Suricata DPI 엔진을 추가하여, 새 세션은 DPI 검사를 거치고 분류 완료된 세션만 오프로드되도록 구성합니다.

# Lab 2: NFQUEUE + Suricata DPI 통합
# 사전 조건: Lab 1의 네트워크 환경 구성 완료
# Suricata 설치: apt install suricata (또는 dnf install suricata)

# ============ 1. Suricata 설정 ============
# /etc/suricata/suricata.yaml 수정 (주요 항목)

cat > /tmp/suricata-nfqueue.yaml <<'EOF'
# NFQUEUE 모드 설정
nfq:
  mode: accept          # 기본 verdict: accept (fail-open)
  repeat-mark: 1
  repeat-mask: 1
  bypass-mark: 8        # DPI 분류 완료 시 이 mark 설정
  bypass-mask: 8
  fail-open: yes        # Suricata 장애 시 트래픽 허용

# NFQUEUE 수신 설정
nfqueue:
  - queue-num: 0
    threads: 2
  - queue-num: 1
    threads: 2

# 출력: eve.json 로깅
outputs:
  - eve-log:
      enabled: yes
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - http
        - dns
        - tls
EOF

# ============ 2. nftables 규칙 (DPI 통합) ============

ip netns exec router nft -f - <<'EOF'
flush ruleset

table inet ngfw_lab2 {
    flowtable ft {
        hook ingress priority 0;
        devices = { r-eth0, r-eth1 };
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # 1. DPI 완료 + bypass mark가 있는 EST 세션 → flowtable
        ct state established meta mark & 0x08 == 0x08 \
            flow add @ft counter accept

        # 2. EST/RELATED (아직 DPI 진행 중) → 통과
        ct state established,related counter accept

        # 3. 새 세션 → NFQUEUE (Suricata DPI)
        ct state new queue num 0-1 fanout,bypass

        # 4. INVALID 차단
        ct state invalid counter drop
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "r-eth1" masquerade
    }
}
EOF

echo "=== DPI 통합 nftables 설정 완료 ==="

# ============ 3. Suricata 시작 및 테스트 ============

# Suricata를 router 네임스페이스에서 NFQUEUE 모드로 시작
ip netns exec router suricata -c /tmp/suricata-nfqueue.yaml \
  -q 0 -q 1 -D

# 잠시 대기 (초기화)
sleep 3

# ============ 4. DPI 탐지 테스트 ============

# HTTP 요청 (DPI가 HTTP로 분류해야 함)
ip netns exec server python3 -m http.server 80 &
sleep 1
ip netns exec client curl -s http://10.0.2.20/

# Suricata 로그 확인
ip netns exec router cat /var/log/suricata/eve.json | \
  python3 -m json.tool | grep -A5 "\"http\""

# conntrack 확인: bypass mark(8)가 설정되었는지 확인
ip netns exec router conntrack -L | grep mark
# mark=8 → DPI 완료, 오프로드 대상

# iperf3 성능 테스트 (DPI 후 오프로드 확인)
ip netns exec server iperf3 -s -D
ip netns exec client iperf3 -c 10.0.2.20 -t 10

# 결과: 첫 몇 패킷은 NFQUEUE 경유, 이후 flowtable 오프로드

echo "=== Lab 2 완료 ==="

Lab 3 — TC flower eSwitch HW offload (SmartNIC 필요)

#!/bin/bash
# Lab 3: TC flower eSwitch HW offload
# 사전 조건: SmartNIC (CX-5+/E810), SR-IOV VF 생성됨

NIC="enp4s0f0"  # PF 이름 (환경에 맞게 변경)
PCI="0000:04:00.0"  # PCI 주소

# ============ 1. eSwitch switchdev 전환 ============

# 현재 모드 확인
devlink dev eswitch show pci/$PCI

# VF unbind
for vf in /sys/bus/pci/devices/$PCI/virtfn*; do
    pci_addr=$(basename $(readlink $vf))
    echo $pci_addr > /sys/bus/pci/drivers/mlx5_core/unbind 2>/dev/null || true
done

# switchdev 모드 전환
devlink dev eswitch set pci/$PCI mode switchdev

# VF rebind
for vf in /sys/bus/pci/devices/$PCI/virtfn*; do
    pci_addr=$(basename $(readlink $vf))
    echo $pci_addr > /sys/bus/pci/drivers/mlx5_core/bind 2>/dev/null || true
done

# TC HW offload 활성화
ethtool -K $NIC hw-tc-offload on

echo "=== eSwitch switchdev 전환 완료 ==="

# VF representor 확인
ip link show | grep "${NIC}v"

# ============ 2. TC flower ct 규칙 설치 ============

VF_REP="${NIC}v0"  # VF0 representor

# 기존 규칙 초기화
tc qdisc del dev $VF_REP ingress 2>/dev/null || true
tc qdisc add dev $VF_REP ingress

tc qdisc del dev $NIC ingress 2>/dev/null || true
tc qdisc add dev $NIC ingress

# VF → Uplink 방향: conntrack 추적 시작
tc filter add dev $VF_REP ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

# VF → Uplink: EST 세션 → HW forward
tc filter add dev $VF_REP ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 \
  action mirred egress redirect dev $NIC

# VF → Uplink: NEW 세션 → CPU
tc filter add dev $VF_REP ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass

# Uplink → VF 방향 (동일 패턴)
tc filter add dev $NIC ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

tc filter add dev $NIC ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 \
  action mirred egress redirect dev $VF_REP

tc filter add dev $NIC ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass

echo "=== TC flower ct 규칙 설치 완료 ==="

# ============ 3. HW offload 확인 ============

# TC 규칙이 HW에 설치되었는지 확인
tc -s filter show dev $VF_REP ingress
# 출력에서 "in_hw" 플래그 확인
# in_hw in_hw_count 1 → HW에 성공적으로 설치됨

# conntrack 오프로드 확인
conntrack -L --status OFFLOAD
# [OFFLOAD] 상태의 세션 확인

# HW 카운터 확인
tc -s filter show dev $VF_REP ingress
# packets/bytes 카운터가 증가하면 HW에서 처리 중

# ethtool 통계
ethtool -S $NIC | grep -E "tx_packets|rx_packets|offload"

echo "=== Lab 3 HW offload 확인 완료 ==="

Lab 4 — XDP DDoS Pre-filter

XDP 프로그램을 작성하여 NIC 드라이버 수준에서 SYN flood 공격을 차단합니다. 이 프로그램은 nftables NGFW 파이프라인 앞에 배치됩니다.

/* xdp_synflood_filter.c — XDP SYN flood 방어 프로그램 */
/* 컴파일: clang -O2 -target bpf -c xdp_synflood_filter.c -o xdp_synflood_filter.o */

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>

#define MAX_ENTRIES  100000
#define SYN_RATE_LIMIT 100   /* 소스 IP당 초당 SYN 최대 100개 */
#define WINDOW_NS  (1000000000ULL)  /* 1초 (나노초) */

/* 소스 IP별 SYN 카운터 */
struct syn_count {
    __u64 count;           /* 윈도우 내 SYN 수 */
    __u64 window_start;    /* 현재 윈도우 시작 시간 */
};

struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, MAX_ENTRIES);
    __type(key, __be32);            /* 소스 IP */
    __type(value, struct syn_count);
} syn_rate_map SEC(".maps");

/* IP 차단 리스트 (관리자가 bpftool로 추가) */
struct {
    __uint(type, BPF_MAP_TYPE_LPM_TRIE);
    __uint(max_entries, 10000);
    __uint(map_flags, BPF_F_NO_PREALLOC);
    __type(key, struct lpm_key);
    __type(value, __u32);           /* 1=block */
} blocklist SEC(".maps");

/* 통계 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 3);  /* 0:pass, 1:drop_rate, 2:drop_block */
    __type(key, __u32);
    __type(value, __u64);
} xdp_stats SEC(".maps");

struct lpm_key {
    __u32 prefixlen;
    __be32 addr;
};

SEC("xdp")
int xdp_syn_filter(struct xdp_md *ctx)
{
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    struct ethhdr *eth = data;
    struct iphdr *iph;
    struct tcphdr *tcph;
    __u32 stat_key;
    __u64 *stat_val;

    /* 경계 검사 */
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    if (eth->h_proto != bpf_htons(ETH_P_IP))
        return XDP_PASS;

    iph = (struct iphdr *)(eth + 1);
    if ((void *)(iph + 1) > data_end)
        return XDP_PASS;

    /* 1. IP 차단 리스트 확인 */
    struct lpm_key lpm = {
        .prefixlen = 32,
        .addr = iph->saddr,
    };
    if (bpf_map_lookup_elem(&blocklist, &lpm)) {
        stat_key = 2;
        stat_val = bpf_map_lookup_elem(&xdp_stats, &stat_key);
        if (stat_val) (*stat_val)++;
        return XDP_DROP;
    }

    /* TCP SYN만 rate limit */
    if (iph->protocol != IPPROTO_TCP)
        goto pass;

    tcph = (struct tcphdr *)((void *)iph + (iph->ihl * 4));
    if ((void *)(tcph + 1) > data_end)
        goto pass;

    /* SYN 패킷만 필터링 (SYN=1, ACK=0) */
    if (!(tcph->syn && !tcph->ack))
        goto pass;

    /* 2. SYN rate limiting */
    __u64 now = bpf_ktime_get_ns();
    struct syn_count *sc;

    sc = bpf_map_lookup_elem(&syn_rate_map, &iph->saddr);
    if (sc) {
        if (now - sc->window_start > WINDOW_NS) {
            /* 새 윈도우 시작 */
            sc->count = 1;
            sc->window_start = now;
        } else {
            sc->count++;
            if (sc->count > SYN_RATE_LIMIT) {
                /* rate limit 초과 → DROP */
                stat_key = 1;
                stat_val = bpf_map_lookup_elem(&xdp_stats, &stat_key);
                if (stat_val) (*stat_val)++;
                return XDP_DROP;
            }
        }
    } else {
        struct syn_count new_sc = {
            .count = 1,
            .window_start = now,
        };
        bpf_map_update_elem(&syn_rate_map, &iph->saddr, &new_sc, BPF_ANY);
    }

pass:
    stat_key = 0;
    stat_val = bpf_map_lookup_elem(&xdp_stats, &stat_key);
    if (stat_val) (*stat_val)++;
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

# ============ XDP 프로그램 로드 및 테스트 ============

# 1. 컴파일
clang -O2 -g -target bpf \
  -I /usr/include/$(uname -m)-linux-gnu \
  -c xdp_synflood_filter.c -o xdp_synflood_filter.o

# 2. XDP 프로그램 로드 (generic 모드: 모든 NIC 지원)
ip netns exec router \
  ip link set dev r-eth0 xdpgeneric obj xdp_synflood_filter.o sec xdp

# 확인
ip netns exec router ip link show r-eth0
# → "xdpgeneric ... prog/xdp" 표시

# 3. SYN flood 테스트 (hping3 사용)
# hping3 설치: apt install hping3
ip netns exec client hping3 -S -p 80 --flood 10.0.2.20 &
FLOOD_PID=$!
sleep 5
kill $FLOOD_PID

# 4. XDP 통계 확인
ip netns exec router bpftool map dump name xdp_stats
# key: 0 (pass), 1 (drop_rate), 2 (drop_block)
# drop_rate 카운터가 증가했으면 rate limiting 작동

# 5. IP 차단 리스트에 추가 (bpftool 사용)
# bpftool map update name blocklist \
#   key hex 20 00 00 00 0a 00 01 0a \
#   value hex 01 00 00 00
# → 10.0.1.10/32 차단

# 6. XDP 프로그램 제거
ip netns exec router ip link set dev r-eth0 xdpgeneric off

echo "=== Lab 4 완료 ==="

참고자료

커널 공식 문서

• Linux Kernel: nf_flowtable 공식 문서 — flowtable 아키텍처, SW/HW 오프로드 메커니즘
• Linux Kernel: switchdev 프레임워크 — eSwitch 모드, FDB 오프로드 API
• Linux Kernel: TC conntrack action 사용법 — TC flower ct action으로 HW CT offload
• Linux Kernel: XFRM Device Offload — IPSec HW offload API (crypto/packet/full mode)
• Linux Kernel: BPF/XDP 문서 — XDP 프로그램 작성, 맵 타입, HW offload

벤더 기술 문서

• NVIDIA MLNX_OFED: Connection Tracking Offload — ConnectX-6/7 CT offload 설정 가이드
• NVIDIA BlueField: TC Flower Offload — BlueField DPU TC flower 규칙 HW offload
• Intel ICE Driver (E810) — E810 eSwitch switchdev 모드 지원 드라이버

DPI/IPS 엔진

• Suricata: NFQUEUE IPS 모드 설정 — Suricata + NFQUEUE inline IPS 구성
• Suricata: 성능 튜닝 가이드 — 멀티스레드, 워커 모드, 메모리 최적화
• nDPI: 오픈소스 DPI 라이브러리 — L7 프로토콜 식별, eBPF 연동

표준/벤치마크

• RFC 9411: Benchmarking Methodology for Network Security Device Performance — NGFW 벤치마크 표준 방법론
• RFC 3511: Benchmarking Methodology for Firewall Performance — 전통 방화벽 벤치마크 (RFC 9411의 기반)
• TRex Traffic Generator — CPS/CC/처리량 측정용 오픈소스 트래픽 생성기

고가용성/운영

• conntrack-tools (conntrackd) 공식 사이트 — HA 세션 동기화, FTFW/NOTRACK 모드
• nftables Wiki — nftables 규칙 작성, flowtable 설정, 예제