2013년 3월 30일 토요일

fireworking




FIREWALKING란?

필터링 장비의 룰(정책)을 조사할 때 사용하는 기법

Firewalk는 traceroute를 이용한 네트워크 스캔 도구이다 - IP 패킷 응답을 분석해서 게이트웨이 ACL(Access Control List) 필터를 점검하고, 그 정보로 네트워크 맴을 그려내는 기술이다. Firewalk Firewalking은 방화벽으로 둘러싸인 네트워크에 대한 정보를 수집하며 traceroute와 같은 IP 패킷 분석을 이용하여, 특정 패킷이 패킷 필터링 장치를 통과하여 공격자의 호스트에서 타겟 호스트로 전송될 수 있는가를 검사한다. 이러한 기술을 이용하여 게이트웨이의 열린 포트를 알아낼 수도 있으며, 또한 패킷 필터링 장치로 보호되는 내부의 라우터를 알아낼 수도 있다. 시스템 관리자는 자신의 네트워크 보안을 강화하는데 사용할 것이다.

네이버 설명 : 침입 차단 시스템이 보호하는 네트워크에 대한 정보를 수집하기 위한 도구의 일종. 트레이스라우트(traceroute)와 같은 유틸리티를 이용한 IP 응답 패킷을 분석하여 특정 패킷이 필터링 장치를 통과하여 공격자의 호스트에서 목표 호스트로 전송될 수 있는가를 검사한다. 이러한 기술을 이용하여 게이트웨이의 열린 포트나 패킷 필터링 장치로 보호되는 내부의 라우터를 알아내기도 하며, 자체 네트워크 보안을 강화하는 도구로도 사용한다.




하는방법 :


Access control lists represent an important first line of defense on most networks, since they are commonly used on routers to limit the protocols allowed to pass to host systems behind the router.Firewalk is an open source tool that will help you verify that your router ACLs are actually doing what you intended them to do. It can also be used as part of your security tool set for penetration testing and providing documented verification of ACLs, as well as rule sets on firewalls.

How it works
Firewalk attempts to determine which protocols a router or firewall will block and which they will pass on to downstream hosts. It operates on an IP expiry technique, much like the commonly used Traceroute program. The IP expiry technique involves manipulating the time to live (TTL) field of the IP header to map out all intermediate routers or hops between a scanning host and the target host. In Firewalk, scans are then sent with a TTL value one hop higher than that of the target host. If the scan packets are blocked by an ACL or firewall, they are dropped or rejected. If allowed to pass through, they will expire and elicit an ICMP time exceeded message. Based upon the results of the scans, Firewalk can identify which ports are open.

Installation
Firewalk is easily installed on any Linux/UNIX system (including Mac OS X). Firewalk relies on three back-end tools: libnet 1.1.x, lipcap, and libdnet. Start by downloading these tools, then unzip them with the "gunzip" command. Follow that with " ./configure", then "make" and finally "make install." After doing these command sequences for each of the backend tools, download Firewalk and do the same process for it.

Running Firewalk
Now that we're ready to run Firewalk, let's explore how it works. There are two phases of Firewalk. The first phase is basically a traceroute function called "hopcount ramping," and the second phase is the scanning or "firewalking" function. To see all the usage parameters, enter the "firewalk" command without supplying any of the host information. Here is what you will see.

Here's a brief explanation of the different options:



OptionDefaultExplanation
-d33434Allows you to specify a different destination port for the ramping phase
-ioffAllows you to specify a different interface
-noffPrevents DNS lookup—may increase speed
-pUDPAllows you to specify the scan protocol—can be TCP or UDP
-roffEnables strict RFC standards adherence
-S1-130, 139, 1025Allows you to specify a different port list for the scanning phase
-s53Allows you to specify a different source port for both phases
-T2Allows you to specify a different timeout for packet return
-toffAllows you to preload a TTL value to eliminate the ramping phase
-vN/AShows the version of Firewalk
-xoffAllows you to specify how many hops the binding host is from the target

To start firewalking, you must specify two hosts: the "target gateway," which is the router or firewall to be scanned, and the "metric." Normally we think of a metric as a number, but in this case, a metric is another gateway or host behind the target gateway.

Phase one—Hopcount ramping
Since the number of hops between the source host and the target host is not known, a standard Traceroute-style IP expiry scan is initiated. The TTL count is incremented at each hop until the target gateway is reached. At this point, the scan is "bound" to the current TTL plus one. Adding one more TTL allows the proceeding scans to go beyond the target gateway toward the metric host. The whole purpose of phase one is to find the TTL count for the target gateway.

