Re: [Snort-inline-users] Snort-inline bug?

[pieter c. <pie...@co...>]

Hi Federico,

Keep in mind that SNIL does not support the stream4 preprocessor which
means that if you are trying to match a packet where the signature ends
up spanning two TCP datagrams, then it will fail (no half matching of
signatures!). Something like this can easily happen with long signatures
and small TCP datagram sizes and is also influenced by the location of
the signature in the data being packetised.

Note that it is not an IP fragmentation issue but a question of TCP data
spanning more than one packet.

There is unfortunately currently not a cure in the OSS community for
this problem and unless we get TCP reassembly support going, will be
with us for a while.

Regards,
Pieter

On Tue, 2004-01-20 at 17:47, Federico Petronio wrote:
> Same days ago I post to the bug section from SF.net the following, but I 
> can't realice if that's a snort-inline bug, a missconfiguration or what. 
> Any help would be welcome.
> 
> ----
> I found that snort-inline is letting pass in packets that it shouldn't. 
> For instance:
> 
> I have snort-inline 2.0.1 installed. I change the rule 2077 acction to drop.
> 
> Then I try to access, using Mozilla 1.5 and IE6.0, the URL:
> http://server_name/admin/fileman/upload.php?dir=
> 
> the snort-inline log start showing lines like this:
> 
> [**] [1:2077:2] WEB-PHP Mambo upload.php access [**]
> [Classification: access to a potentially vulnerable web application]
> [Priority: 2]
> 01/13-18:31:06.944124 200.43.81.205:1586 -> 10.2.0.10:80 TCP TTL:117
> TOS:0x0 ID:3095 IpLen:20 DgmLen:578 DF
> ***AP*** Seq: 0x45A19C2C Ack: 0x425899A4 Win: 0xFFFF TcpLen: 20
> [Xref => http://www.securityfocus.com/bid/6572]
> 
> 
> but after 5 minutes of that, the webserver finally got the query and
> answed. That means that snort-inline let pass through the packet that
> should drop. Can anyone check that? I try several time and got the same
> result.
> 
> Thanks...