The return of the Linux router... (from pfSense to Debian, part 6: Suricata IDS)
Hi again mighty Planet!
Today I'm going to add yet another article on the series about Debian based Router/firewall systems (or how my weekends are truly weekends since I switched from GUI based routers back to plain old Linux/Debian routers where CISCO hardware is not an option)
This time I deal on how to use Suricata IDS/IPS software.
Since I used Suricata on pfSense, and I had every ELK monitoring system configured to ingest and analyze Suricata log events, I wanted to setup this on my beloved Debian, and, as expected... it was not really difficult... here are the very basic (far from a complete guide) steps to setup Suricata on a Debian system.
Installing
Well, fairly easy...
Note but that three different pieces of software packages are installed:
- Suricata itself, pretty obvious, the IDS process...
- Suricata-oinkmaster, this is the piece of software that allows us to setup snort based rules / signatures repositories for the IDS to use against inspected traffic.
- Snort-rules-default A set of default snort rules packaged for Debian.
So here we go:
apt-get install suricata suricata-oinkmaster snort-rules-default
Get Rules for your IDS
Here's how to setup Oinkmaster to use the emergingthreats free repository of rules.
There are other, paid, rule repositories, but well ... there's also CISCO Security appliances... so we stick to free and OpenSource...
We will need to edit the /etc/oinkmaster.conf configuration file.
Note that, as of Debian Stretch packaged configuration file, the emergingthreats URL is incorrect.
It points to the former name of emergingthreats project (Bleeding Snort project) so, anyhow, put the following line in the file instead of commenting out bad/old urls.
url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
Now we are ready to launch the oinkmaster command for the first time.
This tool will fetch/update available rules of the remote repository into a target directory.
Here I'll be pointing to Suricata /etc/suricata/rules folder on purpose, to get fresh rules for the IDS process.
It is very convenient to add the following command to the cronjob, so the rules are periodically checked and updated.
Here we go:
oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules
You'll see the progress of fetching and downloading rules.
The process is entirely shown on output, so it is somehow long... at the end, you get something similar to:
...
-> gen-msg.map
-> gpl-2.0.txt
-> rbn-malvertisers.rules
-> rbn.rules
-> reference.config
-> sid-msg.map
-> suricata-2.0-enhanced-open.txt
-> tor.rules
-> unicode.map
But you can check for sure that the rules have been installed for you by listing the target directory looking for emerging rules:
root@r1.hq:~# ls -l /etc/suricata/rules/emer*
-rw-r--r-- 1 root root 364697 Jun 14 18:04 /etc/suricata/rules/emerging-activex.rules
-rw-r--r-- 1 root root 79725 Jun 14 18:04 /etc/suricata/rules/emerging-attack_response.rules
-rw-r--r-- 1 root root 34494 Jun 14 18:04 /etc/suricata/rules/emerging-chat.rules
-rw-r--r-- 1 root root 3305 Jun 14 18:04 /etc/suricata/rules/emerging.conf
-rw-r--r-- 1 root root 1498683 Jun 19 06:25 /etc/suricata/rules/emerging-current_events.rules
-rw-r--r-- 1 root root 1267158 Jun 19 06:25 /etc/suricata/rules/emerging-deleted.rules
...
OK! they they are! we got rules! lets setup the IDS!
Setup Suricata IDS
Suricata comes with one of those long configuration files, with everything there.
The file is /etc/suricata/suricata.yaml, and although monolytic, it eases configuration by trying to keep configuration sections somehow separated...
So, although all is there together, it is not mixed, but instead the configuration tries to follow a logic sequence of steps, in the configuration process.
So, I'll split this section in subsections following the configuration file logic.
Step 1. Inform Suricata about your network
You'll find sections easily ;-)
Here we need to inform which subnets, of those the router is connected to, we could consider our home subnets.
You'll probably want to put here your local LANs, your Wireless LANs, and even some DMZs... Consider that, for Suricata, anything non-home is the expected source (or destination) of bad things.
Here's an example of how this may look in the config:
vars:
# more specifc is better for alert accuracy and performance
address-groups:
HOME_NET: "[192.168.1.0/24,192.168.2.0/24]"
...
Step2. Select the rules to enable or disable
Ok, now we want to ensure Suricata looks for rules at the folder we know we got them.
Also, we have to either comment or comment out rules we want to have
enabled or disabled.
So, check emerging threat rules you know you have and want to use, are commented out... for instance:
default-rule-path: /etc/suricata/rules
rule-files:
...
- emerging-attack_response.rules
Step3. Select outputs to enable.
This one was confusing to me... I wasn't aware of what 'output' was meant for, so I initially enabled everything.
And it turned out that Suricata literally flooded the logs, as it logged a report on every single thing it inspected, even if no problem is detected!.
So, basically, I'm interested on Suricata reporting (and logging) when something looks bad, and that's what alert ouput is.
Additionally, I also liked the idea of Suricata being able to report on SSH traffic passing through and on the flows.
You can use Suricata to output to log details of HTTP traffic flowing through the router, this can be sure very useful in a lot of situations, and this can be configured in quite a good detail.
Here but, I'm disabling HTTP inspection output entirely... But note that this doesn't prevent the IDS from inspecting HTTP for threats and alert on them!!! ... it just means it doesn't report to log every HTTP inspected activity.
types:
- alert:
# payload: yes # enable dumping payload in Base64
# payload-buffer-size: 4kb # max size of payload buffer to output in eve-log
# payload-printable: yes # enable dumping payload in printable (lossy) format
# packet: yes # enable dumping of packet (without stream segments)
http: yes # enable dumping of http fields
tls: yes # enable dumping of tls fields
ssh: yes # enable dumping of ssh fields
smtp: yes # enable dumping of smtp fields
dnp3: yes # enable dumping of DNP3 fields
#- http:
... lot of stuff, I commented everything too
- ssh
- flow
Step4. Configure common capture settings.
Basically, look for, and setup the following lines, specifying in which network interface the IDS/IPS will sniff traffic looking for threats.
Tipically, this is your WAN interface, the one connecting your home networks with the evil Internet.
# Linux high speed capture support
af-packet:
- interface: enp4s0
...
# Cross platform libpcap capture support
pcap:
- interface: enp4s0
Restart IDS with new config
Issue command:
service suricata restart
check that some problem in config file didn't prevent it to start normally:
root@r1.hq:~# service suricata status
● suricata.service - Suricata IDS/IDP daemon
Loaded: loaded (/lib/systemd/system/suricata.service; disabled; vendor preset: enabled)
Active: active (running) since Fri 2018-06-15 14:17:59 CEST; 3 days ago
Docs: man:suricata(8)
man:suricatasc(8)
https://redmine.openinfosecfoundation.org/projects/suricata/wiki
Process: 30084 ExecStop=/usr/bin/suricatasc -c shutdown (code=exited, status=0/SUCCESS)
Process: 30088 ExecStart=/usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid (code=ex
Main PID: 30089 (Suricata-Main)
Tasks: 10 (limit: 4915)
CGroup: /system.slice/suricata.service
└─30089 /usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid
Jun 15 14:17:59 r1 systemd[1]: Starting Suricata IDS/IDP daemon...
Jun 15 14:17:59 r1 suricata[30088]: 15/6/2018 -- 14:17:59 - <Notice> - This is Suricata version 3.2.1 RELEASE
Jun 15 14:17:59 r1 systemd[1]: Started Suricata IDS/IDP daemon.
Yay!!! it's running!!!
Handle the logs
We may clean the output logs from early stuff that's there from before configuration.
echo "" > /var/log/suricata/eve.json
echo "" > /var/log/suricata/fast.log
From now on, event on teh logs belong to what we setup Suricata to log.
At this point, you may consider what to do with those logs
In my case, I use ELKs filebeat utility to send them to a Logstash server to process them and push them into an Elasticsearch cluster.
Suricata can really put a huge amount of data on the logs (that's what it is meant for) so we need to ensure a proper log rotation with compression, specially when Suricata runs on appliances with tiny disks.
So let's put into /etc/logrotate.d/suricata something that handles the log files you setup in your IDS.
For this Vanilla example, here's how the file look like:
/var/log/suricata/*.log
/var/log/suricata/*.json
{
rotate 7
missingok
compress
copytruncate
sharedscripts
postrotate
/bin/kill -HUP $(cat /var/run/suricata.pid)
endscript
}
No delaycompress on this setup, I want logs to be imediatelly compressed upon rotation:
root@r1.hq:~# ls -l /var/log/suricata
total 236532
-rw-r----- 1 root root 116356184 Jun 19 11:33 eve.json
-rw-r----- 1 root root 4467098 Jun 17 06:25 eve.json.1.gz
-rw-r----- 1 root root 61372 Jun 18 17:13 fast.log
-rw-r----- 1 root root 20 Jun 14 17:20 fast.log.1.gz
-rw-r----- 1 root root 117496357 Jun 19 11:33 stats.log
-rw-r----- 1 root root 3794708 Jun 17 06:25 stats.log.1.gz
-rw-r--r-- 1 root root 336 Jun 19 06:26 suricata.log
-rw-r--r-- 1 root root 2508 Jun 16 06:26 suricata.log.1.gz
And thats it!!!!
We got Suricata up and running... lovely Debian!... :-)
So, till the next one!!!