PacketInside / 네트워크 패킷 분석 블로그: 2010

2010년 12월 31일 금요일

패킷파일의 캡쳐시간이 비이상적으로 큰 경우

일전에 포스팅 한 글에서 PCAP 파일을 오픈하는데 65535 값 보다 큰 경우에 대해서
이야기 한 적이 있다. 아직 이 글을 보지 못했다면 다음 링크를 참고하길 바란다:

[LINK] 패킷파일이 깨진 경우는 언제? 65535 보다 큰 값의 헤더가 있다면...

추가적으로 한가지 더 덧붙이고자 한다. 패킷 파일을 보다 보니 시간이 아주 크게 나오는 경우를 보았다. 역시나 이 경우도, 패킷파일이 잘못 저장되어 올바르지 않은 형태로 볼 수 있는데, 결과는 다음과 같다

[Error] (pcap: File has 110080-byte packet, bigger than maximum of 65535)
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 3484
File size: 1559852 bytes
Data size: 2114979 bytes
Capture duration: 1293540784 seconds -> 엄청나게 큰 패킷 저장 시간
Start time: Thu Jan 1 09:00:00 1970
End time: Tue Dec 28 21:53:03 2010
Data byte rate: 0.00 bytes/sec
Data bit rate: 0.01 bits/sec
Average packet size: 607.05 bytes
Average packet rate: 0.00 packets/sec

이렇게 패킷파일의 캡쳐 시간이 비 이상적으로 큰 경우에는 잘못된 형태임을 대충 짐작할 수 있다. 프로그램을 통해 자동으로 분석을 하는 경우와 같은 때는 이런 류는 제외 시켜도 무난한다. 아, 참고로 와이어샤크를 통해 패킷파일을 열어보면 아래 같이 정상적으로 잘 나오는 부분이 있는 반면 Malformed Packet 이라고 제대로 표현하지 못해 보여주지 못하게 되므로 이럴때는 패킷파일이 손상되지 않았나 의심해 볼 수 있다.

2010년 12월 29일 수요일

웹 사이트를 방문하다 본 위험하다는 경고창, 하지만 100%는 아니다.

글 목록을 보다, 예전에 써 놓은 글이 있어서 이제야 소개한다. 어느날 국내 인터넷 쇼핑몰의 한 상품을 보려고 하는데, 사용하는 브라우저인 크롬에서 '경고창' 이 떴다. 아래 그림과 같이 해당 사이트는 위험할 수 있으니 방문하지 말라는 것이다. 크롬에서 이 기능은 유용하게 사용된다. 사실 생각외로 국내에서 정상적인 사이트에 악의적인 코드가 삽입되어 있는 경우는 많다. 공격자 입장에서 생각해 보면, 이것은 좋은 전파의 근원지가 될 수 있다. 감염을 전파시키기 위해서 유명한 사이트 한 곳을 뚫어 거기다 악의적 코드 하나를 삽입해 놓으면 되는 것이다. 이 얼마나 효과적인 방법인가? 그래서 몇년전 부터 대세가 되고 있는 공격중에 하나가 되었다.

어찌되었든, 브라우저에서는 방문하지 말라고 하니 사실 여부를 떠나서 찝찝하고, 그런데 또 보고싶기도 하다. 일단 경고상으로는 이미지 파일이 문제가 되고 있다.

<img src="http://hy[삭제]2.kr/gmk/g[삭제]0dc.gif"

위 파일이 문제가 되는 것인데, 해당 사이트는 이미지파일을 호스팅하고 있는 곳이다. 일단 이미지 파일을 내려받아, 세부검토를 해 본결과 파일은 정상이었다. 혹시 내가 틀린것일까? 구글에서 운영하는 서비스가 항상 최신의 데이터를 유지하지는 못한다. 검사할 당시에는 악의적으로 판단되어 차단되었지만, 그 후에 정상적으로 변경되었더라도 구글 정책상으로 일정기간 동안 악의적 사이트로 분류가 된다.

그러므로 접속경고 메시지가 100% 맞는 것은 아니다. 하지만, 일반 사용자가 판단하기란 쉬운일도 아니기 때문에 꼭 굳이 해당 사이트에 접속할 필요가 없다면 접속을 안하는 것이 좋을것 이다.

차단된 사이트의 세부정보를 더 들여다 보면 언제 이 사이트가 악의적으로 분류되었고 어떤 이유에서 차단되었는지 나온다.

아래쪽 메시지중 같은 형태의 악의적코드를 호스팅하고 있는 또 다른 도메인을 한번 방문해 보았더니 아래와 같은 정보가 나온다.

Of the 9669 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2010-06-09, and the last time suspicious content was found on this site was on 2010-06-09.
Malicious software includes 3970 trojan(s), 3814 scripting exploit(s), 681 exploit(s).

무려, 3970 개의 트로이 목마가 포함되었다고 한다. 또, 맥도널드와 유사한 도메인인 mcd0nalds.com 에는 17392개의 트로이목마와 8개의 웜이 포함되어 있다. 엄청난 숫자의 악성코드가 해상 사이트에 존재하는 것이다.

