"pcap_cnt" is not accurate on TCP streams

Help
1

I am trying to find the original packet that triggered Suricata’s alert.

From the eve.json, I extracted the pcap_cnt and pcap_filename for the relevant alert.
When I open the relevant pcap_filename and search for the packet number (as described in the “pcap_cnt”), most of the time I’ll get a packet that makes sense it triggered the alert.

However, on TCP streams, it’s quite the opposite. the “pcap_cnt” is not referring to the packet which triggered the alert. Sometimes it seems, the “pcap_cnt” referees to the packet within the same stream as the packet triggered the alert.

Is there any option to log the original packet which triggered the alert?

INFO:

Suricata - tested on version 6.0.9 and 7.0.0-beta
Suricata command - “suricata -r pcap.pcap -k none”

2

Usual difference comes from the fact that Suricata by default acts on “acked data”

So if you have a signature like alert http any any -> any any (http.uri; content: "toto";)
And have a pcap with

  • p1 from client : GET /toto HTTP/1.1
  • p2 from server : ack p1
  • p3 from client : new request

You will get alert on p3 :

  • on p1 Suricata does not process the data because it has not been acked, so no alert
  • on p2 Suricata does the processing, but there is no match as p2 is from server to client and http.uri keyword will only match on client to server
  • on p3, Suricata has processed the data, and the direction is right, so there is a match
2 Likes
3

See Bug #3480: EVE JSON - Incorrect Packet Logged - Suricata - Open Information Security Foundation

1 Like