- NANOG - lists.nanog.org

Re: Actions to quiet the Smurf amplifiers?
by Danny McPherson 19 Oct '98

19 Oct '98

ingress filtering .. that's a novel idea :-) -danny Phil Howard wrote: > >The method involves a software design change in the routers. For each >arriving packet, in addition to doing a routing lookup based on the >destination, also do a routing lookup based on the source address. >If the interface the packet arrived on is NOT in the list of addresses >that routing back to the source suggests, then discard the packet. >That will drop the majority of packets before they even read smurf >amplifiers, as they are generally forge-sourced to the ultimate target >of the attack. The first router hop with this implemented where the >source address is invalid will stop the attack. The core backbone >probably does not need to have this enabled, but all the leafs from it >should to ensure no forged sources can get through.

2 1

Actions to quiet the Smurf amplifiers?
by Havard.Eidnes＠runit.sintef.no 19 Oct '98

19 Oct '98

Hi, a few months ago there was quite a bit of talk about publishing known Smurf amplifier networks. I've been exchanging a few e-mails with one of the guys maintaining the smurf amplifier registry at http://www.powertech.no/smurf/ He tells me that since they started, several thousand entries have been fixed. However, the list is still quite a moutful (860KB in dense format, approx. 11.000 entries, no less!). It would appear that we (collectively) are not doing a sufficient job to remove this at times quite bothersome problem. One thing is that there's been lots of talk about preventing source IP address spoofing, but apparently not enough has happened there. Going after the networks being abused as amplifiers is quite a bit easier since they can be easily identified. Massaging the condensed list mentioned above and adding up the entries for the origin the route was seen with at the time the prefix was bound to an AS, the top of the (rather long!) list comes out as something like this: AS# Ampl. %ampl AS name AS174 6427 6.24 PSINet Inc. AS3561 4337 4.21 Cable & Wireless USA AS701 4152 4.03 UUNET Technologies, Inc. AS1239 2545 2.47 Sprint AS1 2372 2.30 BBN Planet AS568 2149 2.09 DISO-UNRRA AS2551 1721 1.67 NETCOM On-Line Communication Services, Inc. AS2548 1710 1.66 Digital Express Group, Inc. AS1785 1549 1.50 Sprint, Government Systems Division not-analyzed 1478 1.44 AS7018 1420 1.38 AT&T AS2900 1244 1.21 Arizona Tri University Network AS268 983 0.95 Uniformed Services University of the Health Sciences "Ampl." is the sum of the amplification factor for the amplifier nets that were announced with this AS number as the home AS in BGP when each prefix was bound to a BGP route. "%ampl." is the percentage of the total sum of the amplifier factors for all the networks in the list. Folks, it would seem that there's ample work left to inform your customers that they should take the necessary precautions to prevent their networks from being inundated with traffic by being exploited as an amplifier in a "Smurf" denial-of-service attack. It might be a good idea to point out that doing the work to prevent this from happening is also in their own best self-interest. Lastly, I'd like to get some idea as to how best to attack this problem -- the present method of "public list of shame" of the providers with the amplifiers as "local sources" is one method, but I'm far from certain that it will be effective. Comments appreciated. - Håvard

7 8

Unusual Traffic
by Jesse Whyte 19 Oct '98

19 Oct '98

This traffic is getting denied by my ingress Internet filters designed to stop spoofed internal addresses. However, I have yet to see traffic that has this pattern. The site in question has no alternate Internet connection that could be resending this traffic. As the ingress points in question are the legitimately advertised connections (via BGP), I can't think of any other reason this traffic should be appearing. However, I really do not understand what an attacker would gain with probe packets like this. The return traffic should (in an ideal world) simply get redirected to the loopback interface. But then again, this world is far from ideal, necessitating this message. Oct 13 13:33:04 ingress.router.ip.address 4267746: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(34) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(34), 1 packet Oct 13 13:33:06 ingress.router.ip.address 4267747: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(37) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(37), 1 packet Oct 13 13:33:07 ingress.router.ip.address 4267749: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(43) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(43), 1 packet Oct 13 13:33:08 ingress.router.ip.address 4267751: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(25) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(25), 1 packet Oct 13 13:33:09 ingress.router.ip.address 4267752: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(26) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(26), 1 packet Oct 13 13:33:11 ingress.router.ip.address 4267754: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(28) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(28), 1 packet Oct 13 13:33:14 ingress.router.ip.address 4267755: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(31) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(31), 1 packet Oct 13 13:33:16 ingress.router.ip.address 4267757: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(32) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(32), 1 packet Oct 13 13:33:17 ingress.router.ip.address 4267758: %SEC-6-IPACCESSLOGP: list 113 denied udp 50.50.50.50(33) (Ethernet1/5 0010.117d.fc08) -> 50.50.50.50(33), 1 packet Thanks for your help...Please note that the ip address (50.50.50.50) is NOT the real IP of the target in question... Jesse Whyte Security Analyst Office of Information Resources State of Tennessee (615)741-8651

