The Practical Linux Hardening Guide
"Did you know all your doors were locked?" - Riddick (The Chronicles of Riddick)
The Practical Linux Hardening Guide provides a high-level overview of hardening GNU/Linux systems. It is not an official standard or handbook but it touches and uses industry standards.
This guide also provides you with practical step-by-step instructions for building your own hardened systems and services. One of the main goals is to create a single document covering internal and external threats.
A few rules for this project:
The Practical Linux Hardening Guide use following OpenSCAP configurations:
C2S for Red Hat Enterprise Linux 7 v0.1.43.
The requirements are derived from the (NIST) 800-53 and related documents.
Please also remember:
This guide contains my comments that may differ from certain industry principles. If you are not sure what to do please see Policy Compliance.
Simply speaking, hardening is the process of making a system more secure. 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.
The process of hardening servers involves both IT ops. and security teams and require changes to the default configuration according to industry benchmarks.
Also for me, hardening is the fine art of doing the right things, even if they don't always look to have a big impact. It's always a balance between ease of use and protection.
In my opinion, you should drop all non-industry policies, articles, manuals, and others especially on production environments and standalone home servers. These lists exist to give a false sense of security and aren't based on authority standards.
There are a lot of great GNU/Linux hardening policies available to provide safer operating systems compatible with security protocols. For me, CIS and the STIGs compliances are about the best prescriptive guides - but of course you can choose a different one (e.g. PCI-DSS, DISA).
Most of all you should use Security Benchmarks/Policies which describe consensus best practices for the secure configuration of target systems.
Configuring your systems in compliance eliminates the most common vulnerabilities. For example, CIS has been shown to eliminate 80-95% of known vulnerabilities.
On the other hand, these standards are complicated checklists (often for newbies, difficult to implement). In my opinion, ideally, real world implementation is automated via something like OpenSCAP.
You should use a rational approach because more is not better. Each environment is different, so even though security rules should all work in theory, sometimes things will not work as expected.
Hardening is not a simple process. Here are general rules following common best practices:
This guide is tested on Red Hat Enterprise Linux 7 and CentOS 7 distributions because these are:
Both distributions allow the use of certified tools which can parse and evaluate each component of the SCAP standard.
If you use another distribution - no problem, this guide is also for you.
Here is the structure of the chapters:
Chapter - e.g. Core Layer | |-- Subsection - e.g. Maintaining Software | \ | |-- Rationale | |-- Solution (+ policies) | |-- Comments | |-- Useful resources | |-- Subsection - e.g. Accounts and Access | \ | |-- Rationale | |-- Solution (+ policies) | |-- Comments | |-- Useful resources
Levels of understanding:
If you do not have the time to read hundreds of articles (just like me) this multipurpose handbook may be useful. This handbook does not get into all aspects of GNU/Linux hardening. I tried to put external resources in many places in this handbook in order to dispel any suspicion that may exist.
I did my best to make this guid a single and consistent (but now I know that is really hard). It's organized in an order that makes logical sense to me.
Do not treat this hardening guide as revealed knowledge. You should take a scientific approach when reading this document. If you have any doubts and disagree with me, please point out my mistakes. You should to discover cause and effect relationships by asking questions, carefully gathering and examining the evidence, and seeing if all the available information can be combined in to a logical answer.
I create this handbook for one more reason. Rather than starting from scratch in, I putting together a plan for answering your questions to help you find the best way to do things and ensure that you don't repeat my mistakes from the past.
So, what's most important:
Making major changes to your systems can be risky.
The most important rule of system hardening that reasonable admins follow is:
A production environment is the real instance of the app so make your changes on the dev/test!
The second most important rule is:
Don’t do anything that will affect the availability of the service or your system.
The third rule is:
Make backups of the entire virtual machine and important components.
And the last rule is:
Think about what you actually do with your server.
The Center of Internet Security (CIS) is a nonprofit organization focused on improving public and private sector cybersecurity readiness and response.
Please see CIS Benchmarks.
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.
Please see Stigviewer to explore all stigs.
The National Institute of Standards and Technology (NIST) is a physical sciences laboratory and a non-regulatory agency of the United States Department of Commerce.
Please see National Checklist Program (NCP).
Payment Card Industry Data Security Standard (PCI-DSS) compliance is a requirement for any business that stores, processes, or transmits cardholder data.
In accordance with PCI-DSS requirements, establish a formal policy and supporting procedures for developing configuration standards for system components that are consistent with industry-accepted hardening standards like:
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 as a hardening helper. OpenSCAP can easily handle the SCAP standards and generate neat, HTML-based reports.
The auditing system settings with SCAP Security Guide project contains guidance for settings for Red Hat/CentOS and it's validated by NIST.
You should inspect the security content of your system with
oscap info module:
# For RHEL: oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml # For CentOS: oscap info /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
The OpenSCAP scanner will only provide meaningful results if the content you want it to process is correct and up to date. The
oscap tool scans your system, validates security compliance content, and generates reports and guides based on these scans.
Official OpenSCAP Base documentation says:
The command-line tool, called
oscap, offers a multi-purpose tool designed to format content into documents or scan the system based on this content. Whether you want to evaluate DISA STIGs, NIST‘s USGCB, or Red Hat’s Security Response Team’s content, all are supported by OpenSCAP.
Before use, please read Using OSCAP documentation.
# Installation: yum install openscap-scanner # Make a RHEL7 machine e.g. PCI-DSS compliant: oscap xccdf eval --report report.html --profile xccdf_org.ssgproject.content_profile_pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml # Make a CentOS machine e.g. PCI-DSS compliant: oscap xccdf eval --report report.html --profile xccdf_org.ssgproject.content_profile_pci-dss /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
SCAP Workbench is a utility that offers an easy way to perform common
oscap tasks on local or remote systems.
Before use, please read Using SCAP Workbench documentation.
# Installation: yum install scap-security-guide scap-workbench
Security + DevOps: Automatic Server Hardening.
This project covers some of the things in this guide which can be automated (e.g. setting of grub password or enforcing the permissions of the common directories). Its a good start if you want to make changes and see how it works from the level of automation tools.
If you find something which doesn't make sense, or something doesn't seem right, please make a pull request and please add valid and well-reasoned explanations about your changes or comments.
Before adding a pull request, please see the contributing guidelines.
If this project is useful and important for you or if you really like The Practical Linux Hardening Guide, you can bring positive energy by giving some good words or supporting this project. Thank you!
For license information, please see LICENSE.
:beginner: To start please go to the Wiki.