네트워크 모니터링 개요
작성자 정보
- 관리자 작성
- 작성일
컨텐츠 정보
- 1,496 조회
- 0 추천
- 목록
본문
네트워크 모니터링 개요
앞에서는 보안의 관점에서 네트워크 모니터링의 필요성을 언급하였지만 다른 관점에서 접근해 보자. 이 글을 읽고 있는 분이 여러 시스템이나 네트워크 관리자라면 다음의 질문에 답해 보기 바란다.
- 대부분 전체 트래픽은 라우터나 스위치에 MRTG를 걸어 쉽게 알 수 있을 것이다.
그렇다면 가장 많은 트래픽을 유발하는 IP(서버)를 sort하여 실시간으로 모니터링 가능한가?
- 여러분의 네트워크가 유발하는 정상적인 트래픽 중 TCP는 어느 정도인지, UDP나 ICMP 트래픽은 어느 정도인지 알고 있는가?
- 만약 TCP의 경우 웹 트래픽은 어느 정도이고, SMTP, HTTPS, POP3등의 트래픽은 얼마인가?
- bps 뿐만 아니라 전체 트래픽의 pps(초당 패킷수), fps(초당 flow수)는 얼마인가?
- 컨텐츠를 제공하고 있다면 여러분의 시스템에 접속하는 유저 중 ISP별 분류 이를테면 KT, 하나로, 두루넷 이용자는 어느 정도 비율이 되는가?
사실상 이러한 질문은 관리자라면 많이 궁금해 하는 내용이지만 MRTG에 의존하여 모니터링을 하고 있는 대부분의 관리자라면 쉽게 답하기 곤란한 것이 사실이다.
여기에서는 이러한 질문에 답하기 어려운 이유와 답을 할 수 있는 방법을 찾아보도록 할 것이다.
12.1.1 SNMP를 이용한 모니터링
네트워크 규모와 관계없이 가장 대중적으로 사용되는 네트워크 모니터링 방식은 네트워크 장비에 SNMP(Simple Network Management Protocol)를 enable한 후
MRTG(http://www.mrtg.org/)와 같은 모니터링 프로그램을 이용하여 네트워크 트래픽이나 장비의 부하율 등을 체크하는 것이다. 특히 MRTG는 단순히 트래픽뿐만 아니라 장비의 부하율이나 온도, 시스템 자원, ping 결과 값 등 수치로 나타낼 수 있는 모든 변동 상황을 5분, 매일, 매주, 1년 단위로 직관적으로 모니터링 할 수 있어 거의 모든 서버/네트워크 관리자들이 필수적으로 사용할 만큼 대중적으로 사용되고 있다.
그러나 MRTG만을 사용하는 환경에서 트래픽이 갑자기 증가하였을 경우에는 총 트래픽의 변동 여부만 알 수 있을 뿐, 만약 트래픽이 평소와는 다른 양상을 보일 때 유발된 트래픽의 특성(이를테면 TCP인지 UDP인지 아니면 ICMP인지, TCP나 UDP라면 몇 번 포트에서 유발된 트래픽인지 등)은 무엇인지 등, 문제가 발생한 원인을 규명하고 좀 더 심화된 모니터링을 하기 위해서는 어쩔 수 없는 한계가 있을 것이다.
그러나 이 문제는 SNMP 자체가 Layer 2까지만 처리하기 때문이지 MRTG 프로그램 자체의 한계는 아니다.
아래 그래프는 라우터에 snmp를 설정 후 MRTG를 이용하여 라우터의 트래픽을 모니터링 한 것인데, 17시 30분경에 평소와는 달리 약 30M 정도 트래픽이 상승한 사실은 알 수 있지만, 이 트래픽의 특성(이를테면 어떤 IP에서 어떤 서비스로 유발된 트래픽인지 등)은 알 수 없다.
[그림] MRTG에서의 트래픽 상승
snmp를 이용하여 장비의 다양한 정보를 모니터링 할 수 있다.
다음의 주소에 접속하면 cisco나 com등 다양한 벤더별로 mrtg를 위한 cfg 파일이 존재하는데, 이를 이용하여 트래픽(bps)뿐만 아니라 pps , CPU, memory 사용률, CRC에러, 포트에러, 디스크용량, 온도 등 다양한 모니터링이 가능하다.
http://www.somix.com/support/mrtg_repository.php
* 6509 CPU 예 장비의 CPU를 모니터링 하고자 할 때 설정한다. 다량의 pps가 유발되는 ddos공격 등 발생시 cpu가 상승할 수 있다.
* 6509 온도 모니터링 예 IDC에서는 쾌적한 온도를 유지하는 것이 중요하므로 이를 이용하여 원격으로 온도모니터링이 가능하다.
* 각 포트별 브로드캐스트 패킷 각 포트별로 브로드캐스트 패킷의 개수를 모니터링 할 수 있는데, 아래의 경우 G2/46포트에서의 브로드캐스트 패킷개수를 보여주게 된다. 각 포트별로 다른 값을 지정하면 된다.
* 각 포트별 pps 각 포트별로 inbound/outbound pps를 모니터링 할 수 있다. 아래는 G2/46 포트에서의 pps를 보여주게 되는데, &를 기준으로 해서 앞에 것은 in packet, 뒤에 것은 out packet을 의미한다.
* 각 포트별 error 각 포트별로 error 발생 여부에 대한 모니터링이 가능하다.
만약 mrtg를 이용할 때 송신과 수신 또는 in과 out 을 반대로 표현하고 싶을 때가 있다. 이를테면 스위치와 서버의 트래픽을 모니터링 하고자 할 때 mrtg는 송신과 수신이 서로 반대인데, 두 트래픽을 합쳐야 할 경우가 있을 수 있다. 이러한 경우에는 아래와 같이 Target부분에 - 를 붙여주면 된다.
Target[mrtg-total]: -26:public@router:::::2 + 16777219:public@192.168.0.241 |
12.1.2 ip accounting과 netflow 개요
앞에서 ‘트래픽의 특성’을 파악하기 위해서는 snmp에 한계가 있음을 살펴보았는데, 이를 해결하기 위해 라우터에서 기본적으로 제공하는 모니터링 기능 중 “ip accounting”과 “netflow”를 이용하면 장비를 통과하는 트래픽의 특성을 쉽게 모니터링 할 수 있다.
아래는 특정 인터페이스의 트래픽을 모니터링 하기 위한 “ip accounting” 설정 예제를 보여주고 있다.
ROUTER#conf t // global config 모드로 변경 ROUTER(config)#int serial1 // serial1 번 인터페이스 모드로 변경 ROUTER(config-if)#ip accounting // ip accounting 기능 설정 ROUTER(config-if)#Ctrl + Z // Ctrl 키를 누른 상태에서 z키 입력 ROUTER#show ip accounting // ip accounting 결과 보기 Source Destination Packets Bytes 211.17.47.11 65.192.28.33 2 120 211.17.45.28 209.85.13.32 1 60 211.17.45.184 216.32.243.7 1 44 211.17.47.112 198.41.3.54 5 212 211.17.45.34 198.41.0.4 2 98 211.17.46.4 209.247.164.36 1 112 211.17.47.13 216.239.46.140 42 56431 211.17.45.187 216.87.103.212 19 28500 |
위의 ip accounting은 serial 1번 인터페이스를 통해 outbound 되는 소스ip와 목적지ip 그리고 각 패킷의 개수와 사이즈(byte)등의 정보를 보여주고 있다.
만약 특정 목적지(Destination)나 소스(Source)에서의 트래픽이 특별히 많을 경우에는 해당 트래픽을 유심히 살펴볼 필요가 있다.
또는 소스는 1개인데, 목적지가 여러 개이거나 반대로 목적지는 1개인데 소스가 여러 개인 경우 ip나 포트 등을 스캔하는 것은 아닌지 또는 공격 등을 의심해 보아야 할 것이다.
필자의 경우도 초기에 회사에서 E1 전용회선을 사용할 때 갑자기 트래픽이 가득 차서 느려질 때 이를 이용하여 누가 많은 트래픽을 유발하는지 찾곤 했었는데 대부분이 동영상을 다운로드 하거나 P2P를 통해 파일을 전송하는 경우 또는 웜 바이러스에 감염된 경우가 대부분이었다.
이와 같이 ip accounting은 어떤 ip에서 많은 트래픽을 유발하는지 규명하고자 할 때 간편하게 사용될 수 있다.
그러나 E1(2M) 정도의 회선이라면 가능하겠지만 그 이상의 트래픽을 서비스하는 경우 라우터 부하를 유발하므로 사용을 자제하여야 한다. ip accounting 설정 후 해제하려면 no ip accounting을 입력하면 된다.
그리고 앞에서와 같이 매번 라우터로 로그인하여 CLI(Command Line Interface)환경에서 명령어를 설정하고 모니터링하기가 번거로우면 아래 그림과 같이 웹을 통해 상시적으로 모니터링이 가능한 CIPAF(http://cipaf.sourceforge.net/)라는 프로그램을 이용할 수도 있다.
[그림] CIPAF를 이용한 예
그러나 ip accounting은 간단한 모니터링은 가능하겠지만 다소 부족한 점이 느껴진다.
따라서 좀 더 다양하고 많은 기능을 이용하기 위해서는 netflow라는 것을 이용할 수 있는데, 아래는 라우터에서 제공하는 또 다른 기능인 netflow 설정 예제를 보여준다.
ROUTER#conf t // config 모드로 변경 ROUTER(config)#int serial1 // serial 1번 인터페이스 선택 ROUTER(config-if)#ip route-cache flow // netflow 기능 설정 ROUTER#show ip cache flow // netflow 결과 보기 IP packet size distribution (360715 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .832 .036 .007 .007 .006 .013 .005 .004 .011 .008 .007 .009 .006 .004
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .004 .003 .007 .004 .017 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes 159 active, 65377 inactive, 50342 added 789091 ager polls, 0 flow alloc failures last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 1 0.0 10 55 0.0 71.6 15.6 TCP-FTP 916 0.0 3 47 0.0 3.9 8.8 TCP-FTPD 12 0.0 5 500 0.0 6.3 5.4 TCP-WWW 27967 0.0 9 92 0.0 7.0 4.6 TCP-SMTP 2555 0.0 11 221 0.0 7.8 4.4 TCP-other 1219 0.0 4 180 0.0 4.4 8.5 UDP-DNS 14424 0.0 2 64 0.0 6.7 13.8 UDP-NTP 22 0.0 1 76 0.0 0.0 13.1 UDP-other 4733 0.0 1 152 0.0 0.6 14.4 ICMP 714 0.0 7 300 0.0 8.1 14.6 Total: 52563 0.0 6 104 0.0 6.3 8.3
src dest pr src port des port 203.254.149.28 134.111.200.231 06 0401 0089 203.254.149.28 134.111.200.232 06 0402 0089 203.254.149.28 134.111.200.233 06 0403 0089 203.254.149.28 134.111.200.234 06 0404 0089 ..... 중략 |
netflow를 이용하려면 IOS 버전이 12.x 이상이어야 하고, CEF (Cisco Express Forwarding) 또는 distributed CEF가 enable되어 있는 것이 좋다.
CEF를 enable하려면 global config 모드에서 “ip cef" 또는 ”ip cef distributed“를 실행하면 된다.
참고로 현재 IOS의 버전은 “show version"을 입력하면 확인할 수 있다. |
결과를 보면 직관적으로 무엇을 의미하는지 알 수 있을 것이다.
제일 먼저 패킷 사이즈별로 분포가 나오는데, 32바이트에서 64바이트 사이가 83%정도로 가장 많은 것을 알 수 있다.
그 다음에는 프로토콜-서비스별로 총 flow 수, 패킷 수, 바이트 수 및 초당 flow 수, 패킷 수, 바이트 개수가 나온다.
UDP 1434번을 사용하는 MS-SQL웜으로 인한 1.25 대란이 발생했을 때 필자는 라우터에 로그인하여 제일 먼저 이 명령어를 실행했었는데, 당연히 UDP-other가 가장 많았었다.
그 다음으로 보이는 것이 현재 네트워크를 지나는 패킷의 소스/목적지/프로토콜/포트정보인데, 여기에서 보이는 포트 및 프로토콜은 우리가 익숙하게 사용하는 10진수가 아니라 16진수로 표현된 것이므로 어떤 포트 및 프로토콜인지 해석하려면 힘들기 때문에 익숙하고 알기 쉬운 10진수로 변환하여야 한다.
이를테면 위의 경우 목적지 포트(des port)에 많이 보이는 0089를 10진수로 변환하면
0089 = 163*0 + 162*0+161*8+160*9 = 137
이므로 TCP(06) 137번 포트인 것을 알 수 있다.
137/TCP인 netbios의 경우 바이러스나 웜(Worm) 발생 시 자주 보이는 포트인데, 만약 137을 포함한 패킷만을 보려면 아래의 명령어를 실행하면 된다.
# show ip cache flow | include 0089 |
또는 줄여서
# sh ip ca fl | i 0089 |
참고로 여기에서 include는 UNIX의 grep과 같은 의미로 0089를 포함한 라인만 출력하라는 의미이며 반대로 특정한 문자열을 제외한 라인만 출력하려면 exclude를 사용하면 된다.
또한 프로토콜 역시 같은 방법으로 10진수로 변환하면 다음과 같다.
06 = 161*0 + 160*6 = 6 (TCP)
11 = 161*1 + 160*1 = 17 (UDP)
IANA에서 지정한 프로토콜 번호는 아래 URL 및 표에서 확인할 수 있는데 특히 TCP는 6, UDP는 17, ICMP는 1인데, 이 값은 네트워크에서 자주 사용되므로 가능한 외워 두는 것이 좋다.
http://www.iana.org/assignments/protocol-numbers
숫자 프로토콜 설명 RFC 및 참고 ------- ------- -------- ---------- 0 HOPOPT IPv6 Hop-by-Hop Option [RFC1883] 1 ICMP Internet Control Message [RFC792] 2 IGMP Internet Group Management [RFC1112] 3 GGP Gateway-to-Gateway [RFC823] 4 IP IP in IP (encapsulation) [RFC2003] 5 ST Stream [RFC1190,RFC1819] 6 TCP Transmission Control [RFC793] 7 CBT CBT [Ballardie] 8 EGP Exterior Gateway Protocol [RFC888,DLM1] 9 IGP any private interior gateway [IANA] 10 BBN-RCC-MON BBN RCC Monitoring [SGC] 11 NVP-II Network Voice Protocol [RFC741,SC3] 12 PUP PUP [PUP,XEROX] 13 ARGUS ARGUS [RWS4] 14 EMCON EMCON [BN7] 15 XNET Cross Net Debugger [IEN158,JFH2] 16 CHAOS Chaos [NC3] 17 UDP User Datagram [RFC768,JBP] |
[표] 프로토콜 번호 목록
같은 방식으로 아래는 netflow를 이용하여 한때 유행했던 Nachi worm에 감염된 서버를 검색하는 방법을 보여주고 있다.
Nachi worm은 icmp echo-request(type 8 code 0)로 scan을 하게 되는데, 여기에서 Pr(프로토콜)이 01인 것은 앞에서 이야기한대로 ICMP 패킷임을 뜻하며 ICMP는 TCP나 UDP 와 달리 port의 개념이 없다는 것을 참고하기 바란다.
Router# show ip cache flow|include 0000 0800
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa2/0 211.47.94.48 Fa1/0 XX.XX.XX.119 01 0000 0800 1 Fa2/0 211.47.94.48 Fa1/0 XX.XX.XX.169 01 0000 0800 1 Fa2/0 211.47.86.157 Fa1/0 XX.XX.XX.63 01 0000 0800 1 Fa2/0 211.203.1.118 Fa1/0 XX.XX.XX.111 01 0000 0800 1 Fa2/0 211.208.248.6 Fa1/0 XX.XX.XX.95 01 0000 0800 1 |
그렇다면 ICMP 패킷은 netflow를 활용하여 어떻게 확인할 수 있을까? ICMP 패킷은 바로 목적지 포트(DstP) 정보를 보면 된다.
아래에서 목적지 포트는 0800인데, 여기에서 8은 ICMP type이고 뒤에 있는 00은 코드를 뜻한다.
따라서 type 8, code 0은 icmp echo request를 뜻하게 되는 것이다.
같은 방식으로 301은 type 3, code 01이므로 icmp host unreachable이 된다.
만약 이 값이 16진수로 보일 경우에는 10진수로 변환하면 된다.
netflow는 라우터에서만 볼 수 있는 것은 아니다.
Switch에서도 설정 및 확인할 수 있는데, 아래의 경우 백본 스위치로 많이 사용하는 catalyst 6500 native ios에서 netflow 설정 방법을 보여주고 있다.
6500_SWITCH# conf t 6500_SWITCH(config)# mls flow ip full // hybid 모드에서는 set mls flow full 6500_SWITCH(config)# mls nde sender |
이때 결과는 라우터와 약간 다른데, 아래와 같이 프로토콜이나 서비스명이 16진수로 보이지 않고 10진수로 나타나거나 아예 프로토콜 이름과 서비스명으로 출력되기 때문에 변환할 필요 없이 바로 알 수 있어 가독성이 좋다.
6500_SWITCH# show mls ip detail // hybrid 모드에서는 show mls entry Displaying Netflow entries in Supervisor Earl DstIP SrcIP Prot:SrcPort:DstPort Src i/f:AdjPtr -------------------------------------------------------------------- Pkts Bytes Age LastSeen Attributes --------------------------------------------------- QoS Police Count Threshold Leak Drop Bucket Use-Tbl Use-Enable -----------+------------+---------+-----------+----+-------+-------+----------+ 211.xx.xx.xxx 24.312.72.2 tcp :42532 :telnet 0 : 00 0 1229 20:12:35 L3 - Dynamic 0x0 0 0 0 NO 40 NO NO 211.xx.xx.xx 210.44.7.159 icmp:0 :0 0 : 00 0 94 20:11:01 L3 - Dynamic 0x0 0 0 0 NO 92 NO NO 211.xx.xx.xx 211.49.108.213 icmp:0 :0 0 : 00 0 239 20:08:36 L3 - Dynamic 0x0 0 0 0 NO 92 NO NO 211.xx.xx.xxx 211.45.207.172 udp:dns :1043 0 : 00 0 82 20:11:13 L3 - Dynamic 0x0 0 0 0 NO 92 NO NO |
Cisco 계열 스위치에는 IOS 종류에 따라 set 기반의 CatOS와 라우터 기반의 Native IOS가 있는데, 백본 스위치로 많이 사용되는 6500 스위치의 경우 라우터와 명령어 방식이 동일한 Native IOS로 사용될 수도 있고, CatOS와 IOS가 결합된 hybrid 방식 이렇게 두 가지로 사용 가능하다.
각각의 장단점이 있으므로 어떤 방식이 더 좋다고 설명할 수는 없지만 최근에는 Native를 많이 사용하는 추세이다. |
다시 한 번 강조하지만 앞에서 잠시 살펴본 ip accounting은 라우터의 CPU나 메모리를 많이 차지하므로 실행했을 경우 라우터에 많은 부하를 유발하여 심할 경우 라우터가 다운되는 경우까지 있으므로 트래픽이 많은 경우에는 각별히 주의하여야 한다.
즉, T1(1.5M)이나 E1(2.048M) 정도의 전용선을 사용하는 사무실의 라우터라면 활용 가능하지만 그 이상의 트래픽을 처리하는 곳에서는 절대 실행하면 안 된다.
아마도 실행과 동시에 라우터의 CPU 부하가 점차 상승하여 라우터를 재부팅해야 할 일이 생기거나 그렇지 않더라도 부하가 많이 상승될 것이다.
이에 반해 이제부터 본격적으로 살펴볼 netflow는 라우터에 부담을 주지 않으면서도 ip accounting의 결과를 포함하는 등 ip accounting에 비해 더욱 유용한 결과(소스ip,목적지ip,포트, 프로토콜 등 7가지 정보)를 보여주므로 ip accounting보다 더욱 권장되는 방법이다.
netflow가 제공하는 7가지 항목은 다음과 같다.
[그림] netflow가 제공하는 항목
관련자료
-
이전
-
다음
