In this day and age, the most common security mechanism in place will be some sort of firewall. Firewalls are a great security mechanism when used in conjunction with other security controls; however, they must be properly maintained and monitored to be truly effective. There are several mechanisms that can be used to attempt to bypass these devices.
It is important to know where you are being blocked when scanning. When testing through a firewall it may become difficult to prepare a stealth attack if you do not have all of the information. Remember that tools such as Firewalk or Hping can assist with determining where the block occurs and whether the port is truly available or just closed. Although this may seem simple, knowing whether there is a firewall in the first place is fairly important as well.
Sometimes, we can use traceroute to see the path to the target system. Let's take a look at an open traceroute from VMnet3 to VMnet8 (NAT):
student@Phobos:~$ traceroute 192.168.75.20 traceroute to 192.168.75.20 (192.168.75.20), 30 hops max, 60 byte packets 1 pfSense.localdomain (192.168.101.10) 0.248 ms 0.166 ms 0.117 ms 2 192.168.75.20 (192.168.75.20) 1.351 ms 1.243 ms 1.188 ms
Looking at this result, we can see that the first hop goes through our gateway at 192.168.101.10 before being routed to the host. Now, we will try the reverse from the Kali machine.
root@kali:~# traceroute 192.168.101.10 traceroute to 192.168.101.1 (192.168.101.1), 30 hops max, 60 byte packets 1 * * * 2 * * * [Truncated…] 30 * * *
Something is blocking us from receiving the path information (it's the pfSense firewall configuration). This technique is not always useful, but definitely good to know about.
There is a firewall; now what? The next step is to determine which ports are being blocked by the firewall, or more importantly which are open.
Hping3 is included as part of the Kali distribution. It can also be invoked at the command line by simply typing: hping3. Hping3 is a powerful tool that can be used for various security testing tasks. The following syntax can be used to find open ports while remaining fully in control of your scan:
root@kali:# hping3 -S 192.168.101.101 --scan 1-80
An example of the output of this command is shown in the following image:
This command allowed us to perform a SYN scan starting at port 1 and incrementing through 80 ports. Enter the following command at the Kali prompt:
hping3 –c 10 -S --spoof 192.168.101.102 -p 80 192.168.101.101
This command will spoof 10 packets from 192.168.101.102 to port 80 on 192.168.101.101. This is the basis for an idle scan and if successful would allow you to hping the 192.168.101.102 machine to look for an increase in the IP sequence number. In this case, we could enable monitoring on the pfSense machine to emulate what this traffic looks like to a network administrator reviewing the logs.
Challenge yourself to create and monitor different packets and the usage of Hping so that you can gain a good understanding of the traffic flow. The best means of remaining undetected while testing is to fully understand the technology that is being used.
Take a look at the logs generated from a successful scan and keep in mind that, due to the amount of traffic involved, even secured networks will sometimes only log and trigger events based on denied traffic.
Tip
Logging per rule will need to be enabled on the firewall to see allowed traffic. Not logging permitted traffic is a fairly standard practice as it reduces the firewall log size. Educate your clients that proactively monitoring allowed traffic can also be beneficial when attempting to truly secure a network.
One of the easiest methods to test open ports on a firewall is to simply use the firewalking script for Nmap. To test the open firewall ports, you will need a host behind the firewall as the target:
nmap --script=firewalk --traceroute 192.168.101.101
The command sequence is straightforward and familiar: we invoke nmap, use the script option, and choose the firewalk script. We then provide the input that firewalk needs by performing a traceroute to 192.168.101.101, which we know is behind our target firewall.
Although we were able to determine which ports on the firewall were open (21, 80, and 443), if you take a look at the firewall denies it quickly becomes apparent that this is not a quiet test and should only be used when stealth is not needed. What this boils down to is that stealth requires patience and a well made plan of action. It may be easier to manually verify if there are any common ports open on the firewall and then try to scan using one of the well-known ports.
Tip
To effectively emulate proper firewalking or port probing with Hping, the network would need to have a gateway behind the firewall. This can be accomplished in a lab when replicating a production environment, but it is beyond the scope of this chapter. The commands remain the same, but the information gained can increase dramatically. These tools use TTL to determine if a port is open or not and, as our gateway is on the same machine as our firewall and router, the results are varied and obscured.
All in all, idle scans remain the best method of determining what is behind a properly locked down firewall. The flavor of the moment is SYN Cache Idle scanning and a great paper about this subject titled Idle Port Scanning and Non-interference Analysis of Network Protocol Stacks Using Model Checking written by Roya Ensafi, Jong Chun Park, Deepak Kapur, and Jedidiah R. Crandall, University of New Mexico can be found at the following link:
https://www.usenix.org/legacy/event/sec10/tech/full_papers/Ensafi.pdf