There's a pivotal question with remote security scanners:
Should they go ahead and exercise a hole to see if it's there.
I've got no interest in starting a debate on this subject, but
it's essentially what the issue is with the router check.
ISS seems to only be willing to try a hole if it's non-disruptive.
For example, it will test for a rdist hole by attempting to create
a file in /tmp.
In the abscence of other information (i.e. SNMP access, or logging
in to do a sho ver) the only way to check for that particular router bug
is to try it. As you know, the main result of that bug is crashing the
router.
(Presumably, there's a buffer overflow that might let code be pushed
on, but I don't think that could be done reliably by an automated
scanner given all the Cisco architectures it might run across.)
So, I assume that ISS is trying to determine vulnerablity without crashing
your router. ISS could give the advanced user the option of trying to
crash the router, and then ping it to infer if it's vulnerable. That
option
could be appropriate in a penetration test. In an environment where
one is trying to use the tool to keep on top of patch levels for internal
systems, you might consider giving the IS scanner a read-only SNMP
string. The latter option is certainly not terribly secure, but no less so
than any other SNMP use.
Ryan
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:10 PDT