[Oisf-users] Extracting Packet Header + Payload

[Korodev]

Hi Eric,

Thanks for the great response. So what would be the intended use case
of the packet option?

After trawling through the list archives, I realize I'm not the first
person to ask so maybe the documentation could be a bit clearer on
what the packet and payload options actually do and do not provide.

Cheers,

\\korodev


On Thu, Apr 19, 2018 at 5:13 PM, Eric Leblond <eric at regit.org> wrote:
> 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>