SecurityOnion@Home - Suricata Include

 At work we started to use the include statement in our Suricata.yaml file while we were using SecurityOnion 16.04 and with the switch to SecurityOnion 2.3, I wanted to see how easy this would be to implement.  

First things first, we go from having a Suricata.yaml for each interface to having one bonded interface, so that makes updating simple.  With the bonded interface there is no more /etc/nsm/interface/suricata.yaml. I did find a suricata.yaml file under /opt/so/conf/suricata/ but it's created and managed with Salt, which means I probably cannot/should not edit that file directly. 

I am running a standalone version of SecurityOnion at my house so the steps might be a little different in a distributed environment.   

In the salt configuration first place I found a reference to the suricata yaml file was at:

/opt/so/saltstack/default/salt/suricata/default.yaml  which build out the suricata.yaml to /opt/so/conf/suricata.  

I decided to put the test_var.yaml @ /opt/so/conf/suricata/ 

Lets see what happens when I add the include file directly to the default.yaml file.  

1. After the update you run:  salt minionname_standalone state.highstate
2. Run:  so-status 

             3. Run: so-suricata-start

     4. Run: docker logs so-suricata

 It's looking for the file in the /etc/suricata/ folder (Which does not exist on-base OS, but it does exist on the Docker container for Suricata.  

We can validate this with docker inspect so-suricata (Looking for Binds)

As you can see that there is a /etc/suricata (The right side of the bind, which is the Docker container).  Looks like for the most part there are files that are bound between the Docker image and the core OS of SecurityOnion. 

I thought about putting the include file on the docker file @ /etc/suricata, but this does not sound like a good option for two reasons:

1. Upgrades would erase this
2. Probably more important, unsure if the included file inside the docker would work due to connecting the core OS.  

 From the last image it looks like I could potentially put the file in two directory locations:

1.  /nsm/suricata ---> This is where the eve.json files are, so probably not the best location
2.  /opt/so/conf/suricata/rules -->  which maps to /etc/suricata/rules on the docker container

Back to salt to make some updates to the sls files.   I am editing the /opt/so/saltstack/local/pillars/minions/name_standalone.sls

Note: Remember spacing (2) on yaml files

1. Edit the sls at the end:

            suricata:
              config:

                include:/etc/suricata/rules/test_var.yaml

1. Next I copy the test_var.yaml -> /opt/so/conf/suricata/rules
2. Then I run: salt minionname_standalone state.highstate
3. Check Docker containers with so-status (All good)
4. And validate with docker logs so-suricata
   
   
   

Now I have an include file as part of SecurityOnion, and my local teams can update that file which could cause Suricata to fail, but it's better than them trying to update the sls files under minions to add/remove variables in my opinion (which could break more functionality besides Suricata)