Why not to stealth all ICMP

[corndog420]

Here is a cool email I got today, regarding some interesting aspects of stealthing against ICMP traffic. I was particularly taken with this email, as I just watched Leo Laporte advise disabling all icmp traffic via the win xp firewall. What do you folks think? Safer on or off? I'm not particularly worried about my address being used as a spoofer, but I suppose it's a matter of time,

http://home.neb.rr.com/dagreasepound...ockallicmp.txt

Corn

[instronics]

Stealthing means the firewall just DROPS all ICMP packets.

Advantage - The packets sent to the FW will not respond, slowing down potential portscans, or ICMP in general.

Disadvantage - It makes the attacker aware that there is a firewall DROPING ICMP packets.

Choose your poison.

[slarty]

What about the useful ICMP packets which actually give applications information? Like unreachable messages?

Nobody ever seems to give a damn about them.

Perhaps because Windoze doesn't seem to handle them correctly anyway?

Slarty

[thehorse13]

Ahhhh yes, Slarty, I was going to bring up the various ICMP message types. In case anyone is interested, here is a link to the complete list of ICMP message types and related codes.

http://www.iana.org/assignments/icmp-parameters

The nice thing about ICMP is that you can filter specific types that are associated with the usual enumeration nonsense while allowing those that are beneficial to your admins. That said, I think that the document is a bit narrow in content and depth in regards to ICMP.

--TH13

[x acidreign x]

Originally posted here by instronics
Stealthing means the firewall just DROPS all ICMP packets.

Advantage - The packets sent to the FW will not respond, slowing down potential portscans, or ICMP in general.

Disadvantage - It makes the attacker aware that there is a firewall DROPING ICMP packets.

Choose your poison.

thats only if the attacker knows there is a live system at the ip in question. this is rarely the case, in most cases it is an attacker scanning ip after ip to determine which one is alive. Dropping icmp packets will give the attacker the assumption that there is no machine alive at your ip so is actually a good thing. This does not, however, protect against port scanning, which is scanning comonly used ports for a response. Dropping ICMP Packets is adviseable, but it does not make you "invisible" by any means.

[r04dki11]

Along the lines of horse13's comments I have found a firewall set of rules that allows only the outbound and inbound ICMP I want (two separate rules) and two other rules that deny all other ICMP connections (one for inbound, one for outbound). This way I can run traceroute out but will not respond to an inbound traceroute, or will allow an inbound echo reply but wont send one. This seems to keep things working fairly smoothly even if it did take a little poking around to find the right mix.

I don't know if this will help corndog's e-mail but it works for me.

[stormulf]

Yah, nice...NIce to know that there are some who do know what improperly configured 'firewalls' can do! ICMP is important. But try telling ipoperations that! Really screws with the net the way these nerbs think...did I say think?

Thanks for sharing that email with us. I needed that after the past few days tracing down those net unreacheables!

[ammo]

More intelligent (stateful) firewalls, like pf on OpenBSD, use their connection state table to allow valide ICMP packets, ie. those that relate to established connections (or in the process of being established), even when you have a "block in icmp" rule. No need to filter on particular icmp codes for inbound or outbound...

Ammo

[stanger]

hmmm...attackers..??

just one thing about blockin,droppin,stealthin(orwhatever) all ICMP traff:
if you are running a webserver you will make any DSL user angry about your shitworking site.
a little problem with lenght of the blocks while usin DSL( sry ,still i do not really understand this ).
the dsl users will only be able to access ya site without errors by coming thru a proxy.

greetz, stanger