보통 F/W은 L3/L4만을 검사합니다.
TCP/IP기준으로 IP와 TCP(UDP) 헤더 만을 본다고 해도 되겠지요.
이 부분만을 보고 패킷을 전달해주거나, drop시키거나 함으로써 그 기능이 완성됩니다.
그런데, 님다, 코드레드등 보다 많은(?!) 유해트래픽은 이러한 헤더정보만으로는 검출할 수 없습니다.
소위 패킷의 payload부분을 봐야 했던것이지요.
패킷 = 헤더 + 데이터(payload)
라고 할때, 헤더만으로는 안되고, 데이터까지 봐야한다는....
즉, 깊게 봐야한다는 것이지요.
이러한 원리에서 네트워크 기반 IDS가 나오게 됩니다.(호스트 기반 IDS도 있습니다만)
그래서, 좀,..., 했는데.
다음 두 문제가 대두됩니다.
1) IP fragmentation
2) TCP reassembly
TCP/IP는 기본적으로 IP레이어 밑단, 즉, 피지컬레이어에 제약없도록 설계되었습니다.
그러자니, 하부구조로 ethernet, FDDI, ATM, PPP등 그 MTU사이즈가 다양한 것을 모두 감당하도록 프로토콜 스택을 구현해야 합니다. (이미 운영체제들이 내장하고 있는 프로토콜스택에서는 이를 하고 있다는...)
이때, IP 레이어에서 프레그멘테이션(fragmentation)을 수행해서, 해당 미디어에 맞게 패킷을 자르거나 붙여서 전송하는 역할을 수행합니다.
좋은 얘기인데, 검출하는 입장에서는 프레그멘테이션이 부담입니다.
이를 테면, "i love you" 라는 패턴을 유해 트래픽으로 간주하는데,
"i love" , " you"가 각각 다른 패킷으로 날라가게되면, 문제가 되지요.
그래서 IP fragmentation이 필요하며,
IP는 순서보장을 못하는 관계로, " you", " i love"순으로 패킷이 올수도 있습니다.
그래서 tcp reassembly를 수행해야 했던것이지요. 물론 재전송등등 tcp는 좀더 복잡하지요.
정리하자면, TCP인 경우(TCP가 트래픽의 대부분 맞지요?!)
패킷의 프레그멘테이션에 대한 처리 ==> 패킷의 스트림화 ==> 검사
이런 시나리오로 동작해야 했습니다.
이때, false positive는 유해트래픽이 아닌데(지극히, 정상인데..) 유해트래픽이라는 보고를 하는 경우입니다.
뭐 몇개 정도야 감수하겠지만, 수백, 수천, 수만개를 IDS가 오탐해서 보고하면 관리자 수명이 짧아집니다.
그래서, 관리자가 장수하기 위해 오탐을 줄이기를 원합니다. :twisted:
반면, 유해 트래픽인데, 나 몰라라 하고 그냥 통과시키면, 경계근무 소홀로 문제가 됩니다.(false negative)
그래서 여기까지 ...했더니, 소잃고 외양간 고친다라는 얘기가 나오더라 이겁니다.
검사하?보고(그래프, 이메일, sms, 사이렌..)했더니, 이미 바이러스감염 또는 공격받았음...쿵~.
그래서, IDS말고 IPS가 대두되게됩니다.
검출만 말고, 실시간에 막아라! 지요.
그랬는데, 이 모든 절차를 실시간에 하기를 원하더라! 이겁니다.
성능개선 및 오탐에 대한 대처가 이 분야의 화두라고 생각됩니다.
연구소/비영리/영리추구법인등에서 다양한 방법론을 사용해서
이를 극복하고자 하고 있습니다. 뭐가 정답인지는 별관심없고, 저도 잘 모르지만, 하여간 이쪽 분야 하는 사람들이 나름대로 노력하고
있는 것으로 알고 있습니다.
또한, 무엇이 유해트래픽인가? 라는 부분에 대한 연구도
중요합니다. 이쪽도 단순 패턴에 기반한 트래픽분석에서 부터 rule, behavior기반에 이르기까지 다양한 접근이 있습니다.
음 얘기가 쓸데없이 길어져서, 질문으로 다시 돌아가면,
Deep Stream Inspection
이걸하려면,
1) 패킷을 어떻게 잡을것인가?(IDS인경우)/어떻게 차단할것인가?(IPS인경우 둘다 고려)
2) IP fragmentation 처리?
3) TCP reassembly?
4) string match? <======= 제가 보기에 이게 deep stream inspection에서는 키포인트군요.
5) 총체적인 검출/방지 엔진?
* 질문하신 분이 전혀 문외한 같지는 않고, 차분히 공부해보시고 좋은 프로그램 만드시길 바랍니다.
보통 F/W은 L3/L4만을 검사합니다. TCP/IP기준으로 [b]I
보통 F/W은 L3/L4만을 검사합니다.
TCP/IP기준으로 IP와 TCP(UDP) 헤더 만을 본다고 해도 되겠지요.
이 부분만을 보고 패킷을 전달해주거나, drop시키거나 함으로써 그 기능이 완성됩니다.
그런데, 님다, 코드레드등 보다 많은(?!) 유해트래픽은 이러한 헤더정보만으로는 검출할 수 없습니다.
소위 패킷의 payload부분을 봐야 했던것이지요.
패킷 = 헤더 + 데이터(payload)
라고 할때, 헤더만으로는 안되고, 데이터까지 봐야한다는....
즉, 깊게 봐야한다는 것이지요.
이러한 원리에서 네트워크 기반 IDS가 나오게 됩니다.(호스트 기반 IDS도 있습니다만)
그래서, 좀,..., 했는데.
다음 두 문제가 대두됩니다.
1) IP fragmentation
2) TCP reassembly
TCP/IP는 기본적으로 IP레이어 밑단, 즉, 피지컬레이어에 제약없도록 설계되었습니다.
그러자니, 하부구조로 ethernet, FDDI, ATM, PPP등 그 MTU사이즈가 다양한 것을 모두 감당하도록 프로토콜 스택을 구현해야 합니다. (이미 운영체제들이 내장하고 있는 프로토콜스택에서는 이를 하고 있다는...)
이때, IP 레이어에서 프레그멘테이션(fragmentation)을 수행해서, 해당 미디어에 맞게 패킷을 자르거나 붙여서 전송하는 역할을 수행합니다.
좋은 얘기인데, 검출하는 입장에서는 프레그멘테이션이 부담입니다.
이를 테면, "i love you" 라는 패턴을 유해 트래픽으로 간주하는데,
"i love" , " you"가 각각 다른 패킷으로 날라가게되면, 문제가 되지요.
그래서 IP fragmentation이 필요하며,
IP는 순서보장을 못하는 관계로, " you", " i love"순으로 패킷이 올수도 있습니다.
그래서 tcp reassembly를 수행해야 했던것이지요. 물론 재전송등등 tcp는 좀더 복잡하지요.
정리하자면, TCP인 경우(TCP가 트래픽의 대부분 맞지요?!)
패킷의 프레그멘테이션에 대한 처리 ==> 패킷의 스트림화 ==> 검사
이런 시나리오로 동작해야 했습니다.
이때, false positive는 유해트래픽이 아닌데(지극히, 정상인데..) 유해트래픽이라는 보고를 하는 경우입니다.
뭐 몇개 정도야 감수하겠지만, 수백, 수천, 수만개를 IDS가 오탐해서 보고하면 관리자 수명이 짧아집니다.
그래서, 관리자가 장수하기 위해 오탐을 줄이기를 원합니다. :twisted:
반면, 유해 트래픽인데, 나 몰라라 하고 그냥 통과시키면, 경계근무 소홀로 문제가 됩니다.(false negative)
그래서 여기까지 ...했더니, 소잃고 외양간 고친다라는 얘기가 나오더라 이겁니다.
검사하?보고(그래프, 이메일, sms, 사이렌..)했더니, 이미 바이러스감염 또는 공격받았음...쿵~.
그래서, IDS말고 IPS가 대두되게됩니다.
검출만 말고, 실시간에 막아라! 지요.
그랬는데, 이 모든 절차를 실시간에 하기를 원하더라! 이겁니다.
성능개선 및 오탐에 대한 대처가 이 분야의 화두라고 생각됩니다.
연구소/비영리/영리추구법인등에서 다양한 방법론을 사용해서
이를 극복하고자 하고 있습니다. 뭐가 정답인지는 별관심없고, 저도 잘 모르지만, 하여간 이쪽 분야 하는 사람들이 나름대로 노력하고
있는 것으로 알고 있습니다.
또한, 무엇이 유해트래픽인가? 라는 부분에 대한 연구도
중요합니다. 이쪽도 단순 패턴에 기반한 트래픽분석에서 부터 rule, behavior기반에 이르기까지 다양한 접근이 있습니다.
음 얘기가 쓸데없이 길어져서, 질문으로 다시 돌아가면,
Deep Stream Inspection
이걸하려면,
1) 패킷을 어떻게 잡을것인가?(IDS인경우)/어떻게 차단할것인가?(IPS인경우 둘다 고려)
2) IP fragmentation 처리?
3) TCP reassembly?
4) string match? <======= 제가 보기에 이게 deep stream inspection에서는 키포인트군요.
5) 총체적인 검출/방지 엔진?
* 질문하신 분이 전혀 문외한 같지는 않고, 차분히 공부해보시고 좋은 프로그램 만드시길 바랍니다.
* 제가 방금 읽은 페이퍼도 볼만한것 같습니다, 시간 남으면 보세요. 요지는 스트링매치를 하드웨어 써서 해봤다. 그랬더니, 좋더라정도군요.
http://www.arl.wustl.edu/~todd/hoti.pdf
* 참고만 하세요. 믿지 말고 :twisted:
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
답변 고맙습니다.
안녕하세요?
이렇게 자세히 답변을 달아주셔서 감사합니다.
모르는것이 많아 자주 질문을 올립니다.
그럼 오늘도 수고하시고 행복하세요...
댓글 달기