Written by m4dz

I recently told you about the choices you have to make for your sysadmin stack. In fact, these choices impact your whole technical chain, from your OS and its setup to the system architecture. It means you have to adjust the cursor between maintaining each element by yourself or relying on a partner to manage them for you.

Securing remote access goes from trivial things to less-understandable points for non-experts. Consider this article as primary guidance, and feel free to browse some links to more in-depth articles¹⁾²⁾.

TL;DR: security is a vast and complex realm of knowledge, and may be complex. If you only want to know how to improve your remote access setup to alwaysdata servers, read the section about using secured methods.

Don’t let anybody enter your home

You run your application on remote servers. It allows you to provide access to your service from anywhere. There’s usually no physical access for you to those machines³⁾. So, you use remote access to those machines. Most of the time, it’s through a remote shell, something like SSH. What SSH does is to provide you access to both a shell and a low-level files-manager on your remote machine. Consider it as a door to your living room. Not taking care of it is a nonsense. Never do this at home, kids.

An important security concern is the way you manage remote access to your production servers. Here too, you may want to do it, or you may prefer to use a service that embeds a secured setup for you. At alwaysdata, we think that using a service that does it for you is often the best choice, but some parts remain for you to handle. Because this part is sometimes difficult to understand and to maintain, we want to give you some advice on how to secure your access correctly.

The right level of security is the one you’re able to understand and to manage. So, to make sure you’ve got all the expertise needed to be safe at home, let’s talk a bit about what you have to know to protect your remote access and to avoid giving anybody access. My goal is not to turn you into a security expert; it is merely to ensure you know the basics (and probably a bit more) about security and why it matters.

Fortunately, common SSH servers come with a default configuration mostly secured. OpenSSH, which is the default SSH server in most platforms, does it. But distributing a default configuration means that maintainers need to address the common use-cases rather than the high-level secured setup. This setup will probably lock out 90% of the malicious users. Think of it as adding a standard robust door to your mansion; it is better than nothing, but it is still not an armored door. We want to consider how to strengthen this default setup.

Be Safe, Be Smart

Securing its remote access implies to take care of a few digital concerns, mainly because you stay in charge of the client parts. Even if you have a properly secured server, you may get into troubles if your client-side protection is too weak. Let’s take a look at your responsibility.

Use SSH Keys to connect

We would recommend using SSH key rather than password authentication for SSH remote access. This way, you can efficiently manage who can access your remote server, on which device, and revoke access in case of emergency⁴⁾. It’s a good idea to have one pair of keys⁵⁾ for each user on each device. It gives you more flexibility to revoke access when a device is lost or stolen, instead of revoking the complete user access.

To know how to generate a secure, updated key, take a look at the ed25519 key format section.

Avoid password connection

Passwords can’t be secured enough to be the only protection against malicious access. You should use a key-based login as mentioned above to make sure that your remote user is protected, e.g., from a brute-force attack that will try to crack your user’s password.

In alwaysdata, the SSH connection using password is disabled by default, and only connections using SSH keys is allowed. You must have to write your public key in the ~/.ssh/authorized_keys file manually⁶⁾. If you need to enable password-access nonetheless (e.g., to transfer your public key first), check the box to authorize connection using password. Please keep in mind that it’s a less-secured method, so turn it off when you don’t need it.

If you run your personal server, after copying your public key on the server, disable password-based login in sshd configuration.

It also seems that some users/administrators think that not protecting their accounts with a password is a good idea. Personally, I think that even the weakest password is better than no password at all. In any case, you must avoid allowing those no-password users to log in remotely without any protection.

We forbid empty passwords on alwaysdata servers.

Use strong passphrases

Using strong keys is essential, but you can’t rely on them without securing them. It means that each SSH key must be passphrase-protected with a unique, dedicated, reliable password. It also applies to your user’s login access, so feel free to use the same method to set up your user’s password.

I have two methods to generate random passphrases in CLI⁷⁾:

You should have openssl rand or gpg (or both) installed on your system. Make sure to check your password resilience against brute-force attacks with the How Secure Is My Password tool. You don’t want a weak password to compromise your whole business security.

Use cryptographic hardware

If you’re concerned about secure remote access, you should consider using certificate client authentication coupled with a hardware device, so you keep it safe from attackers and unaccessible from your computer. You can then use some cryptographic hardware device like Nitrokey Pro or YubiKey 4 to store your keys/certificates and manage the client authentication for you.

Stay up-to-date

Keep your SSH server updated

SSH security breaches are regularly discovered, and patched quickly by the maintainers and contributors of the projects. Keeping your server updated is necessary. It also implies you keep your SSH client up-to-date too. As I’m writing this blog post, the current OpenSSH version is 7.6, released Oct. 3, 2017. Check your current version:

Use SSH v2 protocol

SSH comes in two versions of its protocol. The current, modern one, is the v2. It is more secure, more flexible, and even more-encrypted in all steps of the process. Almost every client has supported the v2 for a long time, so feel free to disable v1 and only serve the latest if you run your server.

For legacy reasons, the v1 was still available on alwaysdata servers. Since the release of OpenSSH 7.6, the v1 protocol is now removed from the codebase (unavailable even in compilation flags), so stay up to date.

