Well, this title may be a slight lie, actually. This installation of the Antikythera course is going to focus more on a discussion of security, and what is necessary for your web server, and a couple of slightly more advanced methods of securing it. The self hosted/open source community is often populated by individuals who have extreme feelings about security. You may hear, for instance, from certain sources, that you need to take extreme measures to protect your security, or you will surely be hacked. You may be bombarded with terminology, abbreviations, possible scenarios, and defense mechanisms that you can hardly grasp, and feel as though security is an overwhelming topic that you will never fully understand, and therefore shouldn’t try. The mission here is to find that balance between completely secure* and completely insecure. We will call that balance “secure enough” and it’s what we should always be aiming for.
Getting Started with Security
We’re going to jump right in. The first place to get started is by modelling your threat level. One advantage of self hosting is that it removes an enormous security threat: personal data is generally only useful in aggregate. Hackers simply aren’t going to want to spend as much time and effort accessing the data of one or a few individuals, when they can target either gigantic groups like Google and Facebook, or smaller, but still substantial groups like user forums, business websites, and other similar operations. By hosting things yourself, you are removing a huge target from your back right away.
So what types of threats remain? You will have to model this specifically for yourself, but it’s generally safe to assume that there’s at least two parties that are interested in gaining access to your web server:
- Malicious actors indiscriminately looking for financial gain
- Internet vandals
The first category is often from third-world or BRIC countries, and typically involve someone, possibly government funded, setting up a script that randomly tries to hack into every single IP address it encounters, and mine them for financial information which they can then use to enrich themselves. These people usually have limited resources and are indiscriminately looking for the weakest prey. North Korea, for instance, is infamous for this.
The second category is quite similar, but they aren’t necessary interested in financial gain, but rather just destruction for the sake of it. It could be an automated script as well, or it could be that some random teenager with a penchant for computers and networking happens to come across your server while in a destructive mood. This is just the classic “don’t leave your car unlocked” scenario. Some people are just jerks.
The point is, however, that due to the lack of aggregate data, and relative anonymity of our web-server, places it at a significantly lower threat level than large web operations. Therefore, we probably don’t need to go crazy trying to secure everything. However, if you believe you are going to be specifically targeted specifically, then your threat model is slightly different, and you should probably look elsewhere for security advice. That’s not to say that the security measures we will be implementing in this article are poor, but rather, protecting yourself from every security threat is a full-time occupation, and even the best fail constantly. There is no system that is entirely secure.
The first commandment of security, and the most important, is to stay updated. Security is a never-ending cat and mouse game. The hackers expose a new flaw. The developers patch that flaw. The hackers discover another. As software becomes more complex, more opportunities for attack are created. Your best bet to remaining unhacked is to keep all of your software on your server up to date. That applies to the server OS, and any applications running on it. So how do we do this? You should periodically be logging into your server, and updating the software. This is something we do every day for the Human Paradox server, although you could probably get away with once a week or so. That is part of the trade-off between security and convenience that you will have to decide on based on your threat model.
So let’s start by logging into our web server. When you log on, it should tell you how many updates are available, and how many of those are security updates. I haven’t updated my Linode since it was created, and so there is quite a lot of updates pending:
74 packages can be updated. 38 updates are security updates.
So we can see that we should probably update this system. The way to do this in Linux is probably slightly different than you may be used to, but still extremely convenient. Most applications on Ubuntu are installed from packages in repositories specific to your operating system, which in this case is Ubuntu Server 18.04. Developers maintain those application repositories, and when you want to install an application, your server will look it up in those repositories to find it, and install the proper version. When those applications are updated by developers, your server will see that when it scans the repositories. However, your server won’t always know exactly what is in the repositories, unless you tell it to check them for updates. So first we will run the command to update to do that:
sudo apt update
A nice short command. Sudo runs it as root, apt stands for “Advanced Package Tool” and is the program that checks repositories and manages software, and update is telling it to update the repositories on hand so that we know what the most up-to-date software is.You should see it checking the repositories, and then it should tell you how many packages can be updated. On this particular run, mine says 84 packages have updates available, which is 6 more than what it said before I checked.
Now, we want to actually update them. The command for this is very similar:
sudo apt upgrade
The only real difference is that we are saying “upgrade” instead of “update”, telling apt to actually install any updates. This will update the 84 packages that have available updates. Apt will tell you how much hard drive space this will take up, and ask you to enter “y” to confirm. Because this is the first time we are updating, there is quite a lot and so it will take up a substantial amount of space. Some software may ask you for inputs when you update, and you may have to choose or confirm certain settings. However, usually it’s an entirely automated process. Be sure to run these commands often, as they are the first layer of protection you have at your disposal, and also probably the best.
This is a big one. Encryption is a pretty cool technology that solves a lot of problems in a way that many other security devices cannot. If you live in the 21st century, you have almost certainly heard of encryption. And you likely have at least a vague knowledge of how it works. We take sensitive information, and hash, or scramble it. To hash this information, we use a specific function and key. Anything that travels through that function with a specific key can’t be unraveled without that key. Essentially, this is a way of distilling sensitive information down to one simple file: your cryptographic key. Modern encryption is currently virtually flawless. To decrypt something without a key would take longer than the universe has existed. That is because encryption works exponentially. For each additional digit you add, the amount of possibilities increases by a whole power. Indeed, the weakest parts of encryption typically tend to be in its implementation. There may be weak points in the communication between your computer and the encryption method that reveal the unencrypted contents, for instance. That is a good reason why it’s so important to keep your software updated.
One way we can employ encryption to help secure our server is by asymmetric key pairs. The basic idea behind asymmetric key pairs is that one key is public, that anyone can see and interface with. People can use that public key to encrypt things. However, anything encrypted with that public key can only be decrypted by a private key. We can use this to authenticate our login when we connected to our server over SSH. This is generally superior to password based authentication for a variety of reasons. The encryption keys are much longer, and therefore difficult to break, than a password. Also, you don’t have to worry if someone accesses the key stored on your server, because it isn’t useful for logging into the server – you still need that private key to use it, which never leaves your possession.
OpenSSH, which is our SSH server installed on our web server, supports public key authentication. All we have to do is enable it and generate our key pair. To do that, we are going to download PuTTYgen, which can be found on PuTTY’s website: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
Once that is downloaded, go ahead and run it. You should see this screen:
Select RSA, and make sure that it is set to 2048 bits. Then go ahead and click the “Generate” button. Follow the prompt to move your mouse around. This is generating randomness to help ensure no one else has your identical key. Once you have generated your key, go ahead and name it something you can identify it with. I typically use separate keys for each computer, so that if one ever gets compromised or corrupted, I have alternate methods of accessing my server, so I typically name mine after the computer it will be used on. Then, choose a passphrase for the key. This will prevent someone that happens to come across it from using it. Finally, click the “Save Private Key” button, and save the key somewhere that you won’t lose it. That key that you just saved is your private key that you will use to decrypt the public key saved on your server, and tell your server that you are authorized to access it.
Next, copy the public key in the text box at the top of the PuTTYgen window, and paste it into a text editor. We have to place this key on our web server so that we can use the key based authentication. Log into your server if you haven’t, yet, and make sure you are in your user’s home, or ~, folder. We need to make a directory to store our public key in. Go ahead and do that by running the mkdir command:
sudo mkdir .ssh
We’re running this as a root user, and mkdir tells it to make a new directory, or folder. We aren’t specifying where to place this new directory, so it will make it in the directory we are currently in. The “.” at the beginning tells the server to hide this directory so that it isn’t immediately visible when we run ls. Now we need to generate a text file called “authorized_keys” to store our public key in. That text file has to be in the .ssh directory, so we will run a nano command in that directory:
sudo nano .ssh/authorized_keys
This command is telling nano to make a new text file named authorized_keys in the .ssh directory. It should also open the text file for editing. Copy your public key, and paste it into the text file by simply right-clicking in PuTTY where you want to paste it. Then press “Ctrl+X” to save it, double check that the file is named correctly, and press “Enter” to write the file.
Now, we need to enable the public key authentication in our ssh configuration file. So like in the last tutorial, we are going to edit it in nano. However, instead of navigating to the directory to do that, we’re going to take a shortcut, and specify directly to nano what directory the file is in. To do this, run:
sudo nano /etc/ssh/sshd_config
This simply tells nano to look in those directories for the sshd_config file, and saves us a couple of commands to navigate there ourselves. Inside the SSH config file, look for a line that says
We’re going to delete the # comment in front of the line so that it looks like this:
Now, press “Ctrl+X” to save it, press “Enter” to confirm the file name, and then restart our SSH service to force it to reload the configuration file:
sudo service ssh restart
Now, exit your PuTTY terminal, and let’s test it out. In PuTTY, select your saved connection, and click “load” but do not connect. On the left hand side of the screen, you should see what says “SSH.” Click the “+” box next to SSH, and select “Auth.” On the “Auth” screen, click “Browse” and select the private key you saved to your PC with PuTTYgen. Then, in the menu on the left, scroll back up to “Session”, select it, and then save it under your website again. That will update PuTTY to use your private key when connecting.
Now go ahead and connect. Enter your username, and the server should ask you for the passphrase for your key. This is the passphrase you set earlier in PuTTYgen. Enter that, and it will decrypt your key and allow your key based connection:
If it works, there’s only one thing left to do, and that’s disable password-based authentication entirely. Before you do this, you should be warned – if you lose your private key, you will be unable to access your web server. So it’s a wise idea to make a few backups of the file to different places, such as other computers, or flash drives.
To disable public key authentication, go ahead an open up the ssh configuration file again, with:
sudo nano /etc/ssh/sshd_config
Now, we’re interested in finding the
line. Remove the # comment, and change the “yes” to a “no”. The final line should look like this:
Save your file, and reload the ssh service again with:
sudo service ssh restart
and you’re done. We just dramatically increased the security of our server with two pretty simple steps. We also learned about how asymmetric key-pair authentication works, and how to use encryption to make our lives easier. In the next tutorial, we will actually begin installing some software that will make our lives easier, and free us further from the yoke of big tech.
*It should be noted that no server or program or computer is ever entirely secure. If it can be built, it can be hacked. That is why taking a realistic approach to security, and understanding that there will always be a trade-off between security and convenience is so important. Perhaps the best approach you can take is to simply make yourself a harder target than most other people, and hope any malicious actors select the easier opportunity elsewhere.