Palo Alto Networks Knowledgebase: DotW: reset-server, reset-client or silent drop

DotW: reset-server, reset-client or silent drop

Created On 09/25/18 19:03 PM - Last Updated 07/18/19 20:11 PM

This week's Discussion of the Week's topic was asked by Sly_Cooper on how to decide if a negative action from the Palo Alto Networks firewall should be silent or a notification sent, and who should receive the notification.





Veteran community member Brandon_Wertz immediately hit the nail on the head with his remark that there will be several scenarios and schools of thought that will set an administrator on either side of the fence.



To deside on the right strategy, it is important to list pros and cons for all options available for each flow in and out of the organization.  It may be beneficial for blocked connections to internal servers to notify internal clients and the server to improve responsiveness of the application and close open sockets on the server quicker. Locally hosted public servers may also benefit from a reset packet when a connection is terminated, but the external client may not need this notification to help prevent reverse mapping through the use of portscanning.


Not sending a reset packet out to a client on the internet may help prevent scanning attempts or prevent reflective attacks where a malicious client spoofs its source address in an attempt to trigger a victim to send out reset packets to a secondary victim's IP, which is the apparent source.


On the other hand, a silent drop may be a dead giveaway a firewall is blocking a port for a more experienced attacker. Sending out ICMP type 3 messages upon a denied session and simultaneously enabling more complex protection methods for scanning, like zone protection, will provide a more userfriendly experience for external users. These users will be notified immediately their session was denied, while scanning attempts are thwarted, leveraging protection mechanisms.



In short:

  • a silent drop is useful if obscurity is preferred.
  • reset-client is useful when user experience is key, the application will immediately be able to let the user know a connection is not available.
  • reset-server is useful when internal resources need to be protected from excessive resource consumption due to half-open sockets.
  • reset-both will provide best user experience and protect servers' resources, but may facilitate malicious use.
  • zone protection will add protective mechanisms that allow a more userfriendly experience while still protecting against abuse.




You can follow the original discussion here reset-client vs. reset-server



Other resources on this topic


Configurable Deny Action

SANS ISC InfoSec Forums

How To Choose an Effective Firewall Policy to Secure your Servers

Drop versus Reject




Feel free to leave a comment below with your own insights.




  • Print
  • Copy Link

Choose Language