Tip! Tip! Tip!은 싸이버정보통신에서 네트워크 엔지니어로 종사하고 있는
박상철(zesum@cyberinfocomm.com)씨가 현업에서의 경험을 공유하고, 실무에 적용할 수 있는 정보를 제공하고자
마련한 것입니다. 네트워크와 관련된 많은 문서와 서적이 있지만 단순히 이론적인 측면에 많이 치우쳐져 있습니다. 이 코너는 현장에서
일하는 엔지니어와 네트워크 관리자들이 필요로 하는 살아있는 지식을 전달하는 역할을 할 것입니다.
박
상철 | 싸이버정보통신 네트워크 엔지니어
ip account와 cache flow를 이용한
라우터에서의 패킷 분석
특정 구간을 지나가는 모든 패킷의 종류를 정확히 알기 위해서는 포트 미러링을 한 후 스니퍼 등을 연결해 패킷 캡처를 해야
한다. 하지만, 간단하게 측정하고자 할 때는 추가 장비 없이 라우터에서 제공하는 기능을 이용할 수 있다. 라우터에서 어떤 종류의
패킷이 지나가는지를 알아 볼 수 있는 방법으로 (그림 1)과 같이 ip account를 이용하는 방법과 ip route-cache
flow를 이용하는 방법 두 가지가 있는데, 지금부터 이들에 대해 살펴보도록 하자.
<ip account를 이용하는 방법>
인터페이스 기준으로 나가는 방향의 패킷을 볼 수 있다. (그림 1)에서 인터페이스 e0에 ip account 설정을 해주면
라우터에서 e0을 통해 빠져나가는 트래픽을 볼 수 있다.
[1] config 방법
Router(config)# interface FastEthernet 0
Router(config-if)#
ip accounting output-packets
Router(config-if)# ^Z
[2] 확인
Router# show running-config
...
interface
FastEthernet0
ip address 192.168.1.1 255.255.255.0
ip
accounting output-packets
...
[3] 본격적인 분석
Router# show ip accounting
(표 1)의 결과를 텍스트 파일로 저장해 엑셀에서 불러온 후 정렬을 하면 원하는 내용을 정리해 볼 수 있다.
[4] 특정 부분만 보기
Router# show ip accounting | include 192.168.1.191
include라는 명령어를 이용해 앞의 결과에서 필요한 부분만 골라 볼 수 있다(표 2).
[5] 내용 초기화
Router# clear ip accounting
<ip route-cache flow를 이용하는 방법>
cache-flow는 ip account와 반대로 인바운드로 오는 패킷을 볼 수 있으며, ip account 보다 세밀한
분석 기능을 제공한다.
[1] config 방법
Router# configure terminal
Router(config)# ip cef
Router(config)#
interface FastEthernet 1/0
Router(config-if)# ip route-cache flow
Router(config-if)#
^Z
[2] 확인
Router# show running-config
...
ip cef
...
interface
FastEthernet 1/0
ip address 192.168.1.1 255.255.255.0
ip
route-cache flow
...
[3] 초기화 하기
Router# clear ip flow stats
[4] 분석하기
Router# show ip cache flow
IP packet size distribution
(16029M total packets):
(표 3)에서 윗 부분은 패킷 크기를 나타내고 밑 부분은 %를 나타낸다. 즉, (표 3)에서 1025~1536바이트 크기의
패킷이 전체 패킷의 56.3을 나타내고 있다. (표 4)는 각 프로토콜별 패킷 분포도를 나타낸 것이다.
(표 5)에서 가장 많은 패킷은 192.168.1.121에서 10.19.169.431로 가는 것이고, 포트 번호는
0x09FA → 0x04BE인 패킷이 1177개가 지나갔다는 것을 의미한다. (표 5)의 내용을 텍스트로 캡처한 후 엑셀에서
소트하면 어떤 포트가 많이 사용되는 것이고, 어떤 IP가 많이 사용되고 있는지 알 수 있다.
[5] 분석 사례
지금까지의 내용을 이용해 실제 현장에서의 분석 사례를 살펴보도록 하자. 네트워크가 마비되는 경우는
여러 가지 원인이 있지만 최근 사례를 살펴보면 웜/바이러스에 의한 라우터 CPU 과부하로 인한 경우가 많다는 것을 알 수 있다.
이것의 근본적인 원인은 마이크로소프트 윈도우의 보안패치를 하지 않은 컴퓨터들이다. 가장 대표적인 경우가 1.25 인터넷 대란이라고
불리우는 SQL_Overflow(슬래머)로 인한 것이다.
일단, 윈도우 보안패치가 안된 컴퓨터가 감염이 되면 외부로
엄청나게 많은 양의 패킷을 전송하게 된다. 더군나 여기서 목적지를 바꿔서 전송을 하기 때문에 그 효과는 더욱더 증가하게 된다.
만약, 목적지 어드레스를 바꾸지 않고 전송한다면 캐시 정보를 이용하기 때문에 그나마 피해의 정도가 줄어든다.
Router# show interfaces stat
GigabitEthernet0/1
Switching path Pkts In Chars
In Pkts Out Chars Out
Processor 3398293
243976123 1875321 138934994
Route cache 1673154281
1814744709 3107259586 1930898125
Total 1676552574
2058720832 3109134907 2069833119
위에서 보다시피 일반적인 경우에는 캐쉬를 이용하는 경우가 훨씬 더 많다. 하지만, 목적지를 바꿔가면서 시도하는 공격이
발생하는 경우 Route cache 부분이 줄어들고 Processor를 이용하는 부분이 증가한다. 물론, 가장 대표적인 사례가
슬래머 웜이다.
[사례] MS-SQL 취약점 공격
지금부터 나오는 내용은 예전에 1.25 인터넷 대란을 일으킨 일명 SQL_Overflow(슬래머)공격이 일어났을 당시 모
사이트에서 실제로 일어난 상황이다. 어느날 NMS에서 갑자기 라우터가 응답이 없다는 경고가 들어왔고, MRTG 그래프를 살펴보니
어느 순간 갑자기 평상시 10~20% 정도였던 라우터 CPU 사용률이 갑자기 90% 이상까지 올라간 것이다. 라우터에 들어가서
show ip cache flow 명령어를 이용해 살펴보니 udp/1434 패킷이 엄청나게 많음을 알 수 있었다.
Router# show ip cache flow
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP
DstP Pkts
Gi1/0 172.16.190.106 Gi2/0 218.232.16.171 11
0E69 059A 1
Gi1/0 10.100.128.34 Gi2/0
142.145.198.152 11 08F3 059A 1
Gi1/0 172.16.190.106
Gi2/0 174.49.243.115 11 0E69 059A 1
Gi1/0
10.100.128.34 Gi2/0 74.134.74.140 11 08F3 059A 1
Gi1/0
172.16.190.106 Gi2/0 52.105.110.74 11 0E69 059A 1
Gi1/0
10.100.128.34 Gi2/0 119.231.159.57 11 08F3 059A 1
Gi1/0
10.100.128.34 Gi2/0 51.163.99.139 11 08F3 059A 1
Gi1/0
10.100.128.34 Gi2/0 136.150.144.122 11 08F3 059A 1
Gi1/0
10.100.128.34 Gi2/0 193.222.217.63 11 08F3 059A 1
Gi1/0
10.100.128.34 Gi2/0 134.193.142.57 11 08F3 059A 1
Gi1/0
172.16.190.106 Gi2/0 76.45.149.179 11 0E69 059A 1
Gi1/0
172.16.190.106 Gi2/0 72.80.161.151 11 0E69 059A 1
Gi1/0
172.16.190.106 Gi2/0 58.72.111.143 11 0E69 059A 1
Gi1/0
172.16.190.106 Gi2/0 202.212.32.37 11 0E69 059A 1
Gi1/0
10.100.128.34 Gi2/0 149.126.197.85 11 08F3 059A 1
Gi1/0
172.16.190.106 Gi2/0 100.143.189.248 11 0E69 059A 1
Gi1/0
10.100.128.34 Gi2/0 20.236.68.153 11 08F3 059A 1
Gi1/0
172.16.190.106 Gi2/0 156.214.198.83 11 0E69 059A 1
Gi1/0
10.100.128.34 Gi2/0 177.129.233.46 11 08F3 059A 1
Gi1/0
172.16.190.106 Gi2/0 136.136.226.3 11 0E69 059A 1
Gi1/0
10.100.128.34 Gi2/0 44.37.44.106 11 08F3 059A 1
Gi1/0
172.16.190.106 Gi2/0 194.122.231.157 11 0E69 059A 1
Gi1/0
210.107.128.34 Gi2/0 111.187.167.250 11 08F3 059A 1
일단, 급하게 라우터에서 액세스 리스트로 udp/1434를 차단해, 피해를 최소화할 수 있었다. 차단 후 다시 캐시 플로우
내용을 보면 다음과 같이 목적지 인터페이스가 Null로 표시된다. 목적지 인터페이스가 Null이라는 것은 그 패킷을 드롭시킨다는
것을 뜻한다.
router# show ip cache flow
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP
DstP Pkts
Gi1/0 172.16.190.106 Null
218.232.16.171 11 0E69 059A 1
Gi1/0 10.100.128.34
Null 142.145.198.152 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 174.49.243.115 11 0E69 059A 1
Gi1/0
10.100.128.34 Null 74.134.74.140 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 52.105.110.74 11 0E69 059A 1
Gi1/0
10.100.128.34 Null 119.231.159.57 11 08F3 059A 1
Gi1/0
10.100.128.34 Null 51.163.99.139 11 08F3 059A 1
Gi1/0
10.100.128.34 Null 136.150.144.122 11 08F3 059A 1
Gi1/0
10.100.128.34 Null 193.222.217.63 11 08F3 059A 1
Gi1/0
10.100.128.34 Null 134.193.142.57 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 76.45.149.179 11 0E69 059A 1
Gi1/0
172.16.190.106 Null 72.80.161.151 11 0E69 059A 1
Gi1/0
172.16.190.106 Null 58.72.111.143 11 0E69 059A 1
Gi1/0
172.16.190.106 Null 202.212.32.37 11 0E69 059A 1
Gi1/0
10.100.128.34 Null 149.126.197.85 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 100.143.189.248 11 0E69 059A 1
Gi1/0
10.100.128.34 Null 20.236.68.153 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 156.214.198.83 11 0E69 059A 1
Gi1/0
10.100.128.34 Null 177.129.233.46 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 136.136.226.3 11 0E69 059A 1
Gi1/0
10.100.128.34 Null 44.37.44.106 11 08F3 059A 1
Gi1/0
172.16.190.106 Null 194.122.231.157 11 0E69 059A 1
Gi1/0
210.107.128.34 Null 111.187.167.250 11 08F3 059A 1
출처 : On the net 6월호
| 
