Blocked IP Addresses

Viewing Blocked Addresses

The blocked address list is the register of what is currently blocked and why it got there.

Where to find it

Architect Panel → Security:

• Blocked IP Addresses — the register
• Security Settings — the thresholds that create automatic entries

What an entry records

• The address.
• The time it was blocked.
• A manual flag — whether a person added it or the platform did.

The manual flag is the first thing to check

It separates two completely different situations. An automatic entry means somebody failed to sign in repeatedly — routine, self-clearing, usually uninteresting. A manual entry means an administrator made a decision, and that decision has no expiry attached to it.

When investigating why somebody cannot reach the system, this flag tells you immediately whether to wait or to act.

Reading the list

Look at it as a shape rather than a count:

• A steady trickle of automatic entries — normal background noise on any internet-facing system.
• A sudden burst — an attack in progress, or something that just broke. An integration with a stale credential can generate this as convincingly as an attacker.
• Manual entries you do not recognise — worth asking about. They do not expire, and the reason lives only in whoever added them.

Check it after a report of lock-out

"I cannot get in from the office" is answered here in seconds. The distinction that matters is whether the address is blocked or the account is — they are separate lists and they produce the same complaint.

Automatic entries clear themselves

They lapse when the ban length passes. Removing one by hand is only worth doing when somebody legitimate is waiting.

Manual entries do not

They stay until removed. That is the point of them, and it is also the reason the list needs an occasional review — see the article on removing blocks.

Keep a note outside the list

The register has nowhere to record why a manual block was added. Keep that somewhere durable — a ticket, a security log — because an address with no explanation is one nobody will ever feel confident removing.

Worked example

A user reports being unable to sign in from a branch office. The list shows the branch's address blocked automatically eight minutes earlier. A colleague had mistyped their password repeatedly, and because the whole office shares one address, everybody behind it was affected. It clears on its own two minutes later, and the incident prompts a look at whether the threshold suits sites of that size.

Recommendations

• Check the manual flag first.
• Check both lists — address and account — on any lock-out report.
• Record the reason for manual blocks elsewhere.
• Watch for bursts rather than counting entries.

Manually Blocking an Address

Adding an address by hand blocks it until somebody removes it. It is the right response to a specific, identified source and the wrong response to most other things.

Where to find it

Architect Panel → Security:

• Blocked IP Addresses — where manual blocks are added
• Blocked User Accounts — the account-level equivalent

Architect Panel → Activity:

• Activity Log — evidence for the decision

When it is the right tool

• A single source generating sustained abuse that the automatic rule is not catching.
• An address you have positively identified during an incident.
• A known-bad source you have been told about by somebody credible.

When it is not

A distributed attack is the important case. Blocking addresses one at a time against a botnet is a losing race — you will add entries faster than you can think, and the attack will not notice. That needs handling upstream at your firewall or CDN, which can act on patterns rather than individual addresses.

It is also the wrong tool for a specific user's behaviour. If one person is doing something they should not, deal with their account; blocking their address affects everybody who shares it and does nothing when they move.

Verify the address first

Take it from the platform's own records — the error log, the activity log, the API log — rather than from a report or a screenshot. Addresses are easy to misread and the consequence of blocking the wrong one is locking out someone legitimate with no obvious explanation.

Check what else is behind it

Before blocking, look at whether that address has successful sign-ins from real users. A shared office connection, a mobile carrier gateway or a corporate VPN can carry an attacker and a hundred legitimate users at once, and blocking it stops both.

Manual blocks are permanent by default

Nothing removes them. That is why the list needs a review habit — treat every manual block as temporary in intent, note when you added it and why, and revisit.

Prefer the narrowest action

If the problem is one account, block the account. If it is one address, block the address. If it is a network, that is a firewall matter. Reaching for the broadest available action because it is the easiest to apply is how organisations end up unable to explain their own block lists.

Worked example

During an incident, the API log shows one address making thousands of malformed requests with a revoked credential. It has no successful sign-ins from anybody. It is blocked manually, the ticket records the address, the evidence and the date, and a calendar reminder is set to review it in a month. When the review comes round, the traffic has long stopped and the block is removed.

Recommendations

• Take the address from platform logs, never from a report.
• Check for legitimate users behind it before blocking.
• Handle distributed attacks upstream.
• Record the reason and a review date every time.

Removing a Block

Removing a block takes a moment. Knowing which ones should go is the part that needs a habit.

Where to find it

Architect Panel → Security:

• Blocked IP Addresses — the register
• Security Settings — the ban length automatic entries follow

Automatic entries

Leave them alone. They lapse on their own, and removing one only makes sense when somebody legitimate is waiting and cannot afford to.

If you find yourself clearing automatic blocks regularly, the threshold does not suit your users — fix the setting rather than the symptom.

Manual entries need a review

Because nothing removes them, a manual block outlives the reason for it. Review them periodically — quarterly is enough for most organisations — and for each one ask:

• Do we know why this was added?
• Is that reason still current?
• Is there any evidence of continued abuse from it?

Remove blocks you cannot explain

This is the recommendation people resist, so it is worth the argument.

An unexplained block is not protecting you from anything you can name, and it may be silently breaking access for somebody. Addresses get reassigned; the address that belonged to an attacker two years ago may belong to a customer now, and they will experience your system as simply broken, with nothing to tell them why.

If a block is genuinely still needed, removing it will produce evidence quickly and you can add it back — with a reason this time.

Watch after removing

Check the automatic entries over the following days. A genuinely hostile address will trip the automatic rule again promptly, which both tells you the block was justified and re-blocks it while you decide.

Do not clear the whole list

Tempting when it is long, and a bad idea — it discards the manual decisions along with the noise. Automatic entries clear themselves; there is never a good reason to bulk-delete.

If a user is still blocked afterwards

Check the account list. Address and account bans produce identical symptoms, and clearing one while the other stands is the commonest reason a lock-out "will not go away".

Worked example

A quarterly review finds nine manual blocks. Six have tickets explaining them and remain justified. Three are unexplained and over a year old; they are removed and the list is watched for a fortnight. None reappears — one of them turns out to have been a customer's new office connection, which had been failing silently for months.

Recommendations

• Review manual blocks quarterly.
• Remove anything you cannot explain, and watch afterwards.
• Never bulk-clear the list.
• Check the account list too when a lock-out persists.