Comparing Manual Audits vs. Automated Security Scanning
I used to spend hours tailing logs and ticking off boxes on a physical clipboard. It was exhausting. Then, a server I managed got hit by an SSH brute-force attack at 2 AM. That wake-up call taught me a hard lesson: manual checks are slow and prone to human error. You might remember to disable root login, but did you check the UMASK settings for new users or the kernel’s response to ICMP redirects?
Manual auditing involves grinding through CIS Benchmarks or STIGs line by line. It is excellent for learning, but it doesn’t scale. If you have ten servers, you’re looking at 40+ hours of work. Automated auditing with Lynis changes that. It executes over 300 security checks in under five minutes. Unlike heavy network scanners like OpenVAS, Lynis runs locally. This gives it deep visibility into the file system, kernel parameters, and running processes that external scans miss.
The Pros and Cons of Using Lynis
Before weaving Lynis into your production workflow, you should understand its boundaries. It is a diagnostic tool, not a magic wand. This distinction is actually its greatest strength.
The Pros
- Zero Dependencies: Lynis is built on shell script. It doesn’t require Python, Ruby, or a database. If the server has a shell, Lynis runs.
- Non-Intrusive: It never modifies your configuration files. It only reads them and reports findings, ensuring your system stays stable.
- Modular Architecture: You can toggle specific tests. This is perfect for auditing a specialized web server or a lightweight container host.
- Educational: Every suggestion includes a link to documentation. It doesn’t just tell you what’s wrong; it explains why it matters.
The Cons
- Manual Remediation: Lynis identifies the holes but won’t plug them for you. You still need Ansible, Salt, or manual edits to apply the hardening.
- Local Execution: You need shell access. It cannot scan a remote IP address from the outside.
- Data Density: The output is detailed. Teams used to colorful dashboards might find the terminal-based report intimidating at first.
The Recommended Setup for Real-World Use
Avoid installing Lynis through default package managers like apt or yum. Security tools must be current to catch modern exploits. Often, distribution repositories lag six months behind the latest release. For production, I pull directly from the official CISOfy repository or clone it from GitHub.
Centralize your setup in /usr/local/lynis and use a custom profile. This prevents “alert fatigue” by allowing you to ignore specific warnings required by your application. If your app needs a specific open port, you don’t want to see a red warning every week.
Implementation Guide: From Installation to Hardening
This is the exact workflow I use to bring a fresh Linux install up to production-grade security.
1. Installing the Latest Version
On modern Ubuntu or Debian systems, use the signed repository. This ensures you receive signed updates automatically.
# Install prerequisites
sudo apt update && sudo apt install apt-transport-https ca-certificates curl gnupg
# Add the GPG key to the trusted keyring
curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key | sudo gpg --dearmor -o /usr/share/keyrings/cisofy-archive-keyring.gpg
# Add the repository
echo "deb [signed-by=/usr/share/keyrings/cisofy-archive-keyring.gpg] https://packages.cisofy.com/community/lynis/deb/ stable main" | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
# Install Lynis
sudo apt update
sudo apt install lynis2. Running Your First Audit
Launch a full system scan with the audit system command. You must run this as root. A standard user lacks the permissions to inspect sensitive files like /etc/shadow or deep kernel configurations.
sudo lynis audit systemWatch the categories scroll by: Boot and services, Users and groups, Networking, and Storage. Pay attention to the colors. Green is healthy. Yellow is a suggestion. Red is a warning that demands an immediate fix.
3. Analyzing the Hardening Index
At the end of the report, look for your Hardening Index. A default Ubuntu 22.04 LTS installation usually scores around 58. Don’t panic. These OSs are optimized for convenience, not lockdown. My target for production is always 80 or higher. You can track your progress by comparing the lynis-report.dat files generated after each hardening session.
4. Implementing Hardening Fixes
The “Suggestions” section at the bottom is your to-do list. Here are two fixes I apply to almost every server:
Kernel Hardening
Lynis frequently flags parameters that allow man-in-the-middle attacks. Fix these by editing /etc/sysctl.conf.
# Disable IP forwarding and ignore ICMP redirects
sudo nano /etc/sysctl.conf
# Add these lines to the bottom:
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
# Refresh the settings
sudo sysctl -pRestricting Compilers
If an attacker gains access, they shouldn’t be able to compile exploit code. Restricting the gcc compiler to the root user is a quick, effective win.
# Prevent non-root users from executing gcc
sudo chmod o-x /usr/bin/gcc5. Automating the Audit
Security is a process, not a destination. Configurations drift and new vulnerabilities emerge. I set up a weekly cron job to run a quiet scan. It logs findings and alerts me if anything breaks the security baseline.
# Open the root crontab
sudo crontab -e
# Run a weekly audit every Monday at 3 AM
0 3 * * 1 /usr/bin/lynis audit system --cronjob --quiet > /var/log/lynis-weekly.logRefining Your Profile
Sometimes you can’t change a setting. Perhaps your cloud provider requires a specific firewall configuration that Lynis flags. In these cases, create a custom.prf in /etc/lynis/. Add skip-test=TEST-ID to clear the noise. This keeps your reports actionable and honest. Proactive auditing ensures that the next time someone tries to brute-force your SSH port, they’ll find a brick wall instead of a door.
