October 1998 - Test - lists.nanog.org

Even more unusual traffic
by Jesse Whyte 20 Oct '98

20 Oct '98

I apologize for sending three messages, but in the review of our access-list violations, I have discovered even more odd and unusual traffic... Oct 13 11:49:03 protecting.router.ip.address 46: %SEC-6-IPACCESSLOGP: list 102 denied udp 10.10.10.10(0) -> 20.20.20.20(0), 3 packets Oct 13 11:54:03 protecting.router.ip.address 48: %SEC-6-IPACCESSLOGP: list 102 denied udp 10.10.10.10(0) -> 20.20.20.20(0), 3 packets Oct 13 13:49:06 protecting.router.ip.address 50: %SEC-6-IPACCESSLOGP: list 102 denied udp 10.10.10.10(0) -> 20.20.20.20(0), 2 packets Oct 13 13:54:07 protecting.router.ip.address 52: %SEC-6-IPACCESSLOGP: list 102 denied udp 10.10.10.10(0) -> 20.20.20.20(0), 2 packets IANA lists port 0 as reserved (failing to note what it is reserved for), so why am I seeing this traffic in the wild? What is its function, both as a source port and a destination port? And more importantly, why is someone trying to access it on my primary DNS server? Your help is appreciated... Jesse Whyte Security Analyst Office of Information Resources State of Tennessee (615)741-8651

2 1

Wired News on Backhoe Troubles
by James Glave 20 Oct '98

20 Oct '98

http://www.wired.com/news/news/technology/story/15645.html Back, Back! Dreaded Hoe by Chris Oakes , Wired News 4:00 a.m. 19.Oct.98.PDT Participants in the North American Network Operators Group email discussion list -- the primary shop talk forum for telecom and ISP engineers -- have been bandying about ideas for a new T-shirt. One prototype features the black profile of a backhoe, the staple machine of construction crews everywhere. A massive shovel hangs off an insect-like arm, suspended above four giant tires. It's not the image you'd expect for folks who deal in circuits, switches, and packet flow. But there's something else: The backhoe is positioned within the crosshairs of a firing device. Do we have a problem with backhoes here? (more.....) James Glave, News Editor, Wired News, http://www.wired.com (415) 276-8430

1 0

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

20 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 20 Oct '98

20 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 20 Oct '98

20 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 20 Oct '98

20 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 20 Oct '98

20 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 20 Oct '98

20 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