Theme
How the Shield protects your server (formerly Protector!)
One of the most popular and appreciated features of Syncplify Server! has always been its automatic block list (formerly called blacklist): the mechanism that recognizes an attacker and refuses its connections. Since version 8.3.0 that mechanism is the Shield, which replaced Protector!, the engine of every earlier version.
The Shield is deterministic and cheap. It watches every listener of a virtual site, counts what each address does before and around sign in, bans the addresses that cross a rule, and refuses a banned address the moment it connects, before any handshake takes place: the connection is closed at the cost of nothing more than the accept. That is what makes it effective against slow, patient attacks as much as against floods.
Strikes and bans
The Shield 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. In a high availability cluster, bans are shared by every node, while strikes are counted on each node separately.
The Shield only ever counts what an address does before and around sign in, plus 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.
The six 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.
The rules are edited on the Shield page of the Admin UI, Rules tab: the failed sign ins rule is always visible, the others sit behind Show advanced rules. Changes apply the moment they are saved, without a restart, on every node of a cluster.
Manual bans, the safe list and the allow list
An administrator can ban an address or a network by hand on the Bans tab, temporarily or permanently, and can lift any ban. A script can ban the address of the session it runs in with 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.
The safe list, on the same page, names the addresses and networks the Shield never bans, whatever they do: your own offices, your monitoring systems, your load balancers and integration partners. A safe listed address is still authenticated normally and is still subject to the allow list. The allow list, which restricts who may connect at all, is a different thing, and the two are often confused: that page explains the difference.
Separately from the rules, every listener holds at most a configured number of open connections in total and per address, counted at accept. These caps protect the server from exhaustion; they are not a judgement on the client and never earn a ban.
Brute force campaigns
Most SSH brute force traffic on the Internet comes from a handful of long running campaigns; the best known, SSHPsycho (also called Group 93 or the Hee Thai campaign, documented by Cisco Talos and tracked by the SANS Internet Storm Center), was for years responsible for the majority of it, and static blacklists of its known networks never stopped it. A campaign of this kind tries a list of usernames with a list of passwords, from many addresses, at a patient pace.
The Shield is built for exactly that pattern. On SSH the username is known before any password is tried, so the username guessing rule bans a scanner that tries accounts you do not have before it gets to authenticate at all; the slow and patient rule catches the ones that pace themselves below the fast rule; the network wide rule bans the whole network once enough of its addresses have struck; and every refused knock while banned makes the ban longer.
Of course, no defense can keep you safe if you have a user named test with the password 123456. Avoid the common username and password combinations that make any SSH or SFTP server inherently vulnerable, and let the password policy of the virtual site (Admin UI, Access enforcement) enforce the complexity rules for you.
Upgrading from Protector!
Versions before 8.3.0 protected the virtual site with Protector!, the automatic block list introduced in v4. Its behavior tiers and thresholds no longer exist: when you upgrade to 8.3.0 or later, the installer migrates the configuration automatically, derives the Shield's failed sign in rule from Protector!'s window, threshold, ban length and compound settings so that the posture you had tuned is kept, gives the other rules their defaults, and converts the existing block list entries into Shield bans. The event handlers are renamed too (OnProtectorStrike to OnShieldStrike, OnBlocklistAdd to OnShieldBan, OnBlocklistHit to OnShieldBanHit), and they are now notifications: a script on them can no longer veto a strike or a ban.
Further reading
The manual is the reference for the Shield: Shield, safe list, allow list explains the rules and the defaults, and Shield covers the page of the Admin UI. If a legitimate client suddenly cannot connect, start from Connection reset by peer.