Re: [Snort-inline-users] [PATCH] fix restart function called after a SigHUP

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

On Friday 09 July 2004 16:14, William Metcalf wrote:
> Dude if you can get state information to pass from iptables to ipqueue, to
> snort_inline, to the stream4 preproc go for it.  If you take this route,
> you will still have to change the way that stream4 deals with mid-stream
> sessions.  It waits to see both sides of the communication until it marks a
> stream as established i.e. if we are droping packets and the client is
> retransmitting the same packet over and over and the session gets nuked due
> to timeout in stream4 the next packet in will be a retransmission of the
> attack and will make it through because snort does not look at a yet
> unestablished streams packets with stream4 enabled.

Hey Will, other Guys,

Okay, here goes nothing. Attached are two files: one patch and one script with 
example rule for iptables (NAT mode). This is proof of concept quality, and 
needs a lot of work!

What i do here is the following:

Before queueing the packets to snort_inline i mark them in iptables:
0x10: NEW
0x11: ESTABLISHED,RELATED

I read this in TranslateToPcap() into iv.mark.

When ReassembleStream4 can't find a session for the packet, it now first 
checks if packet mark is 0x10. If so, it requires a SYN flag. If this 
succeeds, a session is created.

If the mark is 0x10 but there is no SYN, we drop.

If the 0x10 mark is not set, it checks if 0x11 mark exists. If so it lets the 
packet continue, and the session will be created up midstream.

If no mark is set, it falls back to default behaviour.

Advantage of this approach:
- timeout can be 30 sec even for ssh-sessions, because iptables takes care of 
the connection tracking.
- So we save memory.

Disadvantages:
- no idea if this can work in bridge mode
- is this really secure? i think is, because we can trust iptables?
- this is where you guys come in.


Regards,
Victor


BTW: with this patch and the sighup patch i send yesterday, you can reload 
snort_inline, without losing your connections  : - )

