|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
First let me appologize for sending my response to the whole list, working in several windows causes mental errors at times. My intent was only to reply to the original author rather than the rest of the list. That said, I'd love to hear from anyone thats actually had any sucess in dealing with their NSP and synfloods. I know quite a few folks who'd love to get some insight on how to force their upstream providers to help them track down the culprits, or at least stop the flow. I use IRC as an example (not because anyone actually cares about it, but because its a popular target for small children with even smaller minds.), servers are consistently synflooded by some twit who's mad because someone klined him for being naughty. Joe Admin sees this, calls his upstream, who politely tells him, (and you may consider this an almost direct quote from MCI during one of my experiences), "We're sorry, but we simply can't spend the time it would take to trace this and help you with that problem. It takes an act of God to get one of our supervisors to ok it, and even then it would take at least 10 or more man hours just to find where its entering our path." Now I understand that its time consuming and lord knows crisco's debug is hard on the eyes after a while but.. I'm willing to believe that if you make enough examples of busting the abusers word will get around. Granted there are always going to be people who think they can (and often do) beat the system, but the more effort you put into catching them, the better you become at it, and who knows.. maybe you'll develop a better method. On Fri, 20 Dec 1996, Alan Hannan wrote: > > > mileage will vary with provider and the person within the > company with whom you're working . while ideally results would > just appear, I do believe that with proper escalation and > persistence, you can get assistance. your sales person can be > of help here. > > i know that uunet and mci do give sig. weight to syn attacks, > and will work to determine the source. I'm sure others do too. > > -alan > > ] > ] Except for one small problem, Unless you're _HUGE_ most NSP's (ie. MCI, > ] sprint, uunet) don't give a flying fuck and won't spend the time and > ] manhours it takes to track these things down. At one point one of our main > ] machines was being synflooded on almost every port, mci refused to do a > ] thing about it because it would 'take too long'. > ] > ] On Fri, 20 Dec 1996, Alan Hannan wrote: > ] > ] > > ] > > ] > why even do that? i'm not sure i want you triggering security > ] > mechanisms on my routers. Especially with the overhead > ] > implications, though that is the thread we're currently in [may it > ] > die soon]. > ] > > ] > building an acl that allows packets matching those you're > ] > interested in, and applying it to 'debug ip packet ACL detail' > ] > is fairly simple. > ] > > ] > just sit there doing 'clear ip cache A.B.C.D W.X.Y.Z'. Find > ] > the next hop it's coming from, trace it along, mail your > ] > friendly peer or transit provider, or mail your friendly hacker's > ] > admins. > ] > > ] > granted, this is limited to the domain of routers you control, > ] > but it's pretty effective for finding out where the syn attack is > ] > coming from. > ] > > ] > this assumes the people who are dumb enough to keep syn-ing > ] > continue to be stupid enough to use originating source addresses > ] > like 234.231.0.33. > ] > > ] > -alan > ] > > ] > > ] > ] > 3) Deal with it legally. This is what the telco's do. It implies that we > ] > ] > would need real mechanisms for tracking down offenders. > ] > ] > ] > ] Personally, I'd like to see a protocol that allows you to ask a > ] > ] router to which you were directly connected to stamp an interface ID on > ] > ] all incoming packets bound for a particular network. You could then trace > ] > ] back router by router, interface by interface, where the packets were > ] > ] entering a block of cooperating providers. > ] > ] > ] > ] Thus if I saw an incoming flood of SYN packets or ICMP echoes > ] > ] with forged origin addresses, I could ask my router to ask all its direct > ] > ] peers to begin stamping interface numbers (and/or interface IPs) on the > ] > ] packets they send to me. My router would eat those numbers/IPs so traffic > ] > ] would appear unaffected. > ] > ] > ] > ] Then my tracing tool would know which interface the packets were > ] > ] coming in on and could ask that router to do the same thing (on a > ] > ] hop-by-hop basis for security reasons). Thus I could track it back to a > ] > ] specific enough interface path that perhaps an automated method to > ] > ] install a filter would be sufficient. > ] > ] > ] > ] This stuff needs a lot of work, but might be a direction that > ] > ] would both facilitate emergency filtering and effective tracing for IP > ] > ] packets with forged origin addresses -- assuming the packets have enough > ] > ] in common to allow them to be detected (all pings, or heavy load, or all > ] > ] to same destination IP). > ] > ] > ] > ] David Schwartz > ] > ] > ] > > ] > ] [-] Brett L. Hawn ([email protected]) [-] > ] [-] Networks On-Line - Houston, Texas [-] > ] [-] 713-467-7100 [-] > ] > [-] Brett L. Hawn ([email protected]) [-] [-] Networks On-Line - Houston, Texas [-] [-] 713-467-7100 [-] - - - - - - - - - - - - - - - - -
|