Setup a Remote Server

Today we are talking about setting up a server for remote development. If you have ever spun up a server connected to the internet and seen the log, you will see several entries as would-be hackers attempt to probe your system. By default, your system could have the firewall wide open and unnecessary and unexpected services running.

So, how can we protect our system?

First, to eliminate the risk of a hacker attempting to brute force the account using a dictionary attack, we will disable the root account and ensure we can connect using our private key only.

If you are unfamiliar with SSH and how to create a key to authenticate with the server, check out our guide here Getting Started with SSH.

Copy Public Key to Server

To save ourselves from having to remember a long and complicated password, you did use a secure password, didn't you?

We can copy our public key to the server using the ssh copy id command. If you have not yet added your private key to the SSH agent, you should do this now with ssh-add -k ~/.ssh/your_private_key.

Run ssh-copy-id [email protected] to transfer your public key to the server.

If all has gone well and your public key has transferred to the server successfully, we can test the login works with ssh [email protected] -o PubKeyAuthentication=yes

Configure SSH Server

Now we can log in to the server without using a password. We can safely disable passwords and the root account in the file /etc/ssh/sshd_config

If you are using the root account to log in, you should create a new user for everyday use and use sudo to escalate privileges when needed.

Depending on the distribution or cloud provider, you may find the sshd_config file is a default version or already has settings that should restrict access. In this case, the  *.conf files are within the /etc/ssh/sshd_config.d directory.

Files in the sshd_config.d are included in the main sshd_config file to modify the settings without changing the default configuration. A .conf file will make updating OpenSSH easier if your distribution changes the default values in a future update.

To restrict root access to using a certificate and disallow passwords. Set the PermitRootLogin value to prohibit-password, or to block access, set the PermitRootLogin value to no.

To disable password authentication for all accounts, set the value for PasswordAuthentication to no.

PermitRootLogin prohibit-password # allow root access using certificate
PasswordAuthentication no         # do not allow password login

Reload OpenSSH with systemctl reload sshd to apply your configuration changes.

Test that everything works as expected, and you can connect to the server with your key using ssh [email protected] -o PubKeyAuthentication=yes.

Test that passwords are blocked when not using a key with ssh [email protected] -o PubKeyAuthentication=no.

With the user account locked down, we can move on.

Configure the Firewall

A default Linux installation, the firewall is usually installed but not enabled. How you do this will depend on your distribution.

After enabling the firewall, it is a good idea to check that you can still connect to the server before disconnecting your current session.

UFW

The "uncomplicated firewall" is included with the Debian distribution and derivatives as the firewall of choice. The default UFW configuration will block all incoming traffic.

Creating a rule allowing SSH is as easy as running the following command sudo ufw allow ssh.

To enable the firewall and have it start with the operating system, run the following commands.

sudo systemctl enable ufw
sudo systemctl start ufw

Firewalld

Firewalld is the default firewall in Redhat-based distributions like Fedora and CentOS. The gateway to firewalld rules is the application firewall-cmd and uses a slightly more convoluted syntax than the UFW.

sudo firewall-cmd --zone=public --add-service=http --permanent

To enable the firewall and have it start with the operating system, run the following commands.

sudo systemctl enable firewalld
sudo systemctl start firewalld

Fail2Ban

Fail2ban is a popular tool that helps protect servers from malicious attacks by automatically blocking IP addresses that repeatedly make failed login attempts. Here's a beginner's guide to getting started with fail2ban:

1. Installation: Fail2ban is available for many popular Linux distributions and can be installed using the package manager for your system. For example, on a Debian-based system, you can install fail2ban using the following command:sudo apt-get install fail2ban
2. Configuration: Fail2ban uses configuration files to determine how it should monitor logs and which actions it should take in response to repeated failed login attempts. The main configuration file is located at /etc/fail2ban/jail.conf, and you can create custom configuration files in the /etc/fail2ban/jail.d/ directory.
3. Setting up filters: Fail2ban uses filters to determine which log entries are relevant and should be monitored. Filters are defined in separate files in the /etc/fail2ban/filter.d/ directory, and you can create custom filters if necessary.
4. Enabling and starting the service: After you have installed and configured fail2ban, you can enable and start the service using the following commands:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Monitoring

You can monitor the status of fail2ban using the following command:

sudo fail2ban-client status

This will display a list of all active jails and the number of banned IP addresses for each jail.

Unbanning IP addresses

If you need to unban an IP address, you can use the following command:

sudo fail2ban-client set jail_name unbanip IP_ADDRESS

Replace jail_name with the name of the jail you want to modify, and IP_ADDRESS with the IP address that you want to unban.

These are the basic steps for getting started with fail2ban. By using fail2ban, you can help protect your server from malicious attacks and improve its security.