Loading...
Loading...
The issue happens when we set a usual community name (which is the only authentication method in SNMP v2, and which goes in plaintext through the network), for example, "public" and "private," which are typically set for read-only and read/write access, respectively, to the SNMP agent. We can consider the community names as the password that the SNMP manager is sending so the Data Domain can confirm its identity and reply back with the requested queries. If those names are commonly used and easily predicted, any intruder can guess them and try to get details about the network devices. Security scanners report the DD with SNMP enabled is subject to "CVE-1999-0517," which would be a potential security issue: CVE-1999-0517 : SNMP community name is the default (for example public), null, or missing.
By default, SNMP is disabled on the Data Domain systems, and no community configured. You can configure and enable SNMP, including the community string name for example "public," "private" or some other specific less vulnerable known community names. No matter the DD SNMP configuration, if it is disabled, the security scanner reports no issue whatsoever. Run the following command from the DD CLI to know the SNMP agent status: # snmp status SNMP is enabled. When enabling SNMP, the user must decide whether to use SNMP v2 or SNMP v3 and in the former case, which community strings to use. When using "public" and "private" for the SNMP community string name the scanner will try well-known usual strings and if succeeding in getting a response back from the DD, it raises the alert. This is not a security problem with the DD but a configuration issue that the administrator has to correct.
Resolution consists of the administrator either choosing other (difficult to guess) community string names, or switch over the SNMP v3 which has stronger means for authentication. (See at the bottom for references to other Lightning Knowledge Based Articles that give more details on SNMP v3 management) Instead of "public" / "private," you may specify a different string. You may alternatively use SNMP v3 to eliminate this problem entirely. To get the configured community name, run the following CLI commands: # snmp show config Make note of the current configuration that uses "public" and/or "private" community string names. Example: SNMP v2c Configuration ---------------------- Community Access Hosts --------- --------- ----- public read-only 10.10.10.10 --------- --------- ----- Trap Host Port Community ----------- ---- --------- 10.10.10.10 162 public ----------- ---- --------- You can resolve that issue by removing any trap hosts that use "public" / "private" ro_community or rw_community string from the configuration if they exist: # snmp del trap-host <trap-host name or IP> {:<port number} EX: snmp del trap-host 10.10.10.10:162 Then remove the "public" / "private" ro_community or rw_community string from the configuration: # snmp del ro-community <community-string-list> # snmp del rw-community <community-string-list> We use the following CLI commands to add the SNMP v2 community string back but use a different community string name and any hosts that were in the original configuration. # snmp add ro-community <new community-string> { hosts <hosts> } # snmp add rw-community <new community-string> { hosts <hosts> } If you previously had trap-hosts configured using "public" / "private," then add them back using the new community string name. # snmp add trap-host <trap-host name or IP> {:<port number} version v2c community <new community-string> EX: snmp add trap-host 10.10.10.10:162 version v2c community <new community-string> If we have SNMP management systems or backup software polling the data domain details using that community string name, we have to change the configuration on those management systems as well to use the new strings R eference : Data Domain Managing SNMP
Click on a version to see all relevant bugs
Dell Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.