Project

General

Profile

Actions

Optimization #6792

open

detect/port: port grouping is quite slow in worst cases

Added by Shivani Bhardwaj 3 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

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.


Subtasks 3 (3 open0 closed)

Optimization #6795: detect/port: PortGroupWhitelist fn takes a lot of processing timeResolvedVictor JulienActions
Optimization #6829: detect/port: PortGroupWhitelist fn takes a lot of processing time (7.0.x backport)In ReviewShivani BhardwajActions
Optimization #6830: detect/port: port grouping is quite slow in worst cases (7.0.x backport)In ReviewShivani BhardwajActions

Related issues 5 (4 open1 closed)

Related to Suricata - Bug #6414: detect-engine/port: recursive DetectPortInsert calls are expensiveResolvedShivani BhardwajActions
Related to Suricata - Bug #6843: detect/port: port ranges are incorrect when a port is single as well as a part of rangeResolvedShivani BhardwajActions
Related to Suricata - Bug #6881: detect/port: port grouping does not happen correctly if gap between a single and range portResolvedShivani BhardwajActions
Related to Suricata - Bug #6896: detect/port: upper boundary ports are not correctly handledResolvedShivani BhardwajActions
Related to Suricata - Bug #2908: ip only rules cause suricata to take 17 minutes to startClosedActions
Actions

Also available in: Atom PDF