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

[Victor J. <vi...@nk...>]

Don't know about Will, but it sounds good to me.

Stream4 can only work properly if it sees all packets belonging to a 
connection.

Regards,
Victor

On Tuesday 03 August 2004 20:02, Peter K. Lee wrote:
> 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
>
> -------------------------------------------------------
> 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