|
Security Basics
Removing ping/icmp from a network Mar 25 2008 04:29PM Secure This (lists securethis net) (7 replies) Re: Removing ping/icmp from a network Mar 26 2008 02:55PM Jason Thompson (securitux gmail com) (4 replies) Re: Removing ping/icmp from a network Mar 25 2008 05:32PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) Re: Removing ping/icmp from a network Mar 25 2008 05:17PM Jon R. Kibler (Jon Kibler aset com) (1 replies) Re: Removing ping/icmp from a network Mar 26 2008 12:13PM Secure This (lists securethis net) (1 replies) DoD aproved disk wiping tool Mar 27 2008 01:31PM JP Vicente (jvicente asft net) (4 replies) RE: DoD approved disk wiping tool Mar 27 2008 11:38PM Steve Armstrong (stevearmstrong logicallysecure com) (1 replies) RE: DoD aproved disk wiping tool Mar 27 2008 07:50PM Kevin Ortloff (Kevin Ortloff j2global com) (1 replies) Re: DoD aproved disk wiping tool Mar 27 2008 04:56PM John Syers (jsyers acm org) (1 replies) RE: DoD aproved disk wiping tool Mar 27 2008 03:21PM Timmothy Lester (Timmothy Lester primeadvisors com) RE: Removing ping/icmp from a network Mar 25 2008 04:56PM Hopke, Greg (GHopke libertymgt com) (1 replies) Re: Removing ping/icmp from a network Mar 25 2008 06:12PM Mark Owen (mr markowen gmail com) (2 replies) RE: Removing ping/icmp from a network Mar 26 2008 01:58PM Ramsdell, Scott (Scott Ramsdell cellnethunt com) (1 replies) Re: Removing ping/icmp from a network Mar 26 2008 06:44PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies) RE: Removing ping/icmp from a network Mar 27 2008 02:19PM Ramsdell, Scott (Scott Ramsdell cellnethunt com) (1 replies) Re: Removing ping/icmp from a network Mar 27 2008 02:34PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) |
|
|
Privacy Statement |
> ICMP is not vital for network operation, though it is convenient. PING
> isn't required at all,
Neither is traceroute. Yet I'd hate to be without without either of
them.
> ICMP unreachable messages don't do anything other than notify the
> receiver to stop trying to connect to a destination as it isn't alive
> (the receiver should get a hint of this when his SYN's don't get a SYN
> ACK),
Destination unreachable messages do quite a bit more than "notify the
receiver to stop trying to connect", since they code field carries the
information *why* the destination wasn't reached. Maybe that's not so
important for joe.average@home, but it's pretty darn important for any
network admin.
> ICMP redirects shouldn't happen if your network is structured
> properly, and even if it's not, it just adds an extra hop.
What about "time exceeded"? What about "parameter problem"? What about
"source quench"?
> I don't see any ICMP messages that are a MUST for network operation.
No, they're not a MUST. Connections can also just silently fail, leaving
you as a network admin at a total loss as to *why* they're failing.
Brilliant idea, really.
> That being said, if network monitoring is being done via SNMPv1 or v2
> which isn't secure at all, ICMP is the least of your problems. I agree
> with a few here that you allow ICMP from trusted to untrusted, but not
> vice versa. And definitely NO ICMP from the Internet.
What the heck is so freakin' scary about inbound echo requests? (to
public IP addresses, that is)
ICMP is not "teh evil(tm)". It's a part of the Internet Protocol suite,
and it's there for a reason.
Regards
Ansgar Wiechers
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
[ reply ]