Guide Objective

This guides purpose is to teach you how to secure a Linux server.

There are a lot of things you can do to secure a Linux server and this guide will attempt to cover as many of them as possible.

Why Secure Your Server

I assume you’re using this guide because you, hopefully, already understand why good security is important. That is a heavy topic onto itself and breaking it down is out-of-scope for this guide. If you don’t know the answer to that question, I advise you research it first.

At a high level, the second a device, like a server, is in the public domain – i.e visible to the outside world – it becomes a target for bad-actors. An unsecured device is a playground for bad-actors who want access to your data, or to use your server as another node for their large-scale DDOS attacks.

What’s worse is, without good security, you may never know if your server has been compromised. A bad-actor may have gained unauthorized access to your server and copied your data without changing anything so you’d never know. Or your server may have been part of a DDOS attack and you wouldn’t know. Look at many of the large scale data breaches in the news – the companies often did not discover the data leak or intrusion until long after the bad-actors were gone.

Contrary to popular belief, bad-actors don’t always want to change something or lock you out of your data for money. Sometimes they just want the data on your server for their data warehouses (there is big money in big data) or to covertly use your server for their nefarious purposes.

Why Yet Another Guide

This guide may appear duplicative/unnecessary because there are countless articles online that tell you how to secure Linux, but the information is spread across different articles, that cover different things, and in different ways. Who has time to scour through hundreds of articles?

As I was going through research for my Debian build, I kept notes. At the end I realized that, along with what I already knew, and what I was learning, I had the makings of a how-to guide. I figured I’d put it online to hopefully help others learn, and save time.

I’ve never found one guide that covers everything – this guide is my attempt.

Many of the things covered in this guide may be rather basic/trivial, but most of us do not install Linux every day and it is easy to forget those basic things.

IT automation tools like Ansible, Chef, Jenkins, Puppet, etc. help with the tedious task of installing/configuring a server but IMHO they are better suited for multiple or large scale deployments. IMHO, the overhead required to use those kinds of automation tools is wholly unnecessary for a one-time single server install for home use.

There are many guides provided by experts, industry leaders, and the distributions themselves. It is not practical, and sometimes against copyright, to include everything from those guides. I recommend you check them out before starting with this guide.

  • The Center for Internet Security (CIS) provides benchmarks that are exhaustive, industry trusted, step-by-step instructions for securing many flavors of Linux. Check their About Us page for details. My recommendation is to go through this guide first and then CIS’s guide. That way their recommendations will trump anything in this guide.
  • For distribution specific hardening/security guides, check your distributions documentation.
  • - Red Hat Enterprise Linux 7 Hardening Checklist
  • - # Debian 9.3 server setup guide
  • - Ubuntu Server Initial Security guide
  • - many folks have also recommended this one

About This Guide

This guide…

  • is a work in progress.
  • is focused on at-home Linux servers. All of the concepts/recommendations here apply to larger/professional environments but those use-cases call for more advanced and specialized configurations that are out-of-scope for this guide.
  • does not teach you about Linux, how to install Linux, or how to use it. Check if you’re new to Linux.
  • is meant to be Linux distribution agnostic.
  • does not teach you everything you need to know about security nor does it get into all aspects of system/server security. For example, physical security is out of scope for this guide.
  • does not talk about how programs/tools work, nor does it delve into their nook and crannies. Most of the programs/tools this guide references are very powerful and highly configurable. The goal is to cover the bare necessities – enough to whet your appetite and make you hungry enough to want to go and learn more.
  • aims to make it easy by providing code you can copy-and-paste. You might need to modify the commands before you paste so keep your favorite text editor handy.
  • is organized in an order that makes logical sense to me – i.e. securing SSH before installing a firewall. As such, this guide is intended to be followed in the order it is presented but it is not necessary to do so. Just be careful if you do things in a different order – some sections require previous sections to be completed.

My Use-Case

There are many types of servers and different use-cases. While I want this guide to be as generic as possible, there will be some things that may not apply to all/other use-cases. Use your best judgement when going through this guide.

To help put context to many of the topics covered in this guide, my use-case/configuration is:

  • A desktop class computer…
  • With a single NIC…
  • Connected to a consumer grade router…
  • Getting a dynamic WAN IP provided by the ISP…
  • With WAN+LAN on IPV4…
  • And LAN using NAT
  • That I want to be able to SSH to remotely from unknown computers and unknown locations (i.e. a friend’s house).

Editing Configuration Files - For The Lazy

I am very lazy and do not like to edit files by hand if I don’t need to. I also assume everyone else is just like me. :)

So, when and where possible, I have provided code snippets to quickly do what is needed, like add or change a line in a configuration file.

The code snippets use basic commands like echo, cat, sed, awk, and grep. How the code snippets work, like what each command/part does, is out of scope for this guide – the man pages are your friend.

Note: The code snippets do not validate/verify the change went through – i.e. the line was actually added or changed. I’ll leave the verifying part in your capable hands. The steps in this guide do include taking backups of all files that will be changed.

Not all changes can be automated with code snippets. Those changes need good, old fashioned, manual editing. For example, you can’t just append a line to an INI type file. Use your favorite Linux text editor.

Licenses and Attributions

Speak Your Mind