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:
- Snort 2.8.1 (see above)
- barnyard 0.20.0 (with a modified snortsam plugin)
- snortsam 2.52
- 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)
[jj@Azazel /usr/home/jj]$ wget http://www.snort.org/dl/barnyard/barnyard-0.2.0.tar.gzNow 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.
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
[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.
[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: 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: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader-2.61: [Define if a function `main' is needed.])
autoheader-2.61: WARNING: More sophisticated templates can also be produced, see the
autoheader-2.61: WARNING: documentation.
[jj@Azazel /usr/home/jj]$ wget http://www.redsphereglobal.com/data/tools/security/patches/barnyard-snortsam-hack.gzThis 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.
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.
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$./configure --enable-mysqlYour barnyard is now ready and we will cover the config file and startup after we get ipf and snortsam up and running.
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$sudo make install
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 kernelOnce these have been added please build your kernel, install and reboot. At this point we are ready to fetch and make snortsam.
options IPFIREWALL_FORWARD #Enable the Ip Forwarding function of IPFW
options IPDIVERT #allow this host to divert packets to/through different ints and routes
# IPF Support - default is to accept
[jj@Azazel /usr/home/jj]$ wget http://www.snortsam.net/files/snortsam/snortsam-src-2.52.tar.gzThat'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.
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
[jj@Azazel /usr/home/jj]$ cd snortsam
[jj@Azazel /usr/home/jj/snortsam]$ sh ./makesnortsam.sh
Building SnortSam (release)
Building SnortSam (debug)
[jj@Azazel /usr/home/jj/snortsam]$sudo cp snortsam* /usr/local/bin/
defaultkey secretsThis 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.
keyinterval 30 minutes
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/secretsThe 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 -> 188.8.131.52 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-debugStart 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 -vvvAfter starting barnyard you should see the following debug output from your snortsam-debug:
Debug: Connection from: 192.168.1.7.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 184.108.40.206 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:
Debug: Received Packet: CHECKIN
Debug: Snort SeqNo: cbb9
Debug: Mgmt SeqNo : 7000
Debug: Status : 1
Debug: Version : 14
Blocking host 192.168.1.43 in connection 192.168.1.43->220.127.116.11:0 (icmp) for 60 seconds (Sig_ID: 9999999).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 18.104.22.168 for 60 seconds), this is a function of the [conn] option in the sid-block.map file.
Debug: [ipf] Plugin Blocking...
Debug: [ipf] command /bin/echo "@1 block in log level local7.info quick on bge0 proto 1 from 192.168.1.43/32 to 22.214.171.124/32"|/sbin/ipf -f -
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.mapI 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.
[root@Azazel /home/jj]# tail -n 3 /usr/local/etc/snort/sid-block.map
The next part of this series will cover adding content filtration and a transparent squid instance into the mix on this box.