1. 멀티 세션
DPI 센서 설계에서 가장 간과하기 쉬운 부분은 멀티 세션 처리가 아닐까.. 흔한 예를 들면 FTP 커맨드와 데이터 세션의 관계를 생각해도 되고, 메신저와 P2P 파일 전송이라거나, HTTP의 경우 이번처럼 난데없이 나타나서 곤란하게 하고 있는 Ranges 헤더와 206 Partial Content 응답을 들 수 있겠다. 이건 뭐.. 물론 지금도 난독화된 자바스크립트 때문에 탐지가 개판인건 마찬가지이지만 저런 Ranges 헤더까지 클라이언트가 이용할 경우 제대로 탐지할 수 있는 네트워크 보안 장비가 과연 얼마나 있을까 하는 의문이 든다. 여기에 우리처럼 세션 덤프까지 겹치면 아주 귀찮은 이슈가 된다. IPv4/IPv6 듀얼스택 때문에 IPv4와 IPv6 세션이 연관되는 골치 아픈 케이스도 곧 나오지 않을까? IP 터널까지 끼면.. 응?2. 자동 프로토콜 식별
고전적인 방법으로는 목적지 포트 기준으로 매핑하거나 사람이 룰을 걸어서 매핑하지만 이런 방식은 너무나 한계가 명백하고, 초기 패킷 데이터를 보고 프로토콜을 찍어야 되는데 사실 백도어 류까지 포함하면 프로토콜이 한 두 개도 아니고 개발자가 수많은 경우의 수를 다루는 것은 어려움이 많을 것인데.. PCAP 덤프 잘 모아놓고 분류를 해놓은 다음 학습시켜서 Decision Tree 코드를 자동 생성하게 한다면 쓸만한 결과를 얻을 수 있지 않을까 뭐 그런 생각만 하고 있다..
3. 장시간 유지되는 세션 식별
일반적으로는 TCP 핸드쉐이크를 보고 세션 테이블에 상태를 집어넣게 되는데, 센서가 올라오기 전에 접속이 이루어졌다거나, 굉장히 오래 간간히 지속되는 연결의 경우 인지가 안 된다. 대충 왔다갔다 하는거 보고 핸드쉐이크 있었다치고 만든다고 한다면 고의로 에러 패킷 살짝 흘려주는 것만으로도 무수히 많은 가짜 세션이 만들어져서 세션 테이블 아작낼 수도 있을테고 쉽게 생각할 수 없는 문제다. 그리고 세션 중간에 껴들어서 L7 디코더를 동기화 하는 것도 역시 쉽지 않다.
4. 정규표현식 지원 여부
exact match 방식만을 지원한다면 Aho-Corasick 유한상태기계의 마지막 상태만을 기억하는 것만으로도 충분하기 때문에 버퍼링할 필요도 없고 아무리 룰을 많이 걸어도 메모리나 성능적인 면에서 별다른 저하가 일어나지 않는다. 그리고 정규표현식보다 정교한 디코더와 필드 매칭 방식이 훨씬 정확도가 높은데도 불구하고.. snort처럼 디코더보다 정규표현식의 유연성에 주로 의존하는 방식에 다들 길들여져서 센서가 정규표현식을 지원하지 않으면 별로 안 좋아한다.
아무래도 시간에 쫓기는 상황에서 디코더 개발은 개발자 지원이 붙어야 되지만 정규표현식 패턴은 그런 것 없이도 당장 모니터링 요원이 패턴을 만들어 우겨넣을 수 있기 때문이라 본다. 지금도 차기 개발에서 이걸 지원해야 되나 말아야 되나 고민하고 있는데.. Aㅏ..
요새 생각하는 것 위주로 썼지만 나중에 혹 떠오르는게 있으면 또..
홈형이 오늘 더미 허브 -> 스위칭 허브로 말린 센서 업글한 기념으로 끄적거려봤음..
덧글