Unix

Linux Hardening: Essential Tools for Comprehensive Security Auditing

In this article, we’ll cover the essential tools for Linux hardening—what you might call assessing a Linux system’s security posture and validating configurations from a security standpoint. We won’t just review the tools; we’ll also show practical examples of how to use them.

Be Your Own Auditor: Do‑It‑Yourself Security

Admins—and especially infosec auditors—often have to assess the security of a large number of hosts in a very short time. In the enterprise space, there are dedicated tools for this, such as network vulnerability scanners. I’m sure readers are familiar with everything from the open-source OpenVAS engine to commercial products like Nessus and Nexpose. However, these tools are typically used to find outdated and therefore vulnerable software and then kick off patch management. Moreover, not all scanners account for the nuances of built-in protection mechanisms in Linux and other open-source products. And last but not least, cost matters: commercial tools are usually only feasible for organizations that budget for them.

That’s why today we’ll look at a specialized set of freely available tools that can assess your system’s current security posture, identify potential risks—such as unnecessary services exposed to the internet or insecure default configurations—and even suggest ways to remediate the issues they uncover. Another advantage of these tools is the ability to replicate standard assessment playbooks across farms of any number of Linux systems and build an auditable body of evidence in the form of logs and standalone reports.

Practical Aspects of Security Auditing

Viewed through an auditor’s lens, testing approaches fall into two categories.

First is compliance with so‑called compliance requirements: verifying that mandatory security controls defined by an international standard or best practice are in place. Classic examples include PCI DSS for payment IT systems, SOX404, NIST-800 series, and MITRE.

Second is a purely rational approach, guided by the question “What else can we do to improve security?” There are no mandatory requirements here—just your knowledge, a clear head, and skilled hands. For example, upgrading the kernel and/or application packages, enabling volume encryption, enforcing SELinux, and configuring the iptables firewall.

Everything that falls under the second approach is commonly referred to as Hardening, which can be described as “measures aimed at strengthening the baseline security of an operating system (or application), primarily using built-in capabilities.”

Compliance is typically assessed when preparing for mandatory audits like PCI DSS or other certification audits. Here, we’ll focus on the hardening aspect. Most major vendors publish Hardening Guidelines for their products—documents with advice and best practices for strengthening security using built-in controls and product specifics. For example, such guides are available from Red Hat, Debian, Oracle, and Cisco.

