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 firstname.lastname@example.org.
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!