패킷 스니핑을 통한 유해사이트 차단 프로그램을 만드는 중입니
제목 그대로
패킷을 캡쳐해서 분석하고
그것이 유해사이트이면 차단하는 프로그램을 만드는 중입니다.
전에도 소스를 한번 올렸었는데요
이상하게 VM이 죽어버리는 현상은
뭐 스트링 메소드 대신에 char 배열로 하나하나 하고 -_-
이런식으로 하니까 어느정도 된거 같은데
아직도 가끔 죽기는 합니다. ㅠㅠ
그래도 어느정도 진도는 나갔는데요
네트워크 공부를 하지 않은 상태라서 막히는 부분이 있네요
고수님들의 도움을 요청하고자 글을 쓰게 되었습니다.
우선 프로그램의 매커니즘은 다음과 같습니다.
(자바로 작성)
1. src host가 내 컴퓨터이고 dst port 가 80인 패킷을 캡쳐
(jpcap이라는 라이브러리를 사용합니다. winpcap을 이용하는 라이브러리 이구요
http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html
여기가 주소입니다)
2. 캡쳐된 패킷에서 data필드를 하나하나 char로 찍어서
페이지를 요청하는 GET ~~~~ 이부분이 나오면
여기서 Host : ************* 을 파싱하고 다시 ************ 을 추출해 냄
3. ************을 미리 파일로 구축된 유해사이트 목록과 문자열 패턴 매칭 시도
(알고리즘 구현도 프로젝트 주제에 포함되는 거라서
Boyer-Moore, DFA 알고리즘을 사용합니다.
목록은 10만건 정도... -_-)
4. 유해사이트 목록과 ************** 이 일치하면
서버에는 접속종료를 알리고 클라이언트엔 접속종료와 동시에
차단되었다는 내용의 페이지를 띄워준다.
----------------------------------------------------
이정도 인데요
현재 host 추출하는 부분까지 했습니다.
그런데 패턴매칭이 되면
서버와 클라이언트에 패킷을 뿌려야 된다고 했는데
제가 본 자료에서는
양쪽으로 RST 패킷을 보내면 된다고 하더군요
여기서 의문점이 하나 생기는데요
TCP 패킷에 RST 플래그만 켜주면 되는건가요?
그러니까 하나하나 따져보면 양쪽으로 가면 맥어드레스의 선후관계도 다르고
패킷마다 포트번호도 다르지 않나요?
양쪽으로 RST 패킷을 보낸다는 말 자체를 모르겠습니다.
IP 레이어와 데이터링크 레이어도 건드려야 하는건지...
클라이언트에게는 서버에서 온것처럼 패킷을 만들어 줘야 하는거
같기도 하구요.... 잘 모르겠네요 ㅠㅠ
이부분에 대해서 좀 자세히 설명해 주셨으면 합니다.
두번째로는요 차단하는 매커니즘을 만들었어도
패턴매칭 과정 도중에 서버에서 응답이 오면
막을 방법이 없을것 같다는 막막한 생각이 들었습니다.
그렇지 않나요? ㅠㅠ
제 프로그램 설계가 조금 잘못되어 가고 있다고
느껴지기도 하네요 ㅠㅠ
고수님들 자세한 답변 부탁드립니다. ㅠㅠ
TCP 프로토콜 헤더의 비트 플래그 6개 중에 보면 RST가 있습니다.
TCP 프로토콜 헤더의 비트 플래그 6개 중에 보면 RST가 있습니다.
이걸 1로 세팅해서 보내라는 얘기죠. 그러면 TCP 연결이 끊어진걸로 판단하게
됩니다. (정확히 말하자면 비정상적인 상황이라서 끊을테니 다시 연결하라
그뜻이죠.)
RST패킷과 함께 조작할 것을 나열해야 한다면.
source/destination IP도 당연히 조작 해 줘야 합니다. (서버로 보낸다면 클라이언트 IP가 들어가야죠.)
port 번호도 조작 해 줘야 합니다.
이정도 쯤 되겠네요.
IP Layer까지 조작해야겠네요.
Written By the Black Knight of Destruction
패킷을 분석하면 엄청 cpu에 무리가가겠군여...
패킷을 분석하면 엄청 cpu에 무리가가겠군여...
제가 아는 한도내에서..
제가 정확하게 알고 있는지 모르겠습니다만,
제작하시는 프로그램이 PC에 설치하여 실행하는 유해사이트 차단 프로그램인 것 같은데요.
첫번째 문제는 위에 분이 말씀하신대로 하시면 될 것 같습니다.
두번째로, "패턴매칭 과정 도중에 서버에서 응답이 오면
막을 방법이 없을것 같다는 막막한 생각이 들었습니다"라는 부분에서 스니핑은 지나가는 패킷을 중간에서 가로채서 보는 것이기 때문에 실제로 패킷은 src에서 dst로 아무런 방해없이 가게됩니다. 따라서 패킷을 하나도 지나가지 못하게 막을 수는 없고 시간차가 발생하여 서버와 클라이언트가 데이터를 조금은 주고받을 수도 있는 가능성이 있습니다.
몇년전에 유해싸이트 차단 프로그램을 개발한적이 있습니다.패킷을 캡
몇년전에 유해싸이트 차단 프로그램을 개발한적이 있습니다.
패킷을 캡춰하셔서 TCP Layer 까지 들어가시면 너무 많은 시스템 자원을 끌어쓰실거 같습니다. 물론 주어지는 Action 형태가 REQ -> GET, GET 단계에서 필터링하신 다는 것이긴 하지만요.
국내에 시판이 안되었으니 제가 썼던 방법을 살짝 말씀 드리면 Local Proxy 서버 개념도 한번 생각해 보셨으면 합니다. 일단 불러오는 단계까지는 Proxy 에 저장해 놓고 IE 에 넘기기 전에 필터링하는 거죠. IE Proxy 설정을 하지 않고서도 사용해 버리면 아예 http 가 사용 안되게끔 만드신다면 되지 않을까요? ^^;
물론 개발환경은 M$ VC, Windows SDK 였습니다.
Too Many Sceret is in your heart.
We must break it and don't forget it.
Until no more secret remains in your soul
단지 유해사이트차단이라면, 구지 TCP까지 볼 필요없이, IP Heade
단지 유해사이트차단이라면, 구지 TCP까지 볼 필요없이, IP Header만 보고도 가능합니다. 소위 IP주소로만으로도 가능하겠지요.
그러나, 특정 서비스(포트번호)를 차단하려한다면, TCP헤더중 PORT번호만 보고도 가능하겠습니다.
(여기까지는 일반 파이어월로도 충분히 가능)
그러나, 상위레이어의 내용까지도 보고 차단하려 한다면, lyk21024님의 접근이
올바른 시작입니다.
TCP를 너무 약하게 보지는 마세요.
Sequence#가 틀리면 해당패킷은 버려집니다. 즉, RST만 세팅해서 보내서는
안되고, 순서번호를 예측해서(보통 특정패킷을 잡았을때 알수있음) 보내야합니다.
예측해야하는 이유는, 차단하는 프로그램이 돌고 있는(순서번호예측, 패턴매칭..)등을 하는 동안에도, 양단(실제통신하는 C/S)간에는 이미 다른 패킷이 오갈수있기 때문입니다.
TCP는 중복된 패킷을 버립니다. (RST패킷의 순서번호 영역이 이미 받은 영역이라면?) 그래서, RST보낸다고 차단되지는 않고, 단지 차단될 수 있을지도 몰라!가
맞습니다.
( * IP defragmentation과 TCP reassembly가 왜 필요한지를 검토하세요...)
차단 확률을 높이려면, 계속 연속적으로 보내야겠지요.
트래픽부하가 심해지면, 패킷을 분석하는 프로그램의 부하가 커지게되고,
당연히, 분석+차단패킷 송신이 실시간에 이뤄지지 않을 확률이 높아지고,
오작동이 심하게 예측되는 바입니다.
그러나, 실험실버전에서는 그냥 잘~되는 정도로 만족해도 좋을듯합니다.
* 맥어드레스
맥어드레스는 스위치를 지나게되면서, 본래 송신한 컴퓨터의 맥이 아닌 중간에
중계해주는 장치의 맥으로 변경됩니다. 브로드캐스트 도메인을 벗어나, 라우팅 단계로 가는 순간에 맥은 그 의미를 상실하게됩니다.
만일 완성품이 edge단(네트워크 구성의 말단)에 탑재되는 것이라면 맥어드레스는 의미가 있으나, 상위단에 구성된다면, 맥어드레스는 의미가 없습니다. 무의미!
* 패킷마다 포트(서비스 Layer 4)번호가 틀릴 수 있으나, 이를 극복해야함은 당연합니다.
구지 양쪽으로 보낼 필요는 없는데, (리소스를 아껴주고 싶은쪽) 한쪽에만 보내도 일단 차단은 이뤄집니다.
IP레이어로 차단하면 해당 완성품이 IP레이어단에 설치(탑재)가 가능하고,
데이터링크 레이어로 차단하면, 데이터링크 레이어단에 설치해야합니다.
당연하게도 후자로 구현된것은 전자보다는 다수대를 설치해야할것이며, 비용도 제법들수 있겠습니다. 물론 둘다 일장일단이 있지만요.
당연히 그러해야합니다. 만일 자신이 모르는 패킷이(연결되지 않거나, 열린포트가 아닌 다른 포트로 오거나 등) 도착하면 커널의 TCP/IP스택은 이를 조용히 버리거나, 원격지로 RST를 보내게됩니다.
그렇지요. 맞습니다.
passive 기술의 한계입니다. 물론 passive기술도 나름의 장점도 있지만, 이는 한계이지요.
또한, 네트워크 부하가 심할때, 비정상적인 동작을 수행할 우려가 아주 높습니다.
그러나, 가정을 세워봅시다. 패턴매칭 과정의 성능을 아주 높여서 원격지 서버가
프로세싱하는 시간보다 빨리 일을 처리한다.라고 말입니다.
패턴매칭 과정의 성능은 패시브로하던지 IPS처럼 active로 수행하던지, 전체적으로
시스템의 성패에 영향을 주는 요인입니다. 핵심기술이라는 얘기지요.
패시브기술은 부담없이 돌려볼 수 있고 네트워크 마비등 위험을 발생시키지 않는
특유의 장점을 가지고 있으므로, 나름대로의 영역을 확보할 수 있습니다.
아니요. 설계라기 보다는 점점 발전적인 방향으로 가고 있다고 보입니다.
현재까지 설계상의 문제는 없어보이며, 가장 보편적인 접근을 수행하고 있습니다.
* 좋은 프로그램 만드세요.
일단.. RST을 보내는 것은 아마, 유해 사이트라고 판단되고 나서일듯
일단.. RST을 보내는 것은 아마, 유해 사이트라고 판단되고 나서일듯 합니다.
정상적인 접속이면 검사해서 바로 포워딩 시키면 되지만.
만약에 유해 사이트라고 판단이 된다면, 해당 세션을 끊어야 하죠...
그렇다면 중간에 위치한 유해차단장비에서는 해당 세션을 끊는 방법은 바로 양쪽으로 각각 RST 메세지를 보내주는 것입니다.
물론 RST을 보낼떄는 기존 세션의 정보를 토대로 마치 상대방이 보내준것 처럼 해주어야 하죠...
그러면 해당 세션의 연결을 끊게 됩니다.
앞의 어느분이 왜 양쪽으로 보내냐고 하셨는데...
TCP의 특성상 한쪽만 끊으면 다른 한쪽은 일정 시간동안 계속 해당 세션을 관리하게 되고, 결국은 불필요한 리소스를 낭비하는 일이 생기게 됩니다.
그럼..이만.
==============================
= Crazy Fighter : Kill Them All =
==============================
Re: 패킷 스니핑을 통한 유해사이트 차단 프로그램을 만드는 중
도움이 안되는 질문을 해서 미안합니다만 궁금해서요.
10만건의 유해사이트 목록 DB는 어디서 구하셨나요? 혹은 어떻게 만드셨습니까?
10만건이라면(또는 다량) 검색트리/해쉬의 구현도 매우 중요한 주제입니다
10만건이라면(또는 다량) 검색트리/해쉬의 구현도 매우 중요한 주제입니다.
또한 부하분산/병렬처리도 중요한 이슈입니다.
관련 프로젝트가 있지요. 개발이 진행중인것처럼 보이지는 않지만요.PC
관련 프로젝트가 있지요. 개발이 진행중인것처럼 보이지는 않지만요.
PC에 설치해서 제어하지 않으며 ICMP로 제어한다는 차이는 있습니다.
http://djstop.kldp.net/index.html
그리고 패킷 생성은 libnet을 이용하시면 쉽게 할 수 있습니다.
Re: 패킷 스니핑을 통한 유해사이트 차단 프로그램을 만드는 중?
아직 구하진 않았습니다
근데 못구할거 같기도 하네요 ㅠㅠ
정보통신윤리위원회, 청소년보호위원회에서
다 퇴짜 맞았습니다 ㅠㅠ
//TODO
* 차단 방법론1) RST, FIN등 패킷을 보내차단 =>
* 차단 방법론
1) RST, FIN등 패킷을 보내차단
=> TCP만가능
2) ICMP제어 패킷을 전송
=> TCP/UDP도 가능
3) ARP spoofing
=> Edge network에서 적절
4) F/W, IPS, Switch등 외부 차단가능장비에 관리자로 접속하여 룰등을 추가/삭제/변경
=> 장비마다 사용방식이 상이하여, 다양한 기종지원을 준비해야하는...
* 소 잃고 외양간 고칠 가능성에 대한 고려 : 탐지시간이 길어 차단시점을 놓지는 경우
* 근본적으로 차단방법론도 중요하나, 탐지방법 ,성능, 정확성(오탐대비)이 중요한 이슈임
5) 게이트웨이 장비로 구현(마치 IPS, F/W처럼)- 탐지성능에
5) 게이트웨이 장비로 구현(마치 IPS, F/W처럼)
- 탐지성능에 따라 전체네트워크의 통신에 영향
- system fail시, 망이 마비될 가능성(fallback, bypass등에 대한 고려)
- 오탐(false positive)으로 인한 정상트래픽 차단가능성(차단한 트래픽이 중요업무시 더욱 위험)
흠..
KLDP 글은 삭제가 안되는군요... ㅠ
//TODO
댓글 달기