[분석] DDoS 환경에서 OVS kernel datapath 성능 붕괴

 

kt cloud

 

📝 요약 SUMMARY

이 글에서는 DDoS 공격 시 Open vSwitch(OVS) 커널 데이터패스에서 발생하는
Upcall Storm, Mask Explosion, 캐시 스래싱의 원인과 성능 저하 구조를 다룹니다.
eBPF/XDP 사전 필터링과 TC·하드웨어 오프로드, 운영 지표를 활용한 대응 방향을 정리합니다.

#OVS #DDoS #KernelDatapath #UpcallStorm #XDP

---

DDoS 공격 상황에서의 성능 붕괴

무작위 패턴의 DDoS 공격(예: 위조된 소스 IP 및 포트를 사용하는 SYN flooding attack)은 OVS datapath의 구조적 전제 조건을 직접적으로 타격합니다. OVS의 고성능은 트래픽의 locality에 의존하기 때문입니다. 이 locality가 깨지면 시스템은 연산 비용이 가장 높은 처리 경로로 강제 진입하게 됩니다.

Upcall Storm (Slow-Path Resource Exhaustion)

무작위 DDoS 공격에서는 일반적으로 모든 패킷이 고유한 플로우(Flow)로 인식됩니다.

• 메커니즘: 무작위로 생성된 헤더는 기존 커널 플로우와 일치하지 않으므로, 모든 패킷이 플로우 미스(Flow Miss)를 유발합니다.
• 영향: 커널은 Generic Netlink를 통해 모든 패킷에 대해 유저스페이스ovs-vswitchd로 업콜(Upcall)을 실행해야 합니다. 이 과정에서 CPU 사이클은 패킷 포워딩이 아닌 문맥 교환(Context switching), 넷링크 직렬화, 유저스페이스 파이프라인 처리에 소모됩니다.
• 결과: 처리량(Throughput)이 초당 수백만 패킷(Mpps) 단위에서 수만 단위로 급락하며, 정상적인 트래픽 처리가 불가능해지고 네트워크 노드는 응답 불능 상태에 빠집니다.

TSS Mask Explosion (Lookup Scaling Failure)

특정 공격 패턴을 차단하기 위해 OpenFlow 파이프라인에 완화 규칙을 설치하면, 커널의 와일드카드 매칭 복잡도가 증가합니다.

• 메커니즘: 매칭된 헤더 필드의 고유한 조합마다 커널의 mask_array에 새로운 항목이 필요합니다.
• 영향: TSS(Tuple Space Search)의 조회 시간 복잡도는 마스크의 개수를 N이라 할 때 $O(N)$입니다. 마스크의 개수가 늘어날수록 커널은 모든 패킷에 대해 전체 데이터패스에 걸쳐 더 많은 해싱과 메모리 비교 작업을 수행해야 합니다.
• 결과: 시스템 전체의 지연 시간(Latency)이 완화 규칙의 수에 비례하여 선형적으로 증가하며, 이는 성능 면에서 '이차적인 공격' 효과를 낳습니다.

Cache Thrashing 및 최적화 실패

무작위 공격 시 OVS의 주요 패스트 패스(Fast-path) 최적화 기능들이 무력화됩니다.

• 마스크 캐시 실패: 모든 무작위 패킷마다 하드웨어 RSS(skb_hash)가 달라지기 때문에, CPU별 mask_cache의 O(1) 성공률이 0%에 가깝게 떨어집니다.
• 재균형 작업의 과부하(Rebalancing Churn): 백그라운드의 마스크 재균형기(Rebalancer)가 끊임없이 변하는 "핫(Hot)" 마스크의 우선순위를 정하느라 CPU 사이클을 낭비하게 됩니다. 이는 지속적인 캐시 무효화와 RCU 동기화 오버헤드로 이어집니다.

성능 저하 요약 (Summary of Performance Degradation)

구분	주요 원인 (Primary Cause)	성능 영향 (Performance Impact)	결과 (Result)
처리량 (Throughput)	업콜 스톰 (Upcall Storm)	유저스페이스 전환 오버헤드 발생	Mpps 단위에서 Kpps 단위로 급감
지연 시간 (Latency)	마스크 폭발 (Mask Explosion)	TSS 조회 복잡도 증가 (O(N))	규칙 수에 따른 선형적 지연 증가
자원 효율성 (Efficiency)	캐시 스래싱 (Cache Thrashing)	최적화 실패 및 RCU 동기화 오버헤드	데이터 처리 전 CPU 자원 고갈

---

기술적 배경

위에서 기술한 성능 저하 모드를 이해하기 위해서는, 특화된 캐싱 레이어로서의 OVS 데이터패스 설계를 살펴볼 필요가 있습니다.

구현 개요

커널 데이터패스(net/openvswitch/)는 마이크로 플로우(Micro-flows)에서 발생하는 플로우 폭발 문제를 방지하기 위해, 와일드카드를 사용하여 여러 헤더 필드를 매칭하는 '메가플로우(Megaflows)' 실행에 집중합니다.

• 플로우 테이블: TSS 알고리즘을 구현하며 플로우의 생명 주기를 관리합니다.
• 플로우 키 추출: 가공되지 않은 sk_buff 구조체를 검색 가능한 sw_flow_key로 파싱합니다.
• RCU 동기화: RCU(Read-Copy Update)를 통해 테이블을 보호함으로써, 모든 CPU 코어에서 락(Lock) 없이 병렬 조회가 가능하도록 합니다.

TSS(Tuple Space Search) 알고리즘

TSS는 OVS가 완전 일치(Exact-match) 해시 테이블을 사용하면서도 와일드카드 조회를 수행할 수 있게 해줍니다.

