FIREWALL IDENTIFICATION

Introduction:

Two most familiar firewalls arise popularity in the market at the moment; Application Proxies, and Packet Filtering Gateways. 

Pro's and Con's

Application Proxies : more secure, strict

Packet Filtering Gateways :  corporate networks, high performance.

Vulnerabilities in these firewalls arise quite often. Each type of firewall is found with a new exploit and technique to circumvent. The biggest exploit vulnerability is a misconfiguration of the firewall.

A well-configured, architecturally designed, updated, and maintained firewall, is hardly penetrable. Most hackers not bother with them, attempting to find a way to work around them. By either exploiting trust with the secured systems behind the firewall, or even by attacking through another service not filtered by the firewall, i.e. dial up.

Detecting Present Firewalls :

Scanning : Default open ports

CheckPoint's Firewall- default listens on TCP ports 256, 257, 258.
Microsoft's Proxy Server - default listens on TCP ports 1745 and 1080

nmap -n -vv -P0 -p256, 257, 258, 1080, 1745 target

Banner grabbing : 

nc -v -n 10.10.1.8 23
(UNKNOWN) [10.10.1.8] 23 (?) open
Eagle Secure Gateway.
Hostname:

TCP 25 (Send Mail Transfer Protocol, SMTP):

nc -v -n 10.10.1.8 25
(UNKNOWN) [10.10.1.8] 25 (?) open
421 10.10.1.8 Sorry, the firewall does not provide mail service to you.

nc -v -n 10.10.1.72 259
(UNKNOWN) [192.168.21.1] 259 (?) open
30000003

 nc -v -n 10.10.1.95 259
(UNKNOWN) [192.168.29.212] 259 (?) open
31300003

Using Debugging tools

Traceroute:

Ex: packet filtering device that blocks all except for ping and ping responses (ICMP types 8 and 0 respectively). 

traceroute 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms
2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms
3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms
4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms
5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 * * *
9 * * *
10 * * *

Hop 7, at 10.10.1.8, is assumed to be the firewall. Of course, we may not be right, a firewall can be a router, or any other packet filtering or redirection application.

Instead of using the default UDP datagram TTL packets, which seemed to not work. We decided to force traceroute with the -I arguement to use ICMP packets.

traceroute -I 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 Hops Max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms
2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms
3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms
4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms
5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 10.10.1.9 [10.10.1.9] 62.926 ms 66.125 ms 67.032 ms
9 10.10.1.10 [10.10.1.10] 70.482 ms 71.273 ms 71.762 ms
10 10.10.1.11 [10.10.1.11] 73.192 ms 76.921 ms 82.325 ms

Looking at the traceroute results carefully you can see that we were able to detect hosts, and systems behind the firewall.

Ex 2 : firewall blocking all except DNS. This leaves UDP port 53 open.

traceroute 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms
2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms
3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms
4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms
5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 * * *
9 * * *
10 * * *

Customizing traceroute: port used, number of probes sent default is 3.

Beginning our scan with a starting port number of :

(target_port - (number_of_hops * num_of_probes)) - 1

( 53 - ( 8 * 3 )) - 1 = 28

The new reconstructed packet will have an acceptable and accessible port number, therefore allowing it to bypass ACL restrictions. As shown in the following example.

traceroute -p28 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.522 ms 0.624 ms 0.625 ms
2 10.10.1.3 [10.10.1.3] 5.327 ms 6.360 ms 6.380 ms
3 10.10.1.4 [10.10.1.4] 7.217 ms 7.612 ms 7.656 ms
4 10.10.1.5 [10.10.1.5] 8.927 ms 9.090 ms 9.238 ms
5 10.10.1.6 [10.10.1.6] 9.529 ms 10.812 ms 12.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 10.10.1.9 [10.10.1.9] 65.158 ms * *
9 * * *
10 * * *

traceroute increases the port number for each probe sent, or scan terminates after passing our target firewall. Since the first probe had an assigned port of UDP 53 (DNS), the next probe sent had UDP 54. Based on the ACL's gathered for this packet filtering application, the UDP 54 is blocked. To possibly get more information and probe the network yet some more, we must keep the packet at a condition where it will bypass the ACL. And since we would like to keep the port at UDP 53, we need to issue another arguement to disable incrementation of packet portnumber for each probe. 

