Monday, November 4, 2013

Suricata on CentOS 6

This post will cover building and installing the Suricata IDS on CentOS 6.4.  This procedure is adapted from the following documentation from openinfosecfoundation.org:

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/CentOS_56_Installation
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Basic_Setup

The following procedure assumes at least a minimal CentOS 6.4 installation with the base package group installed.

Not all of the prerequisite packages for building suricata are included in the CentOS repositories, so the EPEL package repository will fill in the gaps.

Add the EPEL repo to your system if you haven't already:

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
Start by installing the prerequisite packages: (may take some time depending on your system and internet connection)

# yum install gcc gcc-c++ make automake autoconf libtool pcre pcre-devel libyaml libyaml-devel libpcap libpcap-devel file-libs file-devel libpcap libpcap-devel zlib zlib-devel libnet libnet-devel libcap-ng libcap-ng-devel
I've chosen to install gcc and autotools individually rather than install the Development Tools package group.  I think it's a good practice to limit unnecessary software on internet-accessible systems or systems with security-related roles, so I don't want a lot of the packages that come in the Development Tools group.  In fact, if you're really serious about security you would probably want to compile suricata on a development machine and leave gcc and autotools off of your production systems altogether.

Download and extract the suricata source tarball from openinfosecfoundation.org:

# wget http://www.openinfosecfoundation.org/download/suricata-1.4.6.tar.gz # tar -xzf suricata-1.4.6.tar.gz
Now build and install suricata:
# cd suricata-1.4.6 # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # make # make install-full
I've chosen the install-full target for installation, because this will create directories and install some rules and configuration files for us.

Now that suricata is built and installed we can go about configuring it and installing some support scripts.  I'm using oinkmaster set up to take care of updating the rules on my system.  Download the oinkmaster tarball from http://oinkmaster.sourceforge.net/download.shtml.  (I don't want to post a direct link because I'd have to choose a mirror for you, and I'd rather not)

Extract the files and install oinkmaster.conf and oinkmaster.pl on your system.
# tar -xzf oinkmaster-2.0.tar.gz # cd oinkmaster-2.0 # cp oinkmaster.pl /usr/bin # cp oinkmaster.conf /etc
Edit /etc/oinkmaster.conf and correct the url:
url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
We can now test oinkmaster:
# oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules
If all went well you should have a whole bunch of *.rules files in /etc/suricata/rules.  You probably want oinkmaster to update your IDS rules automatically, so something like the following in your crontab will do the trick.  For more information see: http://oinkmaster.sourceforge.net/readme.shtml.

30 2 * * * oinkmaster.pl -C /etc/oinkmaster.conf -o /etc/suricata/rules 2>&1 | logger -t oinkmaster
In order to make suricata process these rules we'll have to update its configuration.  First get a list of all the rules in /etc/suricata/rules with something like:
# ls /etc/suricata/rules/*.rules
We need to make sure all these rule files are listed in the suricata configuration, so open up /etc/suricata/suricata.yaml and check the rule-files section against the list of rule files.

The rule-files section in my suricata.yaml looks like this:

rule-files: - botcc.rules - ciarmy.rules - compromised.rules - decoder-events.rules - drop.rules - dshield.rules - emerging-activex.rules - emerging-attack_response.rules - emerging-chat.rules - emerging-current_events.rules - emerging-deleted.rules - emerging-dns.rules - emerging-dos.rules - emerging-exploit.rules - emerging-ftp.rules - emerging-games.rules - emerging-icmp_info.rules - emerging-icmp.rules - emerging-imap.rules - emerging-inappropriate.rules - emerging-info.rules - emerging-malware.rules - emerging-misc.rules - emerging-mobile_malware.rules - emerging-netbios.rules - emerging-p2p.rules - emerging-policy.rules - emerging-pop3.rules - emerging-rpc.rules - emerging-scada.rules - emerging-scan.rules - emerging-shellcode.rules - emerging-smtp.rules - emerging-snmp.rules - emerging-sql.rules - emerging-telnet.rules - emerging-tftp.rules - emerging-trojan.rules - emerging-user_agents.rules - emerging-voip.rules - emerging-web_client.rules - emerging-web_server.rules - emerging-web_specific_apps.rules - emerging-worm.rules - files.rules - http-events.rules - rbn-malvertisers.rules - rbn.rules - smtp-events.rules - stream-events.rules - tls-events.rules - tor.rules While we're editing suricata.yaml, the classification-file and reference-config-file fields also need to be updated:

classification-file: /etc/suricata/rules/classification.config reference-config-file: /etc/suricata/rules/reference.config

At this point, suricata is configured and can be tested with the following command:

# suricata -c /etc/suricata/suricata.yaml -i eth0

For a real IDS setup, we also need an init script for suricata, but I'm going to cover that in a follow up post.

Hope this has been helpful, thanks for reading!


Friday, June 22, 2012

efw-upgrade behind a proxy

The efw-upgrade command will fail for an EFW living on a network that requires use of an HTTP proxy.  To make it work efw-upgrade needs to be configured to use the proxy to download updates and repo data, but there doesn't appear to be any official documentation on how to do this.  EFW uses the Smart Package Manager, and luckily there's good documentation for smart. 

To make efw-upgrade work, use SSH or the console of the EFW to log in as root then run this command:

smart config --set http-proxy=proxyurl

My proxy url looks something like: http://a.b.c.d:8080

Monday, April 2, 2012

libtool version mismatch

Building ec2new on CentOS 6.2, I came across the following error:

libtool: Version mismatch error.  This is libtool 2.4, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6b.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4
libtool: and run autoconf again.

I found references to LT_INIT in ltmain.sh, so I deleted it and ran libtoolize.  After that the build process suggested in INSTALL worked fine.

Saturday, March 31, 2012

WPAD with EFW

My home router is running Endian Firewall Community edition v2.5.1, and I wanted to configure it to support WPAD using DHCP option 252.  The answer is simple but a little harder to find than I expected, so here it is.

Add the following into the "Custom configuration lines" text box on the DHCP Server configuration page in the EFW web-management console, substituting a.b.c.d for the IP Address of your EFW router:

option wpad code 252 = text;
option wpad "http://a.b.c.d/wpad.dat";

In the first line you're telling your DHCP server that option 252 is going to be an ASCII text string with the name wpad.  In the second line you're assigning a string to that option so the server can give it out to clients.  What you're doing here is giving your DHCP clients the URL for a Proxy Auto-Config file, that will tell them the location of the proxy server and possibly some other options.  If you want to check out the PAC file that EFW creates for you, open up that wpad.dat file from your router and take a look at it.

Option 252 is still only a draft, but it's used commonly enough that many DHCP clients and servers implement it.