The first 10 minutes on the server

ABC Security Ubuntu

“ My first 5 minutes on the server ” by Brian Kennedy is a great introduction to quickly securing a server against most attacks. We have several fixes for this manual to complement our full guide . I would also like to explain in more detail some things for younger engineers.

Every morning I check logwatch email notifications and get thorough pleasure by watching a few hundred (sometimes thousands) of unsuccessful attempts to gain access. (Many are quite prosaic - trying to log in as root with a password of 1234 again and again). The general methodology given here is suitable for Debian / Ubuntu servers, which we personally prefer to everyone else. They usually serve only as hosts for Docker containers, but the principles are the same.

On a large scale, it is better to use fully automatic installations with tools like Ansible or Shipyard , but sometimes you just pick up a single server or pick up tasks for Ansible — an instruction is intended for such situations.
')
Note: This help is created as a basic alphabet. It should be expanded and supplemented according to your needs.

Firstly

We don't even have a root password yet. I would like to choose something random and difficult. We use the password manager generator with the maximum complexity settings. Password Manager saves the password and encrypts it, access to it is possible only by a long master password. It provides a couple of redundant security measures (a long, complex random password + password protection with encryption and another long password). You use a password manager or other tools, keep your password safe by using some form of encryption. You only need this root password if you lose your sudo password.

# passwd

* Note: An interesting discussion about root passwords has opened on HN and Reddit . It is worth reading.

Now you should update the repositories and roll out the latest patches. Next will be a separate section on automating the installation of security updates.

apt-get update
apt-get upgrade

Add user

You should never go to the server as root. We follow the same rules when creating users that Brian Kennedy has set, but you can use your own. Our small team did not have problems using a single user for authorization, but in large teams it’s better to create different users with different privilege levels, where only a select few receive sudo privileges.

useradd deploy
mkdir /home/deploy
mkdir /home/deploy/.ssh
chmod 700 /home/deploy/.ssh

Install the default shell for the user deploy, we use bash:

usermod -s /bin/bash deploy

Remember: chmod 700 means that the account owner has rights to read, write and run programs. We are still with root privileges, but after a minute we will run the chown recursively in this folder for the user deploy and the group deploy. Only this user should be allowed to work with the .ssh folder.

Ssh key authentication

We try not to use passwords to log on to the server. There was a lot of controversy about this after Brian's instructions came out, but I am also inclined to agree with this position. Here are a few comments on this:

1. Ssh keys are better than passwords because they contain and require more information.
   
   
2. Passwords can be picked up by brute force. Guessing by the public key is essentially impossible, so that they can be considered completely safe.
   
   
3. What about computer theft? Yes, your private keys are there, but it is easy to revoke the ssh-key; you just need to remove the public key from authorized_keys. You should also protect the secret key with a secure and long passphrase. See next item.
   
   
4. All this works ONLY ON THE CONDITION OF A SAFE AND LONG PASSWORD PHRASE PROTECTING THE KEY. Repeat a second time, because it is critically important.

So let's leave in the past password authentication. Copy the contents of id_rsa.pub ¹ from your local machine to the servers in the file authorized_keys.

vim /home/deploy/.ssh/authorized_keys

Set the correct privileges, guided by the principle of Linux security, known as the principle of minimal privileges :

chmod 400 /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy -R

chmod 400 sets permissions so that only the owner can read the file. Another chown makes the user deploy and the group deploy the owners (recursively) of their home directory. We mentioned this earlier when we set permissions to read, write and execute for the owner of this directory.

Let us come back to this a bit later, when we correctly test our user deploy and sudo to disable root authorization and install authorization only using the ssh key.

Testing the user deploy and installing sudo

We are going to check how the author of the user deploy is happening, while at the same time keeping the ssh connection for root open, just in case. If everything works fine, we use our open root connection to set the password for deploy. Since we disable password authentication, this password will be used when using sudo. Again, we launch the password manager to generate a complex and random password, save it in an encrypted form and inform colleagues (synchronize the encrypted file with the password).

passwd deploy

Installing sudo is easy. Open the sudo file:

visudo

Add the %sudo group under the root user, as shown below. Make sure that all other users and groups are repulsed with comments with the # symbol (users have no prefixes, and groups start with % ). On most fresh installations there is nothing there, just in case.

root ALL=(ALL) ALL
%sudo ALL=(ALL:ALL) ALL

Now add the user deploy to the sudo group.

usermod -a -G sudo deploy

This will give the deploy user access to sudo after entering the password we just created.

Note to the correction: Thanks to the user ackackacksyn on Reddit for the correct remark that you should not add users directly to the sudo list .

Activate ssh key login

The ssh configuration for this machine is stored here:

