BGP route explosion
I had a network outage this morning brought about by a BGP route explosion at around 6:30 EST(-4) this morning. Anyone else notice it, and who the culprit whats? I got the exact same hit from both my providers, ATT Can, and Telus. Thanks Andrew
Re: BGP route explosion
I had a network outage this morning brought about by a BGP route explosion at around 6:30 EST(-4) this morning. Anyone else notice it, and who the culprit whats? I got the exact same hit from both my providers, ATT Can, and Telus. Yeah its been reported a few places - we saw about 130K routes. -- Neil J. McRae - Alive and Kicking [EMAIL PROTECTED]
Re: BGP route explosion
On Wed, 1 May 2002 08:42:02 -0400 [EMAIL PROTECTED] (Andrew Herdman) wrote: I had a network outage this morning brought about by a BGP route explosion at around 6:30 EST(-4) this morning. Anyone else notice it, and who the culprit whats? I got the exact same hit from both my providers, ATT Can, and Telus. Thanks Andrew I did not see this on Sprint, UUNet or vBNS. Regards Marshall Eubanks
Re: BGP route explosion
AS818 saw the spike, courtesy Geoff Houston's Table Data Program: http://ryouko.dgim.crc.ca/bgp/bgp-all.html Neat tool - I tried to grab the src but the first 1000 or so lines are blank and uncompilable. Anyone have a good version of the src?
Verizon fiber cut in Midtown Manhattan
http://1010wins.com/topstories/StoryFolder/story_1199630592_html WINS) May 1, 2002 6:49 am US/Eastern (New York-AP) -- Telephone service in a section of midtown Manhattan has been disrupted by a construction accident. Verizon spokesman Cliff Lee says a construction crew working on 58th Street between Lexington and Third avenues yesterday cut into a cable underground, causing the disruption. It's unclear how many customers have experienced problems. Police say thousands of people have been affected. Lee says Verizon has received about 400 calls from customers having difficulty. Repair crews are working at the scene. The affected area is between Third and Fifth avenues from 57th to 65th streets. (Copyright 2002 by The Associated Press. All Rights Reserved.)
Re: news-peering
} I'm trolling for newspeers, if there is anyone out there still using } NNTP.. http://www.usenet-se.net/peering/ A useless list based on my experience (zero responses to requests to twelve different sites). --lyndon
Re: news-peering
supernews.com is my news provider and they are pretty good. Todd - Original Message - From: Lyndon Nerenberg [EMAIL PROTECTED] To: Katsuhiro Kondou [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 9:53 AM Subject: Re: news-peering } I'm trolling for newspeers, if there is anyone out there still using } NNTP.. http://www.usenet-se.net/peering/ A useless list based on my experience (zero responses to requests to twelve different sites). --lyndon
Re: news-peering
On Wed, 1 May 2002, Lyndon Nerenberg wrote: } I'm trolling for newspeers, if there is anyone out there still using } NNTP.. http://www.usenet-se.net/peering/ A useless list based on my experience (zero responses to requests to twelve different sites). Some of the information on there is most likely stale. Several sites we used to peer with when we ran a news server have been borged into other companies or are no longer serving news, but are still on the list. jms
Re: Large ISPs doing NAT?
I don't know if this is an annual argument yet, but the frog is in the pot, and the flame is on. Guess who's playing the part of the frog? Answer: ISPs who do this sort of thing. Value added security is a nice thing. Crippling Internet connections will turn the Internet into the phone company, where only the ISP gets to say what services are good and which ones are bad. While an ISP might view it appealing to be a baby bell, remember from whence we all come: the notion that the middle should not inhibit the endpoints from doing what they want. You find this to be a support headache? Offer a deal on Norton Internet Security or some such. Offer to do rules merges. Even offer a provisioning interface to some access-lists. Just make sure that when that next really fun game is delivered on a play station that speaka de IP your customers can play it, and that you haven't built a business model around them not being able to play it. Eliot mike harrison wrote: On Monday, 2002-04-29 at 08:43 MST, Beckmeyer [EMAIL PROTECTED] wrote: Is anybody here doing NAT for their customers? Tony Rall: If you're NATing your customers you're no longer an ISP. You're a sort-of-tcp-service-provider (maybe a little udp too). NAT (PAT even more Depends on scale and application. We have lots of customers that we NAT, one way or another. And a lot more that we don't. Some customers WANT to 'just see out' and they like all the 'weird stuff turned off'. Sometimes it's a box at the customers end, sometimes it's nat'd IP's on the dial-up/ISDN/FracT1/T1/Wireless connection itself. Saying we are not an ISP because we do some NAT is a little harsh. Giving the customer options and making things work (when done right, and explained properly we have no sales droids) is good business and I think good for the 'net. It gives the clueless (and sometimes cluefull) just a little more isolation. What is wrong is NAT'ing when you should not.
Re: Large ISPs doing NAT?
On Wed, 01 May 2002 14:55:02 PDT, Eliot Lear said: some access-lists. Just make sure that when that next really fun game is delivered on a play station that speaka de IP your customers can play it, and that you haven't built a business model around them not being able to play it. There was a reason I said *ALMOST*. ;) Thanks, Eliot. msg01308/pgp0.pgp Description: PGP signature
Re: Large ISPs doing NAT?
At 3:03 PM -0700 5/1/02, Scott Francis wrote: On Wed, May 01, 2002 at 02:55:02PM -0700, [EMAIL PROTECTED] said: I don't know if this is an annual argument yet, but the frog is in the pot, and the flame is on. Guess who's playing the part of the frog? Answer: ISPs who do this sort of thing. Value added security is a nice thing. Crippling Internet connections will turn the Internet into the phone company, where only the ISP gets to say what services are good and which ones are bad. While an ISP might view it appealing to be a baby bell, remember from whence we all come: the notion that the middle should not inhibit the endpoints from doing what they want. You find this to be a support headache? Offer a deal on Norton Internet Security or some such. Offer to do rules merges. Even offer a provisioning interface to some access-lists. Just make sure that when that next really fun game is delivered on a play station that speaka de IP your customers can play it, and that you haven't built a business model around them not being able to play it. As long as it is _clear_ from the get-go that customers behind NAT are getting that service, and not publicly-routable IP space, I don't see the problem. If they don't like it, they don't have to sign up to begin with - as long as there is no doubt as to what kind of service they're getting, there shouldn't be a problem (legally, at any rate). You've got to be kidding. Do you think it's clear to the average consumer buying a GPRS phone what NAT is, and why they might or might not want it? Do you think the use of NAT will be explained to these customers? Or clearly stated in 5pt text on page 17 of the service agreement? IMHO, as one of the people who will likely be using Cingular's GPRS network with a Danger HipTop, I _strongly_ hope they choose to use routable address space instead of NAT. I would hate for NAT to be an impediment to some cool new app no one has thought of yet because these gizmos aren't in widespread use yet. This is not to say that if, as Eliot posits, the next Big Thing on the market requires public IPs that your customer base won't all jump ship. That's a risk that providers will have to weigh against the benefits of NAT. I'm more concerned that if the major metropolitan markets deploying GPRS all use NAT, then the Next Big Thing won't ever happen on GPRS devices. Customers won't jump ship if they have no where to jump to. That might sound attractive to the bean counters, but think of the customers you might never get in the first place. Also, I don't see how deploying NAT could be a cost savings over requesting real IP space. -pmb -- Ring around the Internet, | Peter Bierman [EMAIL PROTECTED] Packet with a bit not set | http://www.sfgoth.com/pmb/ SYN ACK SYN ACK, |Nobody realizes that some people expend We all go down. -A. Stern | tremendous energy merely to be normal.-Al Camus
Effective ways to deal with DDoS attacks?
There's been plenty of discussion about DDoS attacks, and my IDS system is darn good at identifying them. But what are effective methods for large service-provider networks (ie ones where a firewall at the front would not be possible) to deal with DDoS attacks? Current method of updating ACLs with the source and/or destination are slow and error-prone and hard to maintain (especially when the target of the attack is a site that users would like to access). A rather extensive survey of DDoS papers has not resulted in much on this topic. What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? Thanks. Pete.
Re: Large ISPs doing NAT?
I think a lot of the GRPS stuff is heading towards IPv6 w/IPv4 gatewaying. The NAT issue has certainly resulted in a quite a few disgruntled satellite customers (I'm thinking here primarily of direcpc.com) who're willing to put up with the large latencies, but get really irate when their apps won't work via NAT, or who want to run RFC1918 space for a LAN at home, then find out that lots of stuff can't stand being NATted twice. -- Roland Dobbins [EMAIL PROTECTED] // 650.776.1024 voice Central databases already exist. Privacy is already gone. -- Larry Ellison, CEO of Oracle Corporation On Wed, 2002-05-01 at 16:07, Peter Bierman wrote: At 3:03 PM -0700 5/1/02, Scott Francis wrote: On Wed, May 01, 2002 at 02:55:02PM -0700, [EMAIL PROTECTED] said: I don't know if this is an annual argument yet, but the frog is in the pot, and the flame is on. Guess who's playing the part of the frog? Answer: ISPs who do this sort of thing. Value added security is a nice thing. Crippling Internet connections will turn the Internet into the phone company, where only the ISP gets to say what services are good and which ones are bad. While an ISP might view it appealing to be a baby bell, remember from whence we all come: the notion that the middle should not inhibit the endpoints from doing what they want. You find this to be a support headache? Offer a deal on Norton Internet Security or some such. Offer to do rules merges. Even offer a provisioning interface to some access-lists. Just make sure that when that next really fun game is delivered on a play station that speaka de IP your customers can play it, and that you haven't built a business model around them not being able to play it. As long as it is _clear_ from the get-go that customers behind NAT are getting that service, and not publicly-routable IP space, I don't see the problem. If they don't like it, they don't have to sign up to begin with - as long as there is no doubt as to what kind of service they're getting, there shouldn't be a problem (legally, at any rate). You've got to be kidding. Do you think it's clear to the average consumer buying a GPRS phone what NAT is, and why they might or might not want it? Do you think the use of NAT will be explained to these customers? Or clearly stated in 5pt text on page 17 of the service agreement? IMHO, as one of the people who will likely be using Cingular's GPRS network with a Danger HipTop, I _strongly_ hope they choose to use routable address space instead of NAT. I would hate for NAT to be an impediment to some cool new app no one has thought of yet because these gizmos aren't in widespread use yet. This is not to say that if, as Eliot posits, the next Big Thing on the market requires public IPs that your customer base won't all jump ship. That's a risk that providers will have to weigh against the benefits of NAT. I'm more concerned that if the major metropolitan markets deploying GPRS all use NAT, then the Next Big Thing won't ever happen on GPRS devices. Customers won't jump ship if they have no where to jump to. That might sound attractive to the bean counters, but think of the customers you might never get in the first place. Also, I don't see how deploying NAT could be a cost savings over requesting real IP space. -pmb -- Ring around the Internet, | Peter Bierman [EMAIL PROTECTED] Packet with a bit not set | http://www.sfgoth.com/pmb/ SYN ACK SYN ACK, |Nobody realizes that some people expend We all go down. -A. Stern | tremendous energy merely to be normal.-Al Camus
Re: Effective ways to deal with DDoS attacks?
http://www.secsup.org/Tracking/ UUNet uses that...others might as well, Shrug. Quick, simple, effective tracking of DDoS attacks. As for identifying attacks, quite honestly large ISP's are typically still relying on customer notification. I know that's how we do it. On Wed, 1 May 2002, Pete Kruckenberg wrote: There's been plenty of discussion about DDoS attacks, and my IDS system is darn good at identifying them. But what are effective methods for large service-provider networks (ie ones where a firewall at the front would not be possible) to deal with DDoS attacks? Current method of updating ACLs with the source and/or destination are slow and error-prone and hard to maintain (especially when the target of the attack is a site that users would like to access). A rather extensive survey of DDoS papers has not resulted in much on this topic. What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? Thanks. Pete.
Re: Effective ways to deal with DDoS attacks?
Then you are pushing out /32's and peers would need to accept them. Then someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! Additionally you are creating a way to basically destroy the Internet as a whole. One kiddie gets ahold of a router, say of a large backbone provider, takes one of their aggregate blocks (/16? /10? /8?) and splits it into /32 announcements. Anyways, some providers already allow you to set a community on a route, and they will inturn blackhole it for you. I believe Teleglobe does this for some customers and I know UUNet does this for all customers. On Wed, 1 May 2002, Wojtek Zlobicki wrote: What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? A great deal of thought is being expended on this question, I am certain, however, how many of these thought campaings have born significant fruit yet, I do not know. How about the following : We develop a new community , being fully transitive (666 would be appropriate ) and either build into router code or create a route map to null route anything that contains this community. The effect of this being the distribution of the force of the attack. This aside, how effective would be using a no export community with ones peers (being non transitive, it would still distribute the force of the attack).
Re: Effective ways to deal with DDoS attacks?
Then you are pushing out /32's and peers would need to accept them. Then someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! I am in no way proposing discounting current filtering rules. There are alway two different intersts one must consider, one that of the customer and two that of the service provider. If a large block must be filtered so be it. Where are providers drawing the line ? Anyone have somewhat detailed published policies as to what a provider can do in order to protect their nework as a whole. At what point (strength of the attack) does a customers netblock (assuming a /24 for example) get null routed by whichever party. Anyways, some providers already allow you to set a community on a route, and they will inturn blackhole it for you. I believe Teleglobe does this for some customers and I know UUNet does this for all customers. When the attack is distributed, having one or two providers (even if they are UUNET or Teleglobe) is just not enough. Must private routing policy be developed in order to make my suggestion work. The reason that so many methods likely fail are the difficulty of implementation and low implementation.
Re: Effective ways to deal with DDoS attacks?
In a message written on Wed, May 01, 2002 at 08:17:04PM -0500, dies wrote: Then you are pushing out /32's and peers would need to accept them. Then someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! I'm not sure what form this would take, but I have long wished route processing could be sent into a programming language. For this specific example it would be nice to set a maximum number of route limit for the total number of routes on the session, as well as /per community/. That is, community :666 == blackhole me, and I could limit each peer to say, 6 of these at a time. More would not take down the session, but simply be ignored. I can carry 6 /32's for every peer I have, and if they only have 6, they will probably use them for the most abusive target. There are, of course, approximately an infinitate number more applications for a more flexible mechanism. Of course, it would require more human smarts, which might be why vendors don't do it. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Effective ways to deal with DDoS attacks?
On Wed, May 01, 2002 at 09:38:52PM -0400, Wojtek Zlobicki wrote: How about the following : We develop a new community , being fully transitive (666 would be appropriate ) and either build into router code or create a route map to null route anything that contains this community. The effect of this being the distribution of the force of the attack. This has been proposed a dozen times over, and I agree that there should be a well known community for discarding packets. Go try and get the IETF to add it, let me know how it goes. :) This aside, how effective would be using a no export community with ones peers (being non transitive, it would still distribute the force of the attack). Many people do this already. If you're looking to purchase transit and you think this is something you'll care about, ask for it or vote with your wallet. -- Richard A Steenbergen [EMAIL PROTECTED] 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)
RE: Large ISPs doing NAT?
On Wed, 1 May 2002, Deepak Jain wrote: I'm more concerned that if the major metropolitan markets deploying GPRS all use NAT, then the Next Big Thing won't ever happen on GPRS devices. Customers won't jump ship if they have no where to jump to. The only people who'd be deploying GPRS are GSM cellular providers, no? Verizon and Sprint PCS, in particular, are not using GPRS, but migrating to CDMA-based 3G cellular technologies. I don't know that those technologies use CDMA. And of course, there are still markets like my very own hometown (2nd largest city in Ohio) that don't have GSM yet (even though #1 and #3 do). VoiceStream is supposedly launching their GSM network in Cleveland (*snort* I've heard that before). But they're not here yet, ATT is nowhere near doing GSM here as far as I know, and Cingular's network here (former AmeriBlech Cellular) is TDMA. I could be completely off base, of course. Being a customer of Sprint PCS and Verizon, and a former customer of Alltel and Northcoast PCS, I've not had much reason to follow GSM developments; every one of the companies I've used runs CDMA. Feel free to correct me if I am wrong. -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net The Indians are unfolding into the 2002 season like a lethal lawn chair. (_News-Herald_ Indians Columnist Jim Ingraham, April 11, 2002)
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: We experience a lot of types of attacks (education/research network = easy hacker target). With DDoS incidents, it seems we are more often an unknowing/unwilling participant than the target, partly due to owning big chunks of IP address space. Universities are hacker training grounds, but also have much better network security response than most corporate networks. Whatever problems you have, the rest of us will have soon enough it may just take us longer to notice it. Has anyone tried this kind of an approach or any other type of automated/efficient approach to dampen the zombie side of the DDoS attack? Has anyone implemented Bellovin's Pushback in a production network yet?
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote: and then again, there has been much discussion on simple DoS attacks, where the term DDoS is erroneously used... I am very much not trying to imply that this is the case here, but it's important that the two be thoroughly distinguished from each other - they are totally different things to deal with. Sorry, I should have been more clear. My issue (currently) is not being the target of the DDoS attack, but being a (unwilling) participant. People outside our network are launching DDoS attacks (distributed SYN floods) against destinations outside our network, using about 8,000 Web server hosts on our network as reflectors. These are not zombies. They are secured, uncompromised Web servers. The attack spoofs the target address as the source, and one of our machines as a destination, port 80. Getting everyone to implement defenses (SYN cookies) on their Web servers is nearly impossible (most don't even have a defense--printers and routers with Web interfaces). SYN packet comes in, one of these machines responses with a RST to the source, which is actually the target of the attack. Unfortunately, the target is often a site that people would like to get to, as is the reflector, so permanent filters on the target or reflector create lots of complaints. We captured several seconds of the last DDoS and came up with over 700 participating hosts... Some of them probably appear to be from our network... Pete.
Re: Effective ways to deal with DDoS attacks?
What we use and we're a 'largeish' network: http://www.secsup.org/Tracking/ (shameless plug #1) Among other things this is a tool we use... there was a great set of slides and presentation given at NANOG23: http://www.nanog.org/mtg-0110/greene.html (shameless plug #2) There is also a set of papers Barry Greene from Cisco has available on the Cisco website... I'm positive he'll respond to this with the link, if he doesn't search the NANOG mailing list archive for the link it should be obvious in posts from Barry. If you want more pointers I'd be glad to chat on the phone with you, numbers included below. --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Wed, 1 May 2002, Pete Kruckenberg wrote: There's been plenty of discussion about DDoS attacks, and my IDS system is darn good at identifying them. But what are effective methods for large service-provider networks (ie ones where a firewall at the front would not be possible) to deal with DDoS attacks? Current method of updating ACLs with the source and/or destination are slow and error-prone and hard to maintain (especially when the target of the attack is a site that users would like to access). A rather extensive survey of DDoS papers has not resulted in much on this topic. What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? Thanks. Pete.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote: True DDoS attacks, fortunately, are rarer than most people believe. If they were not, the Internet as we know it would look a lot more like a telephone system in USSR-at-it's-worst-days. For example, of the two recent DDoS's I 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... also had core equipment fall over, and we all came the [now obvious] conclusion that the only way to stop these attacks was to completely null route ourselves at our upstreams (they tried filter-fishing for specific data which may have helped our investigation, but when their routers started wheezing, we gave them the OK to just send us straight into the bit bucket till it was over... Hmm, this highlights the need to learn how to use the equipment, learn its boundaries and learn defenses inside these boundaries... -Chris
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, dies wrote: Then you are pushing out /32's and peers would need to accept them. Then someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! Yes. Additionally you are creating a way to basically destroy the Internet as a whole. One kiddie gets ahold of a router, say of a large backbone provider, takes one of their aggregate blocks (/16? /10? /8?) and splits it into /32 announcements. Or, blackhole the /16 :) more fun! (assuming no other smaller announcements inside that /16 of course) Anyways, some providers already allow you to set a community on a route, and they will inturn blackhole it for you. I believe Teleglobe does this for some customers and I know UUNet does this for all customers. Hmm, Mr. 'dies' is almost correct... if you are a UUNET customer and you would like to do this please call the customer service center and they will help you to configure this 'service'. Thanks though Mr. 'dies' :) On Wed, 1 May 2002, Wojtek Zlobicki wrote: What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? A great deal of thought is being expended on this question, I am certain, however, how many of these thought campaings have born significant fruit yet, I do not know. How about the following : We develop a new community , being fully transitive (666 would be appropriate ) and either build into router code or create a route map to null route anything that contains this community. The effect of this being the distribution of the force of the attack. This aside, how effective would be using a no export community with ones peers (being non transitive, it would still distribute the force of the attack).
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Wojtek Zlobicki wrote: Where are providers drawing the line ? Anyone have somewhat detailed published policies as to what a provider can do in order to protect their nework as a whole. At what point (strength of the attack) does a customers netblock (assuming a /24 for example) get null routed by whichever party. Most providers likely have a policy similar to: I can't sacrafice 1 my network for 1 customer. So, if the attack is sufficient to degrade service on the ISP network most likely the customer under attack will get null routed. Anyways, some providers already allow you to set a community on a route, and they will inturn blackhole it for you. I believe Teleglobe does this for some customers and I know UUNet does this for all customers. When the attack is distributed, having one or two providers (even if they are UUNET or Teleglobe) is just not enough. Must private routing policy be developed in order to make my suggestion work. The reason that so many methods likely fail are the difficulty of implementation and low implementation. Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 security contact that can actually help in the case of an attack. Today there are very few that have this capability. I'd say from personal experience that the number is way too small, even in the 'large' ISP arena :( More pressure from customers for real security would be a good start.
Re: Large ISPs doing NAT?
On Wednesday, May 1, 2002, at 10:33 , Steven J. Sobol wrote: On Wed, 1 May 2002, Deepak Jain wrote: I'm more concerned that if the major metropolitan markets deploying GPRS all use NAT, then the Next Big Thing won't ever happen on GPRS devices. Customers won't jump ship if they have no where to jump to. The only people who'd be deploying GPRS are GSM cellular providers, no? The concern exists regardless of the specifics of the always-on, cellular packet radio protocols being used, surely? [GSM coverage is patchy in the US] It's prevalent elsewhere. I'd be surprised if there aren't more GSM subscribers in the world than non-GSM subscribers. Joe
Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 04:28:44AM +, Christopher L. Morrow wrote: Let me say this one more time... RATE LIMITS DON'T DO SHIT TO STOP ATTACKS for the victim atleast, all they do is make the job of the attacker that much easier. For instance: 1) I synflood www.avleen.org 2) you rate-limit syns to 1MB 3) I now only flood 1MB and I still win So, don't rely on a rate-limit as its not going to help. Thank you, I can't make this point enough and people still say we'll just rate limit!. Filtering is only as good as your ability to DETERMINE WHAT TO FILTER. The only time you can get anything from this is when you admit defeat on keeping your services responding to new connection but want to keep existing connections and/or the end servers from failing completely. Depending on the service in question this may or may not be a good goal. -- Richard A Steenbergen [EMAIL PROTECTED] 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)
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Richard A Steenbergen wrote: I give it 2 months, then they'll start hitting random dst IPs in a target prefix (say a common /24 going through the same path). Damn you, don't give them any ideas :)
Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote: On Wed, 1 May 2002, Wojtek Zlobicki wrote: Where are providers drawing the line ? Anyone have somewhat detailed published policies as to what a provider can do in order to protect their nework as a whole. At what point (strength of the attack) does a customers netblock (assuming a /24 for example) get null routed by whichever party. Most providers likely have a policy similar to: I can't sacrafice 1 my network for 1 customer. So, if the attack is sufficient to degrade service on the ISP network most likely the customer under attack will get null routed. Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just for the sake of the argument), UU will not null route my ircd if it it gets attacked on regular basis, say *daily* ? Furthermore you are going to consistently place filters on your routers, take them out within the 24h (or whatever then-current policy of UUnet is) and track attacks back to their sources within the boundaries of your backbone on a daily basis? ;) Will you do that for say a regular T1 customer or do I need more commitment as sales droids like to put it, to even consider such a service ? ;) Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 security contact that can actually help in the case of an attack. Today there are very few that have this capability. I'd say from personal experience that the number is way too small, even in the 'large' ISP arena :( More pressure from customers for real security would be a good start. sigh, tried and failed, miserably I might add. -Basil
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: On Wed, 1 May 2002, Richard A Steenbergen wrote: DDoS attacks is such a generic term. There are a wide variety of attacks which each need to be handled in their own way, the extra D is just one possible twist. Can you explain what kind of attack you're interested in? We experience a lot of types of attacks (education/research network = easy hacker target). With DDoS incidents, it seems we are more often an unknowing/unwilling participant than the target, partly due to owning big chunks of IP address space. We most frequently are the zombie/reflector participants in an attack that originates outside our network, to a target outside our network. As many as 8,000 hosts on our network are reflecting SYN floods in the current attacks. Sounds like its time for a firewall on your network :) Identification doesn't seem to be a problem. Snort is doing far too well notifying us. Responding and managing all of the defenses is becoming a lot of pain-staking work, and error-prone (why can't Cisco make ACLs easier to manage). they aren't tough to 'manage' they are sometimes tough to live with though :( Our approach so far has been temporary blocks (via ACL) of the target address. Blocking 8,000 internal addresses, many legitimate (secured) Web servers, generates more complaints. I'm thinking about a scripted Zebra feed where route injections are triggered by Snort. Routes for the target and/or SYN flood reflector hosts could be injected temporarily during the attack to border routers, which would route-map those routes to Null0. Script periodically withdraws routes to see if the attack is over (some of these last weeks, some only last a few seconds), to minimize the impact on those otherwise legitimate hosts. This is a nice idea, anything 'scripted' is prone to abuse though ;( all of a sudden www.your.edu is dead.. on class registration day no less. Has anyone tried this kind of an approach or any other type of automated/efficient approach to dampen the zombie side of the DDoS attack?
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: On Wed, 1 May 2002 [EMAIL PROTECTED] wrote: and then again, there has been much discussion on simple DoS attacks, where the term DDoS is erroneously used... I am very much not trying to imply that this is the case here, but it's important that the two be thoroughly distinguished from each other - they are totally different things to deal with. Sorry, I should have been more clear. My issue (currently) is not being the target of the DDoS attack, but being a (unwilling) participant. People outside our network are launching DDoS attacks (distributed SYN floods) against destinations outside our network, using about 8,000 Web server hosts on our network as reflectors. Funny, you say 'secured' here... These are not zombies. They are secured, uncompromised Web servers. The attack spoofs the target address as the source, and one of our machines as a destination, port 80. Getting everyone to implement defenses (SYN cookies) on their Web servers is nearly impossible (most don't even have a defense--printers and routers with Web interfaces). and here you say: printers and routers Since when did they need to be accessible off campus? Additionally, why does a router need a web interface?? Printers are on the cusp, but they certainly don't need to be accesible from out of your LAN.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Basil Kruglov wrote: On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote: On Wed, 1 May 2002, Wojtek Zlobicki wrote: Where are providers drawing the line ? Anyone have somewhat detailed published policies as to what a provider can do in order to protect their nework as a whole. At what point (strength of the attack) does a customers netblock (assuming a /24 for example) get null routed by whichever party. Most providers likely have a policy similar to: I can't sacrafice 1 my network for 1 customer. So, if the attack is sufficient to degrade service on the ISP network most likely the customer under attack will get null routed. Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just for the sake of the argument), UU will not null route my ircd if it it gets attacked on regular basis, say *daily* ? I did not say that. Furthermore you are going to consistently place filters on your routers, take them out within the 24h (or whatever then-current policy of UUnet is) and track attacks back to their sources within the boundaries of your backbone on a daily basis? ;) uhm... sure, we do this now... or have you not been paying attention? Will you do that for say a regular T1 customer or do I need more commitment as sales droids like to put it, to even consider such a service ? ;) read above. Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 security contact that can actually help in the case of an attack. Today there are very few that have this capability. I'd say from personal experience that the number is way too small, even in the 'large' ISP arena :( More pressure from customers for real security would be a good start. sigh, tried and failed, miserably I might add. Then become a UUNET customer cause we already do this... Perhaps other providers with 24/7 security teams will pipe up to give potential customers a heads-up on options other than UUNET? If you go with UUNET please tell the sales driod I sent you cause then I get 50 bucks :) (my only raise thanks to bernie)
Re: Effective ways to deal with DDoS attacks?
On Thu, 2 May 2002, Richard A Steenbergen wrote: SYN packet comes in, one of these machines responses with a RST to the source, which is actually the target of the You have an interesting situation. I think rate limiting outbound RSTs would be the least offensive thing you could do, off the top of my head. What about just blocking out-going RSTs altogether from our borders? While this interferes with proper TCP functionality, would it actually interfere enough to cause noticeable problems? Would certainly be less of a burden on routers than rate-limiting. Pete.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: On Thu, 2 May 2002, Richard A Steenbergen wrote: SYN packet comes in, one of these machines responses with a RST to the source, which is actually the target of the You have an interesting situation. I think rate limiting outbound RSTs would be the least offensive thing you could do, off the top of my head. What about just blocking out-going RSTs altogether from our borders? While this interferes with proper TCP functionality, would it actually interfere enough to cause noticeable problems? Would certainly be less of a burden on routers than rate-limiting. Aren't the initial packets in the 'gibson syn amp attack' syn-ack's?
