Enabling Ping Replies in Windows Server 2008 and R2
Archived note. Originally published 20 July 2010 on iishacks.com. It describes Windows Server 2008 and Windows Server 2008 R2 as they behaved at that time and is preserved here as a record. The netsh firewall context shown below was deprecated in favour of netsh advfirewall, and the server versions described are no longer current. Verify against current vendor documentation before applying any of it to a live system.
The recovered note
A common question is why a Windows Server 2008 host does not answer pings, and how to make it answer. It does not reply by default. No official reason was published at the time; the likely reasoning has to do with the ping of death and with ping flooding.
The ping of death is an attack in which a target is sent an unusually large ICMP packet. Ping flooding works differently: if the target is set to respond to pings, it can be loaded to the point where it no longer responds effectively to other requests such as HTTP and FTP. Denial-of-service attacks of that kind usually need a coordinated effort across many machines to bring a server down, but they happen, and often.
To enable replies on the public profile — that is, over the internet — open Administrative Tools, then Windows Firewall with Advanced Security, then Inbound Rules. Find File and Printer Sharing (Echo Request — ICMPv4-In), right-click it and select Enable Rule.
The same thing can be done from a command prompt on Windows Server 2008:
netsh firewall set icmpsetting 8Or, to disable the setting again:
netsh firewall set icmpsetting 8 disableOn Windows Server 2008 R2, the equivalent is:
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allowWhy the default is to drop inbound echo
An echo reply is a free statement that a host exists. That is the entire value of the protocol and also the entire objection to it. A host that answers confirms an address is live and gives a round-trip time saying roughly how far away it is — without a single connection being opened and, on most configurations of the period, without anything being logged.
Scanning an address range is cheap when the hosts answer and expensive when they do not. Silence does not prevent discovery, since anything publishing a service on a well-known port has already announced itself, but it does raise the cost of a sweep and removes the easiest confirmation step available to whoever is running it.
Set against that, the attacks named in the original note had already aged by 2010. Oversized-packet handling was long since fixed in the stacks that were vulnerable to it, and a flood large enough to matter overwhelms the link rather than the ICMP handler, so the host's own settings are not where that fight is decided. The default is conservative rather than protective: it withholds information that has no purpose on a public interface.
Which firewall profile is being opened
This is the part worth being deliberate about, and the part the console makes easy to get wrong. Windows Firewall with Advanced Security keeps three profiles — Domain, Private and Public — and a rule applies to whichever are ticked. Enabling the built-in echo rule without checking its scope can quietly open the behaviour on all three.
The distinction is what makes the change routine or consequential. On the domain profile, a server answering echo requests is answering machines that have already authenticated to the same directory, disclosing what those machines could obtain several other ways. On the public profile it is answering the internet: every scanner that touches the address gets a confirmation it would otherwise have to work for.
The habit worth keeping is to enable echo on the profile that needs it, leave the others alone, and check the rule afterwards rather than trusting the default scope. A rule enabled for management convenience inside a datacentre has no reason to answer anything else.
netsh firewall and netsh advfirewall
The two command forms are not interchangeable. netsh firewall is the older context, kept for compatibility with scripts written for earlier Windows versions, and it was deprecated in favour of netsh advfirewall. It cannot express what the newer firewall can: per-profile scope, remote address restrictions, interface types, and program and service bindings.
That is why the R2 line is longer. It creates a named rule that appears in the console alongside every other, can be inspected, scoped and removed by name, and reads unambiguously in a script. The older command sets a global ICMP setting that is far harder to audit later, against an interface already on its way out.
The monitoring trade-off
There is a cost to silence that is easy to overlook while thinking about attackers, and it lands on the operator rather than on anyone else.
A host that does not answer echo requests is a host the operator's own availability checks cannot see either. A great deal of monitoring — uptime checks, path tests, latency graphs, the first step of most fault-finding — assumes a reachable host replies. Where it does not, availability has to come from something else: a service check against the port that actually matters, an agent reporting outward, or a synthetic transaction. Those are better signals than an echo reply, since a host can answer a ping while the application on it refuses every request. They also all have to be built.
The trap is the middle state, where echo is disabled and nothing replaces it. The result is a server that is invisible to attackers and equally invisible to its owner until a user reports the outage. If echo replies are turned off on a public interface, decide first what will be watching the host instead, and confirm that the replacement check actually fires when the service stops.
Reading it today
The reasoning holds; the commands have moved on. Current guidance lives in the Windows Defender Firewall documentation, the broader Windows Server documentation covers the platform, and NIST SP 800-123, the Guide to General Server Security remains a sound reference for deciding what a server should expose in the first place.
Related notes are filed under Security, viruses and trojans and Windows and Server. The companion piece on blocking IP addresses with IP Security Policy in Windows Server 2003 shows what host-level filtering looked like before the advanced firewall existed, and the complete index is at post archives.