Locking Down a Linux Server - The Entryways

So my main goal for this week was to lock down my Linux servers at home. For the moment, I run two: A Raspberry Pi 3 running Raspbian, and my Synology DS418play which runs DSM. I’ll try to go over security basics that can apply to a wide range of Linux servers, but the bulk of my experience is with Debian-based distros, so if you’re not running Ubuntu, Debian, Linux Mint, or any other Debian derivative, your mileage may vary. These can also apply to other operating systems like Windows and Mac, it just depends on what you do with them.

Depending on what all you run on your servers, you may have various entryways to get in, including a web-based authentication (common on NAS appliances), GUI (whether it be GNOME, KDE, Cinnamon, etc.), SSH, Telnet (please don’t use Telnet), and other items you may not be thinking. It’s wise to think of all the possible ways to access data and secure them.

Telnet

So I’ll start with Telnet, and this one’s simple: Do not use Telnet. Seriously, if you still rely on Telnet in 2019, something’s wrong. You should never use Telnet if at all possible. By default everything under it is plaintext, including authentication. Disable it when possible.

SSH

SSH is the preferred CLI method, so here’s a couple of pointers for securing your SSH environment.

• Disable password-based authentication and switch to a key-based authentication. Is it annoying as hell sometimes? Yes. Does it really increase your security? Yes. If you’re securing systems that include a lot of data, this should be a standard.
  • To accomplish this, edit the /etc/ssh/sshd_config file on your installation and set PasswordAuthentication no. You’ll also need to add your public key to ~/.ssh/authorized_keys, otherwise you’ll lock yourself out of SSH! Once all of that is set, a restart of your machine or a restart of the ssh daemon is needed (systemctl restart sshd).
• Disable the root account and do not use it. It’s another one of those annoying things, but it’s much safer to add your account as a sudoer and sudo your commands. This also prevents you from being an idiot and accidentally running rm -rf / on your machine. At least then you’ll have to actually type in sudo rm -rf / for that to work. Also, don’t do that.
  • A quick-and-easy command to disable the root account would be passwd -l root. This will prevent the root account from being able to log in.
• Change the default port of SSH. Yes, this is more of security-through-obscurity than anything else, but you’d be surprised how many common port scanners will check that port 22 to see if anything happens to run on it. Why not run your SSH on port 23, or port 21, or any other port? You do have 65535 options to choose from, might as well choose your favorite number… unless it’s 22.
  • To change this, you’ll be back in the /etc/ssh/sshd_config file on your system. Find the line that states # Port 22, remove the #, and change the number to what you’d like it to be. Restart your ssh daemon and you’ll be good to go.

GUI

So GUI methods sound a little weird, but this includes any way you see a system with more than just text. This can include accessing it through your favorite X server, through a web interface, and other means. Here’s some things to take a look at to help secure this side of your systems.

• Enable two-factor authentication. This is by far the most common thing you can do to help secure these areas. Whether you use an app on your phone that supports TOTP codes, a hardware token like a Yubikey, or you print out a giant list of one-time-use codes (don’t do that), these methods add the extra step of “what you have” to your “what you know”.
  • Need some recommended apps to hold those TOTP keys? I personally use Authy as it syncs with my phone number. Want something that doesn’t sync and always stays local? Take your pick of Google Authenticator, Microsoft Authenticator, or go the open source route with FreeOTP.
• Change the default port of your administration console. It’s another one of those security-through-obscurity things, but if you run a web interface admin console, it’d be a good idea to change the port from the default setting, as the default settings are likely a quick search away from being found.
  • A good example of this is setting up my Synology server, default ports for admin are 5000 and 5001 (HTTP and HTTPS, respectively). Did I change those? You’re damn right I did.

Other Quick Things to Note

So these are just a few things to think about when securing the so-called entryways to your systems, but here’s a couple of other general items to keep in mind.

• Never expose your SSH port to the Internet. Seriously. If you want to see what it’s like to be port-scanned and potentially DDoS’d, then by all means, but this is a practice that is never recommended.
• Never expose your admin console to the Internet. This is deja vu, really. Insert what I said above here.

Conclusion

So this is just a first port in securing your Linux systems. Later on I may decide to publish more advanced things to think about when securing these systems, as there are many things to think of when making sure your data stays where you want it.