Hardening Ubuntu 18.04 LTS

Just got a new box setup and delivered to me by the company’s IT department. They setup a user-account with sudo privileges and included my public ssh-key. But in case you only have a root account you should create a user-account with sudo privileges yourself:

$ adduser username
$ usermod -aG sudo username

And from your local machine upload your public key:

$ ssh-copy-id -i .ssh/id_rsa user@hostname

So let’s start hardening. First let’s set a new password:

$ passwd

After that I needed to set another hostname, since the one I got from IT was not what I asked for:

$ sudo nano hostname
$ sudo nano hosts
$ sudo reboot 

ssh & sshd

In /etc/ssh/sshd_config set:

PermitRootLogin no 
PasswordAuthentication no 

In /etc/ssh/ssh_config set:

HashKnownHosts yes

firewall

Use a firewall to block all unwanted traffic to your machine. Only open up the ports you want publicly available and limit access to your ssh-port to known IP’s only.

$ sudo ufw allow from 10.2.0.0/16
$ sudo ufw allow http 
$ sudo ufw allow https
$ sudo ufw enable
$ sudo ufw status numbered

unattended updates

Make sure the package is installed and running:

$ sudo apt install unattended-upgrades
$ sudo service unattended-upgrades status

Edit /etc/apt/apt.conf.d/50unattended-upgrades to do only security updates on production machines. Only out-comment the following lines:

"${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
"${distro_id}ESM:${distro_codename}";

Security updates may need dependencies from non-security origins. EMS, or extended security maintenance is for releases that have reached end of life, like 14.04 LTS.

Further you can play with settings like:

Unattended-Upgrade::Mail "your@email.com";
Unattended-Upgrade::MailOnlyOnError "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Doing automatic-reboots at night are at your own risk, I don’t do that on production machines, but really think it is perfectly fine on private, personal and development boxes. And I have never had anything go wrong with them, ever…

Add/edit /etc/apt/apt.conf.d/20auto-upgrades:

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

The unattended upgrades are initiated by your daily crontab, in my case this runs at 06:25 by default, which I think is a little late to also do a reboot, so I changed the time my daily crontab runs by editing /etc/crontab:

# m h dom mon dow user	command
17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly
0  3	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6	* * 7	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6	1 * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Test

$ sudo unattended-upgrades --dry-run --debug

Checkrestart

Another great way to see whether you need to reboot a machine or are just fine with reload/restarting services is the checkrestart command. It is not on the machine by default so you install it yourself:

$ sudo apt install debian-goodies

I added it to my .bash_profile so everytime I log into the machine I get to see which processes still use old versions of upgraded files.

echo 'Type password for checkrestart report'
sudo checkrestart

More stuff…

This list is of course incomplete and could be updated and expended over time… Things like fail2ban or appArmor might be added….

But for now let’s install that LEMP stack!