Console Access

Best Practices for securing access to the Linux console

C05348A3-9AB8-42C9-A6E0-81DB3AC59FEB
           

Linux servers have gained popularity because of the operating system's stability and because they can easily be managed remotely in a “headless” configuration. SSH access is still a widely popular way to manage Linux servers, but as soon as you deploy a server from your favorite cloud provider, a scan of your system logs will show you just how fast and how often hackers will try to SSH into your box. Weak Linux servers are highly prized by hackers to use as a jump point to cover their tracks and hack more valuable targets, to use as bots for distributed denial of service (DDOS) attacks, and even to mine cryptocurrencies.

All cloud providers make it clear that through their shared responsibility model, securing the operating system on a virtual machine is your responsibility! If you are not willing to learn to be a moderately good systems administrator, find a qualified person to help you.

Here are a few guidelines to help you keep your server safe:

  1. The first thing you must do when deploying a server is to patch it. Keep your server patched regularly and often, no excuses!
  2. Don’t allow incoming SSH connections on your server at all unless you absolutely have to. Many cloud providers allow you to get console access to your server via a web console, such as the AWS systems manager. Yes, it can be a bit clunky at times, but it will keep your system safe. Yes, this means that you cannot use SCP to copy files to your system, but if you need this, you’re doing it wrong anyway!
  3. If you must allow incoming connections to SSH, use a security group (or equivalent) and firewall rule to limit access only from your home or office IP address or subnet. Don’t leave it open to the world!
  4. Changing SSH to run on a port other than 22 cannot hurt, but don’t rely on this to keep your server safe, they will find it and do a port scan to discover all open ports.
  5. Never ever ever keep any system with a default password for any applications! The default Raspberry Pi is well known to everyone and you may as well announce that you are running a public server. Obviously, change the default password to a unique and secure passphrase.
  6. Instead of passwords, use SSH keys whenever possible to avoid brute force attacks.
  7. In addition to SSH keys, use a multi-factor (MFA) solution, they are available for free from Google, Duo and other Providers.
  8. Never allow SSH access to the root account. Configure the SSH accounts to require a password to issue sudo commands, if they do gain access to your system, make them work for it!
  9. Run all applications under a service account that doesn’t allow SSH access.
  10. Monitor your server logs frequently, and look for any suspicious processes or signs of unusual activities. It is your responsibility, not the cloud provider’s to do so. While they may alert you of unusual activity coming from your system, they may also ban you and close your account!
  11. Look for serverless options, many people deploy a Linux server because it is what they are most familiar with, there might very well be slightly more complex solutions that don’t involve running your own servers, such as Lambda and Google functions.

I am not at all affiliated with them, but DigitalOcean provides some great guides on how to configure some of these recommendations, such as:

Stay safe out there and Linux responsibly!

Posted Comments: 0

Tagged with:
Ssh