Re: SourceFire RNA

[Renaud Deraison <deraison () nessus org>]

On Tue, Dec 02, 2003 at 06:34:18PM -0500, Jason wrote:

> > If you disable DCOM, then the attack vector is not here any more -> you 
> > are not vulnerable. So the active probe actually did its job well.
>
> except that normal patching and administrative activity can silently re 
> enable the service hence leaving it open and unknown until the next 
> round of scans while producing a not vulnerable result for a period of time.

Oh right. Scan often.

> > The initial patch _was_ effective - it fixed _a_ form of the overflow.
> > If the patch was properly applied, msblaster would not propagate.
>
> If it applied properly and the method of checking was sufficient.
>
> Ineffective is relative to systems that were reported patched even 
> though the patch failed to apply correctly. I am aware of scanners that 
> incorrectly reported a system patched and required a verification of the 
> actual files in use. Some of these were discussed on the lists.

The implementation of the scanners may be flawed, but the same can be
said of passive scanners as well - ie: maybe there are some changes in
behavior they don't see. Don't mix the principles with their actual
implementation.

> > Passively you can at best determine that you have a bunch of Windows 
> > hosts out there. Some might have been patched, some might not. And in
> > the end, you don't even know if you've seen ALL of them.
>
> What more do you need to know?
>
> it is a WinXXX system.

You determine that passively.

> Those systems were built with X configuration.

You can't determine that passively.

> Those systems had the last patch applied on X.

You have a *very* organized security team, congratulations. But then
again, the passive scanner won't be your sole source of information -
your security team will have to correlate its results with the subnets
they know they did patch.
 
[...]
> > You did not foresee anything. You saw that a 
>
> ???

Sorry. I meant you saw a change in behavior. That is, host X is now doing FTP.
This actually is useful, but not pro-active threat management - if the
host has been broken into, it's too late.

> Unless the local administrator blocked the traffic at the border, having 
> the net result of slowing the scan while they were at it.

In the same vein you should not deploy your IDS on a switch, you should
not deploy your scanner in front the of the firewall. There are a number
of distributed scanners solutions out there now. 

> Unless the host has a firewall

Then is it really vulnerable ? (apart from client-side vulnerabilities
of course, where passive scanners can shine in all their glory).

> Unless the host was on the road
> Unless the host was turned off
> Unless the host was recently smacked in the mouth and currently rebooting.

Right. Scan often and use a passive scanner between two scans.

I've never said that passive scanners were useless - heck, I wrote one. 
I said that you don't get to have the full picture JUST with them. The
same is true with active scanners as well, but it just turns out that
usually the active scanners gets to see a larger picture.


                                -- Renaud

---------------------------------------------------------------------------
---------------------------------------------------------------------------