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 정보를 이용한 블로그 글은 다음을 참고한다.


오늘 소개하고자 하는것은, 트래픽 흐름의 형태에 따라 사운드를 출력시키는 것이다. 트래픽 종류에 따라
지정된 사운드가 스피커를 통해 흘러나온다. 이름하여 Tcpsound 이다. 파일은 아래 URL 에서 받을 수 있다.

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

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


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
  src/sound.c:154:sound_load_cfg: Rule will be ignored.
src/sound.c:64:path_search: No such file or directory: sonar.wav
  src/sound.c:154:sound_load_cfg: Rule will be ignored.
src/sound.c:64:path_search: No such file or directory: warning.wav
  src/sound.c:154:sound_load_cfg: Rule will be ignored.
src/sound.c:64:path_search: No such file or directory: pop.wav
  src/sound.c:154:sound_load_cfg: Rule will be ignored.
src/sound.c:64:path_search: No such file or directory: info.wav
  src/sound.c:154:sound_load_cfg: Rule will be ignored.
src/sound.c:64:path_search: No such file or directory: cuckoo.wav
  src/sound.c:154:sound_load_cfg: Rule will be ignored.

사운드 파일을 찾지 못해서 발생하는 것이다. 이럴 경우 따로 파일의 경로를 지정해 주거나 또는, make install 하게 되면 적절한 위치에 다 복사가 된다.