지금, 웹 상에서는 엄청난 양의 악성코드가 유포되고 있다. 사용자 입장에서는 감염될 가능성이 아주 넓어 졌기 때문에 많은 주의가 필요하다. 최소한 윈도우 보안 업데이트만 꾸준히 해도 이러한 위험성은 조금 낮아진다. 물론, 0-day 공격에 대해서까지 커버하기란 힘들지만, 다음과 같은 기본적인 사항들만 지켜도 보안성은 90% 이상 높아진다.

- 최신의 윈도우 보안 업데이트 유지
- 사용하는 소프트웨어 보안패치가 나온경우 빠른 업데이트 하기
- 윈도우에서 패스워드 사용하기
- 공유폴더 사용하지 않기
- 백신 프로그램, 개인용 방화벽 프로그램 설치
- 출처가 확인되지 않은 프로그램 실행하지 않기
- 크랙 사이트 방문하지 않기

이외도 있지만, 최소한 이것만은 지킨다면 컴퓨터는 더욱 안전하게 사용가능할 것이다.

2010년 12월 27일 월요일

임의의 데이터 파일을 생성해 낼때 사용할 수 있는 방법은?

임의의 파일을 생성하여 테스트 할 경우가 있다. 디스크 IO 를 측정할 경우나 또는 지정한 데이터 크기의 임의파일을 만들어 여러 전송에 성능측정을 하는 경우도 있다. 이렇게 임의 파일을 만드는 가장 간단한 방법은 /dev 밑에 존재하는 디바이스를 이용하는 것이다.

# cat /dev/urandom > test.bin

/dev/urandom 을 통해서 test.bin 을 생성하는 것이다. 적정한 시점에서 Ctrl+C 를 눌러 중지하면 된다. /dev/urandom 외에 /dev/zero, /dev/random 을 이용할 수 있다. /dev/zero 가 가장 빠르게 동작할 것이며, /dev/urandom 은 /proc/sys/kernel/random/pool_size 에 의해 사이즈 Chunk 가 결정된다.

이외 dd 를 이용해 원하는 사이즈 값 만큼 생성해 내는 방법도 있다. 아래의 예는,
/dev/zero 를 이용해 test.bin 을 생성하는데, 그 사이즈는 50 메가 이다.

# time dd if=/dev/zero of=test.bin bs=50000000 count=1

1+0 records in

1+0 records out

50000000 bytes (50 MB) copied, 0.326928 s, 153 MB/s

real 0m0.346s

user 0m0.000s

sys 0m0.136s

초당 153M가 나왔고, 0.3 초 정도 걸렸다. 이런 방법들은 디스크 성능 측정에 유용하기도 하고, 패킷 전송률 같은 것을 테스트 할때도 임의의 데이터 파일을 생성해 전송해 보는데도 유용하다.

2010년 12월 24일 금요일

스노트(Snort) 룰을 파싱하여 패킷 생성, 전송하기

IDS 로 많이 사용중인 오픈소스 스노트가 있다. 스노트로 제작된 관련 탐지 룰도 많이 찾아 볼 수 있고, 실제 무료/상업용 침입차단 패턴이 이 스노트 형태의 기반이 많다. 여기서 스노트를 다룰 것은 아니다. 다만, 패킷 분석이 많이 사용되는 영역중에 하나로 어떤 위협을 차단/탐지 하기 위한 패턴 작성을 빼 놓을 수 없다.

네트워크 상에서 흘러다니는 트래픽을 정확히 분석 판단하고 어떤 부분을 패턴으로 뽑아내어 사용할 것인가는 단순한 것부터 복잡한 것까지 다양하다.

시그너처 패턴 작성 후 올바로 탐지하는 것을 테스트 하기 위해 트래픽을 재 전송해 보고 한다. 이미 여기서 언급한 tcpreplay 나 기타 도구를 이용해 재전송해보는 것으로 내가 만든 패턴이 올바른지 확인할 수 있다.

앞서 소개한 PackIt 도구에서 유용한 유틸리티가 하나 있다. 그것은 스노트 룰을 PackIt 명령어로 만들어, 패킷을 전송할 수 있도록 도와주는 것이다. 스노트 룰의 QA 등과 같은 업무에는 나름 유용하게 사용할 수 있을 것이다.

다운로드는 다음의 경로에서 가능하다.

http://packetfactory.openwall.net/projects/packit/s2pgen.pl

이 파일은 펄(Perl) 스크립트로 간단히 만들어져 있는 것으로 룰 파일을 지정하면, packit 으로 검증해 볼 수 있게 명령어를 만들어 준다. 파일을 열어 첫 시작부분을 보면 주소 설정을 정의하는 부분이 있다. 시그너처 파일에서 룰을 읽어들여 파싱할때 필요한 기본 정보이다. 이 정보들만 여러분들의 네트워크 상황에 맞게끔만 조절하여 사용하면 된다.

