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

=============================================================================
CERT(sm) Advisory CA-96.01
Original issue date:   February 8, 1996
Last revised: August 30, 1996 
              Information previously in the README was inserted
              into the advisory.

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

Topic: UDP Port Denial-of-Service Attack
- -----------------------------------------------------------------------------

The CERT Coordination Center has received reports of programs that launch
denial-of-service attacks by creating a "UDP packet storm" either on a system
or between two systems. An attack on one host causes that host to perform
poorly. An attack between two hosts can cause extreme network congestion in
addition to adversely affecting host performance.

The CERT staff recommends disabling unneeded UDP services on each host, in
particular the chargen and echo services, and filtering these services at the
firewall or Internet gateway.

Because the UDP port denial-of-service attacks typically involve IP spoofing,
we encourage you to follow the recommendations in advisory CA-95:01.

We will update this advisory as we receive additional information.
Please check advisory files regularly for updates that relate to your site

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

I.   Description 

     When a connection is established between two UDP services,
     each of which produces output, these two services can produce a
     very high number of packets that can lead to a denial of service
     on the machine(s) where the services are offered. Anyone with network
     connectivity can launch an attack; no account access is needed.
     
     For example, by connecting a host's chargen service to the echo service
     on the same or another machine, all affected machines may be
     effectively taken out of service because of the excessively high number
     of packets produced. In addition, if two or more hosts are so connected,
     the intervening network may also become congested and deny service
     to all hosts whose traffic traverses that network.

II.  Impact
     
     Anyone with network connectivity can cause a denial of service.
     This attack does not enable them to gain additional access.

III. Solution
     We recommend taking all the steps described below.

     1. Disable and filter chargen and echo services.
        This attack is most readily exploited using the chargen or echo
        services, neither of which is generally needed as far as we are aware.
        We recommend that you disable both services on the host and filter
        them at the firewall or Internet gateway.

        To disable these services on a host, it is necessary to edit the
        inetd configuration file and cause inetd to begin using the new
        configuration. Exactly how to do this is system dependent so you
        should check your vendor's documentation for inetd(8); but on many
        UNIX systems the steps will be as follows:
         (1) Edit the inetd configuration file (e.g. /etc/inetd.conf).
         (2) Comment out the echo, chargen, and other UDP services not used.
         (3) Cause the inetd process to reread the configuration file
             (e.g., by sending it a HUP signal).

     2. Disable and filter other unused UDP services.
        To protect against similar attacks against other services, we
        recommend
           -  disabling all unused UDP services on hosts and
           -  blocking at firewalls all UDP ports less than 900 with 
              the exception of specific services you require, such as
              DNS (port 53). 
     
     3. If you must provide external access to some UDP services, consider
        using a proxy mechanism to protect that service from misuse.
        Techniques to do this are discussed in Chapter 8, "Configuring
        Internet Services," in _Building Internet Firewalls_ by Chapman
        and Zwicky (see Section IV below).

     4. Monitor your network.
        If you do provide external UDP services, we recommend monitoring
        your network to learn which systems are using these services and
        to monitor for signs of misuse. Tools for doing so include Argus,
        tcpdump, and netlog.

        Argus is available from
             ftp://ftp.net.cmu.edu/pub/argus-1.5/
             MD5 (argus-1.5.tar.gz) = 9c7052fb1742f9f6232a890267c03f3c
     
             Note that Argus requires the TCP wrappers to install:
             ftp://info.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.2.tar.Z
             MD5 (tcp_wrappers_7.2.tar.Z) = 883d00cbd2dedd9bfc783b7065740e74

       tcpdump is available from
             ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z
             MD5 (tcpdump-3.0.2.tar.Z) = c757608d5823aa68e4061ebd4753e591
        
             Note that tcpdump requires libpcap, available at
                 ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z
                 MD5 (libpcap-0.0.6.tar.Z) = cda0980f786932a7e2eebfb2641aa7a0

       netlog is available from
              ftp://net.tamu.edu/pub/security/TAMU/netlog-1.2.tar.gz
              MD5 (netlog-1.2.tar.gz) = 1dd62e7e96192456e8c75047c38e994b

      5. Take steps against IP spoofing.
         Because IP spoofing is typically involved in UDP port
         denial-of-service attacks, we encourage you to follow the
         guidance in advisory CA-95:01, available from

               ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing

IV. Sources of further information about packet filtering

    For a general packet-filtering recommendations, see  
   
         ftp://info.cert.org/pub/tech_tips/packet_filtering

     For in-depth discussions of how to configure your firewall, see

         _Firewalls and Internet Security: Repelling the Wily Hacker_
         William R. Cheswick and Steven M. Bellovin 
         Addison-Wesley Publishing Company, 1994
         ISBN 0-201-63357
        
         _Building Internet Firewalls_
         Brent Chapman and Elizabeth D. Zwicky
         O'Reilly & Associates, Inc., 1995
         ISBN 1-56592-124-0

- ---------------------------------------------------------------------------
The CERT Coordination Center staff thanks Peter D. Skopp of Columbia
University for reporting the vulnerability and Steve Bellovin of AT&T Bell
Labs for his support in responding to this problem. 
- ---------------------------------------------------------------------------

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 (FIRST).

We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact the
CERT staff for more information.

Location of CERT PGP key
         ftp://info.cert.org/pub/CERT_PGP.key

CERT 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

To be added to our mailing list for CERT advisories and bulletins, send your
email address to
        cert-advisory-request@cert.org

CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
        ftp://info.cert.org/pub/

CERT advisories and bulletins are also posted on the USENET newsgroup
        comp.security.announce


Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.

CERT is a service mark of Carnegie Mellon University.

=============================================================================
UPDATES
         
Silicon Graphics Inc.

SGI acknowledges CERT Advisory CA-96.01 and is currently investigating.
No further information is available at this time.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history

Aug. 30, 1996  Information previously in the README was inserted into the
               advisory.
Feb. 23, 1996  Updates section - added information from Silicon Graphics, Inc.
Feb. 21, 1996  Solution, Sec. III.4 - added new URL for Argus.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMiTAHHVP+x0t4w7BAQGfMgP/VUfOtZS1+Pl9KTRe1buCq7lxXP3CFz//
LcjzuZVcGIz0akMb+EytK5yznAZpXLcvo1eUKtmbAoyu0Eq30YMTfhvLUQK48SVk
vURi0qYjvwbsQVWhZOiity3l7/imdhgX8IsrcRkYCTPEMALUc3PsYO903uHDutn7
mC5n1qW2Gqk=
=uBej
-----END PGP SIGNATURE-----
