Thuta Learning
Search
ProjectsSecurityintermediate

Project — Linux Server Security Hardening

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

  • Get comfortable with the Project — Linux Server Security Hardening, no need to be intimidated by it
  • Be able to run tools yourself inside an authorized lab environment
  • Be able to apply this concept immediately in a real assessment/report

Take a moment to think about this

Security Hardening is the process of shrinking a system's attack surface and turning default/misconfigured settings into secure configurations — concrete steps like disabling unnecessary services, tightening firewall rules, securing SSH configuration, and enabling automatic security updates. In this project you'll take the concepts you learned in Firewall/Password Security (Intermediate chapter) and put them to practical use.

Let's connect it to a real scenario

On a lab Linux VM (a fresh install, or Metasploitable used as a hardening exercise), work through these hardening steps one by one: disable unnecessary services (telnet, FTP), configure the `ufw`/`iptables` firewall to default-deny with only the minimum required ports open, switch SSH from password authentication to key-based authentication, and disable direct root login over SSH.

Let's walk through it together

bash
# Hardening checklist commands (on your own lab VM)

# Disable unnecessary services
sudo systemctl disable telnet
sudo systemctl disable vsftpd  # if not needed

# Configure firewall: default deny, allow only SSH
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

# Disable SSH root login (edit /etc/ssh/sshd_config)
# PermitRootLogin no
# PasswordAuthentication no  (after setting up key-based auth)
sudo systemctl restart sshd
You should see
$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere

5-minute try-it

Harden a lab VM yourself following the hardening checklist — run an Nmap scan (Basic chapter) before and after hardening and compare how much the attack surface has shrunk.

A quick word of caution

Before doing SSH hardening (disabling root login, disabling password auth) on a production server — set up and test key-based access first, and only then disable password auth, or you could end up locking yourself out of the server.

Easy traps

  • Disabling password authentication before confirming that your key-based setup actually works when switching SSH over to key-based authentication — you could end up locking yourself out of the server (on a VM, you'd only be able to get back in via console access)
  • Forgetting to open the ports your application actually needs (for example 80/443 for a web server) when configuring a default-deny firewall — you can end up accidentally blocking a legitimate service

Now try it yourself

Harden a lab VM yourself following the hardening checklist — run an Nmap scan (Basic chapter) before and after hardening and compare how much the attack surface has shrunk.

You'll know it worked when: $ sudo ufw status Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere

Project — Linux Server Security Hardening | Thuta Learning