Phase two—Firewalking
After reaching the target gateway and binding the scan to the proper TTL count, the actual scanning portion is started. Then either TCP or UDP packets are sent from the scanning host to the metric host one port at a time until the scan is completed. If a given probe is passed through the target gateway ACL, the scanning host receives an "ICMP TTL expired in transit" message from the binding host. If the scanning host receives no response after the timeout expires, it is assumed that the packet was denied by the ACL and was dropped.

Example scans
Figure A shows a diagram of the test network that we'll be using for two example scans.

Figure A


For our example, the target gateway is Router3 with the IP address of 192.168.100.2, and the metric is the host at IP address 192.168.200.10.

For demonstrative purposes, the first scan we'll do is without any ACL on the router. Then we'll apply an access list to the router, rerun our scan, and compare the firewalking results with our ACL. Note: Scan print outs have been shortened for brevity.

Scan 1—No ACL
We're going to run the following command:
[root@localhost local]# firewalk -s25� -d25 -pTCP 192.168.100.2 192.168.200.10

This will result in the following output:
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 25, destination port: 25
Hotfoot through 192.168.100.2 using 192.168.200.10 as a metric.
Ramping Phase:
�1 (TTL� 1): expired [192.168.1.1]
�2 (TTL� 2): expired [192.168.1.10]
�3 (TTL� 3): expired [192.168.100.2]
Binding host reached.
Scan bound at 4 hops.
Scanning Phase:
port�� 1: A! open (port not listen) [192.168.200.10]
port�� 2: A! open (port not listen) [192.168.200.10]
port�� 3: A! open (port not listen) [192.168.200.10]
port� 21: A! open (port listen) [192.168.200.10]
port� 22: A! open (port not listen) [192.168.200.10]
port� 23: A! open (port not listen) [192.168.200.10]
port� 24: A! open (port not listen) [192.168.200.10]
port� 25: A! open (port listen) [192.168.200.10]
port� 26: A! open (port not listen) [192.168.200.10]
port 139: A! open (port not listen) [192.168.200.10]
port 1025: A! open (port not listen) [192.168.200.10]

Scan completed successfully.

Total packets sent:��������������� 135
Total packet errors:�������������� 0
Total packets caught�������������� 148
Total packets caught of interest�� 135
Total ports scanned��������������� 132
Total ports open:����������������� 132
Total ports unknown:�������������� 0

Firewalk displays "A!" when it determines that the metric host is directly behind the target gateway. From this scan we see that all ports are open, but the server is only listening to ports 21 and 25.

Scan 2—ACL applied
On the target router, I've added an ACL that blocks outbound traffic except for TCP ports 25 (SMTP) and 23 (Telnet) on the interface for network 192.168.200.0. Here's the router configuration:
interface Ethernet0
�ip address 192.168.200.1 255.255.255.0
�ip access-group 101 out
�no ip directed-broadcast
access-list 101 permit icmp any any
access-list 101 permit tcp any any eq smtp
access-list 101 permit tcp any any eq telnet
access-list 101 deny any any

Here's what Firewalk reports when we run a scan:
[root@localhost root]# firewalk -pTCP 192.168.100.2 192.168.200.10
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 53, destination port: 33434
Hotfoot through 192.168.100.2 using 192.168.200.10 as a metric.
Ramping Phase:
�1 (TTL� 1): expired [192.168.1.1]
�2 (TTL� 2): expired [192.168.1.10]
�3 (TTL� 3): expired [192.168.100.2]
Binding host reached.
Scan bound at 4 hops.
Scanning Phase:
port� 21: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port� 22: *no response*
port� 23: A! open (port listen) [192.168.200.10]
port� 24: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port� 25: A! open (port listen) [192.168.200.10]
port� 26: *no response*
port� 27: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port 139: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port 1025: *no response*

Scan completed successfully.

Total packets sent:��������������� 135
Total packet errors:��������������0
Total packets caught�������������� 73
Total packets caught of interest�� 72
Total ports scanned��������������� 132
Total ports open:����������������� 2
Total ports unknown:�������������� 67


The two ports definitely open are 23 (Telnet) and 25 (SMTP). The ports reporting "no response" are basically invisible. This means that no response was received before timing out. We can assume that the packets were dropped, but as you can tell from this example, you need to run a variety of scans to really map an access list or firewall rule set.

Summary
This article provides an introductory look at the capabilities of Firewalk. This open source tool clearly warrants further study and usage, and undoubtedly has a viable place in the network security tool chest for auditing and documentation purposes. One thing to keep in mind is that this is a "noisy" application, meaning it's activity will be picked up by router and firewall logs as well as by any listening IDS, so be sure you have approval before scanning any routers or firewalls.

댓글 없음:

댓글 쓰기