traceroute -S -p28 10.10.1.12
traceroute to 10.10.1.12 [10.10.1.12], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.522 ms 0.624 ms 0.625 ms
2 10.10.1.3 [10.10.1.3] 5.327 ms 6.360 ms 6.380 ms
3 10.10.1.4 [10.10.1.4] 7.217 ms 7.612 ms 7.656 ms
4 10.10.1.5 [10.10.1.5] 8.927 ms 9.090 ms 9.238 ms
5 10.10.1.6 [10.10.1.6] 9.529 ms 10.812 ms 12.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 10.10.1.9 [10.10.1.9] 62.926 ms 66.125 ms 67.032 ms
9 10.10.1.10 [10.10.1.10] 92.332 ms 93.214 ms 96.016 ms
10 10.10.1.11 [10.10.1.11] 101.523 ms 103.273 ms 103.923 ms
11 10.10.1.12 [10.10.1.12] 104.516 ms 105.523 ms 105.682 ms
12 10.10.1.13 [10.10.1.13] 109.231 ms 111.122 ms 117.923 ms

Firewalking:

Firewalk works by constructing packets with an IP TTL calculated to expire exactly one hop past the firewall, like Traceroute. Expected Result: The packet is allowed by the firewall, it will be allowed to pass and will expire as instructed. Therefore giving off an "ICMP TTL expired in transit" message. Of course, if the packet is blocked by the firewall's rules, it will be dropped down, and we will recieve either a null response (no response), or an ICMP type 13 Admin Prohibited filter packet. By sending probes in a successive manner and recording which ones answer and which ones don't, the access list on the gateway can be determined.We must have two pieces of information before we begin:

1) IP Address of the Last Gateway detected before the firewall kicks in.
2) IP Address of a host located in the firewalled area, behind the firewall.

IP Address 1, the gateway, will provide us as a way point. If we can not get a response beyond this machine, it is assumed that our packet is being blocked by whatever protocol we tried to pass. As you might have figured out already, IP Address 2, the host, will be used as a destination for the packets. An example of firewalk in action:

firewalk -n -P1-8 -pTCP 10.10.1.7 10.10.1.12
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: [10.10.1.1]
probe: 2 TTL: 2 port 33434: [10.10.1.2]
probe: 3 TTL: 3 port 33434: [10.10.1.3]
probe: 4 TTL: 4 port 33434: [10.10.1.4]
probe: 5 TTL: 5 port 33434: [10.10.1.5]
probe: 6 TTL: 6 port 33434: [10.10.1.6]
probe: 7 TTL: 7 port 33434: Bound scan: 7 hops [10.10.1.7]
port 135: open
port 136: open
port 137: open
port 138: open
port 139: *
port 140: open

As we can see, the firewall's ACL rules are bypassed by the use of firewalk. More information including the source code can be found at www.packetfactory.net/projects/.

Now back to our cool radical utility nmap. Reason: nmap scans a host like a normal scanner and gives you an "open" or "closed", plus it tells you what ports may be blocked. There are 3 reasons or conditions that may cause the return of a fitlered port:
1) No SYN/ACK packet was recieved.
2) No RST/ACK packet was recieved.
3) System replied with an ICMP type 3 (Destination Unreachable) with code 13 (Communication Administratively Prohibited).

Nmap will use all these conditions and consider it a filtered port. For Example:

nmap -p21,23,53,80 -P0 -vv 10.10.1.10
Starting nmap V. 2.07 by Fyodor (fyodor@dhp.com, www.insecure.com/nmap/)
Initiating TCP connect() scan against (10.10.1.10)
Adding TCP port 21 (state Open).
Adding TCP port 53 (state Firewalled).
Adding TCP port 23 (state Firewalled).
Adding TCP port 80 (state Open).
Interesting ports on (10.10.1.10):
Port State Protocol Service
21 open tcp ftp
23 filtered tcp telnet
53 filtered tcp domain
80 open tcp http

From what we see in the ouput, a couple of ports are `Firewalled`. We can use the tcpdump output to determine the reason its filtered.

Raw Packet Transmission and HPING:

Raw packet transmission is also used to probe networks behind a firewall. Hping works by sending TCP packets a destinational port, then analyzing and reporting the packet recieved. Hping allows us to discover accepted, blocked, dropped, or rejected packets. Thus allowing our probing of the ACL rules to expand even further and more indepth.

