Re: SourceFire RNA

From: Renaud Deraison (deraison_at_nessus.org)
Date: 12/03/03

  • Next message: Jason: "Re: SourceFire RNA" 
    Date: Tue, 2 Dec 2003 19:02:51 -0500
To: Jason <security@brvenik.com>, focus-ids@securityfocus.com

    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

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

  • Next message: Jason: "Re: SourceFire RNA"

    Relevant Pages

    • Re: SourceFire RNA
      ... If you can scan 15 ports a sec and only scan the common ports lists you ... That is 2.3 minutes per host. ... >>though the patch failed to apply correctly. ... > The implementation of the scanners may be flawed, ...
      (Focus-IDS)
    • Re: Pointers to Free Web Vulnerability Scanners for Blackbox testing
      ... Are you after open source black box web app scanners? ... What are the important things to remember while doing blackbox web app testing? ... Cenzic finds more, "real" vulnerabilities fast. ... buy it or download a solution FREE today! ...
      (Pen-Test)
    • Re: Vuln Scanning software choices
      ... > You basically say, I tested 10 scanners, selected one, but you have to ... Audit your website security with Acunetix Web Vulnerability Scanner: ... Check your website for vulnerabilities ... Cross site scripting and other web attacks before hackers do! ...
      (Pen-Test)
    • AW: Iptables Clues and Advices.
      ... Most scanners are used on networks not on specific hosts. ... These scanners usually try to ping each host ... >> technical support. ... >> Stop SPAM before it stops you. ...
      (Security-Basics)
    • RE: Vulnerability Scanning
      ... After reviewing some scan results and finding a number of false positives ... This is in no way reflecting upon nessus's ability to find vulnerabilities ... and I truely believe all scanners have these issues. ... For more information on a proactive anti-virus service working around the clock, around the globe, visit: ...
      (Pen-Test)
    • Quantcast