Non-Standard Sguil Configurations

From WTFwiki
Jump to navigation Jump to search

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?