Learn Linux server security
Plain definitions of the terms, and guides that solve one problem each with read-only commands you can check yourself. Written for people who run Linux servers without a security team.
If you think a server was compromised
Start with the triage sequence, then go deeper on the step that turned something up. Read-only commands throughout; nothing here deletes evidence.
SSH and brute force
Why every server sees login attempts, which ones matter, and how to make guessing pointless.
Hardening and privilege
Getting a server into a good state, and noticing when it drifts out of one.
A vulnerability in the news
What a named vulnerability means for a server you run, and for a site on hosting someone else runs.
Concepts
What the categories mean, so you can tell products and approaches apart.
Glossary
26 terms, each defined in a sentence or two. The link under each one goes to the page that explains it in full.
- AI security audit
An automated review of a server's security posture in which an AI system reads the evidence collected from the server (configuration, accounts, packages, exposure) and returns ranked findings, each with the evidence behind it and a recommended fix. A finding is a lead to check, not a verdict.
Read more about AI security audit- Attack surface
Everything on a server that someone outside can reach and try to abuse: listening services, open ports, web applications, login methods and the accounts behind them. Reducing it (closing ports, binding databases to localhost, key-only SSH) removes risk rather than watching for it.
Read more about Attack surface- Automated incident response
Actions a security tool takes on its own when it detects an attack, such as blocking an attacking address at the firewall. The questions that matter are which actions run without a person, which wait for approval, and how a wrong action is undone.
Read more about Automated incident response- Autonomous server security
Security software that detects threats on a server and can act on them without a person approving each step, within limits the owner sets. In practice the limits are the point: what it may do alone, what it must ask about, and how it rolls back.
Read more about Autonomous server security- Compliance evidence
A dated record showing that a control was in place and operating for a stated scope, such as a configuration export, a log, a file integrity report or a vulnerability scan with the patches that followed. Evidence feeds an assessment; it is not certification.
Read more about Compliance evidence- Cryptojacking
Using someone else's server to mine cryptocurrency without permission, usually Monero with XMRig after an attacker gets in through a weak password, an exposed service or a vulnerable application. The miner is a symptom: it proves someone can run code on the server.
Read more about Cryptojacking- CVE
Common Vulnerabilities and Exposures: the public identifier given to a known security flaw in a specific piece of software, such as CVE-2024-6387 in OpenSSH. Whether a server is affected depends on the exact package version its distribution ships, because distributions backport fixes without changing the upstream version number.
Read more about CVE- EDR
Endpoint detection and response: software that records detailed activity on each endpoint and gives an analyst actions such as isolating a host. Built mainly for large fleets with a security team watching it.
Read more about EDR- fail2ban
An open-source tool that reads log files or the systemd journal, counts failures per source address, and adds a temporary firewall ban when an address fails too often within a window. It answers guessing; it cannot tell whether a guess already succeeded.
Read more about fail2ban- File integrity monitoring (FIM)
Recording a cryptographic hash, owner and permissions of the files that matter, checking them again later, and reporting what changed. Useful only when it covers the right paths and someone can tell a planned change from an unplanned one.
Read more about File integrity monitoring- Host-based intrusion detection (HIDS)
Software that runs on a server and watches it from the inside (logs, file integrity, processes and connections) for signs of attack or compromise, and reports with the evidence. It detects; it does not prevent. OSSEC and Wazuh are open-source examples.
Read more about Host-based intrusion detection- Incident response
The ordered work after a suspected compromise: preserve evidence, contain, establish scope, rotate credentials, eradicate or rebuild, recover, and record what was learned. On a server where root was compromised, rebuilding from a known-good image is usually safer than cleaning.
Read more about Incident response- Indicator of compromise (IoC)
An observable sign that a system may have been compromised: an unexpected login, a new key or account, a process running from /tmp, a connection to an unfamiliar address. One indicator is a reason to look, not proof.
Read more about Indicator of compromise- Least privilege
Giving each account and program only the access it needs, and no more: no shared root logins, sudo for named commands rather than everything, services running as their own users. Privileges tend to grow over time unless someone checks.
Read more about Least privilege- Linux server security
Keeping an internet-facing Linux server from being taken over, and knowing quickly when someone tries or succeeds: hardening, patching, access control, monitoring of what changes on the host, and a plan for responding.
Read more about Linux server security- Listening port
A network port on which a program is waiting for connections. A service bound to 0.0.0.0 or :: listens on every interface and can be reached from outside unless a firewall stops it; one bound to 127.0.0.1 is reachable only from the server itself.
Read more about Listening port- Persistence
Whatever an attacker sets up to keep access after a reboot or a password change: a cron line, a systemd service or timer, an SSH key, a new account, a modified startup file. Finding and removing all of it is why rebuilding is often safer than cleaning.
Read more about Persistence- Privilege drift
The slow accumulation of access nobody planned: a sudo rule added for a one-off task, an account left in the docker group, a key that outlived its owner. Each change looks harmless; together they widen what one stolen account can do.
Read more about Privilege drift- Privilege escalation
Going from limited access (a web application user, an ordinary account) to more, usually root, through a misconfigured sudo rule, a setuid binary, a writable script that root runs, or a kernel or package vulnerability.
Read more about Privilege escalation- Security agent
A program installed on a server that runs continuously, collects security data from the host and sends it to a platform for analysis; some can also act, for example by adding a firewall rule. Because most need root, installing one is a trust decision.
Read more about Security agent- Server hardening
Reducing what can go wrong on a server before anything happens: key-only SSH, a default-deny firewall, automatic security updates, fewer running services, least privilege. Hardening drifts as the server changes, so it has to be checked, not just done once.
Read more about Server hardening- SIEM
Security information and event management: a central system that collects logs and alerts from many sources and correlates them. It watches no host itself; it depends on what is sent to it.
Read more about SIEM- SSH brute-force attack
Automated, repeated guessing of usernames and passwords against a server's SSH service. Every public server sees it; it only becomes dangerous where password login is allowed.
Read more about SSH brute-force attack- Threat detection
Continuously evaluating what a server is doing (authentication, processes, files, network) against what it normally does and what an attacker needs to do, and reporting the difference with enough evidence for a person to decide.
Read more about Threat detection- Web shell
A script, usually PHP on Linux web servers, that an attacker uploads through a vulnerable application so they can run commands on the server from a browser. It runs as the web server's user, and is often the first step before privilege escalation.
Read more about Web shell
Free tools
Checks you can run now. The paste-in checkers run in your browser and send nothing anywhere.