Tuning the Thresholds
The three settings interact, so changing one in isolation rarely does what you intended.
Where to find it
Architect Panel → Security:
- Security Settings — the three IP banning settings
- Blocked IP Addresses — the effect of your changes
Architect Panel → Activity:
- Activity Log — sign-in activity around a ban
What each one does
- Attempts — sensitivity. Lower catches attacks sooner and catches more real users.
- Monitoring Period — patience. Longer catches slow attacks and accumulates innocent failures.
- Ban Length — cost to the attacker, and to the user who tripped it.
Tighten by lengthening the ban, not by lowering attempts
This is the useful rule. Lowering the attempt count is what generates support calls, because real people genuinely do fail three or four times.
Lengthening the ban costs an attacker a great deal and a real user very little — someone locked out for thirty minutes usually resets their password instead of waiting, which is what you wanted anyway.
Sensible ranges
- Attempts — 5 to 15. Below 5 you will hear about it.
- Monitoring Period — 5 to 30 minutes.
- Ban Length — 10 minutes to an hour. Longer for administrator-only systems.
Change one thing, then wait
Adjust one setting and watch for a week before adjusting another. The effects are visible in the block list and in support volume, and both need a few days to show.
Changing all three at once means that when something goes wrong you cannot tell which change did it.
Read the block list, not just its length
A long list is not automatically a problem, and a short one is not automatically fine. What matters is the shape:
- Many distinct addresses, each banned once — an attack spread across a botnet. Tightening thresholds will not help; each address is already under the limit.
- One address banned repeatedly — either a determined attacker or a large shared connection. Check which before acting.
- Addresses from unexpected countries — worth knowing about, though not conclusive on its own.
Do not tune your way out of a real attack
If you are adjusting thresholds during an incident, you are using the wrong tool. Block the addresses manually, and if the attack is distributed, the answer is upstream — at your firewall or CDN — rather than in these three fields.
Match the setting to the audience
A system used only by staff can be much stricter than one used by the public. If you run both, the stricter posture belongs on the administrative surface, and the general settings should suit the people who will actually trip them.
Worked example
A team finds the ten-minute ban is not deterring a persistent attempt from a small set of addresses. Rather than dropping attempts to three, they raise the ban to an hour and leave attempts alone. The attack becomes pointless within a day, and no legitimate user notices.
Recommendations
- Lengthen the ban before lowering attempts.
- Change one setting at a time and wait a week.
- Read the shape of the block list, not its length.
- Handle live attacks upstream, not in these settings.