Testing firewall and IDS rules is a regular part of penetration
testing or security auditing. However, because of the unique complexity
involved of different environments, automated scanners are not able to
provide much use in this area. Several free and open source tools exist
to help craft packets to test firewalls and IDS rules, which can aid in
general assessment. A general working knowledge of TCP/IP is required to
make use of such tools, as well as recommended access to a Linux or OS X
laptop for portable testing. After obtaining a general assessment of a
firewall and its rules, corrections to rules can be updated as
appropriate.
Modern firewalls from major vendors, by default
today, have a strict rule set that generally is fairly secure. Vendors
are much more security aware than in previous years and products now
thankfully reflect a more security conscious environment and internet.
Various testing is still required to ensure the rules in place are
operating as they should or to test and locate areas of improvement in
configuration.
Each TCP or UDP packet has four basic parts of information in the header in regards to routing:
- source port : source ip | destination port : destination ip
Firewall
rules are often setup to inspect packets and route them based on these
source/destination indications in the packet headers. The problem with
this is that the source ip or port can be altered to attempt to bypass a
firewall if poor rules are in place. Firewall rules should be
configured to process DENY rules first, followed by ACCEPT rules later
to avoid many of these security issues in most cases.
A side note on tcpdump
Firewall
testing generally involves two components: an active process or
application sending requests and also a separate independent application
recording down a packet capture of the event. With all of the examples
below, it is recommended to run tcpdump or wireshark in a separate
window to record the interaction and requests that result from the
target firewall.
Running
tcpdump tack i [interface] will provide a simple output in your
terminal window. If it is more desirable to have this data written out
to a file, use tack w.
$ sudo tcpdump -i eth0 -w myfile.cap |
nmap
nmap
is not only useful to gain some initial firewall assessments concerning
open ports but to also do a few general firewall checks that require a
quick inspection. In particular, a modern firewall should not be thrown
off by a host fragmenting packets or using an alternate source port to
allow traffic to pass through the firewall.
Running nmap [target] by default with no options will only perform a TCP scan.
Use -Pn if ICMP replies are blocked to skip the ICMP host discovery step of nmap.
Nmap scan report for example.com (192.168.1.14) |
Host is up (0.12s latency). |
Not shown: 990 filtered ports |
SYN scan
To
perform a TCP SYN scan, use -sS. This is helpful for firewall that
would generally block port scanners. A SYN scan only sends the initial
TCP SYN packet creating what is known as a half-open connection. It is
often perceived that this method causes less load or network stress on
resources.
ACK scan
TCP
ACK scan can be useful as well. If allowed at the firewall, an ACK scan
can report back if a port is being filtered or unfiltered. Generally,
most modern firewalls filter such ACK requests.
Below is the output from a firewall properly configured to filter this sort of probe:
$ sudo nmap -sA example.com |
Nmap scan report for example.com (192.168.1.12) |
Host is up (0.11s latency). |
rDNS record for 192.168.1.12: example.com |
All 1000 scanned ports on example.com (192.168.1.12) are filtered |
Compared to a firewall that is not filtering probes from an ACK scan:
$ sudo nmap -sA example.com |
Nmap scan report for example.com (192.168.1.12) |
Host is up (0.10s latency). |
rDNS record for 192.168.1.12: example.com |
Not shown: 996 filtered ports |
UDP scan
To
perform a UDP scan, use -sU. This must be done in addition to TCP
scanning to inspect current open UDP ports of a firewall. Scanning for
UDP ports is more problematic than scanning for TCP, due to the lack of
any back and forth handshake response when sending UDP packets. Be aware
that many false positives can occur when attempting UDP scans.
Additional nmap tips
Once general port assessment is achieved with nmap, a couple of other quick checks can be performed to test firewall rules.
-f fragment packets
Tack
f in nmap is possible from Linux or BSD hosts only. This option is used
to bypass firewalls; though, again, most all modern firewall vendors
block these types of requests. Test that the firewall does not treat
this traffic different than regular traffic.
-g specify source port
As
mentioned, each packet has a source port as well as destination port,
along with source ip and destination ip. It is possible to change the
source port with a quick nmap test to test if firewall rules are
configured to allow traffic according to particular source ports. Port
53 or 20 are often used as a testing source port. Many times this is
used in combination of specifying the destination port to see if the
traffic is allowed to pass through the firewall with a particular
source/destination combo:
$ sudo nmap -g53 -p22 [target] |
Here
is an example of a host that has port 22 TCP filtered at the firewall.
Using a source port of 20 allow the traffic to bypass the firewall can
be demonstrated as follows:
$ sudo nmap -sS -p22 -g20 192.168.1.16 |
Nmap scan report for 192.168.1.16 |
Host is up (0.057s latency). |
Whereas, a typical port scan would not show the specified port visible:
Nmap scan report for 192.168.1.16 |
Host is up (0.060s latency). |
Not shown: 998 filtered ports |
hping
hping
is a tool for crafting TCP, UDP, or ICMP packets in a repetitive
fashion much like the ping utility operates for ICMP packets. hping is
useful to inspect if a particular port or packet is being filtered at
the target firewall side or if a particular traffic type is being
manipulated altogether.
An example command with hping is:
$ sudo hping3 192.168.1.202 -p 22 -c 4 -V -S |
sudo hping3 [destination host] [port] [number of packets to transmit] [verbose] [-S for SYN]
This
above example is sending four TCP SYN packets on port 22 to the host.
It is helpful while issuing hping commands to open up a second terminal
and run tcpdump to record the session at the same time.
An example of port 22 traffic being filtered looks similar to the following:
$ sudo hping3 example.com -p 22 -c 4 -V -S |
using en1, addr: 172.16.1.101, MTU: 1500 |
HPING example.com (en1 192.168.1.12): S set, 40 headers + 0 data bytes |
--- example.com hping statistic --- |
4 packets transmitted, 0 packets received, 100% packet loss |
round-trip min/avg/max = 0.0/0.0/0.0 ms |
Whereas port 22 SYN packets accepted would appear similar to the following:
$ sudo hping3 example.com -p 22 -c 4 -V -S |
using en1, addr: 172.16.1.101, MTU: 1500 |
HPING example.com (en1 192.168.1.14): S set, 40 headers + 0 data bytes |
len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 |
sport=22 flags=SA seq=0 win=14600 rtt=94.4 ms |
seq=2025389860 ack=1382964684 sum=d336 urp=0 |
len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 |
sport=22 flags=SA seq=1 win=14600 rtt=114.5 ms |
seq=2231940279 ack=1895298182 sum=abbf urp=0 |
len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 |
sport=22 flags=SA seq=2 win=14600 rtt=97.0 ms |
seq=1994283418 ack=1525068590 sum=5b80 urp=0 |
len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 |
sport=22 flags=SA seq=3 win=14600 rtt=95.3 ms |
seq=96473888 ack=1204458524 sum=216a urp=0 |
--- example.com hping statistic --- |
4 packets transmitted, 4 packets received, 0% packet loss |
round-trip min/avg/max = 94.4/100.3/114.5 ms |
tcpreplay
tcpreplay
is a suite of tools used by many firewall vendors to test their own
firewall hardware. tcpreplay operates by replaying a previously recorded
packet capture (.pcap format) against a particular target. The
particular capture can be edited with tcprewrite and replayed to assist
in testing particular hardware or TCP/IP stack for a given network
traffic scenario. tcpreplay is not only used to simply replay edited
captures for testing, but it is also used to test particular rates of
the captured traffic as well against the device.
To replay a particular packet capture via the specified, use the following command:
$ sudo tcpreplay --intf1=eth0 file.cap |
The rate of playback can be specified in mbps, for example:
$ sudo tcpreplay --mbps=100.0 --intf1=eth0 file.cap |
The
counterpart of tcpreplay is tcprewrite. tcprewrite is used to modify
the existing capture file which can then be replayed via tcpreplay.
The syntax used for editing a packet capture file is:
$ tcprewrite [options] --infile=input.cap --outfile=output.cap |
Various
options include rewriting tcp/udp ports, rewriting source/destination
addresses, altering MTU, altering source/destination MAC addresses, as
well as modifying ethernet checksums. More information can be found on
the project page wiki (http://tcpreplay.synfin.net/wiki/tcprewrite).
Legacy tools
Other tools related that may be of interest are isic, which can test the stability of a TCP/IP stack:
http://isic.sourceforge.net/. Tomahawk is useful to test the network throughput of network hardware:
http://tomahawk.sourceforge.net/. Fragroute is useful to rewrite traffic aimed for a target host for TCP/IP scrubbing or other advanced testing
http://www.monkey.org/~dugsong/fragroute/. Another older utility is ftester (
http://dev.inversepath.com/ftester/README)
which incorporates a packet generator along with a packet sniffer. Even
though these tools are some years old, they are still valid today as
the basic concepts of TCP/IP remain unchanged.
Conclusions
Firewalls,
along with IDS setups, are very common in networks of all sizes. Using
an IDS is optional but provides a level of comfort for many
administrators in that the IDS will typically monitor traffic for
malicious attempts as well as offer benefits such as DoS or
rate-limiting prevention.
Many network administrators and security
administrators often setup hardware from vendors with no additional
auditing or testing. On new deployments or with any changes to firewall
rules, a full audit of the firewall or IDS should be performed to verify
security using tools as in this guide as well as commercial tools.
The
firewall is the first point of contact to a network and should be
considered a device that will be poked and tested 24×7 by potential
hackers. Ensuring that proper configurations and rules are in place is
critical for the entire network’s security.
No comments:
Post a Comment