Testing Firewalls Hping3 ONLY!!
Testing Firewall Challenge -- Only Hping3
Testing your firewalls is a critical step in assuring you are protecting your assets appropriately. This article is called "Testing Firewalls Hping3 ONLY" because I foresee many more posts on my part on this very topic. In time I may collect my methods into a single post.
In my home lab environment I have a machine set up that is dedicated to NIDS. The only thing this machine does is monitor the network----An excellent side project if you have a spare computer kicking around. On my home lab network there is very little risk of intrusion. The only activity will be from inside.
I have set up a ton of firewalls, so when I built the target I honestly just flew through the FW setup(Not ideal). I set it up so that I can ssh over port 22(internal only), the machine can connect to the internet only through port 80 and 443, DNS on 53 and port 4000 so I can transfer files from a different machine somewhere else in the house. I have also set a default policy of "DROP" if the above is not specifically met.
Now I wanted to challenge myself. I preach to my students the glories of hping3. So for this test I am going to forgo using my favourite tool (nmap) and use hping3 for the whole testing. Specifically I will use hping3 for host discovery, port scanning, and testing the firewall to see what gets through.
1. Get IP class:
-very easy and quick "ifconfig" and you will know what class you are working it.
- my network is class "C"
2. Host Discovery:
-There are many better tools then hping3 for this task. For host discovery I always turn to nmap. However that is not part of this challenge!
This method is slow and noisy, but it works.
hping3 -1 192.168.1.x --rand-dest -I wlan0 --fast
In layman terms the above command goes as follows from left to right.
Using hping3 we are sending a icmp echo request to the random IPs in a class C private network, we are sending this packet through the interface wlan0, and because I am impatient I want it done "fast."
So I let the command sit a few minutes and it comes back with:
192.168.1.64
192.168.1.66
hping3 -S 192.168.1.73 -p ++1 >> ports1.txt
192.168.1.73
I stopped it before it could get my router -->254. But we do not care about the router.
3. Scanning
Before I can do an OS fingerprint I need to know which ports will accept a connection. Thankfully there are only three machines to scan.
There are a couple ways of doing this
One way(and it is tedious) is to send a single SYN packet to every port.
hping3 -S 192.168.1.73 -p ++1
As you can see in this picture I got a lot of nothing until I got to port 22 where I got a packet back with the flags SA set. An open port!!
I adapted my command to get a file output.
hping3 -S 192.168.1.73 -p ++1 >> ports1.txt
With three terminals running I can scan all three machines and ship the info to an output file. I go and get a coffee because I want all 65355 scanned.
Also if I wanted to be more stealthy I could set the interval on when these packets are sent out.
hping3 -S 192.168.1.73 -p ++1 --interval 10
This would send a new packet every 10 seconds. In case you are curious it would take 7.58 days to complete this scan. YIKES!!
So the results for machine 192.168.1.73 are:
port 22: response SA
port 53: response RA (closed)
port 80: response RA (closed)
port 443: response RA (closed)
port 4000: response RA(closed)
----closed is good, it means the port is accessible.
We have found our target.
4. Testing Firewall:
-I can tell there is a firewall because there are very few ports detected. That tells me that someone intentionally set this configuration up in this manner. The nature of the ports tells me that the firewall's intention is to only allow their user access to the internet. Also most of the ports responded with nothing, which tells me that the firewall in place DROPs packets by default other than specified ports. (Very important information)
-Here we are dealing with an interesting part of the exercise. When you are testing your firewall you should be clear on what your intent is. When I am probing a professional environment(pentest) I am not sure what I may find. I want to see if I can send a packet through the firewall with the goal of learning about the environment behind the wall.
In the scenario we are dealing with I want to see if the firewall I set up will do what I told it too. Steps 1-3 demonstrate that we can identify a network, discover hosts and scan those hosts. In step 4 we will have access to the target and the sender simultaneously. Monitoring the target we will be able to identify packets that potentially make it through the firewall.
Below I will list the conducted tests and the result:
Keep note that a response of none is what was anticipated
port 80/443
| Terminal | Response |
| hping3 -SA -c 1 -p 80 192.168.1.73 | none |
| hping3 -c 1 -F -p 80 192.168.1.73 | none |
| hping3 -c 1 -FPU -p 80 192.168.1.73 (xmas packet) | none |
| hping3 -c 1 -SF -p 80 192.168.1.73 | none |
| hping3 -2 -c 1 -p 80 192.168.1.73 (UDP packet)(It shouldn't respond because it is UDP. UDP scans work better with nmap) | none |
| hping3 -c 100 -d 80 -S -p 80 -s 80 -a 192.168.1.73 192.168.73 (land attack, spoofing the the source as the destination IP) | none |
port 4000
| Terminal | Response |
| hping3 -S -c 1 -p 4000 192.168.1.73 | RA |
| hping3 -SA -c 1 -p 4000 192.168.1.73 | none |
| hping3 -SF -c 1 -p 4000 192.168.1.73 | none |
| hping3 -2 -c 1 -p 4000 192.168.1.73 | none |
Port 53
| hping3 -2 -c 1 -p 53 192.168.1.73 | none (however on the target side using TCPDUMP I saw a UDP blast. Which means the UDP packet arrived. |
Lessons Learned:
So it turns out my firewall on the target is not that bad. It could use a little tightening. As a result I learned that I would like to block some ICMP packet types from internal resources (I forgot to add it....oops). Having a default policy of DROP was a really good move. I learned through Hping3 that I had a few specific ports open that allowed the machine to do what I wanted it too and nothing else was allowed. It also blocked some of my more sneaky packets like SF (SYN-FIN). This is the kind of thing you want to get out of a Firewall test. To answer the question "did I miss anything?" Even something seemingly small is significant.
During this practice I was reminded that we shouldn't limit ourselves to only one tool. Through the use of many tools we can get different pieces of the picture. Hping3 is incredibly useful, however for a true firewall test I would have also liked to have utilized nmap. Nmap can easily conduct protocol scans, OS fingerprinting, versioning(absolutely critical). Some of these things (like OS fingerprinting) are doable with Hping3 but are just too cumbersome to be that useful.
I liked this challenge because it made me dig deeper into a tool that I already love and have a deeper understanding of it. Hping3 should be used for Firewall tests. It is a simple and efficient little packet generator.
Andrew Campbell
Reference:
