Non-Standard Sguil Configurations

Sguil Sensor and Full Content on Separate Servers

• Note: THIS IS NOT TESTED, IT IS THEORETICAL--PLEASE NOTIFY ME IF YOU TRY IT.

Prerequisites

• You must have both machines available and with the OS and all related software installed.
• You must already have a basic understanding of Sguil-related process and terminology.
• The sensor itself must have (2) Network Interface Cards (preferably ethernet).
• The collection device must have an adequate amount of drive space.
• Both machines preferably should have at least 1Gb ethernet interface.
• A crossover cable.
• A monitor port / tap / other means of effectively monitoring traffic.
• Network filesystem knowledge and a willingness to actually use one.

Assumptions

• In this example, our sensor agent has the following configuration:

 Hostname: sensor
 CPU: P4/2.4ghz
 RAM: 512MB
 HDD: 40GB
 NICs: 1*Intel EtherExpress Pro 10/100 (fxp), 1*Intel GigE (em)

• Our collector of full content dumps has the following configuration:

 Hostname: collector
 CPU: Xeon 3.2ghz
 RAM: 2GB
 HDD: 4*250GB in software RAID0 (using geom, vinum, whatever works for you.)
 NICs: 1*Intel GigE (em)

• Our tap/span port is connected to fxp0 on 'sensor'

• Our crossover cable exists between em0 on 'sensor' and em0 on 'collector'

Setup

• Make sure your sensor is setup as one normally would, with two exceptions:

1. You will not be running log_packets.sh on it
2. Your /nsm/sensor/dailylogs will be an NFS (or other..) mount to the collector.

• The collector needs only do a few very simple things:

1. Accept NFS mount requests (with write permissions) from sensor
2. Run the log_packets.sh script to handle snort and the full content data

• Note that you should do the research on a proper BPF expression to not log all of your NFS traffic over the link. That would suck.

• Once you have your sensor and collector installed, cabled, and ready, its time to bridge them.

Bridging

• First, assign a valid IP address to fxp0 on your sensor, but LEAVE 'em0' ALONE FOR NOW.
• Assign a valid IP to em0 on your collector, pretend they're both cabled to the switch.
• On the sensor, do this:

 # kldload if_bridge
 # ifconfig em0 up
 # ifconfig bridge0 create
 # ifconfig bridge0 addm em0 addm fxp0 up
 # sysctl -w net.inet.ip.forwarding=1

• Now, from another machine entirely, attempt to ping the collector. If all is well with the bridge, it should work fine.
• You can go to work setting up firewall rules for this configuration to deny certain traffic to the collector (for instance if you run a 40GB backup job overnight that you don't want to pcap); feel free to use ipfilter or pf or ipfw or whatever makes you most comfortable.
• For firewalling purposes, here is how the flow works on 'sensor':

 fxp0:
   in: from LAN to sensor
   out: from sensor to LAN

 em0:
   in: from collector to sensor/LAN
   out: from sensor/LAN to collector

• On the 'collector', firewalling is normal and shouldn't be necessary.

• If this is a permanent configuration, you may wish to do the following:

1. Add this to /etc/rc.conf:

 gateway_enable="YES"
 ifconfig_fxp0="inet N.N.N.N netmask 0xffffff00"
 ifconfig_em0="up"
 ipfilter_enable="YES"
 ipfilter_rules="/etc/ipf.conf"
 ipmon_enable="YES"

1. Add this to /etc/rc.local:

 if [ -f /etc/bridge.up ]; then
       ### BUILD THE BRIDGE!
       /sbin/ifconfig bridge0 create
       /sbin/ifconfig bridge0 addm em0 addm fxp0 up

       ### Reload firewall ruleset.
       /etc/rc.d/ipfilter restart
 fi

• Remember, you don't have to use ipfilter, but I do and this is my example.
• Now simply 'touch /etc/bridge.up' as an appropriately privileged user and reboot the sensor to test the configuration. If you ever need to bring it up without the bridge, just 'rm /etc/bridge.up' and it won't happen.

• Have fun, get creative.. post feedback maybe?