Home page logo

snort logo Snort mailing list archives

Re: Snort doesn't trigger while the payload size is big (even for ~4-5KB files)
From: Sujit Ghosal <thesujit () gmail com>
Date: Tue, 14 Dec 2010 16:38:22 +0530

 The same case is happening for Snort v2.9.0.2 as well. However one extra
thing I did in Snort is, I changed its configuration slightly by
disabling gzip. Below are the changes details.
a. I commented this line from:
*preprocessor http_inspect: global iis_unicode_map unicode.map 1252
compress_depth 20480 decompress_depth 20480

*preprocessor http_inspect: global iis_unicode_map unicode.map 1252*

b. Deleted "*inspect_gzip \*" option from "*preprocessor
http_inspect_server: server default \*" preprocessor options.

*NOTE:* I made the 2 above changed as while running snort it was showing
zlib error. So I removed those 2 lines to solve the purpose for the time

*NOTE:* My modified Snort.conf file for  http://dpaste.com/286499/

- Sujit

On Tue, Dec 14, 2010 at 12:16 PM, Joel Esler <jesler () sourcefire com> wrote:

Do you have the ability to try and test the same scenario with a fresh
build of available from Snort.org?


On Dec 14, 2010, at 1:23 AM, Sujit Ghosal wrote:

Hi Joel,
    Below are my snort related details, you have asked for:
Snort version is (Build 114) and is installed in FC13.
Snort Config: http://vim.pastey.net/143877
Pcap: http://www.mediafire.com/?p3wdxosvswt9zmj

As you can see, for the SID: 8888 I am using an addition content match
"|2f|StructTreeRoot|20|" which you will find in the 3rd/4th TCP reassembled
stream in the pcap. And for this my snort rule doesn't trigger. But for the
SID: 9999 I have removed that pattern and the snort rule triggers.

## Not Working
Reassembly Check"; flow:established,to_client; content:"PDF-"; nocase;
depth:300; content:"|2f|Linearized|20|"; nocase; distance:0;
content:"|2f|StructTreeRoot|20|"; nocase; distance:0;
classtype:attempted-user; reference:url,www.exploit-db.com/exploits/11111/;
reference:url,www.google.com; sid:8888; rev:1;)

### Working (StructTreeRoot Pattern removed)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WORKING Sample
TCP Reassembly Check"; flow:established,to_client; content:"PDF-"; nocase;
depth:300; content:"|2f|Linearized|20|"; nocase; distance:0;
classtype:attempted-user; reference:url,www.exploit-db.com/exploits/11111/;
reference:url,www.google.com; sid:9999; rev:1;)

Best Regards,

On Tue, Dec 14, 2010 at 3:49 AM, Joel Esler <jesler () sourcefire com> wrote:

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:

Hey Joel,
      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?

Best Regards,Sujit

Joel Esler

Lotusphere 2011
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:

  By Date           By Thread  

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