{
	"id": "a372508f-403c-442c-bb88-bb42d7c694ea",
	"created_at": "2026-04-06T00:18:07.280794Z",
	"updated_at": "2026-04-10T13:11:44.682439Z",
	"deleted_at": null,
	"sha1_hash": "ea8a903b458fd4c183bad51a189c9341e9bbca9b",
	"title": "Reducing the Risk of SNMP Abuse | CISA",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 44837,
	"plain_text": "Reducing the Risk of SNMP Abuse | CISA\r\nPublished: 2017-06-05 · Archived: 2026-04-05 23:38:28 UTC\r\nSystems Affected\r\nSNMP enabled devices\r\nOverview\r\nThe Simple Network Management Protocol (SNMP) may be abused to gain unauthorized access to network\r\ndevices. SNMP provides a standardized framework for a common language that is used for monitoring and\r\nmanaging devices in a network.\r\nThis Alert provides information on SNMP best practices, along with prevention and mitigation recommendations.\r\nSNMP depends on secure strings (or “community strings”) that grant access to portions of devices’ management\r\nplanes. Abuse of SNMP could allow an unauthorized third party to gain access to a network device. \r\nSNMPv3 should be the only version of SNMP employed because SNMPv3 has the ability to authenticate and\r\nencrypt payloads. When either SNMPv1 or SNMPv2 are employed, an adversary could sniff network traffic to\r\ndetermine the community string. This compromise could enable a man-in-the-middle or replay attack.\r\nAlthough SNMPv1 and SNMPv2 have similar characteristics, 64-bit counters were added to SNMPv2 so it could\r\nsupport faster interfaces. SNMPv3 replaces the simple/clear text password sharing used in SNMPv2 with more\r\nsecurely encoded parameters. All versions run over the User Datagram Protocol (UDP).\r\nSimply using SNMPv3 is not enough to prevent abuse of the protocol. A safer approach is to combine SNMPv3\r\nwith management information base (MIB) whitelisting using SNMP views. This technique ensures that even with\r\nexposed credentials, information cannot be read from or written to the device unless the information is needed for\r\nmonitoring or normal device re-configuration. The majority of devices that support SNMP contain a generic set of\r\nMIBs that are vendor agnostic. This approach allows the object identifier (OID) to be applied to devices regardless\r\nof manufacturer.\r\nImpact\r\nA remote attacker may abuse SNMP-enabled network devices to access an organization’s network infrastructure.\r\nSolution\r\nA fundamental way to enhance network infrastructure security is to safeguard networking devices with secure\r\nconfigurations. US-CERT recommends that administrators:\r\nConfigure SNMPv3 to use the highest level of security available on the device; this would be authPriv on\r\nmost devices. authPriv includes authentication and encryption features, and employing both features\r\nhttps://us-cert.cisa.gov/ncas/alerts/TA17-156A\r\nPage 1 of 2\n\nenhances overall network security. Some older images may not contain the cryptographic feature set, in\r\nwhich case authNoPriv needs to be used. However, if the device does not support Version 3 authPriv, it\r\nshould be upgraded.\r\nEnsure administrative credentials are properly configured with different passwords for authentication and\r\nencryption. In configuring accounts, follow the principle of least privilege. Role separation between\r\npolling/receiving traps (reading) and configuring users or groups (writing) is imperative because many\r\nSNMP managers require login credentials to be stored on disk in order to receive traps.\r\nRefer to your vendor’s guidance for implementing SNMP views. SNMP view is a command that can be\r\nused to limit the available OIDs. When OIDs are included in the view, all other MIB trees are inherently\r\ndenied. The SNMP view command must be used in conjunction with a predefined list of MIB objects.\r\nApply extended access control lists (ACLs) to block unauthorized computers from accessing the device.\r\nAccess to devices with read and/or write SNMP permission should be strictly controlled. If monitoring and\r\nchange management are done through separate software, then they should be on separate devices.\r\nSegregate SNMP traffic onto a separate management network. Management network traffic should be out-of-band; however, if device management must coincide with standard network activity, all communication\r\noccurring over that network should use some encryption capability. If the network device has a dedicated\r\nmanagement port, it should be the sole link for services like SNMP, Secure Shell (SSH), etc.\r\nKeep system images and software up-to-date.\r\nReferences\r\nThe Interfaces Group MIB using SMIv2\r\nRevisions\r\nJune 5, 2017: Initial Release\r\nSource: https://us-cert.cisa.gov/ncas/alerts/TA17-156A\r\nhttps://us-cert.cisa.gov/ncas/alerts/TA17-156A\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://us-cert.cisa.gov/ncas/alerts/TA17-156A"
	],
	"report_names": [
		"TA17-156A"
	],
	"threat_actors": [],
	"ts_created_at": 1775434687,
	"ts_updated_at": 1775826704,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ea8a903b458fd4c183bad51a189c9341e9bbca9b.pdf",
		"text": "https://archive.orkl.eu/ea8a903b458fd4c183bad51a189c9341e9bbca9b.txt",
		"img": "https://archive.orkl.eu/ea8a903b458fd4c183bad51a189c9341e9bbca9b.jpg"
	}
}