-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



=============================================================================

CERT* Advisory CA-98.01.smurf

Original issue date: Jan. 05, 1998

Last revised:   August 24, 1998

                Updated vendor information for Data General Corporation.



                A complete revision history is at the end of this file.



Topic: "smurf" IP Denial-of-Service Attacks

- -----------------------------------------------------------------------------



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.



- -----------------------------------------------------------------------------



I.   Description



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"

    Author: Craig Huegen 

    URL: http://www.quadrunner.com/~chuegen/smurf.txt





II.  Impact



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.





III. Solution



A. Solutions for the Intermediary



1. Disable IP-directed broadcasts at your router.



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.



2. Configure your operating system to prevent the machine from responding to

   ICMP packets sent to IP broadcast addresses.



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.





B. Solutions for the Victim



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

http://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



        http://ftp.cert.org/pub/whois_how_to





C. Solution for the Site Where Attacks Originate



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 RFC 2267,

"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://ftp.isi.edu/in-notes/rfc2267.txt





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Appendix A - Vendor Information



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.





Cray Research - A Silicon Graphics Company

==========================================

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 Systems

=============

Cisco recommends the following configuration settings as protection against

being used as an intermediary in smurf attacks:



1. Disabling IP directed broadcast for all interfaces on which it is

   not needed. This must be done on all routers in the network, not

   just on the border routers. The command "no ip directed-broadcast"

   should be applied to each interface on which directed broadcasts

   are to be disabled.



   Very few IP applications actually need to use directed broadcasts,

   and it's extremely rare for such an application to be in use in a network

   without the knowledge of the network administrator. Nonetheless,

   as when any functionality is disabled, you should be alert for

   possible problems.



   This is the preferred solution for most networks.



2. If your network configuration is simple enough for you to create

   and maintain a list of all the directed broadcast addresses in

   your network, and if you have a well-defined perimeter separating

   your own network from potentially hostile networks, consider

   using a filter at the perimeter to prevent directed broadcasts from

   entering the network. For example, if your network number is

   172.16.0.0, and you uniformly use a subnet mask of 255.255.255.0,

   then you might use Cisco access list entries like



     access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.255 0.0.255.0

     access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.0 0.0.255.0



   Note that this is not a complete access list; it's simply two

   entries. See the Cisco documentation for more information on

   configuring access lists. The best place to apply such a filter is

   usually on the incoming side of each router interface that connects

   to the potentially hostile network.



   This solution may be administratively infeasible for networks using

   variable-length subnet masks, or which have complex external

   connectivity. There is also some possibility that legitimate

   directed broadcasts may be being sent into your network from the

   outside, especially if you're working in a research environment.



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



Data General Corporation

========================



  DG/UX has an option to enable/disable the forwarding of IP broadcast 

  packets. It is disabled by default.  This means that if DG/UX is used 

  along the path, it will not forward the attack packets.

 

  DG/UX B2 with Security Option has a 'netctrl' facility which enables the

  administrator to disable the response to a broadcast ICMP ping message.

  



DIGITAL EQUIPMENT CORPORATION

=============================



Currently DIGITAL products do not deny individual ICMP service to a

host. That, outside the intranet, firewalls should protect from this

kind of spoof/attack.



If the problem has to be dealt with inside the firewall and the

intranet, then policy should address "malicious acts"and the

individuals responsible.





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.





IBM Corporation

===============

AIX 4

- -----

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





AIX 3

- -----

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 don't respond to ICMP packets not sent

to their own address, but do forward them.  They're currently

examining the problem to see what kind of solution they can provide.





The NetBSD Project

==================

Under NetBSD you can disable forwarding of directed broadcast

packets with this command, as root:



        # sysctl -w net.inet.ip.directed-broadcast=0



NetBSD will always respond to broadcast ICMP packets.  In the

future, NetBSD may allow this to be disabled.





Sun Microsystems

================



    To prevent incoming broadcast packets from entering your network

    (III. A. 1. in this advisory)



    Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:



      Use the following command:



        ndd -set /dev/ip ip_forward_directed_broadcasts 0



    SunOS 4.1.3_U1 and 4.1.4:



      Do the following:



        Add ``options DIRECTED_BROADCAST=0'' to system configuration

        file and rebuild kernel



    To prevent systems from responding to broadcast ICMP packets

    (III. A. 2. in this advisory)



    Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:



      Use the following command:



        ndd -set /dev/ip ip_respond_to_echo_broadcast 0



    A corresponding variable for ip_respond_to_echo_broadcast does not exist

    in SunOS 4.1.x.





- -----------------------------------------------------------------------------

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/).





CERT/CC Contact Information

- ----------------------------

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



Postal address

         CERT Coordination Center

         Software Engineering Institute

         Carnegie Mellon University

         Pittsburgh PA 15213-3890

         USA



Using encryption

   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.

   Location of CERT PGP key

         http://ftp.cert.org/pub/CERT_PGP.key



Getting security information

   CERT publications and other security information are available from

        http://www.cert.org/

        http://ftp.cert.org/pub/



   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 http://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: http://ftp.cert.org/pub/cert_advisories/CA-98.01.smurf

           http://www.cert.org/pub/alerts.html



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Revision history



Aug. 24, 1998  Updated vendor information for Data General Corporation.



Aug. 14, 1998  Updated vendor information for Sun Microsystems.



Apr. 28, 1998  Updated vendor information for Cisco Systems and

               Sun Microsystems.

               Corrected URL for obtaining RFCs



Apr. 10, 1998  Updated vendor information for Cisco Systems



Feb. 10, 1998  Updates to Appendix A - Vendor Information



Jan. 29, 1998  Updated reference to the filtering document (now an RFC)

               in Section III-C.



Jan. 13, 1998  Updated vendor information for NetBSD.



Jan. 7, 1998   Updated or added vendor information for Digital Equipment

               Corporation and Livingston Enterprises, Inc.





-----BEGIN PGP SIGNATURE-----

Version: PGP for Personal Privacy 5.0

Charset: noconv



iQA/AwUBOBTATFr9kb5qlZHQEQKmZQCcD2CgcRl5wHlkNrF08qOjIHYszhwAoILh

/7ZKbwAWCujVHs76cfeDJRoJ

=asjq

-----END PGP SIGNATURE-----