OVERVIEW:

The information here provides in-depth information regarding "smurf" and 
"fraggle" attacks, with a focus on Cisco routers and how to reduce the 
effects of the attack.  Some information is general and not related to an 
organization's particular vendor of choice; however, it is written with a 
Cisco router focus.  No confirmation has been made to the effects on other 
vendors' equipment; however, others have provided me with information for 
various vendors, which is provided in the document.  See the 
"Acknowledgements" section below for the sources and contact information. 
I am happy to accept information from other colleagues or other vendors 
who are willing to provide information about other vendors' products in 
relation to this topic. 

This paper is always being updated as I receive more information about 
attacks and work with ways to minimize impact. 

DESCRIPTION:

The "smurf" attack, named after its exploit program, is one of the most 
recent in the category of network-level attacks against hosts.  A 
perpetrator sends a large amount of ICMP echo (ping) traffic at IP broadcast 
addresses, all of it having a spoofed source address of a victim.  If the 
routing device delivering traffic to those broadcast addresses performs 
the IP broadcast to layer 2 broadcast function noted below, most hosts on 
that IP network will take the ICMP echo request and reply to it with an 
echo reply each, multiplying the traffic by the number of hosts 
responding.  On a multi-access broadcast network, there could potentially 
be hundreds of machines to reply to each packet. 

The "smurf" attack's cousin is called "fraggle", which uses UDP echo 
packets in the same fashion as the ICMP echo packets; it was a simple 
re-write of "smurf". 

Currently, the providers/machines most commonly hit are IRC servers and 
their providers. 

There are two parties who are hurt by this attack...  the intermediary 
(broadcast) devices--let's call them "amplifiers", and the spoofed address 
target, or the "victim".  The victim is the target of a large amount of 
traffic that the amplifiers generate. 

Let's look at the scenario to paint a picture of the dangerous nature of 
this attack.  Assume a co-location switched network with 100 hosts, and 
that the attacker has a T1.  The attacker sends, say, a 768kb/s stream of 
ICMP echo (ping) packets, with a spoofed source address of the victim, to 
the broadcast address of the "bounce site".  These ping packets hit the 
bounce site's broadcast network of 100 hosts; each of them takes the packet 
and responds to it, creating 100 ping replies out-bound.  If you multiply 
the bandwidth, you'll see that 76.8 Mbps is used outbound from the "bounce 
site" after the traffic is multiplied.  This is then sent to the victim (the 
spoofed source of the originating packets). 

HOW TO DETERMINE IF YOUR NETWORK IS VULNERABLE:

Several sites have been established to do both active and passive scanning 
of networks to determine whether or not directed-broadcast is enabled. 

http://www.netscan.org/ is a site which actively scans the IPv4 address 
space and mails network contacts with information on how to disable them. 

http://www.powertech.no/smurf/ is a site which will test scan your 
network and allow you to enter a known smurf amplifier site. 

HOW TO KEEP YOUR SITE FROM BEING THE SOURCE
PERPETRATORS USE TO ATTACK VICTIMS:

The perpetrators of these attacks rely on the ability to source spoofed 
packets to the "amplifiers" in order to generate the traffic which causes 
the denial of service. 

In order to stop this, all networks should perform filtering either at the 
edge of the network where customers connect (access layer) or at the edge 
of the network with connections to the upstream providers, in order to 
defeat the possibility of source-address-spoofed packets from entering 
from downstream networks, or leaving for upstream networks. 

Paul Ferguson of cisco Systems and Daniel Senie of BlazeNet have written 
an RFC pertaining to this topic.  See: 

ftp://ftp.isi.edu/in-notes/rfc2267.txt

for more information and examples on this subject. 

Additionally, router vendors have added or are currently adding options 
to turn off the ability to spoof IP source addresses  by checking the 
source address of a packet against the routing table to ensure the return 
path of the packet is through the interface it was received on. 

Cisco has added this feature to the current 11.1CC branch, used by many 
NSP's, in an interface command '[no] ip verify unicast reverse-path'. 

See the "other vendors" section for 3Com information regarding this feature. 

