Tag Archive | suricon

SuriCon 2021 – Call for Trainings

We are pleased to announce our Call for Trainings for SuriCon 2021! SuriCon opens with two days of training prior to the start of the conference. Training submissions should be for either a 1 or 2 day course and should include aspects that are related to Suricata.

You can submit your training proposal at Call for Trainings – SURICON

Important Dates

Call for trainings opens: February 2021
Call for trainings closes: June 4, 2021
Notifications sent out: June 2021

Training Selection Process

The SuriCon training review board consists of members of the Open Information Security Foundation (OISF) and other distinguished members of the information security community. If you have any questions please don’t hesitate to reach out to us at SuriCon@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.

Roadmap Development Session at SuriCon

One of the most exciting things of last year’s Suricata User Conference in Barcelona was the road map discussion. For those who weren’t there, this is how it worked: the dev team sat on the stage and explained some of the ideas for next steps in Suricata development. There was a lively discussion between the team and the crowd. Many ideas were thrown in (and out as well). At the end of the session we had a list of wishes and ideas. The dev team did a guestimate of effort on each. Then together we all discussed priorities.


Last year’s list included the following ‘top priority’ ideas:

  • flow bypass: almost done
  • failing better: in progress
  • hyperscan integration: mostly done
  • performance recommendation: needs work
  • default config improvements: mostly done
  • dynamic stream depth: almost done

The result of last year was also NOT doing some work. The group didn’t care much about a binary output for EVE (e.g. bson or similar), so we
avoided spending time on that.

In our survey of the Barcelona conference, we learned that some ppl found this session extremely valuable, but other ppl much less so. For
this reason we’re doing the session on the 3rd & last day of our conference now. If people don’t care much they can skip it and head home

I’m looking very much forward to doing another session like this in DC, so please consider joining us at SuriCon! The session at SuriCon 2.0 will be quite a bit longer too, so we should be able to cover more topics and more ideas. So please join us!

Oh and do bring your wish list!

Register at SuriCon here.