| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| howto:block-hackers [2023/12/18 17:09] – [Denial of Service] Mention new MaxLoginInactivity setting digital man | howto:block-hackers [2026/01/11 02:06] (current) – [Denial of Service] mention the new MaxDumbTermInactivity option/feature digital man |
|---|
| |
| 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: | 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: |
| * 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) | * 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)) | * 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 Login Inactivity (default: 10 minutes), also ''MaxLoginInactivity'' in the ''[BBS]'' section of ''[[config:sbbs.ini]]'' | * 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'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 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. |
| Note: | 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) | * 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]] |
| * Consecutive failed login attempts with the //same credentials// (name and password) are counted as a //single// failed login attempt | * 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) | * When a client successfully authenticates, its IP address is removed from the failed login list (if it exists there) |
| |
| To persistently block future connections from an IP address that has performed multiple consecutive failed login attempts: | 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->Perm Filter Threshold value... (used to be called "IP Filter Threshold") | * 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... | * or edit your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file and set the ''LoginAttemptFilterThreshold'' value... |
| |
| The default Filter Threshold value is 0 (disabled). | The default Filter Threshold value is 0 (disabled). |
| |
| {{:monitor:sbbsctrl:sbbsctrl.security.png|}} | 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. | 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. |