[ INFO

Hardening is an infosec term for securing a system or application by minimizing vulnerabilities—typically using only built-in utilities and security features.

By the way, Hacker already had a similar article about configuring Hardening options, but it focused purely on setup. We’ll first check the system with specialized utilities—that is, run a security audit and assess the current security posture—and only then enable the necessary security options. Alternatively, if the server is already hardened, our tools can verify that and possibly suggest further improvements.

Tools Overview

1. Lynis — auditing, system hardening, compliance testing

Lynis is first on our list and arguably the most feature-rich Linux auditing tool. Despite that, it’s very easy to use and highly transparent—every test and its result is shown on screen. The utility scans your current security settings and assesses the system’s hardening state. Any warnings and critical security alerts are printed to the terminal and also saved to a separate log file, grouped by category. Beyond security insights, Lynis can also report general system information, details about installed packages, potential configuration issues, and kernel update status.

The developers claim support for a wide range of operating systems: from Arch, BackTrack, and Kali to various flavors of Debian/Ubuntu, RHEL/CentOS, and SUSE; the BSD family (FreeBSD, NetBSD, OpenBSD, DragonFly BSD); as well as more exotic platforms like HP-UX, Solaris 10 and later, TrueOS, and macOS.

Comprehensive documentation with detailed descriptions and usage examples is available in the Lynis Documentation section on the official CISOfy website. If you don’t want to stick to the built-in tests, you can develop your own. You’ll find more details in the Lynis Software Development Kit. And for anyone still undecided about installing the tool, the developers provide a short demo that shows the installation and first run.

In addition to the free version we’ll be using below, the developers offer an enterprise-grade solution. This augments the standard package with a web-based administration interface, optional dashboards, extra documentation (hardening snippets), and a detailed remediation plan for identified issues. And that’s not all—the solution is also available as a cloud service (Software-as-a-Service).

Logo CISOfy
Logo CISOfy

Lynis runs hundreds of individual tests to determine the system’s security posture. The audit itself consists of a series of steps, from program initialization through to report generation.

Since Lynis is a highly flexible, multi-purpose tool, it’s used for a variety of purposes. For example, common use cases for Lynis include:

  • Security audit (user-defined baseline scenario)
  • Compliance testing (e.g., PCI DSS, HIPAA, SOX 404, OpenSCAP, NSA benchmarks)
  • Vulnerability scanning (e.g., outdated software)
  • Penetration testing mode (attempted privilege escalation)
  • System hardening and optimization (unapplied kernel tunables, unnecessary daemons, etc.)

You can install the tool in several ways—for example, by downloading it from the GitHub repository:

git clone https://github.com/CISOfy/lynis
cd lynis
./lynis

as well as by installing it from the Debian/Ubuntu repository:

sudo apt-get update
sudo apt-get install lynis

And for RPM-based distributions (after adding the appropriate repositories first):

yum install linus -y

Installation on macOS:

$ brew search lynis
$ brew install lynis

To run Lynis, you only need to provide at least one option. For example, to run all available tests, use the -c option (check all):

# Typical test suite
sudo lynis audit system
# Full test suite
sudo lynis audit system -c
# Scan a remote host
audit system remote <host>
Test initialization
Test initialization
Test results for the System Tools and Boot & Services groups
Test results for the System Tools and Boot & Services groups
Test results from the Kernel and Memory & Process auditing group
Test results from the Kernel and Memory & Process auditing group
Test results from the Users and Groups & Authentication group
Test results from the Users and Groups & Authentication group

Before running an audit, it’s always a good idea to check whether a new version of Lynis is available:

lynis update info && lynis update check

Besides the default mode, Lynis also supports an — unprivileged mode:

lynis audit --pentest

If you want to include the name of the auditor who ran the test, just add the -auditor <name> parameter:

sudo lynis audit system -c -auditor Daddy

At any point during the audit, press Enter to continue or Ctrl+C to forcibly stop. Test results are written to the Lynis log at /var/log/lynis.log. Note that the log is overwritten on each subsequent run of the utility.

To run tests regularly and automatically, you can schedule a Cron job using the -cronjob flag. In this mode, the tool runs with the specified profile (config) and won’t display any interactive prompts, questions, or warnings. All results are saved to the log. For example, here’s a script that launches the tool with the default config once a month:

#!/bin/sh
AUDITOR="automated"
DATE=$(date +%Y%m%d)
HOST=$(hostname)
LOG_DIR="/var/log/lynis"
REPORT="$LOG_DIR/report-${HOST}.${DATE}"
DATA="$LOG_DIR/report-data-${HOST}.${DATE}.txt"
cd /usr/local/lynis
./lynis -c –auditor "${AUDITOR}" –cronjob > ${REPORT}
mv /var/log/lynis-report.dat ${DATA}
# End

Save this script to /etc/cron.monthly/lynis. And don’t forget to create the log directories (/usr/local/lynis and /var/log/lynis), otherwise it may not function properly.

You can view a list of all commands you can invoke:

lynis show commands
Listing of available commands
Listing of available commands

Curious readers can take a look at the default configuration settings:

lynis show settings

Brief guide to using the utility:

man lynis

The possible statuses for the check results are limited to the following: NONE, WEAK, DONE, FOUND, NOT_FOUND, OK, WARNING.

Example of status output
Example of status output
Running specific tests in Lynis

In practice, you may only need to run a subset of tests—for example, if your server only acts as a mail server or runs Apache. To do this, we can use the -tests option. The command syntax is as follows:

lynis -tests "Test-IDs"

If the sheer number of test IDs is overwhelming, you can use the group parameter -test-category. With this option, Lynis runs only the test IDs that belong to a specific category. For example, we’re going to run the firewall and kernel tests:

./lynis -tests-category "firewalls kernel"
Example: running specific tests
Example: running specific tests

You can view the full list of available tests in the Controls section.

In addition, Lynis’s functionality can be extended with various plugins: you can write your own, or simply drop new ones into the existing plugin directory.

Suggested Fixes

All warnings will be listed after the results. Each entry starts with the warning text, followed by the name of the test that generated it in parentheses. The next line suggests a fix, if one is available. The final line is a URL where you can find details and additional guidance on how to resolve the issue.

Output of remediation recommendations for identified issues
Output of remediation recommendations for identified issues
Audit Profiles

Audit profiles are defined in files with the .prf extension located in the /etc/lynis directory. The default profile has a predictable name: default.prf. The developers advise against editing it directly; any changes you want to make to the audit should be added to the custom.prf file in the same directory.

Create and edit a custom profile:

touch /etc/lynis/custom.prf
sudo nano /etc/lynis/custom.prf

In this file, you can specify a list of tests to exclude from the Lynis audit. For example:

  • FILE-6310: partition check;
  • HTTP-6622: nginx installation test;
  • HTTP-6702: Apache installation test.

To exclude a specific test, use the skip-test directive and specify the test ID. For example:

# Is nginx installed?
skip-test=HTTP-6622
# Is Apache installed?
skip-test=HTTP-6702
Hardening State Assessment

After all tests have run, at the end of each audit output from the tool (just below the recommendations section), you’ll find a section that looks roughly like this:

Lynis security scan details:
Hardening index : 57 [############.........]
Tests performed : 216
Plugins enabled : 0
Overall hardening status score
Overall hardening status score

This numeric result shows both the number of tests passed and the system’s security score—the hardening index—the final figure Lynis uses to rate a server’s overall security posture. It’s important to remember that this index changes as you fix warnings and implement Lynis’s recommendations. So after applying fixes, a subsequent audit may produce a very different number!

[ WARNING

Anything you do as root demands extra care and accountability. Only perform actions you fully understand and are confident about. Don’t skip backups or snapshots.

2. Lunar — a UNIX security auditing tool based on several security frameworks

Lunar is a set of native Bash scripts that assess a target Linux host and generate a security audit report. The tool is based on the CIS benchmarks and other global security frameworks. It claims support for all major platforms: on Linux—RHEL and CentOS from version 5, SLES from version 10, Debian/Ubuntu, and Amazon Linux; plus Solaris from version 6, macOS (recent builds), FreeBSD (partial), AIX (partial), and even ESXi.

Lunar logo
Lunar logo

Among other things, this utility supports the Amazon Web Services (AWS) cloud platform and Docker containers. A detailed description of all features, along with examples of how to run the tool and initiate tests, is provided in the Wiki documentation on GitHub.

Listing all Lunar command-line options
Listing all Lunar command-line options

Run in audit mode, i.e., without making any changes to the system:

./lunar.sh -a

Running in audit mode with more detailed output:

./lunar.sh -a -v

List the tests:

./lunar.sh -S

Run only shell-based tests:

./lunar.sh -s audit_shell_services

Running in remediation mode, that is, with changes being made to the system:

./lunar.sh -l

Preview the proposed system tweaks before committing them to configuration files:

./lunar.sh -d
Example of running tests for the Apache web server
Example of running tests for the Apache web server

3. Nix Auditor — a CIS Audit made easier

Nix Auditor is another script for auditing whether a Linux system’s security meets CIS Benchmark requirements. It targets RHEL, CentOS, and other RPM-based distributions.

The developers claim the following advantages of Nix Auditor:

  • Scanning speed — a basic OS audit takes under 120 seconds, with the report available immediately.
  • Accuracy — validated across multiple CentOS and Red Hat releases.
  • Configurability — the source code and documentation are on GitHub, making it easy to tailor the code to your OS and the specific system components you need to assess.
  • Ease of use — just make the startup script executable and you’re ready to run the checks.

Example command sequence for downloading the utility from a GitHub repository and then running the script:

git clone https://github.com/XalfiE/Nix-Auditor.git
cd Nix-Auditor
chmod +x nixauditor
./nixauditor
Sample output after running Nix Auditor
Sample output after running Nix Auditor

4. Loki — Simple IOC and Incident Response Scanner

The Loki utility isn’t a traditional information security auditing tool, but it’s great for finding signs of compromise—something that can reasonably be considered part of audit practice.

Loki Scanner logo
Loki Scanner logo

According to the developers, their tool offers the following capabilities:

I. Four ways to detect a breach:

  • File names (regex matching against the full file path)
  • YARA rules scan (YARA; match signatures against file contents and process memory)
  • Hash checking (compare scanned files against hashes—MD5, SHA‑1, SHA‑256—of known malicious files)
  • C2 callback checks (compare communication endpoints against C2 IOCs)

II. Additional checks:

  • Regin filesystem check (via –reginfs)
  • Anomaly detection in system and user processes
  • Scanning of unpacked SWF files
  • SAM dump analysis
  • DoublePulsar check — attempt to detect the DoublePulsar backdoor listening on TCP ports 445 and 3389

Let’s briefly touch on how Loki determines whether a system has been compromised. Common indicators of compromise (IoCs) that suggest a computer has been compromised (i.e., breached) include:

  • Appearance of malware on the computer (viruses, backdoors, Trojans, keyloggers, crypters/packers, crypto‑miners, etc.), as well as hacker tools (e.g., for network reconnaissance, vulnerability exploitation, credential harvesting).
  • New, unknown executables or other files showing up, even if the antivirus engine doesn’t flag them as malicious.
  • Abnormal network activity (connections to remote hosts, unknown programs opening listening ports, etc.).
  • Abnormal disk I/O activity and increased system resource usage (CPU, RAM, swap).

Before starting the installation, you need to install a few dependencies: Colorama (adds colored output in the console), psutil (a process inspection utility), and the YARA package if it isn’t already installed.

Alright, let’s begin. Installation on Kali Linux (the YARA package must be installed beforehand; it’s included by default in Kali Linux):

sudo pip2 install psutil netaddr pylzma colorama
git clone https://github.com/Neo23x0/Loki
cd Loki/
python2 loki-upgrader.py
python2 loki.py -h

Installation on Ubuntu/Debian:

sudo apt-get install yara python-yara python-pip python-setuptools python-dev git
sudo pip2 install --upgrade pip
sudo pip2 install -U setuptools
sudo pip2 install psutil netaddr pylzma colorama
git clone https://github.com/Neo23x0/Loki
cd /home/download/Loki
python2 loki-upgrader.py
python2 loki.py -h

Installing on BlackArch:

sudo pacman -S yara python2-pip python2-yara
sudo pip2 install psutil netaddr pylzma colorama
git clone https://github.com/Neo23x0/Loki
cd /home/download/Loki
python2 loki-upgrader.py
python2 loki.py -h

Usage example

Some startup options:

optional arguments:
-h, --help show this help message and exit
-p path Path to scan
-l log-file Log file
--printAll Print all files that are scanned
--noprocscan Skip the process scan
--nofilescan Skip the file scan
--noindicator Do not show a progress indicator
--reginfs Do check for Regin virtual file system
--onlyrelevant Only print warnings or alerts
--nolog Don't write a local log file
Loki Scanner after the first run
Loki Scanner after the first run

By the way, after installing the tool, it’s a good idea to check the local IoC database for updates; you can do this with the Upgrader command:

Loki - Upgrader
optional arguments:
-h, --help show this help message and exit
--sigsonly Update the signatures only
--progonly Update the program files only
--nolog Don’t write a local log file
--debug Debug output
Example of log output during a scan
Example of log output during a scan

First, pay close attention to items highlighted in red. The DESCRIPTION field explains what the file is and why it’s considered suspicious. These are typically viruses, backdoors, and similar malware.

Details on detected malicious files
Details on detected malicious files

5. Linux Security Auditing Tool (LSAT)

LSAT is the final tool in our Linux security auditing roundup. Its standout feature is a modular design that, according to the developer, enables rapid addition of new checks. As of now, the utility claims support for the most common platforms: Linux — Gentoo, Red Hat, Debian, Mandrake on the x86 architecture; SunOS (2.x), Red Hat, Mandrake on SPARC; and Apple macOS.

LSAT is installed by building from source and comes with a pre-made autoconfig, autoconf. If you don’t plan to customize it, you can jump straight to compilation:

./configure
make
# You can also install LSAT system-wide; it will be installed to /usr/local/bin
make install
# and clean up post-installation files
make clean

Alternatively, on Debian/Ubuntu, you can install the package directly from the repository:

sudo apt-get install lsat

The utility is run with the /lsat command and additional options:

/lsat [OPTIONS]
Options:
-d diff current and old md5, output in lsatmd5.diff
-f Force a specific distribution test. Distro names are:
redhat
debian
mandrake
solaris
gentoo
macosx
If no -f option, lsat will guess. If lsat can
not guess the distribution, default is redhat.
-a Show this (advanced) help page
-o Output file name -- default is lsat.out
-r Check rpm integrity -- redhat or mandrake only
-s Silent mode
-v Verbose output
-w Output file in html format
-x eXclude module(s) in filelist from checks..

Conclusion

We’ve covered the most popular, powerful, and practical tools for auditing Linux server security. You should now be well prepared for certification or any other compliance audit. This will also help you objectively assess your current security posture and automatically or semi‑automatically tune your Linux fleet to achieve the highest possible hardening index.

it? Share: