Jump to content

Testing Firewall Rules


Recommended Posts

Sometimes it is handy to check firewall rules without coordinating a test with the end user. For these tests, use the hping2 utility to "spoof" traffic coming from the source IP address(es) used in the firewall rules.

At the same time, monitor the internal and external network interfaces on the firewall to make sure traffic is reaching the firewall and allowed through the firewall. In order to do this, you must have root access on the firewall and on the machine running hping2.

Example firewall rule:

Permit source IP to communicate with destination IP over TCP port 1000.

To test the rule, issue the following hping2 command:

hping2 -a -p 1000

At the same time, log into the firewall and run the following commands (example using a Solaris firewall with internal network interface hme0 and external network interface qfe0):

In window 1:

snoop -d hme0 host port 1000

-- or --

tcpdump -i hme0 host and port 1000

In window 2:

snoop -d qfe0 host port 1000

-- or --

tcpdump -i qfe0 host and port 1000

If you do not see any output in window 1, traffic is not reaching the firewall. A choke router or other packet-filtering device may not be allowing the traffic to reach the firewall.

If you see output in window 1 but not in window 2, traffic is not being allowed through the firewall. Check the firewall rulebase for any errors.

Link to comment
Share on other sites

You can also use nmap

One of the regular tasks you'll be performing with Nmap is verifying that your firewall rules are performing as intended. To do so, run a scan to look for ports that appear open to the outside world and check whether they are filtered or not. A simple firewall audit scan would be something similar to:

nmap -v -sA -ff -r -n www.mywiseguys.net -oA firewallaudit

One of the best ways to understand how your firewall handles uninvited traffic is to verify that its filters and rules are working as you anticipated. For example, one mistake many administrators make when creating rules for allowing traffic through their firewall is to trust traffic based simply on its source port number, such as DNS replies from port 53 or FTP from port 20. To test whether your firewall allows all traffic through on a particular port you can use most of Nmap's TCP scans, including the SYN scan, with the spoof source port number option (--source-port or abbreviated just to –g). Simply provide a port number, and Nmap will send packets from that port where possible. For example, the following command will run a FIN scan using a spoofed source port number of 25 (SMTP) saving the output to file firewallreport.txt.

nmap -sF -g 25 -oN firewallreport.txt www.mywiseguys.net

When auditing your firewall, I recommend that you scan ports in numerical order (option -r) to make it easier to follow the traffic flow when analyzing the Nmap output files. However, when testing the effectiveness of firewalls and intrusion detection systems, use the default, which is a randomized port order, in addition to randomizing the order in which hosts are scanned by using the randomize-hosts option, which can be abbreviated to –rH. This, combined with slow timing options, which we will look at next week, will make any network monitoring devices you have work hard to detect the scan. An example command to test your network defences could be:

nmap -sS --scan-delay 500 -f -rH firewallreport.txt www.mywiseguys.net

Link to comment
Share on other sites

  • 6 months later...

The following will go over how to test Firewall Rules using nmap

Type of Rule

Port(s) - Open/Allowed or Closed/Blocked

Source - Based using a source IP address

Destination - Based on destination IP address

Transport Layer - ICMP blocked/allowed

Then we will go over how to test the nmap commands using your Linksys Router's built in firewall.

We will also look into using the firewall on the Ubuntu BootCD for testing (which would require another laptop)

Link to comment
Share on other sites

SYN scans (-sS) are the workhorse of scanning methods. They are also called "half-open" scans because you simply send a SYN packet, look for the return SYN|ACK (open) or RST (closed) packet and then you tear down the connction before sending the ACK that would normally finish the TCP 3-way handshake. These scans don't depend on the characteristics of the target TCP stack and will work anytime a connect() scan would have worked.

They are also harder to detect -- TCP-wrappers or anything outside of the kernel shouldn't be able to pick up these scans -- packet filters like ipfwadm or a firewall can though. If a box is being filtered NMAP's SYN scan will detect this and report ports which are being filtered.


