# Access Protection

> Who tried to sign in to this server's mail and FTP services, which addresses the authentication broker is refusing, and the settings behind both.

Source: https://www.corepanel.net/docs/security/access-protection/
Last updated: 2026-08-19
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

Mail and FTP are the two doors on a hosting server that face the whole internet and
accept a password. Until now, what came through them left no trace you could read: a
rejected IMAP login was a line in a log file nobody opens, and "when did this mailbox
last work?" had no answer at all.

**Security → Access protection** is that answer. CorePanel's authentication broker checks
every mail and FTP credential on this server, so it is the one process that sees each
attempt *with the client's real address attached* — and it now records them, acts on them,
and lets you undo what it did.

The section has three views:

| View | What it is for |
|------|----------------|
| **Login activity** | The audit trail: every attempt, filterable, newest first |
| **Blocked addresses** | The working list — what is being refused right now, and the way back in |
| **Settings** | Whether the broker may refuse an address, for how long, and the counting behind it |

![The Login activity view of the Access protection section: a header naming the section and marking it available on every edition, a sidebar listing Login activity, Blocked addresses (with a red 2) and Settings, and in the main area four cards reading 1,284 failed logins (up 63% on the previous window), 417 successful logins, 38 source addresses across 21 accounts, and last activity 2 minutes ago. Below them a "Top sources of failed logins" panel lists three addresses with their country flag, failure count, number of accounts tried and services, and under it the event table shows individual sign-ins with time, an Accepted or Rejected pill, service, account, source address and failure reason.](https://www.corepanel.net/_astro/login-activity.C5F5mBNL.svg)

> **Available on every edition**
>
> Seeing who is trying to get into your server is not a paid extra, and neither is stopping
> them: the page, the CLI, the per-mailbox history, the delay applied to whoever is guessing
> and the **block that refuses them mail and FTP** all work on Personal, Pro and Business
> alike, as do the settings behind them. What Pro adds is the **firewall ban** — the same
> decision enforced in the kernel, reaching every port instead of two — through the
> [host firewall](https://www.corepanel.net/docs/security/host-firewall).
>
> The section is shown to **super-administrators only**, on every edition. It spans every
> mailbox and FTP account on the machine, addresses and countries included, which makes it
> a map of the whole server's tenants — not a per-account view — and the release button acts
> server-wide.
## What is never recorded

No password material is ever written to the audit trail: not the value, not a hash, not
its length, not a hint at how close it was. This is a rule the store is built on rather
than a setting you can change, and there is no field to enable.

What each event carries is: when, which service, which account name, the source address,
the country that address resolves to, whether it was accepted, and — on a rejection —
the broker's reason for it (`wrong_password`, `unknown_user`, `account_suspended`).

## The four numbers

The cards at the top cover the selected window (24 hours, 7 days or 30 days), each
compared against the equal span before it:

| Card | What it counts |
|------|----------------|
| **Failed logins** | Rejected sign-in attempts, with the change against the previous window |
| **Successful logins** | Accepted ones, and what share of all attempts they are |
| **Source addresses** | Distinct addresses seen, and how many accounts they touched between them |
| **Last activity** | How long ago the most recent event landed |

All four count **login attempts only**. The broker also handles directory lookups and
certificate requests, and folding those in would make the headline number jump every
time a domain was edited.

## Top sources: one account or many

Below the cards, the addresses with the most rejections in the window, worst first. The
column that decides what to do about a row is not *Failures* but **Accounts**:

- **Failures against one account** are almost always a phone or mail client left with a
  password that has since changed. Blocking that address at the firewall would cut off
  whoever owns the device — often the customer themselves, and often their whole office.
- **The same volume spread across many accounts** is a dictionary run: someone working
  through a list of mailboxes. From three accounts up, CorePanel highlights the count in
  amber, because that is the shape that justifies blocking the address outright.

Sorting by failure count alone would put those two cases side by side with nothing to
tell them apart, which is why the column is there.

Selecting the filter icon on a row scopes the event table below to that address.

## What happens to the addresses that keep guessing

Seeing an attack is half of it. CorePanel also acts on one, and the three things it does are
deliberately very different in weight.

### The delay, on every edition

Once an address has made **10 rejected guesses in five minutes**, its *rejections* start
arriving two seconds late. That is all: a pause before the "no" it was going to get anyway.

It costs a real person nothing, because **a successful login is never delayed**. That is what
makes it safe on the address a whole office shares — the one phone with last month's password
waits two seconds it cannot perceive, and the fifty people working next to it never wait at
all. It needs no licence, no configuration and no firewall: it works on Personal, on a server
with automatic blocking switched off, and on one where firewalld is not running.

Worth knowing where it does the most good. **Dovecot already slows repeated mail failures
down on its own** — two seconds to begin with, escalating to fifteen for an address that
keeps at it — so on IMAP, POP3 and SMTP the CorePanel delay is a small addition to a much
larger one that was always there. **FTP had nothing of the kind**, and that is where these
two seconds are the whole of the protection. What the delay adds on every protocol is the
counting: one place that sees all of them, which is what the decision below is made from.

The number of delayed responses in flight at once is capped, and past the cap the delay is
skipped rather than queued. A tarpit that became the resource exhaustion would have changed
sides.

### The block, on every edition

When an address clears the bar in the table below, CorePanel's authentication broker stops
answering its credential questions altogether. Mail and FTP: `no such user`, immediately, for
half an hour by default. Nothing else — the connection is still accepted, the TLS handshake
still happens, the panel and SSH are never touched, and every website on the server keeps
serving that address normally.

That limited reach is exactly why it can run everywhere. It cannot take a server off the
internet and it cannot lock you out of the page you would undo it from, so it needs no
licence, no firewalld and no adoption — and on a server without those, it is the whole of
the enforcement. Before it existed, an attack on such a server was detected, reported,
recorded on this page, and then left to continue.

**The addresses being refused are listed under Blocked addresses, and you can let any of
them back in.**

![The Blocked addresses view: counters reading 2 denied now and 1 permanently released, a switch to show permanently released addresses, and a table of three rows. The first two are attacking addresses with the time left on their refusal, how many failed logins against how many accounts, the sentence explaining that the firewall did not act, and Release and Release for good buttons. The third row is green, reads Never denied, says it was permanently released by an operator, and offers Undo exemption.](https://www.corepanel.net/_astro/access-protection-blocked.DJYSXKZY.svg)

The **Why the broker, not the firewall** column is the one to read first: every row is
there *because* the firewall did not ban the address, and the reason is always something
about this server — its edition, its configuration, its firewalld — rather than something
about the address.

A release comes in two flavours, and the difference matters when the address belongs to
somebody real:

- **Release** lets it back in now. If it is still guessing it will be blocked again within
  minutes, which is the correct outcome for an address that is actually attacking.
- **Release permanently** also *exempts* it: it will never be blocked here again, however
  much it fails. This is the one to use for a customer's office whose devices all hold the
  wrong password — the case where the failures are real and the attacker is not.

Each entry carries the address's country and its reverse DNS name, resolved in the
background so the list is ready when you open it. **Treat the name as a hint, not an
identity**: it is published by whoever controls the address, which on this page usually
means the attacker.

### The ban, on Pro and Business

Reporting an address to the [host firewall](https://www.corepanel.net/docs/security/host-firewall) is the same
decision enforced somewhere far less forgiving, and it therefore carries an extra bar of
its own. A delay costs one guess two seconds. A block costs one address its mail and FTP.
A firewall ban costs *the whole address* mail, FTP, SSH, the panel and every website on the
server, for up to seven days — and if that address is a shared office or a mobile carrier,
"the whole address" is a lot of people who did nothing.

When the firewall bans an address, the broker does not also block it: two rows to release
instead of one buys nothing on top of a kernel-level rule that already covers both ports.
The broker acts on the cases the firewall does not — a Personal edition, a server that never
adopted firewalld, a firewalld that would not take the rule — and never on the addresses
that must not be touched at all, which are the same in both: the loopback, this server's own
addresses, private and carrier-NAT ranges, and anything on your bastion allowlist.

So all of the following have to be true at once:

| Condition | Why it is there |
|---|---|
| **No successful login from that address in seven days** | One person collecting their mail proves a human being is behind it — on carrier NAT, possibly thousands of them. Nothing outweighs that |
| **At least three different accounts failed** | One mailbox failing forever is a stale password on a device. Many is a dictionary run |
| **Enough volume for the shape it has** — 10 guesses against accounts that **do not exist here**, or 60 against accounts that do, in five minutes; or 20 against accounts that do not exist spread over 24 hours | See below: the shapes are not the same evidence, and neither are the speeds |
| **A globally routable address** | Never the container network, the provider's LAN, carrier NAT, the loopback or this server's own addresses |
| **The audit trail agrees** | Before anything is sent, the case is re-derived from the recorded events — the same rows on this page |

**Why two volumes.** A mail client asks for the mailbox it was configured with. A broken one
asks for a mailbox that *exists*, with the wrong password. Only somebody working through a
list asks, over and over, for mailboxes that were never created here — so that shape has no
legitimate explanation and needs far less of it before CorePanel acts: at one attempt every
two seconds, twenty seconds of guessing is enough.

The other tier keeps a wide margin on purpose, because there its two cases are
indistinguishable. An attacker working from a leaked list of real addresses and an office
whose mailboxes all hold the wrong password produce identical rows — and if every mailbox is
broken, nobody there can sign in to prove otherwise. Banning that customer would add the loss
of FTP, SSH, the panel and their websites to a mail outage they already have, and lock them
out of the page they would fix it from. A slower attacker on that tier is left to the delay
and to your own eyes, which is the right trade when the alternative is guessing wrong about
somebody real.

**Why a day-long window as well.** Both counts above are measured over five minutes, and on
a real server almost nothing trips them. Six days of a production mail server: 1,873 rejected
logins, every single one against a mailbox that was never created there, from 38 addresses —
and **not one of them ever exceeded three failures in any five-minute window**. Eight of them
were a coordinated /24 pacing themselves at roughly one attempt per window each, so that no
burst counter anywhere would ever see them. Those five-minute rules would have reported none
of the 38.

Attackers pace themselves precisely because rate limits are common. So CorePanel also asks
the audit trail a slower question, every five minutes: which addresses have made **20 guesses
against 5 or more accounts that do not exist here, at any speed, in the last 24 hours**. That
one catches 34 of those 38. It is deliberately restricted to accounts that do not exist —
over a day, an office with several broken clients would reach any volume bar against its
*own* mailboxes, but nobody reaches one against mailboxes that were never created.

It changes nothing about the safety rules: an address raised this way goes through every
condition in the table above, including the sign-in immunity. On that production server, the
addresses that succeeded and the addresses that failed did not overlap at all.

That last row of the table is worth understanding, because it is what makes this page the
answer to "why was this address blocked". The running counters only *propose*; the decision
is then rebuilt from the stored events, and if they do not support it — including *which*
shape they support — nothing is reported. It also means a restart can never cause a ban on
evidence it no longer holds.

Everything else the firewall decides — whether this edition may block at all, how long,
whether the operator trusts this signal source, and the addresses that must never be banned
— lives in the firewall's own policy, not here.

> **A successful sign-in protects the address it came from**
>
> This is the single most important rule in the design, and it is worth stating plainly: if
> anyone signs in successfully from an address, that address will not be blocked automatically
> for the next seven days, no matter how much it fails afterwards. An attacker who shares a
> carrier exit with one of your customers keeps getting delayed and stays visible on this page
> — and your customer keeps their mail. Blocking them both would be the worse outcome, every
> time.
Some failures are not counted as guesses at all: a **suspended** mailbox whose owner's client
keeps polling (the password may well be correct), a client that sent no credentials, and
every failure caused by CorePanel itself being unavailable. If those counted, restarting a
service would look like an attack coming from every mail client on the internet.

### The alert that reaches you

An address that clears the bar is also worth an email, and the alert goes out on every
edition whether or not anything banned it — twenty mailboxes tried from one address is
worth knowing on a server whose licence does not include the firewall, and it is the same
sentence either way.

The message names **both** enforcement points, because they answer independently:

```text
Repeated failed mail logins from 178.16.55.216

20 failed logins against 20 different mailboxes in the last 24 hours.

The address is blocked at the authenticator for 30 minutes: it cannot sign in to
mail or FTP while that lasts.
The firewall did not ban it: automatic blocking is part of the Pro edition and above.
```

The middle line is the answer to *"was anything done about it"*. The firewall's half on
its own is not that answer: on a server that never runs one it reads as "nothing was
done" forever, while the address is in fact being refused every credential it asks for.
When the firewall does ban the address, the alert says that instead, with the length of
the ban and how many offences it counted.

The alert is **administrator-only** — a brute-force run against the server is not a
hosting account's business — and repeated reports about the same address fold into a
single entry with a counter rather than one email each. Which severities reach your inbox
at all is under [notification settings](https://www.corepanel.net/docs/notifications).

## Tuning the detection

Every number above is a setting under **Settings**, on every edition: the counting windows, the thresholds
measured inside them, how long the delay is, and how long a block lasts (5 minutes to 24
hours, 30 by default). You can also turn the delay or the blocking off entirely and keep
everything else — the counting, the page, the reporting to the firewall.

**Most servers should change none of it.** These defaults are not conservative guesses;
they were measured against real production mail logs and chosen so that the thing they
refuse to do is block somebody real. Lowering a threshold costs a customer their mail far
more often than it costs an attacker their afternoon, and the failure is quiet: they simply
stop receiving, and open a ticket about something else.

Two of them cannot be lowered past a floor, whatever you type:

- **At least three different accounts.** One mailbox failing forever is a stale password on
  a phone; blocking the address it comes from is the exact mistake this whole design exists
  to avoid.
- **The seven-day sign-in immunity applies regardless.** It is not a threshold and it is not
  optional.

Every field left empty uses the detector's own default, and the greyed number in it is
what that default is — so a form with one number typed into it changes one thing. What the
screen shows back is what the broker reports it is *running*, not what you asked for: the
two differ when a value was clamped, and being told is the point.

The values are stored on the server, so they survive a reinstall of the authentication
broker, and a change reaches it immediately. If a value refuses to change, an environment
variable in the broker's unit file is holding it — the field is marked **Pinned** and says
so, and that override deliberately wins, so a server whose panel cannot be reached can
still be fixed from the shell.

## Filtering the log

The table lists individual events, newest first, and filters by service, account, source
address, country and result. Two details are worth knowing:

- **The default scope is "Logins only".** Switching it to *Everything the broker saw*
  adds the directory lookups, certificate requests and mail-map operations the store also
  keeps. Useful when tracing a mail delivery problem, noise the rest of the time.
- **The country column can be empty.** Country is enrichment, resolved from a local
  database; if that database is missing, the column stays blank and everything else keeps
  working. The page says so rather than leaving you to wonder.

Pagination, page size and the timezone footnote work exactly as on the
[WAF event log](https://www.corepanel.net/docs/security/waf) — the two security tables are deliberately the same
table.

## Per mailbox: recent access

Open any mailbox and go to its **Security** section: under the password and status
controls there is a **Recent access** block with that mailbox's own record — last
successful sign-in, last rejection, how many rejections in total, how many distinct
addresses, and the countries they came from, above the last few events.

This is what answers the support ticket that reads *"my email stopped working"*. Whether
the last accepted sign-in was ten minutes or three months ago, and whether there have
been rejections since, usually settles the question before anyone touches a setting.

The summary spans the mailbox's **whole retained history**, not just the events listed —
"last successful sign-in" would be worthless if it only meant "within the eight rows
shown".

## On the dashboard

The dashboard carries a **Failed logins (24 h)** card naming the worst few source
addresses, so a brute-force run is visible without anyone going looking for it. When one
address is working through several accounts, the card says so in words. Selecting an
address opens this page filtered to it.

The card removes itself when there is nothing to say — a server whose broker keeps no
audit trail shows no tile at all, rather than a broken one.

## Retention, and why the numbers are a floor

Events are kept for **15 days**, or up to 500,000 events, whichever comes first. A server
under sustained attack hits the event ceiling long before the time limit, and the page
says so when it does, naming how far back the history actually reaches.

There is one more honesty note worth understanding. Recording an event must never delay a
login, so when the audit trail falls behind, it **drops events rather than making anyone
wait at the mail server**. If that has happened, the page tells you — and every count on
it is then a floor, not a total. It is the right trade, but only if you know it was made.

## From the command line

The audit trail is available over SSH, which is where you will want it when the panel
itself is what you are worried about:

```bash
corepanel auth stats                    # the window's aggregates, store health, detector
corepanel auth attackers                # worst source addresses
corepanel auth events --result fail     # the raw feed, filterable
corepanel auth user info@example.com    # one mailbox's record
```

`corepanel auth stats` also prints what the detector did — how many responses it delayed,
how many addresses it reported, and how many reports it *withheld* and why. "Nothing was
blocked" has several very different meanings — no attack, no entitlement, an address with a
real user behind it — and they are listed separately rather than added up. It prints the
slow tier's last sweep beside them: how many addresses were caught working through accounts
that do not exist on this server, and when it last looked.

See the [CLI reference](https://www.corepanel.net/docs/cli#corepanel-auth) for every flag.

**The deny list, the release and the settings are panel-only for now.** There is no
`corepanel auth release`, and the shell escape hatch is the calibration rather than the
list: the `COREPANEL_AUTH_*` variables in the broker's unit file will move a threshold or
switch the tarpit off, but nothing there lets an address back in early. What makes that
tolerable is the ceiling — a broker deny lasts at most 24 hours and 30 minutes by default,
and it never touches the panel you would undo it from.