Re: [Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved -> resolved)

[Peter K. L. <sa...@co...>]

Hi Will,

The problem was that when I had this rule in iptables:

iptables -t filter -A INPUT -j QUEUE (sending all incoming packets to be
handled by snort_inline)

An INCOMING TCP connection request (SYN) to the box is handled w/o any
problems.

However if a connection request originated from the box itself, (i.e.
OUTGOING to Google), via a telnet google.com 80 or such, then the
INCOMING TCP response packet to the box gets dropped by stream4 module
in snort.

I'm not sure how stream4 works, but by how you describe it:

 a normal tcp conversation should have not problem with this as every
SYN packet we receive we create a new session for. Every packet we
receive following this in a tcp conversation has a session in stream4
and therefore is not dropped.

I'm guessing that stream4 never sees a SYN packet because it was never
sent to snort_inline via the QUEUE target.  The initial SYN packet just
went straight to Google.com, and the only thing that stream4 sees is the
(SYN ACK?) or some response making it seem like it was a stateless data
packet coming back into the machine.

So, if I understand correctly, stream4 will drop it, and it's doing what
it's supposed to do.

In that case, I guess the *proper* solution is to also feed:

iptables -t filter -A OUTPUT -j QUEUE (sending all outgoing packets to
be handled by snort_inline)

so that stream4 module of snort can keep proper state and become usable.

Does that sound right?

-Peter



On Tue, 2004-08-03 at 08:26, William Metcalf wrote:
> I'm really not sure I understand the problem your having, maybe some
> additional clarification would help. As far as the drop in stream4
> preproc goes, this drop only occurs when data is sent after a stream4
> session has been pruned, or some one is trying to send a stateless
> attack i.e snot/stick attack, or if you have a poorly implemented
> protocol that does not have keep-alives built-in and does not send
> data every so often (currently working on a fix for this) a normal tcp
> conversation should have not problem with this as every SYN packet we
> receive we create a new session for. Every packet we receive following
> this in a tcp conversation has a session in stream4 and therefore is
> not dropped.
> 
> Regards,
> 
> Will
> Inactive hide details for Peter"Peter K. Lee" <sa...@co...>
> 
> 
>                                 "Peter K. Lee" <sa...@co...>
>                                 Sent by: sno...@li...
>                                 
>                                 08/02/2004 06:59 PM
>                         
>                 
>         
> 
>                To
> 
> sno...@li...
> 
>                cc
> 
> 
>           Subject
> 
> [Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved -> resolved)
> 
> 
> I *think* this is the proper resolution...
> 
> I don't know whether this is by design, or it is a bug, but I tracked
> down the problem to be located in 'stream4' preprocessor of the snort
> system.
> 
> For the connection cases as I illustrated in the beginning, the
> stream4
> preprocessor issues a 'drop' (since snort_inline changes probably
> included modifying the preprocessor from 'alert' mode to 'drop' mode).
> 
> There seems to be some additional functions in that module that were
> added by 'snort_inline', but I have not delved into figuring out what
> they do.  Only thing I know is that, for whatever reason, it ALWAYS
> drops incoming 'response' packets, as well as FORWARD packets.
> 
> My tentative solution is to comment out the module altogether...
> 
> Does anyone have better idea about this phenomenon?
> 
> -Peter
> 
> p.s. this should conclude my unnecessary soliloquy...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
>