- Ubuntu 14.04 from here: http://www.armhf.com/boards/wandboard/#trusty. The only drawback is the "reboot problem"
I added a USB ethernet dongle to give me 2 ethernet ports: http://www.amazon.com/gp/product/B00AQM ... UTF8&psc=1. It is recognized out of the box by the kernel.
I have a notebook hard drive connected with an external eSata enclosure.
I have both the Wandboard and the eSata enclosure powered with this: http://www.amazon.com/gp/product/B00LCW ... UTF8&psc=1
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 libjffi-1.2.so 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 192.168.0.0/16. So the rule looks like this:
bpf-filter: not src net 192.168.0.0/16 or not dst net 192.168.0.0/16
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.