Systems based on Linux are relatively secure by default. Not only is the amount of malware just a fraction compared with Microsoft Windows, but the architecture of the operating system helps in defending against common attacks. Still, whatever operating system is in use, weaknesses are introduced quickly. In this article we look at some common practices to improve the security of an Ubuntu system and how we can check it ourselves.
It all starts with data
Usually it's not the operating system nor the application software which is vital to us as users of the system. What really matters to us is the data we create. Photos, written documents, or simply some notes we put into a text file. Security professionals have their holy CIA triad, with Confidentiality, Integrity, Availability as main pillars. Availability is simply having the data available when we want to access it. Creating regular backups is, for example, a method to ensure we can always access our data, even if the primary storage location is lost. Well, this not only makes sense for people who are into security, but also for us! Integrity seems also to be important. We want to make sure that we can access the data, in the same way we stored it in the first place. Saving a document, and after that not being able to read it again, is not making us happy. For this article we have a special look at confidentiality, or, in other words, making sure that only the right people can access our system, our software and our data. As the title suggests, there is a utility named Lynis, which can help us to make the system more secure, and keep it secure.
Who is Lynis and what does she do?
Lynis is six years old, and helps us by performing a security scan of our system. With all the magic involved, we might almost call her a sorcerer. For now, let's call it an audit and hardening tool. The software is open source, free to use and consists of a set of shell scripts. Each script has a specific goal to fulfill, like scanning the available software, performing tests, or providing specific functions to main Lynis script.
Installation
When it comes to installation, most Ubuntu users will directly perform an apt-get install and start using the software. While that's totally fine, we want to make sure that we are using the latest version of Lynis, so we’ll not use the apt-get installation.
To find the latest version, visit to the project website http://cisofy.com/lynis/ and browse to the download section. With wget we download the file, followed by sha1sum to validate the integrity of the download. If the SHA1 hash matches with the hash on the website, our last step would be to extract the downloaded tarball with the tar command.
Commands:
wget http://cisofy.com/files/lynis-1.3.7.tar.gz
sha1sum lynis-1.3.7.tar.gz
tar xfvz lynis-1.3.7.tar.gz
First run
It is time for our first Lynis run and to determine how well this particular system is secured. Move into the directory (cd lynis-1.3.7) and run it from the local directory (./lynis). Lynis will provide the available parameters. The most common ones are -c (check) and -Q (quick). The first one instructs Lynis to run all tests, and the latter is used to skip waiting after each section. If you prefer to check section by section, then use only -c.
For this run we will use the check-all and quick parameters:
lynis -c -Q
Depending on the software installed and the related configurations, Lynis will perform as many tests as needed. Depending on your configuration and software packages, the amount of tests might vary between different runs. On the particular machine used for this article, 144 tests (of 250+) were performed. We can see this number in the logfile, but also at the end of the screen output. The hardening index of this machine was a mere 44, which is considered low.
Hardening the system
Now that we have a first impression on how well our system is hardened (or the lack of) the next step is to determine what actions are suitable for our system. As with all changes to a system, there is some risk involved that it may break something, expected or unexpected. So don't try to fix everything in one go, but apply changes in small steps. As usual, start with the quick wins and then move towards the ones which take more time to implement.
In this case the system seems to be missing security patches, as Lynis found vulnerable packages. As it is a warning, and usually easy to fix, we start with that. When clicking on the Software updater, it notifies us that security patches are available (as expected). That's already something easy to fix, yet very important.
The second warning indicates that Lynis found only one nameserver (or DNS server) configured, or just one that actually works. These servers are used for DNS, which is the engine behind resolving domain names to IP addresses for network communication. While this might be a more serious risk on a server, for our simple desktop one DNS server is fine. If that one stops working, we quickly find out anyways, as we won't be able to browse the web anymore. Servers on the other hand might act in an unexpected way, while we won't always be able to see it. So depending on the role of the system, the warning may be something to seriously consider fixing. In this case we don't mind, and to avoid this warning showing up each time, we can ignore the test in the scan profile.
We edit default.prf and tell Lynis to skip test NETW-2705, which is the ID found at the end of each warning or suggestion line.
default.prf: # Skip one or more specific tests
# (always ignores scan mode and will make sure the test is skipped)
# config:test_skip_always:AAAA-1234 BBBB-5678 CCCC-9012:
config:test_skip_always:NETW-2705:
So now we installed our security updates and told Lynis that we are fine with only one working DNS server, let's do another run.
That is already looking much better! The index not only turned yellow instead of red, it also provided us with additional security due to installing the patches. Since software is usually the weakest link, staying up-to-date with patches from the security repository is important. Ignoring tests won't make a system more secure, but at least it helps us to focus on the things we can really improve.
As dealing with each individual result would make this a very long article, it is more useful to have a look at dealing with suggestions in general. With each suggestion, the primary focus should be on understanding the meaning behind each suggestion. Secondly, the impact and risk of changing pieces of the configuration. Last, but not least, proper testing and making sure the adjustment has no bad influence on the goal of the machine. For example, blocking access to a web server may result in possibly a more secure system, but it won't be able to handle web requests.
Since each system has a completely different purpose, some suggestions might be more suitable for servers, while others apply both to desktops and servers. It is up to you, the user, to decide what suggestions are worth investigating. Others can be ignored in the scanning profile, as shown above.
Useful hints behind each test can be found in the log file (/var/log/lynis.log), which usually shows the related files. Additionally, the related test itself is in the include directory, to determine what the test is looking for. Then there is the CISOfy website with documentation and information about the individual tests themselves. Finally, of course, the Internet. Usually more people will have similar reported suggestions or questions regarding the implementation.
Happy hardening and stay secure!
For more security advice, check out Michaels new monthly security column for FCM.