IP Address Banning

How IP Address Banning Works

Repeated failed sign-ins from one address are banned automatically. It is on by default and it is the platform's main defence against password guessing.

Where to find it

Architect Panel → Security:

• Security Settings — Enable IP Address Banning, Attempts, Monitoring Period and Ban Length
• Blocked IP Addresses — the addresses currently banned

The rule

Three settings define it:

• Attempts — how many failures trip the ban. Ships at 10.
• Monitoring Period — the window those failures must fall within, in seconds. Ships at 600, ten minutes.
• Ban Length — how long the ban lasts, in seconds. Ships at 600.

So out of the box: ten failures from one address within ten minutes earns a ten-minute ban.

Why a window rather than a total

Counting failures within a moving window distinguishes an attack from a bad month. Ten failures in ten minutes is somebody guessing; ten failures spread over a year is an ordinary user who mistypes occasionally, and banning them would be a support call for no security benefit.

Why a temporary ban

A ten-minute ban is devastating to automated guessing — it reduces an attacker to a handful of attempts an hour, which makes any realistic password unreachable — while being a minor inconvenience to a real person who has forgotten their password.

Permanent bans sound stronger and are worse in practice: addresses are shared and reassigned, so a permanent ban eventually blocks somebody innocent, and the list grows until nobody dares prune it.

What it does not stop

Be clear-eyed about this. Blocking by address does not stop:

• An attacker rotating through many addresses, which is cheap and common.
• Credential stuffing that tries one password against many accounts — each account sees one failure, and no address exceeds the threshold.
• Anybody who already has valid credentials.

It raises the cost of the crudest attack. It is a useful layer, not a defence on its own — which is the argument for two-factor authentication and passkeys rather than for tighter thresholds here.

Shared addresses

An office, a school or a hospital may present hundreds of users behind one address. A threshold that is reasonable for an individual can be tripped by ordinary Monday-morning fumbling across a large site.

If you serve users behind large shared connections, watch the block list for addresses that reappear and consider whether the account-level control is doing more of the work.

Worked example

An organisation leaves the defaults in place. A scripted attack tries thousands of passwords against one account; after ten attempts the address is banned, and by the time it lifts the attacker has managed perhaps sixty attempts an hour instead of thousands a second. Nothing is compromised, and no administrator was involved.

Recommendations

• Leave it enabled. The defaults are sensible.
• Do not rely on it alone — pair it with a second factor.
• Watch for shared addresses tripping the rule repeatedly.
• Prefer short bans over long ones.

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.