Suricata, Logstash, Kibana on Quad

Show or tell us what you are doing with your wandboard!

Suricata, Logstash, Kibana on Quad

Postby rabinnh » Sun Oct 19, 2014 4:13 pm

It took a little bit of work, but I got the Suricata IDS installed on a Quad. I have my firewall coming into a managed switch, so I mirror the port to which the firewall is connected to another port. Here is my setup:

The setup is that the Wandboards eth0 interface is setup without an IP address. This is what Suricata is configured to listen on. SO eth0 is connected to the mirrored firewall port.

eth1 (the dongle) is configured with an IP address and is plugged into a regular port on the switch. This gives me a "management" address for ssh and to access the Web server.

I downloaded the Suricata source and built it after creating the Makefile with this configure command:

./configure --enable-nfqueue --prefix=/opt/suricata/usr --sysconfdir=/opt/suricata/etc --localstatedir=/opt/suricata/var --with-libjansson-includes=/usr/include --with-libjansson-libraries=/usr/lib/arm-linux-gnueabihf --enable-geoip.

This allows the logging output to be in EVE json format for Logstash and also enables geoip.

I downloaded Logstash but found that it wouldn't run on the Wandboard. There is a native library included in the jar in the jni/arm-Linux directory called but it is incompatible with the Wandboard. So I downloaded the jffi source, built it on the Wandboard, and repackaged the jar. Now Logstash works perfectly.

I downloaded Kibana, installed apache2, and configured Apache to serve Kibana.

When I first ran the system I found that Logstash would fall behind the packet analysis. After a day it was 4 hours behind and was never going to catch up. Of course large organizations split these components over multiple servers and even a cluster of Logstash/Elasticsearch instances (Logstash has an embedded version of Elasticsearch, but you can also use external instances). However, most of the traffic was internal on the network. The solution was to configure Suricata to use af_packet mode to capture packets, and then use a BPF rule in suricata.yaml to filter out all traffic where the source and destination addresses were on the local subnets, all of which are covered by So the rule looks like this:

bpf-filter: not src net or not dst net

So a packet where the source or destination is not local gets passed through and evaluated.

Here is a screen shot. Note the timeline at the top where there is a capture gap. That was this morning when I was changing the configs to use af_packet mode and the BPF rule:

Some screenshots are attached.
suricata1.png (270.57 KiB) Viewed 2938 times

suricata2.png (125.58 KiB) Viewed 2939 times

suricata3.png (122.49 KiB) Viewed 2937 times
Posts: 3
Joined: Sun Oct 19, 2014 3:48 pm

Return to Showcase and success stories

Who is online

Users browsing this forum: No registered users and 3 guests