- NANOG - lists.nanog.org

DoS yada yada yada
by Richard A. Steenbergen 14 Jul '01

14 Jul '01

I'd just like to take a quick opportunity to clear up some misconceptions on the subject of Denial of Service which seem to have been running rampant around here. First off, I am a longer time EFNet user as well as a former EFNet admin, and I have probably been the target of every type of DoS you could imagine at one point or another. You should not mistake cynicism for a particular chat network for apathy about DoS. I also do not believe IRC as a service is any less deserving of protection from attacks, but I do believe it is far more explainable. Secondly, let's not kid ourselves about where DoS comes from. If EFNet has earned one distinction, it is as the source of every major DoS currently in use against the internet. These programs don't write themselves, nor do people learn to use them effectively for no reason. By far the VAST majority of EVERY attack anyone on this list will EVER see *IS* related to IRC, and if you think "la de da I'm just an innocent little network who gets attacked for no reason" then you obviously don't know what your users are doing. The attacks against other targets like yahoo ebay etc are very rare and happen only as a result of packet kids building a network for use against their IRC targets and then realizing there is a whole world out there that doesn't see attacks like this on a regular basis. Let's also get off our delusions of power that help us deal with the powerlessness of being a DoS victim, no one has filed serious litigation against a network for their unintentional involvement in a DoS, and if anyone does it surely won't be EFNet. We all want someone to blame, but the reality of the matter is that the vast majority of attack sources are victims without any real negligence, and the vast majority of attacks are simply not going to be traced back to the person responsible. None of this changes the fundamental need to design networks which are resistant to malicious disruption, but let's at least try to deal with the reality of the situation. One other comment I'll make for the people who take IRC so seriously as to get bent out of shape over these words: It's just IRC. Repeat that to yourself at least 10 times every night. And one last request, unless you really have something to contribute, please don't reply to this on-list. Thanks. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 7

The Cidr Report
by cidr-report＠cisco.com 14 Jul '01

14 Jul '01

This is an auto-generated mail on Fri Jul 13 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to cidr-report(a)cisco.com. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 13Jul01 0) General Status Table History ------------- Date Prefixes 060701 101036 070701 100965 080701 100869 090701 100962 100701 100995 110701 101196 120701 101105 130701 100848 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11205 Number of ASes announcing only one prefix: 6646 (3807 cidr, 2839 classful) Largest number of cidr routes: 863 announced by AS701 Largest number of classful routes: 1429 announced by AS701 1) Gains by aggregating at the origin AS level --- 13Jul01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1335 997 338 25.3% Telstra Pty Ltd AS701 1429 1212 217 15.2% UUNET Technologies, Inc. AS4293 395 281 114 28.9% Cable & Wireless USA AS6595 161 57 104 64.6% DoD Education Activity Networ AS13999 104 8 96 92.3% Mega Cable S.A. de C.V. AS705 232 137 95 40.9% UUNET Technologies, Inc. AS6429 200 108 92 46.0% RdC Internet AS7018 730 639 91 12.5% AT&T AS4755 211 120 91 43.1% VSNL India AS2568 146 55 91 62.3% CTS Network Services AS4151 160 78 82 51.2% USDA AS8013 296 216 80 27.0% PSINet Ltd. Canada AS577 246 173 73 29.7% Bell Canada AS724 237 165 72 30.4% DLA Systems Automation Center AS7046 311 247 64 20.6% UUNET Technologies, Inc. AS6471 122 59 63 51.6% ENTEL CHILE S.A. AS3464 151 90 61 40.4% Alabama SuperComputer Network AS16473 113 54 59 52.2% Bell South AS16758 63 6 57 90.5% IKON Office Solutions AS1 570 514 56 9.8% BBN Planet AS1239 440 385 55 12.5% Sprint ICM-Inria AS226 144 91 53 36.8% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS3908 202 151 51 25.2% Supernet, Inc. AS17561 112 61 51 45.5% Internet Service West Austral AS852 215 165 50 23.3% Telus Advanced Communications AS9842 54 5 49 90.7% Lotte Data Communication Comp AS2149 317 268 49 15.5% Performance Systems, Inc. AS5106 81 33 48 59.3% Ameritech Advanced Data Servi AS4323 231 183 48 20.8% Time Warner Communications, I For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Cisco's connected->bgp redistribution
by alex＠yuriev.com 13 Jul '01

13 Jul '01

Hello, Can anyone shed some light on why cisco ignores "ip classless" when redistributing classless connected routes into bgp, making things such as /30 into /24s? Thanks, Alex

3 2

BigRed.com - cache poisoning for com/net/org domains
by Mike Batchelor 13 Jul '01

