Options

PCI scans keep failing on SNMP external

edited September 2022 in Firebox - Other

We had a PCI scan performed by Coalfire and they found a failure.
Port 161 UDP Running a SNMP server
This results in a Insecure remote access protocol, this configuration is a violation of PCIDSS 2.2.2, and results in an automatic failure.

I cannot figure out how to disable SNMP on my M590. We have no Policies using that port but it is listening externally. I have a had a call open with Support since Friday and not talked to anyone yet. It has been escalated since Yesterday and still no calls. Any help is appreciated.

Comments

  • Options

    Check to see if SNMP Traps: are set to Disabled.

    Enable SNMP Polling
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/basicadmin/snmp_enable_polling_c.html

    I see this on a UDP scan for port 161 using udpchecker when the above is set to Disabled.
    2022-09-27 17:22:04 Deny 10.0.1.2 10.0.1.1 snmp/udp 61360 161 Trust-VLAN Firebox Denied 51 128 (Unhandled Internal Packet-00) proc_id="firewall" rc="101" msg_id="3000-0148" Traffic

  • Options

    We have this disabled. This issues is showing up on several devices T30, T35,T40 & M590's. On the M590 we are running 12.8.1.

    We have even added
    Port 161 to the blocked ports and it still fails.

    We feel like the WAN side prior to the firewall has this service running. We never see any traffic in the logs for 161 either.

  • Options

    You can select the "Enable logging for traffic sent from this device" check box which should show Fireware responding to the port 161 probe.

    Set the Diagnostic Log Level
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/logging/set_diagnostic_log_level_c.html

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Hanescorp41
    My first inclination would be to run a packet capture to see if you can verify that the firebox is actually responding. If port 161 is in the blocked ports list, the firebox should dropping any traffic that arrives on it.

    If you open Firebox System Manager, you can go to tools -> diagnostic tasks. Choose the TCP DUMP option from the network tab. Choose advanced options. In the arguments box, type:
    "-i eth0 port 161" (without the quotes, replace eth0 with the interface you're using as an external.)

    -James Carson
    WatchGuard Customer Support

  • Options

    We did a dump with WatchGuard. It is listening but the Firebox does not reply. Our PCI scan deems this a failure because is is using v1 on SNMP. We can't find any documentation on how to stop it from listening.

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    @Hanescorp41
    The firebox's default behavior is to silently drop traffic if it's not allowed. It seems strange that the scanning company would suggest no response is listening.

    If they need a reset to be sent as a deny, that can be set up in a policy. If you select Deny in a policy, you'll see an option to send a TCP reset or any of several ICMP unreachable messages.

    -James Carson
    WatchGuard Customer Support

  • Options
    edited September 2022
    @Hanescorp41 It’s common for port scanners to mark UDP ports as “open | filtered” when no response is received. You would have to create a deny policy that denies INCOMING UDP 161 from external networks AND sends an ICMP port unreachable (type 3, code 3) message if you want/need the port to be marked as closed. This can be done using the policy properties like James.Carson suggested. Note that you would need to remove 161 from blocked ports as blocked ports will be evaluated before the deny policy.

    Port scanners have signature databases that can determine the protocol version based on the response received. I just find it odd that Coalfire assumes that SNMPv1 is being used by default when the Firebox hasn’t sent a reply.

    Again, the port is only being marked as open because an ICMP port unreachable isn’t being sent as a response. It is normal behavior for port scanners to mark UDP ports as open|filtered when a response isn’t received. I tested this locally using a different port checker/scanner and it only marked the port as closed when an ICMP Port Unreachable was sent as a response.
Sign In to comment.