Firewalking________________________________________________________________________

A seminar on

Firewalking A network debugging tool

Presented byChinmayee.N

Roll number-764University seat number-2SD98CS080

Examiner ------------------------------------------------

S.D.M.C.E.T

1

Firewalking________________________________________________________________________

Contents1.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

2

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

3

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 attacker’s 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

4

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 WorksTraceroute 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

5

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 encounterSince 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

6

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 subterfugeThe 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

7

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:~>traceroute 10.0.0.10traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms9 * * *10 * * *

Figure 1

zuul:~>traceroute –I 10.0.0.10traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms9 10.0.0.9 (10.0.0.9) 94.127 ms 81.764 ms 96.476 ms10 10.0.0.10 (10.0.0.10) 96.012 ms 98.224 ms 99.312 ms

Figure 2 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). Figure 3

zuul:~>traceroute 10.0.0.10traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms2 10.0.0.2 (10.0.0.2) 2.455 ms 2.479 ms 2.512 ms3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ms 4.747 ms4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 ms 4.980 ms

S.D.M.C.E.T

8

Firewalking________________________________________________________________________

5 10.0.0.5 (10.0.0.5) 5.520 ms 5.809 ms 6.061 ms6 10.0.0.6 (10.0.0.6) 9.584 ms 21.754 ms 20.530 ms7 10.0.0.7 (10.0.0.7) 89.889 ms 79.719 ms 85.918 ms8 10.0.0.8 (10.0.0.8) 92.605 ms 80.361 ms 94.336 ms9 * * *

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)) - 1If 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 = 28The probe that reaches the filter will have an acceptable port number as dictated by the firewall’s ACL and will be allowed to pass (Figure 4).

zuul:~>traceroute -p28 10.0.0.10traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 40 byte packets1 10.0.0.1 (10.0.0.1) 0.501 ms 0.399 ms 0.395 ms2 10.0.0.2 (10.0.0.2) 2.433 ms 2.940 ms 2.481 ms3 10.0.0.3 (10.0.0.3) 4.790 ms 4.830 ms 4.885 ms4 10.0.0.4 (10.0.0.4) 5.196 ms 5.127 ms 4.733 ms5 10.0.0.5 (10.0.0.5) 5.650 ms 5.551 ms 6.165 ms6 10.0.0.6 (10.0.0.6) 7.820 ms 20.554 ms 19.525 ms7 10.0.0.7 (10.0.0.7) 88.552 ms 90.006 ms 93.447 ms8 10.0.0.8 (10.0.0.8) 92.009 ms 94.855 ms 88.122 ms9 10.0.0.9 (10.0.0.9) 101.163 ms * *10 * * *

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

S.D.M.C.E.T

9

Firewalking________________________________________________________________________

the fact that there might actually be something listening on the other end). See appendix A for the source code patch.

zuul:~>traceroute -S –p53 10.0.0.15traceroute to 10.0.0.15 (10.0.0.15), 30 hops max, 40 byte packets1 10.0.0.1 (10.0.0.1) 0.516 ms 0.396 ms 0.390 ms2 10.0.0.2 (10.0.0.2) 2.516 ms 2.476 ms 2.431 ms3 10.0.0.3 (10.0.0.3) 5.060 ms 4.848 ms 4.721 ms4 10.0.0.4 (10.0.0.4) 5.019 ms 4.694 ms 4.973 ms5 10.0.0.5 (10.0.0.5) 6.097 ms 5.856 ms 6.002 ms6 10.0.0.6 (10.0.0.6) 19.257 ms 9.002 ms 21.797 ms7 10.0.0.7 (10.0.0.7) 84.753 ms * *8 10.0.0.8 (10.0.0.8) 96.864 ms 98.006 ms 95.491 ms9 10.0.0.9 (10.0.0.9) 94.300 ms * 96.549 ms10 10.0.0.10 (10.0.0.10) 101.257 ms 107.164 ms 103.318 ms11 10.0.0.11 (10.0.0.11) 102.847 ms 110.158 ms *12 10.0.0.12 (10.0.0.12) 192.196 ms 185.265 ms *13 10.0.0.13 (10.0.0.13) 168.151 ms 183.238 ms 183.458 ms14 10.0.0.14 (10.0.0.14) 218.972 ms 209.388 ms 195.686 ms15 10.0.0.15 (10.0.0.15) 236.102 ms 237.208 ms 230.185 ms

Taking it a bit furtherSince 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

10

Firewalking________________________________________________________________________

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

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

S.D.M.C.E.T

11

Firewalking________________________________________________________________________

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

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

S.D.M.C.E.T

12

Firewalking________________________________________________________________________

zuul:#firewalk -n -P1-8 –pTCP 10.0.0.5 10.0.0.20Firewalking through 10.0.0.5 (towards 10.0.0.20) with a maximum of 25 hops.Ramping up hopcounts to binding host...Probe: 1 TTL: 1 port 33434: <response from> [10.0.0.1]Probe: 2 TTL: 2 port 33434: <response from> [10.0.0.2]Probe: 3 TTL: 3 port 33434: <response from> [10.0.0.3]Probe: 4 TTL: 4 port 33434: <response from> [10.0.0.4]Probe: 5 TTL: 5 port 33434: Bound scan: 5 hops <Gateway at 5 hops> [10.0.0.5]Port 1: openPort 2: openPort 3: openPort 4: openPort 5: openPort 6: openPort 7: *Port 8:open13 packets sent, 12 replies received

Port scanning techniquesOver 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 programs like synlogger are available to detect these scans. FIN packets, on the

S.D.M.C.E.T

13

Firewalking________________________________________________________________________

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 message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded.

S.D.M.C.E.T

14

Firewalking________________________________________________________________________

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

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 destination. This allows prevents false negatives due to intermediate filter blockage and allows firewalk to be more confident in its report.

S.D.M.C.E.T

15

Packet is dropped here instead of being dropped at target

hop n+m(m>1)Packet filter

hop 0 hop n

Figure 8

Packet filter

Destination host

Firewalking host

internet

Firewalking________________________________________________________________________

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.

S.D.M.C.E.T

16

Local network10.1.1.0/24

Remote Network207.136.89.0/24

SourceIP:10.1.1.13DestinationIP:207.136.89.15

SourceIP:207.136.89.15Destination IP:136.1.1.13

sourceIP:207.136.89.15destinationIP:10.1.1.13

sourceIP:136.1.1.13destiantionIP:207.136.89.15

NAT on Router

Firewalking________________________________________________________________________

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 intheir gateways and protect their networks from a stealthy and dangerous attack called firewalking.the administrators can also prevent their firewalls from firewalking throughproxy 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

17

Firewalking________________________________________________________________________

S.D.M.C.E.T

18