13 Jul '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was a weird problem posted to this list by Tim Langdell on May 24, 2001 (see http://www.mcabee.org/lists/nanog/msg01330.html) I am experiencing the same problem, though I am certain it is not due to any registry hacks/trojans/virii on the Windows clients, as Tim's message thread suggested. The problem is that my Win2K DNS server is resolving non-existent domains under com, net or org, to the bigred.com website at 64.177.155.101, instead of giving NXDOMAIN as it should. Let me show you what I have found in my poisoned cache. I did all these queries from a Unix host that resolves through a different nameserver that has not been poisoned. My Win2K DNS server, which services Windows clients on our LAN, is the one I am querying at 172.25.1.104. Check it out: ; <<>> DiG 8.1 <<>> @a.gtld-servers.net nosuchdomainexists.com. any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = ANY, class = IN ;; AUTHORITY SECTION: com. 1D IN SOA A.GTLD-SERVERS.NET. hostmaster.nsiregistry.NET. ( 2001071201 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum ;; Total query time: 96 msec ;; FROM: upolu to SERVER: a.gtld-servers.net 192.5.6.30 ;; WHEN: Fri Jul 13 11:58:03 2001 ;; MSG SIZE sent: 40 rcvd: 117 OK, so such domain exists in the gTLD servers. So far so good. But my Win2K DNS says otherwise: ; <<>> DiG 8.1 <<>> @172.25.1.104 nosuchdomainexists.com. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = NS, class = IN ;; ANSWER SECTION: nosuchdomainexists.com. 4m51s IN NS ns.above.net. nosuchdomainexists.com. 4m51s IN NS ns.eli.net. ;; ADDITIONAL SECTION: ns.above.net. 22h35m53s IN A 207.126.96.162 ns.eli.net. 23h54m5s IN A 209.63.0.2 ;; Total query time: 4 msec ;; FROM: upolu to SERVER: 172.25.1.104 ;; WHEN: Fri Jul 13 11:58:24 2001 ;; MSG SIZE sent: 40 rcvd: 119 Fascinating. Both of these nameservers say NXDOMAIN for nosuchdomainexists.com, same as the gTLD servers. Now check this out. I ask my cache for the A record of the non-existent domain: ; <<>> DiG 8.1 <<>> @172.25.1.104 nosuchdomainexists.com. a ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = A, class = IN ;; ANSWER SECTION: nosuchdomainexists.com. 59m40s IN A 64.177.155.101 ;; Total query time: 3 msec ;; FROM: upolu to SERVER: 172.25.1.104 ;; WHEN: Fri Jul 13 11:58:47 2001 ;; MSG SIZE sent: 40 rcvd: 56 Once I have made this query, the Win2K cache has some different glue for it: ; <<>> DiG 8.1 <<>> @172.25.1.104 nosuchdomainexists.com. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = NS, class = IN ;; ANSWER SECTION: nosuchdomainexists.com. 59m27s IN NS dnsc.nsq.com. ;; ADDITIONAL SECTION: dnsc.nsq.com. 59m38s IN A 66.34.52.233 ;; Total query time: 13 msec ;; FROM: upolu to SERVER: 172.25.1.104 ;; WHEN: Fri Jul 13 11:59:01 2001 ;; MSG SIZE sent: 40 rcvd: 79 Iiiiinteresting. But what else is f'ed up here? I ask my Win2K cache for the address of a.gtld-servers.net and get back 66.34.52.224. In fact, my cache says all the gTLD servers have this address, except for z.gtld-servers.net (yes, "z") for which it gives the address 198.41.3.40. Non-existent gtld-servers.net get the address of the bigred.com website from my Win2K cache. Thing is, the nameserver at 66.34.52.224 is lame for names under gtld-servers.net, and refers me back to the correct names and addresses for the root zone. It is also lame for the nosuchdomainexist.com name that I was testing with. What gives???? How did my cache get poisoned, and how can the poisoning be continuing to affect resolution this way, when none of the poisoned glue appears to work at all?? I'm totally stumped. - --- ALL YOUR BASE ARE BELONG TO US SOMEBODY SET UP US THE BOMB -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO09tr0ksS4VV8BvHEQK7owCgxXlaFfUUGpOdemmgBhXk9IH180cAn3oc OjC8lHvY0wGs7J7FciTyZXmB =dcfg -----END PGP SIGNATURE-----

1 0

Re: Cisco's connected->bgp redistribution
by Dave Israel 13 Jul '01

13 Jul '01

Alex, Make sure you don't have "auto-summary" turned on. Auto-summary is always classful, and therefore nearly always evil. -Dave On 7/13/2001 at 16:20:40 -0400, alex(a)yuriev.com said: > > > Hello, > Can anyone shed some light on why cisco ignores "ip classless" when > redistributing classless connected routes into bgp, making things such as > /30 into /24s? > > Thanks, > Alex > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

3 2

RE: DoS yada yada yada
by Roeland Meyer 13 Jul '01

13 Jul '01

> From: Richard A. Steenbergen [mailto:ras@e-gerbil.net] > Sent: Thursday, July 12, 2001 10:18 PM > As has been mentioned on here before, the "0 day elite packet > juarez" I'm > allegidly responsible for is stream.c. I wrote the core for a former > employer to test Cisco equipment for failure modes and > improve filtering. > A coworker stole and released the code as "stream.c" 6 months > later, as > "packet juarez". I came forward and admitted I knew the > origins of this > code, and proceeded to educate people on how to stop it. So what's his name, so I can be sure not to accidently hire the scum-bag. -- R O E L A N D M J M E Y E R Managing Director Morgan Hill Software Company t:01 925 373 3954 c:01 925 352 3615 f:01 925 373 9781

1 0

whatever happened to RED? (was: Improving Robustness...)
by William Allen Simpson 13 Jul '01

13 Jul '01

Didn't we have a solution to this problem? And the UDP flood from Real? And a host of other problems with saturated links? My operational issue is: what is the status of RED? Being small and only having cisco and *nix routers, I'd expect it was widely deployed. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

3 2

RE: DDoS attacks
by Roeland Meyer 13 Jul '01

13 Jul '01

> From: up(a)3.am [mailto:up@3.am] > Sent: Thursday, July 12, 2001 7:23 AM > I can't help but believe that if even 20% of them > were caught and had to spend just a little time (even hours) with the > cops, and had their peecees confiscated, you'd not be seeing > nearly the problems we are now. This is the main point, a script-kiddie hunt, with prosecution, is the ONLY real deterrent. Throw some of them in hotel greybar and remove them from computing, for life, and we may see some of this turn around. If a lady wears skimpy clothing, does she deserve to get raped? Obviously, not. If a computer has skimpy protection, does it deserve to be turned into a zombie? Simply because you forget to lock your car one night (whilst in your driveway), do you deserve to have it stolen? If you leave a $100 on your kitchen table, in your unlocked house, whilst you are working in your garage, do I have the right to sneak in the back door and take it while avoiding prosecution, on the grounds that you were careless? WRT EFFnet, does a prostitute deserve to be raped? There are certain reasonable presumptions, like safety, that our society affords us. Script kiddies violate those as do the slime-bags that argue for their good. How much of our budgets have gone to protecting ourselve from those rodents? How much revenue has been lost because of their activity? They are the rats of the Internet and bring disease with them whereever they go. Their population is growing to plague proportions and they are getting bolder. It's long past time to poison the lot of them, including their supporters. Personally, I feel that the crud that writes and releases their code for them should be lobotomized. Regardless of their disclaimers, they are NOT doing a public good.

8 11

Re: NANOG Digest V1 #781
by Simon Waters 13 Jul '01

13 Jul '01

> I'm going to go way out on a limb here and say: > 1) I would prefer all attacks use spoofed sources (cause I can track it > across my net in 2 minutes) Perhaps you could enlighten me further on this - if this is a naive question off list. > Ok, that said, think about this: Today we have 1 or 2 or 3 spoofing boxes > per attack (on average), if there are 8000 IIS boxes pinging one 64k ping > per second you can really rack up the bandwidth fast. I don't think this is an issue. If by being able to notify the admin of a few boxes being used in a nonspoofed DDoS attack, we raise the bar so that larger networks must be used, we have gained real ground in the battle. Security isn't normally about absolutes, if you make something harder, without increasing the rewards less rats will do it. We need to be able to trust source IP addresses, before we can even conceive of a system that would permit mailing 8000 administrators to say 'Your box is owned'. Or implement some sort of system to pass the word to peers or transit providers that a particular source should be stopped before it reaches the boundaries of our own networks. Similarly if you want to track down the people who perpetrate the attacks (I'm not convinced this will stop as many as some people think), knowing the source IP is reliable must make life easier. If I had a set of bots, and could control them with spoofed UDP packets, or unspoofed TCP connections, which do you think I'd use?! Some analogies on the list I think are stretched, which is why I think that tracking down perpetrators will be less effective than others have suggested. 1. 7-11 analogy - the real reason people don't rob 7-11s a lot more is that they don't have any real money - the big criminals rob richer places, only the druggies rob 7-11's. This breaks down in DDoS as we can use all those 7-11's to help blackmail the bank. 2. Safe to leave your car unlocked in the street - It is fine to leave your car unlocked in my street. Indeed on one occaison I left the front door open, and came home to find the neighbours had shut it for me as they were "concerned". On the Internet you are less than a few seconds away from even the remotest corner, so your definitely in a cross between the dodgier parts of LA, a Johannisburg slum, and the Lebanon. Yes prosecutions for DDoS will discourage script kiddies, but it won't stop the people with a cause, or countries your country is at war with, or worse countries who are at war with countries who host their sites with you, or hundred of other groups. Thus prosecution may be part of the solution, but "technical" solutions will still be required, and stopping spoofing is probably a first step in the right direction to provide some of these. -- Are you using the Internet to best effect ? www.eighth-layer.com Tel: +44(0)1395 232769 ICQ: 116952768 Moderated discussion of teleworking at news:uk.business.telework

