[Oisf-users] Extracting Packet Header + Payload

[Eric Leblond]

Hi,

On Thu, 2018-04-19 at 12:19 -0500, Korodev wrote:
> Hi all,
> 
> As we transition from unified2 to eve logs, I'm having trouble
> extracting the hex dump of the full packet that tripped an alert.
> Based on the documentation, it looks like I'd need to enable packet
> (header) and payload logging, decode them, and put them together.
> 
> We're currently testing w/ Suricata 4.1 Beta and have some basic test
> signatures to catch GET requests to specific domains. However, I'm
> seeing some odd behaviour where the "packet" field is logging the
> header information for a different packet in the stream. For example
> in the alert event JSON, my payload field contains the expected
> encoded GET request, but the the "packet" field contains the encoded
> packet header for a different packet in the stream, which means
> certain properties like the TCP flags and packet size are incorrect.
> 
> 1. Is this expected behaviour?

Yes. In most cases (tcp or application layer level signature) the
packet is the packet that trigger the analysis of the stream cause the
alert. So it does not contain for sure the interesting data and in most
cases (IDS) it is in the other way (Suricata analyses stream after data
have been acked).

> 2. Is there a better way to extract/log the full packet that tripped
> an alert?

No because it does not really have a meaning (see answer to 3.). What
could make sense would be to have a pcap with the stream that did
trigger the alert.

> 3. Is there an easy way to extract packet header properties (e.g TCP
> flags, packet size)?

No and it can't be done in most alerts as they are generated following
a reconstruction done by Suricata. For instance, Suricata can alert
because there is a match inside the gzipped body of an HTTP request
where IP packet are fragmented (to evade). The (individual) packet does
not make really sense here.

BR,
-- 
Eric Leblond <eric at regit.org>