How To Test Your Linux-Distro Firewall

Want to support HowtoForge? Become 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, 2011-02-14 04:58.

For those who need good external scan test HackerTarget.com have nmap (trusted open source port scan program) free.

 

Payu

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, 2011-01-11 19:33.

Wrong. Steve Gibson is nothing but a fraud. You should do some research : http://allthatiswrong.wordpress.com/2009/10/11/steve-gibson-is-a-fraud/ Says it all. And it's true. Also cites resources and specific things he's said and done that show even more. WRT why Linux is not stealth. Keep in mind linux is often used for servers. Also keep in mind that you should not just drop all packets (say icmp). If you aren't a server or router, well ok. But fact is ICMP has its uses (error codes!); some isp's may even use it when you're having connectivity issues. But if you think all linux machines should be in stealth, then... maybe you should just not use email, web or anything else. What should be done (and is, last I recall of the distros I use or have used) is that services should not be running if not required; I know for sure I had to enable internet services in order for them to be up. And if you do enable firewall, although the rules are not the best method (eg it should be default policy set to DROP and only allow certain things) it still will not allow incoming connections unless you allow them (because of a reject rule). Fact of networks is, in order to provide services, the server need ports open. Linux does not need to be stealth but if it's a requirement for you, well it's not really hard to do, say : /sbin/iptables -I INPUT -j DROP (or set it's policy to drop or install a nat router with no forwarding ports or .. and so on) is it ? Firewalls are not designed to block everything in every situation. I hope you realize this. The fact the protocols have flaws is besides the point (and there are certainly workarounds - be it through syncookies, ignoring forwarding if not a router, limiting how fast packets can come in, and so on). (Yes, I realize the post is fairly old; however, it is a disservice to not make aware the fact that Gibson IS a fraud). Regardless, no computer is 100% secure anyway. Block all incoming traffic? Ok, who has physical access ? "I am the only one with a key to it" - that's security through obscurity because that does not mean no one can access it at some point. And physical access = root access (even with bios password you can always reset cmos, for one example).

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