Re: Removing ping/icmp from a network

IP Whois Information for

OrgName: Internet Assigned Numbers Authority
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US

NetRange: -
NetName: RESERVED-10
NetHandle: NET-10-0-0-0-1
NetType: IANA Special Use
Comment: This block is reserved for special purposes.
Comment: Please see RFC 1918 for additional information:
Updated: 2007-11-27

Clean, I guess.


On 3/27/08, Michael Painter <tvhawaii@xxxxxxxxx> wrote:
Tracing route to []
over a maximum of 30 hops:
1 8 ms 8 ms 9 ms flexnet-adsl-customers []
2 8 ms 8 ms 8 ms shhh.our.upstream []
3 8 ms 8 ms 7 ms
4 10 ms 9 ms 8 ms []
5 61 ms 62 ms 62 ms []
6 61 ms 62 ms 62 ms []
7 82 ms 85 ms 84 ms []
8 84 ms 83 ms 101 ms []
9 83 ms 83 ms 81 ms
10 91 ms 85 ms 83 ms []
11 83 ms 81 ms 81 ms []
12 83 ms 82 ms 81 ms []
13 81 ms 84 ms 84 ms []
14 87 ms 85 ms 82 ms
15 * * * Request timed out.
16 * ^C


----- Original Message -----
From: "Jason" <securitux@xxxxxxxxx>
To: "Mark Owen" <mr.markowen@xxxxxxxxx>
Cc: "Ansgar -59cobalt- Wiechers" <bugtraq@xxxxxxxxxxxxxxxx>; <security-basics@xxxxxxxxxxxxxxxxx>
Sent: Thursday, March 27, 2008 8:52 AM
Subject: Re: Removing ping/icmp from a network

> ICMP is allowed throughout most Internet routers, if you can trace all
> the way to the hop before the firewall, then you have narrowed down
> where the issue is.
> From there, what about network analysis and application monitoring
> tools? What about tcpdump, ethereal, etc? Can that not be used that to
> check network and server latency / response times on a standard web
> request?
> We have a customer in Australia who's ISP blocks all ICMP to and from
> their CPE routers. We seem to get along just fine. Web site is down or
> is slow and the router before the CPE is responding, dump the packets,
> look at the timestamps and see what's going on. IP packet traces spit
> back latency just fine with or without ICMP. Problem inside the CPE?
> Use remote management tools over a VPN to troubleshoot further (if you
> manage the server of course).
> Reputation is not going to change based on whether ICMP is allowed or
> not... if the web site is down its down, clients aren't going to care
> if they can ping it or not if they can't access their data through SSL
> or whichever protocol either way. "Well I can't do my job, but this is
> a stable server because I can ping it".
> Plus, if you absolutely must have ICMP to troubleshoot from the
> Internet, firewall rules can be used to narrow the source and
> destination as someone else in this thread suggested. I may have given
> too much of a blanket statement when saying no ICMP from the Internet
> at all, I should have said no open ICMP. Controlled ICMP through a
> firewall with proper rules should be good.
> I don't consider MS's site unreliable just because I, or anyone on the
> Internet for that matter, can't ping it.
> -J
> On Thu, Mar 27, 2008 at 1:09 PM, Mark Owen <mr.markowen@xxxxxxxxx> wrote:
>> On Thu, Mar 27, 2008 at 12:25 PM, Jason <securitux@xxxxxxxxx> wrote:
>> *snip*
>> > The idea is to limit your Internet footprint to make it as difficult
>> > as possible for an attacker. There is no need for a web server to
>> > respond to ping from the Internet for example.
>> It is very critical that your web server responds to ICMP on the
>> Internet. If you go out of the way and ignore essential protocols for
>> IP over a public network, you're just going to create a headache for
>> all of us.
>> Without ICMP, it is very difficult for us to determine where a problem
>> exists when our clients complain about slow load times or
>> inaccessibility to your website. No ICMP means no basic trace
>> routing, no basic latency checks, and no basic error reporting. So
>> even if the problem is somewhere in our infrastructure that limits or
>> prevents access to your site, you're going to get the blame and bad
>> reputation of an unstable server. If it doesn't respond to ping, and
>> can't be traced, its not our fault that our client can't access your
>> site, it's yours.
>> --
>> Mark Owen