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: kathy.kirk@prudential.com [mailto:kathy.kirk@prudential.com]
Sent: Wednesday, February 08, 2006 4:57 PM
To: focus-ms@securityfocus.com
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
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
