|
'/BOT' ProjectCCS//BOT Poject 2009. 9. 3. 12:49한 달동안 포스팅을 못하고 다시 쓰게 됩니다. Traffic Analysis System _ Ver 1.0프로그래밍/패킷 캡쳐 2009. 7. 3. 00:20그나저나... 워드에 있던 글이 그림 빼곤 복사가 다 되네요...편리해서 좋군요!
서론 Network Traffic Monitoring은 안정적이고, 효과적인 관리를 위해 필수적인 서비스입니다. 그런 까닭에, 모니터링은 비 이상적인 혹은 원치 않은 traffic을 발견하고 그것을 제제할 수 있는 메커니즘이 필요합니다. 모니터링을 관리하는 관리자는 엔터프라이즈 네트워크를 관리하는 관리자가 될 수 있고, 개인 사용자가 될 수 있습니다. 그러나 인력에 의한 모니터링은 시간적으로나 정확도면에서나 한계가 있습니다. 이 글에서는 자동으로 모니터링을 위한 시스템 Traffic Analysis System(TAS)를 제안하고자 합니다. TAS의 기본 모티브는 process별로 특정한 알고리즘을 이용하여 빈도수가 높은 문자 혹은 값을 추출하여 traffic을 특정한 process로 정의하는 것 입니다. 이렇게 추출된 문자 혹은 값을 Signature라 정의하고, 이것은 traffic을 process별로 구분하는데 사용됩니다. 더 나아가 process별로 특정 Signature들이 정의가 되면 Router에서 원치 않은 프로세스의 기능을 차단하는 것을 목적으로 하고 있습니다. 본론  그림. TAS의 전체적인 시스템 구성도 TAS는 총 4단계의 구성을 갖고 있으며, 3개의 Module로 나뉠 수 있습니다. 4단계의 구성은 데이터 수집, 데이터 저장, 정답지 생성, 결과 보고로 나뉠 수 있으며, 데이터 저장 ~ 결과 보고는 Phase 1 ~ Phase 3으로 정의 하였습니다. 데이터 수집에서는 네트워크 카드로 들어 오는 Packet을 획득하는 부분입니다. 현재 버전에서의 Packet 수집 룰은 TCP, Local IP를 갖는 Packet으로 정의 하였습니다. 획득한 Packet은 Flow단위(Source IP, Source Port, Destination IP, Destination Port, Protocol이 같은 Packet묶음)로 분류되게 됩니다. 데이터 저장에서는 Flow Table의 상태 혹은 packet의 옵션을 통해 등록, 삭제 등의 작업이 수행되며, 이 과정을 통해 process별로 파일에 쓰여지게 됩니다. 정답지 생성에서는 파일로 쓰여진 데이터들을 읽어 들여 Signature Table을 만들게 됩니다. 현재 사용하는 Signature 생성 룰은 “packet의 첫 4byte” 전략을 사용하고 있으며 이를 보충하기 위해 “History”라는 메커니즘도 같이 사용하고 있습니다.  그림. TAS의 전체적인 시스템 흐름도 전체적인 시스템의 구성도를 흐름도로 바꾼 형태 입니다. 각 각의 색으로 3 가지의 Module을 구분하였습니다. 녹색은 Phase1, 갈색은 Phase 2, 파란색은 Phase 3을 의미합니다. 아직 내용이 유동적인 부분이 없진 않지만 큰 틀은 여기에서 변하지 않을 거라 생각합니다. 흐름도로 전체적인 시스템을 보면 Flow Table, Signature Table, History Table 의 3 가지 Storage가 존재합니다. Flow Table은 5-tuple(Source IP, Source Port, Destination IP, Destination Port, Protocol)이 같은 Packet 들을 저장하고, Signature Table은 Phase 1에서 파일에 쓰여진 정보를 특정한 알고리즘에 의해 추출된 내용을 저장하고, History Table은 유동적으로 변하는 Server의 IP, Port를 유동적으로 대처하고자 만든 Storage로써, “짧은 시간 내의 같은 Flow에서 발생한 Packet은 동일한 Process에서 발생한 Packet일 것이다” 라는 가정을 갖고 Signature Table의 부족한 부분을 보충하기 위해 통신하는 Server 의 IP, Port를 저장하고 있습니다.  그림. Phase 1의 흐름도 Phase 1의 목적은 획득한 Packet을 의미가 있는 단위(Flow)로 묶는 것 입니다. 현재는 TCP기준으로 테스트를 하고 있으며, 다음과 같이 TCP Flags값을 기준으로 Packet이 처리 되게 됩니다. 이 시스템에서는 획득하는 Packet은, TCP로 통신하는 프로세스의 경우 3-handshake로 연결을 맺고, FIN or RST으로 끝나는 것을 전재로 하고 있습니다. 위의 4가지 flag외의 조합이 생길 수 있기 때문에 다음과 같은 식으로 제외 하였습니다.
 그림. Phase 1에서 제외될 TCP Offset condition(s) SYN의 경우 연결의 처음을 의미하므로 TCP Flow Table의 Head를 생성하게 됩니다. ACK의 경우 데이터의 전송을 의미하므로 TCP Flow Table의 Tail을 생성(or 추가)하게 됩니다. 이때 Head에 연결된 Tail 개수가 10개를 넘게 되면 파일에 쓰게 됩니다. RST의 경우 비 정상적인 종료를 의미하므로 해당 node를 파일에 쓰지 않고 삭제합니다. FIN의 경우 정상적인 종료를 의미하므로 해당 node를 파일에 쓰고 삭제합니다.  그림. Phase 2의 흐름도 Phase 2은 TCP Flow Table에 의해 저장된 파일들을 읽고, process별로 Signature Table을 구성하는 것이 목적입니다. 구성된 Signature Table은 동적으로 발생되는 traffic을 구분하기 역할을 하게 됩니다. 그러므로 시스템의 더 높은 정확성을 위한다면 Phase 1의 Output File이 많이 있어야 합니다.  그림. Phase 3의 흐름도 Phase 3은 파일에 저장된 데이터를 Signature Table에 모두 올립니다. Packet이 잡히면, 메모리에 올라온 Signature Table과 비교하여 결과를 화면에 출력합니다. Signature Table의 matching결과는 Traffic List Control의 Row 색상을 보고 알 수 있습니다.
 - 하얀색: Packet의 데이터 길이가 0 인 경우 - 빨간색: TAS가 A 프로세스라고 분석했지만 Sig Table에는 해당 Signature가 존재 하지 않는 경우 - 녹색: TAS가 A 프로세스라고 분석했지만 Sig Table은 B 프로세스 라고 분석하는 경우 - 파란색: TAS가 A 프로세스라고 분석하고 Sig Table도 역시 A 프로세스라고 분석하는 경우 - 검은색: TAS가 Unknown 으로 분석했지만 Sig Table로 X Process라고 분석한 경우