# make install
./mktool -i -m 0755 tcpsound /usr/local/bin
./mktool -i wavs/*.wav /usr/local/share/sounds
./mktool -i docs/man/*.1.gz /usr/local/man/man1

installation successful

tcpsound 를 실행하면 각 프로토콜 또는 포트번호 별로 지정된 사운드가 있는 것을 알 수 있다.

# tcpsound
searchpath: /usr/share/sounds:/usr/local/share/sounds
proto  src   dst wav path
ARP      0     0 /usr/local/share/sounds/generic.wav
ICMP     0     0 /usr/local/share/sounds/sonar.wav
IP      53    53 /usr/local/share/sounds/warning.wav
IP       0    80 /usr/local/share/sounds/pop.wav
IP      80     0 /usr/local/share/sounds/info.wav
IP     137   137 /usr/local/share/sounds/cuckoo.wav
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
02:55:06.019559 IP 204.152.191.39.80 > 192.168.15.11.38248: . 2697887135:2697888583(1448) ack 4005699112 win 88 <nop,nop,timestamp 1513910257 322740>
02:55:06.044274 IP 204.152.191.39.80 > 192.168.15.11.38248: . 1448:2896(1448) ack 1 win 88 <nop,nop,timestamp 1513910257 322740>

실행되면 스피커에서 뽁,뽀,뽁 과 같은 사운드가 발생되는 들을 수 있다. 이외 -r 옵션을 이용하면
원격지로 로그인하여 실행도 가능하다. 원격지 로그인은 SSH 접속으로 이루어진다.

이 tcpsound 를 보면 그냥 단순히 재미있는 프로그램이기도 하지만, 특별한 목적으로 만들어 사용하는 것도
나름 의미가 있을것 같다. 특정한 포트를 임의의 사운드 파일로 지정하여,
트래픽이 발생될 경우 알람음 형태로 이용이 가능할 수도 있다. 평소에 접근이 이루어지지 않는 포트인데
외부에서 접근이 이뤄지면 음성으로 알려준다면, 나름 좋은 아이디어 아닐까.
특히나 관제 및 서비스 운영 팀 같은데서는 유용하게 이용될 수도 있을것 같다.

참고로, tcpdump 를 기본으로 이용하므로 tcpdump 가 설치되어 있어야 한다.


2010년 12월 17일 금요일

NFS 에서 Stale NFS file handle 에러 발생하는 경우

NFS 를 사용하다 Stale File Handle 에러가 발생하는 경우가 있다면, NFS 의 연결 상태를 의심해 보아야 한다.
예를 들어, NFS 연결되어 있는 디스크 연결이 끊어져 버린 경우의 상태라면 아래와 같은 에러를 접할 때가 있다.

$ ls
.: Stale File Handle
df: `/data': Stale NFS file handle

언마운트를 하고 마운트를 다시 하려고 해도 같은 메시지가 반복된다.

# mount /data
mount.nfs: Stale NFS file handle

이런 경우 간단한 해결방법은, NFS 마운트 포인트를 끊고, 다시 연결해 주면 된다. 하지만 umount 하려고
해도 제대로 연결이 끊어지지 않는다. umount 를 사용할 때 '-f' 옵션을 사용하면 말끔히 해결된다.
아래와 같이 -f 로 언마운트를 하고 다시 마운트를 해 주면 된다.

# umount -f /data

NFS 사용자들이 가끔 겪을 수 있는 문제 같아 살짝 기록해 놓아 본다.

2010년 12월 15일 수요일

IP 주소 정수값으로 표현하기! 1208931688 의 뜻은?

다음 주소를 클릭 하거나 또는 브라우저에서 입력하여 접속해 보자.


구글 검색 사이트로 이동이 된다. 과연 이 숫자는 무엇이지? 이 숫자는 구글 IP 주소를
정수 값으로 표현한 것이다. 즉, 구글뿐만 아니라 IP 주소는 모두 이와 같은 숫자로 표현될 수 있다.
이해가 잘 안 간다면 차례대로 한번 살펴보도록 하자!

google.com 의 도메인 쿼리를 통해 IP 주소를 얻는다.

> google.com
Server: 168.126.63.1
Address: 168.126.63.1#53

Non-authoritative answer:
Name: google.com
Address: 72.14.213.104
Name: google.com
Address: 72.14.213.105
Name: google.com
Address: 72.14.213.106
Name: google.com
Address: 72.14.213.147
Name: google.com
Address: 72.14.213.99
Name: google.com
Address: 72.14.213.103
>

여러 IP 중에 제일 상단에 있는 72.14.213.104 를 대상으로 해 보자. 이 주소를 각각 표현하면
아래와 같이 된다.

IP 주소 : 72.14.213.104
바이너리 : 01001000 . 00001110 . 11010101 . 01101000
정수 : 1208931688

그럼 IP 주소를 정수 값으로 변환하려면 어떻게 해야 하는가? 일단 IP 주소를 4개 로 나눈다.
1번째 주소 72
2번째 주소 14
3번째 주소 213
4번째 주소 104

그리고 다음과 같이 계산될 수 있다.

(1번째 주소 * 256^3) + (2번째 주소 * 256^2) + (3번째 주소 * 256) + (4번째 주소)
= (72 * 16777216) + (14 * 65536) + (213 * 256) + (104)

그리하여 최종 값은
= 1208931688 이 된다.

그럼 어떤 주소라도 쉽게 변환할 수 있을 것이다. 만약 반대로 1208931688 이 숫자값만 알고 있을 경우
IP 주소를 어떻게 쉽게 알 수 있을까? 다음과 같이 펄을 이용하면 금방 알 수 있다.

$ echo 1208931688 | perl -ne 'print $_>>24 ,".",$_<<8>>24,".",$_<<16>>24,".",$_<<24>>24,"\n"'
72.14.213.104

또는 아래와 같은 방법으로 말이다.

$ more test.pl
#!/usr/bin/perl
# PacketInside.com
$ip_number = "1208931688";
$ip_string = sprintf("%vd", pack("N", $ip_number));

print "\n IP Address is $ip_string\n";

$ ./test.pl

 IP Address is 72.14.213.104
$

방법은 여러가지가 많으니 참고하길 바란다. 한가지 주의할 것은, 무조건 IP 를 숫자로 변환하여
웹 사이트를 접속한다고 했을때 다 되는 것은 아니다. 이유는 왜 그럴까?
최근 많은 웹 사이트들은 이름 기반의 가상호스트를 이용하고 있다. 이 뜻은 HTTP 헤더에
Host 필드를 제공하여야 제대로 인식이 되는데 단지 IP 주소만을 이용하여 접속하면 접속하고자
했던 페이지에 접속이 안된다.

예를 들어, packetinside.com 은 211.245.21.34 이지만 IP 로 접속하면 페이지가 안 뜨지만,
도메인명으로 접속하면 페이지가 나타난다.

이 부분이 더 궁금한 분은 가상호스트를 검색해 보면 이에 대한 대답을 더 얻을 수 있다. 자, 어찌되었든
이제 신기하게 보였던 숫자로만의 접속이 어떻게 된 건지 이해가 될 것이다. IP 주소를 표현하는
또 다른 방법!

[참고]

IP 주소 구성을 좀더 쉽게 표현하면 아래와 같다. 172 정수를 2진수로 변환하면 10101100 이 되고 이 8 비트가
모여 1 바이트가 된다. 즉 IP 주소는 4 바이트로 구성되어 있고, 4 * 8 = 32 bit 가 되는 것이다. IPv6 는 128 bit 주소 체계이다.

이미지 출처 : 위키피디아

2010년 12월 13일 월요일

네트워크 패킷분석 블로그, 패킷인사이드가 1주년이 되었습니다~

네트워크 패킷 분석 관련 블로그를 시작한지, 어느덧 1년이 되었습니다.
처음으로 쓴 글을 보니 2009년 12월10일 이네요. 패킷 관련한 주제로는 많은 글들을 보지 못해서,
기록을 남기고자 시작하였고, 지금 보니 그래도 많이 작성했네요.

그리고, 1년안에 방문자 10만명을 달성하였습니다.

총방문자101,805

초기에는 방문자가 없었는데 말이죠, 지금은 꾸준히 매일 300-500 명이 방문해 주십니다.
요새는 패킷 주제 뿐만 아니라 더 범위를 넓혀서 이것저것 쓰고 있기도 하지만, 그래도 큰 주제는
패킷과 관련한 것들로 이루어 집니다.

앞으로도 계속 써 나갈 수 있어야 하는데, 잘 할 수 있을까요? :-)

많이들 방문해 주시고, 좋은 의견도 남겨주세요.

From Rigel

2010년 12월 10일 금요일

어느날 금융사 홈페이지에 방문했더니 뜨는 MySQL 메시지 하나...

얼마전, 한 금융사 홈페이지에 접속을 위하여 방문하였다.
인터넷 뱅킹 사용시 보안 프로그램을 설치할 것을 요구하는데, 키보드 보안 프로그램은 제외하고
로그인을 시도하였더니, 아래와 같은 메시지가 찍히는 것이 아닌가?

mysql_query : Error [1064], ['syntax error' 에러 같읍니다. ('and user_yn='Y' order by seq_no desc' 명령어 라인 1)]

개발 관련 일을 하고 있는 사람이라면 쉽게 MySQL 을 사용하고 있구나 하고 추측해 볼 수 있다.
금융권에서 MySQL 을 사용한다고 하니, 역시나 오픈소스 MySQL 이구나 하는 생각도 든다. 개인적인
생각이지만, 흔히 Mission Critical 한 중요 데이터는 오라클과 같은 상용 데이터베이스를 써야 한다는
의견이 많지만, 왜 MySQL 및 기타 오픈소스들은 안될까? 구글만 보더라도 MySQL 을 튜닝해서 꽤 많은
데이터를 처리하고 있는 것으로 알려져 있는데 말이다.

잠깐, 엉뚱한 얘기로 빠졌는데 위와 같은 메시지를 보고서 제대로 Exception 처리를 안 했다는 생각이
들어서 적어보는 것이다. 사실 이와 같은 에러메시지가 보안적으로 문제가 될 수 있기 때문이다.
제일 간단하게는 여기서 MySQL 을 사용한다는 정보를 알아낸 것이고, 이것을 토대로 범위를 넓혀
갈 수 있다.

가끔 이와 같이 일반 사용자들에게 노출해서는 안되는 형태의 메시지들이 보이는 경우가 있는데,
개발자들은 테스트 시에도 다양한 상황을 고려하여 테스트를 해보아야 한다. 이런 메시지 하나가
시스템을 위협할 수 있는 불씨가 될 수 있다는 사실을 말이다...


2010년 12월 8일 수요일

45,000원 요금제는 인터넷전화 차단, 어떻게 하길래?

최근 스마트폰을 통한 mVoIP 즉, 스카이프와 같은 모바일 인터넷 전화 사용 제한과 관련한
기사가 많이 띄인다. 통신사에서 4만5000 원 이하 요금제 사용자들은 VoIP 이용을 차단/제한 한다는 것이다.
이에 대해 소비자들의 불만도 많은게 사실이다. 하지만, 차단을 시행한다고 했지만
실질적으로는 아직 이용이 가능하다고 한다. 단지 기사를 통해서만, 사용자들이 일단 사용을 포기하도록
유도한 것인가?  다음 기사에서 한 통신사 관계자가 한 말을 보자

통신사 관계자는 “최근 사용자들의 데이터 유형을 구분할 수 있는 딥패킹인스펙션(DPI) 장비를 도입해 트래픽 분류가 가능해졌기 때문에 곧 제한이 가능해 질 것”이라고 설명했다.

차단 정책과 관련해서는 여기서 논의할 부분이 아니니 생략하고, 패킷과 관련된 기술적 방법에 대해서
간단히 한번 생각해 보자. 스카이프,바이버,Fring 등 여러가지 VoIP 관련 프로그램들이 있는데,
이걸 요금제 별로 차단한다고 하면 우선 45,000 이하 사용자들을 구분할 수 있어야 하고 각 프로그램이
사용하는 패킷을 분석할 수 있어야 한다.

머 사용자 구분이야, 이미 데이터를 얼마나 사용하고 있는지 정보도 다 나오고 하니 이건 문제가 아니다.
프로그램을 차단할 수 있어야 하는데, 이것또한 사용되는 프로토콜을 분석하고 차단 가능성을 찾아보면 된다.
제일 간단하게는

- 특정 포트번호의 차단
- 프로토콜의 특정 패턴 차단

이 되겠다. 그런데 포트번호로 다 차단하기에는 문제가 발생할 소지가 있다. 그러므로 특정 패턴 차단 방식이 이뤄질텐데, 항상 구분할 수 있는 특정 패턴이라면 간단하지만, 다이나믹한 형태로 프로토콜이 변하면 쉽지 않다. 하지만, 기본적으로 정의된 형태가 있기 때문에 차단이 가능해 질 것이다.

"기술적으로만 본다면야 차단하는건 충분히 가능하다." 문제는 실제 필드에 이것을 쉽게 반영할 수 있느냐 하는 것이다.  스마트폰 사용인구가 증가하면서 이로인한 데이터가 폭발적으로 증가하고 있다.

엄청난 트래픽 양을 건뎌야 하고, 정확히 판단 분석해야 하며, 45,000 요금제 이하 사용자를 대상으로 적용해야 한다는 것이다. 통신사에서는 기사를 통해 차단한다고 밝혔지만, 실질적으로는 적용을 못하고 있다.
아마, 이런 여러 이슈들 때문에 쉽지 만은 않을 것이다. 각 트래픽에서 구분해 내는 어떤 시그너처 패턴을 작성한다고 했을때, 트래픽 양등도 고려하여 시그너처 패턴이 작성되어야 한다. 다음은 대표적인 오픈소스 침입탐지 시스템인 스노트에서 사용가능한 시그너처 패턴 예이다.

Signature 1 - Skype VoIP Initialization

tcp $HOME_NET any -> any any (msg:"P2P CHAT Skype VoIP Initialization";flow:to_server,established; content:"|8046010301002d0000001000000500000400000a 0000090000640000620000080000030000060100800700c003 0080060040020080040080|";depth:112;classtype:polic y-violation;sid:1000013; rev:1;)

Signature 2 - Skype client login -- reply from server

tcp $EXTERNAL_NET 1024: -> $HOME_NET 1024: (msg:"Skype client login -- reply from server"; flags:AP,SUFR12; flow:to_client,established; flowbits:isset,skype_client_login; dsize:5; content:"|17 03 01|"; depth:3; sid:1000012; rev:2; )

Signature 3 - P2P Skype client setup get newest version attempt

tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"P2P Skype client setup get newest version attempt"; flow:to_server,established; uricontent:"/ui/"; uricontent:"/getnewestversion"; content:"Host|3A| ui.skype.com"; classtype:policy-violation; sid:5694; rev:4;)
등등...

탐지만 하는 것이야 문제가 발생할 것도 없고 큰 이슈가 없다. 하지만, 차단 으로 들어가면 여러가지 고려해야 될 것이 많아지게 된다. 또한, 패턴 형태에 따라 다르겠지만 우회할 수 있는 가능성도 존재할 것이다. 우회 되는 형태가 발견되면 그걸 또 차단해야 할 것이고, 유지보수 비용도 크게 증가될 것이다.  

또 한가지는 실시간성이다. 과금이야 실시간 적으로 데이터를 바로 볼 필요가 없기 때문에 단순히 트래픽을Tapping 형태로만 해서 데이터를 분석해 반영하면 될 것이다. 그런데, 이건 지금 사용자가 사용하려고 할때
차단해야 한다. 실시간적으로 차단이 가능해 져야 한다는 것인데, 트래픽 중간 사이에 장비가 들어가 실시간
적으로 차단하는데 문제가 발생할 소지는 없을까? 장비의 다운, 잘못된 정책, 구성 등 여러 장애원인이
존재하게 될 수 있다.

트래픽을 직접 컨트롤 하는 것과 중간에서 트래픽을 덤프하여 분석하는 것은 분명히 차이가 있다.
그러므로 충분한 테스트와 안전성이 보장되었을때 단계별로 반영이 될 것이다. 만약 차단을 한다면 말이다.

엔지니어 입장에서는 기술적으로 가능이야 하다지만, 이걸 실제 필드에 반영해 운영한다는 것은 어려움들이
존재할 수 있다. 아마 이 글을 읽는 분이 엔지니어라면 동감할 것이다.

그래도 통신사 입장에서는 먼가 차단하려고 계속 고민은 하고 있을 것이다. 이 정도로 하고 있지 않을까?
- 중간에 Tapping 하여 트래픽 데이터 유형 분석
- 가장 많이 이용되는 mVoIP 앱 선정, 사용되는 프로토콜 형태 패턴 분석
- 패턴을 탐지용 형태로만 반영하여 관찰 (False Positive 등)
- 충분히 검증되었다 판단되면, 시범적으로 트래픽이 적은 구간에 시범 적용 / 테스트

mVoIP 차단을 떠나서 통신사에서는 트래픽을 제어할 수 있는 기술은 분명 필요하다. 그 영역에 따라 달라지겠지만 말이다. 어찌되었든 '패킷' 바로 이것 참 재미있는 놈이다. 이놈을 잘 알게 되면 흐름을 다 알 수 있으니 말이다.

마지막으로 앞으로 VoIP 는 꾸준이 크게 증가될 것이 뻔하다. 통신사에서는 이익저해 요소로 이것을 단지 차단하려고만 할게 아니라, 현재의 글로벌 트랜드를 보았을때 새롭게 대처해 나갈 수 있는 방안이 필요하다. 지금 시점에서는 차단이 이득일지 모르나, 앞으로는 아니다. 그리고 소비자들이 분명 사용가능한 데이터 용량 내에서 이용하겠다는데 말이다.

최근 발표된 넥서스 S 에는 VoIP 를 이용할 수 있는  기능이 들어가 있다고 한다. VoIP 를 지원하는 앱을 따로 설치할 필요도 없이 전화번호부에서 바로 이용 가능하다는 것이다. 점차, 인터넷전화의 대세가 예견된다.
어찌되었든 나는 소비자의 편에서 ^^

Internet calling (VoIP/ SIP support)

Gingerbread allows Nexus S to place Internet calls with a SIP account. This allows for enhanced VoIP dialing to other SIP accounts and even phone numbers.

2010년 12월 7일 화요일

패킷 정보가 제대로 안보인다고 ?

패킷 덤프를 하다보면 정보가 제대로 출력이 되지 않는 경우가 있다. 이런 경우는,
해당 프로토콜을 알 수 없거나 또는 출력할 정보가 없는 것이다.

tcpdump 로 덤프하다 보면 아래와 같이 빈 공백으로 나오는 것이 있다. 이것은 단지 하나의 예이다.

# tcpdump -r test.pcap | more
reading from file test.pcap, link-type EN10MB (Ethernet)
17:24:22.251252
17:24:32.255374
17:24:32.953486 IP 192.3.3.14.netbios-dgm > 192.3.255.255.netbios-dgm: NBT UDP PACKET(138)

보통은 간단한 요약 정보가 표시되는데 상위 2줄은 공백으로 비워 있다.  아니, 왜 정보가 제대로 출력되지
않는 것일까? 좀더 세부적으로 보기 위해 -X 옵션을 사용해 보자!

# tcpdump -r test.pcap -X | more
reading from file test.pcap, link-type EN10MB (Ethernet)
17:24:22.251252
        0x0000:  0000 0100 0000 0000 0000 0000 0000 0000  ................
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
17:24:32.255374
        0x0000:  0000 0100 0000 0000 0000 0000 0000 0000  ................
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

보이는 것이라고는 0x00 만이 반복된다. 도대체 이것이 무엇이던가?
-XX 옵션을 사용해 링크레이어 정보까지 확인해 보자.

17:24:22.251252
        0x0000:  0009 xx3f 1b8f 0009 xx3f 1b8f 9000 0000  ..|?....|?......
        0x0010:  0100 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000            ............
17:24:32.255374
        0x0000:  0009 xx3f 1b8f 0009 xx3f 1b8f 9000 0000  ..|?....|?......
        0x0010:  0100 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000            ............

이더넷 헤더에 익숙한 사용자라면 딱 보고 알 수 있겠지만, 일단 이더넷 헤더 구조를 보면 아래와 같다:

Destination MAC address

Source MAC address

Type/Length

User Data


MAC 주소는 각각 6 바이트 이다. 그럼 타입을 보면 0x9000 인걸 알 수 있다. 0x9000 타입은 무엇일까?
이더넷 타입은 미리 정의된 것이 있으며, 아래 주소에서 각 타입을 살펴볼 수 있다.

 36864   9000        -      -     Loopback                 [XEROX]
9000 은 루프백으로 표시되어 있다. 좀더 쉽게 보기위해서는 와이어샤크를 통해 보면
쉽게 알 수 있다. 즉, 루프 프로토콜이었는데, 와이어샤크에서는 파싱하여 보여줄 수 있었지만,
tcpdump 에서는 나타나지 않은 것이다.

또는 tshark 로 아래와 같이도 확인해 볼 수 있다.

# tshark -r test.pcap  -V | more
Frame 1 (60 bytes on wire, 60 bytes captured)
    Arrival Time: Dec  3, 2010 17:24:22.251252000
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 60 bytes
    Capture Length: 60 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:loop:data]
Ethernet II, Src:
(생략...)
    Type: Loopback (0x9000)
Configuration Test Protocol (loopback)
    skipCount: 0
    Relevant function:
    Function: Reply (1)
    Receipt number: 0
Data (40 bytes)

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0020  00 00 00 00 00 00 00 00                           ........
    Data: 000000000000000000000000000000000000000000000000...

패킷 분석 프로그램에 따라 처리하여 보여줄 수 있는 것도 있고, 아닌것도 있다. 여기 예에서는
이더넷 타입이 루프 타입인걸 소개한 것으로, 이 루프 타입은 Layer 2 상에서 'ping' 과 같은
형태로 보면 된다.

패킷 분석을 진행하다 보면 모르는 프로토콜 형태, 타입을 보다 이게 무엇이지 하고
분석 시간이 지연되는 경우가 크다. 그 만큼 분석에는 많은 경험이 있어야 정확히 무엇을 분석해 내야 할지
판단할 수도 있다. 물론, 상황에 따라 다 다르다.

어찌되었든 이런 경우도 있다는 것을 참고하기 바란다.

2010년 12월 3일 금요일

IPv4 주소 할당 이제100일도 안 남았다고요!

IPv6 installation

이미지출처 : www.monohelp.com


좌측 하단에 달려 있는 IPv4 카운터를 유심히 보셨나요? 이제 어느덧,
IPv4 할당이 100일도 채 남아있지 않습니다. 정확히 말하면 90 일 밖에 남지 않은 것이죠.

물론, 이것은 단지 예측한 시간일 뿐입니다.

이 카운터를 달 시점만 해도 할당중지 시간은 2011년 중반이었습니다. (5~6월) 그런데, 3월초로 당겨져 있네요.

할당 중지가 되면 앞으로 기업들이 어떤 행보를 보일까요? ISP 및 직접 IP 를
할당받는 입장에서는 더 이상 주소를 받을 수 없기 때문에, 내부에 가지고 있는
주소를 회수하거나 재 조정해서 사용하지 않을까 합니다. 사실 필요 이상으로
주소를 낭비하고 있는 부분도 분명히 있을 것입니다. 그리고 서비스 이외의
경우라면, 내부에서는 NAT 를 통해서 이용하면 되므로 큰 이슈는 없게 됩니다.

하지만, 최근 국내에서도 불어닥치고 있는 스마트폰 열풍을 고려해보면
IPv4 로의 대응에는 한계에 부딪힐 것입니다. 여러 서비스 구현에도 제약이 있게되는
것이죠. 이렇게 한번 생각을 해보죠! 제가 사용하는 스마트폰에 인터넷 주소가
할당되어 제 스마트폰 자체가 웹 서버나 기타 인터넷 서비스를 직접 할수 있다고 말이죠
내가 사용하는 스마트폰에 나만의 주소가 생긴다, 과연 이것이 주는 의미는 무엇일까요?
지금보다 더 많은 서비스가 탄생할 수 있지 않을까요. 분명 IPv4 주소체계로는
한계를 가지고 있습니다. IPv6 로의 이동은 자연스러워 지겠죠.

내년 초, 공식적인 IPv4 할당 중지가 일어나도 당분간 기존의 주소 자원과
NAT 와 같은 방법등을 통해 큰 혼란은 없겠지만, 신규 서비스를 준비하는
기업입장에서는 더욱 고민이 깊어질 것입니다. IPv6 로의 전환이 이뤄질 것이다라고
몇 년 전부터 이야기가 나왔지만 아직도 IPv4 체계를 유지하고 있는 것을 보면
정말 IPv6 로의 전환이 빠를까 하고 의문이 생길 수도 있지만,
이제 진짜 내년초 IPv4 할당이 중지됩니다.

더이상 주소를 할당해 주지 않는다면 앞으로 어떻게 대처해야 할까요?
정말 IPv6 로의 전환에 속도가 붙을까요? 내년 초 앞으로의 행보를 지켜보도록 하죠.

From Rigel

2010년 12월 2일 목요일

네트워크 패킷 인젝션,캡쳐 도구 Packit

네트워크 패킷을 인젝션하고 캡쳐할 수 있는 도구 Packit(Packet toolkit) 을 소개한다.
앞서 소개했던 많은 도구들과 같이 인젝션하기에 유용한 도구이다.

TCP,UDP,ICMP,IP,ARP,RARP 그리고 이더넷 헤더등 거의 모든 것을 정의할 수 있어,
방화벽, 침입탐지시스템, 트래픽 테스트와 같은 곳에 이용할 때 유용하게 사용될 수 있을 것이다.
Packit 의 버전은 현재 1.0 이며 설치를 하기 위해서는 libnet 1.1.2 이상의 라이브러리와
libpcap 라이브러리또한 필요하다.

소스파일의 다운로드는 다음의 경로에서 할 수 있다:

APT 패키지 사용자라면,
# apt-get install packit 으로 쉽게 설치도 가능하다.

사용에는 큰 어려움이 없으나, 다만 옵션이 상당히 많다. 이 뜻은 세부적으로
정의할 수 있다는 뜻이된다. 기본 사용방법은 아래와 같다:

usage: packit -m mode [-options] 'expression'

사용할 때 모드가 있다는 것을 주의해야 하는데, 모드에 따라서 옵션이 달라지기 때문이다.
옵션에는 capture, inject, trace 가 있으며 기본모드는 inject 이다.

1. 패킷 캡쳐

자주 사용할 만한 패킷 캡쳐 옵션 몇가지를 정리해 보면 아래와 같다

-c count 캡쳐할 카운트 수를 지정
-e 링크 레이어 헤더 데이터 출력
-i interface 네트워크 인터페이스 지정
-n 호스트 주소를 이름으로 변환하지 않음
-r file 패킷을 읽을 파일 지정
-s snaplen 패킷 캡쳐할 snaplen 데이터 사이즈 정의 (기본:68 바이트)
-w file 패킷 파일 저장
-X 헥사와 아스키로 데이터 출력

사용 옵션들을 보면 패킷인사이드에서 여러번 다뤘던 도구들과 큰 차이는 없다.
특히 tcpdump 에 익숙하다면 더욱 그럴것이다.

사용예제>

#packit -m capture -c 100 -i eth0 -w /data/packetinside.pcap
#packit -m cap -nX 'tcp and port 80'

2. 패킷 인젝션

기본적으로 인젝션 되는 패킷의 옵션은 아래와 같으며, 옵션만 봐도 크게 어렵지는 않다.

-t protocol 인젝트할 프로토콜 타입 지정 : TCP, UDP, ICMP, ARP (기본은 TCP)
-c count 인젝션에 몇 개의 패킷을 사용할 것인지 정의
-i interface 네트워크 인터페이스
-w interval 각 패킷을 보내는 간격 시간 (기본 : 1초)
-h 패킷을 보낸 후, 응답을 프린트 해줌 * 필요에 따라 유용한 기능
-v Verbose 모드로 세부적으로 정보를 출력함
-p payload 인젝션 할 페이로드를 지정, HEX 는 '0x' 로 시작하며 각 값의 구분은 공백으로 함
ASCII : -p 'hello world, packetinside.com'
HEX: -p '0x 40 40 40 90 90 90 0d 0a'
-Z length 인젝트할 패킷의 사이즈 정의

-t 로 프로토콜을 지정한 후 각 프로토콜 마다 사용가능한 옵션을 이용하면 되는데
IP,TCP,UDP,ICMP,ARP,이더넷 헤더 옵션을 가지고 있다.
여기서 각 옵션을 일일이 설명하기는 힘들고, packit 의 간단한 도움말을 보면 쉽게 알 수 있다.

TCP/UDP header options
  -a ack      Acknowledgement number
  -D port     Destination port (Range format: start-end)
  -F flags    Flags (format: -F UAPRSF)
  -q seq      Sequence number
  -S port     Source port (Default: Random)
  -u urg      Urgent pointer
  -W size     Window size (Default: 65535)

ICMPv4 header options
  General:
  -C code     Code (Default: 0)
  -K type     Type (Default: 8)

  Echo(0) / Echo Reply(8):
  -N id       ID number
  -Q seq      Sequence number

  Unreachable(3) / Redirect(5) / Time Exceeded(11):
  -g gateway  Redirect gateway host (ICMP Redirect only)
  -j address  Original source address
  -J port     Original source port
  -l address  Original destination address
  -L port     Original destination port
  -m ttl      Original time to live
  -M id       Original ID number
  -O tos      Original type of service
  -P proto    Original protocol (Default: UDP)

  Mask Request(17) / Mask Reply(18):
  -N id       ID number
  -Q seq      Sequence number
  -G mask     Address mask

  Timestamp Request(13) / Timestamp Reply(14):
  -N id       ID number
  -Q seq      Sequence number
  -U ts       Original timestamp
  -k ts       Recieved timestamp
  -z ts       Transmit timestamp

IP header options
  -d address  Destination address
  -f          Don't fragment
  -n id       ID number
  -o tos      Type of service
  -s address  Source address
  -T ttl      Time to live (Default: 128)
  -V ipproto  IP protocol number (RAWIP only)

ARP header options
  -A op       Operation type (Default: 1 (ARP request))
  -x address  Source protocol address
  -X hwaddr   Source hardware address
  -y address  Destination protocol address
  -Y hwaddr   Destination hardware address

Ethernet header options
  -e ethaddr  Source ethernet address
  -E ethaddr  Destination ethernet address

옵션은 위와 같으며, 패킷인사이드 블로그를 열심히 보신 분들이라면 옵션을 이해하는데
어려움이 없을 것이다. 몇가지 예제를 보도록 하자.

다음은 출발지 소스는 8.8.1.1 로 하고 목적지는 192.168.0.1 로 보내는데 총 10개의 패킷을
보낸다. -h 옵션은 응답도 출력하도록 한 것이다. -h 옵션이 주어지지 않으면,
단순히 전송하는 정보만 출력할 것이다.

# packit -t icmp -s 8.8.1.1 -d 192.168.0.1 -c 10  -h
Mode:  Packet Injection using device: eth1

-| SND 1 |------------------------------------------------------------------

Timestamp:   10:28:54.469954
ICMP header: Type: Echo Request(8)  ID: 5854  Seqn: 56577  
IP header:   Src Address: 8.8.1.1  Dst Address: 192.168.0.1
    TTL: 128  ID: 53261  TOS: 0x0  Len: 28  

-| No Response From Peer |--------------------------------------------------

아래는 TCP 패킷을 보내는 것으로 목적지 포트 80에 TTL은 111 그리고 페이로드는 0x40 을
보낸 것이다.

# packit -t TCP -s 192.168.0.253 -d 192.168.0.200 -S 403 -D 80 -T 111 -p '0x 40'
Mode:  Packet Injection using device: eth1

TCP header:  Src Port: 403  Dst Port(s): 80  Flag(s): None
    Window: 65535  
IP header:   Src Address: 192.168.0.253  Dst Address: 192.168.0.200
    TTL: 111  ID: 49354  TOS: 0x0  Len: 41  

Writing packet(s) (1): .

-| Packet Injection Statistics |--------------------------------------------
Injected: 1  Packets/Sec: 1.0  Bytes/Sec: 41.0  Errors: 0

그리고 다음은 ARP 패킷을 만들어 전송한 것이다. 우선 -t 로 ARP 타입을 지정해 주고
-A 1 은 ARP Request 를 뜻하고 -x 는 보내는 IP 주소 -X 보내는 이더넷 주소를 정의한 것이다.

# packit -t arp -A 1 -x 1.2.3.4 -X 5:4:3:2:1:0  
Mode:  Packet Injection using device: eth1

ARP header:  Type: Request(1)
    Sender:  Protocol Address: 1.2.3.4  Hardware Address: 5:4:3:2:1:0
    Target:  Protocol Address: 0.0.0.0  Hardware Address: 0:0:0:0:0:0


Writing packet(s) (1): .

-| Packet Injection Statistics |--------------------------------------------
Injected: 1  Packets/Sec: 1.0  Bytes/Sec: 42.0  Errors: 0

여기서는 간단한 형태로만 만들어 패킷을 전송하지만, 사용하고자 하는 목적에 따라서
다양하게 만들어 볼 수 있다. 옵션을 여러개 사용하여 복잡해 보이지만,
막상 사용해 보면 옵션등이 사용하려는 목적을 대충 추정해 볼 수 있어 심플하게 패킷을 전송할 수 있다.

여기 블로그에서 언급한 많은 도구들 중에서 어떤것이 자기에게 더욱 적합한지는 여러분들이 판단하길 바란다.

From Rigel

2010년 12월 1일 수요일

자바스크립트기반의 분산 해쉬 크랙킹

일전에 클라우드 기반의 크랙킹에 대해서 소개한 적이 있는데,
또 다른 재미있는 것이 있어서 공유하고자 한다. 이름은 Ravan 이라고,
자바스크립트 기반의 분산 컴퓨팅 방식이다. 사이트는 http://www.andlabs.org/tools/ravan.html 이다.

분산되어 있는 여러 브라우저를 통해 Brute Force 공격을 수행한다는 것이다. 이것은 HTML5 의 WebWorkers 를 이용해 브라우저내에 백그라운드의 자바스크립트 스레드를 생성하여 해쉬를 크랙킹하기 위한
작업을 수행한다. 현재 지원되는 해쉬 알고리즘은 아래와 같다:

MD5
SHA1
SHA256
SHA512

작업을 수행하게 되면 사용하고 있는 컴퓨터의 CPU 가 크게 증가하는 것을
볼 수 있을 것이다. 재미있는 것이 이 WebWorkers 인것 같은데, 세부적인 것은
다음 URL 을 참고해 보기 바란다. 왠지 모르게 재밌고 다양한 것을 많이
해 볼 수 있지 않을까 한다. 만약 악의적으로 이용된다면...

http://www.whatwg.org/specs/web-workers/current-work/


[관련글]