IPv4 주소고갈에 따른 마켓의 형성은 시장의 흐름인가?

이전에 언급한 것과 같이 IPv4 주소의 부족이 공식화 되었고, 이에 따라 IPv6 로의 전환이 느릴 수도 있지만 서서히 진행될 것이다. 하지만, 기존에 존재하는 IPv4 네트워크 인프라가 쉽게 전환하기는 현실적으로 어려움이 따를 것이다. 그래서, IPv4 주소를 사고파는 블랙마켓이 형성도 될 것이라고 하였다.

얼마전 마이크로소프트가 노텔로부터 IPv4 주소를 사들이는데 개당 $11.25 달러 정도 소요되었다고 하였다. (참고 : 마이크로소프트 666,624 개의 IP 주소를 사들이는가? )

앞으로 시장에서 주소가 거래될 경우 진짜 얼마의 가치가 되려는지는 아직 알수 없지만, 이와 유사한 움직임이 관찰되고 있다. 더 이상 할당할 IP 주소가 부족해 지면서 이를 사고팔 수 있는 마켓이 형성되고 있는 것이다. 다음 사이트들이 이와 유사한 형태이다.

www.depository.net
www.addrex.net
www.tradeipv4.com

IPv4 주소 부족에 따른 시장의 흐름이 어떻게 변화는지 지켜볼 필요가 있다.

SJC(South East Asia Japan)해저 케이블 공사 시작

저번 일본지진으로 인해 해저케이블이 손상되었고, 이로인한 영향이 있었다고 하였다. 4월초에 발표된 케이블 소식 중에 하나가 SJC 케이블이 이제 공사를 시작하였다고 한다. SJC 는 South East Asia Japan 케이블로 2008년에 계획되었고, 최근에야 공사를 확정한 것이다. 15Tbps 규모로, 일본, 홍콩, 중국, 필리핀, 싱가포르등이 연결 거점이고 해저케이블 길이만 8,900 Km 에 달한다. 태국과, 인도네시아 까지 확장되면 그 길이는 10,700km 에 이른다.

아래 그림을 보면 2008년과 2011년의 계획이 조금 달라진 것을 볼 수 있다.


[출처:  Telecom Ramblings]

하여튼 이로 인해 미국과 아시아의 대역폭이 더욱 크게 확대될 것이며, 케이블의 완공시기는 2013년 중반쯤이다.
해당 기사를 보다 보니 Unity 라는 케이블에 대해서도 보게되었는데, 구글과 5개의 통신사업자가 함께 구성한 해저케이블로 미국과 일본을 연결한 것이다. 전체 대역폭은 7.68 Tbit/s 이다. 2010년4월 1일에 운영하기 시작했다고 한다.

일본 지진 후 해저케이블 정보를 살펴보다 보니, 이런 정보도 좋겠다 싶어서 소개한다.

[참고]
1. Construction of the SJC Cable Underway 기사
http://www.telecomramblings.com/2011/04/construction-of-the-sjc-cable-underway/
2. Unity 케이블
http://en.wikipedia.org/wiki/Unity_(cable_system)
http://www.subtelforum.com/articles/?p=2243

와이어샤크에서 제공하는 랜덤 패킷 생성기 - randpkt

와이어샤크에 포함된 유틸리티 도구중 랜덤 패킷 생성기에 대해서 소개해 볼까 한다. 말 그대로 랜덤한 패킷을 생성하여 테스트해 볼 수 있도록 도와주는 것이다. 패킷 생성기에 대해서는 과거에도 여러개 언급한 적이 있는데, 다음 링크를 참고해 보면 과거 포스팅 글을 볼 수 있다.

http://www.packetinside.com/search/label/패킷생성

일단, 와이어샤크에서 제공하는 패킷생성기의 이름은 randpkt 이다. 과거에 와이어샤크 위키 페이지에서 네트워크 퍼징 테스팅 형태로 소개된 적이 있는데, 보니까 이번 1.5.X 에는 포함되었다. 사용방법은 아주 간단한데, 몇 개 옵션만 설정하면 된다. 일단 실행해 보면 다음과 같은 도움말 화면을 볼 수가 있다.

$ ./randpkt
Usage: randpkt [-b maxbytes] [-c count] [-t type] filename
Default max bytes (per packet) is 5000
Default count is 1000.

Types:
arp Address Resolution Protocol
bgp Border Gateway Protocol
bvlc BACnet Virtual Link Control
dns Domain Name Service
eth Ethernet
fddi Fiber Distributed Data Interface
giop General Inter-ORB Protocol
icmp Internet Control Message Protocol
ip Internet Protocol
llc Logical Link Control
m2m WiMAX M2M Encapsulation Protocol
megaco MEGACO
nbns NetBIOS-over-TCP Name Service
ncp2222 NetWare Core Protocol
sctp Stream Control Transmission Protocol
syslog Syslog message
tds TDS NetLib
tcp Transmission Control Protocol
tr Token-Ring
udp User Datagram Protocol
usb Universal Serial Bus
usb-linux Universal Serial Bus with Linux specific header

아래와 같은 옵션이 가능하다.

-b : 패킷당 최대 바이트 설정
-c : 생성할 패킷 개수
-t : 위에서 보여지는 타입 중에 한개를 지정

기본 패킷당 최대 사이즈는 5000 바이트 이며, 1000개를 생성한다. 아래는 -c 옵션을 통해 2000 개의 패킷을 생성하고 -t 로 UDP 패킷을 생성하겠다고 지정하였다.

$ ./randpkt -c 2000 -t udp testudp_pkt.pcap

testudp_pkt.pcap 의 파일 타입을 보니 패킷파일이 맞다!

$ file testudp_pkt.pcap
testudp_pkt.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 5000)

그리고 아래와 같이 tcpdump 로 읽어 보았더니, 랜덤한 UDP 데이터 이다.

$ tcpdump -n -r testudp_pkt.pcap | more
reading from file testudp_pkt.pcap, link-type EN10MB (Ethernet)
09:00:00.000000 IP 208.21.2.184.21753 > 10.1.1.99.32054: UDP, length 38786
09:00:01.000000 IP 208.21.2.184.26443 > 10.1.1.99.57468: UDP, length 2509
09:00:02.000000 IP 208.21.2.184.9457 > 10.1.1.99.46725: UDP, length 6990
09:00:03.000000 IP 208.21.2.184.34198 > 10.1.1.99.8866: UDP, length 37046
09:00:04.000000 IP 208.21.2.184.1266 > 10.1.1.99.8929: UDP, length 30654
09:00:05.000000 IP 208.21.2.184.344 > 10.1.1.99.52255: UDP, length 6177
09:00:06.000000 IP 208.21.2.184.31183 > 10.1.1.99.31788: UDP, length 45533
09:00:07.000000 IP 208.21.2.184.10209 > 10.1.1.99.12047: UDP, length 22577
09:00:08.000000 IP 208.21.2.184.20021 > 10.1.1.99.22743: UDP, length 40433
09:00:09.000000 IP 208.21.2.184.6049 > 10.1.1.99.51616: UDP, length 30311
09:00:10.000000 IP 208.21.2.184.36432 > 10.1.1.99.18243: UDP, length 52538
09:00:11.000000 IP 208.21.2.184.13544 > 10.1.1.99.60867: UDP, length 57417
09:00:12.000000 IP 208.21.2.184.17578 > 10.1.1.99.17505: UDP, length 14594
09:00:13.000000 IP 208.21.2.184.9524 > 10.1.1.99.55107: UDP, length 46128
09:00:14.000000 IP 208.21.2.184.37164 > 10.1.1.99.28460: UDP, length 49273
09:00:15.000000 IP 208.21.2.184.39487 > 10.1.1.99.24324: UDP, length 25347

건수도 확인해 보니, 옵션에서 지정한 것과 같이 2000 개이다.

$ tcpdump -n -r testudp_pkt.pcap | wc -l
reading from file testudp_pkt.pcap, link-type EN10MB (Ethernet)
2000

사이즈를 보니, 약 5.1 메가 정도가 된다.

$ ls -l testudp_pkt.pcap
-rw-r--r-- 1 rigel rigel 5101896 2011-04-21 21:58 testudp_pkt.pcap

한번 데이터를 살펴보면 Length 가 37046 으로 나온다.

09:00:03.000000 IP 208.21.2.184.34198 > 10.1.1.99.8866: UDP, length 37046
 0x0000:  ffff ffff ffff 0101 0101 0101 0800 4500  ..............E.
 0x0010:  003c c59e 4000 ff11 d7e0 d015 02b8 0a01  .<..@...........
 0x0020:  0163 8596 22a2 90be 05e7 0fad 7889 b8f5  .c..".......x...

아니, 어찌 패킷 사이즈가 이리 큰가? 아까 생성할 때 기본적으로 생성되는 패킷 사이즈 최대는 5000 바이트 인것을 기억할 것이다. 이걸 와이어샤크에서 열어서 살펴보면 UDP 헤더가 bogus header 로 나온다. 그리고 페이로드는 32 바이트이고, 그리하여 UDP 헤더 8 바이트와 페이로드 32바이트를 합치면 40 바이트이다. 하지만, 실제 데이터는 훨씬 크다. 제대로 표현을 못 해 준것 뿐이다.

그런데 몇번 생성하다 보면 출발지와 목적지 IP 가 동일하게 나온다. 왜 그럴까? 이것은 IP 주소등을 랜덤하게 생성하는 기능을 포함하고 있지 않다. randpkt.c 소스 파일을 살펴보면 아래와 같은 부분을 볼 수 있다.

/* Ethernet+IP, indicating UDP */
guint8 pkt_udp[] = {
    0xff, 0xff, 0xff, 0xff,
    0xff, 0xff, 0x01, 0x01,
    0x01, 0x01, 0x01, 0x01,
    0x08, 0x00,

    0x45, 0x00, 0x00, 0x3c,
    0xc5, 0x9e, 0x40, 0x00,
    0xff, 0x11, 0xd7, 0xe0,
    0xd0, 0x15, 0x02, 0xb8,
    0x0a, 0x01, 0x01, 0x63
};

즉, 위와 같이 UDP 패킷에 대해서 헤더 부분이 하드코딩 되어 있는 것이다. 목적지 IP 인 10.1.1.99 는 0x0a, 0x01, 0x01, 0x63 이 되고, 208.21.2.184 는 0xd0, 0x15, 0x02, 0xb8 이 되는 것이다.

[참고]
1. randpkt - Random Packet Generator
http://www.wireshark.org/docs/man-pages/randpkt.html

페이스북의 새로운 데이터센터를 들여다 보자

일전에 구글의 데이터센터에 대해서 공개된적이 있다. 최근에는 (정확히는 4월 초) 페이스북이 새로운 데이터센터의 인프라 정보를 세부적으로 공개했다. 자체적으로 하드웨어를 제작해 38% 더 효율적으로 만들었으며, 비용도 24% 정도 절감했다고 한다. 이것은 오픈컴퓨트 프로젝트의 일환으로 해당사이트에 가면 동영상과 세부 정보등을 확인할 수 있다.



특히 서버 디자인과 세부적인 스펙까지 공개되어 있다. 이런 인프라에도 관심이 많은 탓에 재미있게 보았는데, 여러분들도 한번 살펴보기 바란다.  사이트는 http://opencompute.org 이다.

FTP(File Transfer Protocol)가 벌써 40주년이 되었다네요!

최근 기사를 보니,  파일전송 프로토콜의 대명사인 FTP(File Transfer Protocol)가 어느덧 40주년을 맞이했다고 한다. 정확히는 4월16일 이다. FTP 의 RFC 문서가 나온년도는 1971 년이다. 40주년이나 되었다는 것이 믿기지 않을 정도로, 이렇게 빨리 시간이 흘렀나 하는 생각이 든다. 처음 이 프로토콜은 1971년 4월 MIT 의 Abhay Bhushan 에 의해서 제안되었고 인테넷의 근간이 되는 ARPANet 에서 두 시스템 사이에서 대량의 파일을 전송하기 위한 것이었다.

