[Oisf-devel] Flow inspection
Victor Julien
victor at inliniac.net
Thu Feb 28 10:50:23 UTC 2013
On 02/26/2013 07:49 PM, עמית קליינמן wrote:
> I am piggybacking here on earlier posts by Jörg Vehlow.
> It looks as I am trying to accomplish a similar task - inspecting
> stream of TCP packets that belong to a certain TCP flow
> (a flow is shared between all packets with the same 5 tuple: (protocol,
> src, dst, sp, dp)).
>
> For example:
> For an HTTP session with one request there will be two messages, the
> request and the response.
> If there is another request in the http session it will have four
> messages. (Request, response, request, response)
> The order in which the messages appear is important. Together with the
> payload of a message, the time of the first
> frame and direction should be saved.
>
> I am actually inspecting several such TCP flows, e.g., I need to device
> each of the TCP flow into messages while
> keeping the order the messages were meant to be, when they were sent.
>
> Jörg mentioned he "hooked into the Applayer parser, managed the flags
> that control the behavior of the reassembler himself
> and buffered the data to be able to feed it to the applayer parser the
> way it was before he hooked into"
>
> I wonder if this is the best way to implement this mechanism on top of
> Suricata. If so can someone elaborate on that please?
> Is there a better alternative? Some examples can be very helpful.
If you care about HTTP, hooking into the HTTP parser would be easiest.
The problem with hooking into the stream engine directly is that it's
not protocol aware. Due to lost packets (and possibly other anomalies)
it's possible that 2+ requests or responses are sent to the app layer
parser at once. There we can then distinguish between them while parsing
the data.
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
More information about the Oisf-devel
mailing list