2010년 9월 30일 목요일

자바스크립트 1K 의 세계

재미있는 Contest 가 있어서 소개한다. Contest 의 내용은 자바스크립트를 이용하여 1K 이내로
이쁘게 만드는 것이다. 1K 는 1024 바이트 이므로, 제한된 범위내에서 표현하려고 하면 꽤 머리좀 써야 할것 같다. 이래저래 공백과 불필요한 것들을 다 제거하게 되면 그래도 꽤 많은 문자를 사용할 수 있다. 하지만, 가독성은 상당히 떨어지게 된다.  일단, 다음 사이트를 방문하여 1위부터 10위까지의 데모 페이지를
한번 보시기 바랍니다.


아래 이미지는 5위에 기록된 바이너리 시계의 한 예이다. 140 바이트로 표현된 것으로, IT 인들에게 어울릴법한 시계다 :_)

2010년 9월 27일 월요일

두번째 CaseStudy, 한가지 원인으로만 단정짓고 시작하지 말자.

패킷분석이 쓰이는 곳은 다양하다. 네트워크 트래픽, 응용프로그램간의 트래픽 등등.
이번에는 응용프로그램 관점에서 한번 접근해 보고자 한다. 필자가 간단하게 동작시켜 운영하는 프로그램이 하나 있었다. 자동으로 FTP 에 연결하여 파일을 전송시키는데, 그 과정이 빠르게 이뤄지지 않고 눈에 보일만큼의 어느정도 Delay 가 발생하고 있었다. 이런 경우 다양한 원인이 존재하겠는데, 일단 다음과 같이 하나하나씩 문제의 원인을 찾아나가 보았다.

1) FTP 클라이언트와 서버간 트래픽 확인

tcpdump 를 이용하여 트래픽 덤프를 시작한후, 수동으로 FTP 전송 프로그램을 실행하였다. 다음과 같은 트래픽을 관찰할 수 있었는데, NBT UDP 패킷인 Query 가 보였다. 대략 보면 14:21:18 에 나타났고, 14:21:21 까지 지속되었다. 여기서 몇 초간의 지연이 발생하는 것을 확인하였고, 왜 이런 형태가 나타나는지 찾아야 하는 것이다.

# tcpdump -i eth0 host 192.168.x.x
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:21:18.246571 IP test.netbios-ns > comm-gw.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
14:21:18.246869 IP comm-gw.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
14:21:19.746141 IP test.netbios-ns > comm-gw.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
14:21:19.746448 IP comm-gw.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
14:21:21.246179 IP test.netbios-ns > comm-gw.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
14:21:21.246426 IP comm-gw.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
14:21:22.766782 IP test.1044 > comm-gw.ftp: S 1801204199:1801204199(0) win 65535 <mss 1460,nop,nop,sackOK>
14:21:22.766806 IP comm-gw.ftp > test.1044: S 1835421802:1835421802(0) ack 1801204200 win 5840 <mss 1460,nop,nop,sackOK>

2) nslookup 으로 혹시 DNS 쿼리 확인
혹시나 클라이언트에서 DNS resolving 이 관련있나 nslookup 을 통해 확인하였으니 정상적으로 빠르게 응답해 주었음

3) 넷바이오스와 관련한것 찾아 제거해보기

일단 넷바이오스와 관련한 것이다 보니 시스템 상에서 이와 관련한 것을 Disable 한 후 같은 증상이 계속 일어나는지 확인하기로 하였다. TCP/IP 설정의 고급에서 Wins -> Disable TCP/IP Over Netbios 한 후 UDP 패킷이 발생하지 않았다. 이제 해결된 것인가 ? 하고 FTP 연결을 다시 해봐도 똑같이 Delay 는 계속 발생되고 있다. 분명 이전에 나타났던 트래픽은 나타나지 않지만 지연은 계속된다는 점이다.

시스템 관점에서 몇 가지를 다 확인해 보아도 증상은 해결되지 않았다.

4) 마지막으로, 응용프로그램을 직접 디버깅

호출되는 FTP 응용프로그램을 직접 디버깅을 하여 무엇이 원인인지 세부적으로 접근해 보고자 하였다. 사용한 디버거는 Ollydbg 이며, 실행을 해 나가면서 각 코드별로 Delay 되는 부분은 없는지 찾아나갔다. 그러다, 0x0040A5E3 지점에서 Delay 가 발생하는 것이었다.


gethostbyaddr 를 Call 하면서 발생된 문제였던 것이다. 대략 여기서 5-10 초 정도의 딜레이가 발생하였던 것인데, 이후 사용하는 DNS 에서 Reverse DNS 레코드를 추가하였더니 문제가 깔끔히 해결되었다. 바로 gethostbyaddr API 를 호출하는 과정에서 Delay 가 발생한다는 사실을 알았기 때문이다.

