Talk:Sguil on RedHat HOWTO

From NSMWiki
Jump to: navigation, search

Note re this page

I've taken the liberty of completely re-organizing this page. I realize that screws up the chronology, but I hope it is helpful, as this discussion was getting quite lengthy. --Barrygould 07:39, 9 July 2008 (UTC)

Misc

"dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so" and similar lines in snort.conf should be edited to /usr/local/snort/lib/<whatever> --Bianco 11:09, 11 September 2007 (PDT)

Need to add a bit about the InstantNSM pads+vlan.patch to the appendix on vlan tags. --Bianco 13:23, 11 September 2007 (PDT)

Consider moving the "What the heck are all these processes, anyway?" section earlier in the document. --Bianco 08:08, 12 September 2007 (PDT)

Missing logging to unified configuration for snort.conf --Rfifarek 13:50, 19 December 2007 (PST)

  • I've added some more detail about this below in "Barnyard / Snort Config Fix". --Barrygould 07:39, 9 July 2008 (UTC)


Updated versions of programs

p0f-2.0.6 is available from rpmforge. --Mgrinnell 22:35, 28 December 2007 (PST)

tcpflow-0.21 is available from rpmforge. --Mgrinnell 22:35, 28 December 2007 (PST)

CentOS 4 (and I assume RedHat) complains about the - in ps -auxw in all of the startup scripts. Mgrinnell 14:03, 16 January 2008 (PST)

It might be best to modify the mysqltcl build instructions to avoid using the mysql-devel RPM entirely, and build against the version of MySQL that was compiled from source in this HOWTO. --Bianco 11:25, 10 September 2007 (PDT)

FYIs, I'd to mention that the MySQL community RPMs work fine, and make things a bit easier. You need MySQL-client, MySQL-server, probably MySQL-shared, and you need MySQL-devel to compile mysqltcl. I'm sure the Centos and RedHat 5 ones are OK too, but on RHEL4 they're pretty old (4.1, iirc) --Barrygould 07:59, 2 July 2008 (UTC)

mysql-5.0.54 is available from the CentOSWebStack. --Mgrinnell 22:38, 28 December 2007 (PST)


Startup script fixes

http://nsmwiki.org/Sguil_on_RedHat_HOWTO#Sguil_Startup_Scripts is very unclear; I'm guessing "sample startup file directory" is referring to instantnsm-20080613/startup_files/rhel --Barrygould 08:39, 2 July 2008 (UTC)

There seems to be an error in the pads init script, line 42 or so:

   chown -R  sguil.sguil $NSMDIR/snort_data/$SENSOR/pads.fifo

The "snort_data" shouldn't be there as $NSMDATA is supposed to already contain that.

Also, the pads_agent script doesn't 'stop' correctly:

# service pads_agent-border stop
Shutting down pads_agent-border: kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec]
# ps auxw|grep pads
sguil    26221  0.0  0.0 49908  408 pts/1    S    01:43   0:00 cat /nsm/snort_data/border/pads.fifo

Also, snort (2.8.2.1) won't start unless I create these links:

ln -s /usr/local/snort/lib/snort_dynamicengine  /usr/local/lib/snort_dynamicengine
ln -s /usr/local/snort/lib/snort_dynamicpreprocessor /usr/local/lib/snort_dynamicpreprocessor

--Barrygould 08:58, 5 July 2008 (UTC)

Something is wrong with the init scripts:

Jul  5 02:07:00 nsm runuser: ERROR: Directory /var/run does not exists or is not writable.
Jul  5 02:07:00 nsm runuser: Process ID will not be written to file.

I believe this is coming from an incorrect setting in the sguil_logger init script:

PIDFILE=/var/run/snort_log-$SENSOR.pid

which should be

PIDFILE=/var/run/sguil/snort_log-$SENSOR.pid

It's also happening for pads_agent:

