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.
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
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.
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.
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).
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.
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 email@example.com.
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!