July 2001 - Test - lists.nanog.org

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 12 Jul '01

12 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

RE: Speaking of DDoS attacks
by Rowland, Alan D 12 Jul '01

12 Jul '01

In my humble opinion it looks like something at your mail server. 198.108.1.26 is trapdoor.merit.edu , their mail server, which appears to be re-sending the original 10 Jul mail. The original hit their mail server 10 Jul. This copy was forwarded to your XXX (is this the actual header or are you protecting the innocent?) on 12 Jul. Your work mail server may not be properly acknowledging receipt of the list mail so Merit's server continues to re-send (for the default 4 days?) until the resend TTL. A trace to 165.135.0.253 dies at 500.Serial2-2.GW1.HNL2.ALTER.NET so I'm not sure what's hanging there but I'd look at your mail agent configuration. A second possibility is some non-standard character in your work mail address. You don't say what it is but if there is a character in it that is benign on your system but meaningful to Merit's mail system, there may be a problem. I've been the victim of a similar "attack" in the past as a result of the _ in my address. Just my 2¢ -Al -----Original Message----- From: Robert Cannon [mailto:rcannon101@yahoo.com] Sent: Thursday, July 12, 2001 1:46 PM To: nanog(a)merit.edu Subject: Speaking of DDoS attacks Speaking of DDOS attacks, there seems to be one going on associated with the NANOG list. I was wondering if anyone could offer insite. At my work address, I have received the same email from NANOG about every 10 - 15 minutes. I have received hundreds of copies of this email. Yet at this address I do not receive the repeated copies (and no one else on the list appears to have complained). If I look at the header of the email, the last hop, if I am reading it correctly, is named "zombie.la.interpacket.net" by mrbig.la.interpacket.net. I have since unsubscribed from NANOG from my work address yet still receive the emails. Also, this has been going on for over a week (since a rule filters all my nanog email into a folder, it has not bothered me too much) - every few days, the email that I am repeatedly hit with changes. Currently, the email I am being hit with is "OT: The End of Empire." Below I have pasted the header of the email I would be curious to hear people's thoughts about this. Is this a type of a DDOS? Anyone familiar with it? -B Received: from XXXX ([165.135.0.253]) by XXXX; Thu, 12 Jul 2001 16:01:40 -0400 Received: by XXXX; id QAA14070; Thu, 12 Jul 2001 16:01:38 -0400 (EDT) Received: from unknown(198.108.1.26) by XXXX via smap (V5.5) id xmaa13982; Thu, 12 Jul 01 16:00:42 -0400 Received: by trapdoor.merit.edu (Postfix) id BB70F91231; Tue, 10 Jul 2001 14:35:31 -0400 (EDT) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 896EB91251; Tue, 10 Jul 2001 14:35:31 -0400 (EDT) Delivered-To: nanog(a)trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83A3791231 for <nanog(a)trapdoor.merit.edu>; Tue, 10 Jul 2001 14:35:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79E335DE1A; Tue, 10 Jul 2001 14:36:58 -0400 (EDT) Delivered-To: nanog(a)merit.edu Received: from bond.interpacket.net (us-la-gate.interpacket.net [209.198.223.250]) by segue.merit.edu (Postfix) with SMTP id ECF9A5DDD8 for <nanog(a)merit.edu>; Tue, 10 Jul 2001 14:36:57 -0400 (EDT) Received: (qmail 31855 invoked from network); 10 Jul 2001 18:35:43 -0000 Received: from mrbig.la.interpacket.net (192.168.6.5) by bond.la.interpacket.net with SMTP; 10 Jul 2001 18:35:42 -0000 Received: from [192.168.4.53] (zombie.la.interpacket.net [192.168.4.53]) by mrbig.la.interpacket.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N6TNP8LB; Tue, 10 Jul 2001 11:39:32 -0700 Mime-Version: 1.0 X-Sender: mikey(a)popmail.la.interpacket.net Message-Id: <a05010406b770fb74762d(a)[192.168.4.53]> Date: Tue, 10 Jul 2001 11:35:52 -0700 To: nanog(a)merit.edu From: Mikey Wilsker <mikey(a)interpacket.net> Subject: OT: The End of Empire Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

2 1

DDOS prevention offensive.
by Joseph T. Klein 12 Jul '01

12 Jul '01

