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

레이블이 트래픽인 게시물을 표시합니다. 모든 게시물 표시

2013년 1월 22일 화요일

콘솔 기반의 리눅스/BSD 네트워크 모니터 vnStat

vnStat 는 Linux, BSD 계열의 네트워크 트래픽 모니터이다. 콘솔기반의 도구로 간단하게 사용가능하며, 패킷 스니핑 도구와 같이 직접적으로 트래픽을 모니터 하지 않고 커널에서 제공해주는 네트워크 인터페이스 정보를 기반으로 정보를 보여준다. 직접 스니핑을 하지 않으므로 시스템 자원 사용면에서는 가볍다. 리눅스에서 사용하기 위해서는 커널 2.2 이상 되어야 한다.

주요기능으로는

- 루트 권한 없이도 사용할 수 있다.
- 낮은 시스템 자원 사용
- 다양한 출력 옵션 지원 (요약, 시간, 일,월,주 별로 제공 등)
- libgd 를 이용한 png 이미지 출력
- 동시에 여러개의 인터페이스를 모니터링 할 수 있음
- 빠르고 간단하게 설치하여 사용할 수 있다.

소스는 다음 경로에서 받을 수 있다.
http://humdi.net/vnstat/vnstat-1.11.tar.gz

사용할 수 있는 옵션은 아래와 같으며, 워낙 간결해서 옵션 이름만 보아도 어떤 기능인지 추측이 될 것이다.

$ vnstat --help
 vnStat 1.11 by Teemu Toivola 

         -q,  --query          query database
         -h,  --hours          show hours
         -d,  --days           show days
         -m,  --months         show months
         -w,  --weeks          show weeks
         -t,  --top10          show top10
         -s,  --short          use short output
         -u,  --update         update database
         -i,  --iface          select interface (default: eth0)
         -?,  --help           short help
         -v,  --version        show version
         -tr, --traffic        calculate traffic
         -ru, --rateunit       swap configured rate unit
         -l,  --live           show transfer rate in real time

See also "--longhelp" for complete options list and "man vnstat".

-h 옵션을 사용해 시간대별로 트래픽 현황을 표시한 것이다.

$ vnstat -h
 eth1                                                                     21:25
  ^           r
  |           r
  |           r                                            r
  |        r  r                                            r
  |      t r  r                                            r            t
  |     rt r  r                                            r  r      t  t
  |     rt r  r                                            r  r      t  t
  |     rt r  r         t                      r           r  r      t  t
  |     rt r  rt        t                   r  r        r  rt rt  t rt rt  t
  |  rt rt rt rt rt r  rt r              r  r  r  r  rt rt rt rt rt rt rt  t
 -+--------------------------------------------------------------------------->
  |  22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21

 h  rx (KiB)   tx (KiB)      h  rx (KiB)   tx (KiB)      h  rx (KiB)   tx (KiB)
22    250,801    205,825    06    100,529     49,054    14    205,356    157,877
23    705,144    885,844    07     52,806     44,130    15    258,228    226,265
00    928,792    224,789    08     52,298     45,230    16  1,028,043    343,843
01  1,271,180    292,260    09     70,396     61,719    17    755,804    293,309
02    212,296    186,481    10    155,502     72,451    18    235,691    284,886
03    165,931     91,943    11    266,673     92,497    19    275,554    658,386
04    150,997    437,071    12    392,244    122,185    20    307,819    850,813
05    180,170     56,391    13    133,829    120,555    21    117,474    292,787

일별로 트래픽 현황을 살펴보는 것이다.

$ vnstat -d

 eth1  /  daily

         day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      07/03/09     10.90 GiB |    6.39 GiB |   17.29 GiB |    1.68 Mbit/s
      07/04/09     21.21 GiB |    5.65 GiB |   26.87 GiB |    2.61 Mbit/s
      07/05/09     10.58 GiB |    6.67 GiB |   17.25 GiB |    1.67 Mbit/s
      07/06/09     49.90 GiB |    9.69 GiB |   59.59 GiB |    5.79 Mbit/s

주별로도 트래픽 현황을 볼 수 있다.

