Re: HTTP Reassembly issue PAF enabled

[Parmendra Pratap <parmendra.pratap () yahoo com>]

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.
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 () 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!