https://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022012-10-29T07:50:24ZOpen Information Security FoundationSuricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=24042012-10-29T07:50:24ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>1.4beta2</i> to <i>1.4beta3</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=25032012-11-14T12:08:57ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>1.4beta3</i> to <i>1.4rc1</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=25352012-11-26T12:16:08ZAnoop Saldanhaanoopsaldanha@gmail.com
<ul><li><strong>Target version</strong> changed from <i>1.4rc1</i> to <i>1.4beta2</i></li></ul><p>The fix for <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: IP Rules Failing "not" matching (Closed)" href="https://redmine.openinfosecfoundation.org/issues/599">#599</a>(<a class="external" href="https://github.com/inliniac/suricata/pull/223">https://github.com/inliniac/suricata/pull/223</a>) exposes this bug, which fails 2 unittests(now disabled).</p>
<p>Unittests would be renabled when we fix this bug.</p> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=25422012-11-27T03:02:48ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>1.4beta2</i> to <i>2.0rc2</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=39142013-12-12T11:31:29ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>2.0rc2</i> to <i>2.0rc1</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=40162014-02-06T05:05:56ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>2.0rc1</i> to <i>2.0.1rc1</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=43092014-05-12T06:25:33ZVictor Julienvictor@inliniac.net
<ul><li><strong>Assignee</strong> changed from <i>Anoop Saldanha</i> to <i>OISF Dev</i></li><li><strong>Target version</strong> changed from <i>2.0.1rc1</i> to <i>2.0.2</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=43912014-06-24T04:11:34ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>2.0.2</i> to <i>2.0.3</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=45182014-08-06T07:41:44ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>2.0.3</i> to <i>2.0.4</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=46122014-09-22T05:59:34ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>2.0.4</i> to <i>3.0RC2</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=56372015-11-08T04:02:15ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>3.0RC2</i> to <i>70</i></li></ul> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=124012019-06-03T13:48:37ZPhilippe Antoine
<ul></ul><p>That would make the list order dependent which is not the case right now.<br />So, I do not know if the expected behavior will be clear to everyone.</p>
<p>Should we go for another syntax like<br />(192.168.0.0/16 - 192.168.1.0/24) + 192.168.1.1<br />Then we should issue warnings when we do not have enough parenthesis as operations are not commutative...</p> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=137152019-09-23T21:57:00ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Hmm we could force a syntax that requires all negation coming at the end so it's easier to parse and calculate?</p> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=137312019-09-24T10:15:34ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> changed from <i>70</i> to <i>TBD</i></li></ul><p>I don't think we can risk breaking existing setups/expectations.</p> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=137582019-09-24T20:20:28ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Would you suggest a more advanced parsing?</p> Suricata - Bug #608: engine address parsing issue with negationhttps://redmine.openinfosecfoundation.org/issues/608?journal_id=235322022-05-16T07:49:38ZVictor Julienvictor@inliniac.net
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Rejected</i></li><li><strong>Assignee</strong> changed from <i>OISF Dev</i> to <i>Victor Julien</i></li><li><strong>Target version</strong> deleted (<del><i>TBD</i></del>)</li></ul><p>After further discussion and inspection, I think we can close this as things work as expected. We've implemented what Snort 2.7+ does:</p>
<blockquote>
<p>"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."</p>
</blockquote>
<p>(From: <a class="external" href="http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node16.html">http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node16.html</a>)</p>
<p>So essentially in the example <code>[192.168.0.0/16,!192.168.1.0/24,192.168.1.1]</code>, we first OR the positive ranges/addresses:</p>
<p><code>192.168.0.0/16|192.168.1.1 = 192.168.0.0/16</code></p>
<p>Then we remove the negative range <code>!192.168.1.0/24</code></p>
<p>Leaving <code>192.168.0.0 - 192.168.0.255, 192.168.2.0-192.168.255.255</code>. This is the current behavior and is correct.</p>