SNMP Exposure: Why Public Community Strings Are a Critical Network Risk
SNMP with default community strings exposed to the internet lets attackers map and reconfigure your network. Learn how to detect and lock down SNMP services.
What is SNMP?
Simple Network Management Protocol (SNMP) is used to monitor and manage network devices -- routers, switches, firewalls, printers, servers, UPS systems, and IoT devices. It runs on UDP port 161 (agent) and UDP port 162 (trap receiver).
SNMP allows a management station to query devices for information (CPU load, memory usage, interface statistics, routing tables) and, in some configurations, modify device settings remotely.
It is ubiquitous in enterprise networks. Nearly every network device supports SNMP. The problem is that SNMP was designed in an era when network security meant physical access control, and its default security model reflects that.
Why SNMP exposure is dangerous
Default community strings
SNMP v1 and v2c use "community strings" as passwords. The default read-only community string is public. The default read-write community string is private. These are well-known to every attacker and are the first thing automated scanners try.
An exposed SNMP service with the public community string lets anyone on the internet query:
- Device hostname, location, and contact information
- Network interface details (IP addresses, MAC addresses, traffic statistics)
- Routing tables (your entire internal network topology)
- ARP tables (mapping IPs to MAC addresses)
- Running processes and installed software
- System uptime and hardware information
Read-write access
If the private community string (or any read-write string) is accessible, an attacker can:
- Modify routing tables (redirect traffic)
- Change interface configurations (disable ports, change IPs)
- Modify ACLs on the device
- Change SNMP community strings (locking you out of monitoring)
- Exfiltrate the device configuration (which may contain other credentials)
SNMP reflection/amplification DDoS
SNMP can be abused for DDoS amplification attacks. An attacker sends small SNMP GetBulk requests to exposed SNMP agents with a spoofed source IP (the victim's IP). The SNMP agent sends a much larger response to the victim. Amplification factors of 6x to 50x or more are common.
How to check for SNMP exposure
Using nmap
# Check if SNMP is accessible
nmap -sU -p 161 your-public-ip
# Try default community strings
nmap -sU -p 161 --script snmp-brute your-public-ip
# Get system information if SNMP is open
nmap -sU -p 161 --script snmp-info your-public-ip
Using snmpwalk
# Try the default 'public' community string
snmpwalk -v2c -c public your-public-ip
# If this returns data, your SNMP is exposed with default credentials
# System description is a good quick test
snmpget -v2c -c public your-public-ip 1.3.6.1.2.1.1.1.0
Using Shodan
Search Shodan for your IP range:
port:161 net:your-ip-range/24
Or search for specific community strings:
port:161 "public"
Using onesixtyone
onesixtyone is a fast SNMP scanner designed for discovering accessible SNMP services:
# Scan a range with common community strings
onesixtyone -c community_strings.txt your-ip-range/24
How to secure SNMP
Option 1: Disable SNMP entirely
If you do not actively use SNMP for monitoring, disable it:
# Linux
sudo systemctl stop snmpd
sudo systemctl disable snmpd
# Cisco IOS
no snmp-server community public
no snmp-server community private
no snmp-server enable traps
Option 2: Firewall SNMP to internal networks only
If you need SNMP for internal monitoring, ensure it is never accessible from the internet:
# UFW
sudo ufw deny 161/udp
sudo ufw allow from 10.0.0.0/8 to any port 161 proto udp
# iptables
sudo iptables -A INPUT -p udp -s 10.0.0.0/8 --dport 161 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 161 -j DROP
In cloud environments, check your security groups for any rule allowing UDP 161 from 0.0.0.0/0.
Option 3: Upgrade to SNMPv3
SNMPv3 replaces community strings with proper authentication and encryption:
- Authentication -- username and password (MD5 or SHA)
- Encryption -- DES or AES encryption of SNMP traffic
- Access control -- fine-grained control over what each user can read or modify
Configure SNMPv3 on Linux (/etc/snmp/snmpd.conf):
# Disable SNMPv1 and v2c
agentAddress udp:161
# Create an SNMPv3 user with auth and encryption
createUser monitorUser SHA "authPassword123" AES "privPassword456"
# Grant read-only access
rouser monitorUser priv
# Disable default community strings
# (remove any 'rocommunity' and 'rwcommunity' lines)
Restart the SNMP daemon:
sudo systemctl restart snmpd
Configure SNMPv3 on Cisco IOS:
! Remove old community strings
no snmp-server community public
no snmp-server community private
! Create SNMPv3 group and user
snmp-server group MONITOR-GROUP v3 priv
snmp-server user monitorUser MONITOR-GROUP v3 auth sha AuthPass123 priv aes 128 PrivPass456
Change default community strings (minimum step)
If you cannot immediately upgrade to SNMPv3, at minimum change the community strings to strong, unique values:
# Linux /etc/snmp/snmpd.conf
# Replace 'public' with a strong string
rocommunity s3cur3-r0-$tring 10.0.0.0/8
# Remove any rwcommunity lines unless absolutely needed
This is a stopgap -- SNMPv3 is the correct long-term solution.
Restrict SNMP access by IP
Even with strong community strings or SNMPv3, restrict SNMP access to your monitoring servers:
# Linux /etc/snmp/snmpd.conf -- only allow from monitoring server
rocommunity mySecretString 10.0.1.50/32
# Cisco IOS -- ACL-restricted community
access-list 99 permit 10.0.1.50
snmp-server community mySecretString RO 99
SNMP trap security
SNMP traps (UDP 162) are notifications sent from devices to the monitoring server. If your trap receiver is exposed to the internet, attackers can:
- Send fake traps to flood your monitoring system
- Inject false alerts to mask a real attack
- Probe the trap receiver for vulnerabilities
Firewall UDP 162 the same way you firewall UDP 161.
Verify the fix
After securing SNMP:
# From outside your network -- should time out or show closed/filtered
nmap -sU -p 161 your-public-ip
# Verify default community strings no longer work
snmpwalk -v2c -c public your-public-ip
# Should time out or return an error
Check Shodan for your IPs -- SNMP should no longer appear. For a full view of your exposed services, see open ports security.
How SurfaceScan helps
SurfaceScan scans for exposed SNMP services on UDP ports 161 and 162 across your entire attack surface. It tests for default community strings (public, private, and other common values) and flags any SNMP service accessible from the internet as high severity. Findings include the community string that was accepted and the device information returned, so you can see exactly what an attacker would learn. Continuous monitoring ensures SNMP is not accidentally re-exposed after network changes.
Related articles
Exposed Database Ports: A Critical Security Finding You Must Fix Now
Database ports like MySQL 3306, PostgreSQL 5432, MongoDB 27017, and Redis 6379 exposed to the internet are a critical risk. Learn how to detect and secure them.
Open Ports: Which Ones Are Dangerous and How to Close Them
Not all open ports are a problem, but some should never be exposed to the internet. Learn which ports are dangerous, why, and how to close them safely.
What Shodan Reveals About Your Infrastructure -- and What Attackers See
Shodan indexes every internet-connected device. Learn what information it exposes about your organisation, how attackers use it, and how to reduce your footprint.