HOW TO STOP BEING AN INTERMEDIARY:

This attack relies on the router serving a large multi-access broadcast 
network to frame an IP broadcast address (such as 10.255.255.255) into a 
layer 2 broadcast frame (for Ethernet, FF:FF:FF:FF:FF:FF).  RFC 1812, 
"Requirements for IP Version 4 Routers", Section 5.3.5, specifies: 

---
A router MAY have an option to disable receiving network-prefix- 
directed broadcasts on an interface and MUST have an option to 
disable forwarding network-prefix-directed broadcasts.  These options 
MUST default to permit receiving and forwarding network-prefix- 
directed broadcasts. 
---

Generally, with IP providers and IP applications as we know them today, 
this behavior should not be needed, and it is recommended that 
directed-broadcasts be turned off, to suppress the effects of this attack. 

RFC 2644, a Best Current Practice RFC by Daniel Senie, updates RFC 1812 
to state that router software must default to denying the forwarding 
and receipt of directed broadcasts. 

Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen 
to a select number of addresses in normal operation.  The one MAC address 
that all devices share in common in normal operation is the media 
broadcast, or FF:FF:FF:FF:FF:FF.  If a device receives a packet destined 
to the broadcast link-layer address, it will take the packet and send an 
interrupt for processing by the higher-layer routines. 

To stop your Cisco router from converting these layer 3 broadcasts into 
layer 2 broadcasts, use the "no ip directed-broadcast" interface 
configuration command.  This should be configured on each interface of all 
routers. 

As of Cisco IOS version 12.0, "no ip directed-broadcast" is now the default 
in order to protect networks by default.  "ip directed-broadcast" will be 
needed if your network requires directed broadcasts to be enabled. 

Other vendor information: 

