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/


[관련글]

2010년 11월 25일 목요일

리눅스에서 실제 사용가능한 메모리가 적게 보이는 경우는...메모리 확보하기

리눅스 시스템을 사용하다 보면, 분명 물리적 메모리는 많은데 실제 사용 가능한 메모리가 적게 나와
보이는 경우가 있다. 아래의 경우를 보자:

# free
             total       used       free     shared    buffers     cached
Mem:       8301476    7941864     359612          0     112468    7295056
-/+ buffers/cache:     534340    7767136
Swap:      2650684        676    2650008

전체 메모리는 8,301,476 에서 7,941,864 가 사용되고 있다. 그런데 실제 동작하고 있는 프로세스는
이 정도 만큼을 사용하지 않고 있다. free 에서 보이는 필드 중 cached 가 있다. 캐쉬가 되어 있는 것이
7,295,056 이다. 리눅스 커널은 성능향상을 위해 캐쉬를 하게되는데, 바로 이 수치이다. 이것은 일반적인
상황이며, 많이 사용되고 있다고 걱정할 부분은 아니다. 캐쉬는 실제 프로그램이 동작하기 위해서 사용되는
엑티브된 메모리 페이지 보다 우선순위가 낮게 주어진다.

예를 들어, 1기가의 메모리를 가지고 있는데, 프로그램에 의해 700 메가가 사용되고 있다고 하자. 200메가
정도도 캐쉬되어 있고 50메가 정도가 프리로 남아있는 상태에서 프로그램 동작하는데 150 메가 필요하다면,
캐쉬가 사용되는 부분을 실제 엑티브 되어 돌아가야 하는 프로세스에 할당이 되게 된다.

즉, 캐쉬는 시스템상에서 프로그램이 좀더 빠르게 응답/동작할 수 있도록 하는 것이다.

이런 캐쉬를 사용자에 의해 초기화 시킬 수도 잇는데, /proc/sys/vm/drop_caches 이용하면 된다.

# cat /proc/sys/vm/drop_caches
0
# echo 3 > /proc/sys/vm/drop_caches
# cat /proc/sys/vm/drop_caches
3

위와 같이 값이 3으로 변경된걸 볼 수 있고, 다시 free 를 해 보면 사용가능한 메모리가 크게 늘어나 있는 것을
확인할 수 있다. 대신 캐쉬되어 있는것은 크게 줄어 있다.

# free
             total       used       free     shared    buffers     cached
Mem:       8301476     436616    7864860          0        464      10568
-/+ buffers/cache:     425584    7875892
Swap:      2650684        676    2650008
# cat /proc/meminfo
MemTotal:      8301476 kB
MemFree:       7863868 kB
Buffers:          1492 kB
Cached:          13448 kB
SwapCached:          0 kB
Active:         394288 kB
Inactive:         3456 kB
HighTotal:     7461476 kB
HighFree:      7062172 kB
LowTotal:       840000 kB
LowFree:        801696 kB
SwapTotal:     2650684 kB
SwapFree:      2650008 kB
Dirty:             100 kB
Writeback:           0 kB
AnonPages:      382952 kB
Mapped:          10456 kB
Slab:            13140 kB
SReclaimable:     2968 kB
SUnreclaim:      10172 kB
PageTables:       1300 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:   6801420 kB
Committed_AS:  1179472 kB
VmallocTotal:   116728 kB
VmallocUsed:      4236 kB
VmallocChunk:   111888 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB

이 작업은 커널상에서 캐쉬를 클리어하게 만드는 것으로, 값은 1,2,3 중에 하나를 가질 수 있다. 1은 PageCache 를 2는 트리와 아이노드를 클리어하며 3은 1과2를 두개다 하는 것과 같다. 캐쉬를 클리어하기 전에는 sync 를 수행하고 하는 것이 좋으며, 이 drop_caches 기능은 커널 2.6.16 에 추가되었다.

일부 사용자는 캐쉬 클리어를 한 후 시스템이 Hang 이 되었다는 얘기도 있으므로 참고하길 바란다.

[참고]
1. http://encyclopedia.thefreedictionary.com/cache+memory
2. http://www.faqs.org/docs/linux_admin/buffer-cache.html

2010년 11월 23일 화요일

당신의 패스워드는 안전한가? 클라우드 기반 패스워드 크랙킹