# service pads_agent-border start
Starting pads_agent-border:                                [  OK  ]
# tail /var/log/messages
Jul  5 02:45:15 nsm SGUILD: Sensor agent connect from xxx:48082 sock15
Jul  5 02:45:15 nsm SGUILD: Validating sensor access: xxx : 
Jul  5 02:45:15 nsm SGUILD: Valid sensor agent: xxx
Jul  5 02:45:15 nsm pads_agent-border: pads_agent.tcl startup succeeded
Jul  5 02:47:34 nsm runuser: ERROR: Directory /var/run does not exists or is not writable.
Jul  5 02:47:34 nsm runuser: Process ID will not be written to file.
Jul  5 02:47:34 nsm pads_agent-border: pads_agent.tcl startup succeeded
Jul  5 02:47:34 nsm SGUILD: Sensor agent connect from xxx:48100 sock15
Jul  5 02:47:34 nsm SGUILD: Validating sensor access: xxx : 
Jul  5 02:47:34 nsm SGUILD: Valid sensor agent: xxx

I can't figure out why this is occurring; I have /etc/sguil/pads-border.conf configured with pid_file /var/run/sguil/pads-border. Changing permissions on /var/run/sguil doesn't make a difference. Changing permissions on /var/run gets rid of the error, but no PID file appears!

Update (Jul 8, 2007): I've now changed most of the configs so that they use /var/run/sguil; some of them were still using /var/run, hence the errors above. I couldn't find a setting for one of the snort configs, so I've still got a snort_eth1.pid and snort_eth1.pid.lck in /var/run, but it's working.

Also, the stop commands for the snort_agent and snort init scripts don't show the OK message, and snort is definitely not killed. --Barrygould 09:22, 5 July 2008 (UTC)


Barnyard / Snort Config Fix

Barnyard gets errors reading the snort outputs. Fixed by following http://nsmwiki.org/Sguil_FAQ#Barnyard_says_.22No_input_plugin_found.22.

i.e., the snort config needs to include:

output log_unified: filename snort.unified, limit 128

--Barrygould 09:42, 5 July 2008 (UTC)


PADS

PADS patch is missing from instantnsm-20060110 distribution. You need to fetch instantnsm from cvs. --Mgrinnell 22:35, 28 December 2007 (PST)

  • I'm confused; it looks like the link to PADS is a customized one (http://demo.sguil.net/downloads/pads-1.2-sguil-mods.tar.gz); Howto says "You must use the version with the built-in Sguil modifications." Does it still need to be patched on top of that? looks like the patch is now at http://www.vorant.com/files/pads.patch; it seems to patch in OK. ISTM the one on demo.sguil.net should have the patch applied... is there a licensing problem? --Barrygould 07:56, 2 July 2008 (UTC)
  • This actually isn't as difficult as it sounds. PADS needs a patch just to be able to work with sguil, and these are the patches at demo.sguil.net. These are required for all platforms you want to run PADS + sguil on, as they change the output format of the FIFO to be what Sguil expects. The other set of patches (from vorant.com) is only for Linux (specifically, RHEL/CentOS, but maybe others as well). They fix bugs that keep it from working properly. So if you're running Sguil on Linux, you need to apply both sets of patches. If you're running Sguil on non-Linux, you probably only need the sguil.net patches. Hope this is more clear. Bianco 19:31, 8 July 2008 (UTC)


SANCP

SANCP make command seems to be "make linux" now. Tested on sancp-1.6.1-stable. --Mgrinnell 22:35, 28 December 2007 (PST)

  • on RHEL4, x86-64, I had to ignore the instructions here and modify the Makefile as follows:
Makefile:
# LINUX and BSD CFLAGS (no changes)
CFLAGS = -O3 -I/usr/include/pcap -I/usr/local/include/pcap  -I./ -L/usr/lib/libsocket.so  -g -L/opt/csw/lib -ggdb

# LINUX  LFLAGS (change libpcap location)
LFLAGS = -lresolv -lnsl -lpcap -L/usr/local/libpcap/lib/libpcap-0.9.8.so

and then run 'make linux' --Barrygould 19:34, 3 July 2008 (UTC)


SELinux and MySQL

If you install MySQL without using the RedHat MySQL RPMs, and SELinux is Enforcing, you will need to do the following:

up2date -uv selinux-policy-targeted-sources

or

yum install selinux-policy-targeted-sources

and restart the mysqld service.

In recent versions (as of 5.0.46) of the RPMs from MySQL, instructions are printed to the screen after the installation, with similar information.

I was also seeing SELinux errors when "parsed.border.stats" data was trying to be loaded. This may have been a temporary issue, but I did take some more steps to try to resolve it...

There is a script called audit2allow which will write SELinux policy commands to 'fix' any denied actions in the logs.

audit2allow -i /var/log/messages -l

or

