Re: How to identify which firewall is blocking my request...

["ithilgore.ryu.L () gmail com" <ithilgore.ryu.l () gmail com>]

KKWonder wrote:
> It looks my previuos post was not accepted by the mailing-list, so I'm
> posting it again here... sorry...
>
> My application couldn't talk to the remote machine, it was timing out
> always, so I downloded a copy of nmap to check the port used by my
> application is blocked or not. So I ran it and found that the port is
> filtered. There are 4 firewalls present between my computer and remote
> machine... I need to identify which firewall is blocking my request, so that
> I can request the respective owner to open the port for me for a couple of
> hours. I looked at the nmap options, but I couldn't find the one which can
> solve my problem, could someone help me to get options I should try to
> identify blocking firewall.
>
> Thanks for your help. 
>
>
>   

There is no reliable method to do what you ask, but there is a 
possibility to partially
infer some things by induction:

Firstly, I would try using traceroute - that would give you a rough idea 
of until which point
can your packets arrive unhindered. Keep in mind thought that packets 
don't necessarily travel
through the same route each time.

The second more precise method would be a custom program that would do 
the following:

Use the logic of traceroute but with tcp packets (instead of udp or icmp 
echo requests that
traceroute and tracert do accordingly). This means that you send tcp 
packets to the destination
port you want but with a TTL that begins with 2 and increases thereafter.

An example scenario would go like this:

1) First packets arrive at hosts that *allow* traffic to pass through - 
no need to pay any specific attention to them.

2) Packet arrives at first firewall (let's assume that the 1st firewall 
does *not* block the packet). Since the TTL
will have decreased to 1 by the time it reaches it, the packet will be 
discarded and an ICMP message will be sent
back to you: "ICMP type 11 (code 0) Time exceeded message". The network 
stack disassembles the packet down up - this
effectively means, that the first things it will check is the IP header, 
thus the TTL field which resides there. Consequently,
the destination port (that resides in the TCP header) will not be 
checked at this stage.

3) Now the packet arrives at the first firewall with a TTL of 2, which 
means that this time the TTL check will not fail
and the packet will not be rejected due to insufficient TTL. At this 
stage, any TCP filtering will take place. We
assumed that this firewall allows the packet to pass through, so the 
packet will be forwarded to the next router.

4) Consider that the next host that the packet will arrive is the second 
firewall and this one filters any packets
destined to port X, where X is the destination port in the TCP header of 
your packet. At this time, the TTL check
will take place, so you will get an ICMP message mentioning TTL exceeded.

5) Packet now arrives at second firewall with a TTL of 2. Since the 
destination port is blocked, you will get no
reply at this stage and your packet won't be able to be forwarded further.

6) Following the above logic, you can deduce that the last TTL exceeded 
ICMP message you get, is sent by the firewall
that actually blocks your requests. This, however, assumes that these 
type of messages aren't actually blocked as well.
In case they are, then you can assume either the first or the second 
firewall blocked your packets. If the first firewall
doesn't send any TTL exceeded ICMP message (due to its configuration), 
then you now have 3 possible hosts that might
be blocking your requests: host_before_1st_fw, first fw, second fw. It 
is quite obvious that this method relies exclusively
on the potential of ICMP type 11 (code 0) messages to get back to you, 
in order to work.

A program implementing the above logic is fairly easy to code: Some raw 
packet creation and one sniffer (using libpcap)
to get the replies. You could also take a look at paratrace by Dan 
Kaminsky's paketto keiretsu. It will help you
map the network more easily and perhaps induce more accurate 
conclusions. As far as Nmap is concerned, there is an option
called --ttl <value> that allows you to define your own value, but in 
this case it would need repeated use (or some sort
of script calling nmap each time with a different value of --ttl).


-- ithilgore



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org