Tag Archive | community

Announcing the Suricata Community Council

One of the most valuable moments in the Suricata development process is the annual SuriCon brainstorm. This interaction between the team and community gives the development team a lot of input for the next year.

We hope to create similar conditions more frequently. Therefore, we would like to introduce the new Suricata Community Council – an open and two-way communication channel between the Suricata community and the development team.

The council members will:

  • Provide technical advice and feedback to the development team for major releases;
  • Report on the general state of the Suricata community;
  • Participate in quarterly calls;
  • Join us at SuriCon annually.

We will have quarterly calls as well as convene in-person at SuriCon. To avoid scaling issues, we’re limiting the group’s size and have invited some contributors and other community members to join. Also, the companies at the Platinum and Gold levels of the OISF consortium will each get a representative in the council as well.

As the council comes together we will be updating the Suricata website with bios and more information. In addition, the council will post meeting minutes and updates on https://suricata-ids.org/ and the oisf mailing lists.

For questions about this exciting new community council or becoming a member of the OISF consortium, please contact us at info@oisf.net.

SuriCon 2017 brainstorm summary

At SuriCon in Prague, we spent an afternoon discussing the roadmap for Suricata for the next year. It was a fun an interactive session with lots of discussions and suggestions.

During the session, Matt Jonkman maintained Google spreadsheet, and this post summarizes that. Only issues with ‘high’ priority are mentioned here, as this is already more than we can get done.

We’ve created a high-level ticket that is referenced by all tickets discussed at SuriCon, so this includes the medium and low priority ones: #2309.

Failing better

The idea here is that we should make sure we get more value in ‘failure’ conditions: for example packet loss, or incomplete traffic (due to routing, etc).

A high-level ticket is #2278

Specifically, DNS was brought up: #2272. Also related is the ability to modify memcaps on the fly so that tuning doesn’t always require a full restart of Suricata: #2285.

Suricata sets internal events when protocol anomalies are encountered. These are exposed to the rule language and also used as ‘stats counters’ in the stats.log. A feature request here is to mimic Bro’s ‘weird log’ as well, so create a log output for all these events #2282.

Rule language

Unification and clean up of the ‘buffer’ selection (e.g. ‘content:”abc”; http_uri;’ vs ‘file_data; content:”abc”;’). First step is to agree on a naming scheme and a list of names for all existing buffers: #2285.

Rule writers also asked for simpler ways to express ‘ends with’ and ‘starts with’ (#741, #742) and buffer length (#735).

Being able to write rules that match on both request and response (e.g. HTTP uri and response status) #2280.

Victor is working on a rule ‘transformation API’, allowing buffer transformations (e.g. strip_whitespace). It became clear that the transforms need to support arguments (#1006) and that Lua should be supported (#2290).

File Extraction

Using the SHA256 hash of a file at it’s filename. First store as a temp file, then rename when it’s done. Also, a way to deduplicate storing files #1948

Document best practices for dealing with file extraction #2286.

There is also interest in being able to detect partial file transfers, like when a browser prefetches part of a file #2284.

Eric’s FTP file exaction work is almost complete: #550.


Multiple people expressed interest in JA3 SSL fingerprinting: #2192. Mats Klepsland is working on that.

While not a finalized standard, TLS 1.3 support (#2279) is important as well.


The need for easy test case / pcap sharing was expressed. E.g. Michal mentioned that the Bro project has pcaps with test cases. Probably at first a wiki page listing sources of test cases. Ticket #2322.


HTTP byte-range support #1576.

TCP (and defrag) overlap handling simplification: #2281.

Recording pcaps only for alerting streams: #120, #385, #2219.

Traffic ID ruleset: #2291. A ruleset to classify common high bandwidth traffic, such as video streaming services. In part to assist in flow bypass for performance.

Call for help

The tasks above are together a lot of work, and it’s unlikely that we’ll be able to complete all of there. So if you or your organization would like to help, please let us know! All forms of help are welcome: code, funding, test cases, documentation, testing, designs, etc.  We are also growing our team, but can only do this with financial support from this community – if you are interested in donating to help us grow our dev team, please contact us at info@oisf.net.