DROP or RESET
The difference between the two actions is as old as the time itself. The below article will explore the two in the context of Citrix NetScaler protection features.
The "DROP" action should silently drop the packet without any processing whatsoever. From user expirience perspective the result should be a timeout in the browser. From network perspective the initial TCP SYN packet will timeout. Default timeout 3 seconds, but it doubles each time a SYN attempt fails. It has a maximum number of retransmissions of 5 before the attempt is considered a failure.
The "RESET" action on the other hand will generate a response on TCP session level. The received RST packet depends on the TCP implementation.
Since we're talking about TCP packets, this is all happening on L4.
The rule of thumb states - if it is a trusted network (depending on the definition of trusted network), then use action "RESET". If there is a chance the source ip is malicious use action "DROP". If you're not sure, use "DROP".
You would like to provide slim to no feedback to any thread actors.
Responder Policies - L7 or L4 ?
I thought it was an important question. By the end it will appear less and less valid.
The feature has expressions targetting both L4 and L7:
L4 packet evaluation expression:
CLIENT.IP.SRC.IN_SUBNET(47.10.209.17/24)
L7 packet evaluation expression:
HTTP.REQ.HOSTNAME.SERVER.EQ("alekaf.com")
NetScaler's Actual Behaviour
It is only logical that L7 evaluation cannot heppen without establishing a TCP session. In fact if the service is SSL it will go like this TCP -> TLS -> HTTP -> (L7 expression evaluation). I wouldn't expect "DROP" action to silently drop the packet there. But I would expect it from L4 Policy. Well, there could be other problems like Policy Processing Order (If behind Content-switch). The CS Policy will be evaluated first, then the Responder Policy, hence the HTTP traffic expressions will be evaluated before TCP traffic expressions. What about TCP Load balancers?
All this doesn't matter, because the NetScaler's DROP and RESET behave differently. Contrary on what's written in their documentation - Citrix docs
Below results have been tested with addressable and non-addressable LB vServer (behind CS vServer). The type of the vServer (TCP, SSL) also does not make a difference. The responder acts the same regardless if we evaluate SRC IP or Hostname.
- Responder DROP
TCP Connection will be established and loaded into memory along with TLS handshake:
RST packer with code 8201 will be sent. 8201 is a stray packet. This reset code is triggered when packets are received on a socket that has already been closed. In other words the TCP session no longer is loaded in memory. Dropping the TCP session out of the memory. TCP vServer does not make a difference.
- Responder RESET
TCP Connection will be established and loaded into memory along with TLS handshake again. No surprises here, since the screenshot is from SSL vServer. Although you can argue the L4 expression should be evaluated first. However, configured on TCP vServer it resets the connection almost immediately.
RST packer with code 9814 will be sent. This reset code is used when a request or response matches a Policy Engine policy, whose action is RESET.
- APPFW DROP
Same 8201 Code.
- APPFW RESET
Code 9845 will be issued, which means reset on AppSec policy:
As a conclusion - there is no way to silently DROP the TCP connection given that protection features like IP reputation, APPFW, Geo location blacklisting use same method. The only option left is Extended ACL...
NetScaler Reset Codes could be found here.
Thank you for reading!