New Suricata Features Coming in Next Update

  • A new update for the Suricata GUI package is coming soon.  The pull request with details is here:

    Users of Suricata may find a couple of the new features quite useful.  One of these is the ability to force rule actions to ALERT, DROP or REJECT on a SID-by-SID basis on either the RULES tab or on the ALERTS tab.  More on this in a minute.

    Another change coming is the migration of any automatic SID management configuration from physical files stored on the firewall to lists stored in the firewall's configuration.  This change is important because with it your SID MGMT tab configuration will now be backed up and restored along with the rest of the firewall configuration.  The data will not exist as separate physical files.  You still have the option of uploading or downloading SID MGMT configuration files, but when saving them on the firewall the actual content will be stored as Base64-encoded data within the config.xml file that holds all of the firewall configuration information.

    For user overrides of rule state (enabled or disabled) and rule action (alert, drop or reject), a third "default" option is now available for each setting.  Setting the user override to "default" actually removes all user overrides and returns the rule's state or action to the original value specified by the rule author.  Formerly, when toggling the rule state with the user override icon, you could only switch between "user-forced enabled" or "user-forced disabled".  Now, with the new "default" option, you can return the rule to its original un-forced state.  The same is true for rule action overrides.

    When using Inline IPS Mode, users now have the option of changing a rule's action to REJECT.  This is similar to DROP but with one important difference.  With DROP, the packet is simply dropped and the sender never gets any feedback on the status of the packet sent.  With REJECT, the packet is still dropped, but the sender is notified that the packet was rejected by the recipient.  This is helpful when used with rules associated with internal hosts.  It can prevent applications from experiencing long timeout periods waiting for feedback about a packet that was actually dropped.  With REJECT rules, the sender gets immediate notification that the recipient refused to accept the packet.  Please note that the REJECT option is only available when using Inline IPS Mode operation.  Legacy Mode blocking does not support sending reject messages to the sender.

    Similar to the restriction above with REJECT, the user forced action of DROP is only available when using Inline IPS Mode or Legacy Mode with "Drop-on-Blocks-Only" enabled.  So if you are running in IDS only mode (no blocking enabled), then DROP and REJECT have no meaning.  Similarly, if you are using the original Legacy Mode where every ALERT generates a block, then the DROP action has no relevance.  The GUI will automatically hide rule actions that are not applicable to the current operational mode.

    The rule action override feature will also now be available on the ALERTS tab.  So if you see an alert and want to toggle that rule to DROP when using Inilne IPS Mode, you can click the icon and a modal dialog will open with choices of Default, ALERT, DROP or REJECT.  Choose the action desired for future packets that trigger the rule and save the change.  As mentioned earlier, choosing "Default" will remove any previous user action overrides.

    I will post release notes for the new version when it is approved and posted by the pfSense team.


  • Thanks for the post I really do like my Suricata setup ♥♥

  • Thank you for the release.

    Can a REJECT action be forced to a group of rules, the same as DROP action is, via a SID.conf file ?

  • @NRgia:

    Thank you for the release.

    Can a REJECT action be forced to a group of rules, the same as DROP action is, via a SID.conf file ?

    Not currently, but that would not be hard to add as a feature to the SID MGMT tab.  Something like a "rejectsid.conf" configuration maybe.  I will put it on the list for a future feature update. I  didn't add it this time because I figured only a very tiny handful of rules might need the REJECT action, and a small number can be handled on the RULES tab or "after the fact" on the ALERTS tab.


  • As a feedback, a "rejectsid.conf" is also what I wanted to suggest, but in the end it's your decision.

    Thank you for taking this option into consideration

Log in to reply