49
[4]
Systems Administration: You Cant Get There from Here, ServerWorkstation Expert, May 1999. This article can be found in PDF format at
http:sw.expert.comC4SE.C4.MAY.99.pdf .
The opposite can be true as well. Often ping will fail when the connection works for other uses. For various reasons, usually related to security, some system administrators may block ICMP packets in
general or ECHO_REQUEST packets in particular. Moreover, this practice seems to be increasing. Ive even seen a site block ping traffic at its DNS server.
3.3.3.1 Security and ICMP
Unfortunately, ping in particular, and ICMP packets in general, have been implicated in several recent denial-of-service attacks. But while these attacks have used ping, they are not inherently problems
with ping. Nonetheless, network administrators have responded as though ping was the problem or at least the easiest way to deal with the problem, and this will continue to affect how and even if ping
can be used in some contexts.
3.3.3.2 Smurf Attacks
In a Smurf Attack, ICMP ECHO_REQUEST packets are sent to the broadcast address of a network. Depending on how hosts are configured on the network, some may attempt to reply to the
ECHO_REQUEST. The resulting flood of responses may degrade the performance of the network, particularly at the destination host.
With this attack, there are usually three parties involved—the attacker who generates the original request; an intermediary, sometimes called a reflector or multiplier, that delivers the packet onto the
network; and the victim. The attacker uses a forged source address so that the ECHO_REPLY packets are returned, not to the attacker, but to a spoofed address, i.e., the victim. The intermediary may be
either a router or a compromised host on the destination network.
Because there are many machines responding to a single request, little of the attackers bandwidth is used, while much of the victims bandwidth may be used. Attackers have developed tools that allow
them to send ECHO_REQUESTs to multiple intermediaries at about the same time. Thus, the victim will be overwhelmed by ECHO_REPLY packets from multiple sources. Notice also that congestion is
not limited to just the victim but may extend through its ISP all the way back to the intermediaries networks.
The result of these attacks is that many sites are now blocking ICMP ECHO_REQUEST traffic into their network. Some have gone as far as to block all ICMP traffic. While understandable, this is not an
appropriate response. First, it blocks legitimate uses of these packets, such as checking basic connectivity. Second, it may not be effective. In the event of a compromised host, the
ECHO_REQUEST may originate within the network. At best, blocking pings is only a temporary solution.
A more appropriate response requires taking several steps. First, you should configure your routers so they will not forward broadcast traffic onto your network from other networks. How you do this will
depend on the type of router you have, but solutions are available from most vendors.
Second, you may want to configure your hosts so they do not respond to ECHO_REQUESTs sent to broadcast addresses. It is easy to get an idea of which hosts on your network respond to these
broadcasts. First, examine your ARP table, then ping your broadcast address, and then look at your ARP table again for new entries.
[5]
50
[5]
At one time, you could test your site by going to http:www.netscan.org
, but this site seems to have disappeared.
Finally, as a good network citizen, you should install filters on your access router to prevent packets that have a source address not on your network from leaving your network. This limits not only Smurf
Attacks but also other attacks based on spoofed addresses from originating on your network. These filters should also be applied to internal routers as well as access routers. This assumes you are
providing forwarding for other networks
If you follow these steps, you should not have to disable ICMP traffic. For more information on Smurf Attacks, including information on making these changes, visit
http:www.cert.orgadvisoriesCA- 1998-01.html
. You might also look at RFC 2827.
3.3.3.3 Ping of Death
