This type of protection is deactivated by default because it can reduce performance and frustrate users if it is not correctly configured. Do not activate client denylisting if using a gateway, such as a Unified Access Gateway appliance, which presents all client connections as the same IP address.
If activated, connections from clients on the denylist are delayed for a configurable period before processing. If many connections from the same client are being delayed at the same time, further connections from that client are refused, rather than delayed. This threshold is configurable.
You can activate this feature by adding the following property to the locked.properties file:
secureHandshakeDelay = delay_in_milliseconds
For example:
secureHandshakeDelay = 2000
To deactivate denylisting of HTTPS connections, remove the secureHandshakeDelay entry or set it to 0.
When a TLS handshake over-run occurs, the client IP address is added to the denylist for a minimum period equal to the sum of handshakeLifetime and secureHandshakeDelay.
Using the values in the examples above, the IP address of a misbehaving client is denylisted 22 seconds:
(20 * 1000) + 2000 = 22 seconds
The minimum period is extended each time a connection from the same IP address misbehaves. The IP address is removed from the denylist after the minimum period has expired and after the last delayed connection from that IP address is processed.
A TLS handshake over-run is not the only reason to denylist a client. Other reasons include a series of abandoned connections, or a series of requests ending in error, such as multiple attempts to access non-existent URLs. These various triggers have differing minimum denylist periods. To extend monitoring of these additional triggers to port 80, add the following entry to the locked.properties file:
insecureHandshakeDelay = delay_in_milliseconds
For example:
insecureHandshakeDelay = 1000
To deactivate denylisting of HTTP connections, remove the insecureHandshakeDelay entry or set it to 0.
