Manage authentication protection

cPFence v4+ SSH/Dovecot Authentication Protection blocks source IPs after repeated failed SSH or mailbox sign-ins. It requires IPDB protection and is separate from DDoS connection limits and Root Login Monitor.

You need access to the target server and Manage IPDB protection permission. The server must be connected and licensed.

Authentication protection settings for the selected server; identifying values hidden. Select the image for full size; use browser Back to return.

Enable or disable protection

1. Open IPDB Firewall & IP Tools and choose one server in Server scope.
2. Open Settings. Check that IPDB Protection is on.
3. Set SSH/Dovecot Authentication Protection to the intended state, then click Save. The drawer keeps the server selected when it was opened.
4. Read the save result and reopen Settings to confirm the saved state. If it reports an error, check the current state before trying again.

Keep a way back into the server

Keep a working root session or provider console when changing access protection. Turning this switch off stops authentication-failure protection and removes its owned blocks; other IPDB and UFW policies can still restrict access.

Recover a legitimate client’s access

For historical activity, choose the affected scope on System Dashboard, select DDoS & Brute-force Attacks Blocked, and filter the client’s IP with Source → DDoS & brute-force. Read LAST SEEN before checking current policy below; the combined count is not proof of a current authentication block. See shared drawer filters and data meanings.

The combined drawer contains retained DDoS and brute-force records. Identifying values are concealed; check the incident reason and current policy on IPDB before an access change. Select the image for full size; use browser Back to return.

1. Check the client’s IP on the affected server. Compare the incident’s reason and Current policy in IPDB summary → Details.
2. Correct saved passwords or devices repeatedly attempting failed logins. Several users can share one public IP.
3. If an exception is justified, add a narrow IP whitelist, then check access again. Remove the exception when it is no longer needed.

A whitelist is an access exception, not proof that a source is safe. If access remains blocked, investigate the other policy or service error before disabling protection broadly.