The option -sT to nmap tells it to run a standard TCP connect scan -- basically, "what TCP services are advertised".

server# nmap -sT mwglinuxbox

Starting nmap V. 2.54BETA22 (
Nmap - Free Security Scanner For Network Exploration & Security Audits. )

Interesting ports on mwglinuxbox (IP.of.that.box):

(The 1538 ports scanned but not shown below are in state: closed)

Port State Service

21/tcp open ftp

22/tcp open ssh

25/tcp open smtp

80/tcp open http

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

The following command will run a FIN scan using a spoofed source port number of 25 (SMTP) saving the output to file firewallreport.txt.

nmap -sF -g 25 -oN firewallreport.txt www.yoursite.com

The following command wil audit your firewall by randomized port order, in addition to randomizing the order in which hosts are scanned by using the randomize-hosts option, which can be abbreviated to –rH. This, combined with slow timing options, will make any network monitoring devices you have work hard to detect the scan

nmap -sS --scan-delay 500 -f -rH firewallreport.txt www.yoursite.com

Link to comment
Share on other sites

  • 7 months later...

$ sudo nmap -sS -p 80,443,1494,2598


Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-15 15:01 EDT

Interesting ports on data.website.com (


80/tcp open http

443/tcp open https

1494/tcp filtered citrix-ica

2598/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 3.87 seconds

Link to comment
Share on other sites

  • 1 year later...

tracetcp is a Windows tool which works much better than traceroute because traceroute uses ICMP which is the same thing the command ping uses. It send an ICMP packet and records the echo. tracetcp will actually connect to each hop along the route with a particular TCP port to ensure no one in the path is blocking that port.

common options used are:

C:\tracetcp-0.99.4beta>tracetcp -?

Usage: tracetcp host

where host = hostName|ipAddress[:portNumber|serviceName]

if portNumber or serviceName is not present then port 80 (http) is assumed


-? Displays help information.

-F Disables the Anti-flood timer.

-R Use Raw Sockets to send packets.

-c Select condensed output mode.

-g address Send to remote host using specified gateway.

-h start_hop Starts trace at hop specified.

-m max_hops Maximum number of hops to reach target.

-n No reverse DNS lookups for each node.

-p num_pings # of pings per hop (default 3).

-r p1 p2 Multiple traces from port p1 to p2.

-s p1 p2 Scan ports p1 to p2. Eqiv of: -cnr p1 p2 -h 128 -m 1 -p 1

-t timeout Wait timeout milliseconds for each reply.

-v Displays version information.


tracetcp www.microsoft.com:80 -m 60

tracetcp post.sponge.com:smtp

tracetcp -n -t 500

tracetcp -F -p 1 -n -t 200

or another example is

tracetcp -F -p 1 -n -t 500[/code]



Link to comment
Share on other sites

  • 3 months later...
  • 4 months later...

Check to see if ports are open along the path using TCP connects versus ICMP which is typically blocked as a security measure, especially on firewalls.

tcptraceroute is a traceroute implementation using TCP packets.

The more traditional traceroute(8) sends out either UDP or ICMP ECHO packets with a TTL of one, and increments the TTL until the destination has been reached. By printing the gateways that generate ICMP time exceeded messages along the way, it is able to determine the path packets are taking to reach the destination.

The problem is that with the widespread use of firewalls on the modern Internet, many of the packets that traceroute(8) sends out end up being filtered, making it impossible to completely trace the path to the destination. However, in many cases, these firewalls will permit inbound TCP packets to specific ports that hosts sitting behind the firewall are listening for connections on. By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters.

It is worth noting that tcptraceroute never completely establishes a TCP connection with the destination host. If the host is not listening for incoming connections, it will respond with an RST indicating that the port is closed. If the host instead responds with a SYN|ACK, the port is known to be open, and an RST is sent by the kernel tcptraceroute is running on to tear down the connection without completing three-way handshake. This is the same half-open scanning technique that nmap(1) uses when passed the -sS flag.

$ tcptraceroute

tcptraceroute 1.5beta7

Copyright © 2001-2006 Michael C. Toren

Updates are available from http://michael.toren.net/code/tcptraceroute/

Usage: tcptraceroute [-i ] [-f ]

[-l ] [-q ] [-t ]

[-m ] ] [-s ]

[-w ]


-n Display numeric output, rather than doing a reverse DNS lookup for each hop. By default, reverse lookups are never attempted on RFC1918 address space, regardless of the -n flag.

-N Perform a reverse DNS lookup for each hop, including RFC1918 addresses.

-f Set the initial TTL used in the first outgoing packet. The default is 1.

-m Set the maximum TTL used in outgoing packets. The default is 30.

-p Use the specified local TCP port in outgoing packets. The default is to obtain a free port from the kernel using bind(2). Unlike with traditional traceroute(8), this number will not increase with each hop.

-s Set the source address for outgoing packets. See also the -i flag.

-i Use the specified interface for outgoing packets.

-q Set the number of probes to be sent to each hop. The default is 3.

-w Set the timeout, in seconds, to wait for a response for each probe. The default is 3.

-S Set the TCP SYN flag in outgoing packets. This is the default, if neither -S or -A is specified.

-A Set the TCP ACK flag in outgoing packets. By doing so, it is possible to trace through stateless firewalls which permit outgoing TCP connections.

-E Send ECN SYN packets, as described in RFC2481.

-t Set the IP TOS (type of service) to be used in outgoing packets. The default is not to set any TOS.

-F Set the IP "don’t fragment" bit in outgoing packets.

-l Set the total packet length to be used in outgoing packets. If the length is greater than the minimum size required to assemble the necessary probe packet headers, this value is automatically increased.

-d Enable debugging, which may or may not be useful.

--dnat Enable DNAT detection, and display messages when DNAT transitions are observed. DNAT detection is based on the fact that some NAT devices, such as some Linux 2.4 kernels, do not correctly rewrite the IP address of the IP packets quoted in ICMP time-exceeded messages tcptraceroute solicits, revealing the destination IP address an outbound probe packet was NATed to. NAT devices which correctly rewrite the IP address quoted by ICMP messages, such as some Linux 2.6 kernels, will not be detected. For some target hosts, it may be necessary to use --dnat in conjunction with --track-port. See the examples.txt file for examples.

--no-dnat Enable DNAT detection for the purposes of correctly identifying ICMP time-exceeded messages that match up with outbound probe packets, but do not display messages when a DNAT transition is observed. This is the default behavior.

--no-dnat-strict Do not perform any DNAT detection whatsoever. No attempt will be made match up ICMP time-exceeded messages with outbound probe packets, and when tracerouting through a NAT device which does not rewrite the IP addresses of the IP packets quoted in ICMP time-exceeded messages, some hops along the path may appear to be unresponsive. This option should not be needed in the vast majority of cases, but may be utilized if it is suspected that the DNAT detection code is misidentifying ICMP time-exceeded messages.


Please see the examples.txt file included in the tcptraceroute distribution for a few real world examples.

To trace the path to a web server listening for connections on port 80:

tcptraceroute webserver

To trace the path to a mail server listening for connections on port 25:

tcptraceroute mailserver 25

Link to comment
Share on other sites

  • 3 months later...

One of my favorite tools to use is nmap. I am going to show some examples of how to use this tool to help you manage or even troubleshoot your network.

First know the definitions that will show in the results


An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port. Finding these is often the primary goal of port scanning. Security-minded people know that each open port is an avenue for attack. Attackers and pen-testers want to exploit the open ports, while administrators try to close or protect them with firewalls without thwarting legitimate users. Open ports are also interesting for non-security scans because they show services available for use on the network.


A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.


Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.

nmap -sV -p 22,53,80,8080,443,110,143,1444,1445,1720,1863[/code]

This will check the specific ports on a specific address or a range of IP addresses

Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...