Suricata scheduling rules

mmarco

I need to have suricata rules dropping certain traffic (or not), based on the time of day.

My idea is to define two different Sid Management (SID Mgmt) lists and then apply them by cron.

So for example two lists:

lan-drops-day.conf
lan-drops-night.conf

So Drop SID List would be configured via cron job with one or the other list, based on time of the day.

I don't know how to do this (change sid mgmg list from cron), and also is there easier way to schedule different rules ?

Just as an example I want to allow ping to 1.1.1.1 from 08:00-16:00 and drop it from 16:00-08:00.

bmeeks

There is no support for this within the package. It is not designed to be automated or scheduled.

If you are really skilled in PHP coding and writing Unix scripts, then you could perhaps craft something that works for you completely outside of the Suricata package. But there is no mechanism for accomplishing what you describe within the existing package code.

mmarco

Thank you for reply. Yes, I am now aware that there is no support in the package, but I am trying to figure out way outside of package.

What I got so far is to figure out that those lists are stored in /conf/config.xml (base64 encoded) with the rest of the pfSense configuration and selection of the list to be used as Drop SID List is property <drop_sid_file> inside xml.

So I created a cron job (via package) to replace value of drop_sid_file (using sed) based on schedule and restart suricata. Hopefully this will work. I also need to reload config.xml to be shown in gui properly.

Ugly imho, but if it works ...

bmeeks

@mmarco said in Suricata scheduling rules:

So I created a cron job (via package) to replace value of drop_sid_file (using sed) based on schedule and restart suricata.

I don't think this will accomplish what you desire. It depends on exactly how you restart Suricata.

The GUI code calls a function that reads the data from config.xml and generates both the YAML file for the interface and also creates a suricata.rules file for the interface containing the rules the binary is to parse and load. Simply restarting the Suricata daemon via the available shell script /usr/local/etc/rc.d/suricata.sh will not be sufficient as that script will NOT call the PHP routine that rebuilds the suricata.rules file. It will simply restart Suricata with the same rules as it was running previously. You will need to trigger a rebuild of the rules so that the suricata.rules file for the interface will be updated.

You would have better luck rebuilding the rules file completely outside of the GUI code and forget about trying to change the values coded in config.xml. You would then restart the Suricata daemon using this command:

/usr/local/etc/rc.d/suricata.sh restart

Each configured Suricata instance has its own unique subdirectory under /usr/local/etc/suricata/ where the YAML config file and the suricata.rules file for the interface are maintained. There is a master copy of all the downloaded and available rules under /usr/local/share/suricata/rules (I think that's the correct path -- recalling off the top of my head). That master copy is read to then assemble only the enabled rules for a particular interface and store them in the suricata.rules file in the appropriate subdirectory under /usr/local/etc/suricata/.

mmarco

@bmeeks thank you for the very good explanation.

Yes , it fully makes sense what you say. So my idea will not work .

I don't know how to recalculate rules, so my first thought was to simply save two configuration profiles in some other folder and then swap them, but then I realized that these rules get updated, and if I do this, I will be using outdated rules.

So the only way would be to "tell" frontend to rebuild rules once I change SID management configuration, but I don't know how to trigger that, except perhaps to try to simulate request on GUI.

bmeeks

@mmarco said in Suricata scheduling rules:

@bmeeks thank you for the very good explanation.

Yes , it fully makes sense what you say. So my idea will not work .

I don't know how to recalculate rules, so my first thought was to simply save two configuration profiles in some other folder and then swap them, but then I realized that these rules get updated, and if I do this, I will be using outdated rules.

So the only way would be to "tell" frontend to rebuild rules once I change SID management configuration, but I don't know how to trigger that, except perhaps to try to simulate request on GUI.

You could adapt the official Suricata rules management tool from upstream, suricata-update to potentially accomplish what you wish. Here is a link to the official documentation for that tool: https://docs.suricata.io/en/latest/rule-management/suricata-update.html. That tool is packaged and deployed within the Suricata package on pfSense. So, the code is there. It's just not normally used on pfSense.

You will have to adapt and customize the usage of that tool a bit in order to have it work within the confines of the existing GUI code and the logic used with the Suricata package on pfSense. But if you point that tool to the master rules repository and to the output rules directory for a Suricata instance on pfSense, in theory it should be able to construct a suricata.rules file for you. You would just need to duplicate the dropsid.conf and any other SID management files you created in the GUI out to plaintext files in a directory that suricata-update can access and use. I've never tried this, but I believe it could be make to work with some customization.

I have considered a few times in the past attempting to incorporate this upstream tool into the Suricata GUI package code, but have not yet seriously attacked the problem nor analyzed it deeply enough to identify any potential show stopper issues.