Project

General

Profile

Actions
Copy link

Bug #608

closed
AS VJ

engine address parsing issue with negation

Bug #608: engine address parsing issue with negation

Added by Anoop Saldanha over 13 years ago. Updated almost 4 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.

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #1

  • Target version changed from 1.4beta2 to 1.4beta3

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #2

  • Target version changed from 1.4beta3 to 1.4rc1

AS Updated by Anoop Saldanha over 13 years ago Actions
Copy link
 #3

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

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #4

  • Target version changed from 1.4beta2 to 2.0rc2

VJ Updated by Victor Julien over 12 years ago Actions
Copy link
 #5

  • Target version changed from 2.0rc2 to 2.0rc1

VJ Updated by Victor Julien about 12 years ago Actions
Copy link
 #6

  • Target version changed from 2.0rc1 to 2.0.1rc1

VJ Updated by Victor Julien almost 12 years ago Actions
Copy link
 #7

  • Assignee changed from Anoop Saldanha to OISF Dev
  • Target version changed from 2.0.1rc1 to 2.0.2

VJ Updated by Victor Julien almost 12 years ago Actions
Copy link
 #8

  • Target version changed from 2.0.2 to 2.0.3

VJ Updated by Victor Julien almost 12 years ago Actions
Copy link
 #9

  • Target version changed from 2.0.3 to 2.0.4

VJ Updated by Victor Julien over 11 years ago Actions
Copy link
 #10

  • Target version changed from 2.0.4 to 3.0RC2

VJ Updated by Victor Julien over 10 years ago Actions
Copy link
 #11

  • Target version changed from 3.0RC2 to 70

PA Updated by Philippe Antoine almost 7 years ago Actions
Copy link
 #12

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

AH Updated by Andreas Herz over 6 years ago Actions
Copy link
 #13

Hmm we could force a syntax that requires all negation coming at the end so it's easier to parse and calculate?

VJ Updated by Victor Julien over 6 years ago Actions
Copy link
 #14

  • Target version changed from 70 to TBD

I don't think we can risk breaking existing setups/expectations.

AH Updated by Andreas Herz over 6 years ago Actions
Copy link
 #15

Would you suggest a more advanced parsing?

VJ Updated by Victor Julien almost 4 years ago Actions
Copy link
 #16

  • 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: PDF Atom