From 87a5b5c401b27b935396aee4db32274fe016c81f Mon Sep 17 00:00:00 2001 From: Ashley Anderson Date: Fri, 1 Mar 2019 00:00:27 -0500 Subject: [PATCH 1/2] Fix grammar & typos --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a8d35e6..99c40d7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,6 +1,6 @@ # Contributing -If you would like to support this project, you have an interesting idea how to improve the operation of this tool or if you found some errors - do fork this add your fixes and add pull-request of your branch to the **master branch**. +If you would like to support this project, have an interesting idea how to improve the operation of this tool, or if you found some errors-- fork this, add your fixes, and add a pull request of your branch to the **master branch**. ## Signature of commit @@ -13,7 +13,7 @@ grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1" ## Pull requests -When creating pull request, please heed the following: +When creating a pull request, please heed the following: - Base your code on the latest master branch to avoid manual merges - Code review may ensue in order to help shape your proposal From bc9192ff59ab6b1109b3c6ce86087b2dcd423f40 Mon Sep 17 00:00:00 2001 From: Ashley Anderson Date: Fri, 1 Mar 2019 00:42:06 -0500 Subject: [PATCH 2/2] Fix grammar & typos --- README.md | 148 +++++++++++++++++++++++++++--------------------------- 1 file changed, 74 insertions(+), 74 deletions(-) diff --git a/README.md b/README.md index 6f2dbd1..b658e1c 100644 --- a/README.md +++ b/README.md @@ -42,99 +42,99 @@ **** -## Table of Contents +# Table of Contents - **[Introduction](#introduction)** - * [General disclaimer](#general-disclaimer) - * [The importance of Linux hardening](#the-importance-of-linux-hardening) - * [How to hardening Linux?](#how-to-hardening-linux) - * [Which distribution should be used?](#which-distribution-should-be-used) - * [How to read this guide?](#how-to-read-this-guide) - * [Okay. Let's start, 3, 2, 1... STOP!](#okay-lets-start-3-2-1-stop) + - [General Disclaimer](#general-disclaimer) + - [The Importance of Linux Hardening](#the-importance-of-linux-hardening) + - [How to Harden Linux](#how-to-harden-linux) + - [Which Distribution Should be Used?](#which-distribution-should-be-used) + - [How to Read This Guide](#how-to-read-this-guide) + - [Okay. Let's start, 3, 2, 1... STOP!](#okay-lets-start-3-2-1-stop) - **[Policy Compliance](#policy-compliance)** - * [Center of Internet Security (CIS)](#center-of-internet-security-cis) - * [Security Technical Implementation Guide (STIG)](#security-technical-implementation-guide-stig) - * [National Institute of Standards and Technology (NIST)](#national-institute-of-standards-and-technology-nist) - * [Payment Card Industry Data Security Standard (PCI-DSS)](#payment-card-industry-data-security-standard-pci-dss) + - [Center of Internet Security (CIS)](#center-of-internet-security-cis) + - [Security Technical Implementation Guide (STIG)](#security-technical-implementation-guide-stig) + - [National Institute of Standards and Technology (NIST)](#national-institute-of-standards-and-technology-nist) + - [Payment Card Industry Data Security Standard (PCI-DSS)](#payment-card-industry-data-security-standard-pci-dss) - **[Security Content Automation Protocol (SCAP)](#security-content-automation-protocol-scap)** - * [SCAP Security Guide](#scap-security-guide) - * [OpenSCAP Base](#openscap-base) - * [SCAP Workbench](#scap-workbench) + - [SCAP Security Guide](#scap-security-guide) + - [OpenSCAP Base](#openscap-base) + - [SCAP Workbench](#scap-workbench) - **[DevSec Hardening Framework](#devsec-hardening-framework)** - **[Contributing & Support](#contributing--support)** - **[License](#license)** ## Introduction -### General disclaimer +### General Disclaimer -**The Practical Linux Hardening Guide** provides a high-level overview of the hardening GNU/Linux systems. It is not an official standard or handbook but it _touches_ and _use_ industry standards. +**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: -- useful, simple and not tiring +- useful, simple, and not tiring - include a lot of security tips from the C2S/CIS - contains also non-related rules with C2S/CIS - based on a minimal [RHEL7](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux) and [CentOS 7](https://www.centos.org/) installations -- does not exhaust everything about Linux hardening +- it's not exhaustive about Linux hardening - some hardening rules/descriptions can be done better -- you can think of it also as a checklist +- you can think of it as a checklist Please also 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](#policy-compliance)** chapter. + > This guide also contains my comments that may differ from certain industry principles. If you are not sure what to do please see **[Policy Compliance](#policy-compliance)**. -### The importance of Linux hardening +### The Importance of Hardening Linux 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 in itself don't always look to be having a big impact. It's always a balance between ease of use and protection. +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. -You need to harden your system to protect your assets as much as possible. Why it's important? Please read a great and short article that [explains hardening process](https://linux-audit.com/linux-server-hardening-most-important-steps-to-secure-systems/) step by step by [Michael Boelen](https://michaelboelen.com/). +You need to harden your system to protect your assets as much as possible. Why is it important? Please read a great, short article that [explains the hardening process](https://linux-audit.com/linux-server-hardening-most-important-steps-to-secure-systems/) step by step by [Michael Boelen](https://michaelboelen.com/). -### How to hardening Linux? +### How to Harden Linux -In my opinion you should definitely drop all non-industry policies, articles, manuals and other (especially on your production environments but also if you harden standalone home server). These lists exist to give false sense of security and they are not bases on authority standards. +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. -We have a lot of great GNU/Linux hardening policies to provide safer operating systems compatible with security protocols. For me, CIS and the STIGs compliants are about the best actual prescriptive guides - but of course you can choose a different one (e.g. PCI-DSS, DISA). +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](#policy-compliance) which describe consensus best practices for the secure configuration of target systems. -Configuring your systems in compliance eliminate the most common security fails/bugs. For example, CIS has been shown to eliminate 80-95% of known security vulnerabilities. +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 (for newbies difficult to implement) check-lists. In my opinion ideally, real world implementation is automated via something like OpenSCAP. +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 security rules should all work in theory, but sometimes it not works as well. + > 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. Each of us must devote a lot of time to it. Here are the general rules that just follow the common best practices: +Hardening is not a simple process. You must devote a lot of time. Here are general rules following common best practices: -- never use root account for anything that does not require it -- only sudo individual commands or for a short time -- never let a server running as root (except for its initialization time...) and ensure that it leaves all unnecessary privileges before accepting requests -- secure your firewall the best you can and forbid all unnecessary accesses -- do not install unnecessary or non controlled software +- Never use root account for anything that does not require it +- Only ```sudo``` individual commands +- Never set a server to run as root (except for initialization time) and ensure that it exits all unnecessary privileges before accepting requests +- Ssecure your firewall the best you can and forbid all unnecessary access +- Do not install unnecessary or unstable software -### Which distribution should be used? +### Which Distribution Should be Used? -This guide is being written and tested on **Red Hat Enterprise Linux 7** and **CentOS 7** distributions because: +This guide is tested on **Red Hat Enterprise Linux 7** and **CentOS 7** distributions because these are: -- they are a free (CentOS) and open source -- they are enterprise-class -- they are stable and reliable -- they have great community support -- they are built on coherent snapshots of old packages +- free (CentOS) and open source +- enterprise-class +- stable and reliable +- with great community support +- built on coherent snapshots of old packages Both distributions allow the use of **[certified tools](#scap-security-guide)** which can parse and evaluate each component of the SCAP standard. -If you use another distribution there is no problem, this guide is also for you. +If you use another distribution--no problem, this guide is also for you. -### How to read this guide? +### How to Read This Guide -Primarily please look at the structure of the chapters. Each of them looks as follows: +Here is the structure of the chapters: ``` Chapter - e.g. Core Layer @@ -156,37 +156,37 @@ Primarily please look at the structure of the chapters. Each of them looks as fo Levels of understanding: -- read the _chapter_ and _subsection_, it offers a general overview -- read the _rationale_, it tell you why you should make changes -- read the _solution_ and _policies_, it's always compliant with the standard and on this basis, make changes -- read the _comments_ to find out what you can change/add to the _solution_ -- check the _useful resources_ for a deeper understanding +- _Chapter_ and _subsection_ offers a general overview +- _Rationale_ tells you the reasoning behind the changes +- _Solution_ and _policies_ are always compliant with the standard and on this basis, make changes +- _Comments_ helps you figure out what you can change or add to the _solution_ +- _Useful resources_ provide deeper understanding ### Okay. Let's start, 3, 2, 1... STOP! -Making major changes to the direction of your systems can be risky. +Making major changes to your systems can be risky. -The most important rule of system hardening that reasonable admins actually use is: +The most important rule of system hardening that reasonable admins follow is: - > **`A production environment is the real instance of the app so all your changes make on the dev/test!`** + > **`A production environment is the real instance of the app so make your changes on the dev/test!`** -The second important rule is: +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 backup of entire virtual machines and important components in the middle of them.`** + > **`Make backups of the entire virtual machine and important components.`** And the last rule is: - > **`Think about what you actually do at your server.`** + > **`Think about what you actually do with your server.`** ## Policy Compliance ### Center of Internet Security (CIS) -The Center of Internet Security (CIS) is a nonprofit organization focused on improving public and private-sector cybersecurity readiness and response. +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](https://www.cisecurity.org/cis-benchmarks/)**. @@ -194,11 +194,11 @@ Please see **[CIS Benchmarks](https://www.cisecurity.org/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](https://www.stigviewer.com/stigs)** for explore all stigs. +Please see **[Stigviewer](https://www.stigviewer.com/stigs)** to explore all stigs. ### National Institute of Standards and Technology (NIST) -A National Institute of Standards and Technology (NIST) is a physical sciences laboratory, and a non-regulatory agency of the United States Department of Commerce. +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)](https://nvd.nist.gov/ncp/repository)**. @@ -206,7 +206,7 @@ Please see **[National Checklist Program (NCP)](https://nvd.nist.gov/ncp/reposit 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 established a formal policy and supporting procedures for developing configuration standards for system components that are consistent with industry-accepted hardening standards like: +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: - Center of Internet Security (CIS) - International Organization for Standardization (ISO) @@ -217,13 +217,13 @@ In accordance with PCI-DSS requirements established a formal policy and supporti 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. OpenSCAP can easily handle the SCAP standards and generate neat, HTML-based reports. +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. -Please see **[SCAP Security Policies](https://www.open-scap.org/security-policies/)**, **[OpenSCAP User Manual](https://static.open-scap.org/openscap-1.2/oscap_user_manual.html)** and **[OpenSCAP Static](https://static.open-scap.org/)**. +Please see **[SCAP Security Policies](https://www.open-scap.org/security-policies/)**, **[OpenSCAP User Manual](https://static.open-scap.org/openscap-1.2/oscap_user_manual.html)**, and **[OpenSCAP Static](https://static.open-scap.org/)**. ### SCAP Security Guide -The auditing system settings with SCAP Security Guide project contains guidance for settings of Red Hat/CentOS and it's validated by NIST. +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: @@ -237,13 +237,13 @@ oscap info /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml ### OpenSCAP Base -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, validate security compliance content and generate reports and guides based on these scans. +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](https://www.open-scap.org/tools/openscap-base/) documentation say: +Official [OpenSCAP Base](https://www.open-scap.org/tools/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 see **[Using OSCAP](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sect-using_oscap)** documentation. +Before use, please read **[Using OSCAP](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sect-using_oscap)** documentation. ```bash # Installation: @@ -260,7 +260,7 @@ oscap xccdf eval --report report.html --profile xccdf_org.ssgproject.content_pro SCAP Workbench is a utility that offers an easy way to perform common `oscap` tasks on local or remote systems. -Before use please see **[Using SCAP Workbench](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sect-using_scap_workbench)** documentation. +Before use, please read **[Using SCAP Workbench](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sect-using_scap_workbench)** documentation. ```bash # Installation: @@ -271,23 +271,23 @@ yum install scap-security-guide scap-workbench > _Security + DevOps: Automatic Server Hardening._ -This project covered 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). It's a good start if you want to make some changes and see how it works from the level of automation tools. +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. -Project: **[DevSec Hardening Framework](https://dev-sec.io)** + GH repository: **[dev-sec](https://github.com/dev-sec/)**. +Project: **[DevSec Hardening Framework](https://dev-sec.io)** and :octocat: GitHub repository: **[dev-sec](https://github.com/dev-sec/)**. -Thanks for [@artem-sidorenko](https://github.com/artem-sidorenko)! +Thanks [@artem-sidorenko](https://github.com/artem-sidorenko)! ## Contributing & Support -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. +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 add pull request please see **[this](CONTRIBUTING.md)**. +Before adding a pull request, please see the **[contributing guidelines](CONTRIBUTING.md)**. -If this project is useful and important for you or if you really like _The Practical Linux Hardening Guide_, you can bring me **more positive energy**, give me some **good words** or **support this project** more. Thank you! +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! ## License -For more please see [LICENSE](https://github.com/trimstray/the-practical-linux-hardening-guide/blob/master/LICENSE.md). +For license information, please see [LICENSE](https://github.com/trimstray/the-practical-linux-hardening-guide/blob/master/LICENSE.md). ---