Actually, this is no longer the case with the Internet Scanner 7.0 version. The .0
and the .255 addresses can be scanned as long as they are not determined to be
broadcast addresses. The only .0 limitation that exists currently is the scanning of
the "local" .0 address.
The exhibiting of this behavior is dependent on the configuration of the scanning
machine. In a normal, or /16, configuration where the subnet mask is for example
255.255.255.0, the .0 address related to the first 3 octets would always be considered
by the OS to be invalid. So for a system using the following:
IPADDR: 172.16.22.xxx
SUBNET: 255.255.255.0
GATEWY: 172.16.22.xxx
The address of 172.16.22.0 would be designated as invalid and as such the ICMP packets
would never actually leave the machine, but would generate an internal error saying:
Pinging 172.16.22.0 with 32 bytes of data:
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Ping statistics for 172.16.22.0:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
In an environment where custom subnet masking is being employed and where the .0 and
even the .255 addresses are valid, the configuration of the local IP settings would
not generate this invalidation and the scan would have proceeded normally.
The problem in this situation is that Scanner currently is not excluding this kind of
host address, but in fact begins the scan and hangs when waiting for an ICMP status.
This same behavior would not be displayed on remote .0 or .255 addresses in which a
singular reply is received, so in those cases, as long as they were not broadcast
addresses, they would be scanned. For example, the except below is a section of a
scan log for a remote .0 address:
<Host-Scan-Log IP='172.16.16.0' Time='2003-10-02 10:03:15.062'> 2003-10-02
10:03:15.062 Start Discovery engine scanning target='172.16.16.0' 2003-10-02
10:03:15.000 Ip='172.16.16.0', Discovery status='Router' 2003-10-02 10:03:15.000
Ip='172.16.16.0', IsReachable=1, IcmpPingTime=1, TargetType=3
Notice that a reply is received (further examination of the packets would actually
have shown that the 172.16.16.1 address replied in the place of the 172.16.16.0
address and so the address was not considered a broadcast address, and so Scanner will
handle it as a normal IP address) and so the IP is designated as reachable and is
therefore scanned. But in the case of the local .0 address, notice that the temp log
shows that the scan progressed to the point that it is looking for a ICMP reply:
<Host-Scan-Log IP='172.16.22.0' Time='2003-10-02 10:03:15.062'> 2003-10-02
10:03:15.062 Start Discovery engine scanning target='172.16.22.0' 2003-10-02
10:03:15.000 Ip='172.16.22.0', Discovery status='Router'
But since the reply is never received (expected since it never actually went out)
Scanner simply waits.
We believe that this can easily be addressed by simply making Scanner aware of the
internal OS invalidation reply to the ICMP request, thereby preventing the host from
ever being scanned, much the same way as we currently handle broadcast addresses
discovered during a scan session. This will be addressed in a future release of
Internet Scanner.
Hope that helps,
-- L�
Lynn E. Lowrie
-----Original Message-----
From: Gerard Sam-FMAT01 [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2003 8:51 AM
To: 'Briggs, Jr., Russell B.'; [EMAIL PROTECTED]
Subject: RE: [ISSForum] No Vulnerabilities Discovered
Briggs,
This may not be your problem but it is a known feature of IS all versions. If the last
octet is '0' [zero] or '255' IS will not scan the IP. It will show queued but will
never actually scan the device. This is due to network constraints.
Regards,
Sam
-----Original Message-----
From: Briggs, Jr., Russell B. [mailto:[EMAIL PROTECTED]
Sent: Friday, October 10, 2003 1:36 PM
To: [EMAIL PROTECTED]
Subject: [ISSForum] No Vulnerabilities Discovered
Can someone comment on the common pitfalls when running ISS 7.0? I've tried to scan an
NT 4.0 workstations and server that is not running DNS but using the LMHOST files for
routing purposes. The ISS discovery policy identifies the workstations in the usual
manner but L3 to L5 security policies have yet to uncover any vulnerabilities at all
(yet the system admin claims they are way behind in their software patching).
Appreciate any comments... _______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
