added logwatch

README.md

@@ -26,28 +26,28 @@ An evolving how-to guide for securing a Linux server that, hopefully, also teach
   - [Other Important Notes](#other-important-notes)
 - [The SSH Server](#the-ssh-server)
   - [SSH Public/Private Keys](#ssh-publicprivate-keys)
-  - [Create SSH Group For `AllowGroups`](#create-ssh-group-for-allowgroups)
+  - [Create SSH Group For AllowGroups](#create-ssh-group-for-allowgroups)
   - [Secure `/etc/ssh/sshd_config`](#secure-etcsshsshd_config)
   - [Remove Short Diffie-Hellman Keys](#remove-short-diffie-hellman-keys)
   - [2FA/MFA for SSH](#2famfa-for-ssh)
 - [The Basics](#the-basics)
-  - [Limit Who Can Use `sudo`](#limit-who-can-use-sudo)
+  - [Limit Who Can Use sudo](#limit-who-can-use-sudo)
   - [NTP Client](#ntp-client)
   - [Force Accounts To Use Secure Passwords](#force-accounts-to-use-secure-passwords)
   - [Automatic Security Updates and Alerts](#automatic-security-updates-and-alerts)
 - [The Firewall](#the-firewall)
   - [UFW: Uncomplicated Firewall](#ufw-uncomplicated-firewall)
-  - [PSAD: `iptables` Intrusion Detection And Prevention](#psad-iptables-intrusion-detection-and-prevention)
+  - [PSAD: iptables Intrusion Detection And Prevention](#psad-iptables-intrusion-detection-and-prevention)
   - [Fail2ban: Application Intrusion Detection And Prevention](#fail2ban-application-intrusion-detection-and-prevention)
 - [The Danger Zone](#the-danger-zone)
   - [Proceed At Your Own Risk](#proceed-at-your-own-risk)
 - [The Auditing](#the-auditing)
-  - [`netstat` (WIP)](#netstat-wip)
+  - [netstat (WIP)](#netstat-wip)
   - [Lynis - Linux Security Auditing](#lynis---linux-security-auditing)
   - [CIS-CAT (WIP)](#cis-cat-wip)
 - [The Miscellaneous](#the-miscellaneous)
   - [Configure Gmail As MTA With Implicit TLS](#configure-gmail-as-mta-with-implicit-tls)
-  - [Separate `iptables` Log File](#separate-iptables-log-file)
+  - [Separate iptables Log File](#separate-iptables-log-file)
 - [Left Over](#left-over)
   - [Contacting Me](#contacting-me)
   - [Additional References](#additional-references)
@@ -111,15 +111,15 @@ There are many guides provided by experts, industry leaders, and the distributio
 ### To Do / To Add
 
 - [ ] [Custom Jails for Fail2ban](#custom-jails)
-- [x] [Linux Kernel `sysctl` Hardening](#linux-kernel-sysctl-hardening)
+- [x] [Linux Kernel sysctl Hardening](#linux-kernel-sysctl-hardening)
 - [ ] Security-Enhanced Linux / SELinux - https://en.wikipedia.org/wiki/Security-Enhanced_Linux, https://linuxtechlab.com/beginners-guide-to-selinux/, https://linuxtechlab.com/replicate-selinux-policies-among-linux-machines/, https://teamignition.us/how-to-stop-being-a-scrub-and-learn-to-use-selinux.html
 - [ ] disk encryption
 - [x] BIOS password
 - [ ] Anti-Virus
 - [x] use ed25519 keys instead of RSA for SSH public/private keys
-- [x] `psad`
+- [x] psad
 - [x] unattended upgrades for critical security updates and patches
-- [ ] `logwatch`
+- [x] logwatch
 - [ ] Rkhunter and chrootkit
 - [ ] AppArmor
 - [ ] port knockers for SSH - https://news.ycombinator.com/item?id=19181829, https://www.reddit.com/r/linuxadmin/comments/arx7xo/howtosecurealinuxserver_an_evolving_howto_guide/egropaw/
@@ -370,7 +370,7 @@ Now would be a good time to [perform any tasks specific to your setup](#prepost-
 
 ([Table of Contents](#table-of-contents))
 
-### Create SSH Group For `AllowGroups`
+### Create SSH Group For AllowGroups
 
 #### Why
 
@@ -378,7 +378,7 @@ To make it easy to control who can SSH to the server. By using a group, we can q
 
 #### How It Works
 
-We will use the [`AllowGroups` option](#AllowGroups) in SSH's configuration file [`/etc/ssh/sshd_config`](#secure-etcsshsshd_config). to tell the SSH server to only allow users to SSH in if they are a member of a certain UNIX group. Anyone not in the group will not be able to SSH in.
+We will use the [AllowGroups option](#AllowGroups) in SSH's configuration file [`/etc/ssh/sshd_config`](#secure-etcsshsshd_config). to tell the SSH server to only allow users to SSH in if they are a member of a certain UNIX group. Anyone not in the group will not be able to SSH in.
 
 #### Goals
 
@@ -429,7 +429,7 @@ SSH is a door into your server. This is especially true if you are opening ports
 
 #### Notes
 
-- Make sure you've completed [Create SSH Group For `AllowGroups`](#create-ssh-group-for-allowgroups) first.
+- Make sure you've completed [Create SSH Group For AllowGroups](#create-ssh-group-for-allowgroups) first.
 
 #### References
 
@@ -635,9 +635,9 @@ When you log into a server, be it directly from the console or via SSH, the door
 
 This section will alter the authentication rules for when logging in via SSH to require both a password and a 6 digit code.
 
-We will use Google's `libpam-google-authenticator` PAM module to create and verify a [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm) key. https://fastmail.blog/2016/07/22/how-totp-authenticator-apps-work/ and https://jemurai.com/2018/10/11/how-it-works-totp-based-mfa/ have very good writeups of how TOTP works.
+We will use Google's libpam-google-authenticator PAM module to create and verify a [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm) key. https://fastmail.blog/2016/07/22/how-totp-authenticator-apps-work/ and https://jemurai.com/2018/10/11/how-it-works-totp-based-mfa/ have very good writeups of how TOTP works.
 
-What we will do is tell the server's SSH PAM configuration to ask the user for their password and then their numeric token. PAM will then verify the user's password and, if it is correct, then it will route the authentication request to `libpam-google-authenticator` which will ask for and verify your 6 digit token. If, and only if, everything is good will the authentication succeed and user be allowed to log in.
+What we will do is tell the server's SSH PAM configuration to ask the user for their password and then their numeric token. PAM will then verify the user's password and, if it is correct, then it will route the authentication request to libpam-google-authenticator which will ask for and verify your 6 digit token. If, and only if, everything is good will the authentication succeed and user be allowed to log in.
 
 #### Goals
 
@@ -659,7 +659,7 @@ What we will do is tell the server's SSH PAM configuration to ask the user for t
 
 #### Steps
 
-1. Install it `libpam-google-authenticator`.
+1. Install it libpam-google-authenticator.
 
     On Debian based systems:
 
@@ -747,7 +747,7 @@ What we will do is tell the server's SSH PAM configuration to ask the user for t
     echo -e "\nChallengeResponseAuthentication yes         # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/ssh/sshd_config
     ```
 
-1. Restart `ssh`:
+1. Restart ssh:
 
     ``` bash
     sudo service sshd restart
@@ -757,21 +757,21 @@ What we will do is tell the server's SSH PAM configuration to ask the user for t
 
 ## The Basics
 
-### Limit Who Can Use `sudo`
+### Limit Who Can Use sudo
 
 #### Why
 
-`sudo` lets accounts run commands as other accounts, including **root**. We want to make sure that only the accounts we want can use `sudo`.
+sudo lets accounts run commands as other accounts, including **root**. We want to make sure that only the accounts we want can use sudo.
 
 #### Goals
 
-- `sudo` privileges limited to those who are in a group we specify
+- sudo privileges limited to those who are in a group we specify
 
 #### Notes
 
 - Your installation may have already done this, or may already have a special group intended for this purpose so check first.
-  - Debian creates the `sudo` group
+  - Debian creates the sudo group
-  - RedHat creates the `wheel` group
+  - RedHat creates the wheel group
 
 #### Steps
 
@@ -789,21 +789,21 @@ What we will do is tell the server's SSH PAM configuration to ask the user for t
     sudo usermod -a -G sudousers  ...
     ```
 
-    You'll need to do this for every account on your server that needs `sudo` privileges.
+    You'll need to do this for every account on your server that needs sudo privileges.
 
-1. Make a backup of the `sudo`'s configuration file `/etc/sudoers`:
+1. Make a backup of the sudo's configuration file `/etc/sudoers`:
 
     ``` bash
     sudo cp --preserve /etc/sudoers /etc/sudoers.$(date +"%Y%m%d%H%M%S")
     ```
 
-1. Edit `sudo`'s configuration file `/etc/sudoers`:
+1. Edit sudo's configuration file `/etc/sudoers`:
 
     ``` bash
     sudo visudo
     ```
 
-1. Tell `sudo` to only allow users in the `sudousers` group to use `sudo` by adding this line if it is not already there:
+1. Tell sudo to only allow users in the `sudousers` group to use sudo by adding this line if it is not already there:
 
     ```
     %sudousers   ALL=(ALL:ALL) ALL
@@ -833,7 +833,7 @@ NTP stands for Network Time Protocol. In the context of this guide, an NTP clien
 
 #### Steps
 
-1. Install `ntp`.
+1. Install ntp.
 
     On Debian based systems:
 
@@ -841,7 +841,7 @@ NTP stands for Network Time Protocol. In the context of this guide, an NTP clien
     sudo apt install ntp
     ```
 
-1. Check the status of the `ntp` service:
+1. Check the status of the ntp service:
 
     ``` bash
     sudo systemctl status ntp
@@ -867,7 +867,7 @@ NTP stands for Network Time Protocol. In the context of this guide, an NTP clien
     > Feb 16 00:32:23 host ntpd[1051]: Soliciting pool server 212.110.158.28
     > ```
 
-1. Check `ntp`'s status:
+1. Check ntp's status:
 
     ``` bash
     sudo ntpq -p
@@ -901,7 +901,7 @@ By default, accounts can use any password they want, including bad ones. [pwqual
 
 On Linux, PAM is responsible for authentication. There are four tasks to PAM that you can read about at https://en.wikipedia.org/wiki/Linux_PAM. This section talks about the password task.
 
-When there is a need to set or change an account password, the password task of PAM handles the request. In this section we will tell PAM's password task to pass the requested new password to `libpam-pwquality` to make sure it meets our requirements. If the requirements are met it is used/set; if it does not meet the requirements it errors and lets the user know.
+When there is a need to set or change an account password, the password task of PAM handles the request. In this section we will tell PAM's password task to pass the requested new password to libpam-pwquality to make sure it meets our requirements. If the requirements are met it is used/set; if it does not meet the requirements it errors and lets the user know.
 
 #### Goal
 
@@ -909,7 +909,7 @@ When there is a need to set or change an account password, the password task of
 
 #### Steps
 
-1. Install `libpam-pwquality`.
+1. Install libpam-pwquality.
 
     On Debian based systems:
 
@@ -923,7 +923,7 @@ When there is a need to set or change an account password, the password task of
     sudo cp --preserve /etc/pam.d/common-password /etc/pam.d/common-password.$(date +"%Y%m%d%H%M%S")
     ```
 
-1. Tell PAM to use `libpam-pwquality` to enforce strong passwords by editing the file `/etc/pam.d/common-password` and change the line that starts like this:
+1. Tell PAM to use libpam-pwquality to enforce strong passwords by editing the file `/etc/pam.d/common-password` and change the line that starts like this:
 
     ```
     password        requisite                       pam_pwquality.so
@@ -986,11 +986,11 @@ Automatic and unattended updates may break your system and you may not be near y
 
 On Debian based systems you can use:
 
-- `unattended-upgrades` to automatically do system updates you want (i.e. critical security updates)
+- unattended-upgrades to automatically do system updates you want (i.e. critical security updates)
-- `apt-listchanges` to get details about package changes before they are installed/upgraded
+- apt-listchanges to get details about package changes before they are installed/upgraded
-- `apticron` to get emails for pending package updates
+- apticron to get emails for pending package updates
 
-We will use `unattended-upgrades` to apply **critical security patches**. We can also apply stable updates since they've already been thoroughly tested by the Debian community.
+We will use unattended-upgrades to apply **critical security patches**. We can also apply stable updates since they've already been thoroughly tested by the Debian community.
 
 ##### References
 
@@ -1006,13 +1006,13 @@ We will use `unattended-upgrades` to apply **critical security patches**. We can
 
 ##### Steps
 
-1. Install `unattended-upgrades`, `apt-listchanges`, and `apticron`:
+1. Install unattended-upgrades, apt-listchanges, and apticron:
 
     ``` bash
     sudo apt install unattended-upgrades apt-listchanges apticron
     ```
 
-1. Now we need to configure `unattended-upgrades` to automatically apply the updates. This is typically done by editing the files `/etc/apt/apt.conf.d/20auto-upgrades` and `/etc/apt/apt.conf.d/50unattended-upgrades` that were created by the packages. However, because these file may get overwritten with a future update, we'll create a new file instead. Create the file `/etc/apt/apt.conf.d/51myunattended-upgrades` and add this:
+1. Now we need to configure unattended-upgrades to automatically apply the updates. This is typically done by editing the files `/etc/apt/apt.conf.d/20auto-upgrades` and `/etc/apt/apt.conf.d/50unattended-upgrades` that were created by the packages. However, because these file may get overwritten with a future update, we'll create a new file instead. Create the file `/etc/apt/apt.conf.d/51myunattended-upgrades` and add this:
 
     ```
     // Enable the update/upgrade script (0=disable)
@@ -1074,7 +1074,7 @@ We will use `unattended-upgrades` to apply **critical security patches**. We can
     - Check `/usr/lib/apt/apt.systemd.daily` for details on the `APT::Periodic` options
     - Check https://github.com/mvo5/unattended-upgrades for details on the `Unattended-Upgrade` options
 
-1. Run a dry-run of `unattended-upgrades` to make sure your configuration file is okay:
+1. Run a dry-run of unattended-upgrades to make sure your configuration file is okay:
 
     ``` bash
     sudo unattended-upgrade -d --dry-run
@@ -1082,13 +1082,13 @@ We will use `unattended-upgrades` to apply **critical security patches**. We can
 
     If everything is okay, you can let it run whenever it's scheduled to or force a run with `unattended-upgrade -d`.
 
-1. Configure `apt-listchanges` to your liking:
+1. Configure apt-listchanges to your liking:
 
     ``` bash
     sudo dpkg-reconfigure apt-listchanges
     ```
 
-1. Install `apticron`:
+1. Install apticron:
 
     ``` bash
     sudo apt install apticron
@@ -1103,6 +1103,111 @@ We will use `unattended-upgrades` to apply **critical security patches**. We can
 
 ([Table of Contents](#table-of-contents))
 
+### logwatch - system log analyzer and reporter
+
+#### Why
+
+Your server will be generating a lot of logs that may contain important information. Unless you plan on checking your server everyday, you'll want a way to get e-mail summary of your server's logs. To accomplish this we'll use [logwatch](https://sourceforge.net/projects/logwatch/).
+
+#### How It Works
+
+logwatch scans system log files and summarizes them. You can run it directly from the command line or schedule it to run on a recurring schedule. logwatch uses service files to know how to read/summarize a log file. You can see all of the stock service files in `/usr/share/logwatch/scripts/services`.
+
+logwatch's configuration file `/usr/share/logwatch/default.conf/logwatch.conf` specifies default options. You can override them via command line arguments.
+
+#### Goal
+
+- Logwatch configured to send a daily e-mail summary of the server's status and logs
+
+#### Notes
+
+- Your server will need to be able to send e-mails for this to work
+- The below steps will result in logwatch running every day. If you want to change the schedule, modify the cronjob to your liking. You'll also want to change the `range` option to cover your recurrence window. See https://www.badpenguin.org/configure-logwatch-for-weekly-email-and-html-output-format for an example.
+
+#### References
+
+- https://sourceforge.net/projects/logwatch/
+- https://www.digitalocean.com/community/tutorials/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps
+
+#### Steps
+
+1. Install logwatch.
+
+    On Debian based systems:
+
+    ``` bash
+    sudo apt install logwatch
+    ```
+
+1. To see a sample of what logwatch collects you can run it directly:
+
+    ``` bash
+    /usr/sbin/logwatch --output stdout --format text
+    ```
+
+    > ```
+    > 
+    >  ################### Logwatch 7.4.3 (12/07/16) ####################
+    >         Processing Initiated: Mon Mar  4 00:05:50 2019
+    >         Date Range Processed: yesterday
+    >                               ( 2019-Mar-03 )
+    >                               Period is day.
+    >         Detail Level of Output: 5
+    >         Type of Output/Format: stdout / text
+    >         Logfiles for Host: host
+    >  ##################################################################
+    > 
+    >  --------------------- Cron Begin ------------------------
+    > ...
+    > ...
+    >  ---------------------- Disk Space End -------------------------
+    > 
+    > 
+    >  ###################### Logwatch End #########################
+    > ```
+
+1. Go through logwatch's self-documented configuration file `/usr/share/logwatch/default.conf/logwatch.conf` before continuing. There is no need to change anything here but pay special attention to the `Output`, `Format`, `MailTo`, `MailFrom`, `Range`, and `Service` as those are the ones we'll be using. For our purposes, instead of specifying our options in the configuration file, we will pass them as command line arguments in the daily cron job that executes logwatch. That way, if the configuration file is ever modified (e.g. during an update), our options will still be there.
+
+1. Make a backup of logwatch's daily cron file `/etc/cron.daily/00logwatch` and unset the execute bit:
+
+    ``` bash
+    sudo cp --preserve /etc/cron.daily/00logwatch /etc/cron.daily/00logwatch.$(date +"%Y%m%d%H%M%S")
+    sudo chmod -x /etc/cron.daily/00logwatch.*
+    ```
+
+1. By default, unless you changed it, logwatch sends output to `stdout`. Since the end goal is to get a daily e-mail, we need to change the output type that logwatch uses to send e-mail instead. We could do this through the configuration file above but that would apply to every time it is run -- even when we run it manually and want to see the output to the screen. Instead, we'll change the cron job that executes logwatch to send e-mail. That way, when we run it manually we'll still get output to `stdout` and when cron runs it, we'll get an e-mail. We'll also make sure it checks for all services, and change the output format to html so it's easier to read regardless of what the configuration file says. In the file `/etc/cron.daily/00logwatch` find the execute line and change it to this:
+
+    ```
+    /usr/sbin/logwatch --output mail --format html --mailto root --mailfrom root --range yesterday --service all
+    ```
+
+    > ```
+    > #!/bin/bash
+    > 
+    > #Check if removed-but-not-purged
+    > test -x /usr/share/logwatch/scripts/logwatch.pl || exit 0
+    > 
+    > #execute
+    > /usr/sbin/logwatch --output mail --format html --service all
+    > 
+    > #Note: It's possible to force the recipient in above command
+    > #Just pass --mailto address@a.com instead of --output mail
+    > ```
+
+    [For the lazy](#editing-configuration-files---for-the-lazy):
+    
+    ``` bash
+    sudo sed -i -r -e "s,^($(which logwatch).*?),# \1         # commented by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")\n$(which logwatch) --output mail --format html --mailto root --mailfrom root --range yesterday --service all         # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")," /etc/cron.daily/00logwatch
+    ```
+
+1. You can test the cron job by executing it:
+
+    ``` bash
+    /etc/cron.daily/00logwatch
+    ```
+
+([Table of Contents](#table-of-contents))
+
 ## The Firewall
 
 ### UFW: Uncomplicated Firewall
@@ -1113,7 +1218,7 @@ Call me paranoid, and you don't have to agree, but I want to deny all traffic in
 
 Of course, if you disagree, that is totally fine and can configure UFW to suit your needs.
 
-Either way, ensuring that only traffic we explicitly allow is the job of a firewall. On Linux, the most common firewall is [`iptables`](https://en.wikipedia.org/wiki/Iptables). `iptables`, however, is rather complicated and confusing (IMHO). This is where UFW comes in. UFW simplifies the process of creating and managing `iptables` rules.
+Either way, ensuring that only traffic we explicitly allow is the job of a firewall. On Linux, the most common firewall is [iptables](https://en.wikipedia.org/wiki/Iptables). iptables, however, is rather complicated and confusing (IMHO). This is where UFW comes in. UFW simplifies the process of creating and managing iptables rules.
 
 **UFW** works by letting you configure rules that:
 
@@ -1141,7 +1246,7 @@ WIP
 
 #### Steps
 
-1. Install `ufw`.
+1. Install ufw.
 
     On Debian based systems:
 
@@ -1206,7 +1311,7 @@ WIP
     sudo ufw allow out 68 comment 'allow the DHCP client to update'
     ```
 
-1. Start `ufw`:
+1. Start ufw:
 
     ``` bash
     sudo ufw enable
@@ -1282,7 +1387,7 @@ WIP
 
 #### Default Applications
 
-`ufw` ships with some default applications. You can see them with:
+ufw ships with some default applications. You can see them with:
 
 ``` bash
 sudo ufw app list
@@ -1375,7 +1480,7 @@ sudo ufw allow plexmediaserver
 
 ([Table of Contents](#table-of-contents))
 
-### PSAD: `iptables` Intrusion Detection And Prevention
+### PSAD: iptables Intrusion Detection And Prevention
 
 #### Why
 
@@ -1400,7 +1505,7 @@ WIP
 
 #### Steps
 
-1. Install `psad`.
+1. Install psad.
 
     On Debian based systems:
 
@@ -1408,7 +1513,7 @@ WIP
     sudo apt install psad
     ```
 
-1. Make a backup of `psad`'s configuration file `/etc/psad/psad.conf`:
+1. Make a backup of psad's configuration file `/etc/psad/psad.conf`:
 
     ``` bash
     sudo cp --preserve /etc/psad/psad.conf /etc/psad/psad.conf.$(date +"%Y%m%d%H%M%S")
@@ -1424,9 +1529,9 @@ WIP
    |`ENABLE_AUTO_IDS_EMAILS`|`ENABLE_AUTO_IDS_EMAILS Y;`|
    |`EXPECT_TCP_OPTIONS`|`EXPECT_TCP_OPTIONS Y;`|
 
-   Check the configuration file `psad`'s documentation at http://www.cipherdyne.org/psad/docs/config.html for more details.
+   Check the configuration file psad's documentation at http://www.cipherdyne.org/psad/docs/config.html for more details.
 
-1. <a name="psad_step4"></a>Now we need to make some changes to `ufw` so it works with `psad` by telling `ufw` to log all traffic so `psad` can analyze it. Do this by editing **two files** and adding these lines **at the end but before the COMMIT line**.
+1. <a name="psad_step4"></a>Now we need to make some changes to ufw so it works with psad by telling ufw to log all traffic so psad can analyze it. Do this by editing **two files** and adding these lines **at the end but before the COMMIT line**.
 
     Make backups:
 
@@ -1448,7 +1553,7 @@ WIP
     -A FORWARD -j LOG --log-tcp-options --log-prefix "[IPTABLES] "
     ```
 
-    **Note**: We're adding a log prefix to all the `iptables` logs. We'll need this for [seperating `iptables` logs to their own file](#ns-separate-iptables-log-file).
+    **Note**: We're adding a log prefix to all the iptables logs. We'll need this for [seperating iptables logs to their own file](#ns-separate-iptables-log-file).
 
     For example:
 
@@ -1463,7 +1568,7 @@ WIP
     > COMMIT
     > ```
 
-1. Now we need to reload/restart `ufw` and `psad` for the changes to take effect:
+1. Now we need to reload/restart ufw and psad for the changes to take effect:
 
     ``` bash
     sudo ufw reload
@@ -1473,7 +1578,7 @@ WIP
     sudo psad -H
     ```
 
-1. Analyze `iptables` rules for errors:
+1. Analyze iptables rules for errors:
 
     ``` bash
     sudo psad --fw-analyze
@@ -1490,7 +1595,7 @@ WIP
 
     **Note**: If there were any issues you will get an e-mail with the error.
 
-1. Check the status of `psad`:
+1. Check the status of psad:
 
     ``` bash
     sudo psad --Status
@@ -1563,7 +1668,7 @@ WIP
 
 #### Steps
 
-1. Install `fail2ban`.
+1. Install fail2ban.
 
     On Debian based systems:
 
@@ -1593,7 +1698,7 @@ WIP
 
     **Note**: Your server will need to be able to send e-mails so Fail2ban can let you know of suspicious activity and when it banned an IP.
 
-1. We need to create a jail for `ssh` that tells `fail2ban` to look at `ssh` logs and use `ufw` to ban/unban IPs as needed. Create a jail for `ssh` by creating the file `/etc/fail2ban/jail.d/ssh.local` and adding this to it:
+1. We need to create a jail for ssh that tells fail2ban to look at ssh logs and use ufw to ban/unban IPs as needed. Create a jail for ssh by creating the file `/etc/fail2ban/jail.d/ssh.local` and adding this to it:
 
     ```
     [sshd]
@@ -1619,9 +1724,9 @@ WIP
     EOF
     ```
 
-1. In the above we tell `fail2ban` to use the `ufw` as the `banaction`. Fail2ban ships with an action configuration file for `ufw`. You can see it in `/etc/fail2ban/action.d/ufw.conf`
+1. In the above we tell fail2ban to use the ufw as the `banaction`. Fail2ban ships with an action configuration file for ufw. You can see it in `/etc/fail2ban/action.d/ufw.conf`
 
-1. Enable `fail2ban` and the jail for SSH:
+1. Enable fail2ban and the jail for SSH:
 
     ``` bash
     sudo fail2ban-client start
@@ -1689,13 +1794,13 @@ This sections cover things that are high risk because there is a possibility the
 
 ### Table of Contents
 
-- [Linux Kernel `sysctl` Hardening](#linux-kernel-sysctl-hardening)
+- [Linux Kernel sysctl Hardening](#linux-kernel-sysctl-hardening)
 - [Password Protect GRUB](#password-protect-grub)
 - [Disable Root Login](#disable-root-login)
-- [Change Default `umask`](#change-default-umask)
+- [Change Default umask](#change-default-umask)
 - [Orphaned Software](#orphaned-software)
 
-### Linux Kernel `sysctl` Hardening
+### Linux Kernel sysctl Hardening
 
 <details><summary>!! PROCEED AT YOUR OWN RISK !!</summary>
 
@@ -1705,7 +1810,7 @@ The kernel is the brains of a Linux system. Securing it just makes sense.
 
 #### Why Not
 
-Changing kernel settings with `sysctl` is risky and could break your server. If you don't know what you are doing, don't have the time to debug issues, or just don't want to take the risks, I would advise from not following these steps.
+Changing kernel settings with sysctl is risky and could break your server. If you don't know what you are doing, don't have the time to debug issues, or just don't want to take the risks, I would advise from not following these steps.
 
 #### Disclaimer
 
@@ -1719,7 +1824,7 @@ I won't provide [For the lazy](#editing-configuration-files---for-the-lazy) code
 
 #### Notes
 
-- Documentation on all the `sysctl` settings/keys is severely lacking. The [documentation I can find](https://github.com/torvalds/linux/tree/master/Documentation) seems to reference the 2.2 version kernel. I could not find anything newer. If you know where I can, please [let me know](#contacting-me).
+- Documentation on all the sysctl settings/keys is severely lacking. The [documentation I can find](https://github.com/torvalds/linux/tree/master/Documentation) seems to reference the 2.2 version kernel. I could not find anything newer. If you know where I can, please [let me know](#contacting-me).
 - The reference sites listed below have more comments on what each setting does.
 
 #### References
@@ -1733,9 +1838,9 @@ I won't provide [For the lazy](#editing-configuration-files---for-the-lazy) code
 
 #### Steps
 
-1. The `sysctl` settings can be found in the [linux-kernel-sysctl-hardening.md](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/linux-kernel-sysctl-hardening.md) file in this repo.
+1. The sysctl settings can be found in the [linux-kernel-sysctl-hardening.md](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/linux-kernel-sysctl-hardening.md) file in this repo.
 
-1. Before you make a kernel `sysctl` change permanent, you can test it with the `sysctl` command:
+1. Before you make a kernel sysctl change permanent, you can test it with the sysctl command:
 
     ``` bash
     sudo sysctl -w [key=value]
@@ -1765,7 +1870,7 @@ I won't provide [For the lazy](#editing-configuration-files---for-the-lazy) code
     sudo sysctl -p
     ```
 
-**Note**: If `sysctl` has trouble writing any settings then `sysctl -w` or `sysctl -p` will write an error to `stderr`. You can use this to quickly find invalid settings in  your `/etc/sysctl.conf` file:
+**Note**: If sysctl has trouble writing any settings then `sysctl -w` or `sysctl -p` will write an error to stderr. You can use this to quickly find invalid settings in  your `/etc/sysctl.conf` file:
 
 ``` bash
 sudo sysctl -p >/dev/null
@@ -1882,7 +1987,7 @@ If you forget the password, you'll have to go through [some work](https://www.cy
 
 #### Why
 
-If you have `sudo` [configured properly](#limit-who-can-use-sudo), then the **root** account will mostly never need to log in directly -- either at the terminal or remotely.
+If you have sudo [configured properly](#limit-who-can-use-sudo), then the **root** account will mostly never need to log in directly -- either at the terminal or remotely.
 
 #### Why Not
 
@@ -1929,13 +2034,13 @@ An alternative to locking the **root** acount is set a long/complicated **root**
 
 ([Table of Contents](#table-of-contents))
 
-### Change Default `umask`
+### Change Default umask
 
 <details><summary>!! PROCEED AT YOUR OWN RISK !!</summary>
 
 #### Why
 
-`umask` controls the **default** permissions of files/folders when they are created. Insecure file/folder permissions give other accounts potentially unauthorized access to your data. This may include the ability to make configuration changes.
+umask controls the **default** permissions of files/folders when they are created. Insecure file/folder permissions give other accounts potentially unauthorized access to your data. This may include the ability to make configuration changes.
 
 - For **non-root** accounts, there is no need for other accounts to get any access to the account's files/folders **by default**.
 - For the **root** account, there is no need for the file/folder primary group or other accounts to have any access to **root**'s files/folders **by default**.
@@ -1944,20 +2049,20 @@ When and if other accounts need access to a file/folder, you want to explicitly
 
 #### Why Not
 
-Changing the default `umask` can create unexpected problems. For example, if you set `umask` to `0077` for **root**, then **non-root** accounts **will not** have access to application configuration files/folders in `/etc/` which could break applications that do not run with **root** privileges.
+Changing the default umask can create unexpected problems. For example, if you set umask to `0077` for **root**, then **non-root** accounts **will not** have access to application configuration files/folders in `/etc/` which could break applications that do not run with **root** privileges.
 
 #### How It Works
 
-In order to explain how `umask` works I'd have to explain how Linux file/folder permissions work. As that is a rather complicated question, I will defer you to the references below for further reading.
+In order to explain how umask works I'd have to explain how Linux file/folder permissions work. As that is a rather complicated question, I will defer you to the references below for further reading.
 
 #### Goals
 
-- set default `umask` for **non-root** accounts to **0027**
+- set default umask for **non-root** accounts to **0027**
-- set default `umask` for the **root** account to **0077**
+- set default umask for the **root** account to **0077**
 
 #### Notes
 
-- `umask` is a Bash built-in which means a user can change their own `umask` setting.
+- umask is a Bash built-in which means a user can change their own umask setting.
 
 #### References
 
@@ -1977,7 +2082,7 @@ In order to explain how `umask` works I'd have to explain how Linux file/folder
     sudo cp --preserve /root/.bashrc /root/.bashrc.$(date +"%Y%m%d%H%M%S")
     ```
 
-1. Set default `umask` for **non-root** accounts to **0027** by adding this line to `/etc/profile` and `/etc/bash.bashrc`:
+1. Set default umask for **non-root** accounts to **0027** by adding this line to `/etc/profile` and `/etc/bash.bashrc`:
 
     ```
     umask 0027
@@ -2001,7 +2106,7 @@ In order to explain how `umask` works I'd have to explain how Linux file/folder
     echo -e "\nUMASK 0027         # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/login.defs
     ```
 
-1. Set default `umask` for the **root** account to **0077** by adding this line to `/root/.bashrc`:
+1. Set default umask for the **root** account to **0077** by adding this line to `/root/.bashrc`:
 
     ```
     umask 0077
@@ -2031,21 +2136,21 @@ As you use your system, and you install and uninstall software, you'll eventuall
 
 #### Debian Based Systems
 
-On Debian based systems, you can use [`deborphan`](http://freshmeat.sourceforge.net/projects/deborphan/) to find orphaned packages.
+On Debian based systems, you can use [deborphan](http://freshmeat.sourceforge.net/projects/deborphan/) to find orphaned packages.
 
 ##### <a name="orphaned-software-why-not"></a>Why Not
 
-Keep in mind, `deborphan` finds packages that have **no package dependencies**. That does not mean they are not used. You could very well have a package you use every day that has no dependencies that you wouldn't want to remove. And, if `deborphan` gets anything wrong, then removing critical packages may break your system.
+Keep in mind, deborphan finds packages that have **no package dependencies**. That does not mean they are not used. You could very well have a package you use every day that has no dependencies that you wouldn't want to remove. And, if deborphan gets anything wrong, then removing critical packages may break your system.
 
 ##### Steps
 
-1. Install `deborphan`.
+1. Install deborphan.
 
     ``` bash
     sudo apt install deborphan
     ```
 
-1. Run `deborphan` as **root** to see a list of orphaned packages:
+1. Run deborphan as **root** to see a list of orphaned packages:
 
     ``` bash
     sudo deborphan
@@ -2056,7 +2161,7 @@ Keep in mind, `deborphan` finds packages that have **no package dependencies**.
     > libpipeline1
     > ```
 
-1. [Assuming you want to remove all of the packages `deborphan` finds](#orphaned-software-why-not), you can pass it's output to `apt` to remove them:
+1. [Assuming you want to remove all of the packages deborphan finds](#orphaned-software-why-not), you can pass it's output to `apt` to remove them:
 
     ``` bash
     sudo apt --autoremove purge $(deborphan)
@@ -2070,7 +2175,7 @@ Keep in mind, `deborphan` finds packages that have **no package dependencies**.
 
 ## The Auditing
 
-### `netstat` (WIP)
+### netstat (WIP)
 
 WIP
 
@@ -2099,7 +2204,7 @@ From [https://cisofy.com/lynis/](https://cisofy.com/lynis/):
 
 #### Steps
 
-1. Install `lynis`. https://cisofy.com/lynis/#installation has detailed instructions on how to install it for your distribution.
+1. Install lynis. https://cisofy.com/lynis/#installation has detailed instructions on how to install it for your distribution.
 
     On Debian based systems, using CISOFY's community software repository:
 
@@ -2160,7 +2265,7 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
 
 #### Steps
 
-1. Install `exim4`. You will also need `openssl`.
+1. Install exim4. You will also need openssl.
 
     On Debian based systems:
 
@@ -2168,7 +2273,7 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
     sudo apt install exim4 openssl
     ```
 
-1. Configure `exim4`:
+1. Configure exim4:
 
     For Debian based systems:
     ``` bash
@@ -2211,7 +2316,7 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
     sudo chmod 640 /etc/exim4/passwd.client
     ```
 
-1. The next step is to create an TLS certificate that `exim4` will use to make the encrypted connection to `smtp.gmail.com`. You can use your own certificate, like one from [Let's Encrypt](https://letsencrypt.org/), or create one yourself using `openssl`. We will use a script that comes with `exim4` that calls `openssl` to make our certificate:
+1. The next step is to create an TLS certificate that exim4 will use to make the encrypted connection to `smtp.gmail.com`. You can use your own certificate, like one from [Let's Encrypt](https://letsencrypt.org/), or create one yourself using openssl. We will use a script that comes with exim4 that calls openssl to make our certificate:
 
     ``` bash
     sudo bash /usr/share/doc/exim4-base/examples/exim-gencert
@@ -2249,7 +2354,7 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
     >     support in your mail transfer agent.
     > ```
 
-1. Instruct `exim4` to use TLS and port 465 by creating the file `/etc/exim4/exim4.conf.localmacros` and adding:
+1. Instruct exim4 to use TLS and port 465 by creating the file `/etc/exim4/exim4.conf.localmacros` and adding:
 
     ```
     MAIN_TLS_ENABLE = 1
@@ -2269,7 +2374,7 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
     EOF
     ```
 
-1. Make a backup of `exim4`'s configuration file `/etc/exim4/exim4.conf.template`:
+1. Make a backup of exim4's configuration file `/etc/exim4/exim4.conf.template`:
 
     ``` bash
     sudo cp --preserve /etc/exim4/exim4.conf.template /etc/exim4/exim4.conf.template.$(date +"%Y%m%d%H%M%S")
@@ -2320,7 +2425,7 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
     sudo sed -i -r -e "/\.ifdef MAIN_TLS_ENABLE/ a # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")\n.ifdef TLS_ON_CONNECT_PORTS\n    tls_on_connect_ports = TLS_ON_CONNECT_PORTS\n.endif\n# end add" /etc/exim4/exim4.conf.template
     ```
 
-1. Update `exim4` configuration to use TLS and then restart the service:
+1. Update exim4 configuration to use TLS and then restart the service:
 
     ``` bash
     sudo update-exim4.conf
@@ -2368,11 +2473,11 @@ There are many guides on-line that cover how to configure Gmail as MTA using STA
 
 ([Table of Contents](#table-of-contents))
 
-### Separate `iptables` Log File
+### Separate iptables Log File
 
 #### Why
 
-There will come a time when you'll need to look through your `iptables` logs. Having all the `iptables` logs go to their own file will make it a lot easier to find what you're looking for.
+There will come a time when you'll need to look through your iptables logs. Having all the iptables logs go to their own file will make it a lot easier to find what you're looking for.
 
 #### References
 
@@ -2382,9 +2487,9 @@ There will come a time when you'll need to look through your `iptables` logs. Ha
 
 #### Steps
 
-1. The first step is by telling your firewall to prefix all log entries with some unique string. If you're using `iptables` directly, you would do something like `--log-prefix "[IPTABLES] "` for all the rules. We took care of this in step [step 4 of installing `psad`](#psad_step4).
+1. The first step is by telling your firewall to prefix all log entries with some unique string. If you're using iptables directly, you would do something like `--log-prefix "[IPTABLES] "` for all the rules. We took care of this in step [step 4 of installing psad](#psad_step4).
 
-1. After you've added a prefix to the firewall logs, we need to tell `rsyslog` to send those lines to its own file. Do this by creating the file `/etc/rsyslog.d/10-iptables.conf` and adding this:
+1. After you've added a prefix to the firewall logs, we need to tell rsyslog to send those lines to its own file. Do this by creating the file `/etc/rsyslog.d/10-iptables.conf` and adding this:
 
     ```
     :msg, contains, "[IPTABLES] " /var/log/iptables.log
@@ -2400,13 +2505,13 @@ There will come a time when you'll need to look through your `iptables` logs. Ha
 
     **Note**: Remember to change the prefix to whatever you use.
 
-1. Since we're logging firewall messages to a different file, we need to tell `psad` where the new file is. Edit `/etc/psad/psad.conf` and set `IPT_SYSLOG_FILE` to the path of the log file. For example:
+1. Since we're logging firewall messages to a different file, we need to tell psad where the new file is. Edit `/etc/psad/psad.conf` and set `IPT_SYSLOG_FILE` to the path of the log file. For example:
 
     ```
     IPT_SYSLOG_FILE /var/log/iptables.log;
     ```
 
-1. Restart `psad` and `rsyslog` to activate the changes (or reboot):
+1. Restart psad and rsyslog to activate the changes (or reboot):
 
     ``` bash
     sudo psad -R
@@ -2415,7 +2520,7 @@ There will come a time when you'll need to look through your `iptables` logs. Ha
     sudo service rsyslog restart
     ```
 
-1. The last thing we have to do is tell `logrotate` to rotate the new log file so it doesn't get to big and fill up our disk. Create the file `/etc/logrotate.d/iptables` and add this:
+1. The last thing we have to do is tell logrotate to rotate the new log file so it doesn't get to big and fill up our disk. Create the file `/etc/logrotate.d/iptables` and add this:
 
     ```
     /var/log/iptables.log