Bug #4685
closeddetect: too many prefilter engines lead to FNs
Description
Fix for QA ticket #4672
Bad int handling leads to missed inspection when prefilter engine list gets too long.
Files
Updated by Victor Julien about 3 years ago
- File test.rules test.rules added
This is turning out to be a more complex issue. While the initial analysis is correct for a full ET ruleset, the issue is actually worse if a ruleset uses more keywords. Especially if transforms are added, its easy to exceed the 63 bits (1 is reserved) used for tracking which tx prefilter engines have run.
I'm attaching a example rulefile that leads to the local_id
getting to 160 in 6.0.x and 100 in 5.0.x. The difference is due to duplicate engines for http1/http2 in 6.0.x.
Some thoughts on addressing this:
- the most direct way of fixing this is to expand the bit space. However this will be fairly complex due to how the data structure is ultimately in AppLayerTxData
in Rust.
- perhaps we can track not per engine, but per 'progress' value. At a certain progress value all relevant engines should run so maybe it would be sufficient to track what ran based on this value.
- not really a solution but still a thing to state: we need to untangle the engines list by alproto somehow, as currently we skip most engines in the list due to them not being for our alproto.
Updated by Jeff Lucovsky about 3 years ago
- Copied to Bug #4687: detect: too many prefilter engines lead to FNs added
Updated by Jeff Lucovsky about 3 years ago
- Copied to Bug #4688: detect: too many prefilter engines lead to FNs added
Updated by Victor Julien about 3 years ago
- Status changed from In Progress to Closed