audit2allow -d -l

will read the messages log, or the kernel output from dmesg, respectively.

The output of this command would need to be added to the end of mysql policy, and reloaded, e.g.

emacs /etc/selinux/targeted/src/policy/domains/program/mysqld.te
cd /etc/selinux/targeted/src/policy/
make load

After all of that, I'm not getting any more parsed.border.stats data load errors.

--Barrygould 05:51, 9 July 2008 (UTC)


MySQL Privileges

Depending on your mysql configuration (if DNS is not used), it may be necessary to also grant privs to sguil@127.0.0.1. Either way, it won't hurt anything, and it's considered good practice. e.g.

mysql> GRANT ALL PRIVILEGES ON sguildb.* TO sguil@localhost IDENTIFIED BY "sguil_password";
mysql> GRANT ALL PRIVILEGES ON sguildb.* TO sguil@'127.0.0.1' IDENTIFIED BY "sguil_password";
mysql> GRANT FILE ON *.* to sguil@localhost;
mysql> update user set Password = OLD_PASSWORD("sguil_password") where User = "sguil";
mysql> FLUSH PRIVILEGES;

Naturally, if your database is on a different machine than the sguil server, then you'd need to grant for the name and IP of the sguil server.

Also, I'm not sure why the OLD_PASSWORD is used here... I believe that's only needed for very old clients and libraries. (mysql 4.0) I didn't do it, although I must admit I still don't have PADS working yet.

--Barrygould 05:52, 9 July 2008 (UTC)


Barnyard on 64-bit

Barnyard 0.2.0 needs to be patched or it will get errors when trying to read the snort files, if you run it on a 64-bit system.

Although there are at least 2 64-bit patches available on the web, the only one that worked for me is

http://www.snort.org/users/jbrvenik/Site/Code_files/barnyard.64bit.diff

(thanks to giovani on irc!)

So, the procedure to compile barnyard is:

download from http://www.snort.org/dl/barnyard/
download the 64-bit patch from http://www.snort.org/users/jbrvenik/Site/Code_files/barnyard.64bit.diff
both the tar and the patch should be in the same directory
# up2date tcl-devel
untar
# cd barnyard-0.2.0
# cp $SGUIL/sensor/barnyard_mods/op_sguil.* src/output-plugins
# cp $SGUIL/sensor/barnyard_mods/configure.in .
# cd src/output-plugins
# patch -p0 <  $SGUIL/sensor/barnyard_mods/op_plugbase.c.patch
# cd ../..
# cd ..   (to the directory with the patch)
# patch -p0 < barnyard.64bit.diff
# cd barnyard-0.2.0
# autoconf
#  ./configure --prefix=/usr/local/barnyard-0.2.0+sguil --enable-tcl --with-tcl=/usr/lib64 --enable-mysql --with-mysql-libraries=/usr/lib64 --with-mysql-includes=/usr/include/mysql
# make
# make install
# cp -r ./etc /usr/local/barnyard-0.2.0+sguil

Note I added the mysql libs to the configure statement. That may not be necessary. I had originally assume barnyard would be talking to the DB like it does with ACID/BASE, but it appears it actually talks to sguild. Anyways, it works for me.

--Barrygould 07:39, 9 July 2008 (UTC)


Other 64-bit issues

I had to add a link for tcltls to get sguil to work on RHEL4, x86-64: ln -s /usr/local/tcltls/lib/tls1.50/ /usr/lib--Barrygould 08:14, 2 July 2008 (UTC)

I also had trouble with mysqltcl3.05, so I went back to 3.03. The installation path's subdirectories were different in the newer one. Also, I had to configure mysqltcl with these parameters:

./configure --with-tcl=/usr/lib64 --with-tclinclude=/usr/include --with-mysql-lib=/usr/lib64 --prefix=/usr/local/mysqltcl-3.03 --exec-prefix=/usr/local/mysqltcl-3.03

--Barrygould 08:14, 2 July 2008 (UTC)--Barrygould 07:56, 2 July 2008 (UTC)


More recent versions of Snort

FYIs, I got setup with Snort 2.8.2.1. Sometime in the 2.7 series, they added a "unified2" output format, but "unified" is still there, and no config changes are necessary. Just don't set the output to "log_unified2" or barnyard 0.2.0 will reportedly choke.

--Barrygould 07:39, 9 July 2008 (UTC)