[Snort-devel] Re: [Snort-users] spp_stream4: EVASIVE RST detection

Jason A. Haynes jahaynes at ...502...
Sat Jul 14 20:11:13 EDT 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


on stream4, I'm getting ready to submit a patch for optioning out of some
of these alerts.  I figured I'd start with this one first (EVASIVE RST)
then work on some of the others.  The question I have is... when
CheckRst() is called a) it's always called in the same place, in the same
way.  Could we snarf that into the function?

(spp_stream4.c:1323)
                        if(CheckRst(ssn, direction, pkt_seq, p))
                        {
                            ssn->server.state = CLOSED;
                            ssn->client.state = CLOSED;
                            DebugMessage(DEBUG_STREAM,
                                    "   Client Transition: CLOSED\n");
                            DebugMessage(DEBUG_STREAM,
                                    "   Server Transition: CLOSED\n");

                            return ACTION_ACK_CLIENT_DATA |
                                ACTION_FLUSH_CLIENT_STREAM |
                                ACTION_FLUSH_SERVER_STREAM |
                                ACTION_DROP_SESSION;
                        }

Obviously the return won't be functionalized (it's different from call to
call).  We could put the ssn->(client|server) = CLOSED and the debugs
inside the function, tho.  I'll do this if there aren't objections?

With or without objections to expanding the function, it's unclear to me
if we want the sessions to really not be flagged closed if the RST check
doesn't pass.  If the check is disabled, I can return 1 unconditionally,
or return 0 without logging anything.  My presumptions on adding
conditional checks are:
1) might be speed related
2) might be crash related (ie certain checks are known to crash it)
both 1 & 2 would benefit from bypassing as much code as possible.  That
is, as much check-specific code which isn't necessary to stream integrity.
3) they can't stand the number of alerts they're getting, possibly from
badly written but approved applications.

w/r/t #3, of course nothing should be violating RFC's, certainly not on
something as low level as TCP/IP stacks.  Usually this assumption is too
ivory tower, but even Windows uses *BSD tcp/ip stacks now, so most OS
stacks should be clean unless tampered with.  On the other hand, we should
probably be quicker to encourage more debuging and tracing than options to
turn off alerts which are (probably) standards-safe.

But for reasons 1-2 at least I figured I'd contribute some options for us.
Just wanted to clarify that if we don't like the RST after the check we
don't want to set:
                            ssn->server.state = CLOSED;
                            ssn->client.state = CLOSED;

Basically, is it possible for an RST to fail our check (perhaps we the
stream timed out after we did) but still signal an intended close of
session by a legitimate application?  Or since the session timeout is 30
seconds does it even (usually) matter?  Since a couple reports have come
in on snort-users I'm wondering..

Thanks,
Jason



- From 

On Sat, 14 Jul 2001, Marcus Vinmcius de Melo Rocha wrote:

> > >
> > > preprocessor stream4 noalerts
> > >                      ^^^^^^^^--- This should do the trick.
> > >
> > > -bill
> > That will kill all stream4 related alerts...I wish there were a way to
> > selectively choose which alerts to show and which to toss.  Or am
> > I totally
> > off base and the alerts we are discussing would be the only
> > alerts you would
> > see from the stream4 pp?
> >
> > -Steve
> 
> Hi,
> 
> I was reading the source code for stream4 preprocessor, and I found the
> following alerts:
>     - "spp_stream4: DATA ON SYN detection"
>     - "spp_stream4: NMAP FINGERPRINT (stateful)"
>     - "spp_stream4: EVASIVE RST detection"
>     - "spp_stream4: Possible RETRANSMISSION"
>     - "spp_stream4: WINDOW VIOLATION detection"
>     - "spp_stream4: STEALTH ACTIVITY (unknown) detection"
>     - "spp_stream4: STEALTH ACTIVITY (Vecna scan) detection"
>     - "spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection"
>     - "spp_stream4: STEALTH ACTIVITY (NULL scan) detection"
>     - "spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection"
>     - "spp_stream4: STEALTH ACTIVITY (FIN scan) detection"
>     - "spp_stream4: STEALTH ACTIVITY (SAPU scan) detection"
>     - "spp_stream4: STEALTH ACTIVITY (Full XMAS scan) detection"
> 
> For now, I'm getting hundreds of "spp_stream4: Possible RETRANSMISSION",
> some "spp_stream4: WINDOW VIOLATION detection", and some "spp_stream4:
> EVASIVE RST detection". I'm studing the logs to find out if it's just false
> positive.
> 
> Hope it helps.
> Marcus
> 
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBO1DfpbLjQl4gvHqLEQIpfACglJ1rhXE2T3G9srI1fRtGPvf7Y4UAn1Jj
cD/bmY9DLFsR5txMZrKGMXEb
=pAJn
-----END PGP SIGNATURE-----





More information about the Snort-devel mailing list