# Defaults
$DEFAULT_PACKIT = "packit";
$DEFAULT_ADDR = "10.0.0.1";
$DEFAULT_DATA = "R";

# Host/Port definitions
$EXTERNAL_NET_ADDR = "10.0.0.1";
$HOME_NET_ADDR = "192.168.0.4";
$HTTP_SERVER_ADDR = "192.168.0.2";
$SQL_SERVER_ADDR = "192.168.0.3";
$SMTP_SERVER_ADDR = "192.168.0.4";
$TELNET_SERVER_ADDR = "192.168.0.5";
$AIM_SERVER_ADDR = "192.168.0.6";
$ORACLE_PORT = "1521";
$HTTP_PORT = "80";
$SHELLCODE_PORT = "81";

우선 스노트에서 제공하는 기본 룰 파일중 하나인 ddos.rules 파일을 가지고 만들어 보면 아래와 같다 :

# ./s2pgen.pl ddos.rules
echo

echo DDOS TFN Probe
packit -t icmp -s10.0.0.1 -d192.168.0.4 -p "0x 31 32 33 34" -SR -DR -K 8 -N 678

echo DDOS tfn2k icmp possible communication
packit -t icmp -s10.0.0.1 -d192.168.0.4 -p "0x 41 41 41 41 41 41 41 41 41 41" -SR -DR -K 0 -N 0

echo DDOS Trin00 Daemon to Master PONG message detected
packit -t udp -s10.0.0.1 -d192.168.0.4 -p "0x 50 4f 4e 47" -SR -D31335

echo DDOS TFN client command BE
packit -t icmp -s10.0.0.1 -d192.168.0.4 -SR -DR -K 0 -N 456 -Q 0

packit 을 통해 보내기 전 echo 로 어떤 패킷인지 출력해 주고 packit 명령어로 전송할 패킷 정보를 만들어 준다. 그리고, 스노트에서 탐지가 되는지 확인해 보면 된다.

시그너처 제작 업무를 하는 이들에겐 나름 도움이 될 것이다. 또는 이를 변형하여 원하는 형태의 도구를 이용하여 만들어보는 것은 어떨까?

2010년 12월 23일 목요일

패킷인사이드가 현재 이전되어 정리중입니다.

패킷인사이드를 접속하셨는데, 먼가 확 바뀌셨죠? 그 동안 이용해온 구글의 텍스트큐브가 서비스를 종료함에 따라 어쩔 수 없이, 이전하게 되었습니다. 그래서 아직 모든게 정리가 안 되어 기본 상태입니다. 댓글도 다 이전이 안된것 같고, 먼가 부족하네요.

곧 다시 정리하여 깔끔한 모습으로 나타나겠습니다. 도메인도 다시 이전이 될 예정이므로

혹시나 접속이 안될 수도 있습니다.

그전에는 주로 직접 설치하거나 꾸며서 사용하는 것을 좋아했었는데, 이제는 그러는게 힘들어지다 보니 이렇게 서비스형 블로그를 사용할 수 밖에 없게 되네요. 일단은, 운영 관련해서는 신경쓰지 않아서 참 좋구요 :-)

나중에 나만의 기능이 필요하고, 방문자도 더 많아지면 패킷인사이드만의 공간을 가져보아야 겠어요.

2010년 12월 20일 월요일

트래픽 흐름에 따라 사운드를 출력해 보자!

재미있는 유틸리티 하나를 소개해 본다. 일전에 트래픽 흐름 상태를 키보드의 LED 표시를 통해

깜빡 거리는 것을 소개한적 있다. 이와 같이 조금은 재미있는 형태의 프로그램이라 보면 된다.

키보드 LED 정보를 이용한 블로그 글은 다음을 참고한다.

-> 2010/04/26 Rigel 키보드 LED 를 이용한 패킷 송신/수신 표시하기

오늘 소개하고자 하는것은, 트래픽 흐름의 형태에 따라 사운드를 출력시키는 것이다. 트래픽 종류에 따라

지정된 사운드가 스피커를 통해 흘러나온다. 이름하여 Tcpsound 이다. 파일은 아래 URL 에서 받을 수 있다.

http://www.ioplex.com/~miallen/tcpsound/

컴파일 하기 위해서는 libsdl 와 libmba 라이브러리가 필요하다. libmba 는 아래 경로를 참고한다.

http://www.ioplex.com/~miallen/libmba/dl/

APT 패키지 사용자는 sdl 패키지를 아래와 같이 설치할 수 있다.

# apt-cache search libsdl-sound

libsdl-sound1.2-dev - Development files for SDL_sound

libsdl-sound1.2 - Decoder of several sound file formats for SDL

# apt-get install libsdl-sound1.2-dev

이후 다운받은 tcpsound 패키지의 압축을 풀고 'make' 를 해 주면 된다.

컴파일 된 tcpsound 를 실행하면 아래와 같은 메시지가 발생된다.

$ ./tcpsound

searchpath: /usr/share/sounds:/usr/local/share/sounds

proto src dst wav path

src/sound.c:64:path_search: No such file or directory: generic.wav