Firewall Testing – Traceroute
Although traceroute was discussed in Footprinting → “Tracerouting – Finding your way back” it’s also important to note some key features that traceroute can be utilized for. With the traceroute tool you can ascertain:
- Network paths from your host to the target.
- Ports the firewall will allow back into the trusted zone.
- A state-by-state hop until the final packet destination (which in many cases it may return abnormal results placing you for instance in the middle of the, Atlantic or Pacific oceans).
- Firewall testing against networks with improper security settings enabled.
- Useful for UDP and ICMP testing against firewalls (Where it may be a common practice for a network administrator to leave UDP fully open focusing his or her security practices on the abundantly used TCP).
In most cases we will start out with our host command to determine the IP address of the target. You can also issue a dig command for the return information, too. Finally the last two methods (only one we will detail) is the usage of p0f – and through a web browser and finally the usage of the ping command. However, please note that the ping command will in fact make some noise and most possibly be logged!
At this point in the materials you should already be familiar with launching the ping, host, utilizing p0f and whois lookups (which is not mentioned in the previous paragraph). To be brief and to the point, we will highlight them quickly in figure 1.0:
From the figure listed above, we see the 3 different types of obtaining the IP address. As for the icing on the cake, you can also do this with the use of a packet sniffer to grab the traffic as you look at the target location via web. Now that we see we have an IP address of: 18.104.22.168 we can launch a traceroute to see what information we get in return. Figure 1.1 displays a traceroute dump of google.com:
Figure 1.1 demonstrates line 13 with the IP addresses we had discovered.
What the figure in 1.1 is telling us is that, if we see the address of: 22.214.171.124 as the final stop on our packet traversal we know that it is hitting google. We’ve verified this previously. The next steps we need to take is to confuse the firewall and allow it to forward our packets to the internal network so we may get a chance to build an IP address listing of the internal machines. Or, we can at least see one machine that is behind that firewall to hopefully exploit.
In order to trick the firewall we need to perform a few of the following actions with traceroute:
Attempt to change the port we are sending our requests through for traceroute.
Change the protocol from UDP / TCP to ICMP.
Change the TTL value
As per our first suggestion the port can easily be changed; you can do a port change as follows:
Figure 1.2 Demonstrating a port change and firewalling
It is not uncommon to find that while you are running a traceroute request that along the way ports will be firewalled. Of course, we truncated the information that was displayed herein. The scans can go to about 30 hops.
To change your port settings you will use the following command: traceroute -p 21 target.com the -p tells the traceroute application that you’d like to target a specific port and have the scans piked / traced over those ports. Target.com identifies any target that you’d like to use (google, apple, microsoft, etc).
Changing protocols is empirical, to the scanning process. Failure to test and try different protocols may leave you blind sided during your scans. Taking in the following account; traceroute -P UDP -p 25 foo.com in this instance, it may appear a bit confusing. We are issuing the -p and, -P options concurrently. Albeit the command options appear similar and to many windows users the -p and -P options may be transparent / interchangeable they are in-fact their own options! The lower-case option is that of port, while the capitalized option is that of Protocol.
Certain options of the traceroute functionality are only available to root. Issuing the protocol option with TCP in regular user mode will generate error: “The specified type of tracerouting is allowed for superuser only.” In such a case you’d need to sudo and perform the option all one one line providing your password for root.
Figure 1.3 will demonstrate the usage of TCP options in traceroute:
Figure 1.3 displaying an attempt at TCP tracerouting as root.
Considering our scans have failed in figure 1.3, the scan results may still yield information for you – so, don’t skimp on the testing. Trying other ports may yield different results. In addition to which, the final settings would be to attempt ICMP and UDP. You can run this in the same manor as the other scans. To toggle those options, launch the scans as the following for ICMP:traceroute -P ICMP -p 80 foobar.com as per the scans of the UDP type, enter the following: traceroute -P UDP -p 80 foobar.com
Additional scan techniques will in most cases require root privileges, if an error message is displayed about superuser privileges please utilize sudo before the command execution parameters to tap into additional functionality. In addition to which your results and mileage may vary. This deeply depends on the fact that if you are launching the scans through a firewall on your end, some of your packets may be terminated at your gateway!