The best kinds of personal projects are rabbit-holes. While professionally, I usually try to avoid such entanglements, when pursuing a project for my own satisfaction, finding that one discovery leads to another which leads to another can be exciting. A project can continue to grow and evolve as it lets you know just how much you don’t know, or at least have forgotten. It is humbling. It is rewarding. It is fun.
The idea was simple: let’s build a BBS. I was vaguely aware that bulletin board systems or BBSes weren’t quite dead yet. And I had recently read a really good article by a former sysop (BBS system operator) about his experiences operating a BBS as a young man and how he has kept it alive through today. This really reignited my interest. I initially I thought I would just peruse a few BBSes online and amuse myself by connecting some of my old hardware to them and compute like it is 1989. But I figured with a BBS of my own, it would be not only easier to tweak how it worked with my specific vintage hardware, but it would also be a nice window into the world of a sysop. I had used many different BBSes as a kid, but never ran my own, and the thought of finally becoming an operator had an appeal.
Scope defined. That seemed easy enough. But like I said, the best personal projects are rabbit-holes. First I had to brush up on my C programming to do a little customization. Then I had to reacquaint myself with Linux networking and security. I couldn’t forget to set up my own logging and monitoring services. Then there was the actual customization of the BBS itself, learning archaic and obscure BASIC-like scripting languages from the late eighties. Finally I had to connect it to the internet and set up a DMZ.
I spent so much time relearning so much stuff that I hadn’t had to use in years just to learn about and appreciate some old tech that was still new to me. It was great to be reminded of the joy of endless tweaking. And then there were the hours I spent digging through my archives from over thirty years ago to find old text files and shareware to be able to re-share them with a new audience.
So if you are like me and would like a nice “little” project that will allow you to connect with the world as we used to before the internet, it isn’t that hard. But be warned that it can occupy you endlessly in the best kind of way.
First, familiarize yourself with BBSes
Using a BBS is not like anything you know from the modern internet. Not only is a BBS entirely text-based, but it is almost always modularized and built as layers of different menus. These were also the days before standardization so mastering one system does not mean that you are already a master of another. If you have never used a BBS before, knowing a bit about how to navigate a BBS will be immensely useful in understanding how to configure your own. Even if you HAVE used one before, signing in to one today will still be a bit of a shock to your system and is worth it to reawaken some latent muscle memory and forgotten skills.
Download SyncTERM
In their heyday, BBSes were connected via telephone line and you had to actually dial in using a modem (maybe at the screaming fast rate of 2400 baud!). While a few still sit behind a telephone number, most BBSes today are found online and you can connect via the internet.
Since modern OSes don’t bother to support such outdated technologies and protocols, to faithfully reproduce the terminal experience, it is good to have software that remembers how to present the ANSI and ASCII characters of a BBS. SyncTERM is a freely-available client designed specifically for this. It is available for Windows, Mac, and Linux.
SyncTERM handles all kinds of obscure protocols from the height of BBSing and can render whatever ASCII you throw at it. It can even process RIP scripts. And if you know what those are, can we be friends?
Find lists of BBSes online
It is not hard to find lists of BBSes available online today to try out. Many have guest accounts so you can sign in and look around without creating an account. Some are entirely open so you can make your own accounts. Play around, have fun, but be respectful of the local community.
- Read the latest posts to the various forums
- Have a look at the downloads section for shareware
- Have a look at the various “door” games: text-based games from ASCII-graphic minesweeper, to immersive adventure narratives
Decide what you want
Enjoyed yourself? Now you need to figure out what you want.
- If you just want to run your own BBS at home for your own enjoyment and connect machines on your local network, then all you really need to worry about is installing the BBS software and configuring it as you like.
- However if you want to invite others onto your BBS, you will need to configure it as a proper server with the requisite network settings and security hardening. Welcome to my rabbit-hole.
I decided that I wanted the following:
- A BBS that would be accessible from the public internet so I could demonstrate it anywhere and invite friends to join me
- A BBS that anyone could join with restricted access, but would require my approval to fully use
- A BBS that was stripped to its basics, limited to posts, messaging between users, and file up/download
- An onboarding process that required minimal amounts of questions/interactions and gathered as little data as possible
- No inter-BBS communication of extraneous services
The remainder of this document will guide you through the main steps of setting up such a BBS. This document is written for people who are already somewhat familiar with *nix system usage and administration, so doesn’t go into a lot of detail, but rather touches the most important steps. If you don’t have that experience, don’t get discouraged. I try to link to more in-depth resources for every topic, so if you are determined, this is still an entirely doable project.
Gather what you need
You don’t need much to get started. Mostly just a lot of time to spare. In addition to that you will need:
- Synchronet BBS software
- A computer that can run it
I recommend a Raspberry Pi since if you are a tinkerer, you likely already have one lying around anyway, and it has more than enough power to run Synchronet. Additionally, if you decide to open it up to the world or just want to leave it running all the time to be available to yourself, the Pi sips energy compared to a full-sized computer or an old DOS machine.
Get your Pi ready
If you do go for a Raspberry Pi, think about doing a headless install of Raspberry Pi OS or another supported OS. The GUI is completely unnecessary for running Synchronet and the rule-of-thumb in computer security is not to install something if you don’t need it.
Create a BBS user
This is not strictly necessary if you are only playing around with the software and don’t intend to make your BBS available to others to use. But since it is simple to do and is absolutely necessary should you choose to make your BBS public, I recommend just doing it to begin with.
Simply create a user under Linux as you normally would. This use will need to have sudo rights initially in order to be able to build and install Synchronet. You can remove sudo rights after your BBS is up-and-running.
Install Synchronet
Synchronet has some excellent documentation. The reason that I chose Synchronet as my BBS software was not only that it was pretty widely-used in the modern BBS community, but also because it is so well-documented and is actively maintained. You can find the installation instructions for a Raspberry Pi here.
http://wiki.synchro.net/howto:raspbian_install
You should have no problems installing it successfully on your Raspberry Pi if you follow the very good instructions. Just remember to be signed into your Pi as your new user to do so.
Configure Synchronet
Before you start Synchronet or even the Synchronet configuration utility, you should make some configurations in a couple of important initialization files.
sbbs.ini
The ctrl/sbbs.ini file is mainly responsible for defining your port numbers and enabling certain services and sign on options.
http://wiki.synchro.net/config:sbbs.ini
Most importantly, you will need to set all ports it uses to be above 1024 if you don’t want to run Synchronet as root (you shouldn’t) or use setcap to override this (it doesn’t persist if you update Synchronet). Basically, it is easiest if you just set them above 1024 here.
Under the [BBS] section simply change this line.
TelnetPort = 2323You can set it to anything above 1024, but I like 2323 because 23 is the default telnet port and 2323 is easy to remember.
Another line to update is Options.
Options = XTRN_MINIMIZED | NO_HOST_LOOKUP | NO_QWK_EVENTSThis disables host lookups of users and QWK events, which is used for inter-BBS communication. I don’t want either.
In the [Mail], [FTP], [Web], and [Services] sections, set Autostart = false for each since I don’t want external mail service, an FTP server, or to proxy the BBS via a web interface.
In the [UNIX] section, be sure to set User and Group to the user you created on your Pi.
modopts.ini
The ctrl/modopts.ini file is the module options configuration file, which enables and disables many options for the various different parts of the software.
Out-of-the-box, Synchronet runs a LOT of features that you probably don’t want to mess with as you get started such as inter-BBS communications and using a web interface. If you are like me, you just want to telnet in, which means you can turn off a lot of features.
In the [login] section, disable
email_passwords = false
confirm_email_address = false
guest = falseIn the [newuser] section, disable
send_welcome = false
survey = falseIn the [logon] section, disable
show_avatar = false
set_avatar = false
email_validation = falseIn the [chat_sec] section comment out the following with leading semicolons.
;irc_server
;irc_chanelAnd add the following
finger = false
imsg = false
irc = falseComment out everything in the [jsonchat] section with leading semicolons.
Don’t worry if some of that didn’t make sense to you. Mostly we are just disabling extraneous stuff we don’t need for a simple BBS.
Start scfg
exec/scfg is the configuration utility for Synchronet. There are a lot of options here to configure as well. I have outlined the most important to get started with a simple BBS.
Start with the basics under System
- Give your BBS a name.
- Give your BBS a location.
- Set your time zone.
- Define your operator or sysop account name.
- Define a password for the sysop.
- Note that passwords in Synchronet are not case-sensitive.
- You will need this when you first sign in.
Under File Areas and Message Areas you can define the structure of your message boards and file directories. This is not necessary to get started as there are defaults already there.
Under External Programs select Timed Events and disable everything except CHKSPACE and MSGMAINT. This disables a number of automations that SBBS uses to synch with the wider BBS world, which I don’t want.
We disabled displaying a user avatar in the ini files, but Synchronet (since version 3.17) automatically asks a a new users to choose an avatar. Let’s disable this. Under External Programs select Online Programs (Doors) and select System Info and Available Online Programs. Select the Avatar Chooser and toggle the Execute on Event to no. This is not required, but it took me forever to find and I wanted to include it here.
This is about all you need to get started. All of the options available to you are detailed here.
http://wiki.synchro.net/util:scfg
Start Synchronet
exec/sbbs is the executable for Synchronet. It requires no parameters. If everything was set up properly, it should start and log to standard output so you will see what it is doing.
Tapping ? Will show you the options you have to see what Synchronet is doing.
For now, it is up-and-running. Let’s sign in!
Sign in to Synchronet
Use SyncTERM to sign in to your new BBS. Makes sure when you add your BBS to SyncTERM, you specify using telnet protocol and use your custom port (2323). Alternatively you can also just telnet in directly with a telnet client if you want, but the graphics will not render perfectly.
You will first see a splash screen of ANSI art. Here is Vetrauen BBS’s splash screen, the BBS home of Synchronet software.
You will need to create an account. Synchronet assumes that the first account to be created is the sysop, so you will have to provide the sysop password that you defined when you ran exec/scfg.
You will be asked a number of onboarding questions. You can disable these in exec/scfg.
You will notice a lot of splash screens (in their full ANSI glory) and other information messages.
Finally you will arrive at your home screen similar to the following.
Add SBBSCTRL to your environment variables
Before you go any further, it is probably a good idea to add SBBSCTRL to your environment variables. The installation instructions had you set one for your session so starting exec/sfg and exec/sbbs would work, but this will not persist between logins.
You can do this in your own ~/.profile file, but for your server it is probably better to set it system-wide in /etc/profile
Customize Synchronet
Now that you have used Synchronet for a bit, let’t talk about the customizations that I did. To meet the requirement of having a minimally-functional BBS with only the basic options, I needed to start disabling lots of features and updating menus. I also needed to eliminate some of the screens when onboarding. To do this, you need to understand a bit about how Synchronet is structured.
How Synchronet is structured
If Synchronet is well-documented (which it is), it is well-documented in the sense that Linux is well-documented (which it is). That is, its documentation is like man pages. Every article about each feature is pretty exhaustive, but it assumes that you already know everything about about every other feature. So I will try to provide some perspective here.
Synchronet has the following directories.
/sbbs/ctrl/ # Contains critical configuration files
../data/ # Contains the run-time data created during BBS operation
../exec/ # Contains all executables including utility programs for the BBS
../mods/ # Contains user-modified executables, takes precendence over /exec
../nodeX/ # Contains info about connections to that particular node
../text/ # Contains text of menus displayed to users
../web/ # Web server for modern web interface to the BBS
../webv4/ # Modern bootstrap-based web-user interface replacing /web
../xtrn/ # External (door) programs accessible using the BBSYou can find more details about these directories here.
http://wiki.synchro.net/dir:index
The most important for customization are in the text directory, which we will see as we walk through the sign-on process.
Screens
First of all the most important diagram you need getting started is here.
╔═══════════════╗
║ text/answer.* ║
╚═══════╤═══════╝
┌─────┴─────────────────┐ ┌─────┐ ╔═══════════════╗
│ text/banner.* exists? ├─┤ Yes ├─╢ text/banner.* ║
└─────┬─────────────────┘ └─────┘ ╚═══════════════╝
┌───────┴──────────────────────┐
│ Login Prompt (exec/login.js) │
└───────┬──────────────────────┘
┌─────┴─────┐ ┌─────┐ ╔═══════════════╗ ╔═════════════════╗
│ New User? ├─┤ Yes ├─╢ text/sbbs.msg ╟─╢ text/system.msg ║
└─────┬─────┘ └─────┘ ╚═══════════════╝ ╚════════╤════════╝
┌──┴─┐ ╔════════╧═════════╗
│ No │ ║ text/newuser.msg ║
└──┬─┘ ╚════════╤═════════╝
│ ┌─────────┴──────────┐
│ │ Password Selection │
│ └─────────┬──────────┘
│ ┌──────────┴────────────┐
│ │ Default Configuration │
│ └──────────┬────────────┘
│ ╔═══════════════════╗ ┌─────┐ ┌─────────┴──────────┐
│ ║ text/feedback.msg ╟─┤ Yes ├─┤ Feedback Required? │
│ ╚═════════╤═════════╝ └─────┘ └─────────┬──────────┘
│ ┌───────┴───────┐ ┌──┴─┐
│ │ Send Feedback │ │ No │
│ └───────┬───────┘ └──┬─┘
│ ┌─────────┴──────────────────────────┐ │
│ │ New User Module (exec/newuser.js) ├──┘
│ └─────────┬──────────────────────────┘
│ ┌─────────┴─────────┐
│ │ New User Event(s) │
│ └─────────┬─────────┘
┌───────┴────────────┴─────────┐
│ Logon Module (exec/logon.js) │
└───────┬──────────────────────┘
│ ╔═══════════════════════════════════╗
└──╢ text/menu/logon<security-level>.* ║
╚═════════╤═════════════════════════╝
╔══════════╧════════╗
║ text/menu/logon.* ║
╚══════════╤════════╝
╔══════════╧═════════╗
║ text/menu/logon1.* ║
╚══════════╤═════════╝
...
╔══════════╧══════════╗
║ text/menu/logon99.* ║
╚══════════╤══════════╝
╔══════════╧══════════╗
║ text/menu/random*.* ║
╚══════════╤══════════╝
┌────────┴───────┐
│ Logon Event(s) │
└────────────────┘Copied from http://wiki.synchro.net/config:text_files
As you can see, the sign-on process leads the user through many different screens based on .msg files. These screens are maintained in the text directory. The good news is that these are easy to edit.
For example, the first thing that is returned when a user connects to Synchronet is a file named text/answer.msg, which I edited to place the server information before the client and remove mention of my OS version. Then any text/banner.msg is shown. This is a splash screen for the site. And so on. Any of these files can be edited and customized.
More importantly there is a rich set of variables that you can use in them, called at-codes, to insert user or environment data.
http://wiki.synchro.net/custom:atcodes
In this way, you can edit these screens fairly easily. And if you want to skip one, simply delete it or rename it.
You can use a text editor if you need need to edit the text, but if you really want to be able to properly edit the ANSI graphics, you should use an application like PabloDraw, available for Windows, Mac, and Linux.
http://picoe.ca/products/pablodraw/
ANSI art was just the creative use of fixed-width characters. Programs like PabloDraw are easy to learn and are designed to handle such pseudo-graphics.
Menus
Menus are made of two parts: the graphic that is rendered to display the menu and the script that processes the actual input from the user. One is not built from the other, so if you want to customize a menu, you have to do it in both places.
I wanted to remove the QWK messaging option from the main menu. Also, I wanted Q to be the command to sign out or quit the BBS session.
So I had to do two things:
Edit the text/menu/main.msg menu to remove that option. Using PabloDraw, this was as easy as copying everything below that line and pasting it over it. I also had to update the logoff key to Q instead of O.
Then I had to edit the exec/default.src, which is the logic of the main menu. This is written in Baja, a BASIC-like scripting language developed for BBSes. It is easy to use and easy to understand.
https://www.synchro.net/docs/baja.html
I just found the entry for QWK and commented it out and then updated the entry for logoff with Q instead of O.
The only difference is that once a Baja menu is edited, it needs to be recompiled. This is easily done from the same directory with a simple command.
./baja default.scr
Now if I sign back in, I see my changes. And if I enter Q, I log off. If I enter O, it responds with Unrecognized command thanks to the updated exec/default.src file.
As you dig deeper, you will find that some menus are written in JavaScript. These don’t need to be compiled to update. You can customize these as you would any other JavaScript. Be sure to put anything you customize in the mods directory. Scripts here take precedence over those in exec.
In my case, I wanted to prevent sending email outside of Synchronet as well. In Synchronet terms, email is messaging between users within the BBS. Netmail is sending email outside of the BBS using the BBS. I simply commented out the lines in email_sec.js for the option. I then of course had to update the menu as well as we already saw.
Recompiling Synchronet
As you have seen, Synchronet is primarily driven by scripts and menus. You have seen how to customize both already. For most users, this is enough to customize their own BBSes.
At the core of Synchronet, is a lot of C code holding the system of screens and menus together. If you followed the installation instructions, the build script automatically pulls down the source files of Synchronet and you can browse them in repo/src/sbbs3. This source code can be inspected, modified, and rebuilt to your needs.
In my case, I wanted to prevent bots from knowing exactly what software I am running. Since the first line returned by Synchronet is a copyright line including the software version, I wanted to suppress this so bad actors wouldn’t have such an easy time fingerprinting my system. Going into answer.cpp and commenting out the line with the variables VERSION_NOTICE and COPYRIGHT_NOTICE did the trick. All I had to then to do was rebuild Synchronet using the same command from the installation instructions in the sbbs directory.
make install SYMLINK=1 JSINCLUDE=/usr/include/js JSLIB=mozjs185Make it your own
Now that you have a BBS with the features you want, you need to add some data to make it your own.
Of course you can start posting messages in the discussion areas. Remember that you can customize these using exec/scfg. Posting a welcome message as the sysop is always a good idea.
http://wiki.synchro.net/util:scfg:message_areas
You can also add shareware files to download to your files areas. Again, you can customize the various file areas in exec/scfg. To actually upload them easily, you can use the helper utility exec/postfile.js. This is executed with exec/jsexec.
./jsexec postfileWithout passing any parameters, you will be prompted what to do. Just understand that you will need to copy the file that you want to add to your BBS to the necessary directory first in order for postfiles.js to be able to find it. So if you want to post a file to your Text files section and the Humor subsection, you will first need to copy the file to sbbs/data/dirs/text_humor. Then you can run postfile.js.
If the files are on a different machine, use scp to copy data between machines using SSH.
scp ~/my-file-for-bbs.txt bbs-user@192.168.0.2:/home/bbs-user/sbbs/data/dirs/text_humorDecide what you want to do next
Congratulations! You now have a working BBS! At least on your own network. You can log in using SyncTERM on modern hardware in a GUI or just use Telnet on older hardware.
For vintage hardware that only has an RS232 serial interface, there are any number of wifi-to-serial modems out there to connect vintage hardware to your BBS.
https://www.cbmstuff.com/index.php?route=product/category&path=59_66
You can even sign in on your iPad using Termius or similar shell apps.
https://www.termius.com/free-ssh-client-for-ios
If you are happy with that, you can stop here.
But what if you want to invite your friends to join you in the conversation? What if you want to recreate a small community BBS of decades past? Well you need to connect your BBS to the wider world. Though connecting it to POTS (plain old telephone service) is not practical (though still doable), connecting your BBS to the web is the next best thing.
However this does not come without risks. If you haven’t hosted any service on the public internet before, you will need to prepare yourself. Even if you don’t want to share the BBS on the public internet, setting up some of the services necessary to do it can be a fun learning experience if you want to understand Linux system administration a bit better.
Disclaimer: I am not a security expert and the following is given as a starting point for securing your own server, but I am no way guaranteeing this information to be complete or accurate. It is up to you to ensure that your own server is secure.
Hardening your Pi
Hardening is reducing the attack surface of your machine. And reducing the attack surface simply means minimizing the ways someone could compromise your machine. There are many lists on the interwebs about how to go about doing this, but it comes down to a few principles.
- Create a dedicated user for your BBS service.
- Remove the default
piuser. - Always require a password for sudo.
- Uninstall anything you don’t need.
- Keep it up-to-date.
- Secure your SSH connections with RSA key pairs.
- Set up a firewall.
I won’t go into these in depth since there is plenty of documentation already out there. You can find a good overview here.
https://pimylifeup.com/raspberry-pi-security/
Hardening Synchronet
Synchronet itself offers a number of mechanisms to discourage bad actors from messing with your BBS.
One of the most important things to do is disable plain text passwords in your log files.
SCFG -> System -> Toggle Options -> Echo Passwords Locally
http://wiki.synchro.net/howto:hardening
Then you can tweak the settings for when a user is temporarily banned for incorrect passwords. This stops brute force attacks.
http://wiki.synchro.net/howto:block-hackers
Monitoring your Pi
Hardening only takes you so far. You also need to pay attention to what’s going on on your Pi. This involves keeping tabs on your logs.
Start Synchronet as a service
Starting Synchronet as a service means two things: 1) it starts when the Pi starts and 2) it logs using the Linux standard syslog service so your logs are in one place.
Synchronet has documented how to set it up as a systemd service. Just be sure to update any example configurations with the path of your own installation.
http://wiki.synchro.net/howto:systemd
Then you just need to tell syslog to manage Synchronet’s log file.
http://wiki.synchro.net/config:nix#logging
Once complete, you can find the log file under /var/log/sbbs.log with most other system logs.
Keep tabs on things with umonitor
Synchronet provides you with exec/umonitor to show you the current status of your BBS including who is online and what they are accessing. Use open an SSH window into your server and let it run!
You can have umonitor running in a window and use screen to multiplex the terminal and have your log file open at the same time.
https://www.howtogeek.com/662422/how-to-use-linuxs-screen-command/
Install msmpt so your Pi can email you
Wouldn’t it be great if you didn’t have to log in every day to know what happened on your BBS? What if your server could email you the logs?
The built-in mail utility in Linux only sends message to users on the same machine. With mstmp, if you have access to an external SMTP server, you can send email message using it to any email address.
https://www.howtoraspberry.com/2021/06/how-to-send-mail-from-a-raspberry-pi/
Once set up, you can create shell scripts to send you the log on a daily basis using cron.
Install Logwatch
Emailed logs are nice, but there are a lot of logs on one Linux machine, not just the sbbs.log. Wouldn’t a daily digest of the most important logs be nice? That’s where logwatch comes in.
Setting up logwatch is easy. And out-of-the-box is monitors the logs of most standard Linux services.
https://www.techrepublic.com/article/how-to-install-and-use-logwatch-on-linux/
By default, it will also dump a cron script in to /etc/cron.daily so you will get a logwatch digest emailed to you every day. However you will need to change your /etc/logwatch/conf/logwatch.conf configuration to point to your ssmtp setup.
mailer = “/usr/bin/msmtp recipient@email.com”Logwatch by default does not include Synchronet’s log, but logwatch is well-documented and you can add it easily.
/etc/lgowatch/conf/logfiles/sbbs.conf
The log file configurations can be shared between configs and tell them where to find the log files. Yours simply needs to have one line pointing to the location of the log file
LogFile = /var/log/sbbs.log/etc/logwatch/conf/services/sbbs.conf
Every service needs a configuration, this overrides or adds to the general configuration in logwatch.conf and needs to point to a log file configuration file to know where to get the logs and give it a name.
LogFile = sbbs
Title = “Synchronet BBS”etc/logwatch/scripts/services/sbbs
Every service needs a script to parse its log files. The script needs to be an executable and is usually a perl script, but can also be a shell script (as long as its stars with the #!/bin/bash directive or similar so perl knows how to execute it.
To get started, just have a simple cat command without any parameters. Logwatch will pass it the log file when it is executed.
That’s it! Now you will have your Synchronet logs along with all other important system logs emailed you on a daily basis.
Add Synchronet to Logrotate
There’s a lot of information in the sbbs.log file. You won’t want to receive the whole file every day. This is where logrotate comes in. Most default service on Linux use logrotate to, well, rotate logs.
For Synchronet, we want a new log every day, and the previous days to be stored as sbbs.log.1. The next day sbbs.log.1 is copied to sbbs.log.2, the current day’s becomes sbbs.log.1, and the new file is sbbs.log. And so on.
You simply need to drop a configuration file in the /etc/logrotate.d directory as described here.
http://wiki.synchro.net/config:nix#logfacility
Just update the parameters to rotate as often as you would like.
Connect to the internet
In a traditional home network setup, you have your internal network separated from the internet by your internet modem/router. Your modem/router allows out any traffic starting in your network (like you browsing this webpage) and allows in anything that is IN RESPONSE to a request from your network (like my website delivering this page to you on your request). Any other unsolicited requests to your network are denied by your router’s firewall. This is fine since (generally) nothing from the outside should access what is in your network.
However if you want to host a BBS system, people will be sending you unsolicited requests to which you must respond in order to offer the service. But you don’t want to to expose your entire network to the internet.
What you can do is port-forward to your BBS server. This means that you tell your router to let in traffic for only a certain port and then forward that to and only to your BBS server. Settings will vary by modem/router manufacturer. In our case, we need to port forward port 2323 (or whatever you want it to be) to port 2323 on the Pi to allow telnet traffic through to the BBS server.
Disclaimer: I am not a security expert and this information is given as a starting point for securing your own server, but I am no way guaranteeing this information to be complete or accurate. It is up to you to ensure that your own server is secure.
Once you are finished, anyone can access your BBS via telnet://<ipaddress>:2323 Note that the IP address is not of your BBS machine, but your public IP address assigned externally to your modem by your ISP. You can generally find this in your modem’s configuration interface. This is usually a dynamic IP address, meaning your ISP can reassign you a new one at any time. Fortunately Synchronet offers a service to provide you with a stable address you can provide to your users.
http://wiki.synchro.net/module:dyndns
Go the extra mile
With all of that, you are running with your own publicly-accessible BBS! Configurations! You don’t have to do these next steps, but if you want to invest the time, they can give you additional security.
Set up a DMZ
Port-forwarding traffic to your BBS server is sufficient to make it publicly-accessible. However, what happens in the unlikely event that someone compromises your server? They are then already inside your network and could access other resources from there.
What if you created another network between your modem/router and your actual network? This is the idea of a DMZ or demilitarized zone.
Placing your BBS server in a DMZ means that if it is compromised, the threat is limited to the DMZ. This is because your network sits on the other side of the DMZ behind a router or something similar. This means that the compromised server can try to send request to your internal network, but these will be denied since they are not responses to requests that originated within the internal network. But your internal network can still access the internet because it can originate requests intenerally, pass them through the DMZ and to your modem. Any responses are allowed back in because they are responding to an internal request.
That the idea, anyway. DMZs and network topology can become very complicated very easily, but there are countless resources online on how to set one up.
Disclaimer: I am not a security expert and this information is given as a starting point for securing your own server, but I am no way guaranteeing this information to be complete or accurate. It is up to you to ensure that your own server is secure.
Set up fail2ban
fail2ban is very useful to any internet-facing server, not just your BBS. It is a learning service, which monitors your traffic and identifies suspicious activity throttling it and ultimately banning it if necessary.
https://pimylifeup.com/raspberry-pi-fail2ban/
Synchronet has limited built-in facilities to do some of the same things, but fail2ban works at the firewall level for the whole server. It is easy to set up and use and integrates with Synchronet.
http://wiki.synchro.net/howto:fail2ban
You may want to whitelist your own machines so you don’t accidentally get blacklisted by fail2ban if you forget your password a few too many times. If you do, log into the BBS server and do the following.
sudo fail2ban-client statusto get the jail name, fail2 ban creates “jails” for each servicesudo fail2ban-client status JAILto see what is banned.sudo fail2ban-client set JAIL unbanip 0.0.0.0to remove the IP 0.0.0.0 from the banned list
Set up ClamAV
If you are going to allow people to upload and share shareware, you should probably make sure that it is free from viruses not only to protect your users, but your server as well.
https://www.techrepublic.com/article/how-to-install-and-use-clamav-on-ubuntu-server-20-04/
ClamAV has a built-in daemon called freshclam to update the virus database. However the virus scanning program clamscan, only runs on demand. ClamAV is not a continuously-scanning endpoint protection program. So you will need to set up a cron job to run it on a regular basis.
Create a backup
You worked so hard on your BBS, it would be a shame if anything happened to it. You should always have a working and tested backup strategy.
Synchronet itself only needs the contents of the sbbs directory. It contains all configuration and data, so you can simply create a script to back this up. Again there are any number of articles on the internet on how to script a backup of a directory.
https://ubuntu.com/server/docs/backups-shell-scripts
But also consider that you worked hard to configure your server too. It might be good to image the entire SD card of the Pi as well.
Remember, with any backup strategy you want three copies of your data.
- The working copy
- The backup on-site
- Another backup off-site
Take the time to make the copies, maintain them, and test them.
Visit my BBS
After contemplating the implications of the history of BBSes, I of course created my own BBS. If you’d like to sign in, contact me and I will be happy to share the link.