NAP/ISP Saturation WAS: Re: Exchanges that matter...
hannan at uu.net
Sat Dec 21 01:47:40 UTC 1996
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.
] 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 184.108.40.206.
] > -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 (blh at nol.net) [-]
] [-] Networks On-Line - Houston, Texas [-]
] [-] 713-467-7100 [-]
More information about the NANOG