$ vnstat -w

 eth1  /  weekly

                      rx      |     tx      |    total    |   avg. rate
   ---------------------------+-------------+-------------+---------------
    last 7 days    114.11 GiB |   56.58 GiB |  170.69 GiB |    2.38 Mbit/s
      last week    137.79 GiB |   58.96 GiB |  196.75 GiB |    2.73 Mbit/s
   current week    102.60 GiB |   49.92 GiB |  152.52 GiB |    2.49 Mbit/s
   ---------------------------+-------------+-------------+---------------
      estimated    121.38 GiB |   59.06 GiB |  180.44 GiB |

다음은 이미지 출력 기능을 이용해 만들어 낸 것이다.

summary

vnStat 의 장점으로는 PHP 웹 기반으로 구현된 것도 있고 윈도우 기반의 SystrayIcon 도 있다. 이미지 출력 또한 지원한다.( http://humdi.net/vnstat/cgidemo/ )
루트 권한 없이 가볍게 트래픽 현황을 모니터링 하고 싶은 분들에게 추천해 본다.

[참고]
1. http://humdi.net/vnstat/

2013년 1월 7일 월요일

NetEM을 이용한 Traffic Shaping (패킷 지연,유실,대역폭 제한등)

NetEM(Network Emulation)기능을 활용한 패킷의 지연, 중복, 유실 등을 테스트해보자. 에뮬레이션은 다양한 관점에서 활용될 수 있다. 애플리케이션의 벤치마크라든지 제품의 테스트 또는 대역폭의 제한으로까지 이용할 수 있다.

NetEM 은 크게 2개의 컴포넌트로 구성되어 있다. 큐를 위한 커널 모듈과 설정을 위한 커맨드라인 도구인 tc 가 있다. 커널모듈은 2.6.8 이후부터 통합되었고, iproute2 패키지의 한 부분이다. 여기서는 Traffic Shaping 과 관련하여 소개를 해 보고자 한다. Traffic Shaping 은 네트워크 트래픽을 제한하여 자원에 대한 우선순위를 조정한다. 사전에 정의된 분류, 정책, 큐 등을 이용하여 네트워크 자원을 필요에 따라 효과적으로 정의하는 것이다. 이것을 통해 여러분들은

- 네트워크 서비스 조절
- 대역폭의 제한
- 서비스에 대한 QoS(Quality of Service) 보장

을 통해 네트워크의 안정적인 운영, 서비스 가용성등을 확보할 수도 있다.

기본적으로 큐는 FIFO 패킷 큐 형태로 동작한다. 학교 수업때 한번쯤 들어보았을 만한 이 것은 먼저 들어온 것이 먼저 나간다는 First In First Out 개념이다.

이제 몇 가지 사용 예제를 알아볼 것인데, 여러분들이 사용하는 커널이 2.6.8 이상 이라면 특별한 설치는 필요하지 않다. 아마 대부분의 경우 사용할 수 있을 것이다.

해당 기능은 커널 컴파일 옵션시 다음 그림과 같이 선택되어 있으면 된다.

예제를 설명하기 전에 주로 'tc' 커맨드 도구를 이용하여 설명을 할 것이다. tc 의 기본적인 사용방법은 아래와 같다:

tc qdisc [ add | change | replace | link ] dev DEV [ parent qdisc-id |

root ] [ handle qdisc-id ] qdisc [ qdisc specific parameters ]

tc class [ add | change | replace ] dev DEV parent qdisc-id [ classid

class-id ] qdisc [ qdisc specific parameters ]

tc filter [ add | change | replace ] dev DEV [ parent qdisc-id | root ]

protocol protocol prio priority filtertype [ filtertype specific param‐

eters ] flowid flow-id

tc [ FORMAT ] qdisc show [ dev DEV ]

tc [ FORMAT ] class show dev DEV

qdisc 는 Queue Discipline (qdisc) 로 패킷을 받고 서비스하기 위한 순서를 정하기 위한 어떤 룰들의 집합이라고 보면 된다. 즉, 이것은 패킷 큐로 패킷을 전송할때 어떤 알고리즘을 사용해 패킷을 보낼지 정하는 것이다. qdisc 는 Classless, Classful, Root, egress, ingress 등이 있다. Root 는 classful/classless 랑 상관없이 각 네트워크 인터페이스의 상위 qdisc 이고 egress 는 밖으로 나가는 패킷에 대해서만 동작하고 ingress 는 내부로 들어오는 트래픽에 대해서 동작한다.

- 패킷 80ms 지연하기

# tc qdisc add dev eth0 root netem delay 80ms

add 를 통해 dev 로 네트워크 인터페이스를 정의해 주고 qdisc 를 처리하기 위한 이름을 netem 로 지정하였다. 그리고 마지막으로 delay 를 80ms 주었다.

일단 정상적인 지연을 적용하기 전에 Ping 을 해 보았다. 평균적으로 0-1ms 속도가 나왔다. 하지만, 지연을 적용하고서는 다음과 같이 81ms 정도로 지연되었다.

# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=81.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=2 ttl=244 time=81.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=81.2 ms
^C
--- 203.255.xxx.xxx ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 81.067/81.117/81.208/0.064 ms

- 패킷을 랜덤하게 지연시키기 (30ms ~ 80ms)

특정 값으로 정하기 보다는 지정된 범위안에서 랜덤하게 지연하는 것이다. 명령어 마지막에 추가적으로 값을 하나 더 지정해 주면 된다.

# tc qdisc change dev eth0 root netem delay 80ms 30ms
# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=77.1 ms
64 bytes from 203.255.xxx.xxx: icmp_req=2 ttl=244 time=93.7 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=78.8 ms
64 bytes from 203.255.xxx.xxx: icmp_req=4 ttl=244 time=100 ms
^C
--- 203.255.xxx.xxx ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 77.131/87.483/100.138/9.756 ms

- 기존에 정의된 지연을 다른 값으로 변경

처음 add 를 사용한 것과 달리 change 라고만 바꿔주고 delay 시킬 값을 지정해 주면된다.

# tc qdisc change dev eth0 root netem delay 30ms
# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=31.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=2 ttl=244 time=31.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=31.0 ms
^C
--- 203.255.xxx.xxx ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 31.024/31.062/31.090/0.205 ms

- 현재 정의된 네트워크 인터페이스의 설정 값 확인

# tc qdisc show dev eth0
qdisc netem 8001: root refcnt 2 limit 1000 delay 30.0ms

- 패킷 유실 15% 설정하기

loss 라는 파리미터를 주고 값을 입력한다. 여기서는 약 15% 정도 유실을 설정하였다.

# tc qdisc change dev eth0 root netem loss 15%
# tc qdisc show dev eth0
qdisc netem 8001: root refcnt 2 limit 1000 loss 15%
# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=0.935 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=1.36 ms
64 bytes from 203.255.xxx.xxx: icmp_req=4 ttl=244 time=1.10 ms
64 bytes from 203.255.xxx.xxx: icmp_req=6 ttl=244 time=1.01 ms
64 bytes from 203.255.xxx.xxx: icmp_req=7 ttl=244 time=1.00 ms
64 bytes from 203.255.xxx.xxx: icmp_req=8 ttl=244 time=1.57 ms
^C
--- 203.255.xxx.xxx ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7011ms
rtt min/avg/max/mdev = 0.935/1.164/1.570/0.227 ms

ping 을 해보면 패킷이 유실되는 것 같이 지연이 발생한다.
예를들어 0.1% 라면 대략 1000개중에 1개 정도가 랜덤하게 Drop 된다고 볼 수 있다.

- 패킷 중복

# tc qdisc change dev eth0 root netem duplicate 1%

duplicate 를 이용하여 정의하면 된다.

- 패킷 깨트리기

# tc qdisc change dev eth0 root netem corrupt 0.1%

- 정의된 설정정보 제거하기

# tc qdisc del dev eth0 root
# tc qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

- 특정 IP 목적지 우선순위 조정

203.255.xxx.xxx 로 나가는 것은 Priority 를 3으로 조정하는 것이다.

# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst 203.255.xxx.xxx/32 flowid 1:3
# tc qdisc show dev eth0
qdisc prio 1: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

- 패킷 대역폭 정의하기

# tc qdisc add dev eth0 root handle 1:0 netem delay 100ms
# tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 256kbit buffer 1600 limit 3000
# tc -s qdisc ls dev eth0
qdisc netem 1: root refcnt 2 limit 1000 delay 100.0ms
Sent 306774 bytes 4269 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 5p requeues 0
qdisc tbf 10: parent 1:1 rate 256000bit burst 1600b lat 43.8ms
Sent 305784 bytes 4254 pkt (dropped 0, overlimits 3 requeues 0)
backlog 0b 5p requeues 0

지연을 100ms 로 지정하였고, 대역폭을 256Kbit 로 설정하였다.

이상 여기까지 간단히 NetEM 을 이용한 트래픽 제어를 살펴보았다. 간단하게만 언급하였으니 세부적인 것은 Man Page 등을 살펴보길 바란다.

[참고]
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

2012년 5월 2일 수요일

*NIX 콘솔 기반 네트워크 사용량 표시 도구 - nload

현재 네트워크 사용량을 표시해주는 nload 를 소개한다. 사실 너무나도 많은 도구들이 있는데, 그래도 이런 형태의 도구는 있다고 알아두면 좋기 때문에 이름만은 기억해 두자. 'nload' 는 콘솔 기반의 프로그램으로 실시간으로 네트워크 상태를 표시해 준다. 아스키 형태의 그래프로도 말이다.

크게 Incoming/Outgoing 으로 화면이 나뉘어져 있으며 옵션은 다음과 같다.

nload [-a period] [-i max_scaling] [-m] [-o max_scaling] [-t interval]
[-u h|H|b|B|k|K|m|M|g|G] [-U h|H|b|B|k|K|m|M|g|G] [devices]

디바이스가 여러개 있는 경우 -m 으로 한번에 표시할 수 있으며, -t 로 화면의 Refresh 시간을 지정할 수 있다. 기본 값은 500 밀리세컨드 이다. 참고로 만약 100 밀리세컨드 이하로 값을 지정하면 빈번하게 계산해야 하기 때문에 부정확해 질 수도 있다는 점은 알아두길 바란다.

-u 로 트래픽 수치 표현 방법을 지정할 수 있다. 비트, 킬로비트, 메가 비트등의 옵션이 있다.

F2 키를 누르면 옵션 화면이 나타나서 설정 값등을 볼 수 있으며, 이동키를 통해 움직일 수도 있다.

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

http://www.roland-riegel.de/nload/

데비안 계열 사용자는 apg-get install nload 로 쉽게 설치할 수 있다.

2012년 1월 8일 일요일

1분에 640 테라바이트 트래픽이 흘러다닌다고?

과연, 인터넷에서 전송되고 있는 데이터량은 얼마나 될까? 최근 인텔(Intel)에서 재미있는 인포그래픽을 발표하였다. 매 분 인터넷 상에서 무슨일이 일어나는지 주요한 지표를 수치화 한 것이다. 트래픽 데이터 관점에서만 보더라도 인텔은 인프라에 대한 투자는 충분히 이뤄지고 있는지 질문을 던지고 있다. 인터넷에 접속되는 디바이스는 전 세계 인구를 넘어 설 만큼 크게 증가하고 있는데, 과연 네트워크는 이러한 예측에 충분히 대비하고 있는가에 대한 것이다.

[이미지출처 : 인텔]

약간 관점을 달리해서 생각해 보자. 각국 정부는 사회기반시설에 대한 투자를 한다. 도로, 항만, 철도 기타 등에 말이다. 인터넷 인프라는 투자하면 안되는 것일까? 어찌보면 이제 인터넷은 세계 경제 움직임의 중심에 서 있기도 하다. 그런 의미에서 보면, 네트워크 인프라는 중요하지 않을 수 없다.

그건 그렇고, 인포그래픽의 주요한 부분을 정리하면 다음과 같다:

- 전세계 IP 네트워크에서 매 분 마다 거의 640 테라 바이트의 트래픽이 흘러다니고 있다.
- 6백만 페이스북 페이지 뷰어, 2백만개의 구글 검색 쿼리
- 유투브에 30시간의 비디오 데이터가 올려지고
- 130 만명이 비디오를 본다.

한달, 아니 1주도 아니고 매 분마다 발생하고 있는 데이터라고 한다.

수치화 해서 보니 어마어마한 데이터다. 인프라 관리 입장에서 보면 이 수많은 데이터를 어떻게 관리하고 저장하고 운영해야 할지 참 쉽지 않은 일들이다.

이렇게 엄청난 데이터가 네트워크를 통해서 흘러다니고 있는데, 분석한다면 ?
여러분의 상상력에 맡기겠다.

2011년 4월 12일 화요일

암호화된 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

2010년 12월 20일 월요일

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

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

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

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

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

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

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

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

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

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

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

# apt-cache search libsdl-sound

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

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

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

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

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

$ ./tcpsound

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

proto src dst wav path

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