보안적으로 보면, 그 당시는 보안이 크게 고려되지 않아 Clear Text 로 사용자이름과 패스워드가 네트워크 상으로 전송되었다. FTP 세션을 맺을때 랜덤한 포트 번호가 할당되어서 감청과 같은 부분도 괜챦을 것이라 생각하였지만, 그것은 보안장치로서는 부족하다는 것을 알게되었고, SSL 과 같은 보안 매커니즘이 같이 결합되어 사용되었다.

지금은 보안을 고려한 전송 방식도 많이 나와있지만, 아직까지도 FTP 는 파일 전송으로 대중적인 프로토콜 임은 분명하다. 나 또한, 내부 시스템끼리는 즐겨 사용한다. SFTP, SCP 등을 쓸 수도 있지만, 역시나 편한 것은 이것이 아니겠던가? 물론, 보안이 꼭 필요한 곳은 암호화가 사용되지만 말이다.

40주년이 된, FTP 가 과연 얼마나 우리 귀에 익숙하게 오르내릴지는 모르지만...

[참고]
1. RFC114, A FILE TRANSFER PROTOCOL
http://tools.ietf.org/html/rfc114
2. The Register, FTP celebrates ruby anniversary
http://www.theregister.co.uk/2011/04/15/ftp_turns_40/
3. ARPANet
http://en.wikipedia.org/wiki/ARPANET

와이어샤크 1.4.5, 1.5.1 버전 릴리즈

와이어샤크 1.4.X, 개발버전 1.5.X 그리고 1.2.X 버전까지 업그레이드가 되었다. 릴리즈 된지는 몇일 되었는데, 다른 일로 바쁘다 보니 지금에야 공유하게 되었다. 일단 보안 취약점이 보고되어 Fix 가 되었다. 이번 취약점은 DECT, NFS 그리고 X.509 의 프로토콜 파서에서 발생한 것으로 DECT 는 버퍼오버플로우가 가능하여 원격에서 공격코드 실행까지 가능하다. 보안취약점외 알려진 몇 가지 기능들이 수정되었다. 1.4.X 에서는 새로운 기능은 없으며, HTTP, LDAP, MySQL, NFS, sFlow, SSL, TCP 프로토콜이 업데이트 되었다.

1.5.X 는 1.4.X 보다 많은 기능이 업데이트 되었는데, TShark 에서 text2pcap 과 유사하게 텍스트 덤프파일을 Import 할 수 있으며, SMB 오브젝트 Export 등이 가능하다. 더불어, 프로토콜도 많이 업데이트 되었다.

윈도우 32 비트 버전은 다음 링크를 통해서 다운로드가 가능하다.

와이어샤크 1.4.5
와이어샤크 1.2.16
와이어샤크 1.5.1

항상 발전하는 와이어샤크 고마워요~

APNIC 의 IPv4 주소 할당 임박, 제한적 할당 X-day 는 하루 앞으로...

패킷인사이드의 오른쪽 하단에 있는 IPv4 주소고갈 카운트가 1일 남은 4/16 로 X-day 가 설정되어 있다. 오전에 보았을 때 15일 이었던것으로 기억하는데, 16일로 바뀐 것 같다. 그렇지 않아도, 14일 국내 관련 기사를 보니 "인터넷주소 'IPv4' 사실상 할당 종료" 기사가 나왔다.

기사내용 왈, IPv4 할당이 15일로 사실상 종료되고, IPv6 로의 전환에 박차를 가할것으로 보인다는 것이다. 방통위에서도 '최종할당방식' 을 시행함에 따라 사실상 IPv4 주소할당이 종료된다고 밝힌 것이다.

지난 2월3일에 NRO 에서 마지막 남아있던 /8 주소를 APNIC 에 할당 하였고, 이게 APNIC 에 할당된 주소가 얼마 남지 않아 제한적 할당에 들어가는 정책이다. 다음 그래프를 보면, 4월에 IPv4 여유량을 표시한 것인데, 이제 /8 정도만 남아있게 된 것이다.

[출처: APNIC/ APNIC's IPv4 pool usage]

아래는 APNIC 사이트에서 최종 남은 /8 에 대한 주소 정책을 기술한 것이다.

Available:

Given the final /8 policy permits each LIR to receive only one small block (a /22), and that APNIC regularly receives returned IPv4 resources when LIRs close, it will take a very long time to delegate its entire IPv4 pool. For more information, see IPv4 exhaustion details.

Reserved:

Quarantined blocks will be released to the Available pool when their routability and usability problems are minimized.

Delegated:

There will be no change to how delegated addresses are managed.

각 LIR 은 한개의 /22 를 받을 수 있다고 한다. LIR 은 KT 와 같은 ISP 가 해당되는 것으로 다음 IPv4 주소 분배 정책을 표시한 구조를 보면 이해가 쉬울 것이다. (X-day 후 완전환 할당 중지를 의미하는 것은 아니다)


[출처: APNIC / Hierarchy of IPv4 address space distribution]

/22 는 10비트를 사용하므로,  2^10  = 1024 개의 주소가 된다. 앞으로 국내의 IPv6 대응 현황을 지켜볼 일 만이 남은것 같다. 더불어, 나에게는 IPv4 주소의 패킷 분석 뿐만 아니라, IPv6 에 대한 패킷 분석도 슬슬 더욱 다뤄봐야 하는 주제가 되고 있다.

참고로, 다음은 IPv4 와 관련해 패킷인사이드에 포스팅 된 글이므로 참고하길 바란다.

http://www.packetinside.com/search/label/ipv4

윈도우 패킷스니퍼 WinDump 에 컬러 Hightlighting 기능을 입혀보자

커맨드라인의 패킷덤프 프로그램으로는 tcpdump 를 많이 사용하는 편이다. 윈도우에는 이와 유사한 Windump 라는 것이 있다. tcpdump 와 같은 형태로 윈도우에서 실행가능한 커맨드라인의 패킷 스니퍼이다. 와이어샤크와 같은 GUI 에 익숙해져 있다면, 커맨드라인의 출력되는 화면은 보잘것 없어 보인다.

어느 블로그에 Windump 와 관련한 괜챦은 스크립트 소개를 보았다. 윈덤프의 출력에 컬러를 입혀 보여주는 것으로 그나마 컬러를 입혀서 보면 보기에는 더욱 좋을 것이다. 방법은 윈도우의 파워셀(PowerShell)을 이용하는 것으로 이것이 설치되어 있어야 한다. 윈도우 7 의 경우는 기본적으로 포함되어 있고 그렇지 않은 경우라면 사이트에서 다운받아 설치하면 된다.

일단 파워쉘 스크립트인 Sniff.ps1 을 다음의 경로에서 다운로드 받는다:

http://blogs.sans.org/windows-security/files/Sniff.zip

압축을 풀고 실행해 보자

.\Sniff.ps1

이걸 그냥 도스창에서 실행하면 실행되지가 않는다. 파워쉘로 실행되어야 하므로 도스창에서 powershell 이라고 치면 파워쉘로 들어간다. 나의 경우는 파워쉘을 관리자 권한으로 실행시켰다. 실행 정책 때문에 관리자 권한이 필요하기 때문이다.

일단 아래와 같이 실행해 보니 권한이 부족하다고 나온다.

PS C:\PlayGround\Sniff> .\Sniff.ps1
이 시스템에서 스크립트를 실행할 수 없으므로 C:\PlayGround\Sniff\Sniff.ps1 파일을 로드할 수 없습니다. 자세한 내용은 "get
-help about_signing"을 참조하십시오.
위치 줄:1 문자:12
+ .\Sniff.ps1 <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

현재 실행 정책을 살펴보니 '제한적' 이다.

PS C:\PlayGround\Sniff> Get-ExecutionPolicy
Restricted

그래서 임시적으로 실행하기 위해 아래와 같이 제한을 풀었다.

PS C:\PlayGround\Sniff> Set-ExecutionPolicy unrestricted

실행 규칙 변경
실행 정책은 신뢰하지 않는 스크립트로부터 사용자를 보호해 줍니다. 실행 정책을 변경하면 about_Execution_Policies 도움말
항목에 설명된 보안 위험에 노출될 수 있습니다. 실행 정책을 변경하시겠습니까?
[Y] 예(Y)  [N] 아니요(N)  [S] 일시 중단(S)  [?] 도움말 (기본값은 "Y"임): y

실행정책을 변경한 다음에는 Sniff.ps1 을 정상적으로 실행할 수 있게 된다.
사용할 네트워크 어뎁터를 묻는 명령을 실행할 경우는 아래와 같이 실행하면, 네트워크 카드를 선택한 후 패킷 덤프를 할 수 있다.

PS C:\PlayGround\Sniff> .\Sniff.ps1 -ask

1.\Device\NPF_{8B751B[삭제]-95BF-F2FB6F703EE6} (3Com EtherLink PCI)
2.\Device\NPF_{E849DA[삭제]-BD12-157CFC55BD8B} (NVIDIA nForce MCP Networking Adapter
3.\Device\NPF_{DE78577C-[삭제]9B-E46B98062A8F} (Sun)

Which adapter number? :

* 참고로, Windump.exe 가 설치되어 있어야 한다. Windump 는 윈도우 패스에 잡혀 있으면 실행하는데 전혀 문제 없다. Windump 는 아래 참고 URL 에서 구할 수 있다.

다음 이미지는 아래와 같은 명령을 통해 실행한 화면으로 tcp 트래픽 중 80 번 포트를 덤프하도록 지정한 것이다.

PS C:\PlayGround\Sniff> .\Sniff.ps1 "tcp and port 80" -ask

[참고]
1. 윈덤프 컬러 사용 관련 블로그 글
http://blogs.sans.org/windows-security/2009/10/22/windump-color-highlighting/
2. 윈덤프 다운로드
http://www.winpcap.org/windump/
3. 마이크로소프트 윈도우 파워쉘
http://technet.microsoft.com/en-us/powershell

암호화된 VoIP 트래픽의 문장 50% 를 인지할 수 있을까?

구글, MIT, 노스캐롤리나 대학, 존스홉킨스 대학에서 다양한 비트레이트 코덱으로 암호화된 VoIP 트래픽에서 문장을 탐지할 수 있는 방법에 대해서 논문을 발표한 것이 있다.

http://portal.acm.org/citation.cfm?doid=1880022.1880029

일단 주제부터가 관심을 끄는데, 암호화된 음성 데이터에서 문장을 인식할 수 있다는 것은, VoIP 통신 내용을 감청할 수 있다는 뜻이 되기도 한다. 이 논문의 결론부터 보면 암호화된 트래픽에서 평균 정확도는 50% 가까이 되며, 특정한 문구에서는 90% 이상이 될만큼 인지할 수 있다고 한다.
이 논문에서는 사람의 음성이나 녹음된 단어와 같이 사전에 샘플링된 데이터를 이용하지 않고, 그들이 고안해낸 기술적 방법으로 음성을 인식했다고 한다.  그렇다고 VoIP 트래픽 데이터를 다 감청한다는 뜻은 아니다. 어디까지나 학술적으로 발표된 내용이며, 다양한 환경에 따라 제약이 있기 마련이다. 우선, 이 음성 대상도 미국인들의 음성에 기준으로 되어 있다. :-)

ACM 에서는 해당 자료에 접근하기 위해서는 구매를 해야 하는데,  IEEE S&P 2008 에서 발표된 문서를 다음 사이트에서 살펴볼 수 있다. 그냥 참고수준에서 한번 살펴보면 좋을것 같다. VoIP 서비스를 하고 있는 기업이라면.

http://cs.unc.edu/~fabian/papers/oakland08.pdf

와이어샤크에는 VoIP 관련한 메뉴를 볼 수 있는데, 테스트 준비가 되면 VoIP 관련한 내용도 언급해 보도록 하겠다.

[참고]
1. Hidden Markov model
http://en.wikipedia.org/wiki/Hidden_Markov_model

월드 IPv6 데이(World IPv6 Day)를 통한 글로벌 IPv6 사전 테스트

2011년 6월8일, ISOC(Internet Society)의 리드하에 IPv6 연결 테스트가 있다. 이름하여 월드 IPv6 데이 이다. 여기에는 구글, 페이스북, 야후, 아카마이 등이 메이저로 참여하며, 24시간은 IPv6 연동 테스트를 진행한다. IPv4 주소 부족에 따라 IPv6 로의 성공적인 전환을 위해 준비하는 것이다. 각 기업들마다 IPv6 전환 준비를 위해 테스트를 진행하겠지만, 이번과 같이 글로벌하게 테스트는 진행된 적이 없기 때문에, 이번 월드 IPv6 데이가 IPv6 전환 준비에 많은 도움이 될 것이다.

이와 관련 추가적인 사항은 다음 사이트를 방문해 보면 된다

http://isoc.org/wp/worldipv6day/

이번 행사에 참여를 원하면 참가신청을 내면 되고, 현재 참여하겠다는 기관의 목록에는 한국기업은 보이지 않는 것으로 보인다. 몇몇 일본 기업도 눈에 띄는데, 뛰어난 네트워크 인프라를 가지고 있는 한국기업은 왜 하나도 보이지 않는 것인가?

http://isoc.org/wp/worldipv6day/participants/

2011년이 IPv4 고갈시점이고, IPv6 전환점의 큰 해가 될텐데.. 한국 기업들 충분히 준비하고 있는가요? NAT 나 기타 방법으로 계속 버티면 되겠지 하는 생각하는건 아니겠죠.

[참고]
1. World IPv6 day
http://test-ipv6.com/ipv6day.html

리눅스 20주년을 정말 축하해요 ^.^

리눅스가 올해로 20주년을 맞이했다. 리눅스 파운데이션은 이와 관련 다양한 행사도 준비하고 있다. 예를 들면, 비디오 컨테스트로 누구나 응모할 수 있다. 당첨자는 벤쿠버에서 열리는 LinuxCon 에서 발표된다.
아래 이미지는 리눅스 20년간의 주요한 내용을 담아 정리된 것이다.

1991년은 Linux Torvalds 가 포스팅 한 메시지 "Hello Everybody Out there..." 와 함게 처음으로 리눅스 코드를 배포한 해이다. 1993년에는 슬랙웨어가 주요 배포판으로 퍼져나갔는데, 나 또한 그 당시의 슬랙웨어를 기억한다. 배포되는 리눅스 중에서는 슬랙웨어가 유명했었다. 1996년에는 Linus 가 아쿠아리움에 방문하면서 리눅스의 마스코트로 펭귄을 선택했다는 사실. 1999년은 레드햇이 퍼블릭하게 배포되었으며, 2010년은 리눅스 기반의 안드로이드가 나타난다.

리눅스 20주년을 정말 축하하며, 앞으로 펭귄의 활약을 더 기대해 보고 싶다. :-)

