Randy Bush <randy@psg.com> writes:
speaking as a small provider, I can tell you that I find running snort against my inbound traffic does reduce the cost of running an abuse desk. I do catch offenders before I get abuse@ complaints, sometimes.
unfortunately snort does not really scale to a larger provider. and, to the best of my poor knowledge, good open source tools to black-hole/redirect botted users are not generally available. universities have some that are good at campus and enterprise scale.
I can't speak to the scaling of snort (I only eat around 20Mbps, and snort on a 256Mb Xen VM handles it just fine) but I'm not sure what you are getting at with regards to open-source tools to blackhole or redirect botted users. I mean, we've all got hooks in our billing system (or some other procedure) to manually disable abusive (or non-paying) customers now, right? I guess I'm not seeing how it is any harder to have a script watching snort disable the customer than it is to have freeside disable the customer when they dont pay their bill. My current setup (and I'm not saying this is the right way, or even a good way to do it) is just snort logging to a file. I then have a perl script tailing that file and 'doing stuff' - right now, 'doing stuff' consists of figuring out if it is abuse from one of my customers (in which case it puts it in the log for me) or to one of my customers (in which case, it puts it in a log for that customer. I figure it doesn't cost me any extra, so I might as well let customers see incoming attacks.) If I sat down at it long enough to say 'alert X (or alert X, y times in Z seconds) means the customer is definately botted (or abusive)' setting the perl script to run a script that uses ssh to connect to my router and blackhole the customer (or or to connect to my freeside system and suspend the account) is if not trivial, at least fairly easy. It's certainly something I could give to the junior guy on my team, and while I'd want to check his work and test carefully before going live, I'm confident he could implement. If you really need something pre-built, check out: http://www.snortsam.net/ (I haven't used it, but I don't think it's the only tool of its kind.) the hard parts (as I see them) are going to be 1. identifying the snort attacks that mean a box should be shut down. I mean, I don't want to shut you down for a simple port-scan. Maybe you are checking one of your own networks? things like that are probably more of a 'warning' for the customers I target. This is probably easier on a network targeting 'normal' customers, 'cause you can prohibit many of those things in your AUP. Also, at this point, it's pretty important that you don't have a noticable number of false positives. you probably want to run your thing in notify-only mode for a while until you are comfortable. 2. making sure that your system doesn't turn in to an easy way to DOS another server on the same network. BCP38, if implemented tightly enough (something I'm doing quite well on IPv4, but not on IPv6) can largely fix this problem, and as you are watching for abuse behind your own router, is a realistic solution. But it still takes some effort.