- NANOG - lists.nanog.org

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 02 May '02

02 May '02

Wasn't trying to make you mad, just looking for clarity. =) -----Original Message----- From: Mark Turpin [mailto:mark@gomez.charter.com] Sent: Thursday, May 02, 2002 11:25 AM To: nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 10:16:55AM -0700, LeBlanc, Jason wrote something like this: > Thats how it we understood it to work (CEF lookup). It checks for a route > in the table, obviously any real route would be in the CEF table. I may be > wrong, but it doesn't actually send a packet to verify, the logical way to > check would be by checking CEF, as anything the router knows about that is > valid would be in CEF. If I'm misunderstanding, please do send more info. I think a typo on my part has led to misunderstanding even more. However, the thread's getting hot, so I'm about ready to part ways with it. Regarding my statements, I was not inferring a packet be sent off to a host, or anything of that nature. What I'm referring to is a simple lookup [we now agree by CEF] to verify that the interface a packet was received on was actually the interface CEF would use to go back to the source of that packet. (I forgot source last time) If you can tweak rpf now to support multihoming, woohoo. And yes, depending on where you implement rpf the routing table comes into play. big woop. Earlier LeBlanc, Jason wrote something like this: > There are some limitations as to where uRPF works, SONET only on GSRs for > example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I > think) regardless of interface type. Impact should be minimal, as it simply > does a lookup in the CEF table, if the route isn't there it discards. That's what prompted me to even reply in the first place was noticing the fact you stated rpf only worked on pos interfaces on gsrs and that it did a simple route lookup. Both of which I disagree with. I've already stated what its looking for in the fib, and its *not* whether its 'there or not'. i'm over it, so have a good day... -mark -- Why is it considered necessary to nail down the lid of a coffin?

1 0

RE: DDOS attacks and Large ISPs doing NAT?
by Daniska Tomas 02 May '02

02 May '02

> -----Original Message----- > From: Gary E. Miller [mailto:gem@rellim.com] > Sent: 2. mája 2002 20:00 > To: Mansey, Jon > Cc: nanog(a)merit.edu > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > > > Who says a NATed host can not be a zombie? Get the NATed > host to read an email virus. The virus then coonects to an > IRC channel that tells the zombie when to spew. recursion again. the point was just about minimizing, not about completely avoiding. for every solution you do a new exploit will be invented in a short time, no matter how great the patch is > Each phone would not spew much, but imagine you got 100M > phones to do your DDoS for you... it's not about the number of phones but about capacity of the network even if you have 1k phones on one gsm sector they still only can generate as much as the radio allows for. how many channels you suppose to be available for gprs for the whole sector? three? four? several? maybe if you're optimistic enough. i definitely would not consider gprs being a broadband service. then - there are loads of different portable device on the market now and the diversity will increase. how would you manage to load your ddos clients to all these kinds of devices? in the end you maybe will get a few % (if lucky and tricky enough) of the portables. compare it to the aggregate traffic the whole gprs network could generate (not that much) and i don't think you can talk about a ddos in scale we are used to today -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.

1 0

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 02 May '02

02 May '02

Thats how it we understood it to work (CEF lookup). It checks for a route in the table, obviously any real route would be in the CEF table. I may be wrong, but it doesn't actually send a packet to verify, the logical way to check would be by checking CEF, as anything the router knows about that is valid would be in CEF. If I'm misunderstanding, please do send more info. -----Original Message----- From: Mark Turpin [mailto:mark-nanog@gomez.charter.com] Sent: Thursday, May 02, 2002 10:05 AM To: LeBlanc, Jason Cc: nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this: <snip> > > There are some limitations as to where uRPF works, SONET only on GSRs for > example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I > think) regardless of interface type. Impact should be minimal, as it simply > does a lookup in the CEF table, if the route isn't there it discards. Keep > in mind this is NOT a filter, so the impact is much less, it is simply a CEF > lookup, much more efficient than a filter. This will get rid of a HUGE > percentage of spoofed packets that hit your network, and would also work > pretty well if you are the source of an attack. There is some debate as to > whether you must not have ANY RFC1918 space for this to work. We're trying > to find this out (not a priority), if I get info I'll post. > hmm... either you're being extremely vague, or you misunderstand how RPF works. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu r_c/scprt5/scdrpf.htm Its not checking cef to see if a route is there.... its making sure that a packet received on an interface came in on an interface that is the best return path to reach that packet. thereby explaining why multihomed customers will get borked in the event of using rpf. enjoy, -mark -- Support your local medical examiner--die strangely.

