[Snort-devel] HTTP Reassembly issue PAF enabled

Parmendra Pratap parmendra.pratap at ...398...
Fri Apr 5 19:14:06 EDT 2013


Brilliant - Thanks Russ normalization on tcp sorts this out.
Just a a small note - I used load_mode=passive.

So if I go it right with normalization on , reverse Ack is not awaited for in S5 prior to flushing , rest is same and PAF still works as expected to for supported protocols/preprocessors ?

Also , is there at all a flip side to running snort in "forced" inline mode on top pcap like this, performance wise may be?

Thanks
Parmendra


________________________________
 From: Russ Combs <rcombs at ...402...>
To: Parmendra Pratap <parmendra.pratap at ...398...> 
Cc: "snort-devel at lists.sourceforge.net" <snort-devel at lists.sourceforge.net> 
Sent: Friday, 5 April 2013 5:15 PM
Subject: Re: [Snort-devel] HTTP Reassembly issue PAF enabled
 
On Fri, Apr 5, 2013 at 11:56 AM, Parmendra Pratap
<parmendra.pratap at ...398...> wrote:
> Hi Hui
>
> Thanks again for a quick response.
>
> Have tried -Q flag , but since I am using Pcap DAQ it fails to start with -Q
> set.
> However it does start wiith --test-inline mode , which I assume works no
> different from -Q except that drops are not enabled.

Actually, normalizations are not enabled in that case.  You should see
something like this in your startup output:

WARNING: tcp normalizations disabled because not inline.

Try running with:

--daq dump --daq-var load-mode=read-file -Q

> My snort.conf does have preprocessor normalize_tcp: ips have set.
>
> But even with the above set up I can still replicate the same issue related
> to incorrect tcp flags.
> As I said before , I think it seems like a matter of setting the tcp header
> of the last packet that completes the PDU inside Packet->tcph->th_flags in
> the s5 preprocessor when doing a PAF based flushing.
> I can see that the direction i.e. sourceIP/port and destIP/port being
> reversed for the same reason in the Packet struct when doing a reassembly
> based flushing from s5.
>
> Thanks
> Parmendra
>
> __________________________________________________________________________
>
> Hi Parmendra,
>
> To be clear, you must use IPS mode to get what you want, so you need to
> 1) use -Q  when you run snort
> 2) Enable Normalization for TCP:
>
> preprocessor normalize_tcp: ips
>
> Best,
> Hui.
> On 04/04/2013 08:25 AM, Parmendra Pratap wrote:
>> Hi Hui
>> Thanks for a quick reply.
>> I tried the use case with Snort 2.9.4.5.
>> Does not make a difference.
>> Issue is still replicable with the steps outlined in my root email.
>> This is what I think is going on , based on few tests and source
>> lookups <excuse my newbieness if it reflects anywhere below :) >-
>> Stream5 reassembly does not tag a packet as complete PDU until it
>> recieves subsequent ack gainst the packet no matter wheter or not the
>> packet actually holds complete PDU  (in this case HTTP) or not.
>> With PAF enabled this prevents the URI Bufs from being created and
>> inspected in HTTP inspect module until the next packet arrives (ie ack
>> against the original packet that contained the HTTP req).
>> When the HTTP inspect URI Bufs based match fires, with PAF ON,  its
>> always(mostly?) when the ack on reverse direction is received.
>> The spo_alert* modules simply uses the header data provided in the
>> Packet->tcph which holds the header from the current packet ie ack
>> packet from the server ... and hence the incorrect TCP header display
>> with PAF on.
>> There is no way curently to get the correct TCP headers unless Stream
>> 5 is queried to give the original raw packet <spo_log_tcp_dump.c does
>> that>.
>> Realworld issue arising from the above is incorrect TCP header data in
>> alerts. TCP dumps are OK though for reason mentioned above.
>> There seems multiple ways to get around this:
>> Generate TCP dump on all alerts and assume the alerts will have
>> incorrect TCP headers
>> Write an alert output plugin that inspects the raw packet for correct
>> TCP headers etc
>> Add more metadata to Packet struct which can provide the correct TCP
>> headers at least for the last packet that completed the PDU in the
>> alert output plugins.
>> Last option looks the most organic and least sub optimal one to me.
>> Given my little experience with snort so far , I wont be surprised if
>> any of the above stated flow is incorrect.
>> I will more than appreciate if someone can correct me above and
>> enlighten me more about the internals :) .
>> Thanks
>> Parmendra
>>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130405/00b932c2/attachment.html>


More information about the Snort-devel mailing list