Thread: Snort IPS IPFW
View Single Post
Old 16th April 2017
JVWilliams JVWilliams is offline
New User
 
Join Date: Apr 2017
Posts: 4
Default

Sorry to dredge up an old thread, but as I've had some success with this, and haven't seen anything newer, I thought I'd post some information for anyone who needs it.

As noted above, pf can redirect packets from kernel space to user space using divert packets, like the following (on a box placed between the world and the gateway machine):

Code:
WAN_IF=em0
LAN_IF=em1
LON_IF=lo0

# the gateway WAN address
GATEWAY="192.168.1.2" 

set skip on $LON_IF
set skip on $LAN_IF

block in all
block out all

# Allow IPS to communicate with the world for Snort rule updates, etc.
pass out on $WAN_IF from ($WAN_IF) to any

pass on $WAN_IF from $GATEWAY to any binat-to ($WAN_IF:0) divert-packet port 700
This makes no attempt to do any significant firewall filtering, as the two pass statements should cover just about everything. Obviously, other firewall filtering could be added.

The key is the "divert-packet" statement (NOT "divert-to" or "divert-reply"), which redirects all packets passing through the IPS to divert socket 700. Without anything listening on that socket and re-injecting the packets, nothing should pass through.

On the Snort side, the use of the "ipfw" Snort data acquisition, or daq, module (unfortunately named; I think this has led to some confusion) is essential. On other platforms, Snort can use the "afpacket" daq for inline (IPS) service, but this isn't available on OpenBSD at this point.

Within the "snort.conf" file, Snort can be configured to make use of divert sockets and run inline as follows:

Code:
config policy_mode: inline
config daq_dir: /usr/local/lib/daq/
config daq: ipfw
config daq_mode: inline
config daq_var: port=700
And for inline duty, snort itself is run as follows:
Code:
/usr/local/bin/snort -D -c /etc/snort/snort.conf -Q -u _snort -g _snort -t /var/snort -l /var/snort/log
The "-Q" switch tells Snort, combined with the "config policy_mode: inline" setting, to drop packets when a "drop" rule is matched (see: http://manual-snort-org.s3-website-u...00000000000000 )

This ISN'T a comprehensive description of snort configuration or rule generation. I use pulledpork.pl run via cron on a daily basis to generate a unified "snort.rules" file and download/keep rules up to date, to choose the "ips_policy" level (which selects the rules enabled for IPS duty), and to modify rules from "alert" to "drop" with pulledpork's "dropsid" functionality. And I'm still experimenting with Snort configurations for improving performance.

But that's basically it.

As for why anyone would do this:
Firewalls are basically whitelisting devices. They allow certain traffic through if the source/destination addresses and ports are right, and packets themselves aren't malformed (of course, they're also useful for rate limiting and traffic shaping, etc.). However, firewalls can't detect whether the content of traffic sent to/from correct addresses and ports is nonetheless malicious. That's where signature-based deep-packet inspection and blacklisting can add additional protection.

A few notes:
  1. This only works on routing firewall configurations. Divert sockets don't seem to work on interfaces configured as part of a transparent (bridging) firewall.
  2. Compiling the Snort and Daq code from Snort.org will not function on OpenBSD for IPS duty. A few years back, Lawrence Teo noticed that the ipfw daq module was handling the creation of divert sockets incorrectly due to a permissions issue (basically, running Snort as root was required, making the standard practice of running it under the "_Snort" user nonfunctional). Only the versions of Snort in the ports/OpenBSD package repositories work correctly, as they include Teo's patch. In other words: just use pkg_add snort to get a working version (daq is a dependency).
  3. Snort is single-threaded. While the divert sockets function is fast, with signature-based detection as Snort does it there are real throughput limits, dependent on the size of the Snort ruleset.
  4. Snort itself does, of course, add an additional attack surface for bad actors to go after. Snort has a pretty good record on this (not a lot of vulnerabilities uncovered since the project started 20 years ago, despite a whole lot of IPS duty) and the authors are responsive to bugs. But running Snort chrooted with the "-t" switch, and under the non-administrator account "_Snort", is a wise idea. If the Snort process fails, note that the configuration above will "fail open" (all traffic not originating on the Snort box will cease).

Last edited by JVWilliams; 19th April 2017 at 04:32 PM.
Reply With Quote