From: Per Gregers Bilse Date: Mon, 13 Apr 1998 16:23:14 +0200 Organization: EUnet Communications Services BV Subject: Smurf attacks Several hosts inside EUnet have been the targets of smurf attacks, and a number of you are familiar with the problem. For those who are not, some technical notes and explanations on the issue are at the end of this note. Put very briefly, a smurf attack is carried out by somebody pinging the broadcast address of networks (ethernet or fddi) with several hosts on them. The hosts each individually respond to the pings, thus sending out a multitude of packets for each ping the source transmits. Now, this isn't particularly useful in any normal case, but when the source sends pings with a faked source address it has suddenly become a very effective denial-of-service attack. To the best of my knowledge nobody inside EUnet except EUnet Norway (with only little effect) has yet been used to "bounce" (generate the traffic for) a smurf attack, but this will only be a question about time. Like spam, we can see these things starting in one place (the US), drifting through different sectors of the US part of the Internet, and eventually coming to Europe and other locations when possibilities on the US side have been reduced. The first widely known such attacks used MAE-East and MAE-West as launchpads, and in mid August last year MFS made it a requirement to prevent such attacks; otherwise people would simply be disconnected. We have recently seen persistent smurf attacks on Xlink and Relcom customers originating essentially within European academic networks, so it is to be expected that European commercials are next. Although the damage to a potential victim that can be done from most locations within EUnet is much smaller than in the case of US networks being used (due to the generally lower bandwidth), being the launchpad for such an attack will do substantial damage to your own network and connectivity. As long as over a year ago EUnet Austria was taken out completely by a break-in on a co-located server from which a "normal" floodping attack was launched; this essentially broke connectivity with AS286, and being the launchpad for a smurf attack can easily have the same result. And as opposed to a break-in, an attacker doesn't need to do anything even remotely difficult -- the code to carry out a smurf attack is well-known and simple to use. Fortunately, it is in most cases simple to avoid being used. All that's needed is to turn off directed broadcast on broadcast media; in Cisco speak: interface ethernetN no ip directed-broadcast I believe Ascend is the only vendor which currently doesn't support the similar functionality, meaning that those having Ascend equipment for dial-in will be vulnerable to attacks launched by their own customers. However, the effect of such an attack will likely be quite limited, and protection against outside attacks is obviously still possible (assuming a dial-up group is connected by routers where directed broadcast can be turned off). The above deals with how to prevent being used for such an attack; there's nothing technical that can immediately be done to prevent being the victim of such an attack, but as several of you will know we usually spot such attacks very quickly and block the traffic. However, one thing that can reduce the possibility of being a victim is to try to enforce "good behaviour" of users. We haven't seen a single smurf attack targeted at anything else than IRC servers, individual dial-ups, and/or other hosts closely associated with hobby users. It is obviously a rather tall order to make people behave well, but it must be kept in mind that all such attacks are provoked; the attackers (maybe with the exception of outright psychopaths) don't just pick hosts at random and then launch an attack. Those of you operating services that have a community feel to them (Ping in BE comes to mind) should consider what can be done, if not done already. Note that the Net's favourite opinion holder, Karl "machine-gun" Denninger from Chicago, has now resorted to filtering traffic from networks which have been used to launch smurf attacks. I think it can be expected that more people will follow this example. On Apr 11, 15:25, Karl Denninger wrote: > Subject: SMURF amplifier block list > > The following networks and masks are banned from our network at the core due > to being smurf amplifiers. > > When the folks who own these STOP THIS, we'll take them off the list. > Contact me by TELEPHONE if you want to discuss this matter or what a Smurf > is and why you should care. > > I'm going to start posting the blacklist here weekly in the hopes that peer > pressure will cause people to clean up their acts. Until you DO clean up > your act, you're not transiting our network - period. > > We're not going to accept this kind of vandalism and attractive nuisance any > more. If you haven't disabled directed broadcast forwarding, you are a > potential listee on this blacklist. > > DO IT NOW, or risk connectivity blockades. > > I urge all other network providers to block any identified smurf amplifier > that they can verify, and to post their list as well. > > Only through public pressure can people be forced to CORRECTLY configure > their networks to make these attacks impossible to launch. > > access-list 2 deny 128.118.0.0 0.0.255.255 > access-list 2 deny 129.24.0.0 0.0.255.255 > access-list 2 deny 129.111.0.0 0.0.255.255 > access-list 2 deny 129.100.0.0 0.0.255.255 > access-list 2 deny 128.40.0.0 0.0.255.255 > access-list 2 deny 129.101.0.0 0.0.255.255 > access-list 2 deny 203.64.0.0 0.0.255.255 > access-list 2 deny 129.115.0.0 0.0.255.255 > access-list 2 deny 203.108.225.0 0.0.0.255 > access-list 2 deny 129.60.0.0 0.0.255.255 > access-list 2 deny 137.79.0.0 0.0.255.255 > access-list 2 deny 130.37.0.0 0.0.255.255 > access-list 2 deny 130.70.0.0 0.0.255.255 > access-list 2 deny 203.108.236.0 0.0.0.255 > access-list 2 deny 132.169.0.0 0.0.255.255 > access-list 2 deny 129.107.0.0 0.0.255.255 > access-list 2 deny 129.49.0.0 0.0.255.255 > access-list 2 deny 129.96.0.0 0.0.255.255 > access-list 2 deny 130.65.0.0 0.0.255.255 > access-list 2 deny 134.205.0.0 0.0.255.255 > access-list 2 deny 129.29.0.0 0.0.255.255 > access-list 2 deny 204.48.224.0 0.0.0.255 > access-list 2 deny 205.177.49.0 0.0.0.255 > access-list 2 deny 204.47.208.0 0.0.0.255 > access-list 2 deny 204.242.172.0 0.0.0.255 > access-list 2 deny 194.6.129.0 0.0.0.255 > access-list 2 deny 206.31.78.0 0.0.0.255 > access-list 2 deny 207.211.60.0 0.0.0.255 > access-list 2 deny 206.27.242.0 0.0.0.255 > access-list 2 deny 207.175.67.0 0.0.0.255 > > I'm sure there are more, but these are the ones blacklisted in our > network configuration right now. > > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin > http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV > | NEW! Corporate ISDN Prices dropped by up to 50%! > Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS > Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost >-- End of excerpt from Karl Denninger On Apr 12, 0:36, Karl Denninger wrote: > > But posting the list of blackholed sites publicly gives the attackers a > > list of sites not to bother trying to use...so they keep coming out with > > new&improved versions of smurf using networks that actually work. > > The goal is to make the number of possible sources ZERO. > > If ISPs around the world refuse to forward directed broadcasts, it WILL > be zero. If a provider loses connectivity to significant parts of the > network, they'll fix their fscking routers. > > I'll note that one of the worst offenders right now, and the biggest > sources, is APNIC's netblocks. There are huge, multi-T3-connected, smurf > amplifiers on some of those network numbers. You'll find that in 203.64 > there are multiple high-bandwidth sources with ENABLED directed broadcasts. > > Guess what? That entire /16 can't talk to us any more. I've tried talking > to APNIC with no response. I've emailed every contact I can think of - > nothing. > > Now I've told them to fsck off. They can either fix the damn thing or > they can stuff connectivity to us up their behinds. > > I did this to huge parts of UUNET's infrastructure a few months ago. It > *DID* get their attention, and smartly. At one time, not long back, their > entire New York POP was one huge smurf amplifier of the worst kind - multiple > MAX TNTs on 100BaseTX, all with directed broadcasts possible into their NICs. > Ouch. We saw *sustained* loads in excess of 100Mbps coming from there. > I blocked a /16, and two days later their CUSTOMERS started calling us > asking why they couldn't talk to us any more. > > We told them why. > > Less than a week later it magically "fixed itself", although UUNET denied > that they changed anything or that it was ever broken. Yeah, right. > > At least the problem got solved. > > Bluntly, I've had enough and so have my customers. Our IRC server is the > recipient of daily attacks. Our *customers* DS1s are getting hit as well. > While I can fix the IRC server problem by putting it on a Switched 100BaseTX > port, that's not really a fix -- that's just making the firehose big enough > that the jerks can't fill it. > > No more Mr. Nice Guy. I don't like getting paged at 3:00 AM because some > two-bit punk got Klined off our IRC server for running clonebots and > decided to smurf us in retaliation. > > My fix is to render all connectivity to and from the offending netblocks > VOID until the owners fix their routers. These folks, by the way, are NOT > clueless - they are DELIBERATELY ignoring the problem. > > The folks who can source significant smurfs today are NOT Joe's T1 and Grill. > They are NATIONAL and INTERNATIONAL ISPs who damn well ought to know how to > prevent this and why they should. The guy with a T1 can't hit us hard > enough to even show up on our monitors. To make my blacklist you have to > hit me with enough bandwidth that we *see* the problem, and that means > you're at least mid-fractional-DS3 connected. > > If they're permitting this kind of behavior to take place *IT IS THEIR FAULT*, > and has to be due to either deliberate lack of action or gross negligence. > > I'll KEEP adding netblocks to that access group as required, and keep > posting the list. And I won't remove a single network from there until > I've VERIFIED that they can no longer be used for this kind of vandalism. > > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin > http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV > | NEW! Corporate ISDN Prices dropped by up to 50%! > Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS > Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost >-- End of excerpt from Karl Denninger Below follows a reasonably extensive paper about the type of attack. ========================================================================== http://www.quadrunner.com/~chuegen/smurf.txt THE LATEST IN DENIAL OF SERVICE ATTACKS: "SMURFING" DESCRIPTION AND INFORMATION TO MINIMIZE EFFECTS Craig A. Huegen chuegen@quadrunner.com Last Update: Sat Apr 11 16:48:01 PDT 1998 New additions: * Added information on "fraggle" Editor's plea: *please* distribute this information freely, and abide by my redistribution requirements (see the very end) when doing so. It's important that these attacks be minimized, and communication is the only way to help with this. 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 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 "bounce sites", and the spoofed address target, or the "victim". The victim is the target of a large amount of traffic that the bounce sites 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 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 "bounce sites" 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.internic.net/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 source spoof 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 DCEF code which is being tested by NSP's, in an interface command '[no] ip verify unicast reverse-path'. It is being evaluated for a future production mainline release. 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.. 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 all routers which provide routing to large multi-access broadcast networks (generally LANs), with more than 5-10 devices. It is unnecessary on point-to-point interfaces, such as POS, serial T1, HSSI, etc., because point-to-point interfaces will only generate two replies--one for each end of the link. No testing has been done on multi-point frame-relay; however, routers on NBMA networks typically do not forward broadcasts unless explicitly configured to do so. Point-to-point sub-interface models will behave like many point-to-point links--again, this command will have little effect, stopping only one of the two replies. Other vendor information: * Proteon/OpenROUTE: Daniel Senie (dts@senie.com) 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. * Bay Networks: Jon Green (jcgreen@netins.net) reports that under current code, there is no way to keep Bay Networks routers from converting layer 3 broadcasts to layer 2 broadcasts easily. However, there is a feature request (bugID CR33408) to add a configuration option, and it is expected to be in BayRS version 12.0. A workaround is to set a false static ARP address in the router for the broadcast address of the LAN you wish to protect, or set a false static host route for the broadcast address. * 3Com NETBuilder products: Mike Kouri (Mike_Kouri@3com.com) 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 ! -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." 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 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. "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 uncomment 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. (This next section assumes IOS behavior with standard central switching-- FIB/CEF isn't covered here, the behavior is different, I believe.) 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), 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. Efforts are underway to integrate these fixes in the other major versions and branches as well. 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 bounce sites or intermediaries to track the spoofed echo _request_ packets back to their source (the perpetrator). MCI's Internet Security team has put together a perl script which, in an automated fashion, can log into your Cisco routers and trace a spoof attack back to its source. The program is available, free of charge. See http://www.security.mci.net/dostracker/ for more information. 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 "SMURF UPDATE": Since this document was published in October, 1997, we have seen significant reductions in the amount of smurf attacks. From the statistics gathered on noticeable smurf attacks, we have seen a reduction in average bandwidth used on a smurf attack from 80 Mbps to 5 Mbps. Additionally, there has been a reduction in the number of noticeable smurf attacks (by about 50%). Fraggle attacks are not widely used as the same methods of prevention for ICMP smurf work for UDP fraggle. 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. Specific thanks to: * Ravi Chandra of Cisco Systems for information on the bugfixes. * Daniel Senie of BlazeNet, Jon Green of Bay Networks, Mike Kouri of 3Com for information on other vendors' equipment. * Paul Ferguson of Cisco Systems, Kelly Cooper of GTE/BBN, Rob McMillan of CERT for sanity-check and review comments. 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. 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 (chuegen@quadrunner.com) 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 chuegen@quadrunner.com http://www.quadrunner.com/~chuegen/smurf.txt ========================================================================== -- ------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at domain