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
   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.






More information about the NANOG mailing list