====== Blocking "Hackers" ======
===== Definition of "Hacker" =====
For the purpose of this article, the term "hacker" ((Yes, I know there are alternative definitions of Hacker: http://www.mithral.com/~beberg/hacker.html)) refers to automated systems which attempt to login to your Synchronet TCP/IP servers and services using common, well-known, or randomly selected credentials (user names and passwords). These "hackers" are usually not humans sitting at keyboards, typing names and passwords, but rather automated systems (e.g. scripts, a.k.a "robots") which scan the Internet looking for systems with user accounts with guessable credentials and/or known vulnerabilities in their system software. Sort of like a modern version of "[[wp>Wardialing]]".

===== The Risk =====
The truth is, if one of these scripts successfully logged into your BBS as "root" or "admin" or whatever, they wouldn't know what to do: These scripts are most likely expecting to encounter some kind of Unix shell prompt with which they can further interrogate the system for known vulnerabilities or use the system to launch attacks against other hosts on your local network or the Internet. A Synchronet BBS command shell would not provide a favorable environment to these "hacking" scripts, but they don't know that, so they will just continue to blindly probe your ports and rattle your doorknobs. It may be irritating to some, but it's mostly harmless.

==== Denial of Service ====
One thing these attacks can do, though it's usually not their intention, is to tie up your BBS's resources (e.g. Terminal Server nodes for Telnet, RLogin, SSH connections and logins). If you find that your [[server:Terminal]] Server's nodes all are being occupied by "hackers" attempting brute-force logins (or just sitting stupidly idle until disconnected due to inactivity), you can mitigate this problem by setting the ''**MaxConcurrentConnections**'' value in the ''**[BBS]**'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file to a non-zero value which is fewer than the number of BBS nodes you have setup in [[util:SCFG]].

For example, if you have 4 nodes configured in SCFG, then you might want to limit the maximum concurrent connections (from the same client IP address) to 2 (e.g. ''**MaxConcurrentConnections=2**''). IP addresses listed in your ''[[dir:ctrl]]/ipfilter_exempt.cfg'' file are not connection-limited. Clients that are successfully logged into your BBS do not count against the concurrent-connections limit, if one is configured.

The default configuration (in ''[[dir:ctrl]]/[[config:sbbs.ini]]'') contains //no// concurrent-connections limit (i.e. ''**MaxConcurrentConnections=0**'').

This protection mechanism was introduced in Synchronet v3.17 (November, 2016).

Synchronet v3.22 added the ability to //auto-filter// (persistently block) IP addresses that repeatedly hit the per-IP concurrent-connections limit on the Terminal Server — see [[#Concurrent Connection Auto-Filtering]] below.

=== Inactivity ===

One potential annoyance is when dumb bots connect to your BBS terminal nodes and just sit there idle for a long period of time, tying up that node. A couple of counter measures are available here:
  * In Synchronet v3.20 and older, Set the ''inactive_hangup'' setting in the ''[login]'' section of your ''[[dir:ctrl]]/[[config:modopts.ini]]'' file to terminate such //dumb// connections after just a short amount of inactivity (e.g. 30 seconds)
  * Make sure if you're using any "login matrix" or other 3rd party login module, especially those with animated prompts, that they include some kind of user-inactivity timeout and disconnection support((this is a surprisingly common flaw in custom animated pause prompt mods))
  * Synchronet v3.20 added a new configuration option to help with this scenario: SCFG->Servers->Terminal Server->Max User Login Inactivity (default: 10 minutes), also ''MaxLoginInactivity'' in the ''[BBS]'' section of ''[[config:sbbs.ini]]''
  * Synchronet v3.21 added a new configuration option to help with this scenario: SCFG->Servers->Terminal Server->Max Dumb Login Inactivity (default: 1 minute), also ''MaxDumbTermInactivity'' in the ''[BBS]'' section of ''[[config:sbbs.ini]]''
===== Synchronet's Defense =====
Synchronet normally disallows the use of common passwords by users (see the ''[[dir:text]]/password.can'' file) and system operator accounts are protected with a secondary "system password", so there should be little chance of a dictionary-based login attack actually succeeding. You can run ''[[dir:exec]]/badpasswords.js'' (e.g. using [[util:jsexec]]) to check your user database for common passwords if you wish.

Synchronet also disallows the use of common administrative user login names (e.g. ''root'', ''admin''). This is accomplished through the ''[[dir:text]]/[[config:name.can]]'' file.

To protect against "brute force" style attacks, that is, where an attacker may iterate through every possible password for a given user, Synchronet:
  - Will delay a configurable amount of time before responding to failed login attempts (default: 5 seconds, see [[config:sbbs.ini|LoginAttemptDelay]])
  - Will throttle TCP/IP connections from attackers, increasing the configurable delay with each login failure (default: 1 second per failure, see [[config:sbbs.ini|LoginAttemptThrottle]])
  - Can create an entry in the ''[[dir:data]]/hack.log'' file to notify the system operator(s) of the suspicious activity (default: after 10 failed login attempts, see [[config:sbbs.ini|LoginAttemptHackThreshold]])
  - Can temporarily ban (block connections) from an attacking IP address after a configurable number of failed login attempts (default: after 20 failed login attempts, duration: 10 minutes, see [[config:sbbs.ini|LoginAttemptTempBanThreshold]] and [[config:sbbs.ini|LoginAttemptTempBanDuration]])
  - Persistently block all future connections from the attacking IP address by adding an entry to the ''[[dir:text]]/[[config:ip.can]]'' file (default: disabled, see [[config:sbbs.ini|LoginAttemptFilterThreshold]])
  - Limit the number of concurrent connections to the Terminal Server from a common host/client IP address (default: disabled, see [[config:sbbs.ini|MaxConcurrentConnections]])
  - //(v3.22+)// Persistently block (auto-filter) IP addresses that repeatedly hit the per-IP concurrent-connections limit on the Terminal Server (default: disabled, see [[config:sbbs.ini|MaxConConnFilterThreshold]], [[config:sbbs.ini|MaxConConnFilterDuration]], and [[config:sbbs.ini|MaxConConnFilterSilent]])

To do this, Synchronet tracks the source IP address of all failed login attempts. The sysop can list the failed login attempts:
  * In the Synchronet Control Panel for Windows, using the View->Login Attempts... menu option
  * In the Synchronet Console (sbbs), using the ''a'' (show failed login attempts) command

Note:
  * These IP addresses are only tracked during a single continuous invocation of the Synchronet process (rerunning the BBS clears the list and resets any temporary bans in effect)
  * Temporary IP address bans can be cleared (without resetting a server) by using [[config:semfiles#clear_failed_login_list_semaphore_files]]
  * In Synchronet v3.22 and later, the failed-login list (and the per-IP max-concurrent strike counters) can also be cleared at runtime by publishing to the MQTT ''clear'' topic under the corresponding host or server scope.
  * Consecutive failed login attempts with the //same credentials// (name and password) are counted as a //single// failed login attempt
  * When a client successfully authenticates, its IP address is removed from the failed login list (if it exists there)

==== Auto-Blocking ====
=== Temporary Banning ===
To temporarily ban future connections from an IP address that performed multiple consecutive failed login attempts:
  * In the Synchronet Control Panel for Windows, set File->Properties->Security->Failed Login Attempts->Temp Ban Threshold value and Temp Ban Duration...
  * or edit your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file and set the ''LoginAttemptTempBanThreshold'' and ''LoginAttemptTempBanDuration'' values...

... to numbers you are comfortable with.

The default temporary ban Threshold is 20 (failed login attempts) while the default temporary ban duration is 10 minutes.

Note: Setting the Temp Ban Threshold to 0 will disable temporary bans based on failed login attempt counters, but a failed login with a blocked name (from ''[[dir:text]]/name.can'') will still result in an immediate temporary ban, regardless of the Temp Ban Threshold value.

=== Persistent Filtering ===

To persistently block future connections from an IP address that has performed multiple consecutive failed login attempts:
  * In the Synchronet Control Panel for Windows, set File->Properties->Security->Failed Login Attempts->Auto Filter Threshold value... (used to be called "IP Filter Threshold", then "Perm Filter Threshold")
  * or edit your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file and set the ''LoginAttemptFilterThreshold'' value...

... to a number you are comfortable with.  I do not suggest setting this value lower than 10 so that you do not filter the IP address of valid BBS users who simply forgot their password.  You may wish to warn your BBS users that they should not repeatedly attempt invalid passwords or their IP address may be automatically blocked by your system.

The default Filter Threshold value is 0 (disabled).

The //duration// of the persistent IP address filters that area automatically creates is also configurable (default: 0/infinite).

{{:howto:sbbsctrl.3.20.security.png|}}

Note: These ''LoginAttempt'' values may be set in your ''[[config:sbbs.ini]]'' to different values for each Synchronet server/service if you wish, but that's a configuration that most sysops won't need.

See ''[[config:sbbs.ini]]'' for a list of all the failed-login-attempt related configuration settings available.

=== Concurrent Connection Auto-Filtering ===

//(Synchronet v3.22 and later, Terminal Server only.)//

Some bots don't bother attempting logins at all — they simply open many connections from the same IP and then sit at the login prompt, occupying every available node. The per-IP ''MaxConcurrentConnections'' limit (above) caps how many such connections a single IP can hold open at one time, but on its own it doesn't //punish// repeat offenders: as soon as one of their connections drops, they can immediately open a new one to take its place.

Starting in v3.22, the Terminal Server can optionally //auto-filter// (persistently block, via ''[[dir:text]]/[[config:ip.can]]'') any IP that repeatedly bumps into its own per-IP concurrent-connections limit. Each time a new (unauthenticated) connection from an IP is rejected for exceeding the limit, that IP's "strike" counter is incremented; once the configured threshold is reached, the IP is added to ''ip.can'' (or, optionally, the //silent// counterpart ''[[dir:text]]/[[config:ip-silent.can]]'' — see ''Auto-Filter Silently'' below) with an expiration time, and subsequent connections from that IP are dropped before they can occupy a node.

Strike counters are kept in memory only and are cleared on any of:
  * A successful login from that IP
  * A Terminal Server recycle or restart
  * A [[config:semfiles#clear_failed_login_list_semaphore_files|''clear'' semaphore file]] (the same one used to clear failed-login lists)
  * Publishing to the MQTT ''clear'' topic under the corresponding host or server scope

Configure either via SCFG or by editing ''[[dir:ctrl]]/[[config:sbbs.ini]]'' directly:
  * **SCFG -> Servers -> Terminal Server -> Max Concurrent Connections...** opens a submenu with:
    * ''Maximum (Unauthenticated)'' — the per-IP concurrent-connections limit (the existing setting)
    * ''Auto-Filter Threshold'' — number of times an IP must hit the limit before being filtered (0 = disabled)
    * ''Auto-Filter Duration'' — lifetime of the resulting ''ip.can'' entry (default: 1 day)
    * ''Auto-Filter Silently'' — if //Yes//, abuser IPs are added to ''[[dir:text]]/[[config:ip-silent.can]]'' instead of ''ip.can'', so subsequent connections from those IPs are dropped without logging a //blocked// notice (default: //No//)
  * Or, in the ''**[BBS]**'' section of ''[[config:sbbs.ini]]'':
    * ''**MaxConConnFilterThreshold**'' (default: ''0'', i.e. disabled)
    * ''**MaxConConnFilterDuration**'' (default: ''1d'')
    * ''**MaxConConnFilterSilent**'' (default: ''false'')

Setting ''MaxConConnFilterThreshold=0'' disables the auto-filter and preserves the prior v3.21 behavior (connections over the limit are simply rejected, with no follow-up filtering).

As with the failed-login auto-filter, IPs listed in ''[[dir:ctrl]]/ipfilter_exempt.cfg'' are exempt from this mechanism.

=== Web Server Rate Limiting ===

//(Synchronet v3.22 and later, Web Server.)//

The same kind of resource-exhaustion problem affects the [[server:web|Web Server]]: automated scrapers and bots can open a flood of connections and requests, occupying every available client slot (''MaxClients'') and tying up threads and TLS handshakes so that legitimate visitors are turned away.  Increasingly these come from large cloud/hosting ranges and are spread thinly across hundreds of addresses, so a per-IP limit alone never trips.

To mitigate this, the Web Server supports two rate limiters plus an auto-filter:
  * **Connection rate limiter** — caps the number of connections allowed from a client over a time period, enforced at //accept// (before a session thread or TLS handshake is created), so a flood is shed at the cheapest possible point.  Configured via ''MaxConnectsPerPeriod'' / ''ConnectRateLimitPeriod''.
  * **Request rate limiter** — caps the number of HTTP[S] requests from a client over a time period (enforced after each request is parsed).  Configured via ''MaxRequestsPerPeriod'' / ''RequestRateLimitPeriod''.
  * **Subnet aggregation** — optionally counts (and filters) all clients within an IPv4/IPv6 subnet //together//, in CIDR notation, defeating abuse distributed thinly across a provider's range.  Configured via ''RateLimitSubnetPrefix4'' (e.g. ''24'') and ''RateLimitSubnetPrefix6'' (e.g. ''64''); ''0'' counts each host IP separately.
  * **Auto-filter** — a client (or subnet) that exceeds a rate limit ''RateLimitFilterThreshold'' times is persistently blocked by adding its IP or CIDR to ''[[dir:text]]/[[config:ip.can]]'' (or, when ''RateLimitFilterSilent'' is enabled, the //silent// ''[[dir:text]]/[[config:ip-silent.can]]'', which is checked at //accept//), with an expiration of ''RateLimitFilterDuration'' seconds.

Configure either via **SCFG -> Servers -> Web Server -> Rate Limiting...** or by editing the ''**[Web]**'' section of ''[[dir:ctrl]]/[[config:sbbs.ini]]'' directly; see [[server:web]] for the full list of keys.  All limiters and the auto-filter are disabled by default, and IPs listed in ''[[dir:ctrl]]/ipfilter_exempt.cfg'' are exempt.

===== See Also =====
  * [[:howto:|How-To index]]
  * [[:config:sbbs.ini]]
  * [[:config:ip.can]]
  * [[:config:Filter Files]]

{{tag>}}
