https://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022017-12-18T15:58:23ZOpen Information Security FoundationSuricata - Feature #2343: Add "flush" command to unix sockethttps://redmine.openinfosecfoundation.org/issues/2343?journal_id=92202017-12-18T15:58:23ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>Assignee</strong> set to <i>OISF Dev</i></li><li><strong>Target version</strong> set to <i>TBD</i></li></ul> Suricata - Feature #2343: Add "flush" command to unix sockethttps://redmine.openinfosecfoundation.org/issues/2343?journal_id=92442017-12-19T02:36:20ZVictor Julienvictor@inliniac.net
<ul></ul><p>Chris, could you describe your scenario here again? Reading it here again it doesn't really make sense to me anymore. Even without packets a live instance of Suricata should do its flow cleaning w/o issues.</p> Suricata - Feature #2343: Add "flush" command to unix sockethttps://redmine.openinfosecfoundation.org/issues/2343?journal_id=94362018-02-06T04:45:29ZChris Knott
<ul><li><strong>File</strong> <a href="/attachments/1477">test.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1477/test.pcap">test.pcap</a> added</li><li><strong>File</strong> <a href="/attachments/1478">test_missing_end10.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1478/test_missing_end10.pcap">test_missing_end10.pcap</a> added</li><li><strong>File</strong> <a href="/attachments/1479">test_end10.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1479/test_end10.pcap">test_end10.pcap</a> added</li><li><strong>File</strong> <a href="/attachments/1480">single_packet.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1480/single_packet.pcap">single_packet.pcap</a> added</li><li><strong>File</strong> <a href="/attachments/1481">eve_test2.json</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1481/eve_test2.json">eve_test2.json</a> added</li><li><strong>File</strong> <a href="/attachments/1482">eve_test3.json</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1482/eve_test3.json">eve_test3.json</a> added</li></ul><p>I've tested some scenarios in order to understand the behavior.</p>
<p>First I want to explain my test setup:<br />In order to get a reproducible result I am using a dummy network interface (dummy kernel module) without any IP configuration ... so the interface is completely silent and only sends data that I want it so send:</p>
<p>dummy: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500<br /> ether 52:54:00:7e:27:af txqueuelen 1000 (Ethernet)<br /> RX packets 0 bytes 0 (0.0 B)<br /> RX errors 0 dropped 0 overruns 0 frame 0<br /> TX packets 0 bytes 0 (0.0 B)<br /> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0</p>
<p>In order to get data onto the interface I am using prerecorded PCAP files and tcpreplay (e.g. "tcpreplay --intf1=dummy /home/christoph/single_packet.pcap"). Suricata listens to the dummy interface and ignores checksum errors recorded in the PCAP files ("suricata -i dummy -k none").</p>
<p>My findings:</p>
<p>Test 1: Sending a complete flow at once (file: test.pcap) ... all information was inside the eve.json file. So no findings there.</p>
<p>Test 2: I was curious what happens if I send the content of the file in chunks (keeping all flow timeout values on default values in the configuration). So the second test was: sending the beginning of the flow (file: test_missing_end10.pcap) ... wait a bit (more than 10 minutes ... so all timeouts should hit) ... and send the end of the flow (file: test_end10.pcap). Surprisingly to flow did not timeout after the 10 minutes that I would have expected. Instead it timed out after sending the second part (file: eve_test2.json).</p>
<p>Test 3: My question was now: What happens if I send the beginning of the flow (file: test_missing_end10.pcap) ... wait a bit (more than 10 minutes ... so all timeouts should hit) ... and send another packet of a different flow (file: single_packet.pcap). Also after sending the single packet the original flow timed out (file: eve_test3.json).</p>
<p>So it seems for cleaning up a flow (and sending the flow information to the eve.json file) you need a network packet to arrive at the interface (seems that the timeout checks for flows are done when receiving a packet). If the network packet flow suddenly stops no cleanup can be done any more. I don't know if this was done intentionally?</p> Suricata - Feature #2343: Add "flush" command to unix sockethttps://redmine.openinfosecfoundation.org/issues/2343?journal_id=139572019-09-27T08:17:22ZVictor Julienvictor@inliniac.net
<ul></ul><p>This is not intentional, no. Is this still reproducible? We've fixed some bugs with how packets are handled at flow timeout.</p>