ActiveManage Docs ← Back to activemanage.co.uk

IP Address Banning

How IP Address Banning Works

The IP banning engine watches every sign-in attempt, password reset request and API call. When it sees a pattern that looks abusive — too many failures from a single source in a short time — it adds the source IP to a temporary block list.

Flow diagram: Request arrives → check IP against blocklist → if blocked return 403 → else process → on failure increment counter → if counter exceeds threshold within monitoring window, add to blocklist for ban duration

The Three Knobs

IP banning is controlled by three settings working together:

  • Attempts — how many failures from one IP trigger a ban (e.g. 10).
  • Monitoring period — the time window over which attempts are counted (e.g. 5 minutes).
  • Ban duration — how long the IP stays blocked once triggered (e.g. 1 hour).

So with the example numbers: 10 failures from the same IP in any 5-minute window = banned for 1 hour. After expiry the counter resets.

What Counts as a Failure

  • Wrong password on sign-in.
  • Wrong 2FA code.
  • Invalid password reset token.
  • API request with invalid credentials.
  • Submissions to anti-bot honeypots.

Examples

  • Brute force: A scanner tries 1,000 password combinations. After 10 failures it's banned for 1 hour. By the time the ban lifts the attacker has moved on.
  • Office NAT: 20 people behind one IP — if one mistypes a password 5 times, the others still have 5 attempts before the IP is banned. Tune monitoring period higher (e.g. 60 mins) for shared NATs.
  • Mobile carriers: Many users share a small pool of carrier IPs. Set thresholds higher and consider geo-aware exceptions.
Note: IP banning is one layer in defence-in-depth. Use it together with account banning (per user), 2FA and breach-list password checks. Each layer catches a different category of attack.

Tuning Attempts, Monitoring Period, and Ban Length

The default thresholds are conservative — they catch obvious attacks while rarely tripping innocent users. For higher-security deployments, tighten them. For consumer apps with shared mobile carriers, loosen them. This article gives concrete tuning recipes.

IP banning settings panel with sliders/numeric inputs for Attempts (10), Monitoring period (5 min), Ban duration (1 hr), and a toggle 'Apply per-username inside one IP'

The Default Numbers

  • Attempts: 10
  • Monitoring period: 5 minutes
  • Ban duration: 1 hour

Tightening (High Security)

For finance, healthcare or administrator-only apps:

  • Attempts: 5
  • Monitoring period: 10 minutes
  • Ban duration: 24 hours
  • Combine with mandatory 2FA and per-username counters.

Loosening (High Volume Consumer)

For a marketplace where many real users share carrier IPs:

  • Attempts: 20
  • Monitoring period: 30 minutes
  • Ban duration: 30 minutes
  • Per-username throttling rather than per-IP catches individual account abuse.

Tuning Process

  1. Look at the blocked IPs log over the last 30 days.
  2. Spot-check the top-blocked IPs to see whether they're real users or attackers.
  3. If many real users are caught, raise attempts or extend the monitoring period.
  4. If attackers are slipping through (many failures per hour but never quite tripping the limit), tighten.

Worked Examples

  • Bank-grade app: 3 attempts, 30 min window, 24 hr ban. Painful for fat-fingered users — that's the point.
  • Mobile-first consumer app: 20 attempts, 60 min window, 15 min ban — generous enough not to lock out shared carrier IPs.
  • B2B internal: 8 attempts, 10 min window, 1 hr ban. Staff have stable IPs and good password managers; misfires are rare.