Somehow I thought I could get away with not reading this list, since Alec was
reading it. Dunno what I was thinking. :-) Now I've joined...
Thanks to Avi and Perry for speaking so acurately for me over the last few
days. They've said most of what I would have, and saved me a lot of time
when I couldn't afford it.
I've scanned the back mail about SYN attacks and I have a few comments.
Justin asked about CPU usage on dialup servers. I have no idea what the
Ascends are like, but I suspect that within a single POP it's probably OK
to do your filtering at your core router(s), for those core routers that
connect things like MAXes to your backbone. Unless you have a lot of
customers with their own IPs, you can get away with filtering against
your own IP numbers (or whatever subnet you've allocated to the box(es)
connecting to the core router) on the outbound access-list for the upstream
port or ports on that core box. (Actually, it probably wouldn't be considered
a "core" router but rather an intermediate aggregator, if you have enough
MAXes or Annexes or whatever. But that's irrelevant.)
Of course, you can still lose: If you have a bunch of MAXes all on an
ethernet and you filter at a cisco that feeds them into your backbone,
any customer on one can attack any other customer on any other of those
boxes. But that's MUCH less dangerous than having no filters at all, and
a whole lot easier to track down (you know the attack is local to the
victim).
Someone else (sorry, I don't remember who) asked how the SYN floods can be
tracked down. It's late so I'll skip some details for now (I can fill in the
blanks later if necessary), but there are two ways I can think of.
I figured out the first Friday night while trying to get a handle on what
was happening to us. You can trace the packets backwards, one router at
a time, by using "debug packet ip <a.l.> detail". The a.l. permits attacking
packets (like "access-list 198 permit tcp any host <blah> eq smtp" and
"access-list 198 deny ip any any") and nothing else. This will show you
all the offending packets *AND* the physical interfaces they arrived on
and were sent to. The one fly in the ointment is that ciscos don't "see"
all the packets that go through them. To make the cisco see the packet, so
it can provide the debug output for it, it to filter *against* it on one
of the interfaces. So you create another a.l. which is the exact opposite
of the debug a.l. and apply it to the interface the packet is exiting.
Once you know the physical port the packet came from, you know the next
router (if it's a T1/T3) or at least the broadcast net it's on; usually
that net will be very small, only 2-4 hosts, and you can try each one to
pick up the trail.
Of course if you trace it back to a gigaswitch or something like that you
may have some trouble; maybe the best way to deal with this is to brute-
force it: look for the packet on everything that sends data into the switch
that the packet is exiting. There's probably a better way, but I haven't
thought of it...
The other technique is something Avi came up with. It involves playing
games with static routes to Null0 for the attacked host on routers which
may be carrying the attacking packets. But if you do this you have to make
*damn* sure you don't redistribute that static route (at least) into your
IGP... There's also a way to use route announcements to get a similar
effect but you have to be peering with a lot of people at someplace like
MAE-E to use it usefully. I'll let Avi provide details rather than mangle
this myself, given the hour.
Of course both techniques are quite labor-intensive. That's why we can't
afford a reactive attitude to these sorts of attacks.
I want to echo Avi and Perry's call for customer packet filtering on border
routers. If you still think that waiting for an attack and then tracking
down the perp is a good idea, I suggest that you shut down half your site
for four days and see how your customers like it. If anyone wants I'd be
happy to shut their site down for them. Free service. :-)
Anyway, sorry for the lousy sentence structure and singular/plural
disagreements. It's been a LONG week without much sleep.
/a