패스워드 크랙킹을 하는데는 많은 컴퓨팅 자원이 필요하다. 많은 연산이 필요해지는데,
CPU 보다는 GPU 가 연산하는데 있어 훨씬 파워풀한 성능을 제공한다. 그런데,이런 GPU 도
클라우드 방식으로 이용하면 더욱 빠르게 처리 가능할 것이다. 최근 아마존에서 제공하는
EC2 클라우드 서비스를 이용해 패스워드를 크랙킹한 것이 소개되었다. 사용된 하드웨어
스펙은 아래와 같다:

22기가 메모리
33.5 EC2 컴퓨터 ( 인텔 제온 X5570, 쿼드코어 X 2)
NVIDIA M2050GPU X 2
1690GB 스토리지
64비트 플랫폼

CUDA-Multiforce 를 이용해 sha1 해쉬 파일을 크랙킹 하는데, 단지 49분이 걸렸다고 한다.
테스트로 이용된 해쉬는 총 14개이며, 아마존 EC2 를 이용하는데 비용은 1시간에 $2.10
이라고 한다. 클라우드 기반의 컴퓨팅 파워를 이용해 저렴한 패스워드 크랙킹이 가능해 진것이다.

일반적으로 이용되는 시스템 자원을 이용하면 얼마나 걸릴까? 때마침 잠깐 테스트할 만한
시스템도 있고하여 겸사겸사 테스트 해보았다. GPU 는 장착되어 있지 않고,
시스템 사양은 아래와같다 :

Intel(R) Xeon(R) CPU E5520  @ 2.27GHz 듀얼 쿼드코아 (16개 로지컬 CPU)
SAS 15K RPM 디스크
메모리 32 기가
64bit 플랫폼/리눅스

사용한 소프트웨어는 RainbowCrack 이다. 사전에 미리 테이블을 만드는 작업을
거쳐 최종 검증을 하게 되는데, 이 테이블을 만드는 사전 작업이 많은 시간이 소요된다.

1. 우선 앞서 예제에서 소개되었던 해쉬는 아래와 같다.

# more sha1_hashes.txt
EB45E66E03EE06E74AC824081C7A71352E51DF90
A94B95A7A4D432DE056B0030DA879AF841376069
3B615E3CD3ACA03AC818C7752A109EC7E2168532
8F2005004F8BAA7A1090A9BF3B03C48D38E78157
26BFB52D1809F04EAD2B7F5C002C1EAA7A584696
7110EDA4D09E062AA5E4A390B0A572AC0D2C0220
1902E3D6FC4E78A0BCC50BA12B882769AFBF4A8C
BFE06C47BE2390ACA934AB6A128C141DCEB4072F
CD3724AC40034097A3D27865D710E4F791B6AEDB
A9993E364706816ABA3E25717850C26C9CD0D89D
0D824508182A1AA0EEF9A0B6EE52F8A32AF06F0A
5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
EF8420D70DD7676E04BEA55F405FA39B022A90C8
DA39A3EE5E6B4B0D3255BFEF95601890AFD80709

2. rtgen 을 이용해 레인보우 테이블을 생성한다.  이때 패스워드의 길이는 최소 1 에서
6 사이의 길이로 한 것이다.

# time ./rtgen sha1 ascii-32-95 1 6 1 3800 33554432 0
rainbow table sha1_ascii-32-95#1-6_1_3800x33554432_0.rt parameters
hash algorithm:         sha1
hash length:            20
charset:                 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
charset in hex:         20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e
charset length:         95
plaintext length range: 1 - 6
reduce offset:          0x00010000
plaintext total:        742912017120

sequential starting point begin from 0 (0x0000000000000000)
generating...
524288 of 33554432 rainbow chains generated (1 m 18.4 s)
1048576 of 33554432 rainbow chains generated (1 m 17.2 s)
1572864 of 33554432 rainbow chains generated (1 m 17.8 s)
2097152 of 33554432 rainbow chains generated (1 m 18.2 s)
2621440 of 33554432 rainbow chains generated (1 m 18.4 s)
3145728 of 33554432 rainbow chains generated (1 m 18.3 s)
3670016 of 33554432 rainbow chains generated (1 m 18.4 s)
4194304 of 33554432 rainbow chains generated (1 m 18.4 s)
4718592 of 33554432 rainbow chains generated (1 m 18.3 s)
5242880 of 33554432 rainbow chains generated (1 m 18.2 s)
5767168 of 33554432 rainbow chains generated (1 m 18.2 s)
(생략...)