[참고]
1. 리눅스파운데이션
http://www.linuxfoundation.org/20th/

마이크로소프트 666,624 개의 IP 주소를 사들이는가?

여기서도 자주 언급하였지만, IPv4 주소가 이제 고갈된다는 것은 잘 알고 있을 것이다. 최근 마이크로소프트사가 파산 신청을 한 노텔로부터 IPv4 주소를 사들인다고 하였다. 이 주소가 자그마치 666,624 개의 IP 주소이다. 지금과 같이 IPv4 주소가 부족한 시점에서는 엄청나게 많은 IP 주소이다.

주소를 사들이는데 소요되는 비용은 750만 달러이며, IP 한개의 가치가 11.25 달러 정도가 된다.
아직 이번 딜과 관련해서 최종적으로 승인은 나지 않은 상태이며, 이와 관련한 다양한 의견들이 인터넷 커뮤티니 사이에서 나오고 있다.

워낙에 IPv4 주소 부족 고갈로 문제를 겪고 있다 보니 이슈화 되고 있는 것이다. IP 주소가 펑펑 남는 시점이라면, 마이크로소프트사가 사지도 않았을 것이고, 큰 이슈가 되지도 않았을 것이다. 왜? 이렇게 엄청난 주소를 사들이는 것일까? IP 주소를 판매하려 한다는 얘기도 있고, 얼마남지 않은 IP 주소를 확보하려는 것이라고도 하고 다양한 이야기들이 있다. 다만, 마이크로소프트사가 IP 주소를 판매하려는 목적으로 사들이는 것으로 보이지는 않는다.

이번 이슈로 인해, 앞으로 IPv4 주소가 블랙마켓에서 실제 지금보다 더 높은 가격으로 거래가 되지 않을까 하는 우려도 생기고 있다. 주소 하나가 $11 이라면 도메인 1년 유지 비용 정도와 비슷한데. 이 보다 더 많은 비용을 지불하고 IP 주소를 얻어야 하는 것인가?

IPv6 로 전환되면 문제도 안될텐데, 현실적으로 IPv4 고갈이 다가오지만 IPv6 환경으로 빠르게 바뀌기는 쉽지 않아 보인다.

[참고]
1. 인포월드 기사
http://www.infoworld.com/d/networking/microsoft-offers-75-million-ipv4-addresses-745

와이어샤크로 USB 디바이스를 모니터링 할 수 있다는 사실!

컴퓨터와 USB 사이의 통신 내용도 패킷을 캡쳐하는 것과 같이 볼 수 없을까? 이에 대한 대답은 '있다' 이다. 그것도 우리가 블로그에서 많이 언급하고 친근한 프로그램 중에 하나인 와이어샤크로 할 수 있다.

