| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| howto:block-hackers [2023/12/17 21:52] – [Synchronet's Defense] from Permanent to Persistent digital man | howto:block-hackers [2024/05/14 22:11] (current) – [Synchronet's Defense] mention the failed login list sem files digital man |
|---|
| * 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) | * 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'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) |
| 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. | 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. |
| |
| === Permanent Filtering === | === Persistent Filtering === |
| |
| To permanently 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. |
