| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| howto:block-hackers [2023/12/18 17:16] – [Auto-Blocking] Perm->Auto naming and other updates 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) |
