Firewalking________________________________________________________________________

A seminar on

Firewalking
A network debugging tool

Presented by
Chinmayee.N
Roll number-764
University seat number-2SD98CS080

Examiner

S.D.M.C.E.T

------------------------------------------------

Firewalking________________________________________________________________________

Contents
1.Abstract ----------------------------------------------------------------3
2.Introduction to Firewalking-----------------------------------------4
3.Firewalking-------------------------------------------------------------5
-Introduction to traceroutes
-Traceroute
-How traceroute works?
-problems you might encounter
-changing paths
-No sending messages
-buggy TCP/IP implementation
-Traceroute options
-Traceroute Techniques----------------------------------------------------------7
-protocol subterfuge
-Nascent port seeding
4.Firewalking Technique--------------------------------------------------------11
-Firewalk the tool
-Port scanning techniques
TCP connect() scanning
TCP SYN scanning
TCP FIN scanning
Fragmentation scanning
FTP bounce attack
TCP reverse ident scanning
UDP ICMP port unreachable scanning
ICMP echo scanning
UDP recvfrom() and write() scanning

-A slow walk

5.Fighting back Firewalking-----------------------------------------16

6.Conclusion-------------------------------------------------------------17
7.Bibliography----------------------------------------------------------17

S.D.M.C.E.T

Firewalking________________________________________________________________________

Abstract
Firewalking is a network debugging tool that can be used for knowing the vulnerability
of the firewall that protects our network .The technique can prove harmful if it is used by
a hacker.Firewalking needs two IP addresses, the IP address of the firewall or gateway
and the Ip address of a host behind the firewall.TTL ramping is done using traceroutes to
find the exact value of TTL field that makes the packet expire and generates a
response.Firewalking uses port scanning for detecting open ports on the firewall.
To understand the firewalking technique we need to understand the traceroute
technique.Traceroute is useful to detect the path a packet takes to the destination.
It does TTL ramping to achieve its goal.
Traceroute uses the following techniques
Protocol subterfuge
Nascent port seeding
There are also port scanning techniques used,they are
TCP connect() scanning
TCP SYN scanning
TCP FIN scanning
Fragmentation scanning
FTP bounce attack
TCP reverse ident scanning
UDP ICMP port unreachable scanning
ICMP echo scanning
UDP recvfrom() and write() scanning
Slow walk is a technique that is used to make firewalking work properly in case if the
packets are dropped for reasons other than rejection from firewall.
We can fight back firewalking by using friewalls with NAT and proxy servers for each
application.
The seminar is a an eye opener for system administrators ,it can help them to protect
their firewall from a stealthy dangerous attack called firewalking.

S.D.M.C.E.T

Firewalking________________________________________________________________________

Introduction to Firewalking
When we come across the term firewalking the following questions are obvious to us.
What is firewalking?
Firewalking is a network debugging technique that can help us know the vulnerability of
the firewall that protects our network.
Why is it important to know about firewalking?
It is a technique for detecting vulnerability of the firewall,hence it can be dangerous if the
firewalking technique is used by a hacker.It is important mainly because it is difficult to
detect if the hacker is using this technique to know the firewall vulnerability.
On the other hand its quite a useful technique that can help us know ,how strong our
firewall is.
A brief idea of the technique
Basically firewalking uses a traceroute-like IP packet analysis to determine whether or
not a particular packet can pass from the attackers host to a destination host through a
packet-filtering device. This technique can be used to know 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.

S.D.M.C.E.T

Firewalking________________________________________________________________________

Firewalking
Firewalking as mentioned is a network debugging tool.It can be used by system
administrators as well as hackers.It basically does TTL ramping using traceroute
to find out the exact TTL value required to probe a host beyond the firewall or
gateway and can determine the exact network map by continuing this way.There r
several ways to use traceroutes.Next it performs port scanning to know which
ports are open on the gateway.Again there are many techniques for port scanning.
Since the gateway does not perform content analysis it can be easily fooled.For a
better understanding we should first understand the technique of traceroute.

An introduction to traceroutes
TraceRoute
``Traceroute'' is a network debugging utility that attempts to trace the path a packet takes
through the network - its route. A key word here is ``attempts'' - by no means does
traceroute work in all cases.
If you've been paying attention, you already know that the only facilities TCP/IP provide
for tracing packet routes are IP packet options (record route and its variants) that are
poorly specified, rarely implemented in a useful way, and often disabled for security
reasons. Traceroute does not depend on any of these facilities. Traceroute, to put it
simply, is a hack.
How Traceroute Works
Traceroute transmits packets with small TTL values. The TTL (Time To Live) is an IP
header field that is designed to prevent packets from running in loops. Every router that
handles a packet subtracts one from the packet's TTL. If the TTL reaches zero, the packet
has expired and is discarded.
Traceroute depends on the common router practice of sending an ICMP Time Exceeded
message, back to the sender when this occurs. By using small TTL values which quickly
expire, traceroute causes routers along a packet's normal delivery path to generate these
ICMP messages which identify the router. A TTL value of one should produce a message
from the first router; a TTL value of two generates a message from the second; etc.
+--------+
+--------+
| SENDER |
| TARGET |
+--------+
+--------+
|
^|
[============( Router )=====( Router )=====( Router )==|====]
^
^
^
|
| TTL=1
| TTL=2
| TTL=3
| TTL=4
Traceroute
|
|
|
|
shows these -----+--------------+--------------+------------/
IP addresses

S.D.M.C.E.T

Firewalking________________________________________________________________________

In a typical traceroute session, a group of packets with TTL=1 are sent. A single router
should respond, using the IP address of the interface it transmits the ICMP Timeout
messages on, which should be the same as the interface it received the original packets
on. The user is told this IP address. Also, round trip times are reported for each packet in
the group. Traceroute reports any additional ICMP messages (such as destination
unreachables) using a rather cryptic syntax - !N means network unreachable, !H means
host unreachable, etc. Once this first group of packets has been processed (this can take
10 seconds or no time at all), the second group (TTL=2) begins transmitting, and the
whole process repeats.
Problems you might encounter
Since TCP/IP was not designed to support traceroute, several kinds of problems might
arise.
Changing paths
Always remember - you are not tracing the path of one packet, but of many.
Hopefully, all those packets will follow the same route, but this is by no means
assured. What if a link fails during the traceroute? Your packets may be rerouted, and
traceroute's output becomes a confused combination of two separate routes.
No sending addresses
You only see one IP address from each router - the address closest to you. To put it
another way, traceroute can't tell you which interfaces routers are sending the packets
on. It only shows the interfaces packets are being received on. The sending interfaces
can often be deduced by matching each router with the next one in line - typically
only one interface could be used between them.
Routing problems
TCP/IP's sinister and ubiquitous routing problems may cause the router not to have a
route back to the sender, or to have a route through some interface other than the one
it received the packet on. In these cases, you will either receive no reply at all (no
route), or a reply showing an IP address that never handled the original packet (it was
handled by some other interface on the same router). In short, don't completely trust
traceroute.
Buggy TCP/IP implementations
Traceroute depends on a rather obscure feature that often doesn't work correctly.
Some of the problems people have found: code that fails to decrement TTL, code that
incorrectly forwards packets with zero TTL, code that does not generate ICMP
Timeouts, and code that sends ICMPs with the same TTL as the original packet. This
last problem, of course, results in our ICMP Timeouts being sent with zero TTL guaranteed not to make it back to us.

S.D.M.C.E.T

Firewalking________________________________________________________________________

Traceroute options -Here's a list of common traceroute options:

-m max-ttl
At some TTL value, traceroute expects to get a reply from the target host. Of course,
if the host is unreachable for some reason, this may never happen, so max-ttl (default
30) sets a limit on how long traceroute keeps trying.
-n
Numerical output only. Use this if you're having nameserver problems and traceroute
hangs trying to do inverse DNS lookups.
-p port
Base UDP port. The packets traceroute sends are UDP packets targeted at strange port
numbers that nothing will be listening on (we hope). The target host should therefore
ignore the packets after generating port unreachable messages. Port is the UDP port
number that traceroute uses on its first packet, and increments by one for each
subsequent packet
-q queries
How many packets should be sent for each TTL value. The default is 3, which is fine
for finding out the route.
-w wait
Wait is the number of seconds packets have to generate replies before traceroute
assumes they never will and moves on. The default is 3. This should be more if
pings to the target host show round trip times longer than this.

Traceroute techniques
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.
Protocol subterfuge
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).

S.D.M.C.E.T

Firewalking________________________________________________________________________

Instead of the default behavior of using UDP (Figure 1), we want to force traceroute to
use ICMP packets (Figure 2). Notice that this time we are able to view hosts behind the
firewall.
zuul:~>traceroute10.0.0.10
tracerouteto10.0.0.10(10.0.0.10),30hopsmax,40
bytepackets
110.0.0.1(10.0.0.1)0.540ms0.394ms0.397ms
210.0.0.2(10.0.0.2)2.455ms2.479ms2.512ms
310.0.0.3(10.0.0.3)4.812ms4.780ms4.747ms
410.0.0.4(10.0.0.4)5.010ms4.903ms4.980ms
510.0.0.5(10.0.0.5)5.520ms5.809ms6.061ms
610.0.0.6(10.0.0.6)9.584ms21.754ms20.530ms
710.0.0.7(10.0.0.7)89.889ms79.719ms85.918ms
810.0.0.8(10.0.0.8)92.605ms80.361ms94.336ms
9***
10***
Figure1
zuul:~>tracerouteI10.0.0.10
tracerouteto10.0.0.10(10.0.0.10),30hopsmax,40
bytepackets
110.0.0.1(10.0.0.1)0.540ms0.394ms0.397ms
210.0.0.2(10.0.0.2)2.455ms2.479ms2.512ms
310.0.0.3(10.0.0.3)4.812ms4.780ms4.747ms
410.0.0.4(10.0.0.4)5.010ms4.903ms4.980ms
510.0.0.5(10.0.0.5)5.520ms5.809ms6.061ms
610.0.0.6(10.0.0.6)9.584ms21.754ms20.530ms
710.0.0.7(10.0.0.7)89.889ms79.719ms85.918ms
810.0.0.8(10.0.0.8)92.605ms80.361ms94.336ms
910.0.0.9(10.0.0.9)94.127ms81.764ms96.476ms
1010.0.0.10(10.0.0.10)96.012ms98.224ms99.312ms
Figure2
Nascent port seeding

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).
Figure3

S.D.M.C.E.T

Firewalking________________________________________________________________________

zuul:~>traceroute10.0.0.10
tracerouteto10.0.0.10(10.0.0.10),30hopsmax,40byte
packets
110.0.0.1(10.0.0.1)0.540ms0.394ms0.397ms
210.0.0.2(10.0.0.2)2.455ms2.479ms2.512ms
310.0.0.3(10.0.0.3)4.812ms4.780ms4.747ms
410.0.0.4(10.0.0.4)5.010ms4.903ms4.980ms
510.0.0.5(10.0.0.5)5.520ms5.809ms6.061ms
610.0.0.6(10.0.0.6)9.584ms21.754ms20.530ms
710.0.0.7(10.0.0.7)89.889ms79.719ms85.918ms
810.0.0.8(10.0.0.8)92.605ms80.361ms94.336ms
9***
As you can see from figure 3, the traceroute scan is blocked at the 8th 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.
We can control the following:
The starting source port of the traceroute (which, by default, increases
monotonically as each probe is sent).
The number of probes sent each round (by default this is 3).
The number of hops in between our attacking host and the target firewall.
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:
(target_port(number_of_hops*num_of_probes))1
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:
(53(8*3))1=28
The probe that reaches the filter will have an acceptable port number as dictated by the
firewalls ACL and will be allowed to pass (Figure 4).
zuul:~>traceroutep2810.0.0.10
tracerouteto10.0.0.10(10.0.0.10),30hopsmax,40
bytepackets
110.0.0.1(10.0.0.1)0.501ms0.399ms0.395ms
210.0.0.2(10.0.0.2)2.433ms2.940ms2.481ms
310.0.0.3(10.0.0.3)4.790ms4.830ms4.885ms
410.0.0.4(10.0.0.4)5.196ms5.127ms4.733ms
510.0.0.5(10.0.0.5)5.650ms5.551ms6.165ms
610.0.0.6(10.0.0.6)7.820ms20.554ms19.525ms
710.0.0.7(10.0.0.7)88.552ms90.006ms93.447ms
810.0.0.8(10.0.0.8)92.009ms94.855ms88.122ms
910.0.0.9(10.0.0.9)101.163ms**
10***
S.D.M.C.E.T

Firewalking________________________________________________________________________

10