real    83m51.179s

시간을 측정해 보았더니 83 분이 걸렸다. 적지 않은 시간이 걸렸는데, 이 작업이
진행되는 동안 CPU 는 100% 풀로 사용된 것이다. (16개의 Logical CPU)

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
29166 root      20   0  157m  13m 1012 S 1600  0.0  22:01.80 rtgen

3. 생성된 테이블을 rtsort 로 정렬을 한다.

# ./rtsort  sha1_ascii-32-95#1-6_5_3800x33554432_0.rt
sha1_ascii-32-95#1-6_5_3800x33554432_0.rt:
32361852928 bytes memory available
loading rainbow table...
sorting rainbow table by end point...
writing sorted rainbow table...

4. 만들어진 테이블을 이용해 패스워드 해쉬 파일을 크랙킹 해본다.

# ./rcrack sha1_ascii-32-95#1-6_0_3800x33554432_0.rt -l sha1_hashes.txt
33167699968 bytes memory available
1 x 536870912 bytes memory allocated for table buffer
851200 bytes memory allocated for chain traverse
disk: sha1_ascii-32-95#1-6_0_3800x33554432_0.rt: 536870912 bytes read
searching for 14 hashes...
plaintext of 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 is 1234
plaintext of cd3724ac40034097a3d27865d710e4f791b6aedb is Bwah
plaintext of 8f2005004f8baa7a1090a9bf3b03c48d38e78157 is P4s$
plaintext of a9993e364706816aba3e25717850c26c9cd0d89d is abc
plaintext of 1902e3d6fc4e78a0bcc50ba12b882769afbf4a8c is bad
disk: finished reading all files

statistics
-------------------------------------------------------
plaintext found:                              5 of 14
total time:                                   7.49 s
  time of chain traverse:                     7.19 s
  time of alarm check:                        0.19 s
  time of wait:                               0.00 s
  time of other operation:                    0.11 s
time of disk read:                            0.64 s
hash & reduce calculation of chain traverse:  101026800
hash & reduce calculation of alarm check:     3773101
number of alarm:                              3140
speed of chain traverse:                      14.04 million/s
speed of alarm check:                         19.96 million/s

result
-------------------------------------------------------
eb45e66e03ee06e74ac824081c7a71352e51df90  <not found>  hex:<not found>
a94b95a7a4d432de056b0030da879af841376069  <not found>  hex:<not found>
3b615e3cd3aca03ac818c7752a109ec7e2168532  <not found>  hex:<not found>
8f2005004f8baa7a1090a9bf3b03c48d38e78157  P4s$  hex:50347324
26bfb52d1809f04ead2b7f5c002c1eaa7a584696  <not found>  hex:<not found>
7110eda4d09e062aa5e4a390b0a572ac0d2c0220  1234  hex:31323334
1902e3d6fc4e78a0bcc50ba12b882769afbf4a8c  bad  hex:626164
bfe06c47be2390aca934ab6a128c141dceb4072f  <not found>  hex:<not found>
cd3724ac40034097a3d27865d710e4f791b6aedb  Bwah  hex:42776168
a9993e364706816aba3e25717850c26c9cd0d89d  abc  hex:616263
0d824508182a1aa0eef9a0b6ee52f8a32af06f0a  <not found>  hex:<not found>
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8  <not found>  hex:<not found>
ef8420d70dd7676e04bea55f405fa39b022a90c8  <not found>  hex:<not found>
da39a3ee5e6b4b0d3255bfef95601890afd80709  <not found>  hex:<not found>

위 결과와 같이 14개의 패스워드 중 5개를 발견하였다.  레인보우 테이블을 2개로
이용한 후에는 6개로 1개의 테이블을 이용했을 때보다 1개를 더 찾아내었다.
테이블을 더 만들어 해 보았더니 6개에서는 9개를 찾아냈다. (1개 테이블 생성에 80분이라고 하면,
6개 생성에만 8시간이 소요된 것이다)

# ./rcrack *.rt -l sha1_hashes.txt
32374755328 bytes memory available
6 x 536870912 bytes memory allocated for table buffer
851200 bytes memory allocated for chain traverse
disk: sha1_ascii-32-95#1-6_0_3800x33554432_0.rt: 536870912 bytes read
disk: sha1_ascii-32-95#1-6_1_3800x33554432_0.rt: 536870912 bytes read
disk: sha1_ascii-32-95#1-6_2_3800x33554432_0.rt: 536870912 bytes read
disk: sha1_ascii-32-95#1-6_3_3800x33554432_0.rt: 536870912 bytes read
disk: sha1_ascii-32-95#1-6_4_3800x33554432_0.rt: 536870912 bytes read
disk: sha1_ascii-32-95#1-6_5_3800x33554432_0.rt: 536870912 bytes read
searching for 14 hashes...
plaintext of 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 is 1234
plaintext of cd3724ac40034097a3d27865d710e4f791b6aedb is Bwah
plaintext of 8f2005004f8baa7a1090a9bf3b03c48d38e78157 is P4s$
plaintext of a9993e364706816aba3e25717850c26c9cd0d89d is abc
plaintext of 1902e3d6fc4e78a0bcc50ba12b882769afbf4a8c is bad
disk: finished reading all files
searching for 9 hashes...
plaintext of eb45e66e03ee06e74ac824081c7a71352e51df90 is nVidia
searching for 8 hashes...
plaintext of 0d824508182a1aa0eef9a0b6ee52f8a32af06f0a is GoOd!
plaintext of bfe06c47be2390aca934ab6a128c141dceb4072f is G0o|)
searching for 6 hashes...
plaintext of 3b615e3cd3aca03ac818c7752a109ec7e2168532 is W3a$eL
searching for 5 hashes...
searching for 5 hashes...

statistics
-------------------------------------------------------
plaintext found:                              9 of 14
total time:                                   18.14 s
  time of chain traverse:                     17.06 s
  time of alarm check:                        0.76 s
  time of wait:                               0.00 s
  time of other operation:                    0.32 s
time of disk read:                            2.87 s
hash & reduce calculation of chain traverse:  339161400
hash & reduce calculation of alarm check:     17185485
number of alarm:                              13776
speed of chain traverse:                      19.88 million/s
speed of alarm check:                         22.52 million/s

테이블을 생성하기 까지는 많은 시간이 걸리나, 테이블을 이용해서 찾는 경우는
금방 찾아진다. 그렇다면, 위와 같은 경우를 접목해 보면
클라우드 기반의 시스템 파워를 이용해 테이블을 크게 생성해 놓는다면
추후에 패스워드를 찾는데 오랜 시간이 걸리지 않는것이다. 패스워드 길이가 왜
짧으면 위험한지에 대한 이유를 알 수 있을 것이다. 다음 글은 왜 12자리의 패스워드를 사용해야 하는 가에
대한 포스팅이다.


각 개별 컴퓨팅 파워는 높아지고, 클라우드 방식의 활용은 점차 확대되고 있다. 여기서 필자가 이것을
소개한 이유는 크랙킹을 소개하고자 하는 것은 아니다. 이런 자원이 좋은 쪽으로 이용되면
다양한 과학발전등 큰 도움이 되지만, 악의적 형태로 이용되면 말 하지 않아도 알 것이다.

현재의 수준이 이렇다는 것을 함께 공유하고 싶다. 왜 자꾸 '보안' 이라는 것에 대해서 관심을
가져야 하는 것인지를 말이다...

[참고]
1. 아마존 EC2 를 이용한 클라우트 크랙킹
2. RainbowCrack Project

2010년 11월 22일 월요일

리눅스에서 강제 리부팅이 필요한 경우에는...

리눅스 시스템에서 부팅이나 기타 명령어를 수행하고자 할때 응답이 없는
경우가 있다. 프로세스를 kill 하려고 해도 죽지 않거나 sync or reboot 를
해도 그냥 멈춰 있는 경우를 가끔 경험하는 때가 있다.

# reboot

Broadcast message from root@xxxx (pts/4) (Mon Nov  8 16:45:00 2010):

The system is going down for reboot NOW!


이럴때 강제적으로 리부팅하는 하는 방법이 있다. 다음과 같이 설정하여
강제적으로 리부팅이 가능하다.

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

sysrq 에 값을 셋팅하는데 sysrq 는 무엇일까? sysrq.c 에 기술된 내용을 보면
다음과 같다:

*  What is the magic SysRq key?

Fix Unresponsive or Frozen Linux Computers using Shortcuts

이미지출처 : www.makeuseof.com


It is a 'magical' key combo you can hit which the kernel will respond to regardless of whatever else it is doing, unless it is completely locked up.

즉, 매직키와 같은 것으로 솔라리스 계열의 스팍 시스템 키보드를 보면
Stop 키가 있다. Alt-Stop-<command key> 를 누르면 특정 명령이 수행되는
형태와 같은 것이다.  이 command key 는 사전에 정의된 것으로
'b' 는 syncing 또는 언마운트 없이 즉시 리부팅을 수행하고, 'e' 는
init 를 제외한 모든 프로세스에 SIGTERM 을 보낸다.

위 예와 같이 sysrq 에 1을 설정하여 enable 상태를 만들고 sysrq-trigger에
b 명령어를 보내 즉시 리부팅을 수행하도록 한다.

[참고]
1. Magic SysRq key
http://en.wikipedia.org/wiki/Magic_SysRq_key

2010년 11월 17일 수요일

올해 4월, 전세계 인터넷의 15%가 중국으로 흘렀다고?

이미지출처 : NDIA


흥미로운 기사 하나를 접했다. 올 초, 정확히는 4월 18일 인터넷 트래픽 양의 15% 가까이가 18 분동안 중국으로 우회 되었다는 것이다. 이 사실은
11월17일 미 국회에서 미국-중국의 양국관계에 관한 경제, 보안을 검토 하는 연례보고서에서 그 내용이 알려졌다.

18분동안 중국으로 리다이렉션된 트래픽은 미국 정부, 국방부 및 군사 관련 사이트 및 델, 야후, 마이크로소프트, IBM 과 같은 상업 사이트까지 많은 수를 포함하고 있다.

인터넷에서는 해당 사이트를 찾아갈때 라우팅이라는 경로를 통해 최적의 경로를 따라 사이트를 찾아 들어간다. 정상적인 경우라면 중국을 거치지 않고 들어가야 하는데, 어떤 이유에서 해당 사이트를 찾아 들어가기 까지 중국의 차이나 텔레콤을 거쳐서 정보가 흘러갔다는 것이다.

그렇다면 중국에서는 트래픽을 충분히 감시할 수 있는 상황이 되었을 것이다. 암호화 되지 않은
트래픽 이라면 이메일, 메신저와 같은 내용들이 감청당했을 수 있다. 이렇게 중국을 거쳐서 트래픽이 흘렀어도, 사용자가 느끼기에는 큰 차이가 없었기 때문에 인지도 늦었던 것 같다.

현재 이와 같은 상황이 발생된 이유에 대해 세부적인 사항은 많이 알려져 있지 않다.

정확한 사실 한가지는 2010년4월18일 인터넷 트래픽의 15%가 18분동안 중국의 차이나 텔레콤으로
흘렀다는 사실이다. 무슨일이 일어났을지는 모르지만, 정보 수집형태로 이용된다면 아주 무서운 일이 아닐 수 없다.

물론, 국내에서도 이와 같은 일이 충분히 일어날 수 있다. 만약 악성코드가 감염되어 특정한 곳을 거쳐서 트래픽이 흐르도록 조정된다면, 정보는 중간에서 감청될 수 있다. 사이버전에 효과적으로 이용될 수 있는 방법중의 하나가 될 것이다.

현재 나의 트래픽이 어느 경로로 흘러가고 있는가가 궁금하다면 traceroute 로 쉽게 확인할 수 있다. 윈도우 사용자라면 tracert 명령어를 이용하면 된다.

<윈도우에서 경로추적 예>

C:\>tracert google.com

최대 30홉 이상의
google.com [74.125.53.104](으)로 가는 경로 추적:

  1     5 ms    <1 ms    <1 ms  192.168.0.200
  2     7 ms     7 ms     7 ms  218.146.42.254
  3     7 ms     6 ms     7 ms  121.140.24.161
  4     7 ms     7 ms     6 ms  218.146.42.253
  5     8 ms     7 ms     7 ms  112.190.32.93
  6     8 ms     7 ms     7 ms  218.145.32.193
  7     7 ms     7 ms     7 ms  112.174.81.114
  8     7 ms     7 ms     7 ms  112.174.83.34
  9   123 ms   122 ms   123 ms  112.174.87.126
 10   146 ms   140 ms   133 ms  74.125.51.181
 11   154 ms   123 ms   131 ms  209.85.249.32
 12   124 ms   134 ms   124 ms  66.249.94.199
 13   130 ms   147 ms   130 ms  216.239.46.200
 14   130 ms   130 ms   129 ms  216.239.48.139
 15   135 ms   142 ms   143 ms  72.14.232.70
 16   130 ms   131 ms   130 ms  pw-in-f104.1e100.net [74.125.53.104]

