Understanding the threats to a Linux host

Who attacks a Linux server, and why?

A server on the network is never attacked by chance: it is attacked continuously, by automated tooling and by humans, the moment it has a routable address. The attackers fall into a few profiles, each with a goal:

• Opportunistic botnets: scan the entire IPv4 space for weak SSH passwords, exposed services and known CVEs; their goal is resource theft (cryptomining, spam relays, DDoS muscle).
• Ransomware crews: get a foothold, escalate, spread, then encrypt and extort.
• Targeted / state actors: patient, after data exfiltration and long-term persistence.
• Malicious insiders: already have an account; they abuse legitimate access.

What they all exploit is the attack surface: every open port, running service, installed package, SUID binary, account with a shell, loadable kernel module, world-writable file. The larger that surface, the more ways in, and a default Linux install ships a lot of surface a server never uses.

How a compromise unfolds: the kill-chain

A compromise is rarely a single event. It is a kill-chain, a sequence where each step depends on the previous one succeeding. The decisive insight is that the attacker needs every link to hold: hardening breaks the chain at as many links as possible, so a foothold stays a foothold. This table maps each step to its MITRE ATT&CK technique and the Pavois control family that breaks it:

Three concrete scenarios

1. SSH brute-force (T1110). A botnet sprays passwords at sshd. The chain breaks if root login is off, auth is key-only, and faillock locks the account:

# attacker
hydra -l root -P rockyou.txt ssh://victim
# hardened host: the door is already shut
sshd -T | grep -E 'permitrootlogin|passwordauthentication'   # no / no

2. Writable SUID / sudo misconfig (T1548). An unprivileged shell hunts a path to root:

# attacker
find / -perm -4000 -writable 2>/dev/null ; sudo -l
# hardened host: no stray SUID, sudo needs a password and a TTY

3. Silencing the audit trail (T1562.001). Before acting, the intruder tries to disable logging. Immutable audit rules defeat it:

# attacker
auditctl -e 0                      # disable auditing...
# hardened host: rules are immutable until reboot
auditctl -s | grep enabled         # enabled 2  => locked

What Pavois does NOT detect

Pavois audits configuration posture, not live behaviour. It deliberately does not, and cannot, replace runtime detection. It will not catch:

• an in-memory / fileless implant or a process already running maliciously,
• a zero-day in an application it does not model,
• live network intrusion (it is not an IDS/EDR),
• a compromised dependency at the application layer,
• an attacker who matches the hardened config yet abuses legitimate access.

Pavois shrinks the attack surface and proves the baseline; pair it with shipped auditd logs and an EDR/IDS for runtime detection. This honesty is the point: a green grade is a hardened configuration, not a clean-bill-of-health intrusion scan.

What Pavois audits

Pavois grades the effective configuration of the running host, exactly what an attacker meets. Where an OVAL/oscap scan reads /etc/... and is fooled by Includes, drop-ins or runtime overrides, Pavois queries the resolved state (sshd -T, sysctl -a, systemctl show). Across the domains that map onto the kill-chain it covers surface reduction (packages, services, modules), foothold hardening (SSH, password quality, lockout), escalation containment (sudo, UID-0, permissions, mounts), runtime and boot hardening (sysctl, kernel cmdline, GRUB), detection and persistence (auditd, journald), and the perimeter (firewall, banners). Each finding is scored A-E and tagged with the norms it satisfies (ANSSI BP-028, CIS, PCI-DSS, NIST, STIG), so a green baseline is a kill-chain with its links broken.

FAQ

Is Pavois an antivirus or EDR? No. It audits the host's hardening configuration (the attack surface and posture), not running processes or network traffic. Use it alongside an EDR/IDS, not instead of one.

Why map controls to MITRE ATT&CK? Because it ties each hardening rule to the concrete attacker technique it frustrates, so you can reason about which link of the chain a control breaks rather than treating hardening as an opaque checklist.

Does a green grade mean I'm not compromised? No. It means the configuration is hardened. An already-resident intruder, a zero-day or app-layer abuse is out of scope; that is what runtime detection and log analysis are for.