Suricata Language Server (SLS) has been available for more than 3 years, and it has always been useful for security analysts or rule writers that need to write Suricata signatures and want to get real-time syntax checking and performance hints from their preferred editor. During those 3 years which we consider a beta phase, we observed and gathered insights from users of the tool. We are pleased to announce that we’ve enhanced SLS and are ready to release version 1.0 officially at this time.
In addition to a number of minor enhancements, we wanted to address a major limitation of the last version, notably when writing rules with specific purposes that use specific variables. For example, the default configuration of Suricata does not include a GW_SERVERS variable, so the syntax checking of a signature like:
alert http $GW_SERVERS any -> $EXTERNAL_NET any any (msg:”gw don’t do http outbound”; sid:1;)
Would result in an error message stating the variable GATEWAY_SERVERS is not defined. This is annoying if this is defined in your target configuration.
The only fix available in the previous release was to use --suricata-config and pass it a configuration command in the editor’s language server protocol (LSP), which is not really convenient.
With SLS version 1.0, it is now possible to use specific comments in the rules file to do that dynamically. This can be done by adding the ``## SLS suricata-options:`` prefix to the comment. The text that follows this prefix is passed to Suricata as command line options.
For example, if you want to use custom address groups and specific options, you can add the following line to your rules file:
## SLS suricata-options: --set vars.address-groups.GATEWAY_SERVERS="127.0.0.3"
The variable will then be added to the command line of Suricata when it tests the signatures in the editor. By doing so, it will now pass the test on the variable. Please note that there is really 2 # for the comment.
The second improvement is related to the dataset keyword handling. In some deployments you can not simply do
alert http any any -> any any (msg:"test"; file_data; dataset:isset,fi,type string, load dd.lst; sid:1;)
Instead, you must specify the full path to the dataset.
alert http any any -> any any (msg:"test"; file_data; dataset:isset,fi,type string, load /path/to/dataset/dd.lst; sid:1;)
Because the directory will probably not exist on the platform where you edit the signature file, the test will fail. In addition, creating the file at its final path during a test is not a good practice as the test should be confined. The Suricata Language Server allows users to set the final directory for datasets files by using a specific comment in the rules file. This is done by adding the ``## SLS dataset-dir:`` prefix:
## SLS dataset-dir: /path/to/dataset/
With this line, a signature such as the following one will be correctly parsed and evaluated:
alert http any any -> any any (msg:"test"; file_data; dataset:isset,fi,type string, load /path/to/dataset/dd.lst; sid:1;)
Finally SLS 1.0.0 provides a feature for rules writers to manage different versions of Suricata. It now displays in the help message the minimum and maximum version where the keyword was available:
To download this latest version, please visit the SLS GitHub repository here>>
And to engage the open source community about this and other Suricata tools developed by Stamus Networks, please join the discussion on Discord here >>
