You are hereVerify ports open in a firewall with ftester

Verify ports open in a firewall with ftester


By sean - Posted on 24 October 2008

The need: How can firewall port rules be verified? There are scanning tools available, but they are slow and noisy.

The OpenSource tool ‘fester’, by Andrea Barisani at Inversepath, seems up to the task:

"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. ....
Features: ... simulation of real tcp connections for stateful inspection firewalls and IDS, connection spoofing, IP fragmentation / TCP segmentation,   IDS evasion techniques"

http://dev.inversepath.com/trac/ftester

http://dev.inversepath.com/ftester/

http://www.tisc-insight.com/newsletters/56.html    (I only notice this paper after I had done the tests below, and it provides several examples...)

An example test run of ftester is described below.
Other OpenSource tools of relevance: linet, tcpdump, ifconfig, nmap, hping, nemises, scapy.

Installation: The ftester components are perl scripts so they can be executed on any platform with a recent version of perl (at least 5.6.1 is recommended) and the three perl modules Net::RawIP, Net::PcapUtils, NetPacket. On Ubuntu 8.04, try

apt-get install libpcap0.8 pcapUtils libnet-pcap-perl libpcap-dev
cpan install NetPacket::IP
cpan install Net::PcapUtils

Open ports test

For this test two Suse systems were used, separated by a Sunscreen firewall and several routers:
Emitter       >> NAT router        >> Stealth Firewall >> Sensor
176.17.3.30     80.254.183.65           (Sunscreen)         193.5.233.50
Ftest                                                       ftestd

Initialisation: Empty or move the log files on the emitter (ftest.log) and sensor (ftestd.log). Select a port that we know is open between emitter and sensor, this will be used to send a ‘stop signal’ indicating the end of a test. In this example we expect port 21 (ftp) to be open.

Sensor command: (listen to interface ‘eth0’ in verbose mode)

perl ./ftestd -i eth0 -v
Firewall Tester sniffer v.1.0
Copyright©) 2001-2006 Andrea Barisani <andrea@inversepath.com>
default system TTL =
replies TTL        = 200
listening on eth0

Emitter command: (do a firewall test according to the specification in ftest.conf)
perl ./ftest -f ftest.conf -v
The configuration file, ftest.conf contains:
# 10ms delay
flags: -d 0–01 -v
# checking privileged ports (<1025)
176.17.3.88:1025:193.5.233.50:1-1025:S:TCP:0
# What port do we know is open, through which we can send a special
# packet that indicates the end of the test run?
stop_signal=176.17.3.88:1025:193.5.233.50:21:AP:TCP:0

Results:

On the emitter we see a line output for each packet sent, and additionally, a file ‘ftest.log’ is created documenting  the packets sent

1 - 176.17.3.88:1025 > 193.5.233.50:1 S TCP –
2 - 176.17.3.88:1025 > 193.5.233.50:2 S TCP –
3 - 176.17.3.88:1025 > 193.5.233.50:3 S TCP 0

…..

On the sensor, a line is shown for each packet received:
21 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0

Reporting: The ftest.log can then be copied to the sensor, and the two log files compared, and a report established of the open and closed ports. Below there are no unmodified open port, but several which are open and subject to network address translation.
./freport ftest.log ftestd.log

Authorized packets:

Modified packets (probably NAT):
1 - 176.17.3.88:1025 > 193.5.233.50:1 S TCP 0
2 - 176.17.3.88:1025 > 193.5.233.50:2 S TCP 0
4 - 176.17.3.88:1025 > 193.5.233.50:4 S TCP 0
21 - 176.17.3.88:1025 > 193.5.233.50:21 S TCP 0
80 - 176.17.3.88:1025 > 193.5.233.50:80 S TCP 0
443 - 176.17.3.88:1025 > 193.5.233.50:443 S TCP 0
1026 - 176.17.3.88:1025 > 193.5.233.50:80 PA TCP 0
                >>>>>>>>
1 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
2 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
4 - 80.254.183.65:1025 > 193.5.233.50:80 S TCP 0
21 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
80 - 80.254.183.65:1025 > 193.5.233.50:80 S TCP 0
443 - 80.254.183.65:1025 > 193.5.233.50:443 S TCP 0
1026 - 80.254.183.65:1025 > 193.5.233.50:80 PA TCP 0

Filtered or dropped packets:
3 - 176.17.3.88:1025 > 193.5.233.50:3 S TCP 0
5 - 176.17.3.88:1025 > 193.5.233.50:5 S TCP 0
6 - 176.17.3.88:1025 > 193.5.233.50:6 S TCP 0
7 - 176.17.3.88:1025 > 193.5.233.50:7 S TCP 0
……. (many more lines..)

Analysis: The detected open ports correspond to what was expected in this case, and the information about NAT is correct.

Speed Tests

Some additional tests were conduced to give more real-life usage scenarios. Note that a slow 1Mb network was used for the test, so results are indicative only:
a)    Checking all 65’000 ports for one source and one destination IP took 56 seconds.
b)    Checking all 65’000 ports for 90 source IPs and one destination IP took 80 minutes.
c)    Checking all 65’000 ports from two sets of 45 source Ips and two destinations, i.e. which two ftester instances running in parallel, also took 85 minutes,

  • it was almost twice as fast with two processes running in parallel.
  • The load on the emitter (2Ghz Pentium ‘barebones’, 512Mb ram) was significant (20% cpu, load average with ‘uptime’: 2.21).
  • The (ADSL) NAT router in front of the emitter was really not fast enough:
    FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 193.5.233.53
    %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x8015B04C, alignment 0
    Pool: Processor  Free: 103768  Cause: Memory fragmentation
    Alternate Pool: None  Free: 0  Cause: No Alternate pool

 

Lessons learned.

This is a great tool!

Performance is linear, depending on the number of ports, IPs (in the above low performance environment, one source IP/destination IP for all ports per minute). Checking an entire C-class is much faster than port scanning, but still takes time.

In a Gigabit environment it will of course be much faster than the tests above, but careful selection of source and destination ranges and ports is important.
Several ftester runs can be done in parallel to speed up.