mailing list archives
Re: Snort doesn't trigger while the payload size is big (even for ~4-5KB files)
From: Joel Esler <jesler () sourcefire com>
Date: Mon, 13 Dec 2010 17:19:27 -0500
If an alert spans more than one packet, Snort will log the Stream Reassembled packet.
What version of Snort are you running? What is the rule you are trying to write? What is your Snort configuration?
Can you provide a full session pcap of the traffic?
On Dec 13, 2010, at 5:09 AM, Sujit Ghosal wrote:
I have figured out the issue. Its because of TCP reassembly of packets. In the first steam of my payload snort
was working flawlessly but if I jump to the second place of tcp reassembled data then it was not detecting. Well I
knew that the problem can be solved using flowbits keyword, but I wanted a solution where snort can detect those
re-assembled packets as well. Is it possible to command snort to handle tcp re-assembly without the use of flowbits?
On Sun, Dec 5, 2010 at 10:52 PM, Joel Esler <jesler () sourcefire com> wrote:
Can you provide your Snort configuration, rule you are trying to write
and a full session pcap of the traffic you are attempting to detect?
On Sunday, December 5, 2010, Sujit Ghosal <thesujit () gmail com> wrote:
Hi All, I had a similar type of issue some days back to detect any server side/client side vulnerabilities as
Snort was not detecting even for a single GET or <html> pattern in any requests/responses respectively. Anyways the
problem is somehow solved. It just suddenly started working (may be I think my firewall was blocking initially, I
am not fully sure though).
Now I came through a very bizzare problem. While I am writing a client side signature (lets say some PDF
vulnerability signatures). If the PDF has less number of bytes (within 500-600 bytes and the whole PDF is of 600
bytes) and attack pattern comes within those 600 bytes then snort detects that time with my developed rule. But If
I generate a malformed PDF File through MSF then the malformed objects are being moved to > 600 and the pattern is
present at last of the PDF file (around at 20000th offset). In such cases snort is not detecting the attack. I
checked the signature and everything is perfect as I haven't given any such offset limitations inside that rule.
I gave a look in snort.conf to see the http_preprocessor configs and the checked till how far snort processes
the data length and it is set to 0. So I think it should work in any case.
Can anyone please guide me on what could be the issue and how I can resolve this?
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
Snort-users list archive: