**************************************************************************
Security Bulletin 9801 DISA Defense Communications System
January 7, 1998 Published by: DISN Security Coordination Center
(SCC@NIC.MIL) 1-(800) 365-3642
The DISN SECURITY BULLETIN is distributed by the DISN SCC (Security Coordination Center) under DISA contract as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DISN facilities. Back issues may be obtained via FTP from NIC.MIL [207.132.116.5] using login= "anonymous" and password="guest". The bulletin pathname is scc/sec-yynn (where "yy" is the year the bulletin is issued and "nn" is a bulletin number, e.g. scc/sec-9705.txt). These are also available at our WWW site, http://nic.mil.
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
! !
! The following important advisory was issued by the Computer !
! Emergency Response Team (CERT) and is being relayed unedited !
! via the Defense Information Systems Agency's Security !
! Coordination Center distribution system as a means of !
! providing DISN subscribers with useful security information. !
! !
+ - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - +
===========================================================================
===========================================================================
- -----------------------------------------------------------------------------
This advisory is intended primarily for network administrators responsible for router configuration and maintenance.
The attack described in this advisory is different from the denial-of-service attacks described in CERT advisory CA-97.28.
The CERT Coordination Center has received reports from network service providers (NSPs), Internet service providers (ISPs), and other sites of continuing denial-of-service attacks involving forged ICMP echo request packets (commonly known as "ping" packets) sent to IP broadcast addresses. These attacks can result in large amounts of ICMP echo reply packets being sent from an intermediary site to a victim, which can cause network congestion or outages. These attacks have been referred to as "smurf" attacks because the name of one of the exploit programs attackers use to execute this attack is called "smurf."
The CERT/CC urges you to take the steps described in Section III to reduce the potential that your site can be used as the origination site (Sec. III.C) or an intermediary (Sec. III.A.) in this attack. Although there is no easy solution for victim sites, we provide some recommendations in Sec. III.B.
We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site.
- -----------------------------------------------------------------------------
The two main components to the smurf denial-of-service attack are the use of forged ICMP echo request packets and the direction of packets to IP broadcast addresses.
The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this, an ICMP echo request packet is sent to a machine. If a machine receives that packet, that machine will return an ICMP echo reply packet. A common implementation of this process is the "ping" command, which is included with many operating systems and network software packages. ICMP is used to convey status and error information including notification of network congestion and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or network problems.
On IP networks, a packet can be directed to an individual machine or broadcast to an entire network. When a packet is sent to an IP broadcast address from a machine on the local network, that packet is delivered to all machines on that network. When a packet is sent to that IP broadcast address from a machine outside of the local network, it is broadcast to all machines on the target network (as long as routers are configured to pass along that traffic).
IP broadcast addresses are usually network addresses with the host portion of the address having all one bits. For example, the IP broadcast address for the network 10.0.0.0 is 10.255.255.255. If you have subnetted your class A network into 256 subnets, the IP broadcast address for the 10.50 subnet would be 10.50.255.255. Network addresses with all zeros in the host portion, such as 10.50.0.0, can also produce a broadcast response.
In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial-of-service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim).
The intermediary receives an ICMP echo request packet directed to the IP broadcast address of their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses, many of the machines on the network will receive this ICMP echo request packet and send an ICMP echo reply packet back. When (potentially) all the machines on a network respond to this ICMP echo request, the result can be severe network congestion or outages.
When the attackers create these packets, they do not use the IP address of their own machine as the source address. Instead, they create forged packets that contain the spoofed source address of the attacker's intended victim. The result is that when all the machines at the intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine. The victim is subjected to network congestion that could potentially make the network unusable. Even though we have not labeled the intermediary as a "victim," the intermediary can be victimized by suffering the same types of problem that the "victim" does in these attacks.
Attackers have developed automated tools that enable them to send these attacks to multiple intermediaries at the same time, causing all of the intermediaries to direct their responses to the same victim. Attackers have also developed tools to look for network routers that do not filter broadcast traffic and networks where multiple hosts respond. These networks can the subsequently be used as intermediaries in attacks.
For a more detailed description of the "smurf" attack, please consult this document:
"The Latest in Denial of Service Attacks: 'Smurfing':
Description and Information to Minimize Effects"
Both the intermediary and victim of this attack may suffer degraded network performance both on their internal networks or on their connection to the Internet. Performance may be degraded to the point that the network cannot be used.
A significant enough stream of traffic can cause
serious performance degradation for small and mid-level ISPs that
supply service to the intermediaries or victims. Larger ISPs may
see backbone degradation and peering saturation.
One solution to prevent your site from being used as an intermediary in this attack is to disable IP-directed broadcasts at your router. By disabling these broadcasts, you configure your router to deny IP broadcast traffic onto your network from other networks. In almost all cases, IP-directed broadcast functionality is not needed.
Appendix A contains details on how to disable IP-directed broadcasts for some router vendors. If your vendor is not listed, contact that vendor for instructions.
You should disable IP-directed broadcasts on all of your routers. It is not sufficient to disable IP-directed broadcasts only on the router(s) used for your external network connectivity. For example, if you have five routers connecting ten LANs at your site, you should turn off IP-directed broadcasts on all five routers.
If an intruder compromises a machine on your network, the intruder may try to launch a smurf attack from your network using you as an intermediary. In this case, the intruder would use the compromised machine to send the ICMP echo request packet to the IP broadcast address of the local network. Since this traffic does not travel through a router to reach the machines on the local network, disabling IP-directed broadcasts on your routers is not sufficient to prevent this attack.
Some operating systems can be configured to prevent the machine from responding to ICMP packets sent to IP broadcast addresses. Configuring machines so that they do not respond to these packets can prevent your machines from being used as intermediaries in this type of attack.
Appendix A also contains details on how to disable
responding to ICMP packets sent to IP broadcast addresses on some
operating systems. If your operating system is not listed, contact
your vendor for instructions.
Unfortunately, there is no easy solution for victims receiving the potentially large number of ICMP echo reply packets. ICMP echo reply traffic (the traffic from the intermediary) could be blocked at the victim's router; however, that will not necessarily prevent congestion that occurs between the victim's router and the victim's Internet service provider. Victims receiving this traffic may need to consult with their Internet service provider to temporarily block this type of traffic in the ISP's network.
Additionally, victims in this position should contact the intermediaries and inform them of the attack and of the steps described in the previous section. (Please refer them to http://www.cert.org/pub/alerts.html or ftp://ftp.cert.org/pub/cert_advisories/ for the most recent version of this advisory.)
Victims can use the "whois" command to obtain contact information for
the sites. More information on using whois is available in
ftp://ftp.cert.org/pub/whois_how_to
We recommend filtering outgoing packets that contain a source address from a different network.
Attacks like the smurf attack rely on the use of forged packets, that is, packets for which the attacker deliberately falsifies the origin address. With the current IP protocol technology, it is impossible to eliminate IP-spoofed packets. However, you can use filtering to reduce the likelihood of your site's networks being used to initiate forged packets.
As we mentioned in CERT advisory CA-97.28 on Teardrop and Land denial-of-service attacks, the best current method to reduce the number of IP-spoofed packets exiting your network is to install filtering on your routers that requires packets leaving your network to have a source address from your internal network. This type of filter prevents a source IP-spoofing attack from your site by filtering all outgoing packets that contain a source address from a different network.
A detailed description of this type of filtering is available in the
Internet Draft "Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing" by Paul Ferguson of
Cisco Systems, Inc. and Daniel Senie of Blazenet, Inc. We recommend it
to both Internet Service Providers and sites that manage their own
routers. The document is currently available at
http://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt
Note that although this document is labeled as an IETF "working draft," the content is complete and it is being proposed as an Informational RFC. Because this is an Internet Draft, it will only be available under the above URL for several months. When the document is available as an RFC or otherwise, we will update the URL in this advisory.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Below is a list of the vendors who have provided
information for this advisory. We will update this appendix as
we receive additional information. If you do not see your vendor's
name, the CERT/CC did not hear from that vendor. Please contact
the vendor directly.
Current versions of Unicos and Unicos/mk do not have
the ability to reject ICMP requests send to broadcast addresses.
We are tracking this problem through SPR 709733.
Cisco recommends the following configuration settings as protection against being used as an intermediary in smurf attacks:
In addition to these protections against being used as an intermediary in a smurf attack, Cisco recommends that you take steps to prevent users within your own network from launching such attacks. For "stub" networks which do not provide transit connectivity (most corporate and institutional networks, many smaller ISPs), this is usually best done by installing filters at the network perimeter to prevent any packets from leaving your network unless their IP source addresses actually lie within your network's address space. For the example network above, you might place the following entry in the incoming access lists on the interface(s) facing your internal network:
access-list 101 permit ip 172.16.0.0 0.0.255.255 0.0.0.0 255.255.255.255
access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0
255.255.255.255
FreeBSD, Inc.
=============
In FreeBSD 2.2.5 and up, the tcp/ip stack does not
respond to icmp echo requests destined to broadcast and multicast
addresses by default. This behaviour can be changed via the sysctl
command via mib net.inet.icmp.bmcastecho.
- -----
There is a network attribute called "bcastping" that controls whether or not responses to ICMP echo packets to the broadcast address are allowed. A value of zero turns off responses and a value of one turns them on. The default is zero (i.e., by default AIX version 4 is not vulnerable to the described denial-of-service attack).
Use the following command to check the value of the bcastping attribute:
$ no -o bcastping
Use the following command to turn off responses to ICMP broadcast packets (as root):
# no -o bcastping=0
- -----
The "bcastping" attribute does not exist in version 3.
IBM and AIX are registered trademarks of International
Business Machines Corporation.
Livingston Enterprises, Inc.
============================
Livingston Enterprises products discard any ICMP
packets directed to broadcast addresses, so we protect against
this form of attack. No special configuration is required.
Under NetBSD you can disable directed broadcast with this command, as root:
# sysctl -w net.inet.ip.directed-broadcast=0
- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Craig A. Huegen. Much of the content in this advisory has been derived from his document on "smurf" attacks. The CERT Coordination Center also thanks Paul Ferguson and Daniel Senie for providing information on network ingress filtering, and John Bashinski of Cisco for his contributions.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised,
contact the CERT Coordination Center or your representative in
the Forum of Incident Response and Security Teams (see http://www.first.org/team-info/).
- ----------------------------
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information.
ftp://ftp.cert.org/pub/CERT_PGP.key
CERT publications and other security information are available from
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.01.smurf
http://www.cert.org/pub/alerts.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
****************************************************************************
* *
* *
* *
* *
* *
* *
* *
* *
****************************************************************************
PLEASE NOTE: Some users outside of the DOD computing communities may receive DISN Security Bulletins. If you are not part of the DOD community, please contact your agency's incident response team to report incidents. Your agency's team will coordinate with DOD. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts.
This document was prepared as an service to the DOD
community. Neither the United States Government nor any of their
employees, makes any warranty, expressed or implied, or assumes
any legal liability or responsibility for the accuracy, completeness,
or usefulness of any information, product, or process disclosed,
or represents that its use would not infringe privately owned
rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government. The
opinions of the authors expressed herein do not necessarily state
or reflect those of the United States Government, and shall not
be used for advertising or product endorsement purposes.