The Center for Internet Security has free guides that will help you secure your systems.


A typical corporate environment may have a broad array of systems, including routers, switches, and firewalls from vendors such as Juniper and Cisco, and operating systems like Microsoft Windows, Mac OS X, Linux, and BSD. You may be using cloud services like Amazon Web Services (AWS) and Microsoft Azure. Some vendors provide great documentation for securing their systems, and some don't. In any case, they would not be consistent in how the information is presented when coming from the vendors directly.

If you want thorough, consistent guidance on how to lock down your systems, consider CIS Benchmarks. We'll have a look at what's in CIS Benchmarks, how to obtain them, and how to use them to increase the security maturity of your infrastructure or home. They cover many of the services and systems you're likely using including all of those listed above.

To get a CIS Benchmark for the system you're interested in securing, browse to CIS' site, and fill in the web form.


The benchmarks take a LOT of work to create and maintain and are available to me for free, so I don't mind giving them my info.

Once you fill out the form, you'll receive an email with a link to their download page.


The download page has volumes of information available to you.

It's broken down into broad categories, then sub-categories, then individual versions.


Let's see how we can use the guide for Ubuntu 18.04 Server to increase the security posture or harden an Ubuntu 18.04 server clean installation.

I scroll through Operating Systems, then Linux, then find Ubuntu 18.04 and click Download.


Opening the downloaded .pdf file, we can see the entire document is devoted to locking down Ubuntu 18.04.


409 pages all about how to secure Ubuntu. Take heart, the Windows 10 guide is over 1,200 pages!

Obviously, you'll want to focus on changing the tasks that pose the highest risk for you first.

At a high level, there are scored and unscored items.


Scored items will affect your benchmark score and will appreciably change the security of your server or workstation. We'll be focusing on server security here.

Next, there are server profiles.


If your server will be exposed to the Internet or houses highly sensitive data, it may make sense to pursue level 2 compliance. Bear in mind, level 2 measures can affect the usability of your server.

There's an awesome free tool you can use to audit your Linux, BSD, or MAC OS X system called Lynis. I've written a separate blog post about using Lynis to evaluate and secure your system. We'll use Lynis to see how our score changes as we implement some of the controls recommended in the CIS Benchmark.

In my opinion, there is diminishing return for the effort in some of the measures available to us. It makes sense to focus on the aspects that can most likely lead to compromise if misconfigured. We'll focus on Secure Shell (SSH) authentication security.


Before doing any of my normal hardening steps on a new server, we'll download and run Lynis to get a baseline.

cd /opt/ then git clone You would have to do this with sudo privileges, but we're running as root which I normally would not be doing.

After the download completes, cd lynis.

To run the scan, ./lynis audit system. Our hardening index was 59.


The higher the number reported for the hardening index, the more secure the server is considered to be.

Scrolling up through the results of the scan, we can see that many of them were related to SSH configuration.


Most of the settings for SSH can be changed in /etc/ssh/sshd_confg which is the SSH daemon configuration file.

We'll make a copy of /etc/ssh/sshd_config then edit the original.

cd /etc/ssh
cp sshd_config sshd_config.00
vim sshd_config

One of the first recommended settings in the CIS Benchmark is setting the log level to Informational.


Looking at the sshd_configuration file, we see under #Logging that LogLevel INFO is there, but is commented out as the line starts with a pound sign #.

To activate that command, delete the # at the start of the line before LogLevel INFO.


At this point, if you wanted to do these one entry at a time and test after each one, you would save the file then restart the SSH Daemon.

systemctl reload sshd

We're going to tune several other settings while here though, then restart the SSH daemon.

We'll make the following changes.

X11Forwarding yes to --> X11Forwarding no
#MaxAuthTries 6 --> MaxAuthTries 4
#IgnoreRhosts yes --> IgnoreRhosts yes
#IgnoreUserKnownHosts no --> IgnoreUserKnownHosts yes
#PermitEmptyPasswords no --> PermitEmptyPasswords no
#PermitUserEnvironment no --> PermitUserEnvironment no
#ClientAliveInterval 0 --> ClientAliveInterval 300
#ClientAliveCountMax 3 --> ClientAliveCountMax 0
#LoginGraceTime 2m --> LoginGraceTime 60
#Banner none --> Banner /etc/

Also, add the following lines to your sshd_config file.

# Added per CIS Benchmarks

NOTE: This deviates slightly from what is in the CIS Benchmark book. Looking at the man page for sshd_config and comparing it to the list provided, I found that is supported while (the one called for in the Benchmark) is not. I opened a support ticket with CIS Workbench to have it corrected on 10 February 2019.

I normally also set PermitRootLogin yes to PermitRootLogin no, but only do this after you've added a non-root user and added that user to the sudo group.

To add a user named theo, you would run adduser theo then step through the prompts, setting a password. I normally leave the rest of the information blank. Then usermod -aG sudo theo to add theo to the sudo group.

You'll also want to add your public key to theo's authorized_keys file in /home/theo/.ssh/ and set permissions on the .ssh folder to 700 and the authorized_keys file to 600. Test that SSH login works and sudo works, then set PermitRootLogin no, restart SSH, and make sure remote access still works for theo before disconnecting your running SSH session. More details can be found at my blog post.

Remember, after any change to /etc/ssh/sshd_config, reload the SSH daemon systemctl reload sshd for your changes to take effect.

OK, after our modest changes to the system surrounding SSH security, let's see what our score is with Lynis.

I'm logged as my new non-root user, theo, so I have to run the command with sudo privileges this time.

cd /opt/lynis
sudo ./lynis audit system


And, just like that, we've gone from a hardening index of 59 to a hardening index of 65! And, those six points are related to a service we'll be using and that is often abused if misconfigured.

You can keep going through the recommendations and making the changes to areas of the operating system that make sense for your server.