결론 실험 내용 ( 2009.07.02 )  조금 인터페이스가 바뀌었습니다 :) 정답률이 많이 올라가신것을 볼 수 잇죠!!!!! 왼쪽 에러 메시지가 아직 부족한것이 잇다고 계속 일깨워 주네요 ㅠㅠ  4 byte시그니처들의 모습입니다. Hit Count는 중복된 개 수 입니다. 익스플로러의 방대량 트래픽량 덕분에 많은 시그니처가 익스플로러에 겹치는 현상이 나타납니다. 이를 방지하기 위해 프로세스당 해당 시그니처의 발생 확률을 계산한뒤 중복된 시그니처가 나타나면 발생확률이 높은 쪽으로 탐지하는 방향으로 할 계획입니다. SSM 서류 지원 완료나/흥미로운 곳 2009. 6. 28. 17:19현재 하고 있는 traffic analysis system으로 samsung software membership 에 지원했습니다.
저는 이것을 2006년 부터 생각해왔고, 이제서야 실천에 옮겼습니다.  예전에 네이버 블로그 할때 있던 글입니다. 2006년 5월 16일 새벽 2시 40분 -_-;;; 안자고 뭐했을까요... 결과에 연연하지 않겟습니다. 중요한것은 제가 도전을 했다는 것 이지요. 지금 너무 행복합니다. :) 혹시 삼성소프트웨어 멤버쉽에 관심이 있으신분은 아래 링크를 따라 가세요 여기를 클릭하세요! |