물론, Delay 가 발생하여도 시스템 동작상에는 큰 이슈가 없었지만. 향후 이런 지연 요소가 시스템 전체 과정상에 영향을 줄 수 있는 부분이기 때문에 확실히 해결하고 넘어가는 것이 좋다.

이번 CaseStudy 로 다뤄본 부분은, 직접적인 네트워크 원인으로만 단정짓지 말고 분석을 시작하지 말자는 점이다. 문제해결을 위해 전체를 들여다보고 분석하는 과정에서 트래픽에서 발생된 특정 패턴으로 인해 이게 문제의 원인이다 하고 가정을 해 버리면 접근관점이 한정되어 문제해결 파악에 시간이 걸리게 된다. 위에서 발생한 UDP 패킷만 보고 왜 이게 발생하지 하고 시스템과 네트워크의 관점에서만 계속 문제를 찾다보면 해결이 어려워진다는 것이다. 물론, 결국은 gethostbyaddr 에 의해 발생되어 전체적인 관점에서 보면 네트워크와도 연결이된 것이 맞지만. 필자가 말하는 것은, 문제 원인 파악에는 직접적으로 문제의 원인을 파악하고자 하는 그 대상으로부터 차차 찾아 넓혀가야 한다는 것이다.

즉, 문제의 원인 파악에는 혼자가 아니라 각 관련 담당자들의 도움이 있어야 해결이 쉬워진다. 이와 관련해서는 다음 CaseStudy 에서 왜 협업이 필요한지에 대해서 의견을 나눠보도록 하겠다.


[참고]
1. gethostbyaddr()

2010년 9월 24일 금요일

펄 CPAN 오류 - tar,gzip, bzip2 를 못 찾는다.

펄 사용중에 다음과 같은 오류가 나오는 경우가 있다. 이것은 tar,gzip 등의 경로가 제대로
지정되어 있지 않아 나타나는 경우이다.

CPAN.pm needs either the external programs tar, gzip and bzip2 installed. Can’t continue.

이럴 때는 다시 경로만 다시 잡아주면 문제가 쉽게 해결된다. 일단 모듈 CPAN 을 통해 shell 로 접속한다.

# perl -MCPAN -eshell
cpan shell -- CPAN exploration and modules installation (v1.9402)
Enter 'h' for help.

그리고 conf 옵션을 통해 tar, bzip2, gzip 의 경로를 설정해 주고 저장해 주면 된다.

cpan[1]> o conf tar /bin/tar
tar  [/bin/tar]
Please use 'o conf commit' to make the config permanent!

cpan[2]> o conf bzip2 /bin/bzip2
bzip2 [/bin/bzip2]
Please use 'o conf commit' to make the config permanent!

cpan[3]> o conf gzip /bin/gzip
gzip   [/bin/gzip]
Please use 'o conf commit' to make the config permanent!

cpan[4]>  o conf commit
commit: wrote '/usr/lib/perl5/5.10.0/CPAN/Config.pm'

cpan[5]> quit
No history written (no histfile specified).
Lockfile removed.


2010년 9월 20일 월요일

방송통신위원회, 국내 IPv6 전면적 도입 계획

ITU and IPv6 Website - Articles & Documents: Other Documents

이미지출처 : www.itu.int


최근 기사에서, 방통위가 내년 6월부터 IPv4 할당을 중지하고 IPv6 를 전면적으로 도입한다고 합니다.
저도 올 초부터 계속 이야기를 했지만, 이제 IPv6 로의 전환은 필연적인것 같고, 현재 IPv4 할당 주소가 남아있는 시점은 내년 5월 말입니다.

방통위도 차세대인터넷주소(IPv6)전환 추진계획을 수립했다고 하니 이제 항상 IPv6 로 언제바뀔지 하는 고민은 정말 현실로 이뤄질것 같네요. 하지만 예전에도 수 많은 IPv6 전환 예상이 있었는데, 아직까지도 큰 진전이 없었는데, 이번에는 실질적으로 주소가 내년에 고갈되는 만큼 확실하겠죠.

방통위에서 밝힌 계획들을 보면
- 국내 IPv4 주소 할당 중지시점을 2011년 6월로 선포
- 상용웹서비스, IPTV, 3세대 이동통신 서비스에 IPv6 적용 시범사업 연내 추진
  (새로 구축되는 LTE 통신망은 초기부터 IPv6 기반으로 설계)
- ISP 업체의 백본망 2013년까지 100% 전환, 가입자망 45% 까지 전환