Figure4
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 firewalls 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.
zuul:~>tracerouteSp5310.0.0.15
tracerouteto10.0.0.15(10.0.0.15),30hopsmax,40byte
packets
110.0.0.1(10.0.0.1)0.516ms0.396ms0.390ms
210.0.0.2(10.0.0.2)2.516ms2.476ms2.431ms
310.0.0.3(10.0.0.3)5.060ms4.848ms4.721ms
410.0.0.4(10.0.0.4)5.019ms4.694ms4.973ms
510.0.0.5(10.0.0.5)6.097ms5.856ms6.002ms
610.0.0.6(10.0.0.6)19.257ms9.002ms21.797ms
710.0.0.7(10.0.0.7)84.753ms**
810.0.0.8(10.0.0.8)96.864ms98.006ms95.491ms
910.0.0.9(10.0.0.9)94.300ms*96.549ms
1010.0.0.10(10.0.0.10)101.257ms107.164ms103.318ms
1110.0.0.11(10.0.0.11)102.847ms110.158ms*
1210.0.0.12(10.0.0.12)192.196ms185.265ms*
1310.0.0.13(10.0.0.13)168.151ms183.238ms183.458ms
1410.0.0.14(10.0.0.14)218.972ms209.388ms195.686ms
1510.0.0.15(10.0.0.15)236.102ms237.208ms230.185ms
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.

S.D.M.C.E.T

Firewalking________________________________________________________________________

11

Firewalking Technique
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
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

S.D.M.C.E.T

Firewalking________________________________________________________________________

12

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 networks topology.
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 networks topology.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 networks topology.

Firewalk - The tool

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.
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 dont, 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 doesnt,
the port is considered closed .

S.D.M.C.E.T

Firewalking________________________________________________________________________

13

zuul:#firewalknP18pTCP10.0.0.510.0.0.20
Firewalkingthrough10.0.0.5(towards10.0.0.20)withamaximumof25hops.
Rampinguphopcountstobindinghost...
Probe:1TTL:1port33434:<responsefrom>[10.0.0.1]
Probe:2TTL:2port33434:<responsefrom>[10.0.0.2]
Probe:3TTL:3port33434:<responsefrom>[10.0.0.3]
Probe:4TTL:4port33434:<responsefrom>[10.0.0.4]
Probe:5TTL:5port33434:Boundscan:5hops<Gatewayat5hops>[10.0.0.5]
Port1:open
Port2:open
Port3:open
Port4:open
Port5:open
Port6:open
Port7:*
Port8:open
13packetssent,12repliesreceived

Port scanning techniques

Over time, a number of techniques have been developed for surveying the protocols and
ports on which a target machine is listening. They all offer different benefits and
problems. Here is a line up of the most common:
TCP connect() scanning,TCP SYN scanning, TCP FIN scanning,

Fragmentation scanning,TCP reverse ident scanning,

UDP ICMP port unreachable scanning,UDP recvfrom() and write() scanning,
and finally ICMP echo scanning

TCP connect() scanning : This is the most basic form of TCP scanning. The
connect() system call provided by your operating system is used to open a
connection to every interesting port on the machine. If the port is listening,
connect() will succeed, otherwise the port isn't reachable. One strong advantage to
this technique is that you don't need any special privileges. Any user on most
UNIX boxes is free to use this call. Another advantage is speed.

TCP SYN scanning : This technique is often referred to as "half-open" scanning,

because you don't open a full TCP connection. You send a SYN packet, as if you
are going to open a real connection and wait for a response. A SYN|ACK
indicates the port is listening. A RST is indicative of a non- listener. If a SYN|
ACK is received, you immediately send a RST to tear down the connection
(actually the kernel does this for us). The primary advantage to this scanning
technique is that fewer sites will log it. Unfortunately we need root privileges to
build these custom SYN packets.

TCP FIN scanning : There are times when even SYN scanning isn't clandestine
enough. Some firewalls and packet filters watch for SYNs to restricted ports, and

S.D.M.C.E.T

Firewalking________________________________________________________________________

14

programs like synlogger are available to detect these scans. FIN packets, on the
other hand, may be able to pass through . The idea is that closed ports tend to
reply to your FIN packet with the proper RST. Open ports, on the other hand, tend
to ignore the packet in question. This is required TCP behavior

Fragmentation scanning : This is not a new scanning method in and of itself, but
a modification of other techniques. Instead of just sending the probe packet, you
break it into a couple of small IP fragments. You are splitting up the TCP header
over several packets to make it harder for packet filters and so forth to detect what
you are doing. But we have to be careful as Some programs have trouble handling
these tiny packets.

TCP reverse ident scanning : The ident protocol (rfc1413) allows for the
disclosure of the username of the owner of any process connected via TCP, even if
that process didn't initiate the connection. So you can, for example, connect to the
http port and then use identd to find out whether the server is running as root. This
can only be done with a full TCP connection to the target port