추적을 완료했습니다.

이와 관련 세부적 내용이 확인되면 다시 공유하도록 하겠다.

From rigel.

[참고]
1. ABC뉴스

커널에서 drop 되는 패킷 수가 많다면...

tcpdump 와 같은 패킷 덤프 프로그램을 사용하면 몇 건의 패킷덤프가 되었는지 확인할 수 있다. 그런데, 캡쳐된 상태를 관심있게 살펴 보았다면, 의외로 drop 된 패킷 건수가 크게 나타나는 경우를 경험해 보았을지도 모른다.
다음의 경우를 보자:

16 packets captured
351742 packets received by filter
351655 packets dropped by kernel

tcpdump 를 이용해 패킷 덤프를 하다 Ctrl+C 를 통해 중지 하였는데, 16개의 패킷이 캡쳐되었다. 그런데 packets dropped by kernel 을 보면 그 카운터가 꽤 높다. 필터에서 받은 패킷 건수가 351,742 건인데 drop된 건수가 351,655 라는 것이다. 이러한 것은 다양한 원인이 있겠지만, 사용하는 패킷덤프 프로그램에 의한 영향이거나, 네트워크적인 영향, 하드웨어, 패킷필터, 운영체제와 관련한 것등이 있을 것이다.

이런 경우 IP 주소등을 이름으로 변경하는 작업등이 이뤄지지 않도록 하는 것 만으로도 큰 효과를 볼 수 있다.
tcpdump 에서는 '-n' 옵션을 사용하면 된다.

# tcpdump -i eth0 -n
51119 packets captured
51612 packets received by filter
493 packets dropped by kernel

같은 조건의 환경인데, -n 만을 사용하는 것만으로도 큰 차이가 나타난다. 패킷덤프시에는 이점을 참고하기 바란다. 이외, 커널 상에서 네트워크 관련 파라미터를 수정하는 것도 도움이 될 것이다. 패킷 덤프만이 아니라, 네트워크 관련된 서비스를 하는 시스템이라면 한번쯤은 검토해 보아야 한다.

sysctl 을 통해 관련 파라미터 정보를 확인할 수 있는데, 예를 들어 backlog 를 확인해 보면 아래와 같다.

# sysctl -a | grep backlog
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.tcp_max_syn_backlog = 1024
net.core.netdev_max_backlog = 5000

backlog 는 새로운 연결을 맺는데 관련하여 영향을 주는 파라미터중 하나다. 이외 여러가지 값 들이 있는데, 네트워크 연결이 많다면 다음과 같은 설정이 권장된다.

      net.core.wmem_max = 8388608
      net.core.rmem_max = 8388608
      net.ipv4.tcp_wmem = 4096 65536 8388608
      net.ipv4.tcp_rmem = 4096 87380 8388608
      net.ipv4.tcp_default_win_scale = 7
      net.ipv4.tcp_moderate_rcvbuf = 1
각 값의 설정은 sysctl 을 통하거나 /proc 파일 시스템을 직접 엑세스 할 수 있다.  sysctl 을 이용한다면,

# sysctl -w net.core.rmem_max=8388608

와 같다. 참고로 리눅스 2.6.17 이후에는 오토튜닝이라는 기능이 있는데, 이것은 각 연결에 따라 버퍼 사이즈등이 동적으로 업데이트 되는 것이다. 이 값은 /proc/sys/net/ipv4/tcp_moderate_rcvbuf 를 통해 확인해 볼 수 있는데,

# cat /proc/sys/net/ipv4/tcp_moderate_rcvbuf

1 의 값이 셋팅되어 있다면 autotuning 이 설정되어 있는 것이다.  이런, 네트워크 관련 파라미터 설정외에도
현재 네트워크 관련한 상태를 확인해 보는 것도 원인 파악에 도움이 된다. 네트워크 상태를 파악하는데 기본적으로 많이 사용되는 netstat 를 사용하는 것만으로도 많은 정보를 얻을 수 있다.

