Optimization #6792
closed
detect/port: port grouping is quite slow in worst cases
Added by Shivani Bhardwaj 5 months ago.
Updated 2 months ago.
Description
Given how the port grouping was done historically, in some worst case scenarios, it could take a very long time to group the signatures on the basis of ports and thus increasing the entire time taken by the engine to start by a huge factor.
- Status changed from Assigned to In Review
- Related to Bug #6414: detect-engine/port: recursive DetectPortInsert calls are expensive added
- Status changed from In Review to Resolved
- Label Needs backport to 7.0 added
- Label deleted (
Needs backport to 7.0)
- Related to Bug #6843: detect/port: port ranges are incorrect when a port is single as well as a part of range added
- Related to Bug #6881: detect/port: port grouping does not happen correctly if gap between a single and range port added
- Related to Bug #6896: detect/port: upper boundary ports are not correctly handled added
- Related to Bug #2908: ip only rules cause suricata to take 17 minutes to start added
- Status changed from Resolved to Closed
Also available in: Atom
PDF