FreeBSD 5.x 용 OpenBSD pf 포트 FreeBSD 5.x 용 OpenBSD pf 포트
OpenBSD pf
pf는 OpenBSD의 packet filter로서 ipfilter의 license 문제가 제기 되었을때 OpeBSD진영에서는
이를 수용하지 않고 독자적인 packet filter를 만든데서 유래합니다.(ipf.c)
초창기의 pf는 ipfilter와 거의 비슷한 기능을 지원했지만 지금은 많은 부분이 다르고 state modulation,
SYN proxy등 고가의 상용 방화벽에서도 보기 어려운 다양한 기능을 제공합니다.
FreeBSD 5.x용
pf 홈페이지
메인 홈페이지는 독일에서 영문으로 운영되고 있습니다. 설치 방법과 주의사항, 메일링 리스트등은 메인 홈페이지를 참조하기
바랍니다.(OpenBSD pf
ported to FreeBSD 5.0/5.1)
OpenBSD pf와
FreeBSD pf와의 차이점
ALTQ를
포함한 거의 모든 기능이 동일합니다. 두 OS간의 차이로 극복할 수 없는 부분이 있긴 하지만 이 부분도 커널을 수정할 수 있다면
가능합니다. 가장 큰 차이점은 FreeBSD에서 실행되는 pf는 kernel에 module의 형태로 로드되고, SMP와
multiple kernel threads를 지원한다는 점 입니다.
pf 성능
별도의 성능시험을 하지는 않았지만 ipfw와 ipfilter에 비하여 결코 느리지 않다고
생각합니다. stateful inspection을 사용하여 생성된 방화벽 룰이 있는지 검사할때 ipfw는 hash,
ipfilter는 B-tree, pf는 RB(red-black) tree(balacned tree, AVL을 생각하시면
됩니다.)를 사용합니다. hash의 경우는 hash bucket에 의해서 성능이 좌우되며, 수만 ~ 수십만개의 state가
생기면 hash collision이 발생하여 효율이 급격히 떨어집니다. stateful inspection에서 성능에 가장
영향을 많이 받는 부분이 state정보를 저장할 메모리의 할당과
해제입니다. ipfw와 ipfilter는 전통적인 malloc(9)을 사용하지만 OpenBSD의 pf는 pool(9)을
FreeBSD에서는 zone(9)을 사용합니다. zone(9)은 할당할 메모리의 크기가 동적이지 않을때 malloc(9)보다
효율적이고 보다 빠른것으로 알려져있습니다. 물론 stateful inspection에서는 속도 뿐 아니라 이용 가능한 모든
메모리를 각각의 state정보를 저장하는데 다 소진하였을 경우, 새로운 SYN request에 대한 처리방식도 중요합니다.
ipfw와 ipfilter는 이런 극단적인 상황이 왔을 때 대처할 수 있는 방법이 굉장히 제한적입니다.(사실 할 수 있는게 별로
없습니다. down되지 않기를 바라는 수 밖에는...) 제가 극단적이라는 표현을 사용했습니다만 악의적인 공격자는 여러 프로그램을
이용해서 손쉽게 이런 상황을 유발하게 할 수 있습니다.
pf는 hardware check-sum offload를 지원하기 때문에 고성능의 Gigabit Ethernet
Card를 효율적으로 지원합니다. 하드웨어 시험장비가 있으신 분들은 같은 룰셋으로 방화벽을 설정한 후 시험결과를 알려주시면
project에 큰 도움이 될 것입니다.
pf highlights
FreeBSD 버젼별 지원 상황
| |
|
 |
 |