Suricata IDS and Turris Omnia

The main reason why I bought Turris Omnia was the ability of the device to run LXC containers and the fact that my old Linksys E3200 router had problems with its 5GHz Wifi stability. I also looked for a platform that would be able to satisfy my needs for a device which would be able to run Suricata IDS for my home network.

I tested Raspberry Pi for this purpose and it worked quite well. The only problem is the fact that you need to mirror your traffic against the device in a certain way. And I had a problem to find the way. Ok, I have a switch allowing me to mirror the traffic from port or ports to another port towards Raspberry. But I have some wired and some wireless devices and placement of the switch into my network infrastructure wouldn’t be simple when I (read Raspberry) need to see all the traffic.

But back to the topic. I installed the Turris device and worked fine. Except the fact that the first thing I had to do was to take tongs and tighten a nut. Otherwise I wouldn’t be able to attach an antenna to a wobble connector. I used several four-letters-words during this simple operation as I had just bought a device with a really high price tag and I expected premium product not a DIY device.

OK,  back to the topic again. I also created an LXC container with Debian Linux and installed Suricata. Literally in minutes. Everything worked as expected. The only problem was the fact that Suricata didn’t see all the traffic. Only broadcasts and multicasts and traffic originating or terminating on the LXC container’s IP address. It was quite obvious that the Suricata is not able to switch all the needed places into promiscuous mode. I played with veth/bridge/phy setup of the LXC container for more that a few hours. But without any luck.  And you can be sure that Google was my best friend.

Finally I gave up and realised that I cannot mirror/TAP all the traffic just by configuring LXC networking and manually modifying promiscuous modes of host’s interfaces. And in that moment I found daemonlogger.

I modified the LXC configuration of my Suricata container to:

# Network configuration

lxc.network.type = veth

lxc.network.link = br-lan

lxc.network.flags = up

lxc.network.name = eth0

lxc.network.veth.pair = veth-deb

lxc.network.script.up = /usr/share/lxc/hooks/tx-off

lxc.network.hwaddr = e2:17:79:92:68:e5


lxc.network.type = veth

lxc.network.flags = up

lxc.network.name = eth1

lxc.network.veth.pair = veth-mon

lxc.network.script.up = /usr/share/lxc/hooks/tx-off

lxc.network.hwaddr = e2:17:79:92:68:e6

And installed deamonlogger into Turris host and started it:

# opkg install daemonlogger

# daemonlogger -i br-lan -o veth-mon

Now I could start Suritaca inside of the LXC container:

# /usr/bin/suricata -c /etc/suricata/suricata.yaml -i eth1

And it worked. Probably iptables can be also used to achieve the same goal. But to be honest I am not a friend of iptables. If you know how to mirror traffic using another and more elegant way, please share it with me.

Next steps will be:

  • set an autostart of the all needed components, LXC hooks will be probably the right mechanism.
  • Install another LXC container with ELK stack to visualise and analyse collected Suricata’s data.

I will be back. Soon or never. Good night.

4 komentáře u „Suricata IDS and Turris Omnia

  1. It’s also good idea to change the unix-command part of suricata.yaml to

    unix-command:
    enabled: false

    because /var/run/suricata is in Turris’s RAM and will not survive a reboot but Suricata cannot live w/o that directory.

  2. Hi! Thanks for this howto. I’m trying to achieve the same thing as you did. Can you please clarify a few things:
    1) LXC interfaces: eth1 is used to monitor your network while eth0 is to provide connection to the internet, correct?
    2) veth-mon is a new interface on your Omnia defined in the /etc/config/network config file? How is it defined?
    3) What is the veth-deb interface? How is it defined?
    4) Daemonlogger just relays all the traffic from br-lan to veth-mon, right?
    Thanks. 🙂

    1. Zdravím!

      Je to tak! Veth-mon je použito suricatou a veth-deb je pro ostatní běžnou komunikaci s kontejnerem.

      Je to definováno jen v config souboru LXC kontejneru. Spuštěním kontejneru v něm vznikne eth0 a eth1 a mimo něj (tady v Turris OS) to rozhraní veth-mon. A to je vlastně vše, pak už lze spustit ty „vidle“, třeba daemonlogger a odkázat jej přímo na veth-mon, který je viditelný.

      Omlouvám se za opožděnou reakci…

      – Honza

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *