Server Hardening Basics: How to Lock Down a Machine Before It Gets Attacked

The moment a server has a public IP address, it stops being yours alone. Within minutes, automated scanners from all over the internet start knocking on its door — trying default passwords, probing common ports, looking for software with known holes. This isn’t paranoia; it’s just the background noise of being online. Anyone who has watched a fresh server’s logs for an hour has seen it happen.

Server hardening is how you answer that reality. It’s not one tool or one setting — it’s a collection of deliberate choices that make a machine harder to break into. The goal isn’t to build an impenetrable fortress (nothing online is truly that). The goal is to remove the easy ways in, so an attacker has to work much harder, and the automated bots that make up most attacks simply move on to a softer target.

What hardening actually means

To “harden” something is to reduce its attack surface — the total set of points where someone could try to get in or cause harm. Every open port, every running service, every user account, every piece of installed software is a potential door. Some of those doors you need. Many of them you don’t, and they’re open simply because that’s the default.

Hardening is the process of going through all of those doors and asking a simple question for each one: do I actually need this open? If the answer is no, you close it. If the answer is yes, you make sure it’s locked properly. That’s the whole philosophy, repeated across every layer of the system.

It helps to picture the difference between the default state and a hardened state:

  DEFAULT SERVER                    HARDENED SERVER
  ─────────────                     ────────────────
  many ports open          ──►      only ports you use
  password login           ──►      key-based login only
  root logs in directly    ──►      root login disabled
  everything up to date?   ──►      auto-updates on
  one big admin account    ──►      least-privilege users
  no failed-login limit    ──►      brute-force protection

Notice that none of this is exotic. There’s no special security product you have to buy. Hardening is mostly about turning off what you don’t need and configuring what’s left sensibly. The hardest part is just remembering to do it — and doing it before the machine goes live, not after something goes wrong.

Start with the principle of least privilege

Before any specific setting, there’s a mindset that ties all of hardening together: least privilege. It means every user, every process, and every service should have exactly the access it needs to do its job — and nothing more. A program that only reads files shouldn’t be able to delete them. A user who manages one website shouldn’t have control over the entire machine.

The reason this matters so much is damage control. When something does get compromised — and over a long enough time, something always tries — least privilege limits how far the damage spreads. If an attacker breaks into a low-privilege account, they’re stuck in a small box. If they break into an account that can do anything, they own the server.

This is why the very first hardening move on most servers is to stop using the all-powerful root account for day-to-day work. Instead, you create a normal user, give it the ability to run administrative commands only when needed (via sudo), and lock direct root access down. To go deeper on how users and permissions work underneath this, the article on users and groups in Linux lays out the model, and file permissions covers who’s allowed to touch what.

# create a regular working user
adduser jane

# give that user the ability to run admin commands when needed
usermod -aG sudo jane

# now Jane logs in as herself and uses 'sudo' only when she
# actually needs admin power — not for everything

Lock down how people log in

The single most attacked door on a typical server is the remote login service: SSH, the protocol you use to get a command line on a machine from somewhere else. If you do nothing else, securing SSH gives you the biggest return. (If the protocol itself is new to you, the SSH basics article walks through how it works.)

There are three changes that together transform SSH from a soft target into a hard one:

• Switch from passwords to SSH keys. A password can be guessed, and bots try millions of them. An SSH key is a long cryptographic pair — a public half that lives on the server and a private half that never leaves your own machine. Guessing one is, for all practical purposes, impossible. Once keys work, you turn password login off entirely.
• Disable direct root login. Even with a strong password or key, letting root log in remotely means an attacker only needs to break one well-known account. Force everyone to log in as a normal user first, then escalate with sudo. Now an attacker has to guess both a username and get past the login.
• Consider a non-default port (modestly). SSH listens on port 22 by default, and every bot knows it. Moving it to a different port doesn’t make you secure — a determined attacker can still scan for it — but it dramatically cuts the volume of automated noise hitting your logs. Treat it as tidying, not real protection.

   ATTACKER                         HARDENED SSH
  ──────────                        ────────────
  tries 'root' + password   ──►     root login: refused
  tries common passwords    ──►     passwords: disabled
  brute-forces port 22      ──►     keys only, no guessing in

Close every door you’re not using

A fresh server often comes with services already running that you never asked for — a mail daemon, a database listening on the network, leftover sample apps. Each one is a running program that accepts input from outside, which means each one is a potential way in. The fix is two-sided: stop services you don’t need, and block the ports you’re not using with a firewall.

A firewall is simply a gatekeeper that decides which network traffic is allowed to reach your server. The right way to configure one is the deny-by-default approach: block everything, then open only the specific ports your server actually serves on — typically the web ports (80 and 443) and your SSH port. Everything else stays shut. The firewalls article explains the concept, and ports and protocols covers what those numbers actually mean.

# see which services are listening on the network
ss -tulpn

# a sensible default firewall posture:
#   - deny all incoming by default
#   - allow SSH (so you can still get in)
#   - allow web traffic (80 / 443)
#   - allow all outgoing

The mindset here is the same as with login: start from “nothing is allowed” and open only what’s genuinely required. It’s far safer than starting from “everything is allowed” and trying to remember what to close.

Keep the software up to date

A huge share of real-world breaks-ins don’t come from clever new attacks — they come from old, unpatched software with publicly known holes. Once a vulnerability is discovered and a fix is released, the details become public. Attackers then scan the internet for machines that haven’t applied that fix yet. If your server is behind on updates, you’re on that list.

Keeping software current is one of the highest-value, lowest-effort things you can do. On most systems you update everything through the package manager, and you can enable automatic security updates so critical patches land without you having to remember. The package managers article covers how installing and updating works on Linux.

# refresh the list of available updates, then apply them
# (commands vary by distribution; this is the common Debian/Ubuntu form)
apt update
apt upgrade

# many systems can apply security updates automatically —
# turning this on means critical fixes don't wait for you

Watch the doors: logs and intrusion basics

Hardening reduces the ways in, but it doesn’t make you blind to attempts. Servers keep logs — records of who connected, who tried to log in, what failed. Glancing at them tells you what’s hitting your machine, and a sudden flood of failed logins from one address is a clear sign something automated is hammering away.

You don’t have to watch logs by hand around the clock. Tools exist that read the logs for you and react automatically: if an address racks up too many failed login attempts in a short window, it gets temporarily blocked. This single measure neutralizes the most common attack on the internet — the slow, patient brute-force guess — without you lifting a finger. It’s the natural companion to everything above: hardening shuts the easy doors, and automated monitoring watches the ones that remain.

  too many failed logins from one IP
            │
            ▼
  monitor notices the pattern
            │
            ▼
  that IP is blocked for a while  ──►  bot gives up, moves on

A practical hardening checklist

You don’t have to do all of this at once, but here’s the order that gives you the most safety for the least effort, roughly from highest impact down:

1. Create a non-root user and use it for daily work; reserve admin power for sudo.
2. Set up SSH keys, then disable password login and direct root login.
3. Turn on a firewall with deny-by-default, opening only the ports you serve on.
4. Stop and remove services you don’t actually use.
5. Enable automatic security updates so patches land on their own.
6. Add brute-force protection that blocks IPs after repeated failed logins.
7. Check your logs on a regular rhythm so you know what’s hitting the machine.

Run through this once on a new server and you’ve already eliminated the overwhelming majority of automated attacks — the kind that make up most of what any server faces. None of it requires deep expertise. It’s discipline more than genius.

Why this matters even for small projects

It’s tempting to think hardening is only for big companies with sensitive data — that a small blog or a side project isn’t worth attacking. That’s a common and costly assumption. Most attacks aren’t targeted at you specifically. They’re automated sweeps looking for any vulnerable machine, regardless of how small or unimportant it seems. A compromised server is valuable to an attacker no matter what it was for: it can be used to send spam, mine cryptocurrency, store illegal files, or launch attacks on others. Your project’s size doesn’t protect it; only hardening does.

The encouraging flip side is that the bar is low to clear. Because so much of the internet is full of soft, un-hardened targets, doing even the basics here puts you far ahead of the crowd. Bots take the path of least resistance. Make your machine slightly harder than the average, and most of them simply pass you by.

Wrapping up

Here’s the whole picture in one place:

• Hardening means reducing a server’s attack surface — closing the doors you don’t need and locking the ones you do.
• It’s built on the principle of least privilege: give every user and process only the access it truly needs, so a single break-in can’t spread far.
• The biggest wins, in order: a non-root user, SSH keys with password and root login disabled, a deny-by-default firewall, removing unused services, and automatic security updates.
• Most attacks come from automated bots exploiting old, unpatched software and weak logins — not clever targeting. The basics defeat the vast majority of them.
• Watching logs and automated brute-force protection cover the doors that stay open.
• Size is no protection — small projects get attacked too, but the same basic steps protect them just as well.

From here, each piece deserves a closer look on its own. The next natural step is going deeper on the most-attacked door of all — securing SSH properly, from keys to configuration — so the single biggest part of this checklist is rock solid.