1 0

Odd UDP traffic between secondary servers
by Jesse Whyte 19 Oct '98

19 Oct '98

The environment is fairly typical...one primary DNS server and three secondary servers. One of the secondary servers is on the same subnet as the primary DNS server and the other two are distributed across the Wide Area Network. Of these two remote secondary servers, I see traffic like the following every day in my access-list violations, where ROUTER-WITH-ACL is the router protecting the REMOTE-SECONDARY-2... Oct 11 01:17:07 ROUTER-WITH-ACL 113128: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36070), 1 packet Oct 11 01:18:37 ROUTER-WITH-ACL 113139: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36075), 1 packet Oct 11 01:18:42 ROUTER-WITH-ACL 113140: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36076), 1 packet Oct 11 01:18:47 ROUTER-WITH-ACL 113141: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36077), 1 packet ... Oct 11 03:05:42 ROUTER-WITH-ACL 113623: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36120), 1 packet Oct 11 03:05:47 ROUTER-WITH-ACL 113624: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36121), 1 packet Oct 11 03:05:57 ROUTER-WITH-ACL 113625: 1w3d: %SEC-6-IPACCESSLOGP: list 114 denied udp REMOTE-SECONDARY-1(53) -> REMOTE-SECONDARY-2(36122), 1 packet As you can see, the destination port increments by one on each attempt and this entire process occurs over the period of several hours. This traffic is entirely unidirectional...I do not see any similar traffic on the access list protecting REMOTE-SECONDARY-1. What is the nature of this traffic and should I be concerned? It is obviousely not a zone transfer, and there is no forwarders directive in either config file, so I'm at a loss. Thanks in advance for your help... Jesse Whyte Security Analyst Office of Information Resources State of Tennessee (615)741-8651

1 0

Re: Actions to quiet the Smurf amplifiers?
by Brian Dickson 19 Oct '98

19 Oct '98

On Sat, 17 Oct 1998 Havard.Eidnes(a)runit.sintef.no wrote: > Lastly, I'd like to get some idea as to how best to attack this > problem Well, it is far from the best solution, but here's a suggestion that may be feasible in the interim (ie, while whacking on owners of smurf-amlifiable networks): - establish a site similar to the RBL, as an anti-smurf clearinghouse - have said site do BGP peerings, and announce, as /32's, the broadcast addresses of smurf-nets - have enough major-backbone networks use this mechanism to significantly dampen smurf until it becomes an occasional, localized nuisance Note that doing these as /32's means connectivity to the genuine network is unaffected. Only packets destined for broadcast addresses, ie smurf attacks, will be blackholed - and this before they get amplified. While the total number of network entries may be large initially, aggressive efforts by providers to take ownership of pieces of address space belonging to customers, may quickly reduce the global requirements. E.g., If provider X has 1000 such networks belonging to his single-homed customers, and he static-routes these 1000 /32's himself, this offloads the centralized anti-smurf AS. If 20 such ISPs do this, most of the problem goes away. Major backbones ought not bear the brunt of much of this sort of junk, but in this instance, it may be the best place to do this. The big ISPs will generally have enough memory on their core nodes to handle the additional routes, will be running CEF (so can discard smurf traffic almost for free), and will have much greater effectiveness in doing this. However, the more ISPs that involve themselves, the closer to the offender the traffic will get nuked, and the more likely that the attemt will be logged by the offender's ISP and thus result in termination due to violation of ISP's policies (you do have policies against DoS, right folks?). Comments? -- Brian Dickson, Email: briand(a)teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com

1 0

