How exposed is this box? Read it, then fix it on the same row.

ufw or firewalld, whichever the box runs, with iptables and nftables read and judged behind them. Eight tabs: the verdict, what is reachable — every listening port judged against the rules, so a service open to the world is a finding and not a guess — the rules themselves folded so a v4 rule and its v6 twin are one line, what is open to the world by name, who may reach SSH, the defaults in words, who is knocking (refused connections folded by address), and the log.

One dialog covers a preset, a new rule, or the SSH question, and it asks it the way a person asks it: to whom. Allow and deny rows, denies written before allows, a preview of what will be written. And one invariant that cannot be argued with: the SSH port is allowed before the firewall is ever turned on, its rule cannot be removed while it is the only cover, and a rule that would deny your own address is refused — on screen, and again in Go before anything is written.

sshd is the one door Lens itself comes through, so every change to it can lock you out — which is why this screen works differently from every other. Hardening is a batch: Lens writes its drop-in at /etc/ssh/sshd_config.d/00-lens.conf, sshd validates the file, sshd reloads, and then Lens opens a fresh login from your computer on the port now in force. If that login fails, the previous file comes back by itself and the screen says: reverted.

Two refusals come with it. Root login cannot be turned off unless somebody else can get in and become root. Password logins cannot go off until your key alone has proven a fresh login. Beyond the batch: who can log in reads every account's door — keys, password, AllowUsers, AllowGroups; your login switches Lens's own session to one of your keys already on the box; who logged in folds the sshd log by address with the keys named by fingerprint. Lens makes no key and holds none of yours.

Fail2Ban as doors rather than as jails: SSH, the web logins, mail, FTP, the databases — each switched on with a click, each reading the log that box actually writes. The rule in words: how many tries, in how long, banned for how long, per door or for all of them. Who is banned right now and why, who is never banned, who is refused for good, the activity folded over a window, the log, and an alert by mail through the box's own Postfix when a ban happens.

Lens owns exactly one file here, /etc/fail2ban/jail.d/zz-lens.local, read last so it wins; the package's own files and anything you wrote by hand are never touched.

Inside the web server, ModSecurity with the OWASP Core Rule Set — libnginx-mod-http-modsecurity or libapache2-mod-security2 with modsecurity-crs — reads every request and stops the ones shaped like an attack: an injection, a traversal, a scanner, before the site sees them. One form per engine: the paranoia level, the anomaly thresholds, and whether it is detecting or blocking.

At the door, CrowdSec with its firewall bouncer reads the logs, recognises an attacker by behaviour, and bans the address at the firewall for every port — not only the one it knocked on — and shares reputations, so an address that hit someone else this morning is already banned here. Three levers, because those are the three a person actually pulls: what it reads (a log file, a container's output, a unit's journal, each a file Lens owns in acquis.d), alerts by mail, and scenarios switched between watching and banning.

A box that serves the web wants both; a box that does not still wants CrowdSec. Your own address is allowed in one and whitelisted in the other, and neither can be told to block it.

Nothing on a box tells you it has been changed. These three do, and Lens installs and runs each of them as a job you watch, saving its report on the server so what you see is the last result at any time.

Packages against what the distribution shipped — debsums on Debian and Ubuntu, rpm -V on Rocky and Alma: every file that came from a package, compared with the checksum the package carries. A changed binary in /usr/bin shows up here and nowhere else.

Files against a baseline — AIDE: installed, initialised into a baseline of the filesystem, then checked against it whenever you ask. What was added, what changed, what disappeared, explained in words rather than as a hash diff.

Rootkits — rkhunter and chkrootkit, both, because they look for different things: known signatures, hidden processes, wrong permissions on system binaries, suspicious kernel modules. Warnings Lens recognises carry their meaning and, where one is a known false positive on that distribution, a one-click "this one is known".

Then the part that makes it real: a schedule of systemd timers Lens owns — AIDE at an hour you pick, the rootkit scan on a day and hour, the package check on another — and a mail through the box's own Postfix when something changed since last time. The two "accept the current state" actions get a sentence before you press them, not after, because they are the only things on this screen that can hide an intruder.

Permissions say who owns a file. Mandatory access control says what a program may do at all — so a web server that is compromised still cannot read /etc/shadow, because the kernel refuses regardless of who it thinks it is.

The screen's real job is the denials, and it leads with them: a refusal is far more often a wrong label than an attack, and Lens says which is which, with the fix when it knows it from the meaning. Then the state — AppArmor's profiles in enforce or complain, SELinux's mode, its booleans and its file labelling — and, last, what is listening on this box with nothing confining it at all.

The standard sysctl hardening, grouped the way it is reasoned about: Network — spoofing, redirects, floods; Kernel — pointer exposure, debugging, BPF, ASLR; Filesystem — hard and symbolic links, FIFOs, core dumps. Each switch is read as it is right now, said in words, and set through one file Lens owns, /etc/sysctl.d/90-lens-hardening.conf, live and at boot in the same action.

Every switch that can be written and is not yet right is ticked by default, so hardening a fresh box is one press. And every value Lens changes is remembered as it was, so Remove does not mean "set it to what a blog said": it puts the box back exactly as it was before Lens touched it.

Passwords. What a password must be, how long it lives, and what happens after too many wrong ones — through libpam-pwquality, faillock and login.defs — and, beside the policy, which accounts on this box break it right now. Installing the policy packages asks first and says what they do.

Scheduled tasks. Everything the box runs on its own: cron in all of its places, systemd timers, at jobs, with who runs each one and from where. Persistence is where an intruder lives after the first day, so the shapes it takes are called out by name; this is the list a responder asks for first. Your own entries go in /etc/cron.d/lens, the one file here Lens writes and removes lines from.

Time and entropy. Is the clock right and who keeps it so — chrony, systemd-timesyncd or ntpd, whichever the box runs — because an hour of drift breaks certificates, one-time codes and every log correlation you will ever do. And whether the box has a real source of randomness, with rng-tools where it does not.