• 마스킹(Masking): 규칙들은 해당 "마스크"(어느 필드가 와일드카드인지)에 따라 그룹화됩니다.
• 범위 최적화(Range Optimization): 비트값이 0이 아닌 마스크를 포함하는 sw_flow_key의 메모리 범위만 해싱함으로써, 단순한 L2/L3 규칙에 대한 CPU 비용을 줄입니다.
• 공유 해시 테이블(Shared Hash Table): 모든 플로우는 하나의 거대한 해시 테이블에 저장됩니다. 충돌이 발생하면 마스크 포인터와 마스킹된 키를 대조하여 검증합니다.

패킷 처리 과정 및 멀티코어 확장성

패킷이 데이터패스에 진입하면 다음과 같은 과정을 거칩니다.

• 패스트 패스 (Fast Path): 커널은 하드웨어 skb_hash로 인덱싱된 CPU별 mask_cache를 사용하여 O(1) 조회를 시도합니다.
• 슬로우 패스 (Slow Path): 캐시 미스가 발생하면, 커널은 mask_array를 선형적으로 순회하며 각 마스크를 적용하고 해시 테이블을 조사합니다.
• 병렬성 (Parallelism): RCU 및 CPU별 데이터 구조 덕분에 여러 코어가 경합 없이 동시에 TSS 조회를 수행할 수 있습니다. 통계 및 캐시는 코어별로 독립적으로 유지되어 L1/L2 캐시 국소성을 보장합니다. RCU(Read-Copy Update)를 통해 테이블을 보호함으로써, 모든 CPU 코어에서 락(Lock) 없이 병렬 조회가 가능하도록 합니다.

---

아키텍처 완화 전략

OVS kernel datapath를 성능 붕괴로부터 보호하려면, 패킷이 OVS 인그레스(Ingress) 로직에 도달하기 전인 파이프라인의 가장 초기 단계에서 완화 조치가 이루어져야 합니다.

eBPF/XDP 사전 필터링

가장 효율적인 방어책은 XDP(Express Data Path)를 사용하여 NIC 드라이버 레벨에서 악성 트래픽을 차단하는 것입니다.

• 메커니즘: XDP 후크(Hook)에 eBPF 프로그램을 부착하여, sk_buff 메모리 할당이 일어나기 전에 원시 프레임(Raw frames)을 파싱하고 고속 BPF 맵(예: 동적 차단 목록)과 대조하여 검증합니다.
• 성능: XDP 단계에서의 드롭(Drop) 처리는 메모리 할당 및 전체 TSS 엔진을 우회하므로, OVS 내부에서 드롭하는 것보다 10~20배 더 빠릅니다.

TC 인그레스(Ingress) 및 하드웨어 오프로드

• TC 필터링: 만약 XDP를 지원하지 않는 환경이라면, tc ingress 후크(cls_bpf)에 eBPF를 적용하여 OVS 특유의 조회 루프(Lookup loop)를 우회할 수 있습니다.
• 하드웨어 오프로드: NIC의 플로우 디렉터(Flow Director)나 ntuple 필터를 활용하면, CPU 자원을 전혀 사용하지 않고 실리콘(하드웨어) 레벨에서 공격 패턴을 차단할 수 있습니다.

---

모니터링 및 가시성

운영자는 데이터패스 고갈(Datapath Exhaustion) 현상을 탐지하기 위해 다음 지표들을 반드시 모니터링해야 합니다.

지표 (Metric)	CLI 명령어	공격 징후 (Indication of Attack)
TSS 효율성	ovs-dpctl show (mask_hits/lookups)	패킷당 평균 마스크 검사 수 급증 (>10.0)
튜플 복잡도	ovs-dpctl show (masks)	활성화된 와일드카드 마스크 수의 갑작스럽고 거대한 증가
데이터패스 미스	ovs-appctl dpctl/show -s (missed)	높은 미스율(Miss rate)은 업콜 스톰 발생을 의미
캐시 적중률	ovs-appctl dpctl/show -s (n_cache_hit)	무작위 엔트로피로 인해 적중률이 0%에 근접하게 급락

---

❔자주 묻는 질문 FAQ

Q upcall storm과 mask explosion 중 실제 운영 환경에서 시스템 붕괴를 유도하는 더 치명적인 요인은 무엇인가요?

A 유입되는 트래픽의 특성에 따라 ovs-vswitchd(유저스페이스)의 CPU 점유율이 먼저 치솟는지, 아니면 커널 내 TSS 룩업 오버헤드로 인한 레이턴시 증가가 먼저 발생하는지에 대한 실무적인 선행 지표를 정의하고 모니터링해야 합니다. OVS 에서 policing 기능을 사용하여 upcall rate 제한할 수 있습니다.

Q TSS 알고리즘의 O(N) 복잡도 문제를 해결하기 위해 마스크 수(N)를 제한할 경우, 서비스 가용성에 미치는 부작용은 없는가요?

A Mask Explosion을 방지하기 위해 커널 내 마스크 생성 규칙을 강제로 제한하거나 병합할 경우, 보안 정책이 지나치게 일반화 (Coarse-grained)되어 정상 트래픽까지 차단되는 오탐(False Positive) 가능성은 없는지, 이를 방지하기 위한 임계값 설정 기준이 무엇인지 확인해야합니다.

---

📚 관련 / 출처 REFERENCES

🔗

• https://www.intel.com/content/www/us/en/developer/articles/technical/ovs-dpdk-datapath-classifier.html
• https://www.intel.com/content/www/us/en/developer/articles/technical/ovs-dpdk-datapath-classifier-part-2.html

↗