Shield, safe list, allow list
Syncplify Server! protects every virtual site with the Shield, and gives the administrator two lists that shape what it does: the safe list and the allow list. It is important to understand what each of them is for, because they are often confused with one another. Both lists accept:
- single IP addresses, such as
192.168.172.23 - networks in CIDR notation, such as
192.168.172.0/24
The Shield
The Shield is the server's automatic protection against brute force, scanning and abuse. It replaced the Protector in Syncplify Server! 8.3.0.
It works with strikes and bans. A strike is a mark against an address for something it did, for example a failed sign in. Strikes are counted in memory, per address, within time windows. When an address crosses a rule, the Shield bans it for a while and writes the ban to the database. A banned address is refused the moment it connects, before any handshake: the connection is closed at once, at the cost of nothing more than the accept. Bans are shared by every node of a high availability cluster; strikes are counted on each node separately.
The Shield only ever counts what an address does before and around sign in, and a short list of protocol abuse that no real client produces. Nothing an authenticated user does with files, folders or permissions is ever a strike. This covers every listener of the virtual site, the R2FS! port included: a storage node that presents an id-key the site does not know counts as a failed sign in. A site that has no R2FS! id-key configured yet refuses every node and strikes none of them, so a node started before its key was pasted into the site is never banned for it.
The rules
| Rule | What it watches | Default |
|---|---|---|
| Failed sign ins | Failed sign ins by one address within the window. A sign in that succeeds afterwards, from the same address into the same account, forgives its earlier failures. | 5 failures within 20 minutes; ban for 15 minutes |
| Slow and patient | Attempts against accounts that do not exist, and handshake garbage, counted over a much wider window, so that spacing attempts out does not keep a scanner below the fast rule for free. | 20 within 24 hours; ban for 4 hours |
| Username guessing | Distinct usernames that do not exist, tried by one address. On SSH the username is known at the first authentication request, so this fires before any password is tried. | 4 within 10 minutes; ban for 60 minutes |
| Connect and drop | Connections that speak the protocol and hang up without ever attempting to sign in. Connections that never send a byte, such as a load balancer's health checks, are never counted. | 12 within 5 minutes; ban for 30 minutes |
| Network wide | Strikes pooled by network (a /24 or a /64) together with the number of distinct addresses in it. When both cross their threshold the whole network is banned, even if no single address crossed a rule on its own. | 25 strikes and 5 addresses within 30 minutes; ban for 30 minutes |
| Protocol probe | Handshake garbage and deterministic protocol abuse: bytes that are not TLS on a TLS port, SSH port forwarding requests, a second authentication on an FTP control connection, a session channel held open with no subsystem. Each of these strikes the fast rule and the slow one. | Same thresholds as Failed sign ins |
Two more mechanisms apply on top of the rules:
- Extension. Every connection a banned address makes while banned extends a temporary ban by a share of its base length (50 percent by default). A scanner that keeps knocking keeps its own ban alive.
- Escalation. An address that was banned before is remembered for a week (168 hours by default). Each new ban it earns lasts longer than the last: with the default factor of 100 percent, twice as long every time.
No automatic ban, extended or escalated, ever lasts longer than the longest ban (10080 minutes, one week, by default). Permanent bans, which only an operator or a script can create, never expire and are never extended.
A worked example with the defaults: an address fails five sign ins in a few minutes and is banned for 15 minutes. It keeps trying every few seconds; each refused knock adds 7.5 minutes, so by the time it gives up the ban has grown to an hour. It returns the next day and fails five times again: this time the ban is 30 minutes long to begin with, and grows from there.
Operator and script bans
An administrator can ban an address or a network by hand on the Shield page, temporarily or permanently, and can lift any ban. A script can ban the address of the session it runs in through Terminate(true). Bans created this way carry the rule Added by an operator or Added by a script, so they are always told apart from the automatic ones.
Connection caps
Separately from the rules, every listener holds at most a configured number of open connections in total and per address, counted when a connection is accepted and before any handshake. These caps protect the server from being exhausted; they are not a judgement on the client and never earn a ban. The web listener has its own, more generous per address cap, because a browser opens many connections at once.
The safe list
The safe list names the addresses and networks the Shield never bans, whatever they do. Put your own offices, your monitoring systems and your integration partners there.
Three things stay true for a safe listed address:
- it is still authenticated normally, and a wrong password is still a wrong password;
- it is still subject to the allow list;
- health checkers and load balancers belong on it. A monitor that opens connections and closes them, or that completes a TLS handshake for a living, looks like a scanner to any rule; the safe list is where you tell the Shield it is not one.
Each virtual site has its own safe list, on the Shield page. The management console has a separate one, in the Global Configuration, and the nodes of a cluster are exempt from the console's Shield automatically.
The allow list
WARNING
This is, typically, the most misunderstood of the lists, so please read carefully.
If the allow list is left empty, clients (such as FileZilla, WinSCP and so on) can connect to your server from anywhere. An empty allow list is equivalent to no allow list at all, and most administrators run their server that way.
If you add even a single address or network to the allow list, it becomes active and restrictive: the server only accepts connections from the addresses and networks it contains, and refuses every other source at accept, before any handshake. A refused source is not struck and is not banned; it is simply not admitted.
Please use the allow list very carefully.