WebApp Sec mailing list archives
Re: Should or shouldn't block public ping to a website
From: John Hall <j.hall () f5 com>
Date: Fri, 9 Sep 2011 15:47:46 -0700
I think the answer should be a bit more nuanced. The ICMP protocol offers some very useful and in some cases, required, functionality, so you should probably have a stance of allowing some ICMP types and not others. Here's a list of all the types currently provided by ICMPv4 (condensed from this IANA XML registry <http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml>): *Type * *Description * *Reference(s) * Type 0 Echo Reply (RFC792) Type 1 Unassigned (JBP) Type 2 Unassigned (JBP) Type 3 Destination Unreachable (RFC792) Type 4 Source Quench (RFC792, generation of deprecated in RFC1812) Type 5 Redirect (RFC792) Type 6 Alternate Host Address (JBP) Type 7 Unassigned (JBP) Type 8 Echo (RFC792) Type 9 Router Advertisement (RFC1256) Type 10 Router Solicitation (RFC1256) Type 11 Time Exceeded (RFC792) Type 12 Parameter Problem (RFC792) Type 13 Timestamp (RFC792) Type 14 Timestamp Reply (RFC792) Type 15 Information Request (RFC792) Type 16 Information Reply (RFC792) Type 17 Address Mask Request (RFC950) Type 18 Address Mask Reply (RFC950) Type 19 Reserved (for Security) (Solo) Type 20-29 Reserved (for Robustness Experiment) (ZSu) Type 30 Traceroute (RFC1393) Type 31 Datagram Conversion Error (RFC1475) Type 32 Mobile Host Redirect (David_Johnson) Type 33 IPv6 Where-Are-You (Simpson) Type 34 IPv6 I-Am-Here (Simpson) Type 35 Mobile Registration Request (Simpson) Type 36 Mobile Registration Reply (Simpson) Type 37 Domain Name Request (RFC1788) Type 38 Domain Name Reply (RFC1788) Type 39 SKIP (Markson) Type 40 Photuris (RFC2521) Type 41 ICMP messages utilized by experimental mobility protocols such as Seamoby (RFC4065) Type 42-255 Reserved (JBP) Most of these ICMP types are not necessary for a website on the Internet to expose and several are quite dangerous (which has led to the "block all ICMP" recommendations in security circles). Several of the ICMP message types *are* very useful and are also fairly safe to allow, a couple ICMP message types are required in some circumstances to make the Internet work. These are: *ICMP Message Type * *What it's good for * *Risks for a public website IP * 0 Echo (ping) reply, allow incoming to let your server ping stuff on the other side of the firewall and allow outbound to allow your server to respond to inbound pings. Protocol parsing errors, DoS, could make remote reconnaissance of your network easier. 3 Required outbound for Path MTU Discovery to work for clients contacting your web server. If your web server needs to contact arbitrary sites on the Internet (not recommended), then you'd need to allow inbound as well. Note: ICMP Type 3 has a number of "Codes" under it. To enable PMTUD, you only need to allow Type 3, Code 4 "fragmentation needed and Do not Fragment bit set" outbound. If you have services that require access to arbitrary sites on the Internet, you should probably allow some Type 3 messages inbound to those hosts or accept that the only way you can detect failures is a TCP timeout or timeout in your application. Protocol parsing errors, DoS, if more codes are allowed outbound, remote reconnaissance of your network may be easier. If allowed inbound, spoofed unreachable packets could be used to block your server's responses to users by someone in the path between you. 8 Echo (ping) request, allow outgoing to let your server ping stuff on the other side of the firewall and allow inbound to allow your server to respond to inbound pings. Be sure to only allow pings to specific host IP addresses or ranges. The "Smurf Attack" uses an ICMP echo request to a broadcast address on your network to amplify the DoS attack. Protocol parsing errors, DoS (smurf attack), could make remote reconnaissance of your network easier. 11 Allow outbound to enable others to traceroute to you, allow inbound to enable your server to traceroute out (not recommended, you should use dedicated troubleshooting host, the firewall, or a router to do these checks) Protocol parsing errors, DoS, could make remote reconnaissance of your network easier. The risks listed are very minimal for these ICMP message types. A "protocol parsing error" risk is very unlikely in code that's been in service for many years. The "DoS" potential is pretty minimal, since you'd only respond with a single ICMP packet of about the same size as the attacker sent (except in the "Smurf attack" case). Any attacker would be looking for better amplification effects, such as spoofing an HTTP or DNS request which allows them to send a few small packets and, if they choose the right URL or DNS record, make you send a huge response. The remote reconnaissance risk is generally small, as long as you only allow ICMP to hosts that are supposed to be publicly visible anyway. The implementation of IPv6 makes the "no ICMP" stance unworkable, once you transition, since PMTUD is a required part of the protocol, no longer optional. One of the primary reasons for the "no ICMP" stance was the "Ping of Death" attack. Unfortunately, this attack could have been implemented using just about any IP based protocol, it was just first implemented using ICMP and, again, unfortunately, several operating systems had severe bugs in fragmentation handling that could cause a system crash. No current operating system should be vulnerable to that fragmentation bug. The actually dangerous ICMP message types that should be blocked on your borders: *Type * *Risk * 4 Source quench can be easily spoofed and it's use has been deprecated. 5,6 Redirects are also easily spoofed and can be used to control routing on your network. 9,10 Router advertisement/Solicitation can be used to control routing on your network. 18 Address mask reply could be used to control routing on your network. All of the other ICMP types should probably be blocked for safety's sake, unless you have a good reason to allow them. Many are reserved or rarely used and there may be bugs in the IP stacks software that just haven’t been found yet, or they leak information about your network that nobody else needs to know. JMH On 09/06/2011 11:15 PM, ShiYih Lye wrote:
hi, What Todd said is pretty true, and that is what playing in my mind, "what does blocking ICMP ping from public will buy me ?"
...
I think there is not much benefit of dropping ICMP from the public compare with the bones it gives, at least for a ebusiness website, doesn't it ? Anyone having different view is most welcome to chip in your thought :) Regards, Lye
This list is sponsored by Cenzic -------------------------------------- Let Us Hack You. Before Hackers Do! It's Finally Here - The Cenzic Website HealthCheck. FREE. Request Yours Now! http://www.cenzic.com/2009HClaunch_Securityfocus --------------------------------------
Current thread:
- Should or shouldn't block public ping to a website ShiYih Lye (Sep 09)
- Message not available
- Re: Should or shouldn't block public ping to a website ShiYih Lye (Sep 09)
- Re: Should or shouldn't block public ping to a website Andre Correa (Sep 11)
- Re: Should or shouldn't block public ping to a website John Hall (Sep 11)
- Re: Should or shouldn't block public ping to a website ShiYih Lye (Sep 09)
- Message not available
- Re: Should or shouldn't block public ping to a website MATHDATER (Sep 11)
- <Possible follow-ups>
- Re: Should or shouldn't block public ping to a website Sandeep Cheema (Sep 11)
- Re: Should or shouldn't block public ping to a website Clement Dupuis (Sep 12)
- RE: Should or shouldn't block public ping to a website Martin O'Neal (Sep 13)
- RE: Should or shouldn't block public ping to a website Martin O'Neal (Sep 14)