# netstat -s
Ip:
    2987551774 total packets received
    480 with invalid headers
    4288 with invalid addresses
    139108843 forwarded
    0 incoming packets discarded
    2804683209 incoming packets delivered
    1904276683 requests sent out
    1832 outgoing packets dropped
    1344 dropped because of missing route
    169 fragments dropped after timeout
    1551222 reassemblies required
    38285 packets reassembled ok
    230 packet reassembles failed
    31867 fragments received ok
    5222 fragments failed
    1377531 fragments created
Icmp:
    331800 ICMP messages received
    26 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 331772
        echo requests: 4
        echo replies: 24
    345417 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 340488
        time exceeded: 451
        redirect: 1831
        echo request: 2647
IcmpMsg:
        InType0: 24
        InType3: 331772
        InType8: 4
        OutType3: 340488
        OutType5: 1831
        OutType8: 2647
        OutType11: 451
Tcp:
    7723898 active connections openings
    13569062 passive connection openings
    1469362 failed connection attempts
    2505823 connection resets received
    64 connections established
    2794594182 segments received
    1750284379 segments send out
    4751200 segments retransmited
    0 bad segments received.
    1074943 resets sent
Udp:
    9438290 packets received
    323420 packets to unknown port received.
    0 packet receive errors
    9784976 packets sent
UdpLite:
TcpExt:
    879602 resets received for embryonic SYN_RECV sockets
    552 packets pruned from receive queue because of socket buffer overrun
    21 ICMP packets dropped because they were out-of-window
...(생략)

그리고 다음 도표는 IBM 에서 정리된 파라미터 정보인데, 각 파라미터를 이해하는데 도움이 될거 같아 첨부하였다.

Tunable parameterDefault valueOption description
/proc/sys/net/core/rmem_default"110592"Defines the default receive window size; for a large BDP, the size should be larger.
/proc/sys/net/core/rmem_max"110592"Defines the maximum receive window size; for a large BDP, the size should be larger.
/proc/sys/net/core/wmem_default"110592"Defines the default send window size; for a large BDP, the size should be larger.
/proc/sys/net/core/wmem_max"110592"Defines the maximum send window size; for a large BDP, the size should be larger.
/proc/sys/net/ipv4/tcp_window_scaling"1"Enables window scaling as defined by RFC 1323; must be enabled to support windows larger than 64KB.
/proc/sys/net/ipv4/tcp_sack"1"Enables selective acknowledgment, which improves performance by selectively acknowledging packets received out of order (causing the sender to retransmit only the missing segments); should be enabled (for wide area network communication), but it can increase CPU utilization.
/proc/sys/net/ipv4/tcp_fack"1"Enables Forward Acknowledgment, which operates with Selective Acknowledgment (SACK) to reduce congestion; should be enabled.
/proc/sys/net/ipv4/tcp_timestamps"1"Enables calculation of RTT in a more accurate way (see RFC 1323) than the retransmission timeout; should be enabled for performance.
/proc/sys/net/ipv4/tcp_mem"24576 32768 49152"Determines how the TCP stack should behave for memory usage; each count is in memory pages (typically 4KB). The first value is the low threshold for memory usage. The second value is the threshold for a memory pressure mode to begin to apply pressure to buffer usage. The third value is the maximum threshold. At this level, packets can be dropped to reduce memory usage. Increase the count for large BDP (but remember, it's memory pages, not bytes).
/proc/sys/net/ipv4/tcp_wmem"4096 16384 131072"Defines per-socket memory usage for auto-tuning. The first value is the minimum number of bytes allocated for the socket's send buffer. The second value is the default (overridden by wmem_default) to which the buffer can grow under non-heavy system loads. The third value is the maximum send buffer space (overridden by wmem_max).
/proc/sys/net/ipv4/tcp_rmem"4096 87380 174760"Same as tcp_wmem except that it refers to receive buffers for auto-tuning.
/proc/sys/net/ipv4/tcp_low_latency"0"Allows the TCP/IP stack to give deference to low latency over higher throughput; should be disabled.
/proc/sys/net/ipv4/tcp_westwood"0"Enables a sender-side congestion control algorithm that maintains estimates of throughput and tries to optimize the overall utilization of bandwidth; should be enabled for WAN communication. This option is also useful for wireless interfaces, as packet loss may not be caused by congestion.
/proc/sys/net/ipv4/tcp_bic"1"Enables Binary Increase Congestion for fast long-distance networks; permits better utilization of links operating at gigabit speeds; should be enabled for WAN communication.