자, 그럼 어떻게 USB 트래픽 정보를 볼 수 있을까? 우선 운영체제에서 볼 수 있도록 지원해 주어야 하는데, USB 로우 트래픽 데이터를 패킷 형태로 변환하여 일반적인 네트워크 인터페이스와 같이 인식되어 볼 수 있다. 여기서는 리눅스를 기반으로 하여 설명을 할 것이다. 우선 커널 상에서 DEBUG 파일 시스템이라든지, USB 모니터링 모듈등을 지원해 주어야 한다. 그러므로, 다음과 같은 옵션이 설정되어 커널이 컴파일 되어 있어야 한다.

CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_FS=y
CONFIG_USB_MON=y

USBMON 모듈은 커널 2.6.11 이후에 포함되어 있으며, 최근의 배포판 리눅스에서는 크게 다른 설정 없이 아래의 명령어를 사용할 수 있을 것이다. 일단, lsmod 명령어를 통해 usb 관련한 모듈은 무엇이 올라가 있는지 살펴보았다.

# lsmod | grep usb
rt2800usb              28691  0
rt2x00usb               6829  1 rt2800usb
rt2x00lib              21810  2 rt2800usb,rt2x00usb
mac80211              137340  2 rt2x00usb,rt2x00lib
crc_ccitt               1323  2 rt2870sta,rt2800usb
usb_storage            39625  1
scsi_mod              122149  5 usb_storage,sg,sr_mod,sd_mod,libata
usbcore               122034  6 rt2870sta,rt2800usb,rt2x00usb,usb_storage,ehci_hcd
nls_base                6377  11 isofs,udf,hfsplus,hfs,ntfs,jfs,nls_utf8,nls_cp437,vfat,fat,usbcore

usbmon 은 보이지 않는다. usbmon 모듈은 modprobe 를 통해서 쉽게 모듈을 로드할 수 있다.

# modprobe usbmon

모듈을 올린 후 살펴보니 usbmon 모듈이 올라가 있는 것이 보인다.

# lsmod | grep usb
usbmon                 15322  0
rt2800usb              28691  0
rt2x00usb               6829  1 rt2800usb
rt2x00lib              21810  2 rt2800usb,rt2x00usb
mac80211              137340  2 rt2x00usb,rt2x00lib
crc_ccitt               1323  2 rt2870sta,rt2800usb
usb_storage            39625  1
scsi_mod              122149  5 usb_storage,sg,sr_mod,sd_mod,libata
usbcore               122034  7 usbmon,rt2870sta,rt2800usb,rt2x00usb,usb_storage,ehci_hcd
nls_base                6377  11 isofs,udf,hfsplus,hfs,ntfs,jfs,nls_utf8,nls_cp437,vfat,fat,usbcore

그 다음 DebugFS 파일시스템 타입으로 아래와 같이 마운트 해 주면 된다.

