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...
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 22.214.171.124. ] > ] > -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@example.com) [-] ] [-] Networks On-Line - Houston, Texas [-] ] [-] 713-467-7100 [-] ] - - - - - - - - - - - - - - - - -