Bug #608
closedengine address parsing issue with negation
Added by Anoop Saldanha over 11 years ago. Updated almost 2 years ago.
Description
Address [192.168.0.0/16,!192.168.1.0/24,192.168.1.1] is parsed as
192.168.0.0 - 192.168.0.255, 192.168.2.0-192.168.255.255
instead of
192.168.0.0 - 192.168.0.255, 192.168.1.1 - 192.168.1.1, 192.168.2.0 - 192.168.255.255
Issue comes up when negated addresses are mixed with non-negated addresses.
Updated by Victor Julien over 11 years ago
- Target version changed from 1.4beta2 to 1.4beta3
Updated by Victor Julien over 11 years ago
- Target version changed from 1.4beta3 to 1.4rc1
Updated by Anoop Saldanha over 11 years ago
- Target version changed from 1.4rc1 to 1.4beta2
The fix for #599(https://github.com/inliniac/suricata/pull/223) exposes this bug, which fails 2 unittests(now disabled).
Unittests would be renabled when we fix this bug.
Updated by Victor Julien over 11 years ago
- Target version changed from 1.4beta2 to 2.0rc2
Updated by Victor Julien over 10 years ago
- Target version changed from 2.0rc2 to 2.0rc1
Updated by Victor Julien about 10 years ago
- Target version changed from 2.0rc1 to 2.0.1rc1
Updated by Victor Julien almost 10 years ago
- Assignee changed from Anoop Saldanha to OISF Dev
- Target version changed from 2.0.1rc1 to 2.0.2
Updated by Victor Julien almost 10 years ago
- Target version changed from 2.0.2 to 2.0.3
Updated by Victor Julien over 9 years ago
- Target version changed from 2.0.3 to 2.0.4
Updated by Victor Julien over 9 years ago
- Target version changed from 2.0.4 to 3.0RC2
Updated by Victor Julien over 8 years ago
- Target version changed from 3.0RC2 to 70
Updated by Philippe Antoine almost 5 years ago
That would make the list order dependent which is not the case right now.
So, I do not know if the expected behavior will be clear to everyone.
Should we go for another syntax like
(192.168.0.0/16 - 192.168.1.0/24) + 192.168.1.1
Then we should issue warnings when we do not have enough parenthesis as operations are not commutative...
Updated by Andreas Herz over 4 years ago
Hmm we could force a syntax that requires all negation coming at the end so it's easier to parse and calculate?
Updated by Victor Julien over 4 years ago
- Target version changed from 70 to TBD
I don't think we can risk breaking existing setups/expectations.
Updated by Andreas Herz over 4 years ago
Would you suggest a more advanced parsing?
Updated by Victor Julien almost 2 years ago
- Status changed from New to Rejected
- Assignee changed from OISF Dev to Victor Julien
- Target version deleted (
TBD)
After further discussion and inspection, I think we can close this as things work as expected. We've implemented what Snort 2.7+ does:
"IPs, IP lists, and CIDR blocks may be negated with '!'. Negation is handled differently compared with Snort versions 2.7.x and earlier. Previously, each element in a list was logically OR'ed together. IP lists now OR non-negated elements and AND the result with the OR'ed negated elements."
(From: http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node16.html)
So essentially in the example [192.168.0.0/16,!192.168.1.0/24,192.168.1.1], we first OR the positive ranges/addresses:
192.168.0.0/16|192.168.1.1 = 192.168.0.0/16
Then we remove the negative range !192.168.1.0/24
Leaving 192.168.0.0 - 192.168.0.255, 192.168.2.0-192.168.255.255. This is the current behavior and is correct.