Time to own your rules - PulledPork 0.3.4 Released!

After what seems like forever since I have made a post about anything, I am pleased to announce the general availability of the latest version of PulledPork! This new version (v0.3.4) has a significant number of bugfixes for a variety of OS/distributions in addition to the numerous feature enhancements noted below.

I would like to thank all of the individuals that provided beta testing assistance and valuable feedback. I would also like to thank all of the users that have adopted PulledPork and sent in comments / feature requests. PulledPork certainly would not be where it is without your support and contributions!

Now that we are through the mushy stuff, on to the features!

VRT Rulesets! - Support metadata based VRT recommended rulesets - The short of it is that you can now specify a default pre-defined ruleset, yes.. this ruleset was designed by the VRT! The individual pre-defined rulesets that can be specified are fairly straightforward:

• Connectivity - You run a lot of real time applications (VOIP, financial transactions, etc), and don't want to run any rules that could affect the current performance of your sensor. The rules in this category make snort happy, additionally this category focuses on the high profile most likely to affect the largest number of people type of vulnerabilities.

• Balanced - You are normal, you run normal stuff and you want normal security protections. This is the best policy to start from if you are new, old, or just plain average. If you don't have any special requirements for super high speeds or super secure networks, start here.

• Security - You don't care about dropping your bosses email, everything in your environment is tightly regulated and you don't tolerate people stepping outside of your security policy. This policy hates on IM, P2P, vulnerabilities, malware, web apps that cause productivity loss, remote access, and just about anything not related to getting work done. If you run your network with an iron fist, start here!

Changelog - This feature allows you to specify that you want a changelog (any rule that has any change in it from your previous ruleset, i.e. disabled, enabled, modified etc..) maintained for any and all changes, in a specified log file.

Inline Drops - This feature allows you to specify what SIDs you want to be set to drop, for those running an inline setup!

Multiline Rules - Added full support for parsing of multiline rules.

Enhancements - Many minor enhancements made to the debugging output, speed enhancements, code cleanup, error handling etc...

There are quite a few runtime options and configuration options, please be sure to read through the README files thoroughly, also please be sure to use the latest pulledpork.conf that is included in the tarball! That's about it for now, please feel free to participate by asking questions on the mail list at http://groups.google.com/group/pulledpork-users/ or on freenode in #snort or #pulledpork

One final note, all of the release tarballs will now be named as pulledpork-X.X.X.tar.gz to help out with those maintaining packages and ports, thanks!

Download the tarball here pulledpork-0.3.4.tar.gz
MD5SUM = 034f90a2555c5f82e760b0ce68489ad2
SHA256 = 8b775e6476d653733f3d29ea9c962a76feaf148f3204a90fd47c646802448b80

Cheers,
JJC

Pulledpork v0.2.5 - Released

A new and updated version of pulledpork is out, this version adds functionality and also addresses a number of previously reported bugs, a few simple examples:

• Improved and cleaned up code for efficiency and speed
• Do not overwrite local.rules on run
• Do not attempt to copy . and .. as rules files
• Much more...

The primary feature that has been added allows for the capability to download rules from sites other than snort.org (VRT). Any url can be specified to download a rules tarball from, however md5 hash verification will only work when VRT or ET locations are specified. If a different location (i.e. a local redistribution point) is specified, please be sure to specify the -d (do not verify md5) option. Please see the README and pulledpork.conf files for more information on usage of new and existing options and features.

New option runtime flag:

• -u Where do you want me to pull the rules tarball from

(ET, Snort.org, see pulledpork config base_url option for value ideas)

A new tarball containing all of the new features will be published today at http://code.google.com/p/pulledpork/downloads/list

pulledpork 0.2.2 and new features

Get it while it's hot @here!

I have received a few requests to build support into pulledpork for the restarting of processes (i.e. snort after downloading new rules or modifying the ruleset using disablesid). In response to this, it is done ^-^. You will note in the pulledpork.conf file that there is a new option at the bottom called pid_path. Simply list the path to your pid files (/var/run/snort_intx.pid,/path/to/another/pid.pid) etc... and specify -H at runtime.. you will be magically pleased (assuming you run pulledpork under a context that has permissions to restart said PID).

I also added a second option "-n" that will allow you to make modifications to the disablesid.conf file and re-execute pulledpork without attempting to download the current ruleset or md5 again (ala tuning exercises...).

Please see the included README for additional info and general guidelines on usage... below is some sample output.

./pulledpork.pl -c ../pulledpork.conf -i disablesid.conf -THn
Prepping files for work....
Done!
Copying rules files....
Done!
Disabling your chosen SID's....
Disabled 1 rules in /usr/local/etc/snort/rules/web-iis.rules
Disabled 2 rules in /usr/local/etc/snort/rules/backdoor.rules
Disabled 1 rules in /usr/local/etc/snort/rules/rpc.rules
Disabled 1 rules in /usr/local/etc/snort/rules/exploit.rules
Done
HangUP Time....
Done!
Fly Piggy Fly!

That's all for now, enjoy!

JJC

Snorby for Snort, a Recipe with Barnyard2 and Unified2

Snorby, an all new frontend (yes, it's still Beta) for snort has recently emerged. As such I decided that I would take a look and give my thoughts as well as a quick recipe to get it running fairly quickly using barnyard2. During my testing of Snorby, I talked with the creator (mephux) about his plans for Snorby and also worked through a couple of bugs, that he jumped on right away.

Note: This posting details how to get Snorby working with apache and passenger, NOT Webrick.. if you want that please read the details of how to do so at the Snorby site.

Recipe Components:

• FreeBSD 8.0R
• apache22
• ruby-gems
• ruby-iconv
  
• prawn (gem)
  
• rake (gem)
  
• mysql (gem)
• rails (gem)
  
• passenger (formerly modrails)
• mysql
• snort
• barnyard2
• git

Ok, let's get the dependencies and such out of the way. I am making several assumptions in writing this... the least of which is that you know how to use google if you can't figure something out... also that you already have the base of some of these items installed (ala, FreeBSD, apache, snort). If not, I have previous posts that discuss the setup of said items, and I am again going to drop the google bomb!

We need ruby-gems to get passenger running and ultimately Snorby:

$ cd /usr/ports/devel/git/ && sudo make install clean
...I deselect all of the options, I just want regular old git for this exercise
...output suppressed
$ cd /usr/ports/devel/ruby-gems/ && sudo make install clean
...output suppressed
$ sudo gem install prawn --no-rdoc --no-ri
...output suppressed
$ sudo gem install rake --no-rdoc --no-ri
...output suppressed
$ sudo gem install rails --no-rdoc --no-ri
...output suppressed
$ sudo gem install mysql --no-rdoc --no-ri
...output suppressed
$ sudo gem install passenger --no-rdoc --no-ri
...output suppressed
$ sudo passenger-install-apache2-module
...run through the setup and perform the steps that are noted to activate the passenger capabilities with apache.. ala vi httpd.conf and add the 3 lines that you are told to.
$ cd /usr/local/www/ && sudo git clone git://github.com/mephux/Snorby.git
...output suppressed/usr/ports/converters/ruby-iconv
$ cd /usr/ports/converters/ruby-iconv && sudo make install clean

At this point you are ready to modify your database and email configuration for Snorby. If you have not done so, you should create a snort database (I have called mine snort and created a user "snorby" with password "snorby".. ok that's not really the password but for this writeup it is! This user has full access (not grant) to the snort database. I have also created the apt tables in this database using the create_mysql sql that is included in both Snorby and Snort!

$ sudo cp /usr/local/www/Snorby/config/database.yml.example /usr/local/www/Snorby/config/database.yml
$ sudo cp /usr/local/www/Snorby/config/email.yml.example /usr/local/www/Snorby/config/email.yml

Now choose your preferred editor and modify the /usr/local/www/Snorby/config/database.yml file.. we are only concerned with the production info... you can also modify the email.yml but don't have to for our current purposes.

Install additional gem requirements and setup Snorby to run!

$ cd /usr/local/www/Snorby && sudo rake gems:install
...output suppressed
$ cd /usr/local/www/Snorby && sudo rake snorby:setup RAILS_ENV=production
...output suppressed

At this point you are ready to tell apache all about Snorby, so lets modify our vhost or apache config again. Simply add the following under the vhost of your choice, you need to be sure that RewriteEngine On and RewriteOptions inherit are specified in this vhost (or in scope of your config):

DocumentRoot /usr/local/www/Snorby/public

RailsBaseURI /

<directory "/usr/local/www/Snorby/public">
AllowOverride All
Order deny,allow
Allow from all
</directory>

Once this is complete, restart apache and you will get the login for Snorby when you browse to that vhost. The default username is snorby and password is admin.

We are now ready to modify our snort config to output unified2, modify your snort.conf and comment out your old output plugins or simply replace them with the following:

output unified2: filename snortunified2.log, limit 128

Note that unified2 contains all log and alert data, so no longer do you need two files! And now it's time for barnyard2. Go ahead and fetch the latest version from securixlive.com, configure with "--with-mysql" option. Once that is done copy the barnyard.conf to /usr/local/etc/snort/ and let's go ahead and edit that file, putting in the mysql information that you used with Snorby earlier and making sure that we have our input specified as unified2. You should go through and make sure that all of the paths to the map and ref files are specified correctly. Once that's done, you are ready to fire it up!

sudo barnyard2 -c /usr/local/etc/snort/barnyard2.conf -d /var/log/snort -f snortunified2.log -w /var/log/snort/barnyard2.waldo -D

You should now be receiving events in the snort mysql database and seeing them in Snorby.

Please note that there are a number of security considerations that I did not take into account (ala running all this stuff under root) so please take that into consideration.

Overall, I give Snorby a good rating, it certainly has lots of eye candy at this point. Mephux promises that much of the functionality that everyone wants is coming shortly... I would say that Snorby has a good start and promises to be a decent usable frontend for viewing snort events. Is it a sguil, certainly not... but it does look like it will be a decent alternative to BASE.

Cheers,
JJC

pulledpork included in Security Onion LiveCD

Today, Doug Burks (the creator of the Security Onion LiveCD) announced the release of the latest rev of this tool. Included in this tool are "you guessed it" pulledpork and a number of other useful tools to the sekuritah professional :-)

Read more here => http://securityonion.blogspot.com/2009/06/security-onion-livecd-20090613.html

I would like to extend a thanks to Doug for his work on this tool and the inclusion of pulledpork and the other tools. While I have not yet had the opportunity to download and try out this LiveCD, I will be doing so soon.

Cheers,
JJC

How to block robots.. before they hit robots.txt - ala: mod_security

As many of you know, robots (in their many forms) can be quite pesky when it comes to crawling your site, indexing things that you don't want indexed. Yes, there is the standard of putting a robots.txt in your webroot, but that is often not highly effective. This is due to a number of facts... the least of which is not that robots tend to be poorly written to begin with and thus simply ignore the robots.txt anyway.

This comes up because a friend of mine that runs a big e-com site recently asked me.. "J, how can I block everything from these robots, I simply don't want them crawling our site." My typical response to this was "you know that you will then block these search engines and keep them from indexing your site"... to whit "yes, none of our sales are organic, they all come from referring partners and affiliate programs".... That's all that I needed to know... as long as it doesn't break anything that they need heh.

After puting some thought into it, and deciding that there was no really easy way to do this on a firewall, I decided that the best way to do it was to create some mod_security rules that looked for known robots and returned a 404 whenever any such monster hit the site. This made the most sense because they are running an Apache reverse proxy in front of their web application servers with mod_security (and some other fun).

A quick search on the internet found the robotstxt.org site that contained a listing (http://www.robotstxt.org/db/all.txt) of quite a few common robots. Looking through this file, all that I really cared about was the robots-useragent value. As such, I quickly whipped up the following perl that automaticaly creates a file named modsecurity_crs_36_all_robots.conf. Simply place this file in the apt path (for me /usr/local/etc/apache/Includes/mod_security2/) and restart your apache... voila.. now only (for the most part) users can browse your webserver. I'll not get into other complex setups, but you could do this on a per directory level also, from your httpd.conf, and mimic robots.txt (except the robots can't ignore the 404 muahahaha).

#####################Begin Perl#######################

#!/usr/bin/perl

##
## Quick little routine to pull the user-agent string out of the
## all.txt file from the robots project, with the intention of creating
## regular expression block rules so that they can no longer crawl
## against the rules!
## Copyright JJ Cummings 2009
## cummingsj@gmail.com
##

use strict;
use warnings;
use File::Path;

my ($line,$orig);
my $c = 1000000;
my $file = "all.txt";
my $write = "modsecurity_crs_36_all_robots.conf";
open (DATA,"<$file");
my @lines = ;
close (DATA);

open (WRITE,">$write");
print WRITE "#\n#\tQuick list of known robots that are parsable via http://www.robotstxt.org/db/all.txt\n";
print WRITE "#\tgenerated by robots.pl written by JJ Cummings \n\n";
foreach $line(@lines){
if ($line=~/robot-useragent:/i){
$line=~s/robot-useragent://;
$line=~s/^\s+//;
$line=~s/\s+$//;
$orig=$line;
$line=~s/\//\\\//g;
#$line=~s/\s/\\ /g;
$line=~s/\./\\\./g;
$line=~s/\!/\\\!/g;
$line=~s/\?/\\\?/g;
$line=~s/\$/\\\$/g;
$line=~s/\+/\\\+/g;
$line=~s/\|/\\\|/g;
$line=~s/\{/\\\{/g;
$line=~s/\}/\\\}/g;
$line=~s/\(/\\\(/g;
$line=~s/\)/\\\)/g;
$line=~s/\*/\\\*/g;
$line=~s/X/\./g;
$line=lc($line);
chomp($line);
if (($line ne "") && ($line !~ "no") && ($line !~ /none/i)) {
$c++;
$orig=~s/'//g;
$orig=~s/`//g;
chomp($orig);
print WRITE "SecRule REQUEST_HEADERS:User-Agent \"$line\" \\\n";
print WRITE "\t\"phase:2,t:none,t:lowercase,deny,log,auditlog,status:404,msg:'Automated Web Crawler Block Activity',id:'$c',tag:'AUTOMATION/BOTS',severity:'2'\"\n";
}
}
}
close (WRITE);
$c=$c-1000000;
print "$c total robots\n";

#####################End Perl#######################

To use the above, you have to save the all.txt file to the same directory as the perl.. and of course have +w permissions so that the perl can create the apt new file. This is a pretty basic routine... I wrote it in about 5 minutes (with a few extra minutes for tweaking of the ruleset format output (displayed below). So please, feel free to modify / enhance / whatever to fit your own needs as best you deem. **yes, I did shrink it so that it would format correctly here**

#####################Begin Example Output#######################

SecRule REQUEST_HEADERS:User-Agent "abcdatos botlink\/1\.0\.2 \(test links\)" \
"phase:2,t:none,t:lowercase,deny,log,auditlog,status:404,msg:'Automated Web Crawler Block Activity',id:'1000001',tag:'AUTOMATION/BOTS',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "'ahoy\! the homepage finder'" \
"phase:2,t:none,t:lowercase,deny,log,auditlog,status:404,msg:'Automated Web Crawler Block Activity',id:'1000002',tag:'AUTOMATION/BOTS',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "alkalinebot" \
"phase:2,t:none,t:lowercase,deny,log,auditlog,status:404,msg:'Automated Web Crawler Block Activity',id:'1000003',tag:'AUTOMATION/BOTS',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "anthillv1\.1" \
"phase:2,t:none,t:lowercase,deny,log,auditlog,status:404,msg:'Automated Web Crawler Block Activity',id:'1000004',tag:'AUTOMATION/BOTS',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "appie\/1\.1" \
"phase:2,t:none,t:lowercase,deny,log,auditlog,status:404,msg:'Automated Web Crawler Block Activity',id:'1000005',tag:'AUTOMATION/BOTS',severity:'2'"

#####################End Example Output#######################

And that folks, is how you destroy robots that you don't like.. you can modify the error that returns to fit whatever suits you best.. 403, 404.....

Cheers,
JJC

pulledpork tarball

It's up... get it while it's hot -> http://code.google.com/p/pulledpork/downloads/list

Cheers,
JJC

v0.2 Beta 1 is the outed! -> pulledpork that is <-

As the title indicates, the first beta for v0.2 of pulledpork has just been checked in to the pulledpork svn..

A shortlist of the current featuresets below



Release 0.1:

• First Beta Release
• Downloads latest rules file
• Verifies MD5 of local rules file
• If MD5 has not changed from snort.org.. doesn't fetch files again
• handle both rules and so_rules
• Capability to generate stub files

Release 0.2:

• Rule modification, i.e. disabling of specific rules within rule sets (also for GID 3 rules)
  
• Outputs changes in rules files if any rules have been added / modified
• Compares new rules files with current rule sets
  

So, as you can see above I have added quite a bit of code and functionality to pulled pork. The disablesid function should be pretty robust (perhaps I'll add some additional error handling), but for the most part it should rock and roll!

I'll likely be adding a modifysid section to mirror what oinkmaster does with their modifysid function.. but that's probably still a few weeks out.

Having said all of this, please download, test and post any bugs/issues that you find on the google code page for pulledpork or catch me in #snort on freenode.

And now, the gratuatis screenshot ;-)


Cheers,
JJC

PulledPork Checkin

Quick update today with big enhancements coming this week in the bbq pulledpork arena! (hopefully).

This past Friday I checked in some code for PulledPork that allows for the handling of any format contents of md5 file from the snort.org servers.. we won't be foiled again ;-)

Get your great tasting pulledpork here => http://code.google.com/p/pulledpork

Cheers,
JJC

Pimping Tha All New Snort.org

The home of Snort, snort.org received a facelift last night! The site has been largely static and unchanged for some time now.

A shortlist of the new features on the new snort.org that should make life easier for all:



• New navigation
• Improved account management
• New user forums
• Persistent link panel
• Improved VRT subscription management

What this does NOT mean is that your tools that automatically fetch snort rules tarballs will be broken... everything is still 100% functional and up in that area.

Having said all of this, please check out the new snort.org for yourself!

I extend a hearty good job to the entire snort.org team for their efforts in this, it looks and functions excellently!

Cheers,
JJC

Snort 2.8.5 at snort.org... get it while it's hot!

A beta version of Snort 2.8.5 is now available on snort.org, at
http://www.snort.org/dl/

Snort 2.8.5 introduces:

- Ability to specify multiple configurations (snort.conf and everything
it includes), bound either by Vlan ID or IP Address. This allows you
to run one instance of Snort with multiple snort.conf, rather than
having separate processes.

- Continued inspection of traffic while reloading a configuration.
Add --enable-reload option to your configure script prior to building.

- Rate Based Attack prevention for Connection Attempts, Concurrent
Connections, and improved rule/event filtering. See README.filters
for details.

- SSH preprocessor (no longer experimental)

- Performance improvements in various places

Please see the Release Notes and ChangeLog for more details.

Please submit bugs, questions, and feedback to snort-beta@sourcefire.com.

Baconator - Shared Object Snort Rule Management!

Recently while taking a plane ride from one lovely airport to another and doing some snort shared object rule development, I realized that I did not have a clean and easy way of fetching the latest snort rule tarball.

Don't get me wrong and misinterpret this post, I love Oinkmaster and have been a user of it for many a year!

Now, having said that... Oinkmaster does have it's shortcomings (for me anyway); the least of which is certainly not the fact that it currently does NOT handle shared object rules. With the release of Snort 2.8.4 and it's awesome new dcerpc2 preprocessor... the use of so_rules will most likely be much more prevalent.. and as such, with threats like Conficker and it's varients out there, I needed a way to handle this.

I did consider modifying Oinkmaster to fit my needs, but when I started writing the code at 30,000 feet... I didn't have the Oinkmaster codebase with me.

As a direct result of this thought and the lack of codebase on the plane... I started Baconator. Baconator is a Snort rule management tool that also handles so_rules, the creation of stub files from said so_rules, complete file validation (via MD5) against current VRT releases. It also does much more... or, will anyway.

I'll be posting more about Baconator as I complete the code. For now, if you want to try it out (it's not yet complete) you can checkout the code from the svn repo at http://code.google.com/p/baconator/.

The current code will fetch the latest ruleset from snort.org (ultimately I'll probably build the functionality in to fetch from ET). If you have an existing copy of the rules tarball from snort.org it will fetch the latest rule tarball md5 from snort.org and compare so that it doesn't re-fetch the same tarball again. It then performs the various extraction routines as defined in the conf file or at runtime and puts the files where you tell it to.. the rules files that is!

More info can be found on the google code page for Baconator. I'll also be updating that site regularly with updates to the timeline, current svn etc...

Cheers,
JJC

PHPIDS Phase 1.1

I have been reviewing PHPIDS for some time now, and have come to the conclusion that while a novel idea... it is simply overkill and extra rubbish to include in your php code. I also have some ideas surrounding evasion techniques.... Don't get me wrong, I think that in the right place (i.e. a server that you can not load a real IDS/IPS such as mod_security on) it is better than nothing. I will place one caveat on that though, I am not 100% sure what it does to load capacity (or increasing the load of) and existing site. I'll be conducting some extensive load testing on it over the next week or so and posting those results.

JJC

openpacket.org

I recently took over managing and maintaining OpenPacket.org from Richard Bejtlich of TaoSecurity. I would like to extend my thanks to Richard for his time and efforts in getting OpenPacket.org off the ground.

The mission of OpenPacket.org is to provide quality network traffic traces to researchers, analysts, and other members of the digital security community. One of the most difficult problems facing researchers, analysts, and others is understanding traffic carried by networks. At present there is no central repository of traces from which a student of network traffic could draw samples. OpenPacket.org provides one possible solution to this problem.

Analysts looking for network traffic of a particular type can visit OpenPacket.org, query the OpenPacket.org capture repo for matching traces, and download those packets in their original format (e.g., Libpcap, etc.). The analyst will be able to process and analyze that traffic using tools of their choice, like Tcpdump, Snort, Ethereal, and so on.

Analysts who collect their own traffic will be able to submit it to the OpenPacket.org database after they register.

Anonymous users can download any trace that's published. Only registered users can upload. This system provides a level of accountability for trace uploads.

Our moderators will review the trace to ensure it does not contain any sensitive information that should not be posted publicly. Besides appearing on the site, once a trace has been published you can receive notice of it via this published trace RSS feed.

If you have any doubt regarding the publication of a trace, do not try to submit it. When moderators are unsure of the nature of a trace, we will reject it. OpenPacket.org is not a vehicle for publishing enterprise data as contained in network traffic.

In the upcoming months you will see significant changes and improvements to the OpenPacket.org site. Many of these suggestions are the result of user feedback, so please keep it coming and stay tuned as updates are released!

JJC

"Block the Bad" OSS IPS with Content Filtration and Transparent Proxy Acceleration pt 1.

In this two part series I will discuss and demonstrate the creation of an inline security and content filtration system built on FreeBSD 7.0R. What is a security and content filtration system you might ask? Simply put it is a system that has the capabilities of an IPS with the included benefit of advanced content filtration (things like blacklists, page content scoring "keywords etc", greylists, whitelists and so on...).

This first part, entitled "block the bad" will deal with the IPS aspect of the system that includes some new "or newly revisited" ways of utilizing snortsam with barnyard rather than directly patching snort. This is good for a variety of reasons that include the capability to keep your snort version updated without having to continually re-patch it for snortsam, and not having to load snort down with more work than what it was intended "SNIFFING J00r PAket F00".

Some things in the below documented barnyard snortsam plugin have been hacked together, and I am sure that more capable individuals "rotorhead, Obiwan..." will write a non-hacked-together plugin in the near future. But this will get you up and rolling for now.

A few assumptions are made before we get started... the first is that you have already built snort (2.8.1 is the latest as of the time I wrote this), and if not that you can follow the directions to do so on a previous posting of mine. The second assumes if you want to see output such as BASE, you read and followed that entire posting. The third assumption is that you know how to modify your kernel options and ultimately make and install a new kernel. The fourth and final assumption is that if any of the previous assumptions are not true, you know how to use google.

Now, to the heart of the subject at hand, we will be using the following for the remainder of the excercise:

1. Snort 2.8.1 (see above)
2. barnyard 0.20.0 (with a modified snortsam plugin)
3. snortsam 2.52
4. ipf
5. ipfw (this will come into play in the next part re: content filtering, but can also be used to block by entire source or destination *not protocol/port* hence ipf)

So, for our first step (since we have snort built/running) let's get our barnyard patched so that we have the snortsam plugin. If you previously built barnyard and still have all of the source, that's great... but remember to make clean before we do anything. For my purposes I'll be demonstrating with a freshly downloaded barnyard. You will need autotools "cd /usr/ports/devel/autotools/ && make install clean" to finish the patch work.

[jj@Azazel /usr/home/jj]$ wget http://www.snort.org/dl/barnyard/barnyard-0.2.0.tar.gz

2008-04-13 18:14:39 (537 KB/s) - `barnyard-0.2.0.tar.gz' saved [161543/161543]

[jj@Azazel /usr/home/jj]$ tar xvfz barnyard-0.2.0.tar.gz
x barnyard-0.2.0/

[jj@Azazel /usr/home/jj]$ wget http://www.snortsam.net/files/barnyard-plugin/barnyard-snortsam-patch.gz

2008-04-13 18:16:37 (148 KB/s) - `barnyard-snortsam-patch.gz' saved [27149/27149]

[jj@Azazel /usr/home/jj]$ gunzip barnyard-snortsam-patch.gz
[jj@Azazel /usr/home/jj]$ cd barnyard-0.2.0
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$ patch -p1 < ../barnyard-snortsam-patch
Hmm... Looks like a unified diff to me...
...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 33.
Hunk #3 succeeded at 54.
...
done
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$ ./autojunk.sh
configure.in:147: warning: underquoted definition of SN_CHECK_DECL
configure.in:147: run info '(automake)Extending aclocal'
configure.in:147: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
autoheader-2.61: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader-2.61: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader-2.61: WARNING: is deprecated and discouraged.
autoheader-2.61:
autoheader-2.61: WARNING: Using the third argument of `AC_DEFINE' and
autoheader-2.61: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without
autoheader-2.61: WARNING: `acconfig.h':
autoheader-2.61:
autoheader-2.61: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader-2.61: [Define if a function `main' is needed.])
autoheader-2.61:
autoheader-2.61: WARNING: More sophisticated templates can also be produced, see the
autoheader-2.61: WARNING: documentation.
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$

Now that we have the main part of the patch completed we need to make a few quick modifications to "src/output-plugins/op_alert_fwsam.c" so that it handles the barnyard output properly and loads the sid-msg.map file via a hard coded path (line 191). I threw a patch out there so that you don't need to do this manually, located here: http://www.redsphereglobal.com/data/tools/security/patches/barnyard-snortsam-hack.gz.

[jj@Azazel /usr/home/jj]$ wget http://www.redsphereglobal.com/data/tools/security/patches/barnyard-snortsam-hack.gz

2008-04-13 18:52:54 (1.15 MB/s) - `barnyard-snortsam-hack.gz' saved [641/641]

[jj@Azazel /usr/home/jj]$ gunzip barnyard-snortsam-hack.gz
[jj@Azazel /usr/home/jj]$ cd barnyard-0.2.0
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$ patch -p1 < ../barnyard-snortsam-hack Hmm... Looks like a unified diff to me... The text leading up to this was: ...
Patching file src/output-plugins/op_alert_fwsam.c using Plan A...
Hunk #1 succeeded at 188.
Hunk #2 succeeded at 815.
done
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$

This patch or "hack" has assumed that the location of your sid-msg.map is at /usr/local/etc/snort/sid-msg.map if this is not the case, you will need to edit /src/output-plugins/op_alert_fwsam.c around line 191 and specify the correct path. At this point you can configure barnyard and build as you normally would.

[jj@Azazel /usr/home/jj/barnyard-0.2.0]$./configure --enable-mysql
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$make
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$sudo make install

Your barnyard is now ready and we will cover the config file and startup after we get ipf and snortsam up and running.

The next step is to add the following to our Kernel so that we have ipf and ipfw enabled and running by default at boot.

# IPFW support

options IPFIREWALL #Enable IPFW directly in the kernel
options IPFIREWALL_FORWARD #Enable the Ip Forwarding function of IPFW
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT #allow this host to divert packets to/through different ints and routes

# IPF Support - default is to accept
options IPFILTER
options IPFILTER_LOG

Once these have been added please build your kernel, install and reboot. At this point we are ready to fetch and make snortsam.

[jj@Azazel /usr/home/jj]$ wget http://www.snortsam.net/files/snortsam/snortsam-src-2.52.tar.gz

2008-04-13 19:17:28 (497 KB/s) - `snortsam-src-2.52.tar.gz' saved [1075606/1075606]

[jj@Azazel /usr/home/jj]$ tar xvfz snortsam-src-2.52.tar.gz
x snortsam
[jj@Azazel /usr/home/jj]$ cd snortsam
[jj@Azazel /usr/home/jj/snortsam]$ sh ./makesnortsam.sh
-------------------------------------------------------------------------------
Building SnortSam (release)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Building SnortSam (debug)
-------------------------------------------------------------------------------
Done.
[jj@Azazel /usr/home/jj/snortsam]$sudo cp snortsam* /usr/local/bin/

That's it for the snortsam build, now we are ready to configure everything and fire it up for a test! The first thing that we will configure is our snortsam. There is a good amount of documentation under snortsam/docs/README.conf that covers basic configuration. For our purposes we will create the file /etc/snortsam.conf and place the following in it.

defaultkey secrets
port 6783
accept 192.168.1.0/24
keyinterval 30 minutes
ipf bge0

This configuration specifies a default key of "secrets" and that the snortsam daemon should listen on port 6783 for connectoins from the 192.168.1.0/24 network. The configuration also specifies that the connection between the client (barnyard) and snortsam daemon will be rekeyed every 30 minutes and that ipf will be used on bge0 locally.

On to the barnyard configuration, this file will be barnyard-snortsam.conf located at /usr/local/etc/. The only line that needs to be in this file is the one that calls the snortsam plugin for barnyard and specifies the host:port/password

output alert_fwsam: 192.168.1.7:6783/secrets

The barnyard snortsam plugin uses a sid-block.map file to define what sids will be blocked, how they will be blocked and for how long they will be blocked. The format is quite simple "sid: where[option],duration;" and to test we will put the file at /usr/local/etc/snort/sid-block.map with the following entry

9999999: src[conn], 15 seconds;

I chose sid 9999999 so that I could create a custom rule in my local.rules to test my configuration.

alert icmp any any -> 1.2.3.4 any (msg:"test"; sid:9999999;)

Assuming you were able to add that rule, we are now at the point to fire things up and give it a good old fashioned roll (all in debugging verbose mode of course)!

Restart your snort so that it sees the new SID if you have not done so... -HUP FTW!@!!
Start snortsam (must be as root right now to have access to ipf)

[jj@Azazel /usr/home/jj]$ sudo snortsam-debug

Start barnyard with the new config file (even if you have a previosly running barnyard from the previous security appliance article... this will run at the same time, we have specified a new waldo file and pid file). Note that the following is ALL ONE LINE... no line breaks or crs! Note that this uses the snort.alert and not the snort.log just like the syslog facility.

[jj@Azazel /usr/home/jj]$ sudo /usr/local/bin/barnyard -c /usr/local/etc/barnyard-snortsam.conf -g /usr/local/etc/snort/gen-msg.map -s /usr/local/etc/snort/sid-msg.map -d /var/log/snort/ -f snort.alert -w /var/log/snort/barnyard-snortsam.waldo -p /usr/local/etc/snort/classification.config -X /var/barnyard-snortsam.pid -vvv

After starting barnyard you should see the following debug output from your snortsam-debug:

Debug: Connection from: 192.168.1.7.
Debug: Received Packet: CHECKIN
Debug: Snort SeqNo: cbb9
Debug: Mgmt SeqNo : 7000
Debug: Status : 1
Debug: Version : 14

Now that everything is up and running we can test. The best way to test all aspects is to point a separate system at the IP of this box (default router/gateway) or on my system as evident by the above config "192.168.1.7" and ping 1.2.3.4 with that separate system. The ipfw options that we previously set in the kernel will allow this host to simply route the traffic to the proper destination. You should see debug output from your snortsam-debug as such:

Blocking host 192.168.1.43 in connection 192.168.1.43->1.2.3.4:0 (icmp) for 60 seconds (Sig_ID: 9999999).
Debug: [ipf][28201600] Plugin Blocking...
Debug: [ipf][28201600] command /bin/echo "@1 block in log level local7.info quick on bge0 proto 1 from 192.168.1.43/32 to 1.2.3.4/32"|/sbin/ipf -f -

We can see from the output that it is blocking the source address of 192.168.1.43 and proto 1 (ICMP) only. This means that this host can still browse the internet and do everything (other than send icmp to 1.2.3.4 for 60 seconds), this is a function of the [conn] option in the sid-block.map file.

Wonderful, we now have a functioning version of snortsam running off of the snort output and not snort directly. This means that we can upgrade / change our snort instance itself and not have to re-patch and mess with that... (this of course assumes that the version you use can output unified so that your patched version of barnyard can read it). The final step in this process is to add the sids that you want to block to the sid-msg.map file. I have modified the create-sidmap.pl file to create a sid-block.map compatible output by reading all of the .rules files in a directory and dumping "sid: src[conn], 30min;" output. This output blocks the service by source that the alert was generated from for 30 minutes. The file can be obtained at http://www.redsphereglobal.com/data/tools/security/patches/create-sidblock.pl.gz. Usage is simple and as follows (again, note that it's one line):

[root@Azazel /home/jj]# ./create-sidblock.pl /usr/local/etc/snort/rules/ > /usr/local/etc/snort/sid-block.map
[root@Azazel /home/jj]# tail -n 3 /usr/local/etc/snort/sid-block.map
2500000: src[conn],30min;
2510000: src[conn],30min;
9999999: src[conn],30min;

I suggest that you not put ALL sids in this file, but rather take a subset from rules files that you know are bad news. To do this simply copy the .rules files into a directory of your choice and run the script against that directory (note that the sid-block.map must always live in /usr/local/etc/snort at this time). Other suggestions include daemonizing your barnyard instance (-D) rather than -vvv. The rest you can figure out.

The next part of this series will cover adding content filtration and a transparent squid instance into the mix on this box.

Cheers,
JJC