Suricata

I have a smaller testcase that shows the different alerts generated when reading the same pcap file with runmode single and runmode autofp. Additional alerts are output in single runmode (see the difference between single-6732-10298.sorted and autofp-6732-10298.sorted).

To run the testcases, install suricata in /usr/local/bin (default location) and run:

./test-one-file LLS-6732-10298.pcap single
./test-one-file LLS-6732-10298.pcap autofp

This generates two directories: single-results and autofp-results, that contain LLS-6732-10298.fast and LLS-6732-10298.sorted (strip off time-stamps from .fast and sort).

The files LLS-6732-10298.pcap were created from Lincoln Labs 1999 DDOS file by selecting the two flows between IPs 208.209.46.37 and 172.16.115.87 with ports 6732 and ports 10298. The other LLS- files are similar, with different subsets of ports.

Most interesting, LLS-6732.pcap by itself generates the same alerts in single and autofp, as does LLS-10298.pcap, only putting both flows in the same pcap file causes the problem. Note, flow 10298 comes after flow 6732 in the pcap files. I have not tried reordering the pcap files.

File LLS-208.209.46.37.pcap contains all the flows between IPs 208.209.46.37 and 172.16.115.87 and LLS-not-10298.pcap is the same except removing flow with port 10298. The former gives different alerts, the latter the same alerts.

This testing requires the patch to disable Detect Keywors by adding testing.detect config in suricata.yaml (see attached file).

Hi, we're closing this issue since there have been no further responses.
If you think this bug is still relevant, try to test it again with the
most recent version of suricata and reopen the issue. If you want to
improve the bug report please take a look at
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Reporting_Bugs

Disclosure : I had AI write up most all of this, with my guidance. All attached files are AI-generated (part of an AI pcap creation harness I'm working on using Flowsynth).

I got burned by this recently. Still present in 8.0.6 RELEASE. Attaching a minimal reproducer (suricata-992-repro.tar.gz).

The timestamp mechanism Anoop described in 2013 is directly observable, and the reproducer isolates it: two pcaps in one directory make the discontinuity explicit and controllable. Per the manpage, files read that way are "processed in order of modified time maintaining flow state between files", so a gap between captures becomes a gap in the engine's global clock.

Reproducer¶

Two pcaps, 14 packets total, one rule:

• flow-a.pcap -- an HTTP transaction whose response body carries a marker string. Well-formed (Content-Length matches the body), but the session is never closed: no FIN, no RST. This is ordinary for a truncated lab capture.
• flow-b.pcap -- an unrelated, non-matching HTTP transaction on a different source port, timestamped 1300s after flow A. Its only role is to advance the engine's packet-derived clock.
• test.rules -- one signature matching the marker via file_data / from_server.

Expected result: exactly 1 alert on every run.

./run.sh 500                    # default runmode
./run.sh 500 --runmode single   # control

Results¶

Suricata 8.0.6 RELEASE, stock /usr/local/etc/suricata/suricata.yaml (no tuning; flow-timeouts.tcp.established at its default of 600):

Roughly 1 run in 80 loses the alert. Note that at that rate a single 200-run batch comes back clean about 1 time in 10, so ./run.sh 500 or more is worth running before concluding it does not reproduce.

What happens on a failing run¶

Flow A is split into two flow records -- it is aged out mid-connection:

failing run (eve.json, flow A only):
  flow  state=established reason=timeout  pkts_ts=2 pkts_tc=1
  flow  state=new         reason=shutdown pkts_ts=2 pkts_tc=2
  (no http event, no alert)

passing run:
  http  status=200 length=47
  alert repro marker in response body
  flow  state=established reason=shutdown pkts_ts=4 pkts_tc=3

Flow A's seven packets span 6ms of capture time, so nothing in flow A can age it out. Eviction requires the clock to be at least 600s past its last packet, which means flow B's packets (1300s later) have already advanced the global clock while flow A's remaining packets are still in flight.

The consequence is that the response arrives at a flow that no longer exists. A new flow is created with no request in it, libhtp never builds a transaction (hence no http event and no response body), and the signature is never given anything to match against. The alert is not generated late -- it is not generated at all.

Why this may be worth reopening¶

Offline pcap replay is the basis for rule validation and regression testing, so a few percent of runs silently returning a different answer on identical input is difficult to design around. Neither workaround -- keeping capture timestamps within flow-timeouts.tcp.established of each other, or running single-threaded -- is documented, and you can only arrive at either by diagnosing the failure first. A warning when consecutive files in a directory run are separated by more than the relevant flow timeout would at least make the condition visible.