Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...]
Luke S Crawford
lsc at prgmr.com
Sat Dec 20 00:55:11 CST 2008
Randy Bush <randy at 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 [email protected] 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
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.
More information about the NANOG