Firewalking

Table Of Contents

Figure 1

Figure 2

Figure 3

Figure 4

You will notice that the scan terminates immediately after the target port is passed. This is due to the fact that traceroute continues to increase the port numbers for each probe sent. The probe immediately after the successful one will be denied by the ACL on the firewall. To possibly get further, a simple modification to traceroute can be done to add a command line switch to stop port incrementation (Figure 5). This allows us to force every probe we send to be acceptable to the firewall’s ACL (a side effect being that we might not get the normal ICMP unreachable message from the ultimate destination due to the fact that there might actually be something listening on the other end). See appendix A for the source code patch.

· Taking it a bit further

Since the magic of traceroute is all happening at the IP layer, any transport protocol (UDP, TCP and ICMP) can be used. The foundation laid down by traceroute can extend to any other protocol on top on IP. If we attempt to traceroute to a machine behind a firewall and the probe reaching the firewall is prohibited by an ACL filter, the packet will be dropped on the floor (in most cases). All we can determine from the traceroute scan is the last gateway (in this case, a firewall) that responded. This is good entropic information. This firewall can then become a waypoint that we use to determine the success of future probes. If we traceroute to a machine behind this firewall with a different (protocol) traceroute probe, and we get a response, we know two things: 1) that particular kind of traffic is passed by the firewall, and 2) we know a host behind the firewall. If we only get as far as our waypoint, we know that traffic type is filtered. This is the basis for firewalking.

In order to use a gateway's response to gather information, we must know two pieces of information:

· The IP address of the last known gateway before the firewalling takes place

· The IP address of a host located behind the firewall.

The first IP address serves as our metric (waypoint from the above example), if we can't get a response past that machine, then we assume that whatever protocol we tried to pass is being blocked. The second IP address is used as a destination to direct the packet flow (Figure 6).

Using this technique, we can perform several different information gathering attacks. One attack is a firewall protocol scan, which will determine what ports/protocols a firewall will let traffic through on from the attacking host. This would attempt to pass packets on all ports and protocols and monitor the responses. A second potential threat is advanced network mapping. By sending packets to every host behind a packet filter, an attacker can generate an accurate map of a network’s topology.

While traceroute is a useful application, it is not very extensible for any kind of serious reconnaissance scanning; to this end, the proof of concept tool, firewalk, was built.

· Fire, walk with me where?

Firewalk is a network-auditing tool that employs the techniques described above. It attempts determines what transport protocols a given gateway will let through. The firewalk scan works by sending out TCP or UDP packets with an IP TTL one greater then the targeted gateway. If the gateway allows the traffic, it will forward the packets to the next hop where they will expire and elicit a TTL exceeded in transit message. If the gateway host does not allow the traffic, it will likely drop the packets on the floor and we will see no response. By sending probes in a successive manner and recording which ones answer and which ones don’t, the access list on the gateway can be determined.

· 2 Phases

To work its magic, firewalk has two phases, a network discovery phase, and a scanning phase. Initially, to get the correct IP TTL (that will result in expired packets one beyond the gateway) we need to ‘ramp up’ hop counts. We do TTL ramping in the same manner that traceroute works, sending packets out with successively incremented IP TTLs, towards the destination host. Once we know the gateway hopcount (at that point the scan is ‘bound’) we can move onto the next phase, the actual scan.

The actual scan is simple. Firewalk sends out TCP or UDP packets and sets a timeout; if it receives a response before the timer expires, the port is considered open, if it doesn’t, the port is considered closed (Figure 7).

· A Slow Walk

As noted above, packets on an IP network can be dropped for a variety of reasons. When a packet is dropped for any reason other then it being denied by a filter, it is extraneous loss. For our firewalk scan to be accurate, we need to limit this extraneous packet loss to the best of our ability. The best we can do in most cases is to be redundant with the number of probes we send. Unless there is severe network congestion some of the probes should get through. However, what if the probe we send is filtered or dropped by a different gateway while en route to the target gateway (see figure 8)?

To firewalk, this will look like the target gateway has denied the packet, which, in this case, is certainly a false negative. This is not extraneous loss, so simply sending more packets will not help. To prevent this, we must perform a `slow walk` or a `creeping walk`. This is akin to a normal scan, however we scan each hop en route to the target. We perform a standard firewalk ramping phase, and then scan each intermediate hop up to the destination. This allows prevents false negatives due to intermediate filter blockage and allows firewalk to be more confident in its report.

The major benefit is that we can now determine if blocked ports are false negatives. The drawback is that it is, as its name states, slow.

The easiest solution to this problem is to disallow ICMP TTL exceeded messages from leaving an internal network. This will also have the effect of breaking valid uses of traceroute and may inhibit remote diagnostics of an internal network problem. Another defense against firewalking is the use of some form of proxy server. Network Address Translation (NAT) or any proxy server (both application level and circuit level) can prevent Firewalk from probing behind them. While network based intrusion detection tools could detect certain attacks [3]; it is possible to develop a version of Firewalk that would generate packets that would look like valid packets for each service that it is scanning. Currently, Firewalk only fills in the packet header and does not insert any data into a packet. A more sophisticated version could emulate various services in an attempt to masquerade as valid traffic and randomize the order and times that it scans services.

Apply this diff to traceroute version 1.4a5 to add support for static destination ports. Apply the diff using the unix patch program from the traceroute source directory:

--- traceroute.c.orig   Fri Aug 21 15:15:23 1998
+++ traceroute.c        Sun Aug 23 18:58:08 1998
@@ -289,6 +289,7 @@
 int nprobes = 3;
 int max_ttl = 30;
 int first_ttl = 1;
+int static_port = 0;
 u_short ident;
 u_short port = 32768 + 666;    /* start udp dest port # for probe packets */

@@ -352,7 +353,7 @@
                prog = argv[0];

        opterr = 0;
-       while ((op = getopt(argc, argv, "dFInrvxf:g:i:m:p:q:s:t:w:")) != EOF)
+       while ((op = getopt(argc, argv, "dFInrvxf:g:i:m:p:q:Ss:t:w:")) != EOF)
                switch (op) {

                case 'd':
@@ -406,6 +407,13 @@
                        options |= SO_DONTROUTE;
                        break;

+               case 'S':
+                       /*
+                        * Tell traceroute to not increment the destination
+                        * port, useful for bypassing some packet filters.
+                        * Useless without the -p option.
+                       static_port = 1;
+                       break;
                case 's':
                        /*
                         * set the ip source address of the outbound
@@ -744,7 +752,7 @@
                        register struct ip *ip;

                        (void)gettimeofday(&t1, &tz);
-                       send_probe(++seq, ttl, &t1);
+                       send_probe(static_port ? seq : ++seq, ttl, &t1);
                        while ((cc = wait_for_reply(s, from, &t1)) != 0) {
                                (void)gettimeofday(&t2, &tz);
                                i = packet_ok(packet, cc, from, seq);
@@ -1300,9 +1308,9 @@
        extern char version[];

        Fprintf(stderr, "Version %s\n", version);
-       Fprintf(stderr, "Usage: %s [-dFInrvx] [-g gateway] [-i iface] \
-[-f first_ttl] [-m max_ttl]\n\t[ -p port] [-q nqueries] [-s src_addr] [-t tos]
\
-[-w waittime]\n\thost [packetlen]\n",
+       Fprintf(stderr, "Usage: %s [-dFInrSvx] [-g gateway] [-i iface] \
+[-f first_ttl]\n\t[-m max_ttl] [ -p port] [-q nqueries] [-s src_addr] \
+[-t tos]\n\t[-w waittime] host [packetlen]\n",
            prog);
        exit(1);
 }