Can someone explain how traceroute is working?

I read this article that describes how traceroute works:

http://archives.neohapsis.com/archives/firewalls/2001-q1/1721.html

And then I did ran tracert a few times on my Windows 2000 computer with CHX installed. I was surprised to see tracert work flawlessly.

Tracert basically sends a UDP packet and relies on routers to send back ICMP type 11 code 0 packets. I actually have a CHX rule to Allow incoming ICMP type 11 code 0 packets (note that it is an "Allow" rule, not a "Force Allow" rule), but I also have ICMP stateful inspection turned on, so shouldn't CHX consider those ICMP packets to be unsolicited and reject them? Those packets weren't logged (and I do have stateful inspection logging turned on), so CHX is letting them thru.

Just wondering if CHX is working correctly or if it has a bug.

 

Stateful inspection isn't feasible with many ICMP packet types since error messages tend to be unsolicited and may come from an intermediate router rather than the desired destination, making it practically impossible for a firewall to identify what may be "legitimate" by tracking existing connections.

However stateful inspection can be applied to those ICMP types that involve a request/response pair (e.g. Ping's Echo Request/Echo Response or the Timestamp/Address Mask Request/Reply pairs). For this reason, there is virtually no security benefit in stateful filtering with ICMP compared to just filtering by ICMP message type.

 

Hello delerious,

What is allowed for ICMP will depend on the rules in place.

From your last posted ruleset, edited to just show the ICMP:

With a rule to force allow outbound type 8 code 0 (echo) then due to SPI replies will be allowed unless blocked.
For tracert, allow outbound echo (type 8 code 0) will allow the reply of time exceeded (type 11 code 0) without a need for the allow inbound rule in your last ruleset (unless the reply was outside the timeout)

 

Paranoid: that makes sense.

Stem: I disabled my Force Allow Outgoing ICMP Type 8 Code 0 rule to see what would happen with tracert, and I was surprised to see those packets show up in the log. The link that I had posted said that tracert sends out a UDP packet, but looks like it sends out ICMP type 8 code 0 instead. And the destination IP for those packets is always the tracert destination.

I also disabled incoming ICMP to see what was coming back from the tracert, and it was always type 11 code 0 packets with the source IPs set to the routers along the way. Since the source IPs of the incoming packets aren't matching up with the destination IP of the outgoing packets, I think the SPI should have rejected them. But because of what Paranoid said, maybe the SPI knows that it shouldn't be too strict with certain ICMP types.

 

Hi delerious

To keep things clear and simple:

the only ICMP type/Code used by a PC are:

type 8 code 0 echo request: outgoing only

and these in reply to the previous request:

type 0 code 0 echo reply: incoming only
type 11 code 0 timeout (used by trace route) : incoming only

In a local network you may also use this ICMP type/code:
type 3 code 4: Frag. Needed but a Flag DF is enabled. in and out in LAN only


All the other ICMP type/code must be blocked in and out.

 

No,.. you would need to check the packet info for such as tracert. Yes, if directly blocked, the returned blocked packet will show as the hop (the IP that the trace had got to), but with such as tracert deeper packet inspection made will show if the packet should be allowed or not.

Example: (I have posted full packet info without edit)
I made trace to Wilders (65.175.38.194) just to show the first hop, which is to my router.
The first outbound ICMP:-


The reply from first hop made to this:-
(Note the reply ICMP contains the origin and the final destination which can be checked by the SPI.)


EDIT,
This by the way, is with CHX only allowing the outbound with ICMP SPI enabled. So the reply is solicited

 

I disagree, certainly for a home/trusted LAN. ICMP is there for a reason, to show errors. Error messages, (for eample destination/port unreachable), should be allowed freely within a trusted LAN.

 

I Stern

I have to be more accurate:

Blocking all other ICMP type/code to and from Internet

 

Stem: so the incoming ICMP type 11 code 0 packet also contains most of the information from the outgoing ICMP type 8 code 0 packet embedded in it? So that's why the SPI is allowing them back in.

Thanks for taking the time to look into this. Just curious, what program do you use to analyze packets like that?

 

The analyzer I use is Network Packet analyzer Enterprise, I purchased this a while ago, due to my need to produce reports etc.
You can get the same info from such as Ethereal which is free, this gives output as show below:-