Building an IDS on RHEL 7 using Suricata

I was recently tasked with throwing up a replacement IDS box after an appliance 'died' in not-so-mysterious circumstances during some DC work. The IDS (Suricata) was stipulated, as was the base platform (RHEL 7).

 I wanted to share here some of the notes I made during the build and subsequent testing, some useful links as well as one 'gotcha' I encountered along the way. These might cause you headaches in keeping your IDS running.

 There are a ton of good articles already around covering how to get Suricata working on CentOS (RHEL's community backed spin off) but special mention has to go out to Daniel Miessler's guide which I've linked to below. In terms of getting Suricata up and running it really covers everything.


 That gotcha
You can provide Suricata with parameters around pcap file management if you're capturing full packet and writing it to disk. These parameters are the size limit for each pcap file and the number of files to retain. For example, you could configure your IDS to write (and retain) 100 x 100mb files, giving you 10Gb of full packet data to 'replay' at a later date or parse through some other tool etc.

 If you're tasked with retaining full packet data you need to be mindful of Bug #1117 which causes Suricata to 'forget' about the files when it's restarted. This is because Suricata doesn't track or manage the file count on disk (i.e. via a bookmark file) so when re-started it just starts the counter again. If you neglect this and enable full pcap retention you'll likely eat through your storage very quickly, considering you'll likely be restarting at least daily following rule updates.

 It's also worth noting that if you intend to use sguil and the supporting pcap format, Suricata performs a check to see if directories are empty before deleting them. If they're not, they get left with the contents in tact. Again, this has the potential to eat through your storage, fast.
Outputs
Suricata can throw out event data in a number of ways which can be customised to your environment. During testing, I was asked if I could replicate something akin to SDEE (Security Device Event Exchange). This turned out to be pretty easy to do using u2eve from the idstools set. You can use this tool then to essentially create a new json output, built from the unified2 log (you'll need to enable this) with the addition of the packet data rendered as a base64 string within the event:
# idstools-u2eve -C /etc/suricata/classification.config --prefix unified2.alert -S /etc/suricata/rules/sid-msg.map -G /etc/suricata/rules/gen-msg.map --follow --bookmark --delete --directory /ids-log-dir/ --stdout --output /ids-log-dir/sdee.json
You'll also need to sort out log rotation as there are no settings Suricata for this. Something like this should work for you:
# cat /etc/logrotate.d/suricata
/ids-log-dir/*.log /ids-log-dir/*.json
{
    daily
    rotate 7
    nocompress
    notifempty
    missingok
    postrotate
        /bin/kill -HUP $(cat /var/run/suricata.pid)
    endscript
}
Testing
Once your IDS is installed you'll want to spend some time making sure it works. Generating some *real* alerts can help you make sure your logging and monitoring piece further up the food chain is set-up correctly. You may have already come across testmyids.com, the site which when curl'd from a monitored network should cause your IDS to alert with "GPL ATTACK_RESPONSE id check returned root". Given the the seemingly never ending tide of exploit kits and malware we're up against I figured running some real world examples past the new IDS would make for a good test. 

You can replay PCAPs to Suricata like this:
# suricata -c /etc/suricata/suricata.yaml -r dirty-pcap-file.pcap 
Closing Remarks
I'll definitely be doing more with Suricata now and in the near future. Whether monitoring networks or monitoring on the host, the ability to drop and install an IDS capability in sub-thirty minutes is great one to possess. Alerting aside, the supported event types (i.e. HTTP, DNS, SSH, etc) are giving me ideas around enriched endpoint logging.

 Useful Links / Essential Reading 
The Practice of Network Security Monitoring - R. Bejtlich, 2013 (ISBN: 978-1-59327-509-9)
Building an IDS on CentOS using Suricata - Daniel Miessler
Suricata (and the grand slam of) Open Source IDPS - Peter Manev (QA Lead @ Suricata) 
Suricata - Basic Setup - Suricata Official Documentation 
FCoE Config (RHEL) - RHEL 7 Official Documentation 
Suricata
Community Rules - Emerging Threats 
Oinkmaster (Rule Management)
idstools - Python.org 
idstools documentation
Unifed2 - Snort
Sguil on RedHat HOWTO - nsmwiki.org (if you're adding a gui)
Malware PCAPs - malware-traffic-analysis.net
Malware PCAPs - broadanalysis.com 

Popular posts from this blog

Tools & Techniques - Cloud Firewalls (DigitalOcean)

Image
My home lab is (probably) typical of most security professionals: a beefy workstation running VMWare workstation, a beefy-ish workstation running ESXi and a bunch of laptops, switches and other devices.  I utilise a couple of VPS providers for hosting and exposing VMs to the cloud. My VPS provider of choice has been DigitalOcean for the last couple of years (going by my billing history) and to date, they've been excellent. They recently introduced and advertised a new service feature called 'Cloud Firewalls' and I had chance to have a play with them today. Essentially, they've incorporated a network level firewall service to their VPS offering which can be used as an alternative or in addition to host-based firewalls like iptables, firewalld, etc.  Initial Impressions - Pros, Cons and Limitations Pros No Cost (free!!) - Cloud Firewalls are available at no additional cost. Availability - Cloud Firewalls are available in ever region DigitalOcean operate.
Read more

PCI-DSS: Your CDE may be getting bigger

Image
In December, the PCI Security Standards Council released guidance around scoping and network segmentation for card data environment (CDE) assets. In their own words: “Many organizations struggle to understand where PCI DSS controls are required and which systems need to be protected. This document provides guidance to help organizations identify the systems that, at a minimum, need to be included in scope for PCI DSS. Additionally, the document provides guidance on how segmentation can be used to help reduce the number of systems that require PCI DSS controls.” The guidance goes on to visualise a scoping process, considering each category of system in turn: I believe it’s worth highlighting the ‘broadness’ of the “Connected to OR Security Impacting Systems” . These are cases where the: System component is on a different network (or subnet or VLAN), but can connect to or access the CDE (e.g., via internal network connectivity). System component can connect
Read more

WAR GAMES - Simulating Security Incidents

Image
Why it's a good idea There are a myriad of reasons to test in peace time, the controls and processes which collectively represent your incident readiness. These include: Validating your Incident Readiness - testing can confirm that you are as ready as you think you are, and that nothing has changed resulting in an end state which prevents you from initiating IR.  Assess Controls Coverage and Identify Gaps - testing can confirm your controls coverage is adequate as well as highlighting those gaps which you'd rather not have in the event of a real issue. Demonstrate value of investment - you've probably spent a lot of time and other people's money acquiring controls, attracting talent and preparing for the eventually of an incident. Internal stakeholders will likely already be looking for assurance that their investment has been worth while.  Demonstrate investment and commitment to interested parties - internal stakeholders considered, you'll lik
Read more