Home page logo
/

snort logo Snort mailing list archives

Re: HTTP Reassembly issue PAF enabled
From: Parmendra Pratap <parmendra.pratap () yahoo com>
Date: Fri, 5 Apr 2013 08:56:44 -0700 (PDT)

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!

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault