Why do some web servers not respond to icmp requests?

Solution 1:

It's fairly common these days to drop ICMP, as it's a generic method to use for Denial of Service purposes. A higher-bandwidth host or a multiple of hosts repeatedly pinging a single Web server could utilize all its bandwidth.

Others might drop to lessen their footprint on the Internet, thus potentially being overlooked by mass scan traffic.

While it's common, I'd argue that it provides little value and does little to minimize DoS and footprint while limiting diagnostic potential.

Solution 2:

Apart from the dubious DoS protection and lowered profile, there's a common but overlooked reason a given IP might not respond to pings: it isn't actually assigned to an interface.

Redirecting (port forwarding) IP/protocol/port tuples to the various services you want gives you greater service density on a smaller network.

For instance, suppose your ISP routes 1.2.3.4/30 to you. You've got three choices:

• Route them normally. Leaves you two usable IPs, one of which must be your gateway, so a single host.
• NAT external IP to internal IP. Leaves you four hosts.
• Redirect traffic to internal services as needed. SMTP (TCP 25), DNS (TCP/UDP 53), and your corporate website (TCP 80,443) could all exist on a single external address.

The third way is increasingly common. Most administrators (myself included), when setting it up, don't bother to redirect ICMP so it just drops at the firewall.

Solution 3:

There's no harm in blocking ICMP type 0 (Echo reply), but blocking all ICMP traffic breaks responses to the client if any link in the retun path has an MTU less than the Send Max Segment Size of the TCP connection. This happens because the web server can no longer receive ICMP type 3 code 4 packets (Destination Unreachable; Fragmentation Needed and DF set).

In practice this isn't much of a problem because anyone who needs to tunnel traffic also must set up a mechanism for dealing with the multitude of web servers who's TCP stacks are hampered by misconfigured firewalls.

Solution 4:

Helps with denial of service attacks. No real reason to need the site open for pinging from the public.

Plus it doesn't give the stats for the website; one host or IP could easily be answering for a load balancing farm of servers on the back end (pinging a mysite.com doesn't tell you if all the servers are working properly behind the name.)

Could be just policy of the company to drop unnecessary traffic, or only allow port 80 and SSL traffic in to be redirected to other servers internally.

I guess the other question would be, why bother allowing outside systems to ping your servers if they really have no need to?