Two things... One, some devices have been found to leak sensitive information through SNMP requests - you'll have to search the vulnerability databases to check your devices.
Two, anybody who knows the community name now has a MAJOR tool to use to map your internal network. Make sure you filter ALL SNMP requests at ALL of your boundaries. (Think especially hard about the firewall between your VPN and the internal network). Three, are you going to push this down to the workstation level? That's a lot of machines to police to prevent users from turning off that 'useless' service... -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 4:57 PM To: [email protected] Subject: SNMP service We could us some guidance regarding SNMP. Below is the requirements we were given and our proposed approach. What if any issues do you see with our approach? Have you implemented something like this in your environment, and if so, how many devices do you have conforming to a similar requirement? Requirements: Using one standard community name, enable SNMP read capabilities on all devices supporting SNMP services throughout the corporate network, while mitigating risk of any known vulnerability. Approach: On all supported platforms (i.e. Windows, Solaris, Linux, AIX, etc.) configure the SNMP Service using a unique community name with read only rights and configure the community .name to accept packets from specified trusted hosts. thanks, kathy --------------------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ---------------------------------------------------------------------------