FTP bounce attack : An interesting "feature" of the ftp protocol (RFC 959) is
support for "proxy" ftp connections. In other words, I should be able to connect
from evil.com to the FTP server-PI (protocol interpreter) of target.com to establish
the control communication connection. Then I should be able to request that the
server-PI initiate an active server-DTP (data transfer process) to send a file
ANYWHERE on the internet! Presumably to a User-DTP, although the RFC
specifically states that asking one server to send a file to another is OK. Now this
may have worked well in 1985 when the RFC was just written. But nowadays, we
can't have people hijacking ftp servers and requesting that data be spit out to
arbitrary points on the internet. This protocol flaw "can be used to post virtually
untraceable mail and news, hammer on servers at various sites, fill up disks, try to
hop firewalls, and generally be annoying and hard to track down at the same time.

UDP ICMP port unreachable scanning : This scanning method varies from the
above in that we are using the UDP protocol instead of TCP. While this protocol is
simpler, scanning it is actually significantly more difficult. This is because open
ports don't have to send an acknowledgement in response to our probe, and closed
ports aren't even required to send an error packet. Fortunately, most hosts do send
an ICMP_PORT_UNREACH error when you send a packet to a closed UDP port.
Thus you can find out if a port is NOT open, and by exclusion determine which
ports which are. Neither UDP packets, nor the ICMP errors are guaranteed to
arrive, so UDP scanners of this sort must also implement retransmission of
packets that appear to be lost (or you will get a bunch of false positives). Also,
this scanning technique is slow for machines that limit ICMP error message rate.
For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable

S.D.M.C.E.T

Firewalking________________________________________________________________________

15

message generation to 80 per 4 seconds, with a 1/4 second penalty if that is

exceeded.

UDP recvfrom() and write() scanning : While non-root users can't read port
unreachable errors directly, Linux is cool enough to inform the user indirectly
when they have been received. For example a second write() call to a closed port
will usually fail. Recvfrom() on non-blocking UDP sockets usually return
EAGAIN ("Try Again", errno 13) if the ICMP error hasn't been received, and
ECONNREFUSED ("Connection refused", errno 111) if it has.

ICMP echo scanning : It is sometimes useful to determine what hosts in a

network are up by pinging them all.

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
internet

Firewalking host

Packet filter
Destination host

Packet is dropped here instead of

being dropped at target

hop 0

Packet filter

hop n

hop n+m(m>1)

Figure 8

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 misguiding. 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
S.D.M.C.E.T

Firewalking________________________________________________________________________

16

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.

Fighting back Firewalking

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; 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.
Firewalking can be prevented by implementing NAT(network address translation).the
router in case of NAT maintains a set of external or global IP addresses and a set of
internal IP addresses.whenever a packet arrives the external destination IP address is
mapped to internal address,the packet may be forwarded to any machine.Hence as
traceroute fails ,firewalking also fails.

NAT on Router

SourceIP:10.1.1.13
DestinationIP:207.136.89.15

Local
Localnetwork
network
10.1.1.0/24
10.1.1.0/24

S.D.M.C.E.T

sourceIP:207.136.89.15
destinationIP:10.1.1.13

sourceIP:136.1.1.13
destiantionIP:207.136.89.15

SourceIP:207.136.89.15
Destination IP:136.1.1.13

Remote
Remote
Network
Network
207.136.89.0/24
207.136.89.0/24

Firewalking________________________________________________________________________

17

Conclusion:
Thus we conclude that

Firewalking is in fact a very powerful tool to detect firewall vulnarability.

It is very useful technique that has led to the conclusion that the existing firewalls
need to be enhanced so as to withstand firewalking.
Its an added technique to the hackers list,of which system administrators should be
aware of.
And the most important fact is the discovery of a attack that belongs to the group of
stealthy attacks that are the most undetectable and dangerous of all attacks.

Thus it is necessary for system administrators to be aware of firewalking and make their
firewalls more secure.The administrators should prevent the firewalls by using NAT in
their gateways and protect their networks from a stealthy and dangerous attack called
firewalking.the administrators can also prevent their firewalls from firewalking through
proxy servers for each application.

Bibliography
Linux Firewalls- Robert L. Ziegler
Intrusion Detection-Network Security Beyond the Firewall-Terry Escamilla
Hacking Exposed
by Joel Scambray
Building Internet Firewalls (2nd Edition)
by Elizabeth D. Zwicky
Sites
www.packetfactory.net/Projects/Firewalk/firewalk-final.html
www.certcc.or.kr/paper/tr1998019.html
www.clug.in-chemnitz.de/vortraege/paranoia/node20.html

S.D.M.C.E.T

Firewalking________________________________________________________________________

S.D.M.C.E.T

18