# mount -t debugfs / /sys/kernel/debug
# mount
[생략]
/dev/sdb1 on /media/usb0 type vfat (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/ on /sys/kernel/debug type debugfs (rw)

앞서 설명한 것과 같이 네트워크 인터페이스로 인식을 시켜준다고 하였다. 그럼, tshark 의 -D 옵션을 통해 사용가능한 인터페이스 리스트를 확인할 수 있다.

# tshark -D
1. eth0
2. usbmon1 (USB bus number 1)
3. usbmon2 (USB bus number 2)
4. any (Pseudo-device that captures on all interfaces)
5. lo

기존에는 보이지 않던 usbmon1 과 usbmon2 이 보인다. 그렇다 그럼 이제 이 인터페이스로만 지정해서 패킷 덤프를 해 보면 USB 트래픽을 볼 수 있다는 것이된다. 그런데, 2번과 3번중 어떤것이 올바른 인터페이스일까? 그냥 쉽게는 2번,3번 한번씩 패킷덤프도 해 볼 수 있지만, lsusb 명령어로 usb 정보를 들여다 보자.

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 026: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub

위 화면은 USB 를 연결하기 전이고 다음은 USB 를 연결한 후의 화면이다. 보는 것과 같이 Bus 002 에 새로운 디바이스가 잡혀있는것을 볼 수 있다.

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 026: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 028: ID 090c:1000 Feiya Technology Corp. Flash Drive

그러면, USB 버스 2번이니 위에서 살펴본 인터페이스중 3번인 usbmon2 를 관찰하면 되겠다는 것을 알 수 있다. lsusb 외 usb-devices 명령어를 이용해서도 확인할 수 있다.

# usb-devices
T:  Bus=02 Lev=03 Prnt=26 Port=02 Cnt=01 Dev#= 28 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=090c ProdID=1000 Rev=11.00
S:  Manufacturer=LG Electronics
S:  Product=XTICK
S:  SerialNumber=AA04012700015188
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=300mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

tshark 를 통해서 USB 패킷 데이터를 덤프해 보자. -i 옵션을 통해 인터페이스 번호를 지정해 주었다. 와, USB 트래픽 정보가 잡힌다. 참고로, 와이어샤크 1.2.X 버전 이상을 사용하여야 한다.

# tshark -i 3
Running as user "root" and group "root". This could be dangerous.
Capturing on USB bus number 2
  0.000000         host -> 28.0         USB GET DESCRIPTOR Request DEVICE
  0.000407         28.0 -> host         USB GET DESCRIPTOR Response DEVICE
  0.000422         host -> 26.0         USB GET DESCRIPTOR Request DEVICE
  0.000575         26.0 -> host         USB GET DESCRIPTOR Response DEVICE
  0.000615         host -> 2.0          USB GET DESCRIPTOR Request DEVICE
  0.000658          2.0 -> host         USB GET DESCRIPTOR Response DEVICE
  0.000677         host -> 1.0          USB GET DESCRIPTOR Request DEVICE
  0.000677          1.0 -> host         USB GET DESCRIPTOR Response DEVICE

GUI 버전의 와이어샤크에서는 어떻게 나올까? 다음 그림과 같이 GUI 화면에서도 문제없이 깔끔하게 트래픽 정보가 출력된다.  데이터 영역부분도 보인다.



그러면, 여기서 살짝 의문이 생긴다. 와이어샤크로만 데이터를 덤프할 수 있는 것인가 ? 그렇지는 않다. 네트워크 인터페이스로 잡힌 것이기 때문에 tcpdump 프로그램을 통해서도 볼 수 있다. USB 트래픽 데이터를 파싱해서 보여줄 수 있는 것이면 된다.

# tcpdump -i 3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on usbmon2, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes
09:11:09.835197 CONTROL SUBMIT to 2:28:0
09:11:09.835623 CONTROL COMPLETE from 2:28:0
09:11:09.835647 CONTROL SUBMIT to 2:26:0
09:11:09.835720 CONTROL COMPLETE from 2:26:0
09:11:09.835740 CONTROL SUBMIT to 2:2:0
09:11:09.835845 CONTROL COMPLETE from 2:2:0
09:11:09.835859 CONTROL SUBMIT to 2:1:0
09:11:09.835859 CONTROL COMPLETE from 2:1:0
09:11:12.002810 BULK SUBMIT to 2:28:2
09:11:12.002955 BULK COMPLETE from 2:28:2
09:11:12.002963 BULK SUBMIT to 2:28:1

이 외에도 더 로우 방법으로 확인할 수 있는 방법이 있는데, 직접 디버그파일 시스템을 cat 를 통해 볼 수도 있다. 아래와 같이 말이다.

# cat /sys/kernel/debug/usb/usbmon/2u
ffff88021d618540 1982035431 S Bo:2:028:2 -115 31 = 55534243 a8010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1982035468 C Bo:2:028:2 0 31 >
ffff88021d618540 1982035549 S Bi:2:028:1 -115 13 <
ffff88021d618540 1982035856 C Bi:2:028:1 0 13 = 55534253 a8010000 00000000 00
ffff88021d618540 1982035895 S Bo:2:028:2 -115 31 = 55534243 a9010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1982035963 C Bo:2:028:2 0 31 >
ffff88021d618540 1982035969 S Bi:2:028:1 -115 13 <
ffff88021d618540 1982036213 C Bi:2:028:1 0 13 = 55534253 a9010000 00000000 00
ffff88021d618540 1984037715 S Bo:2:028:2 -115 31 = 55534243 aa010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1984037787 C Bo:2:028:2 0 31 >
ffff88021d618540 1984037793 S Bi:2:028:1 -115 13 <
ffff88021d618540 1984038035 C Bi:2:028:1 0 13 = 55534253 aa010000 00000000 00
ffff88021d618540 1984038056 S Bo:2:028:2 -115 31 = 55534243 ab010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1984038192 C Bo:2:028:2 0 31 >
ffff88021d618540 1984038195 S Bi:2:028:1 -115 13 <
ffff88021d618540 1984038410 C Bi:2:028:1 0 13 = 55534253 ab010000 00000000 00

USB 트래픽을 관찰할 일이 있다면, 와이어샤크를 통한 이 방법이 좋은 방법중에 하나가 될 것이다.  윈도우에서는 와이어샤크를 통해 바로 USB  트래픽을 관찰할 수 없다. 리눅스의 가상 머신에 윈도우를 올려서 사용될 수 있는 방법이 아래 [참고] 를 보면 소개되어 있긴 하다.

추후 시간적 여유가 된다면 윈도우 기반에서도 테스트 해 본 후 결과를 공유하도록 하겠다.

[참고]
1. 와이어샤크 USB 캡쳐
http://wiki.wireshark.org/CaptureSetup/USB

패킷인사이드를 다이나믹뷰로 더욱 생동감 있게 즐겨보세요!

패킷인사이드를 더욱 쉽게 볼 수 있는 다섯가지 뷰를 소개해 드립니다. 시간 구성별로나, 사진 스냅샷과 같은 형태 또는 사이드바와 같이 총 5가지 뷰로 블로그를 볼 수 있습니다.

Flipcard: http://packetinside.com/view/flipcard
Mosaic: http://packetinside.com/view/mosaic
Sidebar: http://packetinside.com/view/sidebar
Snapshot: http://packetinside.com/view/snapshot
Timeslide: http://packetinside.com/view/timeslide

말로 표현방법을 설명하는 것보다는, 직접 사용해 보시고 편한 것으로 사용해 보시면 됩니다. 기존 페이지 출력보다는 좀더 많은 블로그 내용을 빠르게 접근할 수 있는 방법이 될 것입니다. 다만, 이 뷰를 제대로 이용하기 위해서는 인터넷 익스플로러 8 이상, 파이워폭스 3.5 이상, 크롬, 사파리 브라우저등을 이용해야 합니다. 아래 화면과 같이 제대로 표시되지 않는다면, 오래된 버전의 브라우저를 사용하고 있다는 뜻이 되기도 합니다.

 

 

우측 메뉴에 '다이나믹 뷰' 를 통해서도 언제나 쉽게 접근할 수 있습니다.

From Rigel

와이어샤크의 또 다른 유틸리티, Rawshark 의 사용을 알아보자

와이어샤크를 설치하면 같이 배포되는 프로그램으로 Rawshark 가 있다. 주로 GUI 기반에서 사용한다면, wireshark 만을 실행해서 사용하기 때문 다른 유틸리티는 그냥 지나치는 경우가 많다.
Rawshark 이름만으로 추정해 보면, 로우 데이터를 본다는 의미로 추정된다. 이름과 같이 그 의미가 맞다. 로우 libpcap 데이터를 덤프 및 간단한 분석을 수행할 수 있는 기능을 가지고 있다.

우선, Rawshark 의 도움말을 살펴보면 아래와 같은 옵션 사용이 가능하다:

# rawshark -h
Rawshark 1.2.11
Dump and analyze network traffic.
See http://www.wireshark.org for more information.

Copyright 1998-2010 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Usage: rawshark [options] ...

Input file:
  -r <infile>              set the pipe or file name to read from

Processing:
  -R <read filter>         packet filter in Wireshark display filter syntax
  -F <field>               field to display
  -s                       skip PCAP header on input
  -n                       disable all name resolution (def: all enabled)
  -N <name resolve flags>  enable specific name resolution(s): "mntC"
  -d <encap:dlt>|<proto:protoname>
                           packet encapsulation or protocol
Output:
  -S                       format string for fields (%D - name, %S - stringval, %N numval)
  -t ad|a|r|d|dd|e         output format of time stamps (def: r: rel. to first)
  -l                       flush output after each packet

Miscellaneous:
  -h                       display this help and exit
  -v                       display version info and exit
  -o <name>:<value> ...    override preference setting

Rawshark 는 Tshark 와 달리 입력되는 데이터에 대한 정의가 필요하다. 그래서 무작정 실행해 보면 아래와 같은 로그를 보게된다.

# cat test.pcap | rawshark

rawshark: No valid payload dissector specified.


일반적인 형태의 사용과 약간 다르다 보니 혼돈이 오기도 하는데, 정상적으로 실행하기 위해서는 -d 와 -r 옵션을 사용해서 지정해 주어야 한다. 그리고 출력을 원하는 데이터가 있다면 -F 옵션으로 지정해 주어야 한다. Rawshark 는 기본적으로 다음과 같은 입력 레코드가 들어오는 것으로 판단한다. 많이 보던 레코드 형태일텐데, libpcap 에서 사용하는 pcap_pkthdr 구조와 데이터이다.

    struct rawshark_rec_s {
        uint32_t ts_sec;      /* Time stamp (seconds) */
        uint32_t ts_usec;     /* Time stamp (microseconds) */
        uint32_t caplen;      /* Length of the packet buffer */
        uint32_t len;         /* "On the wire" length of the packet */
        uint8_t data[caplen]; /* Packet data */
    };

libpcap 구조 관련해서는 다음 글을 읽어 보면 도움이 된다.

1) PCAP 파일을 파헤쳐 보자 - 그 첫번째 이야기
2) PCAP 파일을 파헤쳐 보자 - 그 두번째 이야기


일단 실행해보면 다음과 같은 형태로 출력이 가능하다.

# cat test.pcap | rawshark -d encap:EN10MB -r- -s -F ip.dst -F http.host
0 FT_IPv4 BASE_NONE - 1 FT_STRING BASE_NONE -
1 1="[FF02::C" -
2 -
3 -
4 0="168.126.63.1" -
5 0="192.168.0.240" -
6 0="168.126.63.1" -
7 0="192.168.0.240" -
8 0="72.14.213.99" -
9 0="192.168.0.240" -
10 0="72.14.213.99" -
11 1="www.goog" 0="72.14.213.99" -
12 0="192.168.0.240" -

일반적인 tcpdump 나 tshark 와 달리 실행방법이 약간은 복잡해 보인다. rawshark 는 입력을 스트림으로 받아 들이기 때문에 앞에서, cat 을 이용했다. 즉, test.pcap 의 내용이 cat 을 통해 읽어 들이고 이 출력을 rawshark 로 넘긴 것이다. 그러므로 -r 옵션으로 - 를 사용하였다. 앞서 rawshark 를 제대로 사용하기 위해서는 -d 와 -r 을 옵션을 사용한다고 하였는데, -d 를 통해 이 데이터가 어떤 것인지 지정해 주었다.  앞에 encap 이라고 되어 있는것은 캡슐화를 뜻하는 것으로 뒤에 EN10MB 는 이더넷 데이터를 뜻한다. 즉, 이 패킷 데이터는 우리가 흔히 사용하는 이더넷 데이터 이라는 것을 지정해 준 것이다. 이런 데이터로는 PPP, FDDI, IEEE802_11 등이 있다. 데이터 타입은 아래 참고의 URL 을 살펴보기 바란다.

여기서 캡슐화라는 것이 나왔는데, 이 캡슐화에 대한 설명은 이미 앞서 포스팅을 해 놓았으므로 읽어보길 바란다.

[링크] 패킷을 보다 자주 접하는 캡슐화(Encapsulation)는 무엇이지?

그리고 -s 는 입력으로 표준 pcap 파일임을 뜻하고, -F 옵션으로 출력할 내용을 지정할 수 있는데, 와이어샤크에서 사용하던 필터를 그대로 사용하면 되므로 어렵지 않게 쓸수 있다. 출력 되어 나오는 것을 보면 아주 심플하다. 다양한 분석기능이 갖춰진 wireshark 와는 다르게 말이다. 말 그대로 로우 데이터를 덤프해서 분석하기 위한 용도이므로 이점은 기억해 두자.  맨앞에 숫자는 패킷의 넘버를 뜻하는 것이고, 그 뒤로 숫자 1 또는 0 이 보인다. 출력 필터로 지정한 것에 대한 필드의 매치 여부를 나타내는 것으로 1이면 매치가 되었다는 것이다. 11번을 보면 HTTP 호스트 정보가 매칭되어서 1 로 표시된것을 볼 수 있다.

마지막으로 앞서 cat 을 통해 출력 시켰는데, 이외에도 tcpdump 를 통해서도 할 수 있고, wireshark 를 통해서도 할 수 있다. 출력을 rawshark 로 넘겨줄수만 있으면 된다.

# tcpdump -r test.pcap -n -w - | rawshark -d encap:EN10MB -r- -s -F ip.dst -F http.host

다음은 eth1 인터페이스를 실시간으로 rawshark 로 넘기는 것이다. 이때 rawshark 옵션으로 -l 옵션을 추가로 사용하였다. 바로바로 실시간으로 데이터가 넘어오기 때문에 바로 Flush 시키도록 한 것이다.

# tcpdump -i eth1 -s 1514 -w - | rawshark -d encap:EN10MB -l -r- -s -F ip.dst -F http.host

[참고]
1. Libpcap 데이터 링크레이어 타입
http://www.tcpdump.org/pcap3_man.html
2. Rawshark 공식 메뉴얼
http://www.wireshark.org/docs/man-pages/rawshark.html
3. 패킷인사이드 libpcap 관련 태그 보기
http://www.packetinside.com/search/label/libpcap