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