내년 6월 과연 실천이 될지 지켜보도록 하죠.
그리고 이제 IPv6 에 대해서도 더 많은 블로깅을 해야 겠네요 :-)


2010년 9월 18일 토요일

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

capinfo, tshak 등을 실행하다 아래와 같은 에러를 얻은 경우가 있다.

[Error] (pcap: File has 1279743227-byte packet, bigger than maximum of 65535)
[Error] (pcap: File has 1174099712-byte packet, bigger than maximum of 65535)
[Error] (pcap: File has 808345964-byte packet, bigger than maximum of 65535)                        

패킷 사이즈만 보면 엄청난 크기이다. 그런데 잘 생각해 보면 이상하다고 생각되는 부분이 있을 것이다.
아래 관련한 소스를 찾아보면 한번 살펴보자.

wireshark1.2.9/wiretap/libpcap.c 를 한번 들여다 본 것이다.

    if (hdr->hdr.incl_len > WTAP_MAX_PACKET_SIZE) {
        /*
         * Probably a corrupt capture file; return an error,
         * so that our caller doesn't blow up trying to allocate
         * space for an immensely-large packet, and so that
         * the code to try to guess what type of libpcap file
         * this is can tell when it's not the type we're guessing
         * it is.
         */
        *err = WTAP_ERR_BAD_RECORD;
        if (err_info != NULL) {
            *err_info = g_strdup_printf("pcap: File has %u-byte packet, bigger than maximum of %u",
                hdr->hdr.incl_len, WTAP_MAX_PACKET_SIZE);
        }
        return -1;
    }

일단, 위에서 발생한 에러의 문구를 볼 수 있다. hdr->hdr.incl_len 이 WTAP_MAX_PACKET_SIZE 보다 큰 경우에 발생한 것인데 WTAP_MAX_PACKET_SIZE 값 또한 찾아보자.
이 값은 wtap.h 에 아래와 같이 정의되어 있다.

/*
 * Maximum packet size we'll support.
 * It must be at least 65535.
 */
#define WTAP_MAX_PACKET_SIZE            65535

최대 패킷 사이즈라고 정의되어 있다. 즉 헤더의 패킷 사이즈를 생각해보면 2 바이트로 최대 65535 까지
가능한 것이다. 그러므로 이론적으로 이 값을 초과할수는 없는 것이기에 패킷 파일이 깨졌을 가능성이 높은 것이다.

한번 테스트용 파일을 tcpdump 를 통해서 오픈 해 봤다. bogus savefile header 라는 문구가 보인다.

# tcpdump -n -r test.cap | wc -l
reading from file test.cap, link-type EN10MB (Ethernet)
tcpdump: pcap_loop: bogus savefile header
1407

이번에는 tshark 를 통해 파일을 읽어 보겠다.

tshark: "test.cap" appears to be damaged or corrupt.
(pcap: File has 781876-byte packet, bigger than maximum of 65535)

781876 바이트를 가지고 있다고 에러가 발생한다. 그리하여 781876 을 HEX 로 변환하여 해당 값을
찾아보니 나타난다.

# hexdump -C test.cap | grep "34 ee 0b"
00072eb0  34 ee 0b 00 66 00 00 00  66 00 00 00 01 00 5e 00  |4...f...f.....^.|

결국은 헤더파일에 잘못된 값이 들어가 있었기 때문에 발생한 것이다. 이렇게 파일이 깨지는 경우도 있으니, 이와 같은 메시지를 얻는 다면 참고하기 바란다.

2010년 9월 17일 금요일

NetBSD 의 새로운 패킷 필터 : NPF

OCS Inventory NG - OCS Inventory NG Supported Operating Systems

이미지출처 : www.ocsinventory-ng.org




NetBSD 에서 새로운 패킷 필터인 NPF 를 발표했습니다.  NPF 는 NetBSD 의 세번째 네트워크 패킷 필터로,
멀티프로세스 기반의 고성능으로 디자인 되었습니다.

이 NPF 는 IP Filter, PF 다음의 버전으로 앞으로 기대가 됩니다. 주요 기능은 아래와 같으며, 번역하면 더 이상해 질 수 있어 원문 그대로를 소개합니다.

* MP-safety and locklessness for scalable MP performance: no longer is the packet filter the bottleneck in your multicore router

* Fast hash-table and red-black tree lookups

* Stateful packet filtering, Network Address Port Translation (NAPT),
  and Application-Level Gateways (ALGs) for, e.g., traceroute

* The N-Code processor, a packet-inspection engine inspired by BPF:
  the N-Code processor is programmed to match packets using generic,
  RISC-like instructions and a few CISC-like instructions for common
  patterns such as IPv4 addresses

* Familiar configuration syntax and utilities

