Project

General

Profile

Actions

Bug #1833

closed

Transaction can be logged before stream reassembly and parsing are complete

Added by WGH WGH about 6 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

I believe bug #1433 can still be observed as of recent Suricata version.

The attached .pcap-file contains a HTTP session with two request-response pairs.
The conversation goes as follows:
  • (omitted)
  • Client: ACK for previous response, (request)
  • Server: ACK, (response)
  • Server: FIN, ACK -- the server initiates TCP close as soon as response it sent, which is actually somewhat rare in HTTP
  • Client: FIN, ACK
  • Server: ACK

I've cloned both Suricata and libhtp directly from Git, and can reliably reproduce it.

In order to do this, you'll need to enable extended HTTP logging in default suricata.yaml config, and replay the attached dump like this. For some reason I was unable to reproduce it with feeding pcaps to Suricata directly or via dummy interface, though.

tcprewrite --seed=$RANDOM --fixcsum --infile 2reqs.pcap --outfile - | tcpreplay --intf1=lo -

Additionally, you should lower af-packet thread count to one to avoid another possible bug where both responses will be lost. I'll report that one once I have reliable test case for it (unless it's actually the same bug as this one).

06/29/2016-20:50:01.383552 localhost [**] /foo [**] <useragent unknown> [**] <no referer> [**] GET [**] HTTP/1.1 [**] 404 [**] 169 bytes [**] 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:43762 -> 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:80
06/29/2016-20:50:01.394696 localhost [**] /foo [**] <useragent unknown> [**] <no referer> [**] GET [**] HTTP/1.1 [**] <no status> [**] 0 bytes [**] 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:43762 -> 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:80

Notice that Suricata is missing the response. There's no status and no response body size for the second request.


Files

2reqs.pcap (2.01 KB) 2reqs.pcap WGH WGH, 06/29/2016 12:41 PM
Actions #1

Updated by WGH WGH about 6 years ago

FWIW, my kernel is 4.6.2, and the bug is reproducible on 3.13.0-32 as well.

Actions #2

Updated by Andreas Herz about 6 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #3

Updated by Jason Ish about 6 years ago

WGH WGH: Are you able to rety with 3.1.1? There have been some changes with respect to transaction logging.

Actions #4

Updated by WGH WGH about 6 years ago

I've just checked, it certainly happens as of ec602089a (tagged suricata-3.1.1).

Actions #5

Updated by Andreas Herz over 3 years ago

Does this still occur with most recent Suricata?

Actions #6

Updated by Andreas Herz over 3 years ago

  • Status changed from New to Closed

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

Actions

Also available in: Atom PDF