AnsweredAssumed Answered

Inaccurate Scan Results on Cisco 3750 Stack - QID: 105513 and 105459

Question asked by craigpardo on Aug 23, 2013
Latest reply on Aug 29, 2013 by craigpardo

Scanning a single Cisco stack of 3750 switches results in these inaccurate results:


1. EOL/Obsolete Software: Cisco IOS 12.1 and 12.2 Detected

QID:    105513


Here is the output from the scanned device when a show version command is run.


ROM: Bootstrap program is C3750E boot loader

BOOTLDR: C3750E Boot Loader (C3750X-HBOOT-M) Version12.2(53r)SE1, RELEASE SOFTWARE (fc1)


XXXXXXXX uptime is 4 weeks, 6 days, 14 hours, 45minutes System returned to ROM by power-on System restarted at 22:09:14 EDT ThuJul 18 2013 System image file is"flash:/c3750e-universalk9-mz.150-2.SE4/c3750e-universalk9-mz.150-2.SE4.bin"


###The "IOS Version" is 15.0(2)SE4 as shownhere:  ###


Switch Ports Model              SW Version            SW Image                

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

*    1 54    WS-C3750X-48P      15.0(2)SE4            C3750E-UNIVERSALK9-M


The Qualysguard scanner is picking up on the bootloader version, not the IOS version.


This is causing our Vulnerability Scan to show more level5 vulnerabilities than are currently present in our network.




2. EOL/Obsolete Software SNMP Version Detected


QID:    105459




The scan results show this:




    SNMPv3[XXXpublic] allows SNMPv1 access which is an obsolete version.




In fact I followed completely the guidelines set out from Cisco on how to disable SNMP version 1 and version 2c on this specific device.  There are no SNMP version 1 or 2c running services on this device, but again it is showing this level 5 vulnerability on our devices.




In the results it even says SNMPv3[XXXpublic] which is our version3 user.  That user as well as all SNMP users in our environment have both an authentication password as well as forced transport encryption.




Disable SNMP:





Is there anything being done to address these issues?  Are there any work arounds for the SNMP vulnerability other than disabling the polling through SNMP?