>
> Regards,
>
> Will
>
>
>
>              Victor Julien
>              <vi...@nk...>
>                                                                         To
>              07/09/2004 05:55          sno...@li...urceforg
>              AM                        e.net
>                                                                         cc
>                                        William Metcalf
>                                        <Wil...@kc...>
>                                                                    Subject
>                                        Re: [Snort-inline-users] [PATCH]
>                                        fix restart function called after a
>                                        SigHUP
>
> On Friday 09 July 2004 09:45, Victor Julien wrote:
> > On Friday 09 July 2004 03:04, William Metcalf wrote:
> > > >I'm no snort expert, nor a snort_inline expert, nor a expert
>
> programmer,
>
> > > but
> > >
> > > >my question is: what would you gain by writing your own preproc? Can
>
> you
>
> > > >point problems in the current one that are so big they can't be fixed?
> > >
> > > The way that stream4 deals with data now is not really ideal for an
> > > inline device.  We could cut a lot of fat out stream4 with the checks
>
> for
>
> > > picking up sessions midstream as this shouldn't ever happen except
>
> during
>
> > > the initialization of the plug-in.  In addition separating out the
> > > session time-out and storing of packets in memory will be difficult
>
> while
>
> > > keeping the stream4 preproc working while not in inline mode.    Rob
>
> has
>
> > > amazingly been able to do this up to this point : -)
> >
> > I have several ideas. Since snort_inline is dependant on Netfilter, can't
> > we in some way use the Netfilter connection-tracking? Maybe with some
> > extension of conntrack or a modification of libipq? We don't have to
> > re-invent the wheel, right?
>
> Sorry to follow up on myself, but if in iptables you mark NEW connections
> 0x1
> and ESTABLISHED/RELATED connections 0x2, and manage to in some way
> communicate this trough the QUEUE target to snort_inline (not sure if this
> is
> possible), then you can use the iptables conntrack, right?
>
> Then it would be possible to pick up sessions midstream because iptables
> tells
> you they are valid (by setting the mark to 0x2)... and then the timeout of
> 30
> sec to 2 minutes would make sense again, because we can pickup sessions
> midstream again.
>
> Iptables would then send NEW connections with mark 0x1 so in snort_inline
> we
> can then inspect the packet. See if it is a synner... this way we can still
>
> detect portscans.
>
> So a new connection with MARK 0x1 would have have the syn-flag, otherwise
> its
> a scan or something. A packet which enters midstream would contain the 0x2
>
> mark (set by iptables), so we know it is not a scan, and we can accept it
> and
> create a session for it again!
>
> How does this sound to you guys?
>
> Regards,
> Victor
>
> > Maybe we want (yes we, i would like to help you ;-) the same timeout
>
> values
>
> > netfilter uses. They make sense in normal use. This would present a
> > challenge because of the much larger memory use of stream4. But maybe we
> > can store the data of sessions that are inactive for a few minutes on
>
> disk?
>
> > Can we  think of something to write the state table to disk so it can
> > survive a sighup (for applying new settings) or even a program restart
> > (they seem to be identical right now (see below)). If you are in a
> > corporate environment, you can't afford to lose sessions of your users if
> > you apply a new rule or a configuration change.
> >
> > <snip>
> >
> > > Don't quote me on this, as I'm not sure if snort still reacts the same
> > > way to a kill -HUP, but in the past it didn't just re-read the config
> > > files, it used exec argv which completely tore down snort and
>
> restarted.
>
> > You're right, I just didn't look right! I was really tired yesterday (in
>
> a
>
> > few days i'm going on my holiday, i really deserved it! ;-)
> >
> > Regards,
> > Victor
> >
> > > Regards,
> > >
> > > Will
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >              Victor Julien
> > >              <vi...@nk...>
> > >
> > > To 07/08/2004 07:13          William Metcalf
> > >              PM                        <Wil...@kc...>
> > >
> > > cc sno...@li...urceforg e.net,
> > >
> > > sno...@li...ur ceforge.net
> > >
> > > Subject Re: [Snort-inline-users] [PATCH] fix restart function called
> > > after a SigHUP
> > >
> > > On Friday 09 July 2004 01:59, William Metcalf wrote:
> > > > The more requests that come in, it's getting conceptually harder to
> > > > meet them modding the stream4 that comes with vanilla snort.  I guess
> > > > I've
> > >
> > > found
> > >
> > > > my research project for my cert, I'll start rewriting stream4 as a
> > >
> > > separate
> > >
> > > > preproc for snort_inline.   What do you guy's think about this?
> > >
> > > I'm no snort expert, nor a snort_inline expert, nor a expert
>
> programmer,
>
> > > but
> > > my question is: what would you gain by writing your own preproc? Can
>
> you
>
> > > point problems in the current one that are so big they can't be fixed?
> > >
> > > > If this is cool with everyone, just send me what you would like to
>
> see.
>
> > > As
> > >
> > > > far as reassembly goes how long do you think we should store packets
>
> in
>
> > > memory from the stream?  What is a good length to keep state?
> > >
> > > I would like to be able to walk away from my ssh session for a few
>
> hours,
>
> > > and
> > > still not lose my session (and i really know people that act this way!
>
> =)
>
> > > But Will, can you explain me something? When snort_inline receives a
> > > sighup
> > >
> > > the Restart() function is called, which in its turn runs through the
> > > PluginRestartList to execute the restart function of the specific
> > > preproc, right? If i'm not mistaken, for stream4 this the
> > > Stream4RestartFunction(). However in that function (starting on line
>
> 3509
>
> > > of spp_stream4.c) i can find
> > > no reason for the state table to flush... so where is flushed (if at
> > > all)?
> > >
> > > > Rob, would you be
> > > > alright with this?
> > > >
> > > > Regards,
> > > >
> > > > Will
> > >
> > > Regards,
> > > Victor
> > >
> > > PS. what kind of cert is that?
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Snort-inline-users mailing list
> > Sno...@li...
> > https://lists.sourceforge.net/lists/listinfo/snort-inline-users