PF_RING 과 Snort의 간단한 리뷰(Review)

Snort®는 소스파이어에서 개발되고 있는 오픈 소스 네트워크 침입 방지/탐지 시스템(NIPS/NIDS)이다. 시그니처(signature), 프로토콜(protocol), 비정상탐지(anomaly-based inspection)을 조합한  스노트는 전세계적으로 가장 넓게 사용되고 있는 IDS/IPS 기술이다. 수백만 다운로드와 약 40만명의 등록된 사용자들과 함께, Snort는 IPS의 사실상 표준이다.

각설하고,...

...

Luca Deri의 페이퍼 "Improving Passive Packet Capture: Beyond Device Polling"에서 소개된 NAPI, PF_RING은 기존 libpcap의 성능을 1)NAPI를 사용(device polling)하고, 2) winpcap처럼 ring 버퍼를 사용하여 개선한 버전이다. 그리고, 아예 이를 프로토콜 패밀리(PF, Protocol Family)로 등재하고자(?)하는 마음으로 PF_RING이름의 프로토콜 패밀리를 가지도록 하는 커널 패치를 만든다. 초기에는 특정 장치(NIC)에 PF_RING을 사용하면 독점적으로 열리므로, 다른 프로그램이 오픈할 경우, 깨지는 현상이 발생했었으나, 패치되었다.

이후, Amitava Biswas는 "A High Performance Real-time Packet Capturing Architecture for Network Management Systems"란 2005년 master thesis에서 DMA_RING을 제안한다. 

이후, Luca Deri는 PF_RING을 꾸준히 업그레이드하여, 10G H/W packet filtering, DNA, libzero for DNA등을 사용할 수 있도록 개선하였다.  현재(2013.03.05), PF_RING은 DNA, TNAPI, HW packet filtering, Libzero for DNA, Virtual PF_RING등을 지원하고 있다.

Luca Deri는 이러한 기반 기술하에서, 몇가지 응용(n2disk, nBox, nProbe, ntop, nDPI, n2n)을 만들었다.

이상 간략하게 PF_RING에 대하여 히스토리를 살펴 보고, 대충 팔로우-업 했다.

 그런데, 오늘의 주 관심사는 Snort이므로, PF_RING기반 Snort를 시중에서 구할 수 있는 기성 시스템 중에서 멀티코아를 가지는 시스템, 즉, 쉽게 구하고, 널리 사용되는 시스템에 설치하여 성능을 알아본  페이퍼를 살펴보았다. 

문서의 제목은 : "Inline Snort multiprocessing with PF_RING" 으로 다음 링크에서 찾아볼 수 있다.

http://www.snort.org/assets/186/PF_RING_Snort_Inline_Instructions.pdf

이 페이퍼를 선정한 이유는 없고, 그냥 리뷰하다가 예전과 어느 정도 발전했나를 follow-up하기 위함이다.

요지는 다음과 같다.

'PF_RING을 사용하여 IP패킷헤더의 ip주소로 로드밸런싱한 패킷(즉, 트래픽)을 다중 스노트가 탐지처리하게 한 후 성능을 살펴 보는 것이다.' 

사용된 하드웨어

ntel(R) Core(TM) i7 CPU 950 @ 3.07GHz, Dual Intel e1000e, 4 Gig RAM 

PF_RING e1000e driver, transparent_mode=1 

Operating System: Linux (CentOS preferred) 

사용한 룰 (1)

Emerging Threats Rules(http://www.emergingthreats.net/)로서 Emerging Threats ETPro™ Ruleset is the only platform independent ruleset that runs on Suricata, SNORT®, and others - providing comprehensive security, no matter what platform you use.

패킷 전송량이 증가할떄(가로축), 패킷 전달(forward) 비율을 보면 멀티코어가 유리함을 보이고 있다. 표로 보면 보다 명확히 알게 될 것이다.

그림에서 보는 바와 같이(표가 페이지를 넘어가게 되어 있어서 캡쳐가 이상타 ^^) 1 core는 100Mbit/s 수준이며, PF_RING inline 및 멀티코어(multi-cores)로 병렬화하면, 700 Mbit/s까지 달성 가능함을 알 수 있다. 200 microseconds의 응답시간(latency)를 가진다.

사용한 룰(2)

http://www.snort.org/snort-rules/을 사용한 경우도 테스트 해 보았다.

그래프에서 보는 바와 같이 PF_RING을 사용하면, VRT룰을 사용하는 경우에도 성능이 향상된다는 것이다.

** 주의: 성능은 사용한 '룰의 type 및 개수'와 테스트/실전 '트래픽의 type'에 아주 심하게 영향을 받는다는 것을 기억하도록 한다.

결론

1) PF_RING DNA를 사용하면 패킷레벨 처리하는 응용에서 고성능이 기대된다. 

2)분석을 행하는 snort와 같은 응용에서는 멀티코어로 처리하여 병렬성을 높이면 유리하다. 

3) 설치하는 부분은 생략함(요원하기는 하지만, 시간 나면 한번 해보기로 함)

토의

2004년(?)에 만들었던 것에 대한 기억을 잠시 더듬어 보니, snort rule을 classify하여 'rule의 type 및 개수'로 분류하여 로드 밸런싱하도록 준비하고, Netfilter IPQ를 멀티플렉싱하고 스노트(분류된 룰 개수)를 병렬(fork)로 수행하도록 만들었던 것과 비교하면, 

1) rule의 type 및 개수로 분류(로드밸런싱 위해)한 2004년 프로젝트의 장점

1-1) snort rule의 정규화 

snort rule은 최초 체계적으로 만들어지지 않아서, 필요할 때마다, 주먹구구식으로 신택스를 확장하는 구조로 만들어져서, parser 제작할 때 애를 먹었던 기억이 난다. 이를 정리하여 XML로 정규화하여 출력하고, rule을 다시 쓰도록 하고, rule type 및 개별로 성능 테스트 및 정리하여 보다 정교한 룰의 분류로 사용하는 것을 계획하였으나,  개별 테스트하기에는 시간과 당시 장비가 너~무 부족했던 기억이 난다. 

2) netfilter ipq보다 우수한 성능으로 간주되는, pf_ring의 장점

이 둘 다를 겸비하면 더 좋은 제품이 나오지 않을까? 한다.

3) 10G또는 그 이상? 로드밸런싱, NPU...