1 0

RE: Improving Robustness of Distributed Services (Re: DDoS attack s)
by Dickson, Brian 12 Jul '01

12 Jul '01

> The implementation has already been done more than once. I spent a lot of time playing around with this, years ago. I did not know that. Thanks for the correction. > The main obstacles are: > > 1) Multicast is not nearly widely enough deployed to be used as a general communications medium. I would not characterize it as such. I think it is currently close enough, so that if the folks who collectively pour their time and effort into IRC, were to coordinate on choices of (non-UUnet) upstreams that support multicast, and the remainder (those without alternatives) were to tunnel to the (now-mainstream) multicast core, the benefits would outweigh the costs. Multihoming to get multicast may not cost much, if your total multicast traffic is small. Keep in mind you only have one copy of a given multicast stream, regardless of client base. Obviously, redundant multicast upstreams is advisable, if it's an important part of your business. The current folks doing multicast (and providing transit to those customers of theirs doing multicst), at tier 1 and peering with each other, includes the likes of Above.net, Exodus, Verio, Sprint, AT&T, Global Crossing, Level 3, Ebone, ESnet, Qwest, etc. The total list (which can be seen at http://www.multicasttech.com/status/mbgp.sum ) may only total about 3% of the AS's, but it's a very good 3%. > With companies like UUnet charging outrageous rates for multicast support or refusing to support it at all, this will not change. For good or bad, there generally aren't networks *like* UUnet. (Let's not go there.) But to my knowledge, no one else charges for multicast, separately. If you give money to companies that do not support your efforts or requirements, who is to blame? Act in a coordinate fashion, and either 701 will support free (or sanely priced) multicast, or you'll be a customer of networks that already support it. > 2) IRC as it currently exists is not merely a message distribution system, ala USENET. IRC contains a lot of global state data, that has to be propagated consistantly to all portions of the network. I don't want to waste too much bandwidth on this (especially since I'm neither an IRC admin nor user), but... The global state info, consider it as a whole. Any of that info is either used for forwarding decisions (data plane), or not, ie for "administrative" purposes (eg identifying current users on a given channel), correct? (Info about other IRC servers I would categorize as data plane stuff). In a multicast, true multicast, environment, the data plane would not require *any* servers, per se. That is the important element of multicast benefit. All the state info *for forwarding* would be kept on ISP router infrastructure (yes, scaling is an issue, blah blah blah). Large (regional or national) ISPs will generally have fully redundant and dynamic multicast infrastructure, if multicast is deployed. (I'm talking MBGP/MSDP/PIM, not DVMRP; redundacy include lots of RP's.) BTW, I know of what I speak; at my previous employer (Teleglobe), we had deployed such an infrastructure internationally and participated at the MIXs, and even provided multicast transit for the multicast feed from the OSLO IETF. The "other" state information, isn't part of the forwarding chain; if that were to remain on servers, and continue to be maintained via unicast TCP, there is no need to put all the other TCP/multicast stuff in. So you would have a hybrid client, using TCP and servers for state info, and multicast/UDP for actual messages. Attacking the servers doesn't affect messaging, and any attack on part of the multicast tree, towards any particular goal (eg nuking a particular client's connection), will be transient in nature and either (a) close to the victim, thus limited in scope and number of affected clients, or (b) a moving target within the multicast-enabled infrastructure, and virtually impossible to disrupt for extended periods short of bandwidth-based attacks. So how is this any better than the current status? Well, if a server dies for whatever reason, the communication pathways themselves are unaffected, only the convenience stuff. And since that gets propogated to other servers, client side software can select alternate servers for that information. Maybe I'm missing some fine points on how IRC is implemented. (3 and 4, security and deployment/conversion/porting - I acknowledged those issues in my original message.) If there is no interest in either stopping DDOS, or in a survivable IRC network, I'll stop contributing to this thread. I'd like DDOS activity to die off, but have no opinion or interest in IRC, per se. But I'd recommend those involved in IRC give this serious consideration. Brian Dickson

2 1