Adding blacklists to Security Onion, using Snort's reputation preprocessor
1,246 views
Skip to first unread message
Shane Castle
Apr 15, 2016, 2:48:05 AM4/15/16
to securit...@googlegroups.com
As supplied, the Snort and Pulledpork configurations are almost completely set
up to add blacklists -- lists of IP addresses that should not be part of
conversations on your network. However, there are a couple of things that must
be changed in order to use them. This is a short how-to on adding blacklists to
Security Onion.
Both Snort (via Talos Intel) and Emerging Threats maintain blacklists. To
download them automatically with your Pulledpork run, add these lines to your
/etc/nsm/pulledpork/pulledpork.conf file:
rule_url=http://talosintel.com/feeds/ip-filter.blf|IPBLACKLIST|open
rule_url=http://rules.emergingthreatspro.com/open/snort-2.9.0/rules/compromised-ips.txt|IPBLACKLIST|open
You will also need to change two other lines in your pulledpork.conf.
Find the line beginning with "black_list=". This tells PP where to put the BL
that it has built. This must be
black_list=/etc/nsm/rules/black_list.rules
At the bottom of the next "paragraph" is a line beginning "IPRVersion=". Change
this to
IPRVersion=/etc/nsm/rules/
The snort.conf files should already be set up with the reputation preprocessor
defined and pointing to the BL file in /etc/nsm/rules. After making the above
changes to your pulledpork.conf, you can run
sudo rule-update
and your blacklists should be downloaded and merged into a single file in
/etc/nsm/rules, and your snort instances restarted.
When one of the blacklisted addresses is part of a conversation, the alert will
have a signature of the form: "reputation: Packet is blacklisted", the gen-id
will be 136 and the sig-id will be 1.
I have not experimented yet with adding local blacklist files. I urge you to
read /usr/share/doc/snort/README.reputation.gz before doing all this.
YMMV. Be careful. Check this on a test system before adding it to a production one.
--
Mit besten Grüßen
Shane Castle
up to add blacklists -- lists of IP addresses that should not be part of
conversations on your network. However, there are a couple of things that must
be changed in order to use them. This is a short how-to on adding blacklists to
Security Onion.
Both Snort (via Talos Intel) and Emerging Threats maintain blacklists. To
download them automatically with your Pulledpork run, add these lines to your
/etc/nsm/pulledpork/pulledpork.conf file:
rule_url=http://talosintel.com/feeds/ip-filter.blf|IPBLACKLIST|open
rule_url=http://rules.emergingthreatspro.com/open/snort-2.9.0/rules/compromised-ips.txt|IPBLACKLIST|open
You will also need to change two other lines in your pulledpork.conf.
Find the line beginning with "black_list=". This tells PP where to put the BL
that it has built. This must be
black_list=/etc/nsm/rules/black_list.rules
At the bottom of the next "paragraph" is a line beginning "IPRVersion=". Change
this to
IPRVersion=/etc/nsm/rules/
The snort.conf files should already be set up with the reputation preprocessor
defined and pointing to the BL file in /etc/nsm/rules. After making the above
changes to your pulledpork.conf, you can run
sudo rule-update
and your blacklists should be downloaded and merged into a single file in
/etc/nsm/rules, and your snort instances restarted.
When one of the blacklisted addresses is part of a conversation, the alert will
have a signature of the form: "reputation: Packet is blacklisted", the gen-id
will be 136 and the sig-id will be 1.
I have not experimented yet with adding local blacklist files. I urge you to
read /usr/share/doc/snort/README.reputation.gz before doing all this.
YMMV. Be careful. Check this on a test system before adding it to a production one.
--
Mit besten Grüßen
Shane Castle
Heine Lysemose
Apr 15, 2016, 4:15:04 AM4/15/16
to securit...@googlegroups.com
Note that adding pure IP rules are pretty resource intensive.
ET Black List currently adds 1060 extra rules
Talos Balck List currently adds 38243 extra rules
Regards,
Lysemose
--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
Shane Castle
Apr 15, 2016, 7:19:55 AM4/15/16
to securit...@googlegroups.com
As it happens, there is an issue with the setup as I have presented it.
Pulledpork is munging the URL of the second blacklist in a way I have not been
able to figure out yet and causing the pulledpork.pl script to croak, as the
munging of the URL causes a 404 Not Found error. (Insufficient testing before
posting. Guilty as charged, your honor.)
Also, to add another blacklist, you add another blacklist definition to the
reputation preprocessor config in snort.conf. This way a local blacklist and
whitelist can be maintained.
I have not looked at how rule-update and Salt will handle blacklists, so for now
this only works for a standalone SO setup.
And finally, the reputation preprocessor is supposed to shorten the processing
path for packets at the expense of using up more memory, granting a free pass to
whitelisted entries and an instant alert on blacklisted ones, depending on how
the reputation preprocessor is configured. The argument can be made that hits on
the blacklist will be more rare than those on the whitelist, so use of the
blacklist only is not saving much overall and that you must employ the whitelist
too in order to get real improved performance.
This is really an exercise and exploration of the capabilities of the Security
Onion NSM for me. I tried to enable a blacklist, it worked (at first, and after
some work), and I thought I'd share what I learned.
YMMV. Caveat lector. Benutzung auf eigene Gefahr.
> <mailto:security-onion%2Bunsu...@googlegroups.com>.
Pulledpork is munging the URL of the second blacklist in a way I have not been
able to figure out yet and causing the pulledpork.pl script to croak, as the
munging of the URL causes a 404 Not Found error. (Insufficient testing before
posting. Guilty as charged, your honor.)
Also, to add another blacklist, you add another blacklist definition to the
reputation preprocessor config in snort.conf. This way a local blacklist and
whitelist can be maintained.
I have not looked at how rule-update and Salt will handle blacklists, so for now
this only works for a standalone SO setup.
And finally, the reputation preprocessor is supposed to shorten the processing
path for packets at the expense of using up more memory, granting a free pass to
whitelisted entries and an instant alert on blacklisted ones, depending on how
the reputation preprocessor is configured. The argument can be made that hits on
the blacklist will be more rare than those on the whitelist, so use of the
blacklist only is not saving much overall and that you must employ the whitelist
too in order to get real improved performance.
This is really an exercise and exploration of the capabilities of the Security
Onion NSM for me. I tried to enable a blacklist, it worked (at first, and after
some work), and I thought I'd share what I learned.
YMMV. Caveat lector. Benutzung auf eigene Gefahr.
> To post to this group, send email to securit...@googlegroups.com
> <mailto:securit...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups
> "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to security-onio...@googlegroups.com
> <mailto:security-onio...@googlegroups.com>.
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups
> "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to security-onio...@googlegroups.com
> To post to this group, send email to securit...@googlegroups.com
> <mailto:securit...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.
> For more options, visit https://groups.google.com/d/optout.
Brian Haugli
Apr 17, 2016, 9:51:55 PM4/17/16
to security-onion
I've gotten good performance and hits using critical stack with it feeding into the bro intel framework. Just another option instead of using snort.
Kevin O'Grady
Apr 19, 2016, 6:02:47 PM4/19/16
to security-onion
+1 for Critical Stack
Doug Burks
Apr 19, 2016, 6:40:50 PM4/19/16
to securit...@googlegroups.com
Hi Shane,
Another option might be to use Jon Schipp's mal-dns2bro to convert
Snort and ET (among others) blacklists into Bro Intel format:
http://blog.bro.org/2014/01/intelligence-data-and-bro_4980.html
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
Another option might be to use Jon Schipp's mal-dns2bro to convert
Snort and ET (among others) blacklists into Bro Intel format:
http://blog.bro.org/2014/01/intelligence-data-and-bro_4980.html
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.
--
Doug Burks
> For more options, visit https://groups.google.com/d/optout.
--
steve baker
Jan 20, 2017, 11:31:13 AM1/20/17
to security-onion
For various non-technical reasons I am looking into adding blacklist capability to Snort instead of Bro, at least for the near future. I've been reading stuff like this:
http://blog.talosintel.com/2012/04/snort-performance-and-ip-only-rules.html
And wondering is the performance overhead mentioned in this thread really still an issue? The reading I'm finding makes it sound like it shouldn't be?
TIA
Steve
Reply all
Reply to author
Forward
0 new messages