Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

This is an old revision of the document!


Hardening the Synchronet Servers

Hardening a system is the process in which an administrator or systems operator reduces the chance an attacker can either gain access or information from a system. It is recommended that systems be hardened to protect your BBS, your users and your self.

Identifing your version of Synchronet

Use of this document requires you to know which version of the software you are using. To identify what version of Synchro you are using follow these steps:

On linux run: exec/sbbs - The version will be listed on the first line. On Windows: TODO

Why Harden My Server

An Attacker can us various tactics to compromise a system - The reasons for compromising a system can include;

  • Gathering information on the users of the system - this inclused your BBS users, not just you
  • Using the system to attack other systems
  • Gathering data from other systems on the same network

Settings to Harden

Some settings I'm proposing to harden include

  • Displaying of passwords to the Console/Log
    • It is extremely common for people to use the same passwords for multiple things - should someone get access to a password from your system, it's possible that same password could be used on other systems
      • Change: Configuration Value
  • Don't email passwords to users
    • email is not a secure method of transfering information - at any given time it's possible email messages could be intercepted
      • Change: Configuration Value
  • Don't show version information to users/attackers
    • Providing version information to attackers in the form of status or other messages improves their chances of knowing what vulnerabilities the software may contain. It would be possible for an attacker to cross reference the version number provided with the softwares website that lists changes and vulnerabilities.
      • Limit use of: @VER@, @OS_VER@, @COMPILER@, @FULL_VER@, @REV@, @VER_NOTICE@ (Only because it includes the version information)
      • NOTE: @PLATFORM@ should be OK
      • NOTE: Providing the Major Version number should be OK (Version 3)
  • Don't provide internal IP addresses
    • Most times our BBSs are using an internal only IP address (192.168.x.x or 10.x.x.x address) and our modems/routers pass the connection though to these systems. It is consitered best practice to keep that information secure.
      • Limit use of: @LOCAL-IP@ (Use @INETADDR@ or @HOSTNAME@ instead)
  • Don't enable telnet
    • telnet is not a secure method of transferring information - at any given time it's possible telnet sessions could be intercepted (most dangerous during authentication)
      • Change: Configuration Value
  • Don't enable FTP
    • FTP is not a secure method of transferring information - at any given time it's possible FTP sessions could be intercepted (most dangerous during authentication)
      • Change: Configuration Value
  • Don't enable HTTP with basic auth
    • HTTP with basic auth is not a secure method of transferring information - at any given time it's possible HTTP with basic auth sessions could be intercepted
      • Change: Configuration Value
  • Don't enable NNTP
    • NNTP is not a secure method of transferring information - at any given time it's possible NNTP sessions could be intercepted (most dangerous during authentication)
      • Change: Configuration Value
  • Don't enable IRC
    • IRC is not a secure method of transferring information - at any given time it's possible IRC sessions could be intercepted (most dangerous during authentication)
      • Change: Configuration Value
  • Don't enable Finger
    • Finger is not a secure method of transferring information - at any given time it's possible Finger sessions could be intercepted
    • Finger provides information about users, their current online status, and the system. A potential information leak.
      • Change: Configuration Value

Hardening Suggestions for 3.16:

  • Passwords should not be echo'd to the log/console
    • Set SCFG->System->Toggle Options->Echo Passwords Locally to “No”.
    • Alternatively, ensure the log/console is not accessable by untrusted users. Since passwords are stored in plain text, having them also in the log or on the console is not an increase in attack surface if this precaution is taken.
  • Disable passwords being sent in emails
    • Set email_passwords=false in the [login] section of the ctrl/modopts.ini file
  • Disable Showing Version information to clients
    • text/answer.wip (Line: 15, @VER@)

Things to Investigate:

@NUMDIR@ - JS_VER - LIB LIBL - LN - MSG_LIB - SOCKET_LIB

See Also


In Other Languages
Translations of this page: