Project

General

Profile

Actions
Copy link

Bug #608

closed

engine address parsing issue with negation

Added by Anoop Saldanha over 11 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Victor Julien
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

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.

Actions
Copy link
 #1

Updated by Victor Julien over 11 years ago

  • Target version changed from 1.4beta2 to 1.4beta3
Actions
Copy link
 #2

Updated by Victor Julien over 11 years ago

  • Target version changed from 1.4beta3 to 1.4rc1
Actions
Copy link
 #3

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.

Actions
Copy link
 #4

Updated by Victor Julien over 11 years ago

  • Target version changed from 1.4beta2 to 2.0rc2
Actions
Copy link
 #5

Updated by Victor Julien over 10 years ago

  • Target version changed from 2.0rc2 to 2.0rc1
Actions
Copy link
 #6

Updated by Victor Julien about 10 years ago

  • Target version changed from 2.0rc1 to 2.0.1rc1
Actions
Copy link
 #7

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
Actions
Copy link
 #8

Updated by Victor Julien almost 10 years ago

  • Target version changed from 2.0.2 to 2.0.3
Actions
Copy link
 #9

Updated by Victor Julien over 9 years ago

  • Target version changed from 2.0.3 to 2.0.4
Actions
Copy link
 #10

Updated by Victor Julien over 9 years ago

  • Target version changed from 2.0.4 to 3.0RC2
Actions
Copy link
 #11

Updated by Victor Julien over 8 years ago

  • Target version changed from 3.0RC2 to 70
Actions
Copy link
 #12

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...

Actions
Copy link
 #13

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?

Actions
Copy link
 #14

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.

Actions
Copy link
 #15

Updated by Andreas Herz over 4 years ago

Would you suggest a more advanced parsing?

Actions
Copy link
 #16

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.

Actions
Copy link

Also available in: Atom PDF