hping 10.10.1.7 -c2 -S -p21 -n
HPING 10.10.1.7 (eth0 10.10.1.1) : S set, 40 data bytes
60 bytes from 10.10.1.1: flags=SA seq=0 ttl=242 id=65121 win=64240
time=144.4 ms

Looking at the recent example, we can see that TCP port 21 on 10.10.1.7 is open, given the fact that we recieved a packet with an SA flag set, which is basically a SYN/ACK packet. This says that a port is open, but we do not know if it is the firewall or not. A little more probing must take place.

hping 10.10.1.10 -c2 -S -p80 -n
HPING 10.10.1.10 (eth0 10.10.1.1) : S set, 40 data bytes
ICMP Unreachable type 13 from 10.10.1.8

For this hping, we recieve an ICMP type 13 packet, which is an ICMP administrator prohibited filter packet. From these few commands we have confirmed that 10.10.1.8 is our firewall, and it is most likely blocking port 80 on 10.10.1.10. Another likely response you might get from a firewalled host is as follows.

hping 10.10.1.16 -c2 -S -p23 -n
HPING 10.10.1.16 (10.10.1.1) : S set, 40 data bytes
60 bytes from 10.10.1.1: flags=RA seq=0 ttl=59 id=0 win=0 time=0.5 ms

This shows 1 of 2 items of possibilities. Number 1 being that the packet was accepted by the firewall and the packet fit the ACL rules, yet the host is not listening on that port. Or Number 2 being that the firewall rejected the packet (as in Checkpoint's reject packet option and rules).

By using the ICMP type 13 packet we had obtained earlier, we can assume that the firewall is allowing our packet through, but the host is just not listening. And Of course, when a paranoid administrator configures the firewall to block all packets, you will receive:

hping 10.10.1.16 -c2 -S -p23 -n
HPING 10.10.1.16 (10.10.1.1) : S set, 40 data bytes

Source Port Scanning:

This technique applies to packet filtering applications and devices which do not maintain state. For example, Cisco's IOS. When thought about, if a firewall cannot maintain state, then it cannot manifest if the connection is inward or outbound. In this case, transmissions may pass through unfiltered. Setting the source port to a common port that is allowed through firewalls, for example our earlier example, UDP port 53 (DNS). Using the -g option with nmap:

nmap -sS -P0 -g 53 -p 139 10.10.1.15

If you receive a positive output of open ports, then you most likely have a vulnerable firewall.

Badly Configured ICMP Packets:

I will briefly discuss this, it has been well documented at www.blackhat.com. According the paper, we can use various methods to elicit an ICMP error message back from a probed host and discover its existence. Some of the methods are as follows:

- Mangling IP headers

- Different Header Length Field

- IP Options Field

- Using non-valid field values in the IP header

- Using valid field values in the IP header (opposite of above)

- Abusing Fragmentation

With the first method we are using bad IP headers in the IP datagram that would generate an ICMP Parameter Problem err or back from the probed machine to the source IP address of the probing datagram. The second method use non-valid field values in the IP header in order to force the probed machine to generate ICMP Destination Unreachable error message back to the malicious computer attacker. The third method discussed uses fragmentation to trigger an ICMP Fragment Reassembly Time Exceeded error message from the probed machine. The last method uses the UDP Scan method to elicit ICMP Port Unreachable error message back from a closed UDP port(s) on the probed host(s). You can learn more about it at http://expert.cc.purdue.edu/~frantzen.

If we probe the entire IP range of the targeted network with all combinations of protocols and ports, it would draw us the targeted network topology map, and will allow us to determine the access list (ACL) a Filtering Device (If present, and not blocking outgoing ICMP Parameter Problem Error messages) is forcing.

Conclusion:
There are many ways to detect and probe a network. try these techniques out themselves on their own systems. These techniques can be constantly used to probe and draw out your network's topology, including the firewall's ACL.

A well-configured is very hard to bypass. Tools like traceroute, nmap, hping, and others that can be used, help attackers to discover (or at least, assume) access paths through your router and firewall as well as the type of firewall you are using. Many vulnerabilities found are due to misconfigurations in your firewalls ACL's, or even a lack of monitoring and administration of the logs, traffic, and maintenance.

Tools:
wafw00f
Nmap
Hping
Traceroute
Firewalk
Netcat

whatwaf