Securing a Server

Securing a Server

This post will cover securing a Linux server. Back in the day, I started with Red Hat 6 and Slackware 4; I still have a book from when I was learning Red Hat 6. I also ended up learning FreeBSD, but I’ll save that story for another post.

I’m not claiming to be an expert in server security, but if you follow these tips, it’ll be a good start in the right direction. I don’t recommend you learning these things on a production server, because I have locked myself out several times, probably more than I can count. You try these out on a test server; you can create a new DigitalOcean droplet for free if you don’t already have an account.

SSH keys

Ideally, your server is on a speedy network, and the specs are decent. However, this also may help people brute force your passwords. An alternative to using a password is to use an SSH key, they are even more secure that passwords.

An SSH key is much harder, if not nearly impossible, to crack. Quantum computing may change how all encryption and security works, but we don’t need to worry about that right now. Your SSH key can be protected with a passphrase, it will help prevent anyone being able to use your key, or you can have one without a passphrase. It’s a personal preference you may decide which way to do it. They would actually need your private key (file) even to attempt to use it, so don’t give out your private key.

If you want to get access to a server, you can send someone your public key without worrying about any consequences. Before, you would have to call someone or email them your password which can be risky.

Here is a good tutorial on how to setup SSH keys.

ed25519

Some people prefer to use ed25519 keys since they are smaller and faster. These are designed to work with ECDH (Elliptic Curve Diffie-Hellman) key agreement scheme.

I am not a fan of the ECC (Elliptic Curve Cryptography), even though I use it every day. If I recall correctly, a few companies and the NSA all claim they own the patent rights for ECC. I don’t trust something that is faster and smaller that is supposedly more secure. I’ve done quite a bit of research on this, and I understand how it can be smaller and quicker. I don’t have any evidence that it isn’t secure, it’s just speculation.

Change your SSH port

Changing the port SSH listens on can help tremendously. There are lots of botnets that run port scans on the internet every day. They look for standard open ports, like port 22, which is what SSH uses. If they scan your server and see you have that port open, they will then try to brute force your server. If they don’t know what port you’re listening on, then they generally move on.

DigitalOcean has an excellent tutorial on changing your SSH port.

fail2ban

If they don’t move on and they continue to hammer your server, you should create a firewall rule that blocks them. It’s probably impossible to monitor your server(s) 24 hours a day, so I highly suggest you use fail2ban to do it for you. You can configure it to block an IP address after X amount of attempts and for how long. It is highly customizable and one of my favorite things to keep an eye on. When I check my fail2ban stats and see the number of bans, it makes me happy.

This works along with the firewall iptables. Here is a helpful tutorial on getting fail2ban setup on CentOS.

Conclusion

You should employ these suggestions, and I encourage you to research these things on your own. Come to your own conclusions on what is best for you and your infrastructure.

If you decide the methods above are helpful, then that is awesome, but you may require more. You might need to be PCI or HIPAA compliant, and that’ll take more work, so keep researching these topics.

If you’re interested in learning more about ECC, check out this overview of cryptography by Gary Kessler.

Disclaimer

These are suggestions and not fool-proof methods to protect your server. These are some of the things I do when I’m setting up a new server.