Vulnerability scan showing CVE-2008-4309 - SNMP 'GETBULK' Reflection DDoS

[inSync-MarkValpreda]

Not seeing anything on this anywhere I search. Nessus is showing CVE-2008-4309 - SNMP 'GETBULK' Reflection DDoS on our PA-1410 on 11.0.3-h10. 

Nessus was able to determine the SNMP service can be abused in an SNMP
Reflection DDoS attack :
Request size (bytes) : 42
Response size (bytes) : 2341

Not sure what I should do to remedy this alert. Thanks for any thoughts or suggestions. 

[H.Najwan]

Hey man, did u manage to fix this issue?  Appreciate your response.

i had the same issue as well.

VA Scan points out:
CVE-1999-0517 (SNMP Agent Default Community Name (public)) 

CVE-2008-4309 (SNMP 'GETBULK' Reflection DDoS

I had to remediate these two but same, i do not see any public way to resolve this. Also i am using v3 so the first CVE im not sure if its false positive.

[S.Cantwell]

That Nessus result is most likely not saying your PA-1410 is specifically vulnerable to an old Palo Alto software bug. Tenable’s plugin is detecting a behavior: the firewall’s SNMP service accepts a small GETBULK request and returns a much larger response, which means it could potentially be used as an SNMP reflection/amplification source. Tenable maps that behavior to CVE-2008-4309.

Your numbers make the concern pretty clear:

• Request: 42 bytes
• Response: 2341 bytes
• Amplification factor: about 56×

The primary remediation is therefore restrict who can query SNMP, rather than looking for a PAN-OS hotfix specifically for that CVE.

For a PA-1410, I would check these items in this order:

1. Do you actually need SNMP polling?
   If not, disable SNMP on the interface Nessus is scanning. Palo Alto explicitly recommends disabling unused management services. SNMP polling is enabled either on the MGT interface or through an Interface Management Profile on a data-plane interface.

2. If you need SNMP, restrict it to only your monitoring servers.
   If Nessus can query the firewall merely because it has network connectivity to that interface, your SNMP exposure is broader than it should be.

   For the dedicated MGT interface:

   Device → Setup → Interfaces → Management

   Make sure Permitted IP Addresses contains only your SNMP/NMS and administrator networks. Palo Alto states that an empty permitted-IP list allows access from any IP address and recommends explicitly specifying allowed addresses.

   If SNMP is enabled on a Layer 3/data-plane interface:

   Network → Network Profiles → Interface Mgmt

   Edit the Interface Management Profile that has SNMP checked, and populate Permitted IP Addresses with only the SNMP monitoring server(s). Palo Alto documents that these profiles control both which management protocols are exposed and which IP addresses can access them.

For example, instead of:

SNMP: enabled
Permitted IP Addresses: <blank>

I'd want something resembling:

SNMP: enabled

Permitted IP Addresses:
10.20.30.15/32   # SolarWinds
10.20.30.16/32   # Secondary NMS

Then a Nessus scanner at, say, 10.50.10.25 should no longer receive an SNMP response at all.

I would also move to SNMPv3 if you're currently using v2c. PAN-OS supports both v2c and v3, but Palo Alto identifies v3 as the more secure option because it provides authentication, integrity, encryption/privacy, and granular MIB access.

One caveat: SNMPv3 by itself does not necessarily eliminate the amplification characteristic. The strongest mitigation for this specific finding is preventing arbitrary hosts from talking to UDP/161 in the first place.

There is also another important issue in your environment: PAN-OS 11.0 is EoL now. Palo Alto's current documentation marks the 11.0 train as end-of-life. So independently of this Nessus finding, I would plan to move that PA-1410 to a currently supported PAN-OS release that is appropriate for your environment.

So my remediation ticket would probably read something like:

Finding: SNMP GETBULK reflection/amplification detected on PA-1410.
Cause: Firewall SNMP service responds to queries from systems beyond the authorized SNMP management hosts.
Remediation: Restrict UDP/161 management access using the PAN-OS Management Interface permitted-IP configuration or Interface Management Profile so that only authorized SNMP managers may query the firewall. Where possible, migrate SNMP monitoring from v2c to SNMPv3. Disable SNMP entirely if monitoring is not required. Upgrade PAN-OS from the EoL 11.0 release train to a currently supported release.

One thing I would not do is start building Security Policy / Vulnerability Protection rules to block GETBULK against the firewall itself. If Nessus is hitting the firewall's own management service, management-plane/interface access controls are the correct control.

Also, 11.0.3-h10 is quite old within an already-EoL 11.0 branch, so I would not spend much effort trying to determine whether some later 11.0 hotfix changes this exact Nessus behavior. Restrict SNMP first, then deal with the PAN-OS upgrade separately.