Configurable Deny Action

Security policies enable administrators to allow desirable applications to pass through the firewall and block unwanted applications from connecting to the outside or between networks.

The 'allow' action assigned to a security policy is fairly straightforward, but when it comes to blocking traffic, several options are available to an administrator to change the behavior of the firewall, depending on the application or the situation.

Beginning with PAN-OS 7.0, an administrator can choose which action to apply to unwanted sessions: drop, deny or reset:

The Drop action is mostly used as a stealthy way of discarding traffic. The firewall will simply throw away any packets associated with an unwanted connection, not letting the client or server know the packets are being discarded. This is a common good practice to reduce exposure to the outside world as port scans will take longer to complete and will result in less usable forensics. If it is desirable to let the client know the session is not allowed, an ICMP Unreachable (ICMPv4 Type3 Code13, ICMPv6 Type1 Code1) message can be sent to make the client aware the remote host is not available for this connection. This can help the source gracefully close or clear the session and prevent applications from breaking, where applicable.

The Deny action will tear down the session using the recommended method per application.

The App-ID description contains a Deny Action description of the action taken if a security policy blocks the application and has the Deny action set. If no Deny Action is listed, the packets will be silently discarded. Drop-reset will discard the session's packets and send a TCP RST packet to let the client know the session has been terminated so it can gracefully close the session locally.

An administrator can also opt to always send a reset packet either to the client, the server or both. In case the session is TCP based, a RST packet will be sent. In case the session is UDP or ICMP based, an ICMP Unreachable will be sent.

• Sending a reset only to the client would ensure, for example, internal hosts receive a notification the session was reset and the browser is not left spinning or the application can close the established session while the remote server is left unaware.
• Reset server can be used to ensure an internal server is able to clear a socket while an external client is left unaware.
• Sending a reset to both will let both parties know the session was blocked.

To prevent sending out too many ICMP Unreachable packets, you can toggle the rate per second via the Session Settings

Was this information helpful to you?

Best regards,

reaper