Re: stream4: Stealth activity

[Nigel Houghton <nigel () sourcefire com>]

On  0, Paul Schmehl <pauls () utdallas edu> wrote:

> > ok, this is gid 111 and sid 1 right?
> Yes, that's correct.  The msg portion of the alert is "spp_stream4: 
> Stealth Activity Detected"
 
> So it's basically a discovery method.  (And I see that I missed an 
> important point, which is that the stealth activity could be incomplete 
> sessions (SYN, but no ACK, FIN/PUSH/URG without a SYN, etc.) rather than 
> inconsistent sequence numbers.)

Yes, there are also other situations in which stream4 could generate
events on too, Xmas scans or Null scans for example and these have their
own gid:sid combos. Stream4 has the opportunity to tell you about
protocol anomalies as a by-product of reconstructing stream data. The
same goes for frag3 and the other pre-processors.

> > What you would ideally be able to do with traffic like this is bypass a
> > firewall.
> >
> > More info on stealth scanning here:
> >
> > http://www.snort.org/docs/faq/1Q05/node43.html
> Here's the problem from an analyst's POV.  If we get these alerts from 
> seemingly random addresses, we can't be certain that it's really a 
> discovery attack as opposed to a faulty NIC or misconfigured stack or 
> application.  So, do we report them?

That's hard to say. Could be a question of wether or not it's worth the
effort given the resources at hand.

> The recent activity seems much more suspicious.  We're seeing alerts 
> from multiple nodes in a /24, making the possibility of randomness seem 
> remote and the likelihood of a deliberate attack much higher.  So, do we 
> report them?  We report all portscans that trigger more than 1000 
> alerts, but most people understand what those are.  If we send a 
> complaint letter to an abuse@ address with a "spp_stream4: Stealth 
> Activity Detected" alert, they're less likely to know what we're 
> complaining about and therefore less likely to follow up, because they 
> won't know what to look for on the suspect host.

Right, the explanation of possible causes would need to accompany the
complaint which might lead to a better response.

> I guess, when we see what appears to be coordinated activity, we can 
> make a more persuasive case that the foreign network needs to take 
> action, so that's probably what we should concentrate on.

Sounds like a good plan of action.

> Thanks for your input, Nigel.
 
No problem, glad I could help.

+--------------------------------------------------------------------+
     Nigel Houghton      Research Engineer       Sourcefire Inc.
                   Vulnerability Research Team

         There is no theory of evolution, just a list
            of creatures Vin Diesel allows to live.


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users