* Modularity and extensibility: users extend NPF by loading a kernel
  module.  NPF provides developers with an extensions API.  NPF rules
  can embed a hook that invokes an extension

아직 자세하게 많은 내용이 공유되지 않았지만, 조만간 더 많은 내용이 공개될 것입니다.
현재 npfctl, npf.conf, npf-ncode 등의 MAN 페이지를 확인할 수 있습니다. 세부적인 내용은
아래 참고 정보를 보시면 되겠습니다.

[참고]
1. NetBSD 에서 공식 발표한 NPF 관련 글
2. MAN Pages 검색
3. 관련 소스

2010년 9월 15일 수요일

8자리 패스워드는 저리가~ 12자리 패스워드를 사용하자

패스워드 이야기를 해 보자. 인터넷이 일상화 되면서 오히려 패스워드는 머리를 골치아프게 하는 놈이 되었다.
쇼핑을 하든 멀 하든, 국내 사이트는 특히 사이트에 가입을 요구한다. 이건 머, 울며겨자 먹기로 가입하는 경우도 허다하다. 또, 무슨 정보를 그렇게 많이 물어보고 기록하는지.

국내 외 사이트는 가입절차도 Simple 하다. 그냥 아이디 패스워드 정도다. 국내는 주민번호에, 회사 전화번호, 자택 전화번호, 주소, 결혼유무, 취미 등 아주 다양하다. 그런데 이 정보가 왜 필요하냐고. 묻고싶다.
더 답답한 것은, 이렇게 모은 정보를 안전하게라도 관리해야지. 허술한 보안정책에 개인정보는 인터넷 공간을 이리저리 떠 돌아 다니고 있다.

개인정보 이야기는 다음에 하고, 사이트 마다 가입시 기록하는 이 패스워드. 한 개로 사용하자니 위험하고 이래저래 달리 사용하자니 복잡하고. 거기다 몇 자지로 사용해야 할지도 고민이다. 이 패스워드와 관련한 글 한개를 보아서 같이 공유해 보고자 한다.

보통 많이 사용하는 8자리 이내의 패스워드 말고 12자리의 패스워드에 대한 이야기 이다. 조지아공대에서 발표한 보고서에 따르면 8자리 문자의 패스워드는 2시간 이내에 깰 수 있었다고 한다. 그런데 만약 12자리의 패스워드를 사용하면 8 자리를 깬것과 같은 컴퓨팅 환경에서 17,134 년이나 걸린다는 것이다.  12자리 이상은 거의 현실적으로 깨기 힘들어진다는 것이다.

그러므로 8자리 보다는 이제 12 자리의 패스워드를 사용하기를 권장한다고 한다.
한 예로, 한 해커가 초당 1조개의 패스워드를 조합할 수 있다는 가정하에 11 자리의 패스워드는 크랙하기 까지 180년이 소요되지만, 한 자리 문자를 늘리는 것만으로도 그 가능성은 아주 희박해진다. 왜냐 바로 17,134 년으로 확 높아지기 때문이다.

컴퓨팅 파워가 높아질 수록 패스워드 길이도 그에 따라 높아지도록 요구될 것이다. 우리는 이제 12 자리에 익숙해져 가야 할 것같다.

[참고]
1. 12-character passwords in the future

안드로이드의 또 다른 패킷 덤프/분석 앱

일전에 안드로이드 패킷 덤프 프로그램인 안드로 샤크를 소개한 적이 있습니다. 그 당시 베타가 진행중이었는데, 추가적인 소식이 계속 없었죠. 그 와중에 다른 프로그램이 공개되었습니다. 공개된 시점은 좀 되었는데, 제가 게을러서 이제야 소개하네요. 이미 아시는 분도 있겠지만,  안드로이드 마켓에서 'shark' 로 검색해 보시면 찾을 수 있습니다. 2개의 프로그램이 있는데요

- Shark for Root
- SharkReader

입니다. SharkReader 는 이름과 같이 PCAP 을 볼 수 있는 프로그램이고요, Shark for Root 는 패킷 덤프 프로그램입니다. 제가 tcpdump 를 통한 패킷덤프를 소개하였는데, GUI 로 조금은 편하게 패킷 덤프를 할 수 있습니다. Shark for Root 는 아래와 같은 화면입니다.

단, 패킷덤프를 위해서는 루트권한이 필요합니다. 그리고 SharkReader 는 제가 가진 모토로이 폰에서 실행은 되는데 세부 패킷정보를 보는 것은 제대로 나오지를 않더군요. 갤럭시 S 에서는 제대로 나오는 것을 확인했습니다. 아직 App 이 퍼펙트 하지는 않는거 같네요.

아, 한가지 빠트린 것이 있는데. 위 프로그램을 설치하면 Shark Updater 라는 것도 하나 생깁니다. 이건 PCAP 파일을 읽어들여 파싱해 보여주기 위한 모듈들을 다운로드 합니다.

2010년 9월 12일 일요일

SSH 터미널 Putty 에서 한글 사용하기

*NIX 시스템에 SSH 로 접근하여 사용하기 위해서는 SSH 클라이언트 프로그램이 필요하다. 나의 경우는
무료로 사용가능한 Putty 를 많이 사용하고 있다. 따로 설치할 필요도 없이, 그냥 실행하는 것 자체로도
사용할 수 있으니 편하다. 그런데 Putty 를 사용하다 보면 한글 사용에 문제가 생기는 경우가 있다.
이럴때는 레지스트리 키를 수정하여 한글이 지원될 수 있도록 변경할 수 있다.

우선, 명령어 실행창에서 (시작->실행) regedit 를 실행 후 아래의 키 값으로 찾아가야 한다.

HKEY_CURRENT_USER -> Software -> SimonTatham -> PuTTY -> Sesseions -> 변경원하는 세션 선택

세션 키 아래에 보면 본이 설정하여 저장하였던 세션 정보를 볼 수 있는데, 해당 세션을 선택하면
FontCharSet 값을 볼 수 있다.

바로 이 FontCharSet 16 진수 0 값을 -> 81로 변경해 주면 된다.



나의 경우는 *NIX 터미널 LANG 환경은 en_US.UTF-8 로 사용하고 있다.
Putty 를 사용하다 보면 자주 이걸 잊어 버리고 또 찾아보게 되어서 공유하고자 여기에 기록을 해 둔다.
Putty 를 이용하는 분들에게 도움이 되길 바란다.

[참고]
1. Putty

2010년 9월 10일 금요일

Bit-Twist 로 패킷파일의 편집과 생성까지 자유자재로..

지금까지 패킷 편집 도구를 몇 가지 소개하였다. 패킷생성기능, 편집 기능등. 패킷인사이드를 검색해 보면 몇 가지를 찾아볼 수 있을 것이다. 이번 도구의 이름은 Bit-Twist 로 패킷을 생성하고, 편집할 수 있는 기능까지 갖추고 있다. 사용방법도 너무 쉬워서 한번 사용예제를 보는 것만으로도 쉽게 이해가 될 것이다.

- bittwist  : PCAP 기반의 패킷 생성기
- bittwistb : PCAP 기반의 이더넷 브릿지
- bittwiste : PCAP 파일 에디터

일단, 다음의 경로를 통해 파일을 다운로드 받을 수 있다.


아차, 여기 예는 리눅스 기반에서 소개한 것이지만. 윈도우에서도 사용가능하다는 점!

도움말은 -h 를 통해서 볼 수 있고, 몇 가지 옵션을 살펴보도록 하자.  우선, 패킷 생성기인 bittwist 로 시작해 보자.  -d 옵션은 현재 사용가능한 네트워크 인터페이스를 보여준다.

# bittwist -d
1. eth0
2. any (Pseudo-device that captures on all interfaces)
3. lo

-i 를 통해 인터페이스를 정할 수 있고, 인자로 패킷파일을 주면 해당 인터페이스로 패킷을 발송한다.

# bittwist -i eth0 test.pcap
sending packets through eth0
trace file: test.pcap
^C
1235 packets (1041023 bytes) sent
Elapsed time = 36.533449 seconds

위 예를 보면 1235 개의 패킷을 전송하였고, Ctrl+C 를 눌러 중단했다. 바로 전송이 빠르게 이뤄지지 않았기
때문에 수동으로 중지한 것이다. 이럴때 -m 옵션을 사용하면 즉시 전송하게 된다.

# bittwist -i eth1 test.pcap -m 0
sending packets through eth1
trace file: test.pcap

2040 packets (1578854 bytes) sent
Elapsed time = 0.037914 seconds

-m 옵션을 사용하였더니 즉시 패킷이 전송되었고, 2040개의 패킷이 다 전달되었다.
-c 옵션은 전송할 패킷 갯수를 지정할 수 있다. 만약 test.pcap 에서 10 개의 패킷만을 전달하고 싶다면 -c 10 을 사용하면 된다.

# bittwist -i lo test.pcap -m 0 -c 10
sending packets through lo
trace file: test.pcap

10 packets (4247 bytes) sent
Elapsed time = 0.000414 seconds

간단한 옵션 몇가지를 통해 금방 패킷을 전송할 수 있는 것을 보았다. 이와 비슷한 기능을 가진 도구로는 tcpreplay 가 기억이 날 것이다.  자, 이번에는 편집 기능을 사용 예를 통해 한번 알아보도록 한다.

