When I was involved with the Australian Stock Exchange we had no ICMP to the internet, limited internally across zones, minimal in the DMZ etc. This was a 6 9's environment (i.e. 99.9999% uptime). There was only a couple issues with ICMP. ICMP was allowed and restricted based on a business need. The only problems where,

A complaint from an ad network who used ICMP responses when configuring targeted "spam" that broke.

A complaint from the audit company who thought they should be able to see ICMP.

A complaint from a network monitoring company who wanted (without permission) to test the ASX as a baseline for their reports to other companies.

Other than this,
- No testing issues
- No client issues
- Systems up at the required levels

Regards,
Craig Wright (GSE-Compliance)

Craig Wright
Manager of Information Systems

Direct : +61 2 9286 5497
Craig.Wright (at) bdo.com (dot) au [email concealed]
+61 417 683 914

BDO Kendalls (NSW-VIC) Pty. Ltd.
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497
http://www.bdo.com.au/

Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within those States and Territories of Australia where such legislation exists.

The information in this email and any attachments is confidential. If you are not the named addressee you must not read, print, copy, distribute, or use in any way this transmission or any information it contains. If you have received this message in error, please notify the sender by return email, destroy all copies and delete it from your system.

Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls. You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or Director of BDO Kendalls. It is your responsibility to scan this communication and any files attached for computer viruses and other defects. BDO Kendalls does not accept liability for any loss or damage however caused which may result from this communication or any files attached. A full version of the BDO Kendalls disclaimer, and our Privacy statement, can be found on the BDO Kendalls website at http://www.bdo.com.au/ or by emailing mailto:administrator (at) bdo.com (dot) au. [email concealed]

BDO Kendalls is a national association of separate partnerships and entities.

-----Original Message-----

From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Michael Painter
Sent: Friday, 28 March 2008 7:49 AM
To: security-basics (at) securityfocus (dot) com [email concealed]
Subject: Re: Removing ping/icmp from a network

Tracing route to microsoft.com [207.46.197.32]
over a maximum of 30 hops:
1 8 ms 8 ms 9 ms flexnet-adsl-customers [206.126.0.5]
2 8 ms 8 ms 8 ms shhh.our.upstream [66.135.224.201]
3 8 ms 8 ms 7 ms 216.236.111.17
4 10 ms 9 ms 8 ms hnl-edge-01.inet.qwest.net [67.129.94.1]
5 61 ms 62 ms 62 ms bur-edge-03.inet.qwest.net [205.171.13.169]
6 61 ms 62 ms 62 ms bur-core-02.inet.qwest.net [205.171.13.89]
7 82 ms 85 ms 84 ms sea-core-01.inet.qwest.net [67.14.1.186]
8 84 ms 83 ms 101 ms sea-edge-03.inet.qwest.net [205.171.26.38]
9 83 ms 83 ms 81 ms 63.237.224.30
10 91 ms 85 ms 83 ms ge-1-3-0-57.wst-64cb-1b.ntwk.msn.net [207.46.36.249]
11 83 ms 81 ms 81 ms ge-0-0-0-0.wst-64cb-1a.ntwk.msn.net [207.46.34.45]
12 83 ms 82 ms 81 ms ge-7-1-0-0.cpk-64c-1b.ntwk.msn.net [207.46.35.41]
13 81 ms 84 ms 84 ms ten3-4.cpk-76c-1a.ntwk.msn.net [207.46.34.38]
14 87 ms 85 ms 82 ms 10.22.0.26
15 * * * Request timed out.
16 * ^C

Hmm...10.22.0.26?

----- Original Message -----
From: "Jason" <securitux (at) gmail (dot) com [email concealed]>
To: "Mark Owen" <mr.markowen (at) gmail (dot) com [email concealed]>
Cc: "Ansgar -59cobalt- Wiechers" <bugtraq (at) planetcobalt (dot) net [email concealed]>; <security-basics (at) securityfocus (dot) com [email concealed]>
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 (at) gmail (dot) com [email concealed]> wrote:
>> On Thu, Mar 27, 2008 at 12:25 PM, Jason <securitux (at) gmail (dot) com [email concealed]> 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
>>

[ reply ]