[Snort-devel] [Snort-users] IP Blacklisting for Snort 184.108.40.206
roesch at ...402...
Wed May 13 21:13:30 EDT 2009
The alerts look exactly like standard preprocessor alerts, I'm using
GID 135 for the plugin and it only generates one message. I could get
fancier with some of it but noting the origin of a blacklisted IP
would be a bit of a pain. The ptrie structure does support attaching
data to the address entries but where there are collisions the logic
will get more complex and it makes the parsing more complex too. If
we can live with it this way that makes life easiest for me but if
someone makes a good use case for it I'll implement it.
On Wed, May 13, 2009 at 4:02 PM, Seth Art <sethsec at ...2499...> wrote:
> I am pretty sure a blacklist.conf, called in snort.conf would do the trick.
> With the name thing, I think it would be informative to record why
> each IP was blocked or alerted on.
> The high speed functionality is great, don't get me wrong. Obviously
> we cant have all the info we get from a sig, AND have a high speed
> preproc, however I assume the alerts will look like any other preproc
> alert, right? If I could pick one piece of information to have in
> addition to the IP, it would be a classification (command and control,
> malware, spam servers, rbn, etc). I think this would help with
> If the additional memory/complexity would defeat the purpose of having
> the high speed preproc in the first place, then I agree that it might
> not make sense.
> Either way, I am looking forward to testing it out. Thanks.
> On Wed, May 13, 2009 at 3:37 PM, Martin Roesch <roesch at ...402...> wrote:
>> 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 220.127.116.11 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 18.104.22.168 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
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