1) 패킷에서 1-2 까지만의 패킷을 뽑아내 저장해 보자.

# bittwiste -I test.pcap -O rigel.pcap -R 1-2
input file: test.pcap
output file: rigel.pcap

2 packets (128 bytes) written

2) 패킷 덤프 할 시간을 지정해 저장하기

일단 PCAP 파일의 첫 시간을 살펴보았더니 2010년7월21일 10시26분이다.

# tcpdump -r test.pcap -tttt | more
reading from file test.pcap, link-type EN10MB (Ethernet)
2010-07-21 10:26:39.659705 IP 179.222.51.219.3645 > 147.245.206.234.www: S 592977294:59297
7294(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

그리고, -S 옵션을 통해 시작시간과 끝 시간을 지정한다. 참고로 -I 옵션은 Input 파일 -O 옵션은 Output 파일을
뜻한다.

# bittwiste -I test.pcap -O rigel.pcap -S 21/07/2010,10:20:00-21/07/2010,10:26:40
input file: test.pcap
output file: rigel.pcap

944 packets (866907 bytes) written

3) IP 를 변경해 보자.

# tcpdump -r rigel.pcap
reading from file rigel.pcap, link-type EN10MB (Ethernet)
10:26:39.659705 IP 179.222.51.219.3645 > 147.245.206.234.www: S 592977294:592977294(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

위 172.222.51.219 출발지 주소를 -> 192.168.0.0 으로 변경해 보자.

# bittwiste -I test.pcap -O rigel.pcap -R 1 -T ip -s 179.222.51.219,192.168.0.0
input file: test.pcap
output file: rigel.pcap

1 packets (66 bytes) written

# tcpdump -r rigel.pcap
reading from file rigel.pcap, link-type EN10MB (Ethernet)
10:26:39.659705 IP 192.168.0.0.3645 > 147.245.206.234.www: S 592977294:592977294(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

확인해 보면 출발지 주소가 설정한대로 변경되었다.

4) -R 옵션을 사용하지 않으면 모든 범위에 적용된다.

# bittwiste -I test.pcap -O rigel.pcap  -T ip -s 179.222.51.219,192.168.0.0
input file: test.pcap
output file: rigel.pcap

2040 packets (1578854 bytes) written

3번과 같은 예제인데, 편집된 패킷 개수를 보면 2040 개이다. -R 을 사용하지 않아 전체에 적용이 된 것이다.

5) 포트 번호 변경

# bittwiste -I test.pcap -O rigel.pcap -R 1 -T tcp -d 80,8080
input file: test.pcap
output file: rigel.pcap

1 packets (66 bytes) written

6) Payload 삽입하기

# echo "hahaha" | xxd
0000000: 6861 6861 6861 0a                        hahaha.

-X 옵션을 통해 위 HEX 값을 삽입.

# bittwiste -I test.pcap -O rigel.pcap -R 1 -L 4 -X 686168616861 -T tcp
input file: test.pcap
output file: rigel.pcap

1 packets (72 bytes) written

편집된 rigel.pcap 을 아래와 같이 확인해 보면 Payload 가 삽입된 걸 볼 수 있다.

