Network Security Hacks [Electronic resources] نسخه متنی

Hack 38 Test Your Firewall

Find out if your firewall really works the way
you think it should.

So you've
set up a firewall and done a few cursory tests to make sure
it's working, but have you tested the firewall to be
sure that it's blocking everything that
it's supposed to? You may not have done this because
you think it will take too long or be too difficult. Luckily
there's
ftester (http://ftester.sourceforge.net), a free tool
for doing extensive firewall tests.

Ftester consists of three Perl scripts. The
ftest script is used for injecting custom
packets as defined in the configuration file
ftest.conf. If you are testing how the firewall
behaves with ingress traffic, you should run this script on a machine
outside of your firewalled network. If you want to test your
firewall's behavior toward egress traffic, you will
need to run ftest from a machine within your
firewall's protected network. One of the other
scripts is ftestd, which listens for the packets
injected with ftest that come through the
firewall that you are testing. This script should be run on a machine
within your internal network if you are testing the
firewall's ingress behavior. If you are testing
egress behavior, you'll need to run it on a machine
external to your network. Both of these scripts keep a log of what
they send or receive. After a test run, their respective logs can be
compared using the freport script, to quickly
see what packets were able to get through the firewall.

Before you can use Ftester, you will need the
Net::RawIP ,
Net::PcapUtils, and NetPacket
Perl modules. You will also need the Net::Pcap
module if it is not already installed, since the
Net::PcapUtils module depends on it. If you have
the CPAN Perl module available, you can install these modules with
the following commands:

# perl -MCPAN -e "install Net::RawIP"
# perl -MCPAN -e "install Net::PcapUtils"
# perl -MCPAN -e "install NetPacket"

Once these modules are available on the systems you will be using to
conduct your firewall test, you will need to create a configuration
file to tell ftest what packets it should
generate.

The general form for a TCP or UDP packet in
ftest.conf is:

source addr:source port:dest addr:dest port:flags:proto:tos

where source addr and source
port are the source IP address and port, and
dest addr and dest
port are the destination IP address and port. Address
ranges can be specified in the
low-high
format or by using CIDR notation. Port ranges can be specified using
the
low-high
format as well. The flags field is where
you specify the TCP that you want set for the packet. Valid values
for this field are S for SYN, A
for ACK, P for PSH, U for URG,
R for RST, and F for FIN. The
proto field specifies which protocol to
use (either TCP or UDP), and
tos contains the number to set the
Type-of-Service (ToS) field in the IP
header to. Sometimes routers will use the contents of this field to
make decisions about traffic prioritization. You can get more
information on the ToS field by reading RFC 791 (http://www.ietf.org/rfc/rfc0791.txt), which
defines Internet Protocol.

ICMP packets can be defined in a similar manner.
Here's the general form for one:

source addr::dest addr:::ICMP:type:code

Here you can see that the main difference between the two forms is
the omission of port numbers and flags. This is because ICMP does not
use port numbers and does not make use of flags. Instead, it uses
types and codes, hence the addition of the
type and code
fields. Currently, there are over 40 ICMP types. Some that may be
familiar to you are the ones used by the ping utility, echo (type 8)
and echo reply (type 0), or the type used by the
traceroute command (type 30). ICMP codes are like
subclassifications of an ICMP type.
Not all ICMP types have ICMP codes associated with them,
although there are roughly the same number of ICMP codes as there are
types. You can find out more about ICMP types and codes by reading the
IANA's assignments for them (see http://www.iana.org/assignments/icmp-parameters).

Here's an ftest.conf that will
check all of the unprivileged TCP ports on a machine with the IP
address 10.1.1.1:

192.168.1.10:1025:10.1.1.1:1-1025:S:TCP:0
stop_signal=192.168.1.10:1025:10.1.1.1:22:S:TCP:0

The stop_signal creates a payload for the packet
that will tell ftestd that the testing is over.

Before starting ftest, you should start
ftestd:

# ./ftestd -i eth0

Now, to run ftest:

# ./ftest -f ftest.conf

This will create a log file called ftest.log
containing an entry for every packet ftest sent.
When ftestd receives the signal to stop, it will
exit. You can then find its log of what packets it received in
ftestd.log. Now you can copy the logs to the
same machine and run them through freport. If
you used a configuration file like the one shown earlier and were
allowing SSH, SMPTP, and HTTP traffic, you might get a report similar
to this:

# ./freport ftest.log ftestd.log
Authorized packets:
-------------------
22 - 192.168.1.10:1025 > 10.1.1.1:22 S TCP 0
25 - 192.168.1.10:1025 > 10.1.1.1:25 S TCP 0
80 - 192.168.1.10:1025 > 10.1.1.1:80 S TCP 0
Modified packets (probably NAT):
--------------------------------
Filtered or dropped packets:
----------------------------
1 - 192.168.1.10:1025 > 10.1.1.1:1 S TCP 0
2 - 192.168.1.10:1025 > 10.1.1.1:2 S TCP 0
3 - 192.168.1.10:1025 > 10.1.1.1:3 S TCP 0

If you are using a stateful firewall and want to test this
functionality, you can also specify packets that have flags other
than SYN set. For instance, if the previous example had used ACK or
some other flag instead of SYN, it would be dropped by the firewall
since only packets with the SYN flag set are used to initiate
connections.

It's a good idea to run ftest
each time you make changes to your firewall, or periodically just to
make sure that your firewall works as you expect it to. While complex
rulesets on your firewall can sometimes make it difficult to predict
exactly how it will behave, ftest will tell you
with good authority exactly what kind of traffic is
permitted.