Body Text
Second Level
Third Level
Fourth Level
Fifth Level
Network-Based Denial of Service Attacks
Growing accessibility to public and private networks has produced a large increase in network-based Denial of Service attacks within the past year. With the growing number of organizations accessing public networks (such as the Internet), the number of attack targets increases. Many networks are still vulnerable to attacks.  In smaller organizations, the network administration may not have sufficient resources to dedicate to security. Many organizations have not protected their networks from packets with faked source addresses, called “spoofs”, due to issues such as equipment age or capability, access control list (ACL) management capabilities, etc.
An attacker relies on anonymity when attacking hosts/networks so that he/she can do so without being identified. Attacks like “Smurf” and “Fraggle” (described in the next few pages) work only when IP source-address spoofing is possible, because of the reflexive nature of the attack.  Without spoofing, they would just be flooding themselves. Other attacks, such as the fragmentation attacks mentioned, simply use spoofing as a way to avoid being identified. Large lists of super-user accounts, as well as user-level accounts, are passed around in order to help deter the identification process when an attack occurs and it can be traced.  Hopping from account to account increases the chance the attacker will not be found due to uncooperative administrators. Internet Relay Chat (IRC) is a tool used by many to pass around exploit information.  It’s also used by many attackers to “show off” their attacks to their peers. Unfortunately, the wide use of IRC by attackers makes IRC servers, operators, and users a target when the attacker wants revenge.  The first targets of the “smurf” program were IRC servers. Providers who do terminate accounts due to abuse are usually targets as well, just like IRC servers who ban users from using the servers.
The attacks that we look at today are in one of three categories and have the following goals:
Prevent another user from using a network connection
Disable a host or service
Monitor traffic
The reasons for these goals vary:
Usually the prevention of network, host, or service usability is a result of some revenge.
Monitoring traffic usually has two eventual goals:
New compromised accounts from which attacks can be staged
Espionage of some type, resulting in embarrassment or blackmail
The “Smurf” and “Fraggle” attacks are two of the most severe Denial of Service attacks found today, because they allow a user with relatively low bandwidth to generate a very large amount of bogus traffic towards a remote network.
They utilize IP directed broadcasts in combination with echo protocols and spoofed packets in order to generate multiplied traffic streams.
There are two victims:
The intended victim, who receives a large amount of traffic from intermediate sites
The intermediate sites, or “bounce sites” used to multiply the traffic streams
The attacks are similar in nature to traditional ping and UDP flooding, except that ping and UDP flooding require that the perpetrator have more bandwidth than the target he/she is attacking.  Smurf and Fraggle allow the multiplication of traffic through the broadcast mechanism and therefore only require that the sites used to multiply the traffic have enough hosts to increase the factor by which the traffic streams are multiplied.
This is a diagram of a “Smurf” or “Fraggle” attack.
The single stream from the perpetrator to the broadcast LANrepresents the flow of information from the perpetrator to the broadcast LAN, usually several packets per second of ICMP echo (“Smurf”) or UDP echo (“Fraggle”) traffic spoofed to look like it is coming from the victim’s system. If the router at the edge of the LAN forwards the broadcast ping to the LAN, each device on the LAN will respond with an echo-reply (ICMP) or will bounce the traffic (UDP), creating a multiplication of the original traffic flow.  The traffic is then directed to the victim. There are usually several bounce sites involved, used to increase the factor by which traffic is multiplied. This attack is characterized by many ICMP echo reply packets at the victim’s site or many UDP packets involving the diagnostic “echo” port.
Filter customers’ networks so that they can only send traffic to you which fits within their network blocks.  For example, if you have assigned a customer a network block of with netmask, the following Cisco ACL would keep them from sending source-spoofed packets, as well as log attempts through your network, when applied to the customer’s incoming interface:
access-list 101 permit ip any
access-list 101 deny ip any any log
interface Serial1    ! Or the customer’s incoming interface
  ip access-group 101 in