# tcpdump -r rigel.pcap -XX
reading from file rigel.pcap, link-type EN10MB (Ethernet)
10:26:39.659705 IP 179.222.51.219.3645 > 147.245.206.234.www: S 592977294:592977300(6) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
        0x0000:  001e 4a48 3900 0024 2119 7756 0800 4500  ..JH9..$!.wV..E.
        0x0010:  003a 7ee5 4000 3006 813f b3de 33db 93f5  .:~.@.0..?..3...
        0x0020:  ceea 0e3d 0050 2358 1d8e 0000 0000 8002  ...=.P#X........
        0x0030:  2000 7bdf 0000 0204 05b4 0103 0302 0101  ..{.............
        0x0040:  0402 6861 6861 6861                      ..hahaha
    
이외 옵션을 잘못사용하면 아래와 같은 에러메시지를 얻게 된다.

bittwiste: invalid header specification

이 도구를 소개하면서 느낀것은 다른 도구들보다 사용이 쉬웠다. 도움말만 참고해서도 쉽게 사용할 수 있을
만큼 간단하고 기능또한 필요한 것으로 잘 모아져 있다.

패킷을 편집하고 생성하는 기능을 원한다면 이 도구가 큰 도움이 될 것이다.

2010년 9월 6일 월요일

와이어샤크에서 2기가 이상의 파일이 열리지 않는다면...

패킷파일을 다루다 보면 보통은 우리가 패킷파일을 오픈하고 살펴볼 수 있는 크기의 파일이 많다.
너무 파일이 커 버리면 분석하는것 자체도 힘들기 때문에..

[관련글] 2010/01/27 Rigel 100 기가 가 넘는 패킷 파일이라고 ? 

그런데 때로는 패킷파일이 생각 이상으로 커지기도 한다. 필자가 이전에 쓴 포스팅에서는 100 기가가
넘는 패킷파일도 있었다고 이야기 하였다. 이번에는 그 정도까지는 아니지만, 대략 2기가가 넘는 파일을
읽어 들이려고 했을때 아래와 같은 에러 메시지를 얻을 수가 있다. (물론, 와이어샤크를 기준으로 했을때이다)

capinfos: Can't open /tmp/test.pcap: Value too large for defined data type

와이어샤크에서는 기본적으로 2기가 이상의 파일을 읽어들일 수가 없다. 이유는 int32 값을 사용하고 있기 때문인데, int32 의 값 범위는 아래와 같다.

−2,147,483,648 to 2,147,483,647

그래서 2기가 정도로 제한된 것이다. 일단 간단하게 나마 해결책은 64비트로 변경해 주는 것이다. 새롭게 다시 컴파일을 해 주면 되는데 아래와 같이 설정후에 컴파일을 다시 해 보자.

CFLAGS=-D_GNU_SOURCE\ -D_FILE_OFFSET_BITS=64 ./configure --enable-wireshark=no --without-zlib


            Build profile binaries : no
                   Use pcap library : yes
                   Use zlib library : no
                   Use pcre library : no
               Use kerberos library : no

./configure 다음의 옵션은 여러분들의 필요에 따라 맞게 사용하면 되고, 중요한 것이 앞쪽에서 CFLAGS 에 설정한 FILE_OFFSET_BITS 를 64로 설정한 것이다. 64 비트로 했을때의 값은 아래와 같다.

−9,223,372,036,854,775,808 to +9,223,372,036,854,775,807

큰 파일을 오픈하는데는 걱정하지 않을 수준이다.

컴파일을 하고, 파일을 읽어보자. (여기서는 tshark 를 사용하지 않고 기본 정보를 얻기 위해 capinfos 를 사용하였다.)

# ./capinfos  /tmp/test.pcap
File type:           Wireshark/tcpdump/... - libpcap
File encapsulation:  Ethernet
Number of packets:   2936376
File size:           3062134522 bytes
Data size:           3015152482 bytes
Capture duration:    310 seconds
Start time:          Tue Aug 31 05:10:43 2010
End time:            Tue Aug 31 05:15:53 2010
Data byte rate:      9737875.87 bytes/sec
Data bit rate:       77903006.99 bits/sec
Average packet size: 1026.83 bytes
Average packet rate: 9483.46 packets/sec

짜잔. 위 예와 같이 3기가 파일도 이제는 오픈이 된다.  이와 관련한 비공식 패치는 아래 참고의 2번을 참고하기 바란다.

[참고]
1. 2147483647
2. 와이어샤크 int32 패치

2010년 9월 5일 일요일

ProcNetMonitor 로 트래픽을 유발하는 프로세스를 쉽게 찾아보자.

윈도우에서 사용 가능한 프로세스 네트워크 모니터 도구가 있어 소개한다. 여러가지 도구들이 있긴 한데, 오늘은 이 도구가 사용하기도 아주 쉽고, 유용할거 같다는 생각이 든다. 윈도우에서 악성코드에 감염되었다고 가정해보자.  그리고, 트래픽 확인을 위해 와이어샤크를 통해 네트워크 트래픽이 발생되고 있음을 확인한다. 그런데, 윈도우의 어떤 프로세스가 이 트래픽을 유발하고 있는지 알기가 어려운 것이다. 특정 프로세스에서 발생하면 쉬운데,
정상 서비스 프로세스에 인젝션 되어 발생되면 까다로워진다.

아래 프로그램은 각 프로세스별로 TCP, UDP, 연결 카운트를 보여주고 있다. 즉, 이 카운트가 크게 증가되었거나 하면 해당 프로세스를 의심해 볼 수 있다. 프로세스를 클릭하여 살펴보면, 어디로 연결되었는지 세부 정보를 확인해 볼 수가 있다. 이 도구의 사용방법을 설명할 것도 없이 워낙에 심플해서, 처음 이런류의 프로그램을 접하는 분들이라도 알 수 있을 정도이다.


Properties 를 누르면 프로세스에 대한 속성을 확인해 볼 수 있으며, Export 를 하면 프로세스 리스트를 HTML 파일로 저장할 수 있다.  다운로드는 다음의 경로에서 할 수 있다.


그리고, 이 프로그램이외에 분석에 유용하게 사용할 만한 도구들도 몇가지 있으므로, 한번 살펴보기 바란다.
패킷을 분석하는데는 그 목적이 있고, 그 목적을 달성하기 까지는 용도에 따라서 이러한 도구가 유용하게 사용될 것이다.

2010년 9월 2일 목요일

NMAP 스캐너를 통해 만든 웹 아이콘 지도

NMAP 에서 재미있는 리서치 결과를 내 놓았다. NMAP 시큐리티 스캐너와 스크립트 엔진을 이용해 뉴욕타임즈, 구글, 엔가젯 같은 수 많은 사이트를 스캐닝 하였다.
스캐닝은 HTML 링크의 아이콘 태그의 파일과 /favicon.ico 를 하였는데, Unique 하게 수집된 아이콘 파일이
328,427 개 였다고 한다. 이중 288,945 개가 적합한 형태의 이미지였는데, 이걸 종합적으로 합쳐 아이콘을
이용한 맵을 만들었다. 아이콘이 클수록 규모도 크다고 볼 수 있는 것이다.  아이콘을 보게되면 역시나
구글이 가장 큰 크기를 차지하고 있고, 그 다음으로는 페이스북, 유투브, 야후, MSN 등이 크다.

[이미지 출처 : NMAP 사이트 ]

우선 Favicon 을 이용해 지도를 만들었다는 사실이 참 재미있다. 그럼 여기서 사용한 스크립트는 무엇일까?
웹 페이지에서 Favicon 아이콘을 얻는 이 스크립트는 HTTP-Favicon.nse 이다. 이 스크립트는 다음 두가지
방법을 통해 아이콘을 확인한다.

- HTML 파일의 <link rel="icon"> 태그를 파싱
- /favicon.ico 확인

NMAP 에서의 스크립트 사용은 아래와 같다 :

nmap --script=http-favicon.nse --script-args favicon.root=<root>,favicon.uri=<uri>

스크립트를 만드는데 이용된 언어는 Lua 이다. 와이어샤크에서도 바로 이 Lua 가 이용된다.
시간이 주어지는대로 와이어샤크와 NMAP 에서의 스크립트 사용에 대해서 한번 소개할 예정이다.

아참, 그리고 Favicon 아이콘을 모르시는 분들을 위해:
이 아이콘은 브라우저 주소창에서 앞쪽에 표시는 작은 아이콘이다. 패킷인사이드에도 보면
주소창앞에 패킷인사이드 로고가 나오는데 바로 이것이다.

[1] WWW 아이콘 지도
[2] HTTP-Favicon NMAP 스크립트
[3] Favicon 이란?

2010년 9월 1일 수요일

와이어샤크 1.4.0 정식 버전 공개

6월초 와이어샤크 1.4.0rc1 버전이 공개된 후, 드디어 1.4.0 정식버전이 공개되었다.
정식버전과 함께 1.4.0rc2 버전도 공개되었으니, 이제 1.2.X 를 뒤로 하고,
1.4.0 의 새로운 기능들을 느껴보기 바랍니다.

몇가지 변경된 기능에 대해서는 저번 1.4.0rc1 에서 소개한적이 있고요,


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

세부적인 릴리즈 노트는 다음을 참고하세요.

[주요변화]
  • 와이어샤크의 메인 화면에서 컬럼을 쉽게 이동할 수 있거나, 오른쪽 클릭을 통해 조정이 가능
  • 파이썬 스크립트 지원
  • 많은 부분에서 메모리 누수 버그 Fix (그래서 그런가, 처리가 조금 자연스러운듯)
  • 와이어샤크 1.4 버전에서는 윈도우 2000을 지원하지 않음. 그러므로 윈도우 2000 에서는 1.2 나 1.0 버전을 이용해야 함
  • Manually Resolve Address 기능
  • 유용하게 이용할 수 있는 부분인데, IP 를 특정 이름으로 변경시켜 놓을 수 있다. 예를들어, 172.16.1.254 라는 것을 쓰고 있다면 이 기능을 통해 Internal Router 이런식으로 바꿀 수 있다.
  • 'Ignore Packet' 기능, 필요없는 패킷에서 오른쪽 클릭을 통해 무시해 버릴 수 있다.
  • 시간 표시가 이제는 시:분:초 형태로 출력된다.
  • 유닉스와 리눅스 환경의 와이어샤크에서 캡쳐 버퍼 사이즈를 설정할 수 있다.
  • 와이어샤크에서 바로 JPEG 파일을 오픈할 수 있음
    JPEG 파일을 와이어샤크로 던져보면 알 수 있다.
  • 새로운 프로토콜 지원
  • 이외 기타 등등