Anatomy of a Hack

Microsoft put out a good article this year about how and intruder might get into your network. I stumpled upon this gem whilst looking for something else, so I haven't quite read it yet, but you can right here.

One of the things he mentions though, might be an oversimplification:

ICMP traffic should be sent to /dev/null at the border. Even a half decent firewall should block ICMP, but it is surprising how often administrators forget to ensure that it is actually disabled. No response should even be sent.

Interestingly enough, in not one but two papers agree that unbiased blocking of ICMP could invariably lead to trouble. The RFC summarized it best, I think:

ICMP messages are commonly blocked at firewalls because of a perception that they are a source of security vulnerabilities. This often creates "black holes" for Path MTU Discovery [3], causing legitimate application traffic to be delayed or completely blocked when talking to systems connected via links with small MTUs.

As for the firewalls I've setup, I leave ICMP alone. There are too many instances where I've found it thankfull when I've been able to ping the firewall's interfaces from all networks attached.

Comments

There are a few Cable/DSL/dial-up providers that quash ICMP. Nothing worse than getting most of the way done with cleaning the mal-ware off of someone's home or office computer and having a busted ping or traceroute convincing you that they still have a corrupted LSP in their TCP/IP stack. At least let me get one or two steps past the gateway before you step all over it.

Subscribe to Comments for "Anatomy of a Hack"