To move toward a positive direction ... Discuss the effect that wide spread filtering against spoofed addresses would have on the current number of DDOS attacks. Why can't access router vendors be jawboned into providing anti spoofing filters as a default configuration; or at least automate the process to eliminate spoofed addresses in the wild? Have a logo like the good housekeeping seal for networks that filter on the egress. As Paul stated, demand it from peers. It is a pain. If the political will exist, it will be done. If the PR and marketing folks think it will increase sales, it will be done a lot faster. -- Joseph T. Klein +1 414 915 7489 Senior Network Engineer jtk(a)titania.net Adelphia Business Solutions joseph.klein(a)adelphiacom.com "... the true value of the Internet is its connectedness ..." -- John W. Stewart III

5 5

Re: DDOS prevention offensive.
by John McNeal 12 Jul '01

12 Jul '01

On Thu, Jul 12, 2001 at 02:57:29PM -0700, Roeland Meyer wrote: > >Aha! I knew there was a reason that I filter EDU <g>. Really? How do you configure a DSL modem to filter EDU? -John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

RE: DDoS attacks
by Roeland Meyer 12 Jul '01

12 Jul '01

I happen to agree, if only because; when script kiddies don't have IRC to play with they'll start looking elsewhere. I'd rather them have an IRC net to play with while they're being hunted. Wouldn't you? > -----Original Message----- > From: Scott Francis [mailto:darkuncle@darkuncle.net] > Sent: Wednesday, July 11, 2001 7:24 PM > To: Richard A. Steenbergen > Cc: Ariel Biener; nanog(a)merit.edu > Subject: Re: DDoS attacks > > > On Wed, Jul 11, 2001 at 07:40:45PM -0400, Richard A. > Steenbergen exclaimed: > > Hrm you may have an idea there. Since so many attacks are related to > > EFNet, and there are so many possible reasons for it to be > impacting the > > rest of the internet, I propose we introduce a new ICMP > type, ICMP EFNet. > > This message type could be used to convey all kinds of important > > information about why things are broken, for example: > > > > ICMP EFNet code 1 - Smurfing > > ICMP EFNet code 2 - SYN Flooding > > ICMP EFNet code 3 - Channel takeover > > ICMP EFNet code 4 - Warring botnets > > ICMP EFNet code 5 - Dianora > > > > and many other useful messages. > > regardless of one's opinion on the usefulness/validity/point > of IRC, I think > some respect is due EFnet simply considering the antiquity of > the network, and > the sheer volume of communication, good bad and indifferent, > that has flowed > over it since its inception. I'm sure I'll be flamed for my > (mis)use of > 'antiquity', but I think IRC has been, and continues to be, a valuable > communication tool. Like any useful tool, it tends to be used for both > beneficial and nefarious purposes. > > And let's not forget that any network attack, regardless of > the target or > purpose, is a Bad Thing and responsible netizens should do > their part to help > eliminate such abuses. > > I'm done preaching now; I'm sure those who agree with me > didn't need a rehash, > and those that don't are unlikely to change their minds. Just > wanted to > provide a counterpoint to the "since $service has no business > function and > doesn't increase profits, there's no point in supporting it" crowd. > > (not that RAS is necessarily in that crowd; he just happened > to be the first > to respond.) > > Sometimes things are worth doing, even if doing them causes > you some grief. I'm > sure cynicism will eventually overwhelm me and I will realize > that there's no > point in sticking one's neck/network out to provide a useful > service to the > community. > > okay, I'm ready for the flames now. > > > -- > > 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) -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m UNIX | IP networks | security | sysadmin | caffeine | BOFH | general geekery GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

13 19

RE: DDOS prevention offensive.
by Roeland Meyer 12 Jul '01

12 Jul '01

> From: Jason Slagle [mailto:raistlin@tacorp.net] > Sent: Thursday, July 12, 2001 10:19 AM > > On Thu, 12 Jul 2001, Bill Larson wrote: > > > Well to sum it up in one sentence. If you eliminate the > bogus addresses, you > > can then target the actual zombie machines used to attack > the site and > > eventually eliminate the risk via patching or null route > them. So filtering > > bogus addresses, non-routable addresses, and the addresses, > which do not > > belong to your net blocks, would serve to combat the denial > of service > > attacks. > > > I believe the attacks in question are actually non-spoofed. > > It's getting the source networks to remove the boxes that is the > problem. Most of them are .edu. Aha! I knew there was a reason that I filter EDU <g>.

1 0