3 2

Re: Large ISPs doing NAT?
by Scott Francis 02 May '02

02 May '02

On Thu, May 02, 2002 at 06:22:23AM -0700, msa(a)samurai.sfo.dead-dog.com said: > > [-- PGP output follows (current time: Thu May 2 06:21:09 2002) --] > gpg: Signature made Thu May 2 01:20:39 2002 PDT using ELG key ID CB33CCA7 > gpg: Good signature from "Scott Francis <darkuncle(a)darkuncle.net>" > gpg: key CB33CCA7.920: expired at Tue Mar 19 12:37:04 2002 PST > gpg: Note: This key has expired! > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ please re-fetch the key from wwwkeys.us.pgp.net or your nearest mirror. I updated this key a couple of months back, but it seems that many still have the old one cached. Sorry about that. -- 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 GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

1 0

RE: DDOS attacks and Large ISPs doing NAT?
by Mansey, Jon 02 May '02

02 May '02

Perhaps I should s/zombie/reflector in my orginal post. Jm > -----Original Message----- > From: Ian Cooper [mailto:ian@the-coopers.org] > Sent: Thursday, May 02, 2002 11:04 AM > To: nanog(a)merit.edu > Cc: Mansey, Jon > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > --On Thursday, May 2, 2002 10:30 -0700 "Mansey, Jon" > <Jon_Mansey(a)verestar.com> wrote: > > > > > To merge these 2 great threads, it is the case is it not > that NAT is a > > great way to avoid DDOS problems. I don't even want to imagine what > > the billing/credit issues would be like if your always-on > phone with a > > real IP is used as a zombie in a DDOS. "Hey I didn't use all that > > traffic last month....etc etc" > > And NAT helps you stop zombie software being installed on the > always-on > device (phone) precisely how? What's to say that an infected > system (or > vandal's system) isn't going to be connected inside the NATed space? > > > I still maintain, since the last time this was on Nanog, > that real IP > > addresses should not be entrusted to the great unwashed. > > The problem isn't that they're unwashed, the problem is that > they're being > pushed software that has bugs and holes that can be exploited > (oh look, the > "bash Microsoft" thread...) > > > And as for NAT breaking applications, I think its time the > > applications wised up and worked around the NAT issues. > > And what about those applications (protocols) that already > exist and break > when NAT exists? Or applications that simply don't scale > well when NAT > exists? > > > Look, if your application is > > important enough to you as the developer, you are going to > want it to > > penetrate and work for as many ppl as possible right? > Office workers, > > home users with gateways, GPRS/GSM/3G cell users etc etc. > So you make > > it use protocols that traverse NAT without breaking. Look at the > > streaming media players out there, they try to use, in order, > > multicast (the most effcient and best quality), UDP,TCP > then HTTP. If > > it cant get a connection with any of the first protocols, it falls > > back to http, and you get your stream. > > Right, and as you move toward HTTP you end up with a stream > that becomes > more and more expensive to deliver (and receive) and it > frequently becomes > harder and harder (and takes longer) to develop that application. > > > When you look at the economics of usability of your app, I > think your > > going to want to make it work through firewalls. > > Depends where the firewall is being run as to whether you > want it to break > the application or not, but if it's possible for all great > apps to run > through firewalls how long is it going to be before "nasty" > apps do that > well? >

