The Practical Linux Hardening Guide
"Did you know all your doors were locked?" - Riddick (The Chronicles of Riddick)
I'm back, work in progress...
Table of Contents
- Introduction
- Policy Compliance
- DevSec Hardening Framework
- Contributing
- Other official hardening guides
- Pre install tasks
- Post install tasks
- Bootloader configuration (grub)
- Disk partitions
- Keep system updated
- Package management
- Netfilter ruleset
- TCP wrapper
- Users and groups
- System path permissions
- PAM module
- Limits
- Shadow passwords
- Linux kernel hardening
- Remove unused modules
- Secure shared memory
- IRQ balance
- Disable compilers
- Email notifications
- Backups
- External devices
- Tools
- Services
- Containers
- Deployment
- Testing configuration
- External resources
Introduction
General disclaimer
The Practical Linux Hardening Guide provide a high-level overview of the security hardening GNU/Linux systems. It is not an official standard but it touches and use industry standards.
- this guide does not exhaust everything about Systems/Linux Hardening
- some hardening rules can be done better
- you can think of it also as a checklist
Before you start remember:
This guide also contains my comments that may be differ from certain industry principles. If you are not sure what to do please see Policy Compliance chapter and think about what you actually do at your server.
The importance of Linux hardening
Out of the box, Linux servers don’t come "hardened" (e.g. with the attack surface minimized). It’s up to you to prepare for each eventuality and set up systems to notify you of any suspicious activity in the future.
How to hardening Linux?
In my opinion you should definitely drop all non-industry policies, articles, manuals and other on your production environments. We have a lot of great GNU/Linux hardening policies to provide safer operating systems compatible with security protocols and security policies.
Most of all you should use Security Benchmarks/Policies which describe consensus best practices for the secure configuration of target systems because configuring your systems in compliance with e.g. CIS has been shown to eliminate 80-95% of known security vulnerabilities.
Policy Compliance
Center of Internet Security (CIS)
The Center for Internet Security (CIS) is a nonprofit organization focused on improving public and private-sector cybersecurity readiness and response.
Security Technical Implementation Guide (STIG)
A Security Technical Implementation Guide (STIG) is a cybersecurity methodology for standardizing security protocols within networks, servers, computers, and logical designs to enhance overall security.
Security Content Automation Protocol (SCAP)
Security Content Automation Protocol (SCAP) provides a mechanism to check configurations, vulnerability management and evaluate policy compliance for a variety of systems. One of the most popular implementations of SCAP is OpenSCAP and it is very helpful for vulnerability assessment and also as hardening helper.
DevSec Hardening Framework
Security + DevOps: Automatic Server Hardening.
This project covered a lot of the things in this guide, which can be automated (e.g. setting of grub password or enforcing the permissions of the common directories).
Project: DevSec Hardening Framework + GH repository: dev-sec.
Thanks for @artem-sidorenko!
Contributing
If you find something which doesn't make sense, or one of these doesn't seem right, or something seems really stupid; please make a pull request or please add valid and well-reasoned opinions about your changes or comments.
Before add pull request please see this.
Other official hardening guides
| Type of hardening guide | Comments |
|---|---|
| STIGs Master List | |
| Arch Linux | |
| CentOS Linux | |
| Debian GNU/Linux | old guide - to update |
| Fedora Linux | old guide - to update |
| Red Hat Enterprise | |
| Slackware Linux | some data may not be available |
| Ubuntu Linux | some data may not be available |
