Firewall Wizards: RE:Vulnerability Scanners ( was: concerning ~el8 / project mayhem )

["Josh Welch" <jwelch () buffalowildwings com>]

> Hi Paul,
>
> > modem provider's netblock.  A scanner won't pick that up unless it's
> Sure.
>
> > The Web server admin adds a new IIS mapping for .xyz files that does the
> Yeah.
>
> > The vulnerability is damaging enough that a non-destructive test isn't
> But of course.
>
> What about? Company policy: no FTP servers on the Internet-exposed
> servers. IT stuff checks the servers THEY DEPLOYED for FTP - none has it.
> Somebody else deploys a box with FTP without telling IT dept. Vuln scanner
> will pick it up (if FTP server is vulnerable). Audit of the KNOWN server
> configurations won't. Admittedy, one can argue that a good audit should
> also include periodic asset discovery, but that is besides the point.
One could also argue that according to the practice of only allowing what is
needed and blocking all else, some sort of access control should be in place
that prevents FTP traffic from ever getting to that server. FTP traffic
beyond that of authorized servers should be denied at the perimeter. An
audit of your security practices would tell you whether you have denied all
FTP. A scanner can only tell you that host w.x.y.z is running an FTP server
and you can access it.

> > implementation verification.  What's more, it's possible to validate
> > things either manually or in an automated fashion, and it's possible to
> > architect for easy validation.
> Well, isn't 'VA scanning' a kind of "ouside remote tool-based
> verfication" ;-)
>
> > It takes me about 10 minutes to manually configure a Linux server so that
> > I'm fairly confident that it's as "hardened" as is necessary.
> It takes me
> Same here. You and me might not need a scanner to verify the box just
> built. To verify the open ports with vulns on 100 servers will take
> 15x1000 min (based on your earlier estimate) of SCANNER time and not
> 2x1000 minutes of YOUR time. Now, we are not even talking of verifying
> boxes smb else built.
>
> My conclusions: scanners are good to find human errors (mostly, silly
> mistakes, but that is besides the point. they might be silly, but still
> popular) in configs remotely. They make sense in addition to config
> verification, not instead of it.
This would be the defense in depth arguement, which I can't disagree with. I
am still somewhat wet behind the ears, so I can't state with the same
confidence as you or Paul that I can lock a machine down and feel good about
it in 10 minutes. I don't have some_one_ else to check my work, so I like to
use
a vulnerability scanner to have some_thing_ else to check it.

Josh

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards