https://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022020-02-16T13:19:30ZOpen Information Security FoundationSuricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=152932020-02-16T13:19:30ZPeter Manevpetermanev@gmail.com
<ul></ul><p>I think it seems the packet logged should be packet 5 (not 7) as it is the ACK of the POST (packet 4). In IDS we act on acknowledged data.<br />Can you share the rule and try the latest master to see if there is any difference?</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=153062020-02-18T03:49:47ZEoin Miller
<ul></ul><p>Peter Manev wrote:</p>
<blockquote>
<p>I think it seems the packet logged should be packet 5 (not 7) as it is the ACK of the POST (packet 4). In IDS we act on acknowledged data.<br />Can you share the rule and try the latest master to see if there is any difference?</p>
</blockquote>
<p>Sure thing. Packet <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: DetectBytetestMatch: Error extracting 8 bytes of string data: 0 on web responses (Closed)" href="https://redmine.openinfosecfoundation.org/issues/4">#4</a> is the one that matches the rule (and ends up in the unified2 output attached as unified2.out) but the packet that is logged in the EVE output is Packet <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Unifed* File Rollover Causes Segmentation Fault (Closed)" href="https://redmine.openinfosecfoundation.org/issues/7">#7</a>:</p>
<p>Here is the rule we were using while testing:<br /><pre>
alert http any any -> any any (msg:"RAPID7 TEST TestHTTPPost - Up Galway"; flow:established,to_server; content:"POST"; http_method; content:"WhoDoYouSupport=UpGalway!"; http_client_body; sid:7777777; rev:1;)
</pre></p>
<p>I'll try it against current tomorrow to see if the behavior is the same tomorrow.</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=153592020-02-18T17:09:06ZEoin Miller
<ul></ul><p>Verified same behavior with release 5.0.2.</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=153612020-02-18T23:02:04ZJason Ishjason.ish@oisf.net
<ul></ul><p>The packet data found in unified2 is more like the "payload" option of eve - in unified2 the packet is rebuilt based on the payload, its not the actual packet. The main difference in eve payload being that we don't fake out the full packet like we do in unified2.</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=153622020-02-18T23:30:50ZEoin Miller
<ul></ul><p>Jason Ish wrote:</p>
<blockquote>
<p>The packet data found in unified2 is more like the "payload" option of eve - in unified2 the packet is rebuilt based on the payload, its not the actual packet. The main difference in eve payload being that we don't fake out the full packet like we do in unified2.</p>
</blockquote>
<p>Alrighty, this raises a few questions from our end:</p>
<ol>
<li>So are people supposed to be using '.payload' instead of '.packet'? </li>
<li>Should the value of '.packet' not be the packet that caused the match?</li>
</ol>
<p>From what I've been told by our team members, '.payload' seems to be the first up to 4k of the stream and doesn't appear to include packet headers. With unified2 on its way out, making sure that what is logged with EVE gives analysts what they need to triage alerting will become more important.</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=153632020-02-18T23:42:00ZJason Ishjason.ish@oisf.net
<ul></ul><p>So they payload should be the same as seen in unified2, minus the headers, as can pretty much be seen when you base64 decode the payload in the eve.json you provided. The rest of the details, like the addresses should be in the event itself. Is that not enough to triage on?</p>
<p>I'm just trying to point out that there is no less data with the loss of unified2, it just in a bit of a different format (which may not be idea in its own right, or not what people are used, etc).</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=153762020-02-19T21:41:37ZEoin Miller
<ul></ul><p>Jason Ish wrote in <a href="#note-6">#note-6</a>:</p>
<blockquote>
<p>So they payload should be the same as seen in unified2, minus the headers, as can pretty much be seen when you base64 decode the payload in the eve.json you provided. The rest of the details, like the addresses should be in the event itself. Is that not enough to triage on?</p>
<p>I'm just trying to point out that there is no less data with the loss of unified2, it just in a bit of a different format (which may not be idea in its own right, or not what people are used, etc).</p>
</blockquote>
<p>Did some more digging, I think the disconnect on our end was:</p>
<ol>
<li>Thinking that '.packet' was the packet that caused the alert, in full.</li>
<li>'.payload' only outputs up to the first 4k by default.</li>
</ol>
<p>By increasing the value for outputs -> eve-log -> types -> alert -> payload-buffer-size, we do see the same output as we would inside of unified2.</p>
It may be helpful to:
<ol>
<li>Increase default value for payload-buffer-size from 4k to 64k so that the full packet is in the eve output by default</li>
<li>Update the suricata.yaml comments for packet:</li>
</ol>
<p>From:<br /><pre>
# packet: yes # enable dumping of packet (without stream segments)
</pre><br />To:<br /><pre>
# packet: yes # enable dumping of packet headers (without stream segments/data/payload)
</pre></p>
<p>It does seem a bit weird still that the value for '.packet' doesn't match the headers for the packet that contained the data payload that matched the rule.</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=209552021-10-13T19:28:28ZPhilippe Antoine
<ul><li><strong>Affected Versions</strong> <i>6.0.3</i> added</li></ul><p>I have been investigating this.</p>
<p>It seems to me the real bug is that we run detection not as early as we can (and should)<br />On pcap UpGalway.pcap, the signature <code>alert http any any -> any any (msg:"RAPID7 TEST TestHTTPPost - Up Galway"; http.method; content:"POST"; sid:7777777;)</code> produces an alert at packet 7.<br />That is why we see this packet 7 in eve.json</p>
<blockquote>
<p>I think it seems the packet logged should be packet 5 (not 7) as it is the ACK of the POST (packet 4). In IDS we act on acknowledged data.</p>
</blockquote>
<p>Suricata indeed does the app-layer parsing on packet 5.<br />But then, when it runs <code>DetectRun</code> with only the packet direction, so we do not match this rule because the rule is to server and the packet 5 is to client.<br />Packet 7 is the first packet in the direction to server after we parsed the data.<br />That is why alert happens on packet 7.</p>
<p>One workaround is to use <code>stream.inline=true</code> to get alert at packet 4</p>
<p>What could be the fix ?<br />- Could we take the rules group in the opposing direction when it is TCP and not inline ?<br />No because packet rules such as with <code>tcp.hdr</code> have the right direction<br />(We need also to keep app-layer protocols supported by both TCP and UDP working)<br />- Could we run <code>DetectRun</code> twice on both directions ?<br />Maybe, but it looks expensive in terms of performance, and kind of annihilating the benefit of the rules grouping...<br />Merging TCP rules groups for both directions would also diminish the benefit of the rules grouping I guess...<br />- Could we change the rules group where we put these kind of rules (over TCP, app-layer, when not inline) ?<br />Yes but it is not enough :<br /> + DetectBufferMpmRegistery have a direction as well which needs to be consistent with one in the sig group<br /> + We also need to revert <code>flow_flags</code> in <code>DetectRunTx</code> so that we get the right transaction progress (the one in the right direction) and so that DetectEngineAppInspectionEngine's direction is consistent as well<br /> + Other things that I did not notice yet...</p>
<p>This seems to be require deep design change...<br />Thoughts ?</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=227602022-03-16T16:45:13ZJason Ishjason.ish@oisf.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-4 priority-default" href="/issues/1380">Feature #1380</a>: JSON and Unified2 output "payload" does not contain full (or real in the case of Unified2) packets for session</i> added</li></ul> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=227622022-03-16T16:47:15ZJason Ishjason.ish@oisf.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-4 priority-default closed" href="/issues/2429">Bug #2429</a>: TCP-session and wrong alert timestamp </i> added</li></ul> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=227642022-03-16T17:23:11ZJason Ishjason.ish@oisf.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-2 priority-4 priority-default" href="/issues/2069">Bug #2069</a>: logging: payload may not represent traffic the generated alert (eve and unified2)</i> added</li></ul> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=227652022-03-16T17:24:30ZJason Ishjason.ish@oisf.net
<ul></ul><p>Just linking up some related issues as I think its worth a discussion and/or documentation.</p>
<p>- Related to <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: JSON and Unified2 output "payload" does not contain full (or real in the case of Unified2) packet... (New)" href="https://redmine.openinfosecfoundation.org/issues/1380">#1380</a>, as I think it relates to the discussion of payload vs packet.<br />- Related to <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: TCP-session and wrong alert timestamp (Rejected)" href="https://redmine.openinfosecfoundation.org/issues/2429">#2429</a> as this shows the discrepancy in time between the triggering packet and the timestamp in the alert which is also seen in EVE.</p>
<p>From my own observations, in IDS mode:<br />- The packet logged is the next packet in the stream. You won't find the alerting data in this packet and often the payload in this packet is empty.<br />- The timestamp of the alert does not align with the packet that contains the triggering data, but instead some packet later.<br />- The payload does contain the triggering data.</p>
<p>In IPS mode:<br />- The packet logged DOES contain the alert triggering data. If the data spans multiple packets, the packet logged is the completing packet (which I think is expected behaviour). So you may not see all the data leading to an alert to trigger, but thats OK, at least the packet logged correlates to the input.<br />- The alert timestamp does match the packet timestamp.<br />- They payload is similar to that in IDS mode, you can see the re-assembled payload leading to the alert to trigger.</p>
<p>Note that there are occurrences where the payload logged may not include the triggering data, as seen in issue <a class="issue tracker-1 status-2 priority-4 priority-default" title="Bug: logging: payload may not represent traffic the generated alert (eve and unified2) (Assigned)" href="https://redmine.openinfosecfoundation.org/issues/2069">#2069</a>. However, I believe this affects IDS mode only, and not IPS mode as detection is run sooner in IPS mode.</p>
<p>Ideally what is logged for alerts should be the same between IDS and IPS mode. Perhaps even going as far as removing <code>packet</code> from the default config as it has no value in IDS deployments. Even them it would be nice if the timestamp was correct for correlations against full packet capture systems.</p> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=255482022-11-17T15:45:11ZJason Ishjason.ish@oisf.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-4 priority-default" href="/issues/2281">Feature #2281</a>: tcp stream: simpler IDS handling of overlap evasions</i> added</li></ul> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=255492022-11-17T15:45:59ZJason Ishjason.ish@oisf.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-6 status-1 priority-4 priority-default" href="/issues/5690">Documentation #5690</a>: Document the differences between IPS and IDS mode.</i> added</li></ul> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=289442023-06-30T13:39:49ZPhilippe Antoine
<ul><li><strong>Assignee</strong> set to <i>OISF Dev</i></li></ul> Suricata - Bug #3480: EVE JSON - Incorrect Packet Loggedhttps://redmine.openinfosecfoundation.org/issues/3480?journal_id=323802024-02-07T16:49:28ZJason Ishjason.ish@oisf.net
<ul><li><strong>Affected Versions</strong> <i>git master</i> added</li></ul>