Sunday, April 13, 2008

"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

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

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]$ ./ warning: underquoted definition of SN_CHECK_DECL run info '(automake)Extending aclocal' or see
autoheader-2.61: WARNING: Using auxiliary files such as `acconfig.h', `'
autoheader-2.61: WARNING: and `', to define templates for `'
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/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 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:
[jj@Azazel /usr/home/jj]$ wget

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]$
This patch or "hack" has assumed that the location of your is at /usr/local/etc/snort/ 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 IPDIVERT #allow this host to divert packets to/through different ints and routes

# IPF Support - default is to accept
options IPFILTER
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

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 ./
Building SnortSam (release)
Building SnortSam (debug)
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
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 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:
The barnyard snortsam plugin uses a 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/ 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 -> 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/ -s /usr/local/etc/snort/ -d /var/log/snort/ -f snort.alert -w /var/log/snort/barnyard-snortsam.waldo -p /usr/local/etc/snort/classification.config -X /var/ -vvv
After starting barnyard you should see the following debug output from your snortsam-debug:
Debug: Connection from:
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 "" and ping 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 in connection> (icmp) for 60 seconds (Sig_ID: 9999999).
Debug: [ipf][28201600] Plugin Blocking...
Debug: [ipf][28201600] command /bin/echo "@1 block in log level quick on bge0 proto 1 from to"|/sbin/ipf -f -
We can see from the output that it is blocking the source address of and proto 1 (ICMP) only. This means that this host can still browse the internet and do everything (other than send icmp to for 60 seconds), this is a function of the [conn] option in the 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 file. I have modified the file to create a 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 Usage is simple and as follows (again, note that it's one line):
[root@Azazel /home/jj]# ./ /usr/local/etc/snort/rules/ > /usr/local/etc/snort/
[root@Azazel /home/jj]# tail -n 3 /usr/local/etc/snort/
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 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.


Tuesday, April 1, 2008

Cisco Acquires Sguil!

In many of my past writings I have mentioned using Sguil and have been an avid user of the solution. On that front, I would like to extend my congratulations to the core members of the team for their great success! It will be exciting to see it running on IOS!

Cisco Announces Agreement to Acquire Sguil™ Open Source Security Monitoring Project

Acquisition Furthers Cisco’s Vision for Integrated Security Products

SAN JOSE, Calif., and LONGMONT, Color., April 1st, 2008 – Cisco and the Sguil™ project today announced an agreement for Cisco to acquire the Sguil™ project, a leading Open Source network security solution. With hundreds of installations world-wide, Sguil™ is the de facto reference implementation for the Network Security Monitoring (NSM) model. Sguil™-based NSM will enable Cisco’s customer base to more efficiently collect and analyze security-related information as it traverses their enterprise networks. This acquisition will help Cisco to cement its reputation as a leader in the Open Source movement while at the same time furthering its long-held vision of integrating security into the network infrastructure.

Under terms of the transaction, Cisco has acquired the Sguil™ project and related trademarks, as well as the copyrights held by the five principal members of the Sguil™ team, including project founder Robert "Bamm" Visscher. Cisco will assume control of the open source Sguil™ project including the domain, web site and web site content and the Sguil™ Sourceforge project page. In addition, the Sguil™ team will remain dedicated to the project as Cisco employees, continuing their management of the project on a day-to-day basis.

To date, Sguil™ has been developed primarily in the Tcl scripting language, support for which is already present inside many of Cisco’s routers and switches. The new product, to be known as “Cisco Embedded Monitoring Solution (CEMS)”, will be made available first in Cisco’s carrier-grade products in 3Q08, with support being phased into the rest of the Cisco product line by 4Q09. Linksys-branded device will follow thereafter, though the exact deployment schedule has yet to be announced.

“We’re extremely pleased to announce this deal,” said Cisco’s Chief Security Product Manager Cletus F. Simmons. “For some time, our customers have told us that our existing security monitoring products did not extend far enough into their network infrastructure layer. Not only was it sometimes difficult to intercept and monitor the traffic, but there were often political problems at the customer site with deploying our Intrusion Detection Systems, as management had heard several years ago that they ere ‘dead’. Now, with Sguil™ integrated into all their network devices, they’ll have no choice!”

Although the financial details of the agreement have not been announced, Sguil™ developer Robert Visscher will become the new VP of Cisco Rapid Analysis Products for Security. “This deal means a lot to the Sguil™ project and to me personally,” Visscher explains. “Previously, we had to be content with simply being the best technical solution to enable intrusion analysts to collect and analyze large amounts of data in an extraordinarily efficient manner. But now, we’ll have the additional advantage of the world’s largest manufacturer of networking gear shoving it down their customers’ throats! We will no longer have to concern ourselves with mere technical excellence. Instead, I can worry more about which tropical island to visit next, and which flavor daiquiri to order. You know, the important things.”

About Cisco Systems

Cisco, (NASDAQ: CSCO), is the worldwide leader in networking that transforms how people connect, communicate and collaborate. Information about Cisco can be found at For ongoing news, please go to

About Sguil™

Sguil™ is the leading Network Security Monitoring (NSM) framework. It is built for network security analysts by network security analysts. Sguil’s main component is an intuitive GUI that provides access to a wide variety of security related information, including real-time IDS alerts, network session database and full packet captures. Sguil™ was written by Robert “Bamm” Visscher, who was apparently too cheap to buy a book on Java or C.

Again, congrats to the team... if you get a chance, please stop in at #snort-gui on freenode and say hi / congratulate the team.