1. Introduction
The SNMP Zero Length UDP Packet Remote Denial of Service vulnerability affects systems running the Simple Network Management Protocol. An attacker can crash a target host or an intervening firewall by sending a specially crafted UDP packet with no data to port 161 (snmp). This could disrupt network connectivity and availability. Impact is likely to be high on availability, medium on confidentiality and integrity.
2. Technical Explanation
This vulnerability occurs because some SNMP implementations do not correctly handle UDP packets with a zero length payload. An attacker can exploit this by sending a UDP packet of size 0 to the target’s SNMP port (161). This causes the receiving system to crash, leading to a denial-of-service condition. The CVE identifier for this vulnerability is CVE-2000-0221. A simple example involves an attacker using a network tool like `hping3` to send a zero length UDP packet to the target’s SNMP port.
- Root cause: Lack of proper input validation when processing incoming SNMP packets, specifically failing to handle zero-length UDP payloads.
- Exploit mechanism: An attacker sends a UDP packet with no data to port 161 on the remote host. This triggers an error in the SNMP service or firewall handling the packet.
- Scope: Systems running SNMP services are affected, including various network devices and servers. Older versions of firewalls may also be vulnerable if they perform deep packet inspection on SNMP traffic.
3. Detection and Assessment
You can check for this vulnerability by verifying the version of your SNMP service or firewall software. Thorough assessment involves monitoring network traffic for suspicious UDP packets targeting port 161.
- Quick checks: Use `snmpget -v2c -c public
` to confirm SNMP is running and responsive. - Scanning: Nessus plugin ID 10854 may detect this vulnerability, but results should be verified manually.
- Logs and evidence: Check firewall logs for dropped UDP packets destined for port 161 with a zero payload size. System logs might show SNMP service crashes or errors related to packet processing.
snmpget -v2c -c public 4. Solution / Remediation Steps
To fix this issue, contact your firewall vendor if the crash occurred on the firewall. If the remote host crashed, filter incoming UDP traffic to port 161 or disable SNMP if it is not required.
4.1 Preparation
- If filtering traffic, ensure you understand the impact on network monitoring and management systems that rely on SNMP. A roll back plan is to restore the previous firewall configuration or remove the filter rule.
- Change windows may be required depending on your organisation’s policies. Approval from a senior network engineer might be needed.
4.2 Implementation
- Step 1: Contact your firewall vendor for available patches or firmware updates that address this vulnerability.
- Step 2: If no patch is immediately available, create a firewall rule to block incoming UDP traffic on port 161 from untrusted sources.
- Step 3: If SNMP is not required, disable the service on the affected host.
4.3 Config or Code Example
Before
# No specific rule blocking UDP port 161 trafficAfter
# Firewall rule example (syntax varies by vendor)
iptables -A INPUT -p udp --dport 161 -j DROP
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue. Least privilege limits the impact of exploitation, while input validation blocks unsafe data from reaching vulnerable services. Safe defaults reduce attack surface and patch cadence ensures timely updates.
- Practice 1: Implement least privilege to restrict access to SNMP only to authorized users and systems.
- Practice 2: Use input validation on all network interfaces to filter out malformed or unexpected packets, including those with zero-length payloads.
4.5 Automation (Optional)
# Example Ansible playbook snippet to block UDP port 161 on firewalls (use with caution)
- name: Block SNMP traffic on firewall
iptables:
chain: INPUT
protocol: udp
destination_port: 161
jump: DROP
5. Verification / Validation
Confirm the fix by re-checking your SNMP service version and attempting to send a zero length UDP packet to port 161. A successful smoke test involves verifying that legitimate network monitoring tools continue to function correctly.
- Post-fix check: Run `snmpget -v2c -c public
` again. The command should still respond, unless SNMP was disabled. - Re-test: Attempt to send a zero length UDP packet using `hping3` or similar tool. The target host should not crash and no errors should be logged.
- Smoke test: Verify that network monitoring systems relying on SNMP data continue to receive updates as expected.
- Monitoring: Monitor firewall logs for any blocked UDP packets destined for port 161, indicating potential attacks or misconfigurations.
hping3 -p 161 --udp -d 0 -c 1 6. Preventive Measures and Monitoring
- Baselines: Update security baselines to reflect current best practices for SNMP security, including disabling unnecessary features and restricting access.
- Pipelines: Add static analysis tools (SAST) to CI/CD pipelines to identify vulnerable SNMP configurations in infrastructure code.
- Asset and patch process: Implement a regular patch cycle for all network devices and servers, prioritizing critical vulnerabilities like this one.
7. Risks, Side Effects, and Roll Back
Blocking UDP port 161 may disrupt legitimate SNMP-based monitoring tools. Disabling SNMP might affect network management capabilities. To roll back, remove the firewall rule or re-enable the SNMP service.
- Risk or side effect 1: Blocking UDP port 161 could break existing network monitoring systems that rely on SNMP. Mitigation is to whitelist trusted sources in the firewall rule.
- Roll back: Step 1 – Remove the iptables rule using `iptables -D INPUT -p udp –dport 161 -j DROP`. Step 2 – If SNMP was disabled, re-enable it using the appropriate service command (e.g., `systemctl start snmpd`).
8. References and Resources
- Vendor advisory or bulletin: Check your firewall vendor’s website for specific advisories related to SNMP vulnerabilities.
- NVD or CVE entry: <