In the default configuration Suricata-Update will download the ET Open ruleset. In the Suricata 5.0 optimized version, JA3 rules are added and enabled by default. See below for instructions on how to disable these rules with Suricata-Update.
The new default configuration has a number of extra EVE loggers enabled by default. These are the ‘anomaly’ logger, and loggers for the snmp, ftp protocols. In 4.1 Rust was optional, unlike in 5.0. This means that loggers for smb, nfs, tftp, ikev2, krb5 are now also enabled by default. As a result, logging volume may be higher than expected. Logging for these protocols can be enabled/disabled in the eve-log section in the suricata.yaml.
When using Suricata with ET (Open or Pro) rules managed by Suricata-Update, the ruleset will automatically switch to the 5.0 version of the ruleset. This has a number of consequences.
- The ET 5.0 ruleset use a different classification scheme. Suricata 5.0 will issue warnings if rules use an unknown classtype. Update your classification.config from the one Suricata 5.0 ships or the ET ruleset version to suppress these warnings.
- If JA3 is enabled in the Suricata configuration (or not specified), the ET5 JA3 rules will be enabled by Suricata-Update. These rules have been quite noisy in the past. If they are alerting too frequently, the rules can be disabled in Suricata-Update.
Read more about upgrading https://suricata.readthedocs.io/en/latest/upgrade.html
Telling Suricata-Update to disable JA3 rules
- By filename. If all the JA3 rules are in a specific file like you find in ET Open and ET Pro, you can use Suricata update to disable all files in a rule. In /etc/suricata/disable.conf add the line: filename: rules/emerging-ja3.rules
- By regular expression. As all the rules we see in the ET Open and Pro ruleset are using the ja3_hash keyword, we can disable JA3 rules by using a regular expression looking for the ja3_keyword. This has the benefit of matching across all filenames. In your /etc/suricata/disable.conf, add the line: re: ja3_hash;
EVE DNS Logging
Suricata 5.0 will default to the version 2 style of DNS logging in EVE if a version is not provided in the configuration. This is something to note if you are upgrading from 4.0, or 4.1 without Rust, as your EVE DNS log format will change. To continue using the version 1 format, you must update your configuration to include “version: 1”. See the documentation at https://suricata.readthedocs.io/en/latest/output/eve/eve-json-output.html#dns-v1-format for more information. However, we recommend moving to the version 2 style output, as it is more compact, and where enhancements to DNS logging will occur.
To see what issues are already reported, see https://redmine.openinfosecfoundation.org/versions/138. If you run into an issue that isn’t listed, please open a new ticket.
We’re happy to present the first beta in the upcoming Suricata 5.0 series. In 5.0 we’re making a couple of large changes.
The most visible is that our Rust support is no longer optional. We’re convinced that Rust is a perfect match for Suricata, and we plan to increase its footprint in our code base steadily. By making it mandatory we’re able to remove parallel implementations and focus fully on making the Rust code better.
The protocol detection engine has been extended to provide better accuracy as well as support for dealing with asynchronous flows. These async flows are sometimes picked up in the wrong direction and the protocol detection engine can now reverse them.
Decoder Anomaly records in EVE
A new log record type has been added: ‘anomaly’. This logs the stream and decoder events that are set by the packet decoders. This is inspired by Zeeks (Bro) ‘weird’ log.
VLAN and capture interface is now part of many more EVE records, even if they are flow records or records based on flow time out.
An option to log all HTTP headers to the EVE http records has been added.
Netmap support has been rewritten so the more advanced features of netmap, such as vale switches, can be used now.
Napatech usability has been improved.
Rule language: Sticky Buffers (in progress)
As discussed at the Suricon 2018 brainstorm session, a new rule keyword scheme is being introduced. It takes the existing ‘sticky buffer’ approach with new keyword names to avoid confusion. The new scheme is <proto>.<buffer>, so for example ‘http.uri’ for the URI inspection.
A number of HTTP keywords have been added.
Unified Lua inspection mixed with the sticky buffers has also been implemented.
With Python 2’s EOL approaching, we’ve made sure that all Suricata’s python code is Python 3 compliant.
Following our deprecation policy, we have removed the following parts: the plain text dns.log, the old files-json.log and support for the Tilera architecture.
Many more things
We’re planning the first release candidate in about a month, with the final about a month later. So early July.
If you’re interested in helping out, we’d be happy to accept patches, documentation, test reports and other kind of feedback.
We are excited to announce the first alpha release of our new tool for updating Suricata rules. This is a new rule update tool specifically built for Suricata with a goal of being useful out of the box, even with no configuration.
This release also introduces the Suricata Intel Index, which is currently a list of available rule sources which Suricata-Update is aware of. The idea here is to make it easier for users to find available rule sets, as well as allowing rule writers to make their rules more discoverable.
- Default to Emerging Threats Open ruleset if no configuration provided.
- Automatic discovery of Suricata version for use in ruleset URLs.
- Flowbit resolution
- Enable, disable, drop and modify filters that should be familiar to users of Pulled Pork and Oinkmaster.
- Easy enabling of additional rule sets from the index.
If you are a rule writer and would like to get listed in the index, please leave a ticket in the issue tracker.
Github Project Page