Re: SONET ring questions
by Tony Li 19 Oct '98

19 Oct '98

pete(a)cobra.brass.com (Peter Polasek) writes: > This interface is extremely mission critical to the point > that a 99.9% uptime will not be acceptable. I have the following > questions: > > 1) Bell Atlantic assures us that, because of the redundancy, we can > expect 100% uptime from the OC-12. I would like feedback as to > whether this is a realistic portrayal of the SONET environment. How many significant digits do you consider acceptable? Even in an ideal APS environment, link failure detection and protection switching does take finite time. You might get 99.999% uptime, but probably not 99.9999999%. Methinks that you've been subjected to Marketing. ;-) Tony

6 7

Major Texas Outages
by Deborah Ann Smith 19 Oct '98

19 Oct '98

Major circuits down around San Antonio and Austin due to inclement weather.. (Flooding in San Antonio, Tornados and rain all over). Expect more problems as Storm heads northeast to Houston. National Guard is letting no one into failure area in San Antonio. All Telcos and ISPs with lines in that area affected. Worldcom stopped counting after 75+ DS3s went down. SWB stopped dispatches around 9pm. EST (See National Guard). -Deb ------------------~~~~~~~~~~~~~~~~~---------------~~~~~~~~~~~~~~ Deborah A. Smith das(a)digex.net Because I can ~~~~~~~~~~~~~~~~~~~----------------~~~~~~~~~~~~~~~~---------------

2 1

WARNING: AOL is hosed (again)
by Stephen Sprunk 19 Oct '98

19 Oct '98

Just for those who aren't aware yet, all your mail to aol.com is about to bounce. sprunk@pegasus:~> host -t ns aol.com c.root-servers.net Using domain server: Name: c.root-servers.net Address: 192.33.4.12 Aliases: aol.com name server DNS2.AUTONET.NET aol.com name server DNS1.AUTONET.NET sprunk@pegasus:~> host -t mx aol.com dns.autonet.net Error in looking up server name: Host not found. -- | | Stephen Sprunk, KD5DWP, CCIE #3723 :|: :|: NSA, Network Consulting Engineer :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Pager: 800-365-4578 / 800-901-6078 C I S C O S Y S T E M S Email: ssprunk(a)cisco.com

9 10

Re: Encouraging smurf-amp measurements
by Richard Steenbergen 19 Oct '98

19 Oct '98

>This is encouraging news: > >I ran a scan for smurf-amps of /24s in 200/8 through 210/8 in late >July that yielded 30,083 networks that returned duplicate >echo-replies. Today, I rescanned those networks, and found that of the >original 30k, only 21,255 returned duplicates -- that's a 29% drop. > >Whether it means that more networks overall are properly configured, or >that different networks are misconfigured, I know not. Optimistically, >I'd like to guess that the former is true, but a complete scan would >be necessary to know. Its an actual across-the-board drop. If you eliminate the puny bcasts (less then 10 dupes) the numbers are even better. I've got a project setup to automatically scan everything in the bgp routing table, grab contact information for the UPLINK (99.9% of those bcasts remaining are ones with dud contact info), send out aggregated emails to said uplinks, and maintain a database of useful statistics. The only thing I'm waiting on is certain persons coughREIDcough coughSTEVEcough to get off their arses and finish what they said they would a couple months ago. =) -- Richard Steenbergen <humble(a)lightning.net> http://www.bitchx.com/~humble humble@EFnet hkp://keys.pgp.com/humble@lightning.net PGP KeyID: 0x21581362 PGP key fingerprint: 7552 6AB2 B9C7 5A1B F1B6 8EA3 DFCF 793D 2158 1362 "I tried sniffing Coke once, but the ice cubes got stuck in my nose!"

1 0

Encouraging smurf-amp measurements
by mark＠vielle.datasys.net 18 Oct '98

18 Oct '98

This is encouraging news: I ran a scan for smurf-amps of /24s in 200/8 through 210/8 in late July that yielded 30,083 networks that returned duplicate echo-replies. Today, I rescanned those networks, and found that of the original 30k, only 21,255 returned duplicates -- that's a 29% drop. Whether it means that more networks overall are properly configured, or that different networks are misconfigured, I know not. Optimistically, I'd like to guess that the former is true, but a complete scan would be necessary to know. mrl

1 0