- Test - lists.nanog.org

Re: Fair Queuing combats DDoS? [was Re: Yahoo! Lessons Learned ]
by Alex Bligh 10 Feb '00

10 Feb '00

Alexei Roudnev (alex(a)genesyslab.com) said: > [deploy WFQ and RPF universally] > Then , if someone want to kill yahoo (for example), he need a few > thousands different data streams to do it - which is impossible. Several thousand different data streams is exactly what DDoS is. Also there is a presumed high correlation with people who do not secure their servers adequately againts intrusion (and thus turning these things into DDoS clients) and people who do not run RPF right next to those servers. Therefore this is only 'impossible' if there are not more than 2000 servers sitting on clueless or fallible peoples network. Recent experiences with internet scaling suggest even if this were true now (which it isn't), it won't last long. -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)

1 0

Re: [Re: Which Part(s) Failed in the recent DOS Attacks?]
by Toplez Razer 10 Feb '00

10 Feb '00

Joe, Firewall-1 has the SynDefender and Cisco IOS 12.0 has TCP Intercept for stopping TCP DOS. Could these features stop massive TCP DOS attacks? Thanks, Audie Onibala ****************************** Joe Shaw <jshaw(a)insync.net> wrote: On 9 Feb 2000, Toplez Razer wrote: > 1. Was it the firewall DOS filter? With packet based DoS attacks, filters don't matter. Bandwidth and saturation are what matters. > 2. No firewall in Yahoo, EBay, ETrade, etc? Yes, there are, and no, they wouldn't have helped for the reason stated above. > 3. Firewall DOS filter worked, but the links were still clogged with massive > ACKs/NACKs? Not exactly, but fairly close. -- Joseph W. Shaw - jshaw(a)insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am." ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

3 3

Re: Info on the DoS attacks.
by Sean Donelan 10 Feb '00

10 Feb '00

On Wed, 09 February 2000, Joe Shaw wrote: > I'd be worried if they didn't have theories or know about the known DDoS > attacks, but not if they didn't have specifics. Tier1 NSP's seem to be > very tight lipped about these sorts of things when they are the > victim. I'm sure there are GC employees on this list, but none have come > forward to give any details. Could be a gag order, which wouldn't shock > me at all. Hopefully we'll know something eventually, but for now we're > all mushrooms when it comes to official information. I guess the techies reduced to reading the New York Times for technical details. Today's NYT has a description from GlobalCenter's PR person. The Yahoo attack was a large number of ICMP EchoReplies(PINGs) coming via GlobalCenter's 50 peering connections (about half of GlobalCenter's total peering connections). Which may explain the "50" number I've been hearing. The original ICMP EchoRequests listed Yahoo as the source address and were directed to other networks which replied to Yahoo. GlobalCenter installed rate-limits, but didn't know if they are effective in preventing attacks. Yahoo's spokesperson confirmed GlobalCenter's account. (free NYT registration required) http://www.nytimes.com/library/tech/00/02/biztech/articles/10attack.html Note: other people have sent me private mail saying it was actually a different method, but this appears to be the official statement out of GlobalCenter and Yahoo.

2 1

Re: identifying ASN
by Ramin Sepehr Rad 10 Feb '00

10 Feb '00

On Thu, 10 Feb 2000, Mark Kent wrote: > > With all this talk of tracing attacks I just noticed that > whois -h whois.arin.net > seems to not be as informative as it used to be. > > When looking up various ASN I sometimes get the information I want, > but frequently I get: > > Sorry, you shouldn't see this record. > > or > > No match for ASN "..." > > (Sample ASes are 2855, 5400, 9057, 11486) > > Did I miss some policy change? > > -mark > > P.S. Fortunately, various radb-like entities still list > information for a lot of ASes. Hello Mark, ARIN is aware one of our servers was not reporting proper results to some WHOIS queries. This has been fixed and measures have been taken to ensure this does not occur in the future. Best Regards, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Ramin Sepehr Rad American Registry for Internet Numbers | | raminr(a)arin.net 4506 Daly Drive | | (703) 227-9876 Suite 200 | | (703) 227-0676 (FAX) Chantilly, VA 20151 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Yahoo! Lessons Learned
by Henry Kilmer 10 Feb '00

10 Feb '00

owen(a)exodus.net writes: >> Last time I tested it, RPF would still fail if it wasn't the way >> packets would flow (not *could* flow). If that has changed, then this >> would work. >> >> >If it hasn't changed, then I think there's a pretty good case for pressuring >the various vendors to make it so. I have to admit, I always thought that >was the case, that there had to be a route out the reverse path, whether >it was preferred or not. > >Thoughts? It would definately make it more useful.

1 0

FW: identifying ASN
by Marsh, Jerry 10 Feb '00

10 Feb '00

Web to the ARIN WHOIS location and enter: ASN xxxx > ---------- > From: Mark E. Mallett[SMTP:mem@mv.mv.com] > Sent: Thursday, February 10, 2000 10:51 AM > To: mark(a)noc.mainstreet.net > Cc: nanog(a)nanog.org > Subject: Re: identifying ASN > > > > > > > > With all this talk of tracing attacks I just noticed that > > whois -h whois.arin.net > > seems to not be as informative as it used to be. > > > > When looking up various ASN I sometimes get the information I want, > > but frequently I get: > > > > Sorry, you shouldn't see this record. > > > > or > > > > No match for ASN "..." > > > > (Sample ASes are 2855, 5400, 9057, 11486) > > > > Did I miss some policy change? > > I noticed this a little while ago and reported it to noc(a)arin.net - > > 10# host whois.arin.net > whois.arin.net has address 192.149.252.22 > whois.arin.net has address 192.149.252.21 > > My perspective is that the .22 server seems to be messed up, and > that querying the .21 server gets good results. > > -mm- >

1 0

identifying ASN
by Mark Kent 10 Feb '00

10 Feb '00

With all this talk of tracing attacks I just noticed that whois -h whois.arin.net seems to not be as informative as it used to be. When looking up various ASN I sometimes get the information I want, but frequently I get: Sorry, you shouldn't see this record. or No match for ASN "..." (Sample ASes are 2855, 5400, 9057, 11486) Did I miss some policy change? -mark P.S. Fortunately, various radb-like entities still list information for a lot of ASes.

4 3

Re: Yahoo! Lessons Learned
by Vadim Antonov 10 Feb '00

10 Feb '00

Dan Hollis <goemon(a)sasami.anime.net> wrote: > The best penalty of all - simply pulling customer's plug till they fix > their network, with a repeat offense resulting in permanent disconnection. Heh. Engineering guys who try to do that very quickly find very irate sales and management types screaming abuse at them :( The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side. --vadim

17 32

Re: FBI / NIPC released a DDoSD detection tool?
by Declan McCullagh 10 Feb '00

10 Feb '00