vim /etc/ssh/sshd_config

You will want to add a few lines there. I think they are quite understandable in their own right. This is the IP address you use to connect. Our company uses a VPN configuration with OpenVPN and cryptographic authentication, so you also need to be authenticated and connected to a VPN to connect to the server.

PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy@(your-VPN-or-static-IP)

Activate all of these rules by restarting ssh services. Probably have to reconnect (do this through the user deploy!).

service ssh restart

Firewall installation

Usually there are two camps. Some use IPtables directly, while others use a convenient interface called ufw , which is a layer above IPtables to simplify the configuration process. A simpler option is usually preferable from a security point of view. DigitalOcean ufw is really good and helps with basic things.

ufw installed by default on Ubuntu, and on Debian it is enough to run the command apt-get install ufw .

By default, ufw should refuse all incoming connections and allow all outgoing, however, it will not start (because otherwise how would you connect?). We will go through and explicitly resolve connections that are considered normal.

First, you should make sure that IPv6 is supported. Open the configuration file.

vim /etc/default/ufw

Set IPv6 to yes .

IPV6=yes

For the remaining ports that we are going to open, you can simply use the ufw tool from the command line, which is very convenient.

sudo ufw allow from {your-ip} to any port 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw disable
sudo ufw enable

The first is a redundant measure that ensures that only connections from our IP address can be connected over SSH (standard SSH port) ² The second and third commands open http and https traffic.

Note: Thanks to chrisfosterelli for noticing that if you are going to set the first rule (and you should do this), then make sure that you have a static IP address or a secure VPN that you are connecting to. A dynamic IP address will leave you without access to the server sometime in the future.

Automatic Security Updates

I like them. They are not perfect, but it's better than missing patches after they are released.

apt-get install unattended-upgrades

vim /etc/apt/apt.conf.d/10periodic

Update this file as follows:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

I generally agree with Brian that it is better to disable regular updates, and leave only security updates. The idea is that it will not be very good if an application suddenly stops working due to updating a package with dependencies, while security updates very rarely create problems with dependencies at the application level.

vim /etc/apt/apt.conf.d/50unattended-upgrades

Edit the file as follows:

Unattended-Upgrade::Allowed-Origins {
"Ubuntu lucid-security";
//"Ubuntu lucid-updates";
};

All is ready.

Fail2ban

fail2ban is a great package that proactively blocks suspicious activity as soon as it is detected. Their wiki says that fail2ban scans the log files (for example, /var/log/apache/error_log ) and bans IP addresses that show suspicious symptoms - too many attempts to enter the wrong password, search for exploits, and so on ... Immediately after installing, Fail2Ban is equipped filters for various services (apache, courier, ssh, etc.).

apt-get install fail2ban

Two-factor authentication

Two-factor authentication is required if we design a system that meets safety standards. Theoretically, if you activate two-factor authentication on top of all other protective measures, then to gain access to the server (through the opening of vulnerabilities in applications), attackers will also have to have:

1. Access to your certificate and VPN access key.
2. Access your computer to get the secret key.
3. Access your passphrase for the secret key.
4. Access your phone for two-factor authentication.

These are many barriers (four) that will have to be overcome. Even if they get root access through sudo, they will have to find the password deploy, which is protected by AES encryption (the fifth barrier).

Install the package.

apt-get install libpam-google-authenticator

To install, run the command and follow the instructions:

su deploy
google-authenticator

Two-factor authentication is very easy to install and adds a nice extra level of security.

Logwatch

This tool is more for fun and monitoring after the fact. Logwatch keeps track of the logs and, in accordance with the settings, sends by mail a daily beautifully structured summary. This is quite entertaining data, and you will be surprised how many attempts to access the server occur every day. I installed it only to show my colleagues how important it is to have good security.

DigitalOcean has an excellent description of installing and configuring Logwatch , but if we want to keep within 10 minutes, then just install it and do a cron job to run it daily and send an email.

apt-get install logwatch

Add cron job.

vim /etc/cron.daily/00logwatch

Add the following line to the cron file:

/usr/sbin/logwatch --output mail --mailto you@example.com --detail high

All is ready

Here you go. After completing all of the above, your main concern and failure point will be your application and services. This is a completely different area.

We are trying to formalize and describe our best practices and processes as much as possible; if you want to learn more, study our repository . Everything is in the public domain, and we continue to replenish it.

---

¹ Make sure that it is `.pub`. It seems very simple, but I met two comrades (both * do not work in our company — they would quickly stop working here) during their careers, who sent me their secret keys (`id_rsa` without the .pub extension) when I asked send the public key. Back to article

² Opinions differ on whether to assign a standard or non-standard port for SSH connections. See here and here the arguments of both sides. Back to article