How To Test Your Linux-Distro Firewall

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Submitted by kanenas.net (Contact Author) (Forums) on Sun, 2006-05-07 00:20. :: Security
Recently, I wrote an article about "How to scan your Linux-Distro for Root Kits".
Now that the machine is... clean! I think, a good thing TO-DO, is to test my Firewall (AGAIN!)
The good news are that we can use the free tool FTester.
The bad news are that FTester needs to be configured right...
So... Let's get to work !


What is FTester ?
The Firewall Tester (FTester) is a tool designed for testing firewalls filtering policies and Intrusion Detection System (IDS) capabilities.

The tool consists of two perl scripts, a packet injector (ftest) and the listening sniffer (ftestd).
The first script injects custom packets, defined in ftest.conf, with a signature in the data part while the sniffer listens for such marked packets.
The scripts both write a log file which is in the same form for both scripts.
A diff of the two produced files (ftest.log and ftestd.log) shows the packets that were unable to reach the sniffer due to filtering rules if these two scripts are ran on hosts placed on two different sides of a firewall.
Stateful inspection firewalls are handled with the 'connection spoofing' option.
A script called freport is also available for automatically parse the log files.

The IDS (Intrusion Detection System) testing feature can be used either with ftest only
or with the additional support of ftestd for handling stateful inspection IDS, ftest can also use common IDS evasion techniques.
Instead of using the configuration syntax currently the script can also process snort rule definition file.


Features:
- firewall testing
- IDS testing
- simulation of real tcp connections for stateful inspection firewalls and IDS
- connection spoofing
- IP fragmentation / TCP segmentation
- IDS evasion techniques


Requirements:
The following perl modules are required: Net::RawIP, Net::PcapUtils, NetPacket

So... we will need the Net::RawIP , Net::PcapUtils, and NetPacket Perl modules.
We may also need the Net::Pcap module if it is not already installed, because the Net::PcapUtils module depends on it.
If we have the CPAN Perl module, we may install these modules with the following commands from shell:

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

# perl -MCPAN -e "install Net::Pcap"

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

# perl -MCPAN -e "install NetPacket"



... and we are done with the perl modules.


Download:
The most recent release is ftester-1.0.tar.gz (2006-Feb-13). From shell run...

# wget http://dev.inversepath.com/ftester/ftester-1.0.tar.gz


All releases at available at http://dev.inversepath.com/ftester.


Extract:
Use tar to... unzip the source pre. From shell run...

# tar -xzf ftester-1.0.tar.gz




So far...
We have installed a few perl modules required, we have downloaded ftester-1.0.tar.gz (2006-Feb-13)
and we have extracted the file and made the directory ftester-1.0.
Well done !!!


Configuration:
We will need to create a configuration file to tell ftest what packets it should generate.
The definition of the packets we want to send for test if they can traverse the firewall is mainly specified in a configuration file (ftest.conf), the main syntax is:

Source Address:Source Port:Destination Address:Destination Port:Flags:Protocol:Type of Service


for TCP and UDP packets,

Source Address:Source Port:Destination Address:Destination Port:Flags:ICMP:icmp_type:icmp_pre


for ICMP packets.

a few examples:

# SYN packet to 10.1.7.1 port 80 
192.168.0.10:1024:10.1.7.1:80:S:TCP:0
# PSH,ACK reply from 192.168.0.10
192.168.0.10:20:10.1.7.1:1022:AP:TCP:22
# UDP packet
192.168.0.10:53:10.1.7.1:53::UDP:0
# ICMP packet type 3 pre 5
192.168.0.10::10.1.7.1:::ICMP:3:5
# ranges are allowed for source address, source port, destination port
# source address can also be specified in CIDR form
192.168.0.1-255:1024:10.1.7.1:22:S:TCP:0
192.168.0.1:1024:10.1.7.1:1-65535:S:TCP:0
192.168.0.1:1-1024:10.7.0.1:20-25:S:TCP:22
192.168.3.0/24:1-1024:10.7.0.1:20-25:S:TCP:0
192.168.0.0/22:1024:10.7.0.1:80:S:TCP:0


A stop signal is necessary for telling ftestd that our test is completed, so use the following syntax:

stop_signal=192.168.0.1:666:10.1.7.1:666:S:TCP:


the stop_signal can be a TCP, UDP or ICMP packet, this packet will cause the
termination of the sniffer so every packet specified after the stop_signal
directive won't be seen by ftestd.

Now from shell...

# vi ftest.conf



You will see a lot of stuff in there... Just comment anything you don't need !!! I used...

# checking privileged ports (<1025)
192.168.0.10:1025:10.1.7.1:1-1025:S:TCP:0
# checking proxy port
192.168.0.10:1025:10.1.7.1:3128:S:TCP:0
stop_signal=192.168.0.10:80:10.1.7.1:1025:AP:TCP:0


Before starting ftest, we should be root and then start ftestd, from shell:

# ./ftestd -i eth0



Run ftest from shell:

# ./ftest -f ftest.conf




Finally we copy the two log files on the same host and we compare them using freport from shell:

# ./freport ftest.log ftestd.log



You will see something like...

Authorized packets:
-------------------
21 - 192.168.0.10:1025 > 10.1.7.1:21 S TCP 0
22 - 192.168.0.10:1025 > 10.1.7.1:22 S TCP 0
23 - 192.168.0.10:1025 > 10.1.7.1:23 S TCP 0
25 - 192.168.0.10:1025 > 10.1.7.1:25 S TCP 0
80 - 192.168.0.10:1025 > 10.1.7.1:80 S TCP 0
110 - 192.168.0.10:1025 > 10.1.7.1:110 S TCP 0
113 - 192.168.0.10:1025 > 10.1.7.1:113 S TCP 0
1027 - 192.168.0.10:80 > 10.1.7.1:1025 PA TCP 0

Modified packets (probably NAT): -------------------------------- 443 - 192.168.0.10:1025 > 10.1.7.1:443 S TCP 0 443 - 192.168.0.10:1025 > 10.1.7.5:443 S TCP 0
Filtered or dropped packets: ---------------------------- 1 - 192.168.0.10:1025 > 10.1.7.1:1 S TCP 0 2 - 192.168.0.10:1025 > 10.1.7.1:2 S TCP 0 3 - 192.168.0.10:1025 > 10.1.7.1:3 S TCP 0 ... ... ... 1026 - 192.168.0.10:1025 > 10.1.7.1:3128 S TCP 0



That's all folks.
A good idea is to run ftest each time you make changes to your firewall,
or from time to time just to make sure that your firewall works !!!


Read more:
Man page (ftester.8)
README



PS:
I don't think is a good idea to post the results of my test !!!
;-)

Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Anonymous (not registered) on Mon, 2006-05-29 07:36.
would recommend to test with nessus also, http://www.nessus.org/
it can also find known security exploits in your firewall
Submitted by Anonymous (not registered) on Fri, 2006-05-12 04:51.

In some cases you could use Shields Up from grc.com to test your config, right?

--Supermike

Submitted by Anonymous (not registered) on Sun, 2006-06-04 18:07.

Because grc.com is a joke. They were the "poster boy" that made Zone Alarm famous.

If you want to thoroughly test things, you don't go to some third party that promotes its own products. You use proven open-source tools from developers that have no money motivated motive. (As in they do it, because they love what they do).

Honestly, how can you trust grc.com if they don't reveal the details of their tests? (source code?). How do you know such online security tests are trustworthy?

Submitted by Jacob (not registered) on Mon, 2008-09-22 07:36.

Grc.com is a great tool and serves it's purpose well.  Not everyone is a technical expert or wants to be in order to use their PC for the actual task at hand.

If you chose not to trust its tests/advice then you could equally doubt the validity of tests/advise on other sites - such as this one!

Grc.com has earned its trust over the years from the user/IT community.

PS.  Why doesn't Ubuntu (and many other Linux flavours) pass the port tests (they should be in stealth mode) out of the box?

Submitted by Anonymous (not registered) on Tue, 2006-08-08 21:49.

Steve Gibson has nothing to do with Zone Labs.  They are currently owned by checkpoint.  He wrote that app as service to the security community to test the very first personal firewalls.  Which is the same reason he give people access to RSA random text generator to get true randome passwords (https://www.grc.com/passwords.htm).

 He also does a security podcast with Leo Laporte to promote computer security.  Listen to the podcast, you will find "they love what they do".  (https://www.grc.com/securitynow)

 None of this has anything to do with ZoneAlarm.

 

Uncue 

Sponsored Links: Unified Communications: Thoughts, Strategies and Predictions
Join the discussion.
www.seamlessenterprise.com

IP Convergence
Integrate your wireless and wireline networks.
Learn how from the experts at Sprint.
www.seamlessenterprise.com

Wireless & Wireline Integration
Thoughts, strategies and solutions: join the discussion
www.seamlessenterprise.com

Unified Communications 2009
Join the Discussion. Now.
www.seamlessenterprise.com