(Adjust ‘101’ to your access-list numbering scheme)
Protect your network from receiving packets from external connections with source addresses that should come from internal machines.  For instance, if you have been assigned the network block of with netmask from your upstream, use the following Cisco ACL:
access-list 199 deny ip any
access-list 199 permit ip any any
interface Serial0    ! Our internet gateway’s interface to the Internet
  ip access-group 199 in
Protect others by ensuring packets you send out into external networks are only those from your addresses.  For instance, following the second example above, we would ensure that only packets with source addresses of 192.168.1.x could exit our network:
access-list 198 permit ip any
access-list 198 deny ip any any
interface Serial0   ! Our internet gateway’s interface to the Internet
  ip access-group 198 out
Host Requirements RFC-1122 Section states “An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.”
IBM has provided a setting in AIX 4.x to disable responses to broadcast addresses.  It is not available in AIX 3.x.  Use the "no" command to turn it off or on.  NOTE: On AIX 4.x responses are DISABLED by default.
no -o bcastping=0         # disable bcast ping responses (default)
Solaris can be set not to respond to broadcast ICMP echo requests.  Add the following line to your /etc/rc2.d/S69inet startup:
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Starting with version 2.2.5, FreeBSD's IP stack does not respond to icmp echo requests destined to broadcast and multicast addresses by default.  The sysctl parameter for this functionality is net.inet.icmp.bmcastecho.
Under NetBSD, directed broadcasts can be disabled by using the sysctl command:
sysctl -w net.inet.ip.directed-broadcast=0
Under Linux, one can use the CONFIG_IP_IGNORE_ECHO_REQUESTS variable to completely ignore ICMP echo requests.  Of course, this violates RFC 1122.
Any system (including Linux) with ipfw can be protected by adding rules such as:
ipfwadm -I -a deny -P icmp -D -S 0/0 0 8
ipfwadm -I -a deny -P icmp -D -S 0/0 0 8
(replace and with your base network number and broadcast address, respectively)
Cisco bugfixes which address some of the problems related to protection against Denial of Service attacks:
BugID CSCdj35407 - “fast drop” ACL code - integrated in 11.1(14)CA
This fix decreases the load on the router’s CPU when a packet matches an ACL “deny” line.  Previously, the processor would place every denied packet through the slow switching path in order to send the appropriate ICMP unreachable messages.  With this fix, only 2 packets per second go to the slow path in order to process those messages.
BugID CSCdj35856 - ACL logging throttles - integrated in 11.1(15)CA
This fix introduced a command “ip access-list logging interval” to set the interval between syslog notifications as a result of a “log” keyword in an ACL.
Unicast RPF checking insures that packets aren’t source-spoofed by ensuring that the packet came in on the same interface as the path back to the source address.  This is disabled by default, as there are configurations in which it would prevent legitimate traffic from flowing (multi-homed environments).  However, for stub networks (those with only one entry/exit point), this command ensures that there are no source-spoofed packets with bogus source addresses.
For the Internet, inter-provider cooperation in tracking down attacks is essential.  NOCs are encouraged to have published procedures/policies for engaging a technical team capable of tracking such attacks.
http://www.quadrunner.com/~chuegen/smurf/ contains extensively detailed information about the “Smurf” and “Fraggle” attacks, including an 8-page white paper on the attacks.
http://ds.internic.net/rfc/rfc2267.txt is a recently-published informational RFC describing implementation of filters to protect against origination and reception of some spoofed packets, written by Paul Ferguson and Daniel Senie.
http://www.security.mci.net/dostracker/ contains information about the MCI-developed DoSTracker tool designed to automate the process of tracking spoofed packets through a network using Cisco routers.
Other references found throughout this presentation also contain a wealth of information about the various attacks.
Please help me to understand and answer your concerns by asking questions and filling out the evaluation forms.
I am always open to suggestions on the presentation or white paper mentioned here.  Please feel free to send e-mail and I will be happy to address it.