Optimization #6792: detect/port: port grouping is quite slow in worst cases - Suricata - Open Information Security Foundation

Custom queries

8.0.0 Stories
Good First Issues
OISF community
Open Doc tasks

Actions

Copy link

Optimization #6792

closed

SB SB

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

Optimization #6792: detect/port: port grouping is quite slow in worst cases

Added by Shivani Bhardwaj about 2 years ago. Updated almost 2 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Shivani Bhardwaj

Target version:

8.0.0-beta1

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 (0 open — 3 closed)

Optimization #6795: detect/port: PortGroupWhitelist fn takes a lot of processing time	Closed	Victor Julien	Actions
Optimization #6829: detect/port: PortGroupWhitelist fn takes a lot of processing time (7.0.x backport)	Closed	Shivani Bhardwaj	Actions
Optimization #6830: detect/port: port grouping is quite slow in worst cases (7.0.x backport)	Closed	Shivani Bhardwaj	Actions

Related issues 5 (0 open — 5 closed)

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