1 0

RE: DDOS attacks and Large ISPs doing NAT?
by Mansey, Jon 02 May '02

02 May '02

To merge these 2 great threads, it is the case is it not that NAT is a great way to avoid DDOS problems. I don't even want to imagine what the billing/credit issues would be like if your always-on phone with a real IP is used as a zombie in a DDOS. "Hey I didn't use all that traffic last month....etc etc" I still maintain, since the last time this was on Nanog, that real IP addresses should not be entrusted to the great unwashed. And as for NAT breaking applications, I think its time the applications wised up and worked around the NAT issues. Look, if your application is important enough to you as the developer, you are going to want it to penetrate and work for as many ppl as possible right? Office workers, home users with gateways, GPRS/GSM/3G cell users etc etc. So you make it use protocols that traverse NAT without breaking. Look at the streaming media players out there, they try to use, in order, multicast (the most effcient and best quality), UDP,TCP then HTTP. If it cant get a connection with any of the first protocols, it falls back to http, and you get your stream. When you look at the economics of usability of your app, I think your going to want to make it work through firewalls. Jm > -----Original Message----- > From: Jake Khuon [mailto:khuon@NEEBU.Net] > Sent: Thursday, May 02, 2002 1:51 AM > To: nanog(a)merit.edu > Subject: Re: Large ISPs doing NAT? > > > > ### On Thu, 2 May 2002 10:42:01 +0200, "Daniska Tomas" > <tomas(a)tronet.com> ### casually decided to expound upon > <nanog(a)merit.edu> the following ### thoughts about "RE: Large > ISPs doing NAT? ": > > DT> and what if one of the devices behind that phone would also be a > DT> personal "ip gateway router" (or how you call that)... you could > DT> recursively iterate as deep as your mail size allows you to... > > It's possible. Could it get ugly? Yes. Do we just want to > shut our eyes and say "let's not go there."... well... maybe. > I just don't think the solution is to say, "this can never > happen... we must limit all handheld devices to sitting > behind a NAT gateway." > > > DT> hope this thread will not end in a router behind a router that > DT> serves as a router seving as a router to another router which has > DT> some other routers connected... > > God forbid! We might have a network on our hands! > > > -- > /*===================[ Jake Khuon <khuon(a)NEEBU.Net> > ]======================+ > | Packet Plumber, Network Engineers /| / [~ [~ |) | | > --------------- | > | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N > E T W O R K S | > +============================================================= > ============*/ >

4 3

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 02 May '02

02 May '02

Try a compiled ACL on a 3 port gigE for some fun. -----Original Message----- From: Christopher L. Morrow [mailto:chris@UU.NET] Sent: Thursday, May 02, 2002 9:48 AM To: Vincent Gillet Cc: Christopher L. Morrow; measl(a)mfn.org; Pete Kruckenberg; nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, 2 May 2002, Vincent Gillet wrote: > chris(a)UU.NET disait : > > > > have been on the receiving end of, the first was generating a little over > > > 300mbit/sec (steady for a prolonged time), and the second went over that by a > > > fair bit. In both cases, we had core equipment (M20's and BSN5000's) fall > > > over and die trying to "work" the events. Additionally, our upstream peers > > > > Your M20 tipped over?? What were you doing? We regularly stop large > > (+100Mb->800Mb) attacks with less horsepower than this. Truthfully, a > > cisco is even capable of filtering (done right) at +200kpps... > > On Cisco boxes, it depends too much on Interface type, LC Engine, IOS, ... > etc ... In this you have my whole-hearted agreement :( But, this goes back to 'know you systems, know their boundaries'. All of the people that work here (on our team) know what you can and can't do, we are effective in our jobs because of this. Sure your random NOC worker or even level3/4 NOC worker isn't going to know all the ins and outs of security thingy's on your backbone equipemt, that's why you pay 5-7 people to learn it :) > > Beside, some features cannot run concurently (i remumber an ACL on GSR > that make my netflow export stop .... it tooks days to figure this out !!!) > Ha! :) try acl's on engine-2 cards with sub-interfaces! (like the triton gig card... cause no one would ever sub-interface a gig interface, right?) > ACL Implement on GSR is too a nightmare. > We are operating more than 70 GSRs with very different interface, LC engine and IOS ... > Just 70? your live is easy then :) Really though, this is, in my opinion, the larges problem Cisco has to over come. They need to have the 'luxury' that Juniper has: One IOS, One implementation of commands, same commands everywhere... consistency I believe its called. Its not, obviously, going to happen overnight, but to their credit folks at cisco ARE working to make the security problem less of a problem. If you are having trouble getting your sales folk from cisco to listen/understand/pass-along-input you can look for their 'ISP Group' which I'm sure Barry Greene will be happy to properly name and provide contacts for, or perhaps they are in the sites he posted here before?

2 1

RE: Global view increase (was:BGP route explosion)
by James Spenceley 02 May '02

02 May '02

Around 15mins ago an additional ~5,000 routes entered the global view, sadly they appear to be hanging around. Last Tuesday had an increase of 2,000 routes. +7000 routes in a week is significant de-aggregation or leak, any ideas on where these routes are flowing ? I've not seen an increase on any of our peers, so I can only assume its coming from a network who doesn't peer particularly "openly". -- James

4 4

Re: Global view increase (was:BGP route explosion)
by David G. Andersen 02 May '02

02 May '02

On Thu, May 02, 2002 at 12:55:45PM -0500, Gerardo Gregory mooed: > <SNIP> > > http://ginseng/bgpview.cgi?time=between&start=2002-05-01+06%3A00%3A00&end=20 > 02-05-01+07%3A00%3A00&bins=100&prefix=&rel=eq&aspath=&asrel=contain&origin_a > s=17676&scale=linear&table=updates_new&action=plot&View=View > > <END SNIP> > > URL Seems unreachable (might be because there was a top level domain omitted > from the URL?) Sorry, not enough sleep last night. Here's the corrected URL, with the added bonus of stripping out some of the unnecessary goo: http://ginseng.lcs.mit.edu/bgpview.cgi?time=between&start=2002-05-01+06%3A0… -Dave -- work: dga(a)lcs.mit.edu me: dga(a)pobox.com MIT Laboratory for Computer Science http://www.angio.net/

1 0

RE: DDOS attacks and Large ISPs doing NAT?
by Daniska Tomas 02 May '02

02 May '02

jon, 1000x ack and for all: i think this MOTD is something very close to the isp nat thread :) "There are only 10 types of people in this world: those who understand binary, and those who don't." (Credits to Theodore Tzevelekis/Cisco) deejay -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: Mansey, Jon [mailto:Jon_Mansey@verestar.com] > Sent: 2. mája 2002 19:31 > To: nanog(a)merit.edu > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > > To merge these 2 great threads, it is the case is it not that > NAT is a great way to avoid DDOS problems. I don't even want > to imagine what the billing/credit issues would be like if > your always-on phone with a real IP is used as a zombie in a > DDOS. "Hey I didn't use all that traffic last month....etc etc" > > I still maintain, since the last time this was on Nanog, that > real IP addresses should not be entrusted to the great unwashed. > > And as for NAT breaking applications, I think its time the > applications wised up and worked around the NAT issues. Look, > if your application is important enough to you as the > developer, you are going to want it to penetrate and work for > as many ppl as possible right? Office workers, home users > with gateways, GPRS/GSM/3G cell users etc etc. So you make it > use protocols that traverse NAT without breaking. Look at the > streaming media players out there, they try to use, in order, > multicast (the most effcient and best quality), UDP,TCP then > HTTP. If it cant get a connection with any of the first > protocols, it falls back to http, and you get your stream. > > When you look at the economics of usability of your app, I > think your going to want to make it work through firewalls. > > Jm

1 0