VESARiA Network Security Specialists
About Vesaria Services Consulting Partners Research Customers Contact Us

Firewall Testing



Firewall Testing From the Eye of a Hacker

This paper, written by someone known as "Mount Ararat Blossom", is a good example how a hacker goes about testing and attacking firewalls.

Find out more about VESARiA Firewall Testing.



by MountAraratBlossom




Application gateways and Packet filtering gateways are two types of firewalls basically available in market. Application gateways are those proxies and they are causing some computational problems in computers due to heavy CPU usage, therefore on busy networks Packet filtering devices are more preferable. However, the vendors are trying to embed these two inevitable characteristics of firewall into one.

Installing a firewall into a gateway is not a security panacea. Those who attended BlackHat ( conference this July in Las Vegas still remember the presentations about FW-1 penetration. Security vulnerabilities are discovered every year with just about every firewall in the market. However, the worst thing might be the misconfigured, unattended and unmaintained ones. Is this laziness? Who knows, but it helps hackers.

There are many tools out there to test the security of our applications. However penetrating into computer networks are sometimes bottleneck because of firewalls.

As those skilled hackers, we need some methodologies to intrude into systems in our pen-tests. I will basically try to cover the methods used widely at wild. We need to understand the ACLs(access control lists) of a firewall or a router, we need to map what is behind the firewall, we wanna know what is allowed in and so on.

As one of our main aim is not to trigger intrusion detection software, we dont wanna deploy full connection (3-way handshake)port scanning. Because, port scanners triggers this systems easily because of the enormous amount of SYN/ACK packets sent back and forth to every port of the firewall just to check them. Therefore, we dont like noisy staff in our pen-tests.

Moreover, we should know that, most of the firewalls do not respond to ICMP echo requests (ping), as long as it is configured with an expert firewall administrator.





Firewall Identification & Traceroute:

Traceroute is a network debugging utility, which attempts to map all the hosts on a route to a certain destination host/machine. It sends UDP datagrams by default or ICMP ECHO Request packets with TTL (time to live) fields set to 1 just before reaching the final target. Once the target reached, as TTL field gets zero, the target will discard the datagram and generate an ICMP Time Exceeded packet back to its originator. By the way, Windows systems use ICMP ECHO Request by default and you can not use UDP method with Microsofts traceroute implementation, "tracert".

Lets assume that a network is protected by a access control device, a firewall or some sort, and it denies everything in but dns traffic. A regular traceroute will be as follows:


traceroute to (, 30 hops max, 40 byte packets

1 ( 0.540 ms 0.394 ms 0.397 ms

2 ( 2.455 ms 2.479 ms 2.512 ms

3 ( 4.812 ms 4.780 ms 4.747 ms

4 * * *

5 * * *

As you see from the preceding example, we can not go beyond which most probably means that there is a blocking device at hop 4. To understand this we have to dig a little deeper.

When traceroute is deployed with default UDP datagram option, it will increase the port number at every time it send a UDP datagram. Hence, we need a equation which will give the starting port number to reach to final target. So the starting port number is

(Target port (number of hops * number of probes)) -1

where number of hops is from our probing box to the firewall, and number of probes is by default 3.

Knowing this, know lets look at our tracerouting

[willyhacker]#traceroute p43

traceroute to (, 30 hops max, 40 byte packets

1 ( 0.540 ms 0.394 ms 0.397 ms

2 ( 2.455 ms 2.479 ms 2.512 ms

3 ( 4.812 ms 4.780 ms 4.747 ms

4 ( 4.972 ms 4.980 ms 6.361 ms

5 * * *

BOOM !, we penetrated in to firewall, which is and get into the network which is most probably a DMZ. However we could not get a reply from The reason is basic, we did not hit to UDP port 53 of this box. As traceroute has incremented our port number again and it has got stuck to ACL on the firewall.

Dont worry, Mike Shiffman (the author of famous firewalk), has a remedy for that. With his modified version of traceroute, traceroute 1.4a5 you can grab it from (

[willyhacker]#traceroute S p53

traceroute to (, 30 hops max, 40 byte packets

1 ( 0.540 ms 0.394 ms 0.397 ms

2 ( 2.455 ms 2.479 ms 2.512 ms

3 ( 4.812 ms 4.780 ms 4.747 ms

4 ( 4.972 ms 4.980 ms 6.361 ms

5 ( 6.1022 ms 5.660 ms 8.531 ms

boom, there we go.. So, what we know is that, we know the IP address and an ACL of firewall (allow TCP/UDP port53 in), a box behind the firewall. This juicy information can help us for further penetration in our tests.

As a result, to test other open ports we can try other ports, with a home grown script, it can be done systematically.



Firewalk is just another utility written by Mike Schiffman, and can also be found at The aim of this little handy tool is to find open ports on a filtering device, Firewall. It works by checking a live system behind a firewall, without touching this system to discover which services are permitted, which ports are open on that firewall.

A second potential advantage of firewalk is mapping the unknown network behind the filtering device. By sending packets to every host behind the firewall, an attacker can generate accurate topology of the network behind the firewall.

The firewalk scan works by sending out TCP or UDP packets with an IP TTL evaluated to expire just one hop past the firewall. If the filtering device allows the traffic in, then it will send the packets to target where the TTL will get zero and the target will elicit a TTL exceeded on transit back to attacker. If the filtering device does not allow the traffic in, then we will not see any packet back which means the port is closed.


[willyhacker]#firewalk -n P135-140 pTCP

Firewalking through (towards with a maximum of 25 hops.

Ramping up hopcounts to binding host...

probe: 1 TTL: 1 port 33434: <response from> []

probe: 2 TTL: 2 port 33434: <response from> []

probe: 3 TTL: 3 port 33434: <response from> []

probe: 4 TTL: 4 port 33434: <response from> []

probe: 5 TTL: 5 port 33434: Bound scan: 5 hops <Gateway at 5 hops> []

port 135: open

port 136: *

port 137: open

port 138: *

port 139: open

port 140: *

However, what we see on our tests is that, some firewalls recognize that the packet will expire when they get to the target host before applying ACL rules. And they elicit an ICMP TTL Expired packet back to attacker and this leads to false-positives.

To learn more about firewalk, you can check the following URL




This tools is basically a TCP ping utility, however it has some additional functionality. You may grab it from It allows user to play with some options of the TCP packet which may let it pass through some filtering devices even if they are blocked, and reports the packets it gets back. . By using the p switch, we can set a fixed destination port, as in the case of traceroute and pass through the firewall. We can even fragment TCP packets as well, but it is basically a TCP ping sweeping utility.

[willyhacker]# hping S p 53 f

60 bytes from flags=SA seq=0 ttl=124 id=17051 win=0 time 45.3

60 bytes from flags=SA seq=1 ttl=124 id=19551 win=0 time 134.9

as you see whenever a port is open (TCP 53/DNS), we receive back SYN/ACK flags set packets.

Moreover, sometimes the filtering devices can not handle fragmented packets and let them in, thus we can map the network behind the filtering device.


Stateless Firewalls & Source Port Scanning:

This method can apply to those filtering devices which does not keep the state of traffic. Namely, it wont work against stateful filtering devices. So what is the idea, basically think of such a device which will never remember if the connection has begun from inside or outside. Boom! I see your sparkling eyes. Right, FTP, or yes, DNS. Anyothers? Several If we send a packet with the source port 20 in FTP, which is the default DATA port, we can check the system behind the firewall and map the network behind the firewall.

For this, we will use nmap, we will discover its features for other methods later on this paper. The g switch of nmap will let us do that.

[willyhacker]# nmap sS P0 g 20 p 139

as you see, we use the SYN scan (-sS) without pinging (-P0) the target system.

If it comes out that the port is open, then it has two significant meanings, one the system probed is alive behind the firewall, which is good for network mapping, and second, FW ACL does not block TCP 139 port, which is a good starting point for hacking Windows based systems.

The authors of Hacking Exposed have also mentioned this method in their second edition and they got a very handy tool for utilizing this method to get into system, fpipe, you may grab it from This utility is a modified port redirector and you can set the source port to 20 with the help of it.



ICMP Enumerating with icmpenum:

Ping is maybe the most known ICMP packet ICMP ECHO REQUEST (type 8) and the reply is ICMP ECHO REPLY (type 0). Therefore most firewall admins blocks incoming pings, however they do not care about other types of ICMP packets, which can be handy for gathering juicy information from the target.

To do use the other options of ICMP, our favorite tool is icmpenum from Simple Nomad. You may grab it from his personal site

Rather than ICMP ECHO packets, we may send ICMP TIME STAMP REQUEST and ICMP INFO packets to the system. Furthermore, it supports spoofing and promiscuous listening for reply packets. Icmpenum is great for enumerating networks who block ICMP Echo packets but have failed to block Timestamp or Information packet, or for upstream sniffing of trusted addresses.

[willyhacker]#icmpenum I 2 v is up is up is up is up is up

in this preceding example, we have enumerated all alive hosts by sending ICMP TIME STAMP requests in the network.

As we have mentioned earlier, it can spoof packets with s switch and can listen in promiscuous mode with p option.

[willyhacker]#icmpenum I 3 s p v

In this example, we have spoofed the IP address with s switch and we get to promiscuous mode with p option with ICMP INFO packets.

To summarize, this tool allows us to determine alive hosts behind the filtering devices with the help of ICMP types ECHO, INFO, TIME STAMP REQUEST. In many of pen-tests, I deploy this little and handy utility for checking the alive hosts behind the firewall and it works most of the time.


Playing with the ICMP Packages:

The folk Ofir Arkin, has released a whitepaper about the hazards of ICMP and its usage about operating system guessing and filtering device testing. I strongly suggest you guys to take a check his study. This part of our study heavily depends on his study and findings. I have tested his findings in a laboratory and used some ideas in my pen-tests. I found them especially handy in network topology mapping and in ACL discovery. You can find his detailed document from, he has given a speech this year at BlackHat Europe.

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

o Header Length Field

o IP Options Field

Using non-valid field values in the IP header

o Using valid field values in the IP header

Abusing Fragmentation

The UDP Scan Host Detection method

With the first method we are using bad IP headers in the IP datagram that would generate an ICMP Parameter Problem error 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).

The tool we will be using for playing with the ICMP packages is called ISIC written by Mark Frantzen. You can grab it from

the user can specify how often the packets will be fragmented, have IP options, TCP options and etc.

In the next example I have sent 20 IP Packets from a LINUX machine to a Microsoft Windows NT WRKS 4 SP4 machine. The datagrams were not fragmented nor bad IP version numbers were sent. The only weird thing sent inside the IP headers was random IP Header length, which have produced ICMP Parameter Problem Code 2 error message as I anticipated.

[root@stan packetshaping]# ./isic -s -d -p 20

-F 0 -V 0 -I 100

Compiled against Libnet 1.0

Installing Signal Handlers.

Seeding with 2015

No Maximum traffic limiter

Bad IP Version = 0% Odd IP Header Length = 100%

Frag'd Pcnt = 0%

Wrote 20 packets in 0.03s @ 637.94 pkts/s

tcpdump trace:

12:11:05.843480 eth0 > > cartman.sys-security.

com: ip-proto-110 226 [tos 0xe6,ECT] (ttl 110, id 119,


12:11:05.843961 eth0 P > kenny.sys-security.

com: icmp: parameter problem - octet 21 Offending pkt: > ip-proto-110 226

[tos 0xe6,ECT] (ttl 110, id 119, optlen=24[|ip]) (ttl 128, id 37776)

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.

Moreover, if you wanna play with the low-level row TCP/IP packages in order to test your systems, firewalls and filtering devices, I do suggest using CASL (custom auditing and scripting language). Cybercop from NAI, has a unique feature which allow us to play with the low-level packets in a GUI interface. We can create any choice of our packets as scripts and run them against the firewalls or whatever system we want. By combinig this tool to the findings of Ofir arkin, we can get the idea what is happening on the victim site and determine the ACL and map the network topology. By the way, dont forget to run your choice of sniffer on your attacking box to review the packets elicited from the target.




NMAPing: (network mapping)

I must mention about the nmap, which you can get from and it is such a wonderful tool, you cant do without it. It has many different switches, which eases our jobs from many different perspectives. Until recently this tool was mainly a UNIX tool, however the folks at eEye ( has released an NT version which performs the same functions as in the UNIX version.

Albeit, it is basically a port scanner, its features let us do some quiet scanning for port probes. Yet, I should mention that, there are some intrusion detection SW out there capable of catching nmap scans.

As I mentioned, most of the firewalls do not respond to ICMP echo requests (ping), thus we will use the P0 switch which disables ICMP pinging. sS switch will perform a TCP SYN stealth scanning and so on. To get all the features of nmap type

[wilyhacker]# nmap h

from your box.

A filtered port in nmap signifies one of three things.

No SYN/ACK packet is received

No RST/ACK packet is received

An ICMP type 3 message (Destination Unreachable) is received.

Nmap pulls all three of this conditions and report it as "filtered" port. To understand this nmap gathers the ICMP packages sent back to the attacker box. ICMP packets houses all the data necessary to understand what is happening.

The "unfiltered" port is reported only when we scan a number of ports and receive an RST/ACK packet back. In this state, either our packets are passing through the filtering device, but the target box do not listen on that port, OR the firewall is responding on behalf of the target with IP spoofing with RST/ACK flags set.

Anyway, I dont wanna get into details of nmap, as there are many papers out there explaining the details of nmap, however as it is understood, it can be handy for network mapping behind firewalls and we can discover filtering device ACLs.



The aim of this paper was to give some idea about firewall penetration testing and network topology mapping behind firewalls. We have touched many different salts of firewall scanning tools, and there are many more at wild.

This methods are deployed in pen-tests to discover what is behind the filtering device and to figure out the ACL of this device. To do a successful pen-test, we need to know what is happening behind the closed doors. Who is watching the door? , what is he/she checking? and so on. Harvesting a wealth of information is the main step for a successful hacking, and to gather this information we have to penetrate through firewalls.

Watch your servers at wild


Vesaria, LLC

© 2000 - 2018 Vesaria Network Security Specialists        
   About Vesaria   |   Legal   |   Privacy   |   Contact