Rely on strong SSH Key with ED25519

You can use several key formats for your SSH Keys. Preferably, you should use the ED25519 algorithm, as it is the best choice nowadays regarding security. Yes, it’s relatively new, but it’s well supported in production right now, and as you manage the server side (or rely on a trusted, dedicated partner), compatibility may not be a big deal.

It will:
 — generate a new key
 — -a set the number of rounds for the function derivation to 1000, which increases security but also the login time. If a quick login is critical to you, consider decreasing this value (the default is 16; 100 offers robust protection against brute-force attacks)
 — -t force the format to use the ed25519 algorithm
 — -C identify your key with your username/device

Network protection

This section contains advanced tips for a sysadmin people that want to highly secure their environment. They may or may not apply, depending on your context and your threat models. In fact, the former sections cover most use-cases of remote access. But you may want to reinforce your security.

Firewall the SSH TCP Port

If you always connect from a known set of dedicated IPs to your servers, so it’s useless (and dangerous) to let any incoming connection try to log in. You should restrict SSH login to known addresses in your firewall rules.

Here, we allow connections from the IP 10.111.111.10 (you have to use your own, obviously) to the SSH port 22 in TCP only on the local machine address (192.168.1.12) using iptables⁸⁾. Firewalling can be hard, but it’s one of your stronger defenses against attackers.

Some of our machines, which handle parts of alwaysdata architecture not aimed to be exposed publicly are IP filtered like that. If you’ve got a VPS or Dedicated Server offer, you can activate IP Filtering in your admin panel to ensure only your IPs are available to connect to your servers.

Blacklist SSH crackers and brute-force attackers

One of the problems with attackers trying to get access to your machine is that they will request access a huge number of times. Even if they don’t get access, it will overload your SSH server, maybe slow down your system, and perhaps result in DDoS. To prevent that, you can use your firewall to ban the attackers’ IPs. Indeed, you won’t blacklist them manually. Instead, you can rely on tools like fail2ban, DenyHosts, or a custom rule in iptables or ufw to temporarily ban them.

In alwaysdata architecture, SSH servers are protected by a fail2ban filter.

Change SSH port and limit port binding

OpenSSH listens to port 22 by default. It makes it vulnerable to remote machine attacks because attackers will first try this port to target SSH breaches. If you don’t care about compatibility and use machines you’re comfortable with, don’t hesitate to change the default port and the binding addresses to which the servers are listening to to decrease the attack surface.

Port knocking

This is one of the most fun tips.

It’s a method that forces remote users to try to connect to a series of ports to trigger a rule in your firewall that will open the access for its IP to the SSH port. By default, the firewall rejects connections to the SSH port. Using a dedicated tool (knock), you will contact your server to a sequence of ports. If the series is correct, the firewall is updated, and a new rule is added to allow only your client IP to connect through SSH. Simple, smart, efficient⁹⁾). It uses the knockd tool.

Misc

Here’s our last tips section. Congrats if you read the article so far! It presents some extra setup available to increase a little bit your security. It’s often useless, but it’s a good know-how.

Trust SSH Host Keys

To be trusted by clients, SSH server presents a key that allows you to authenticate it. This key is generated automatically and belongs to the server only. There’s one key per supported algorithm, and they are presented to the client depending on the setup. You can compare this key at your first connection with the one provided in your SSH admin section.

As modern clients support the ED25519 algorithm, your server can serve only this one and disable others to force its use.

In alwaysdata setup, we still keep all formats available for compatibility reasons.

Disable root access

Your root user is the super admin user in your *nix system. It is the one allowed to do everything on the machine, even wipe it entirely¹⁰⁾. So, it should be used _carefully_. Most of the time, you do _not_ need to be rooted to do what you want, and your system permissions must allow you to execute your commands safely. So, it is a good idea to disable the root user access remotely¹¹⁾. This way, even if a malicious user gets access to the server, that user won’t be able to gain root privileges easily.

Idle log out timeout

It can be a good idea to limit the time a user can be maintained in your system without any activity, to prevent later malicious use. Decrease the number of idle connection allowed and the inactivity time to make sure nobody can stay longer than needed.

Chroot users

Users logged in remotely can access the whole system, sandboxed by the system and files permissions. Chroot users in their home directory could be a good idea. Unfortunately, it’s not as trivial as it seems, and it may require relying on tools like rssh. It may be a complicated setup, but if your threat model implies a risk of data leakage, it’s a good idea.

I hope this long blog post allowed you to understand a little bit more about what matters regarding remote access security. As it relies on cryptographic strengths, it may be hard to manage the whole security of your stack by yourself. Pieces of advice here are what they are: safety tips to increase your security. Please never underestimate how hard it is to keep a whole system safe, and never begrudge working with competent partners who are there to help you. One of our job at alwaysdata is to do it for you. We ensure the cursor is correctly adjusted to give you flexibility without compromising security.

If you want to talk a bit about security, I’ll be at Rennes next Mar. 29, 2018 for the Breizhcamp conference to talk about cryptography and development. See you there!