Bug #6307
openPacket loss or client connection drop causes delayed detection on HTTP rules
Description
If TCP stream is dropped deliberately by the client or by packet loss in a HTTP connection after getting server response, the alert will not be fired until flow timeout even though Suricata should have all necessary data.
Packet flow leading to the issue:
Client -> Server SYN Server -> Client SYN-ACK Client -> Server ACK Client -> Server PSH-ACK: HTTP GET /foo Server -> Client PSH-ACK: HTTP 404 <packet loss or deliberate blackout from client starts here> Client -> Server ACK Client -> Server FIN-ACK Server -> Client FIN-ACK Client -> Server ACK
Observations:
If client stops responding to server on TCP level after receiving the the response to the HTTP query then suricata seems to wait for the flow timeout. I think there is no reason to delay the alert after the server response is seen so some logic seems to be needlessly waiting for the ACK from client here.
Reproducer:
I attached 2 pcaps and a test rule. With these a reproducer can be done by running suricata against a dummy interface and tcpreplay. Reproducing needs a live interface because if suricata exits at pcap end the flows are purged and the alert is emitted.
- Run in terminal A
[Save attached http_test.rules and pcaps to /tmp] ip link add dev dummy0 type dummy ip link set up dev dummy0 suricata --af-packet=dummy0 -S /tmp/http_test.rules
- Run in terminal B:
tcpreplay -i dummy0 /tmp/http_test_full.pcap
- Suricata should log the alert normally.
- Run in terminal A:
[ctrl-c and restart to ensure clean state for suricata] suricata --af-packet=dummy0 -S /tmp/http_test.rules
- Run in terminal B:
tcpreplay -i dummy0 /tmp/drop_all_before_ack.pcap
- Suricata will not immediately log the alert but will log it after flow timeout OR immediately on ctrl-c of the process
Files
No data to display