Firewalking 분석 보고서
작성자 정보
- 웹관리자 작성
- 작성일
컨텐츠 정보
- 4,659 조회
- 0 추천
- 목록
본문
Firewalking 분석 보고서
1998. 12. 28
이현우/CERTCC-KR, 한국정보보호센터
1. 개요
Firewalking은 침입차단시스템이 보호하는 네트워크에 대한 정보를 수집할 수 있는 기술이다. traceroute와 같은 IP 패킷 분석을 이용하며, 특정 패킷이 패킷 필터링 장치를 통과하여 공격자의 호스트에서 타겟 호스트로 전송될 수 있는가를 검사한다. 이러한 기술을 이용하여 게이트웨이의 열린 포트를 알아낼 수도 있으며, 또한 패킷 필터링 장치로 보호되는 내부의 라우터를 알아낼 수도 있다.
본 분석 보고서에서는 Firewalking 기술의 기본 바탕인 traceroute에 대한 설명과 Firewalking을 구현한 프로그램인 firewalk에 대하여 설명한다.
2. Firewalking
2.1 Traceroute
Traceroute는 특정 목적지에 이르는 경로상의 모든 호스트를 보여주는 디버깅을 위한 유틸러티로서, IP 헤더의 TTL(Time To Live) 필드를 하나씩 증가시키면서 UDP 또는 ICMP echo(ping) 패킷을 목적지로 보낸다. UDP를 이용할 경우 패킷을 보낼때마다 목적지 포트번호를 증가시켜 보내게 된다.
IP TTL 필드는 데이터그램의 수명을 제한하는데 라우터가 패킷을 포워드하기 전에 1만큼 감소시키고, 0 또는 그 이하일 경우에는 ICMP 에러 메시지인 TTL exceeded in transit)를 패킷을 보낸 호스트로 되돌려 보낸다. 이러한 에러 메시지를 받은 호스트는 어떠한 라우터에서 패킷이 종료되었는지를 알 수 있고, TTL을 1부터 증가시키면서 패킷을 보냄으로서 목적지 호스트에 이르는 경로에 있는 모든 라우터를 알 수 있게 된다(필터링이나 패킷 유실이 없는 경우). 또한 확실한 응답(ICMP port unreachable 또는 ICMP echo reply)을 얻기 위하여 traceroute는 높은 UDP 포트를 사용한다.
2.2 traceroute를 이용한 정보수집
예 1) ping을 제외한 내부로 들어오는 모든 트래픽을 차단하는 침입차단시스템으로 보호되는 네트워크인 경우, UDP 패킷 대신에 ICMP 패킷을 이용하는 traceroute를 사용하여 내부 호스트 정보를 알 수 있다.
<그림 1> UDP 패킷을 보내는 traceroute을 이용한 경우
zuul:~>traceroute 10.0.0.10
traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms
2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms
3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms
4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms
5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms
6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms
7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms
8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms
9 * * *
10 * * *
UDP 패킷이 침입차단시스템의 접근통제리스트(ACL)에 의해 차단됨
<그림 2> ICMP 패킷을 보내는 traceroute를 이용한 경우
zuul:~>traceroute -I 10.0.0.10
traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms
2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms
3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms
4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms
5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms
6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms
7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms
8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms
9 10.0.0.9 (10.0.0.9) 94.127 ms 81.764 ms 96.476 ms
10 10.0.0.10 (10.0.0.10) 96.012 ms 98.224 ms 99.312 ms
ICMP 패킷은 ACL로 차단되지 않으므로 통과됨
예 2) 침입차단시스템이 DNS 통신을 위하여 UDP port 53을 열어놓은 경우(일반적인 설정), traceroute의 시작 소스 포트(일반적으로 매번 패킷을 보낼때마다 포트번호가 1씩 증가)와 각 라운드당 보내지는 패킷 수(디폴트 3), 그리고 침입차단시스템과 공격 호스트간의 홉 수를 이용하여 침입차단시스템으로 보호되는 내부 네트워크의 호스트 정보를 알아낼 수 있다.
<그림 3> 침입차단시스템(8 hop)의 ACL에 의해 차단됨
zuul:~>traceroute 10.0.0.10
traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms
2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms
3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms
4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms
5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms
6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms
7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms
8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms
9 * * *
10 * * *
네트워크 검색을 위한 traceroute 패킷을 DNS 패킷으로 속이기 위해서는 단순히 다음과 같은 공식으로 얻어진 포트 번호로 스캐닝을 시작하면 된다.
(target_port - (number_of_hops * num_of_probes)) - 1
(53 - (8 * 3)) - 1 = 28
<그림 4> 소스포트가 53인 패킷은 ACL 통과
|
zuul:~>traceroute -p 28 10.0.0.10 traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets 1 10.0.0.1 (10.0.0.1) 0.501 ms 0.399 ms 0.395 ms 2 10.0.0.2 (10.0.0.2) 2.433 ms 2.940 ms 2.481 ms 3 10.0.0.3 (10.0.0.3) 4.790 ms 4.830 ms 4.885 ms 4 10.0.0.4 (10.0.0.4) 5.196 ms 5.127 ms 4.733 ms 5 10.0.0.5 (10.0.0.5) 5.650 ms 5.551 ms 6.165 ms 6 10.0.0.6 (10.0.0.6) 7.820 ms 20.554 ms 19.525 ms 7 10.0.0.7 (10.0.0.7) 88.552 ms 90.006 ms 93.447 ms 8 10.0.0.8 (10.0.0.8) 92.009 ms 94.855 ms 88.122 ms 9 10.0.0.9 (10.0.0.9) 101.163 ms * * 10 * * * |
| | 소스 포트 | 29 30 31 | 32 33 34 | 35 36 37 | 38 39 40 | 41 42 43 | 44 45 46 | 47 48 49 | 50 51 52 | 53 54 55 | |
위에서와 같이 traceroute 패킷의 소스 포트가 53일 경우 침입차단시스템을 통과하여 내부 네트워크의 호스트로부터 응답을 얻었으나, 포트번호가 계속 증가하므로 그 다음부터는 응답을 얻을 수 없다. 따라서 traceroute 프로그램을 약간 수정하여 소스 포트 번호를 증가시키지 않게 하여 모든 패킷이 침입차단시스템을 통과할 수 있도록 할 수 있다.
<그림 5> 소스포트를 증가시키지 않는 수정된 traceroute 프로그램을 이용
zuul:~>traceroute -S -p 53 10.0.0.15
traceroute to 10.0.0.15 (10.0.0.15), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.516 ms 0.396 ms 0.390 ms
2 10.0.0.2 (10.0.0.2) 2.516 ms 2.476 ms 2.431 ms
3 10.0.0.3 (10.0.0.3) 5.060 ms 4.848 ms 4.721 ms
4 10.0.0.4 (10.0.0.4) 5.019 ms 4.694 ms 4.973 ms
5 10.0.0.5 (10.0.0.5) 6.097 ms 5.856 ms 6.002 ms
6 10.0.0.6 (10.0.0.6) 19.257 ms 9.002 ms 21.797 ms
7 10.0.0.7 (10.0.0.7) 84.753 ms * *
8 10.0.0.8 (10.0.0.8) 96.864 ms 98.006 ms 95.491 ms
9 10.0.0.9 (10.0.0.9) 94.300 ms * 96.549 ms
10 10.0.0.10 (10.0.0.10) 101.257 ms 107.164 ms 103.318 ms
11 10.0.0.11 (10.0.0.11) 102.847 ms 110.158 ms *
12 10.0.0.12 (10.0.0.12) 192.196 ms 185.265 ms *
13 10.0.0.13 (10.0.0.13) 168.151 ms 183.238 ms 183.458 ms
14 10.0.0.14 (10.0.0.14) 218.972 ms 209.388 ms 195.686 ms
15 10.0.0.15 (10.0.0.15) 236.102 ms 237.208 ms 230.185 ms
2.3 Firewalk
traceroute는 IP 계층을 이용한 것이기 때문에 다른 모든 transport 계층의 프로토콜(UDP, TCP, ICMP)을 응용할 수 있다. 따라서 여러 가지 프로토콜을 이용하여 traceroute 스캐닝을 시도함으로서 어떠한 종류의 트래픽이 침입차단시스템을 통과할 수 있으며, 내부 네트워크의 구성을 알아낼 수 있다.
라우터의 응답을 이용하여 정보를 수집하기 위해서는 다음의 두가지 정보를 알고 있어야 한다.
1) 목적지 네트워크에 이르는 마지막 게이트웨이의 IP 주소
2) 침입차단시스템 뒤에 위치하는 호스트의 IP 주소
1)을 이용하여 어떠한 프로토콜이 차단되는지에 대한 정보를 수집할 수 있으며, 2)를 이용하여 내부 네트워크로 패킷을 전송할 수 있다.
Firewalking을 이용하여 다음과 같은 정보수집 공격을 수행할 수 있다.
침입차단시스템 프로토콜 스캔 : 모든 포트와 프로토콜로 패킷을 보내어 응답을 모니터링 하여 침입차단시스템이 어떠한 포트 또는 프로토콜을 허용하는 가를 탐색
네트워크 맵핑 : 침입차단시스템 뒤에 위치하는 모든 호스트로 패킷을 보내어 내부 네트워크의 정확한 토폴러지 정보 수집
Firewalk는 위에서 설명한 기술을 이용한 네트워크 감사 도구로 게이트웨이가 어떠한 transport 프로토콜을 통과시키는 가를 알아낸다. Firewalk는 타겟 게이트웨이에 이르는 홉(hop)의 수보다 1만큼 더 큰 IP TTL을 설정하여 TCP 또는 UDP 패킷을 전송하여 스캐닝을 시도하는데, 만약 게이트웨이가 패킷을 통과시키면 다음 홉으로 전송되고 해당 호스트는 TTL exceeded 메시지를 보내게 된다. 하지만 게이트웨이가 패킷을 차단할 경우는 패킷은 버려지게 된다. 연속적으로 이러한 탐색 패킷을 보내어 응답을 분석함으로서 게이트웨이의 접근통제 리스트 정보를 알아낼 수 있다.
Firewalk는 두 단계로 실행되는데 첫 번째 단계는 정확한 IP TTL을 알아내는 것으로 traceroute 방법을 사용한다. 일단 홉(hop)의 수를 알아낸 후 TCP 또는 UDP 패킷을 보내어 탐색을 시작하는데, 만약 응답이 있으면 포트가 열려 있고 응답이 없으면 포트가 닫혀있음을 알 수 있다.
<그림 6> firewalk 수행 결과
zuul:#firewalk -n -P1-8 -pTCP 10.0.0.5 10.0.0.20
Firewalking through 10.0.0.5 (towards 10.0.0.20) with a maximum of 25 hops.
Ramping up hopcounts to binding host...
probe: 1 TTL: 1 port 33434: <response from> [10.0.0.1]
probe: 2 TTL: 2 port 33434: <response from> [10.0.0.2]
probe: 3 TTL: 3 port 33434: <response from> [10.0.0.3]
probe: 4 TTL: 4 port 33434: <response from> [10.0.0.4]
probe: 5 TTL: 5 port 33434: Bound scan: 5 hops <Gateway at 5 hops> [10.0.0.5]
port 1: open
port 2: open
port 3: open
port 4: open
port 5: open
port 6: open
port 7: *
port 8: open
13 packets sent, 12 replies received
위에서 목적지 호스트는 꼭 존재할 필요가 없다. 내부 네트워크의 정확한 토폴러지를 알아내기 위하여 추가적인 스크립트 작성하여 목적지 호스트를 차례로 스캐닝하는 것도 가능하다.
3. 대책
1) 라우터에서 ICMP TTL Exceeded 메시지가 내부에서 외부로 나가지 못하도록 한다. 물론 이로 인하여 정상적인 traceroute의 사용을 하지 못할 수 있으며, 내부 네트워크 문제에 대한 원격 진단을 하지 못할 수 있다.
2) 프락시 또는 NAT(Network Address Translation) 사용으로 Firewalk 스캐닝을 막을 수 있다.
3) 네트워크 기반의 침입탐지시스템 사용
<참고 자료>
[1] http://www.es2.net/research/firewalk
관련자료
-
이전
-
다음