* Proteon/OpenROUTE: 
Daniel Senie (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text78007 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that Proteon/OpenROUTE Networks 
routers have an option to turn off directed broadcasts in the IP 
Configuration menus.  The command sequence to turn them off is: 
*CONFIG (on newer routers) or TALK 6 (on older routers) 
Config>PROTOCOL IP 
IP Config>DISABLE DIRECTED-BROADCAST 
A restart of the router is then required. 
* Nortel Networks (Bay Networks): 
Jon Green (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text77608 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that bugID CR33408 added the 
ability to disable network-directed broadcasts beginning in version 
12.01 rev 1 of BayRS code. 
To disable, enter: 
[1:1]$bcc 
bcc> config 
hostname# ip 
ip# set directed-bcast disabled 
ip# exit 
Note that this will bounce all IP interfaces. 
Greg Hankins (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text71464 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that in BayRS 13.01 
and later, directed-broadcast is disabled by default. 
Tim Winders (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text15511 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) mentions that if you upgrade 
to BayRS 13.01+ from 12.01, directed-broadcasts are not disabled. 
* 3Com NETBuilder products: 
Mike Kouri (Mike_  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text32471 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that all 3Com NETBuilders have 
an option to keep the router from forwarding the directed broadcasts. 
The command sequence to disable the forwarding is: 
SETDefault -IP CONTrol = NoFwdSubnetBcast 
Additionally, 3Com NETBuilder products running version 9.1 or later can 
be configured to discard source-spoofed packets: 
SETDefault !port -FireWall CONTrol = (Filter, DenySrcSpoofing) 
3Com states in the web page (listed below) that this command 
"Specifies whether packets are subject to source-spoofing checks. This is a 
CPU-intensive option and generally results in performance degradation. You 
should disable this option except on interfaces where external, untrusted 
traffic is received.  The source address of incoming packets is checked 
against the routing table.  If the routing information shows that the 
source address is unreachable, or reachable on different interfaces, 
then it is a SrcSpoofing attack." 
* Lucent (Ascend): 
Will Pierce (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text47188 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that on Maxes or Pipelines 
running TAOS 6.0.0 or higher, you can go to the Ethernet->Mod Config menu 
and set both "Reply DirectedBcast Ping" and "Forward Directed Bcast" to 
"No".  For the Max TNT, there is an example at 
ftp://ftp.ascend.com/pub/Software-Releases/MaxTNT/Release-2.0.X/2.0.0/doc/tnt20.pdf
on page 40.  TNT versions 2.0.0 and higher support this. 
* Cabletron SmartSwitch Router (Yago/SSR): 
Greg Hankins (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text26065 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports directed-broadcast is 
disabled by default, and can be enabled by entering the global command 
"ip enable directed-broadcast". 
* Foundry Networks: 
Greg Hankins (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text1591 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that hardware running 
Foundry's routing software can be configured to disable 
directed-broadcasts with the global or per-interface "no ip 
directed-broadcast" command. 
* Redback Networks: 
Justin Streiner (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text74729 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that on the SMS-500 
and SMS-1000 access switches, there is no support for directed 
broadcasts unless used in conjunction with DHCP, and they are not 
forwarded by default. 
* Extreme Networks: 
Aurobindo Sundaram (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text92296 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that you 
can disable IP broadcast forwarding on Extreme's Summit 1 switches 
by using the following commands: 
disable ipforwarding broadcast all 
disable ipforwarding broadcast vlan vlan-name 
* ArrowPoint Communications: 
Greg Hankins (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text25414 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that directed-broadcasts 
can be disabled by using the "no ip subnet-broadcast" global 
configuration command. 
* SGI IRIX as a router: 
Mike O'Connor (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text20585 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) reports that IRIX has been configured 
by default to not forward the directed-broadcasts when used as a router. 
The tunable for this is in /var/sysgen/master.d/bsd. 

There is one case study where this will stop intended behavior: In the 
case where samba (an SMB server for UNIX) or NT is used to "remote 
broadcast" into a LAN workgroup so that the workstations on that LAN can 
see the server, this will prevent the LAN machines from seeing the remote 
server.  This is *only* in the case where there is no WINS server (WINS is 
routed unicast) and a "remote broadcast" is being used--it's a rare but 
notable condition. 

(Editor's note:  I welcome any comments as to what else breaks without 
the support for directed-broadcast.) 

Additionally, hosts can be patched to refuse to respond to broadcasted 
ICMP echo packets.  RFC 1122, "Requirements for Internet Hosts -- 
Communications Layer", Section 3.2.2.6, states: 

---
An ICMP Echo Request destined to an IP broadcast or IP 
multicast address MAY be silently discarded. 

DISCUSSION:
This neutral provision results from a passionate debate 
between those who feel that ICMP Echo to a broadcast 
address provides a valuable diagnostic capability and 
those who feel that misuse of this feature can too 
easily create packet storms. 
---

Because of this, most IP stack implementors have chosen to implement the 
default support provision, which is to reply to an ICMP Echo Request. 
As mentioned in the paragraph from the RFC (above), it is perfectly legal 
for a host to silently discard ICMP echos.  Several patches have been 
found floating about in mailing lists for disabling response to broadcast 
ICMP echos for the freely-available UNIX systems. 

In the case of the smurf or fraggle attack, each host which supports this 
behavior on a broadcast LAN will happily reply with an ICMP or UDP (smurf 
or fraggle, respectively) echo-reply packet toward the spoofed source 
address, the victim. 

The following section contains information to configure hosts *not* to 
respond to ICMP echo requests to broadcast addresses. 

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 ICMP echo requests.  Add the 
following line to your /etc/rc2.d/S69inet startup: 
ndd -set /dev/ip ip_respond_to_echo_broadcast 0 
If you're using Solaris as a router, you can configure it not to 
forward directed broadcasts by placing the following line in 
your /etc/rc2.d/S69inet startup:
ndd -set /dev/ip ip_forward_directed_broadcasts 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. 
Beginning with version 3.x, FreeBSD makes this option configurable in 
the /etc/rc.conf file with an option under the miscellaneous network 
configuration section. 

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. 
"ipfw" can be used from Linux to block broadcast echos, a la: 

Any system with ipfw can be protected by adding rules such as: 
ipfwadm -I -a deny -P icmp -D 123.123.123.0 -S 0/0 0 8 
ipfwadm -I -a deny -P icmp -D 123.123.123.255 -S 0/0 0 8 
(replace 123.123.123.0 and 123.123.123.255 with your base network number 
and broadcast address, respectively) 

To protect a host against "fraggle" attacks on most UNIX machines, one 
should comment the lines which begin with "echo" and "chargen" in 
/etc/inetd.conf and restart inetd. 

INFORMATION FOR VICTIMS AND HOW TO SUPPRESS ATTACKS:

The amount of bandwidth and packets per second (pps) that can be generated 
by this attack is quite large.  With a 200-host LAN, I was able to 
generate over 80 Mbps traffic at around 35 Kpps toward my target--a 
pretty significant amount.  The victims receive this because traffic is 
multiplied by the number of hosts on the broadcast network used (in this 
case, with a 200-host network, I was only required to send 400 Kbps 
to the broadcast address--less than one-third of a T1). 

Many hosts cannot process this many packets per second; many hosts are 
connected to 10 Mbps Ethernet LANs where more traffic than wire speed 
is sent.  Therefore, the ability to drop these packets at the network 
border, or even before it flows down the ingress pipes, is desired. 

Cisco routers have several "paths" which packets can take to be routed; 
each has a varying degree of overhead.  The slowest of these is "process" 
switching.  This is used when a complex task is required for processing 
packets.  The other modes are variations of a fast path--each of them with 
a set of advantages and disadvantages.  However, they're all handled at 
interrupt level (no process-level time is required to push these packets). 

In IOS versions (even the most recent), access-list denies are handled at 
the process (slow) level, because they require an ICMP unreachable to be 
generated to the originating host.  All packets were sent to the process 
level automatically to be handled this way. 

Under a recent code change (Cisco bug ID CSCdj35407--integrated in version 
11.1(14)CA and later 11.1CA, 11.1CC, 11.1CE, and 12.0 trains), packets 
denied by an access-list will be dropped at the interrupt (fast) level, with 
the exception of 2 packets per second per access-list deny line. These 2 
packets per second will be used to send the "ICMP unreachable via 
administrative block" messages.  This assumes that you don't want to log 
the access-list violations (via the "log" or "log-input"  keywords).  The 
ability to rate-limit "log-input" access-list lines (in order to more 
easily log these packets) is currently being integrated;  see the section 
below on tracing spoofed packet attacks for information on logging. 

Filtering ICMP echo reply packets destined for your high-profile machines 
at the ingress interfaces of the network border routers will then permit 
the packets to be dropped at the earliest possible point.  However, it 
does not mean that the network access pipes won't fill, as the packets 
will still come down the pipe to be dropped at the router.  It will, 
however, take the load off the system being attacked.  Keep in mind that 
this also denies others from being able to ping from that machine (the 
replies will never reach the machine). 

For those customers of providers who use Cisco, this may give you some 
leverage with the providers' security teams to help save your pipes by 
filtering before the traffic is sent to you. 

An additional technology you can use to protect your machines is to use 
committed access rate, or CAR.  CAR is a functionality that works 
with Cisco Express Forwarding, found in 11.1CC, 11.1CE, and 12.0.  It 
allows network operators to limit certain types of traffic to specific 
sources and/or destinations. 

For example, a provider has filtered its IRC server from receiving 
ICMP echo-reply packets in order to protect it, but  many attackers are 
now attacking other customer machines or network devices in order to 
fill some network segments. 

The provider above chose to use CAR in order to limit all ICMP echo 
and echo-reply traffic received at the borders to 256 Kbps.  An example 
follows: 

! traffic we want to limit 
access-list 102 permit icmp any any echo 
access-list 102 permit icmp any any echo-reply 
! interface configurations for borders 
interface Serial3/0/0 
rate-limit input access-group 102 256000 8000 8000 conform-action transmit exceed-action drop 

This limits ICMP echo and echo-reply traffic to 256 Kbps with a small 
amount of burst.  Multiple "rate-limit" commands can be added to an 
interface in order to control other kinds of traffic as well. 

The command "show interface [interface-name] rate-limit" will show the 
statistics for rate-limiting; "clear counters [interface-name]" will 
clear the statistics for a fresh look. 

CAR can also be used to limit TCP SYN floods to particular hosts -- 
without impeding existing connections.  Some attackers have started 
using very high streams of TCP SYN packets in order to harm systems 
once again. 

Here is an example which limits TCP SYN packets directed at host 
10.0.0.1 to 8 kbps or so: 

! We don't want to limit established TCP sessions -- non-SYN packets 
access-list 103 deny tcp any host 10.0.0.1 established 
! We do want to limit the rest of TCP (this really only includes SYNs) 
access-list 103 permit tcp any host 10.0.0.1 
! interface configurations for network borders 
interface Serial3/0/0 
rate-limit input access-group 103 8000 8000 8000 conform-action transmit exceed-action drop 

Currently, CAR is only available for 7200 and 7500 series routers. 
Additional platform support is planned in 12.0. 

Additionally, CAR can be used to set IP precedence; this is beyond 
the scope of this paper.  Consult www.cisco.com for more information 
on the uses of CAR. 

TRACING SPOOFED PACKET STREAMS:

Tracking these attacks can prove to be difficult, but is possible with 
coordination and cooperation from providers.  This section also assumes 
Cisco routers, because I can speak only about the abilities of Cisco to 
log/filter packets and what impact it may have. 

Today, logging packets which pass through or get dropped in an ACL is 
possible; however, all packets with the "log" or "log-input" ACL options 
are sent to process level for logging.  For a large stream of packets, 
this could cause excessive CPU problems.  For this reason, tracking 
attacks via IOS logging today is limited to either lower bandwidth attacks 
(smaller than 10k packets per second).  Even then, the number of log 
messages generated by the router could overload a syslog server. 

Cisco bug ID CSCdj35856 addresses this problem.  It has been integrated 
into IOS version 11.1CA releases beginning with 11.1(14.1)CA (a 
maintenance interim release), and makes it possible to log packets at 
defined intervals and to process logged packets not at that interval in 
the fast path.  I will update this page with version numbers as the 
releases are integrated. 

Some information on logging: 

In later 11.1 versions, a new keyword was introduced for ACL logging: 
"log-input".  A formatted ACL line utilizing the keyword looks like this: 

access-list 101 permit icmp any any echo log-input 

When applied to an interface, this line will log all ICMP ping packets 
with input interface and MAC address (for multi-access networks). 
Point-to-point interfaces will not have a MAC address listed. 

Here's an example of the log entry for a multi-access network (FDDI, Ether): 

Sep 10 23:17:01 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 
10.0.7.30 (FastEthernet1/0 0060.3e2f.6e41) -> 10.30.248.3 (8/0), 5 packets 

Here's an example of the log entry for a point-to-point network: 

Sep 10 23:29:00 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 
10.0.7.30 (BRI0 *PPP*) -> 10.0.19.242 (8/0), 1 packet 

Substituting "log" for "log-input" will eliminate the incoming interface 
and MAC address from the log messages. 

We'll use the first log entry to demonstrate how to go from here.  This 
log entry means the packet came in on FastEthernet1/0, from MAC address 
0060.3e2f.6e41, destined for 10.30.248.3.  From here, you can use "show ip 
arp" (if needed) to determine the IP address for the MAC address, and go 
to the next hop for tracing or contact the necessary peer (in the case of 
an exchange point).  This is a hop-by-hop tracing method. 

Example of "show ip arp" used to find next hop: 

netlab#show ip arp 0060.3e2f.6e41 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface 
Internet  10.0.183.65            32   0060.3e2f.6e41  ARPA   FastEthernet1/0 

As you can see, 10.0.183.65 is the next hop where the packets came from 
and we should go there to continue the tracing process, utilizing the same 
ACL method.  By doing this, you can track the spoof attack backwards. 

While this is general information on tracking spoofed packets, it must be 
noted that the victims of a smurf/fraggle attack get packets from the listed 
source in the packets; i.e., they receive echo-reply packets truly from the 
source listed in the IP header.  This information should be used by the 
amplifiers or intermediaries to track the spoofed echo _request_ packets 
back to their source (the perpetrator). 

OTHER DENIAL OF SERVICE ATTACKS WORTHY OF MENTION:

Two other denial of service attacks frequently encountered are TCP SYN 
floods, and UDP floods aimed at diagnostic ports on hosts. 

TCP SYN attacks consist of a large number of spoofed TCP connection set-up 
messages aimed at a particular service on a host.  Older TCP 
implementations cannot handle many faked connection set-up packets, and 
will not allow access to the victim service. 

The most common form of UDP flooding directed at harming networks is an 
attack consisting of a large number of spoofed UDP packets aimed at 
diagnostic ports on network devices.  This attack is also known as the 
"pepsi" attack (again named after the exploit program), and can cause 
network devices to use up a large amount of CPU time responding to these 
packets. 

To get more information on minimizing the effects of these two attacks, 
see: 

Defining Strategies to Protect Against TCP SYN 
Denial of Service Attacks 
http://cio.cisco.com/warp/public/707/4.html

Defining Strategies to Protect Against UDP Diagnostic 
Port DoS Attacks 
http://cio.cisco.com/warp/public/707/3.html

PERFORMANCE INFORMATION:

One ISP has reported that, spread across three routers (2 RSP2 and 1 
RSP4), the fast drop code eliminated a sustained 120 Mbps smurf 
attack and kept the network running without performance problems. 

As always, your mileage may vary. 

ACKNOWLEDGEMENTS:

Thanks to all those who helped review and provide input to the paper, as 
well as sanity checking. 

Referenced documents:

RFC-1122, "Requirements for Internet Hosts - Communication Layers"; 
R.T. Braden; October 1989. 

RFC-1812, "Requirements for IP Version 4 Routers"; F. Baker; June 1995. 

RFC-2267, "Network Ingress Filtering: Defeating Denial of Service Attacks 
which employ IP Source Address Spoofing"; P. Ferguson, D. Senie; 
January 1998. 

RFC-2644, "Changing the Default for Directed Broadcasts in Routers"; 
D. Senie; August 1999. 

Defining Strategies to Protect Against TCP SYN 
Denial of Service Attacks 
http://cio.cisco.com/warp/public/707/4.html

Defining Strategies to Protect Against UDP Diagnostic 
Port DoS Attacks 
http://cio.cisco.com/warp/public/707/3.html

Cisco command documention to turn off directed broadcasts 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/cs/csprtn1/csipadr.htm#xtocid748113

3Com command documentation to turn off directed broadcasts 
http://infodeli.3com.com/infodeli/tools/bridrout/u_guides/html/nb101/family/REF/ip4.htm#190

3Com command documentation to disable source spoofing 
http://infodeli.3com.com/infodeli/tools/bridrout/u_guides/html/nb101/family/REF/firewal3.htm#1823

PERMISSION TO DUPLICATE:

Permission to duplicate this information is granted under these terms: 

1.  My name and e-mail address remains on the information as a target for 
questions and identification of the source 
2.  My disclaimer appears on the information at the bottom 
3.  Feel free to add extra information from other discussions, etc., but 
please ensure the correct attribution is made to the author.  Also 
provide Craig Huegen (  This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text69049 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) a copy of your additions. 
4.  Please help disseminate this information to other network 
administrators who are affected by these attacks. 

If you have questions, I will be happy to answer them to the best of my 
knowledge. 

MY DISCLAIMER:

I'm speaking about this as an interested party only.  All text in this 
paper was written by me; I speak/write for no one but myself.  No vendors 
have officially confirmed/denied any of the information contained herein. 
All research for this paper is being done purely as a matter of 
self-interest and desire to help others minimize effects of this attack. 

Craig A. Huegen 
This e-mail address is being protected from spambots. You need JavaScript enabled to view it '; document.write( '' ); document.write( addy_text91741 ); document.write( '<\/a>' ); //-->\n This e-mail address is being protected from spambots. You need JavaScript enabled to view it
http://www.pentics.net/denial-of-service/white-papers/smurf.txt