Those binaries have been there for about a month, the same time as the Feds published the "trinoo" alert (about half a year late, but who's counting). This page has the date: http://www.fbi.gov/nipc/welcome.htm Somehow I doubt that the NIPC wrote the code. -Declan At 10:44 2/10/2000 -0600, Rodney Caston wrote: >I'm not sure if this is news or not, but looking at >http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released >binaries, (no source code, the jerks), for tools to detect if a box has >trin00, tribal flood net, tfn2k and some other DDoSD's on it. > >So far they have a sparc solaris, intel solaris, and x86 linux binary for >download. While I am shocked to see a government agency writing >potentially usefull code so quickly, I am dissappointed they didn't >release their source code so it can be ported to say.. FreeBSD? .. AIX .. >HP/UX ... and so on... > > >Rodney Caston >Southwestern Bell >Internet Services > >

1 0

Re: Strange announcements
by Danny McPherson 10 Feb '00

10 Feb '00

This was resultant of some left over garbage from a deomonstration I was planning to perform during the route filtering panel Tuesday morning, I had forgot about it (JUST KIDDING!!!). It's obvious that it was the result of a configuration error and it's long since been corrected. Fortunately, it didn't [completely] break anything. It does, however, serve as a nice follow-on to my comments regarding providers needing the ability to perform prefix-based filtering on a per-peer level in addition to the current "just BGP customer routes are filtered". Filtering of this level would require vendors to support hundreds of thousands of lines of ingress prefix-based filtering policies, something that's not __completely available today. Presumably, this same set of policies could also be used to perform unicast RPF-type functions WRT SA-based packet filtering. This would scope the effects of IP spoofing considerably, and remove some of the vulnerabilities regarding unauthenticated origination of BGP routes. A widely-deployed explicit acceptence model (prefix filtering) would also allow providers (who are concerned with de-aggregation and the like hosing their routers) to remove prefix-length based policies, and Save all the "rural" multi-homed folks. Of course, this also assumes that scalable backend infrastructure and systems are in place to authenticate database object entries, etc.. Then again, an SS7-type solution with backend databases and an out-of-band network populating SCPs, along with a completely static transport system, provides support for number portability, perhaps we're simply overlooking something? -danny [snip] To QWEST NOC PEOPLE Folks, You appear to be announcing 198.133.219.0, which is the network that www.cisco.com lives on, whats strange is that you are then transiting this route onto GTEI [AS1] to deliver the traffic. This is fairly sub-optimal and I'm sure incorrect. kenny>sh ip bgp 198.133.219.25 BGP routing table entry for 198.133.219.0/24, version 23258497 Paths: (4 available, best #1, advertised over IBGP) 3356 209 209.244.160.57 from 209.244.160.57 (209.244.2.210) Origin IGP, metric 4401, localpref 100, valid, external, best 3356 209, (received-only) 209.244.160.57 from 209.244.160.57 (209.244.2.210) Origin IGP, metric 4401, localpref 100, valid, external 1 109 4.1.74.105 from 4.1.74.105 (4.0.4.8) Origin IGP, metric 11340, localpref 100, valid, external Dampinfo: penalty 492, flapped 1 times in 00:00:23 1 109, (received-only) 4.1.74.105 from 4.1.74.105 (4.0.4.8) Origin IGP, metric 11340, localpref 100, valid, external kenny>traceroute www.cisco.com Type escape sequence to abort. Tracing the route to www.cisco.com (198.133.219.25) 1 serial4-0-3.hsa1.nyc1.Level3.net (209.244.160.57) [AS 3356] 0 msec 0 msec 0 msec 2 hsipaccess2.Denver1.Level3.net (209.244.2.61) [AS 3356] 48 msec 48 msec 48 msec 3 hsipaccess2.Seattle1.Level3.net (209.244.2.23) [AS 3356] 76 msec 72 msec 76 msec 4 209.0.227.130 [AS 3356] 76 msec 200 msec 148 msec 5 sea-core-01.inet.qwest.net (205.171.26.53) [AS 209] 76 msec 72 msec 76 msec 6 sfo-core-02.inet.qwest.net (205.171.5.105) [AS 209] 84 msec 84 msec 84 msec 7 sjo-core-01.inet.qwest.net (205.171.5.121) [AS 209] 80 msec 80 msec 80 msec 8 sjo-edge-05.inet.qwest.net (205.171.22.46) [AS 209] 84 msec 84 msec 80 msec 9 a5-0-1.sanjose1-nbr1.bbnplanet.net (4.24.145.1) [AS 1] 84 msec 84 msec 84 msec 10 p4-0.paloalto-nbr2.bbnplanet.net (4.0.1.1) [AS 1] 84 msec 84 msec 84 msec 11 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) [AS 1] 84 msec 84 msec 84 msec 12 * * * 13 pigpen.cisco.com (192.31.7.9) [AS 109] 88 msec 88 msec 88 msec 14 www.cisco.com (198.133.219.25) [AS 209] 88 msec 84 msec 88 msec A fix/explanation would be useful. Regards, Neil. -- Neil J. McRae C O L T I N T E R N E T neil(a)COLT.NET

1 0