Writing signatures for Suricata and other intrusion detection systems (IDS) is considered by many to be a form of art.
One of the main reasons is that the rule writer needs to start by examining a network trace to identify patterns that are representative to a threat/behavior without being too broad (to avoid false positives) or too narrow (to avoid being escaped at the first change of a bit in the attack).
But the language used to write signatures is the second reason. It is not really expressive and doesn't have advanced constructs. As a result signatures require complex writing to do things that could appear simple. And there are implicit conventions and structures that must be followed to guarantee correct integration in the detection engine.
As you can begin to see, performing matching at 40 Gbps or 100 Gbps with 60,000 active signatures definitely requires some help from the rule writer.
In the case of Suricata, there are some embedded features that can help the user understand when the syntax of the rule is not correct. But checking the output of the related commands is tedious work.
Introducing the Suricata Language Server
We created the open-source Suricata Language Server (SLS) to solve these problems. SLS is a Language Server Protocol implementation that allows the user to benefit from built-in Suricata diagnostic capabilities when editing rules. SLS provides advanced diagnostics as well as auto-completion.
But before diving into the features of Suricata Language Server, let’s explain a little about the Language Server Protocol. It is a JSON RPC based protocol that allows an external tool (usually a source code editor) to get information – from a language dedicated backend – about the syntax of the file for a given language or structure. Implementations exist for multiple programming languages as well as for some file formats (YAML, JSON, HTML, …). The advantage of the LSP protocol is that once it is implemented for a language, then it will provide the feature set for all the tools that support the protocol.
Suricata Language Server is available under GPLv3 license. It implements diagnostics and auto completion of the keywords as you type in your favorite source code editor or integrated development environment (IDE). Configuration examples are provided for Visual Studio Code, Neovim, Sublime Text and Kate, but it should work for any editor that supports LSP. In the case of the popular Visual Studio Code, we released a plugin on Visual Studio Marketplace. Named Suricata Intellisense it incorporates all the features of Suricata Language Server with an easy configuration.
Suricata Rule Syntax Checking
The syntax checking identifies syntax errors and – maybe even more interesting – it also provides warnings about performance issues as well as hints to help the rules writer.
Suricata Rule Auto-Completion
The second key feature is auto-completion. This is performed using a direct link to the documentation as you can see in this screenshot of Neovim:
Suricata Rule Performance Guidance
SLS also provides real-time performance guidance to the rule writer. It does so with feedback from the Suricata engine itself and with logic implemented in SLS itself.
Performance guidance includes hints such as information about automatic Suricata fast pattern selection and warnings about potential serious performance issues caused by a rule that only has a PCRE regular expression.
Requires a Suricata Binary
A working Suricata binary is needed in order to use the Suricata Language Server. This may appear like a problem, but it is in fact a real advantage. The real-time syntax checks and keyword information is coming directly from the source of truth (an actual running instance of Suricata). So if you use multiple versions of Suricata, you can just switch them in the configuration to benefit from syntax checking and auto-completion adapted to your specific Suricata version.
The Suricata Language Server is available under the GPLv3 license and is hosted on Github. It is also published on Pypi, so a simple pip install suricata-language-server is enough for the installation. Configuration instructions for tested editors are described on the Github page.
Don’t hesitate to provide us feedback or ask questions if you find this project useful. You can contact us on Discord, use the issue system on Github, or simply send us an e-mail (firstname.lastname@example.org).