Hello, I’m considering an upgrade to suricata. Currently my organization runs 6.0.0 as of about 04.2021 on 300 servers in our organization. I see 6.0.10 is out. What improvements have been made since 6.0.0 that would make this worthwhile?
Thanks for your thoughts.
Especially if you run it in production, you should always update to the most recent stable versions since we include security fixes as well. Also there are bugfixes that have been reported in previous versions and we also backport fixes.
See the CHANGELOG suricata/ChangeLog at master-6.0.x · OISF/suricata · GitHub where we also point ot the security related fixes.
Do you have a timeline for the suricata 7.0 version? How many more minor revisions of 6.0 are planned?
We expect Suricata 7 to be released in the Spring of '23.
The number of additional patch releases of 6.0.x depend on many things, one of which are security issues that arise before we declare it EOL. Our EOL policy is at EOL Policy - Suricata
Our roadmap has information that may interest you: https://redmine.openinfosecfoundation.org/projects/suricata/roadmap
I strongly encourage your organization to stay on the latest patch release for the reasons @Andreas_Herz mentioned (security and evasion fixes, important bug fixes).
Thanks, will wait for 7.0
I think this is an important conversation, and I would like to give a bit more of our perspective.
In general, it is important to see the use of a tool like Suricata as the commitment to a lifecycle. I think best practices are roughtly:
Initial phase:
Then during the lifetime of the install:
Then when the installed Suricata approaches the EOL date, the cycle starts again.
In the case of Suricata, this probably means doing this “initial phase” once every 18 to 24 months, and the patch installs every 2 to 3 months.
As to why this is important: 6.0.0 about 2.5 years old by now and we’ve done many patch releases to fix many serious issues. These are just the “Security” tickets closed during the 6.0.x cycle:
Security #5804: Suricata crashes while processing FTP (6.0.x backport)
Security #5710: smb: crash inside of streaming buffer Grow() (6.0.x backport)
Security #5694: smtp/base64: crash / memory corruption (6.0.x backport)
Security #5688: decoder/tunnel: tunnel depth not limited properly (6.0.x backport)
Security #5600: ips: encapsulated packet logged as dropped, but not actually dropped (6.0.x backport)
Security #5430: mqtt: DOS by quadratic with too many transactions in one parse (6.0.x backport)
Security #5431: filestore: Segfault with filestore enabled and forced (6.0.x backport)
Security #5254: protocol detection: exploitable type confusion due to concurrent protocol changes
Security #5252: Infinite loop in JsonFTPLogger
Security #4888: ftp: SEGV at flow cleanup due to protocol confusion
Security #5026: ftp: GetLine function buffers data indefinitely if 0x0a was not found in the frag’d input
Security #5027: smtp: GetLine function buffers data indefinitely if 0x0a was not found int the frag’d input
Security #4634: tcp: crafted injected packets cause desync after 3whs
Security #4726: tcp: Bypass of Payload Detection on TCP RST with options of MD5header
Security #4420: Heap-use-after-free READ 8 · JsonDNP3LoggerToClient
Security #4455: Buffer overread in SMTP SMTPParseCommandBDAT
Security #4458: Rust panic in suricata::dcerpc::detect::handle_input_data (buffer overread)
Security #4483: heap-buffer-overflow WRITE in InspectionBufferSetup with use of InspectionBufferGetMulti
Security #4512: Evasion possibility on wrong/unexpected ACK value in crafted SYN packets
In addition to these many bugs were fixed around stability, correctness and performance. 327 closed bugs/tickets total.
Even if you decide now to wait for 7, please do plan to adopt the whole lifecycle based approach. We realize this is not free, it takes time and resources and can add some risk. But we believe not doing it also exposes the organization to significant risk.
I totally agree with Victor. I do not see any reason not to use the latest patch version – the benefits of these important bugfixes at least for me massively outweigh the risk of potential update-induced breakage. This is in particular because usually no new features or breaking behaviour changes are introduced in such patch level releases.