[Snort-devel] [Snort-users] IP Blacklisting for Snort 188.8.131.52
roesch at ...402...
Wed May 13 15:37:21 EDT 2009
You can achieve the same thing via just putting the iplist
preprocessor instantiation in a separate file (blacklist.conf?) and
then including the file from Snort.conf. I didn't want to spend a lot
of time writing more file opening/reading/parsing logic and loops to
get this out more quickly so I stuck with the built-in parser. I
setup the runtime config of the system so that you could make multiple
calls to load the whitelist/blacklist if it gets bigger than Snort can
load in its standard parse buffer.
In that name field are you trying to denote the source of the
blacklist? Tracking that stuff within the data structure would either
require additional memory and complexity to produce the name or
multiple instantiations of the data structure and associated overhead.
I'd figure performance would be more important than the name but
that's just me talking. I could certainly add all this stuff but I
think basic and fast might be the better way to go from where I sit.
On Wed, May 13, 2009 at 3:31 PM, Seth Art <sethsec at ...2499...> wrote:
> Pretty cool!
> Suggestion: Rather than enter the IP addresses into snort.conf, it
> might be easier to manage something like this if we reference files
> that include the IP lists using a predefined syntax. That way you can
> download community based lists daily without ever having to update
> snort.conf each time.
> Something like this:
> preprocessor iplist: < noalerts > < nodrops > <directory>
> whitelist name <filename>
> blacklist name <filename>
> blacklist name <filename>
> preprocessor iplist:
> whitelist trusted /etc/snort/lists/trusted.list
> blacklist ET-dshield /etc/snort/lists/dshield.list
> blacklist ET-CC /etc/snort/lists/cc.list
> On Wed, May 13, 2009 at 2:50 PM, Martin Roesch <roesch at ...402...> wrote:
>> Hi everyone,
>> I wrote a patch for Snort 184.108.40.206 that implements IP blacklisting as a
>> preprocessor in Snort over this past weekend. We talked about this
>> last week on the mailing list in regards to trying to implement
>> blacklisting using regular Snort rules and how well that doesn't work.
>> This code has been tested against Snort 220.127.116.11 only. I've tested
>> builds on OS X, Ubuntu and Fedora so far. It requires libdnet (or
>> dumbnet-dev for those of you on Debian-based distros) to build
>> properly. Check the README file that comes with it for instructions
>> on patching it into your codebase. It supports inline blocking and
>> alerting but not Flexresp-style TCP reset session shootdowns.
>> Have a look and let me know what features you'd like or bugs you find.
>> This code is purely EXPERIMENTAL, this is just me spending some of my
>> spare time doing a fun coding project so if your machine sprouts legs
>> and refuses to work until it receives part of the TARP bailout it's
>> not my fault.
>> Here's the link:
>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>> Snort: Open Source IDP - http://www.snort.org
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> Snort-users mailing list
>> Snort-users at lists.sourceforge.net
>> Go to this URL to change user options or unsubscribe:
>> Snort-users list archive:
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
More information about the Snort-devel