FIREWALK whitepaper (html)
0e10907a888800226aea0c276cc32b23d2a3a2253b0a92f0ba8c6c98f89e5fb0<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<TITLE>Firewalk</TITLE>
</HEAD>
<B><FONT FACE="Arial" SIZE=4><P ALIGN="RIGHT"><A NAME="_Toc433119204"><A NAME="_Toc433604117"><IMG SRC="CTP_logo.gif"></A></A></P>
<P ALIGN="CENTER"> </P>
<P ALIGN="CENTER"><A NAME="_Toc433119205"><A NAME="_Toc433604118">Firewalking</A></A></P>
</B></FONT><FONT FACE="Arial"><P ALIGN="CENTER"><A NAME="_Toc433119206"><A NAME="_Toc433604119">A Traceroute-Like Analysis of IP Packet Responses to Determine Gateway Access Control Lists</A></A></P>
</FONT><FONT SIZE=2><P> </P>
<P> </P>
<P> </P>
<P> </P>
<P> </P>
<P> </P>
</FONT><B><P ALIGN="RIGHT">Cambridge Technology Partners'</P>
<P ALIGN="RIGHT">Enterprise Security Services</P>
<P ALIGN="RIGHT"> </P>
<P ALIGN="RIGHT"> </P>
<P ALIGN="RIGHT"> </P>
<P ALIGN="RIGHT">David Goldsmith</P>
<P ALIGN="RIGHT">Senior Security Architect</P>
</B><P ALIGN="RIGHT"><A HREF="mailto:dhg@es2.net">dhg@es2.net</A></P>
<P ALIGN="RIGHT"> </P>
<B><P ALIGN="RIGHT">Michael Schiffman</P>
<P ALIGN="RIGHT">Senior Security Architect</P>
</B><P ALIGN="RIGHT"><A HREF="mailto:mds@es2.net">mds@es2.net</A></P>
<P ALIGN="RIGHT"> </P>
<P ALIGN="CENTER"> </P>
<P ALIGN="RIGHT"> </P>
<P ALIGN="RIGHT"> </P>
<I><P ALIGN="RIGHT">October 1998</P>
</I><FONT SIZE=2><P> </P>
<P> </P>
<P> </P>
<P> </P>
<P> </P>
<P> </P>
<P ALIGN="CENTER">Contents of this document are Copyright © 1998 Cambridge Technology Partners Enterprise Security Services, Inc. Distribution is unlimited under the condition that due credit is given and no fee is charged.</P>
<P ALIGN="CENTER"></FONT><A HREF="http://www.es2.net/"><FONT SIZE=2>http://www.es2.net</FONT></A></P>
<FONT SIZE=2><P> ESS is a division of Cambridge Technology Partners, Inc.</P>
<P> </P>
<hr>
</FONT><B><FONT SIZE=4><P>Table Of Contents</P>
</B></FONT><FONT SIZE=2><P><DIR>
<P></FONT>i. <A HREF="#_Toc433604120">Terminology</A></P>
<FONT SIZE=2><P>ii. </FONT><A HREF="#_Toc433604121">A note about examples</A></P>
<P> </P>
<FONT SIZE=2><P>I. </FONT><A HREF="#_Toc433604122">Introduction</A></P>
<FONT SIZE=2><P>II. </FONT><A HREF="#_Toc433604123">Traceroute</A></P>
<FONT SIZE=2><P>III.</FONT><A HREF="#_Toc433604124">Information gathering using traceroute</A></P>
<FONT SIZE=2><P>IV. </FONT><A HREF="#_Toc433604125">Firewalking</A></P>
<FONT SIZE=2><P>V. </FONT><A HREF="#_Toc433604126">Firewalk the tool</A></P>
<FONT SIZE=2><P>VI. </FONT><A HREF="#_Toc433604127">Risk Mitigation</A></P>
<FONT SIZE=2></DIR>
</P>
<hr>
<A NAME="_Toc433604120"></FONT><B><FONT FACE="Arial">i. Terminology</A></B>
</FONT><FONT SIZE=2><P> </P></FONT>
<TABLE CELLSPACING=0 BORDER=0 CELLPADDING=7 WIDTH=619>
<TR><TD WIDTH="38%" VALIGN="TOP">
<FONT SIZE=2><P>ACL</FONT></TD>
<TD WIDTH="62%" VALIGN="TOP">
<FONT SIZE=2><P>Access Control List. A set of rules that enforce a security policy. In the scope of this paper, an Access Control List will solely apply to network policy.</FONT></TD>
</TR>
<TR><TD WIDTH="38%" VALIGN="TOP">
<FONT SIZE=2><P>Router/Gateway</FONT></TD>
<TD WIDTH="62%" VALIGN="TOP">
<FONT SIZE=2><P>Used interchangeably. In the scope of this report, they refer to a multi-homed host that is configured to forward IP datagrams. It may or may not have a packet filtering ACL in place that denies some network traffic.</FONT></TD>
</TR>
<TR><TD WIDTH="38%" VALIGN="TOP">
<FONT SIZE=2><P>Ingress traffic</FONT></TD>
<TD WIDTH="62%" VALIGN="TOP">
<FONT SIZE=2><P>Describes network traffic that originates from the outside of a network perimeter and progresses towards the inside.</FONT></TD>
</TR>
<TR><TD WIDTH="38%" VALIGN="TOP">
<FONT SIZE=2><P>Egress traffic</FONT></TD>
<TD WIDTH="62%" VALIGN="TOP">
<FONT SIZE=2><P>Describes network traffic that originates from the inside of a network perimeter and progresses towards the outside.</FONT></TD>
</TR>
<TR><TD WIDTH="38%" VALIGN="TOP">
<FONT SIZE=2><P>Firewall</FONT></TD>
<TD WIDTH="62%" VALIGN="TOP">
<FONT SIZE=2><P>Refers to a multi-homed host configured to forward IP datagrams which uses a packet filtering ACL to control network traffic.</FONT></TD>
</TR>
</TABLE>
<FONT SIZE=2><P> </P>
<A NAME="_Toc433604121"></FONT><B><FONT FACE="Arial">ii. A note about examples</A></B>
</FONT><FONT SIZE=2><P></P>
<P>There are several sample traceroute dumps used in this report. The astute reader will note that the IP addresses are RFC 1918 <A HREF="#REFER1">[1]</A> compliant non-routable internal network addresses. The empirical data and traceroute dumps are taken directly from live Internet hosts, and in order to protect their identity, we have changed the addresses to anonymize the machines and networks involved.</P>
<P>
<P>
<P>
<hr>
<A NAME="_Toc433604122"></FONT><B><FONT FACE="Arial">I. Introduction</A></LI></B>
</FONT><FONT SIZE=2><P> </P>
<P>This paper describes Firewalking, a technique that can be used to gather information about a remote network protected by a firewall. The purpose of the paper is to examine the risks that this technique represents. This paper is intended for a technical audience with an advanced understanding of network infrastructure and TCP/IP packet structures.</P>
<P>Firewalking uses a traceroute-like IP packet analysis to determine whether or not a particular packet can pass from the attacker’s host to a destination host through a packet-filtering device. This technique can be used to map ‘open’ or ‘pass through’ ports on a gateway. More over, it can determine whether packets with various control information can pass through a given gateway. Also, using this technique, an attacker can map routers behind a packet-filtering device. To fully understand how this technique works, we first need to understand how traceroute works. This paper provides an introduction to traceroute.</P>
<P> </P>
</FONT><FONT FACE="Arial"><B><P><A NAME="_Toc433604123">II. Traceroute</A></P></B>
</FONT><FONT SIZE=2><P> </P>
<P>Traceroute <A HREF="#REFER2">[2]</A> is a network debugging utility designed to map out all hosts en route to a particular destination. Traceroute works by sending UDP or ICMP echo (ping) packets to a destination host and monotonically increasing the time to live (TTL) field in the IP header each successive round (by default, a round consists of three packets or probes). If the traceroute scan is done using UDP the destination port will be incremented with each probe sent.</P>
<P>The IP TTL field is used to limit the lifetime of datagrams across the Internet and is decremented just before a router forwards a packet. If this reduction would cause the TTL to be 0 or less, the router in question will send back an ICMP error message (time to live exceeded in transit) to the original host. This lets the original host know at which router the packet expired. By starting the TTL at one, routers between two given hosts can be found by increasing the TTL and monitoring the ICMP responses (provided there isn't any prohibitive filtering or any severe packet loss). To ensure that it gets a proper response from the ultimate destination host (an ICMP port unreachable or an ICMP echo reply) traceroute will either pick a high UDP port that is unlikely to be used by any application or use ping packets.</P>
<P> </P>
</FONT><FONT FACE="Arial"><B><P><A NAME="_Toc433604124">III. Information gathering using traceroute</A></P></B>
</FONT><FONT SIZE=2><P> </P>
<P>With an understanding of how traceroute works, we can now explore how this can this be used to leverage information about a particular network. This section will demonstrate two different ways of using traceroute to do some network reconnaissance. These following examples are contrived to show specific situations that may or may not be commonplace.</P>
</FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P><FONT FACE="Symbol">·</FONT>
<B> Protocol subterfuge</P></B>
</FONT><FONT SIZE=2><P> </P>
<P>The first scenario involves a network protected by a firewall that is blocking all ingress traffic except for ping and ping responses (ICMP types 8 and 0 respectively). We can use the stock traceroute program to show us what hosts are behind this filter (which is presumably against the security policy). Instead of the default behavior of using UDP (<I>Figure 1</I>), we want to force traceroute to use ICMP packets (<I>Figure 2</I>). Notice that this time we are able to view hosts behind the firewall.</P>
<P> </P></FONT>
<P ALIGN="CENTER"><CENTER><TABLE BORDER CELLSPACING=1 CELLPADDING=7 WIDTH=429>
<TR><TD VALIGN="TOP" HEIGHT=164>
<FONT FACE="Courier" SIZE=1><P>zuul:~>traceroute 10.0.0.10</P>
<P>traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets</P>
<P> 1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms</P>
<P> 2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms</P>
<P> 3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms</P>
<P> 4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms</P>
<P> 5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms</P>
<P> 6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms</P>
<P> 7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms</P>
<P> 8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms</P>
<P> 9 * * *</P>
<P>10 * * *</FONT></TD>
</TR>
</TABLE>
</CENTER></P>
<FONT FACE="Courier" SIZE=1><P> </P>
</FONT><B><FONT FACE="Courier" SIZE=2><P ALIGN="CENTER">Figure 1</P>
</B></FONT><FONT SIZE=2><P> </P></FONT>
<P ALIGN="CENTER"><CENTER><TABLE BORDER CELLSPACING=1 CELLPADDING=7 WIDTH=429>
<TR><TD VALIGN="TOP" HEIGHT=148>
<FONT FACE="Courier" SIZE=1><P>zuul:~>traceroute –I 10.0.0.10</P>
<P>traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets</P>
<P> 1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms</P>
<P> 2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms</P>
<P> 3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms</P>
<P> 4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms</P>
<P> 5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms</P>
<P> 6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms</P>
<P> 7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms</P>
<P> 8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms</P>
<P> 9 10.0.0.9 (10.0.0.9) 94.127 ms 81.764 ms 96.476 ms</P>
<P> 10 10.0.0.10 (10.0.0.10) 96.012 ms 98.224 ms 99.312 ms</FONT></TD>
</TR>
</TABLE>
</CENTER></P>
<FONT FACE="Courier" SIZE=1><P> </P>
</FONT><B><FONT FACE="Courier" SIZE=2><P ALIGN="CENTER">Figure 2</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P><FONT FACE="Symbol">·</FONT>
<B> Nascent port seeding</P></B>
</FONT><FONT SIZE=2><P> </P>
<P>The second scenario involves a more common example of a network protected by a firewall which blocks all ingress traffic except for UDP port 53 (Domain Name Service or DNS). </P>
<P> </P></FONT>
<P ALIGN="CENTER"><CENTER><TABLE BORDER CELLSPACING=1 CELLPADDING=7 WIDTH=429>
<TR><TD VALIGN="TOP" HEIGHT=164>
<FONT FACE="Courier" SIZE=1><P>zuul:~>traceroute 10.0.0.10</P>
<P>traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets</P>
<P> 1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms</P>
<P> 2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms</P>
<P> 3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms</P>
<P> 4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms</P>
<P> 5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms</P>
<P> 6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms</P>
<P> 7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms</P>
<P> 8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms</P>
<P> 9 * * *</P>
<P>10 * * *</FONT></TD>
</TR>
</TABLE>
</CENTER></P>
<FONT FACE="Courier" SIZE=1><P> </P>
</FONT><B><FONT FACE="Courier" SIZE=2><P ALIGN="CENTER">Figure 3</P>
</B></FONT><FONT SIZE=2><P> </P>
<P>As you can see from figure 3, the traceroute scan is blocked at the 8<SUP>th</SUP> hop because no traffic is allowed entrance into the network except for DNS queries. Armed with this knowledge, we can easily map hosts behind the gateway.</P>
<P>We can control the following:</P>
<UL>
<LI>The starting source port of the traceroute (which, by default, increases monotonically as each probe is sent).</LI>
<LI>The number of probes sent each round (by default this is 3).</LI></UL>
<P>We can determine the following:</P>
<UL>
<LI>The number of hops in between our attacking host and the target firewall.</LI></UL>
<P>This information allows us to deterministically control the port number of the probe that will reach the firewall. Due to the fact that the firewall does no content analysis, we can fool it into thinking our packets are DNS queries, and therefore, we can bypass the ACL. We simply begin our scan with a starting port number of:</P>
<DIR>
<DIR>
<DIR>
</FONT><B><FONT FACE="Courier"><P ALIGN="CENTER">(target_port - (number_of_hops * num_of_probes)) - 1</P>
</B></FONT><FONT SIZE=2></DIR>
</DIR>
</DIR>
</DIR>
<P>If you are more then (target_port - 1) number of hops from your destination this method obviously will not work. For our above example this gives us:</P>
<DIR>
<DIR>
<DIR>
</FONT><B><FONT FACE="Courier"><P ALIGN="CENTER">(53 - (8 * 3)) - 1 = 28</P>
</B></FONT><FONT SIZE=2></DIR>
</DIR>
</DIR>
</DIR>
<P>The probe that reaches the filter will have an acceptable port number as dictated by the firewall’s ACL and will be allowed to pass unmolested (<I>Figure 4</I>).</P>
<P> </P></FONT>
<P ALIGN="CENTER"><CENTER><TABLE BORDER CELLSPACING=1 CELLPADDING=7 WIDTH=430>
<TR><TD VALIGN="TOP" HEIGHT=172>
</FONT><FONT FACE="Courier" SIZE=1><P>zuul:~>traceroute -p28 10.0.0.10</P>
<P>traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets</P>
<P> 1 10.0.0.1 (10.0.0.1) 0.501 ms 0.399 ms 0.395 ms</P>
<P> 2 10.0.0.2 (10.0.0.2) 2.433 ms 2.940 ms 2.481 ms</P>
<P> 3 10.0.0.3 (10.0.0.3) 4.790 ms 4.830 ms 4.885 ms</P>
<P> 4 10.0.0.4 (10.0.0.4) 5.196 ms 5.127 ms 4.733 ms</P>
<P> 5 10.0.0.5 (10.0.0.5) 5.650 ms 5.551 ms 6.165 ms</P>
<P> 6 10.0.0.6 (10.0.0.6) 7.820 ms 20.554 ms 19.525 ms</P>
<P> 7 10.0.0.7 (10.0.0.7) 88.552 ms 90.006 ms 93.447 ms</P>
<P> 8 10.0.0.8 (10.0.0.8) 92.009 ms 94.855 ms 88.122 ms</P>
<P> 9 10.0.0.9 (10.0.0.9) 101.163 ms * *</P>
<P>10 * * *</P>
</FONT><FONT SIZE=2><P></FONT></TD>
</TR>
</TABLE>
</CENTER></P>
<FONT SIZE=2><P></P>
</FONT><B><FONT FACE="Courier" SIZE=2><P ALIGN="CENTER">Figure 4</P>
</FONT></FONT>
<FONT SIZE=2>
<P>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 (<I>Figure 5</I>). 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.</P>
<P> </P></FONT>
<P ALIGN="CENTER"><CENTER><TABLE BORDER CELLSPACING=1 CELLPADDING=7 WIDTH=430>
<TR><TD VALIGN="TOP" HEIGHT=226>
<FONT FACE="Courier" SIZE=1><P>zuul:~>traceroute -S –p53 10.0.0.15</P>
<P>traceroute to 10.0.0.15 (10.0.0.15), 30 hops max, 40 byte packets</P>
<P> 1 10.0.0.1 (10.0.0.1) 0.516 ms 0.396 ms 0.390 ms</P>
<P> 2 10.0.0.2 (10.0.0.2) 2.516 ms 2.476 ms 2.431 ms</P>
<P> 3 10.0.0.3 (10.0.0.3) 5.060 ms 4.848 ms 4.721 ms</P>
<P> 4 10.0.0.4 (10.0.0.4) 5.019 ms 4.694 ms 4.973 ms</P>
<P> 5 10.0.0.5 (10.0.0.5) 6.097 ms 5.856 ms 6.002 ms</P>
<P> 6 10.0.0.6 (10.0.0.6) 19.257 ms 9.002 ms 21.797 ms</P>
<P> 7 10.0.0.7 (10.0.0.7) 84.753 ms * *</P>
<P> 8 10.0.0.8 (10.0.0.8) 96.864 ms 98.006 ms 95.491 ms</P>
<P> 9 10.0.0.9 (10.0.0.9) 94.300 ms * 96.549 ms</P>
<P>10 10.0.0.10 (10.0.0.10) 101.257 ms 107.164 ms 103.318 ms</P>
<P>11 10.0.0.11 (10.0.0.11) 102.847 ms 110.158 ms *</P>
<P>12 10.0.0.12 (10.0.0.12) 192.196 ms 185.265 ms *</P>
<P>13 10.0.0.13 (10.0.0.13) 168.151 ms 183.238 ms 183.458 ms</P>
<P>14 10.0.0.14 (10.0.0.14) 218.972 ms 209.388 ms 195.686 ms</P>
<P>15 10.0.0.15 (10.0.0.15) 236.102 ms 237.208 ms 230.185 ms</FONT></TD>
</TR>
</TABLE>
</CENTER></P>
<FONT FACE="Courier" SIZE=1>
</FONT><B><FONT FACE="Courier" SIZE=2><P ALIGN="CENTER">Figure 5</P>
</B></FONT><FONT SIZE=2>
<P> </P>
</FONT><FONT FACE="Arial" SIZE=2><P><FONT FACE="Symbol">·</FONT>
<B> Taking it a bit further</P></B>
</FONT><FONT SIZE=2><P> </P>
<P>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.</P>
<P> </P>
</FONT><FONT FACE="Courier New" SIZE=2>
<A NAME="_Toc433604125"></FONT><B><FONT FACE="Arial">IV. Firewalking</A></B>
</FONT><FONT SIZE=2>
<P>In order to use a gateway's response to gather information, we must know two pieces of information:</P>
<P><FONT FACE="Symbol">·</FONT>
The IP address of the last known gateway before the firewalling takes place </P>
<P><FONT FACE="Symbol">·</FONT>
The IP address of a host located behind the firewall.</P>
<P> </P>
<P>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 (<I>Figure 6</I>).</P>
<P><IMG SRC="Image2.gif"></P>
<P> </P>
<P> </P>
<P>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.</P>
</FONT><FONT FACE="Courier New" SIZE=2><P> </P>
</FONT><FONT SIZE=2>
<A NAME="_Toc433604126"></FONT><B><FONT FACE="Arial">V. Firewalk - The tool</A></B>
</FONT><FONT SIZE=2><P> </P>
<P>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.</P>
</FONT><FONT FACE="Arial" SIZE=2>
<P><FONT FACE="Symbol">·</FONT>
<B> Fire, walk with me where?</P></B>
</FONT><FONT SIZE=2>
<P>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.</P>
</FONT><FONT FACE="Arial" SIZE=2>
<P><FONT FACE="Symbol">·</FONT>
<B> 2 Phases</P></B>
</FONT><FONT SIZE=2>
<P>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.</P>
<P>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 (<I>Figure 7</I>).</P>
<P> </P></FONT>
<P ALIGN="CENTER"><CENTER><TABLE BORDER CELLSPACING=1 CELLPADDING=7 WIDTH=430>
<TR><TD VALIGN="TOP" HEIGHT=226>
<FONT FACE="Courier" SIZE=1><P>zuul:#firewalk -n -P1-8 –pTCP 10.0.0.5 10.0.0.20</P>
<P>Firewalking through 10.0.0.5 (towards 10.0.0.20) with a maximum of 25 hops.</P>
<P>Ramping up hopcounts to binding host...</P>
<P>probe: 1 TTL: 1 port 33434: <response from> [10.0.0.1]</P>
<P>probe: 2 TTL: 2 port 33434: <response from> [10.0.0.2]</P>
<P>probe: 3 TTL: 3 port 33434: <response from> [10.0.0.3]</P>
<P>probe: 4 TTL: 4 port 33434: <response from> [10.0.0.4]</P>
<P>probe: 5 TTL: 5 port 33434: Bound scan: 5 hops <Gateway at 5 hops> [10.0.0.5]</P>
<P> </P>
<P>port 1: open</P>
<P> </P>
<P>port 2: open</P>
<P> </P>
<P>port 3: open</P>
<P> </P>
<P>port 4: open</P>
<P> </P>
<P>port 5: open</P>
<P> </P>
<P>port 6: open</P>
<P> </P>
<P>port 7: *</P>
<P> </P>
<P>port 8: open</P>
<P> </P>
<P>13 packets sent, 12 replies received</FONT></TD>
</TR>
</TABLE>
</CENTER></P>
<FONT FACE="Courier" SIZE=1><P> </P>
</FONT><B><FONT FACE="Courier" SIZE=2><P ALIGN="CENTER">Figure 7</P>
</B></FONT><FONT SIZE=2>
</FONT><FONT FACE="Courier" SIZE=1>
</FONT><FONT FACE="Arial" SIZE=2><P><FONT FACE="Symbol">·</FONT>
<B> A Slow Walk</P></B>
</FONT><FONT SIZE=2><P>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 <I>extraneous loss</I>. 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 <I>different</I> gateway while en route to the target gateway (<I>see figure 8</I>)?</P>
<P> </P>
<P><IMG SRC="Image3.gif"></P>
<P> </P>
<P>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.</P>
<P>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.</P>
<P>More information about Firewalk (including the source) is available from </FONT><A HREF="http://www.es2.net/research/firewalk"><FONT SIZE=2>http://www.es2.net/research/firewalk</FONT></A><FONT SIZE=2>. </P>
</FONT><FONT FACE="Arial">
<B><A NAME="_Toc433604127">VI. Risk Mitigation</A></B>
</FONT><FONT SIZE=2>
<P>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 <A HREF="#REFER3">[3]</A>; 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. </P>
<P> </P>
<hr>
<P> </P>
</FONT><B><FONT FACE="Arial"><P>Appendix A. traceroute static port diff</P></B>
</FONT><FONT SIZE=2>
<P> 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:</P>
</FONT><FONT FACE="Courier" SIZE=1><P> </P>
<A HREF="traceroute.diff">ASCII traceroute.diff</A>.
<HR>
<PRE>
--- 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);
}
</PRE>
<HR>
</FONT><B><FONT FACE="Arial"><P>Appendix B. references</P></B>
</FONT><FONT SIZE=2>
</FONT><FONT SIZE=2><A NAME="REFER1"><LI></A>Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot and E. Lear, "Address Allocation for Private Internets" RFC1918, February 1996</LI>
<A NAME="REFER2"><LI></A>Van Jacobson, traceroute documentation and source code, Lawrence Berkeley National Laboratory</LI>
<A NAME="REFER3"><LI></A>Thomas H. Ptacek and Timothy Newsham, "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", Secure Networks, January 1998 </LI></OL>
</FONT></BODY>
</HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed