DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default Snort IPS IPFW

Hello to all,

Anyone here had successfully deploy a fully functional Snort IPS using IPFW on OpenBSD?

Please share some thought. Thanks.
Reply With Quote
  #2   (View Single Post)  
Old 8th September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

This is not possible. IPFW requires FreeBSD or Linux.
Reply With Quote
  #3   (View Single Post)  
Old 9th September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default

IPFW has similar functionality in terms of divert packet. I though this can achieve on OpenBSD pf packet filter too.

What are the other method (daq) to deploy a fully functional Snort IPS on OpenBSD?

AFAIK, all daq are applicable to Linux netfilter and FreeBSD IPFW only.
Reply With Quote
  #4   (View Single Post)  
Old 9th September 2015
sacerdos_daemonis's Avatar
sacerdos_daemonis sacerdos_daemonis is offline
Real Name: Will forever be a secret.
Spam Deminer
 
Join Date: Sep 2014
Posts: 283
Default

Quote:
What are the other method (daq) to deploy a fully functional Snort IPS on OpenBSD?
If this is true:
Quote:
Originally Posted by jggimi View Post
This is not possible. IPFW requires FreeBSD or Linux.
What would be the "other" methods? Not possible means there is no first method. You appear to be asking the same question twice.

How can this be done?
It is not possible.
But how can I do it?


EDIT
I am assuming "fully functional Snort IPS" means including IPFW.
Reply With Quote
  #5   (View Single Post)  
Old 9th September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

OpenBSD does not have IPFW, and there are no plans to add IPFW.

However, a skilled administrator can use Snort in inline mode, using pf(4) and divert(4).

http://marc.info/?t=137004380800001&r=1&w=2
Reply With Quote
  #6   (View Single Post)  
Old 9th September 2015
denta denta is offline
Shell Scout
 
Join Date: Nov 2009
Location: Sweden
Posts: 95
Default

Out of curiosity, what services are you running that shall be "protected" with this snort installation?
Reply With Quote
  #7   (View Single Post)  
Old 13th September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default

Quote:
Originally Posted by denta View Post
Out of curiosity, what services are you running that shall be "protected" with this snort installation?
General protection. I don't have any web server, database server not ftp or sshd.
Reply With Quote
  #8   (View Single Post)  
Old 13th September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default

Quote:
Originally Posted by jggimi View Post
OpenBSD does not have IPFW, and there are no plans to add IPFW.

However, a skilled administrator can use Snort in inline mode, using pf(4) and divert(4).

http://marc.info/?t=137004380800001&r=1&w=2
Any concrete examples or explanation would be good?
Reply With Quote
  #9   (View Single Post)  
Old 13th September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

The Email chain referenced included an example to test functionality, using ICMP traffic initiated from a test system.
Reply With Quote
Old 13th September 2015
denta denta is offline
Shell Scout
 
Join Date: Nov 2009
Location: Sweden
Posts: 95
Default

Quote:
Originally Posted by Peter_APIIT View Post
General protection. I don't have any web server, database server not ftp or sshd.
So basically, it sounds like the packets that would trigger snort alerts would have been blocked by pf anyway. Perhaps an alternative is the pf overload <table> statement, which allows you to automatically block certain IP:s, without the added effort and security risks of running snort on your external interface(s).
Reply With Quote
Old 14th September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default

Quote:
Originally Posted by denta View Post
Perhaps an alternative is the pf overload <table> statement, which allows you to automatically block certain IP:s, without the added effort and security risks of running snort on your external interface(s).
Any concrete examples?
How to fill out the table with list of blocked ips?
My current pf block syntax is:
block drop log

By the way, this is my pf block log.
Quote:
Sep 14 20:52:56.301290 rule 4/(match) block in on pppoe0: 108.168.174.5.443 > 60.53.42.92.36431: FP 0:31(31) ack 1 win 514 <nop,nop,timestamp 2051785347 10995349> (DF)

Sep 14 20:53:33.017906 rule 4/(match) block in on pppoe0: 1.9.56.40.80 > 60.53.42.92.51352: F 2616242450:2616242450(0) ack 4124174253 win 494 (DF)
Sep 14 20:53:33.305442 rule 4/(match) block in on pppoe0: 1.9.56.40.80 > 60.53.42.92.51352: F 0:0(0) ack 1 win 494 (DF)
Sep 14 20:53:33.615651 rule 4/(match) block in on pppoe0: 1.9.56.40.80 > 60.53.42.92.51352: F 0:0(0) ack 1 win 494 (DF)
Sep 14 20:53:34.234846 rule 4/(match) block in on pppoe0: 1.9.56.40.80 > 60.53.42.92.51352: F 0:0(0) ack 1 win 494 (DF)
Quote:
The Email chain referenced included an example to test functionality, using ICMP traffic initiated from a test system.
The email chain from Lawrence showing there is pf inbound packet using pass in syntax but i don't have any pass in traffic to serve in my environment. I just want to check for every packet of outbound to the equivalent inbound packet for virus scanning and etc.

EDIT:
Layer 7 protocol inspection
policy filtering (or packet marking), TCP flag state filtering,

Thanks.

Last edited by Peter_APIIT; 14th September 2015 at 01:40 PM.
Reply With Quote
Old 14th September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Quote:
Originally Posted by Peter_APIIT View Post
Any concrete examples?
The PF User's Guide, Sir. The PF User's Guide. See the Stateful Tracking Options in the Packet Filtering chapter.
Reply With Quote
Old 14th September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Quote:
Originally Posted by Peter_APIIT View Post
By the way, this is my pf block log.
These are blocks of valid ACK packets. This was discussed in one of your other threads last week. Perhaps you missed the discussion, Peter?

If so, start reading HERE:

http://daemonforums.org/showthread.php?t=9350#post56318
Reply With Quote
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
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Snort Install from Source no configuration Peter_APIIT OpenBSD Packages and Ports 2 18th August 2015 07:02 AM
Snort Daemon not running Peter_APIIT OpenBSD Packages and Ports 7 30th June 2015 12:32 PM
Snort 2.9.1 improves protocol handling J65nko News 0 30th August 2011 12:26 AM
PF + SNORT on one machine WeakSauceIII OpenBSD Security 5 30th July 2009 09:02 AM
snort install error ijk FreeBSD Installation and Upgrading 1 11th August 2008 10:53 AM


All times are GMT. The time now is 09:10 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick