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

The first three cards are the questions an auditor asks first. Exposure is every port something listens on, with its process, judged against the firewall and against docker: reachable from anywhere, from some addresses, not at all, this box only, or published past the firewall by docker. The web and SSH are expected; anything else open to anywhere is the finding, and the fix is on its row — Close, Private network only, Only to me, or Open to the world when you mean it.

Access is every authorized key on every account — whose it is, how old the file is, which account it opens — who may become root and whether a password is asked, and the accounts that are locked, have no password or never logged in. Weak keys, keys on service accounts and root by password are called out, with Remove this key, Take sudo away, Make it ask a password, Lock and Take the shell away on the row.

Permissions & secrets scans the disk for what is open to everyone: world-writable paths, setuid programs no package installed, files nobody owns, secrets anyone can read, /tmp and /dev/shm without noexec, system files that should be root's alone, the umask. The fixes that cannot stop anything working go together under one button; a setuid bit off, noexec on a mount and the umask are asked one at a time, each saying what stops working.

ufw or firewalld, whichever the box runs, with iptables and nftables read and judged behind them. Seven tabs: the verdict — where a card says how many listening ports are reachable and opens Exposure — 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 Vigia 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: Vigia writes its drop-in at /etc/ssh/sshd_config.d/00-lens.conf, sshd validates the file, sshd reloads, and then Vigia 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 puts the public half of one of your keys on the box, proves a fresh login with it, and logs in with it from then on; who logged in shows who is connected right now, with End it beside every session but yours, and folds the sshd log by address with the keys named by fingerprint. A saved login remembers where your key file is, not the key, and a key Vigia makes for you is made on your computer and saved where you say.

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 alerts by mail through the box's own Postfix — one the moment an address is banned, a digest of the last 24 hours once a day, or both.

The jails Vigia sets live in exactly one file, /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 Vigia 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 Vigia 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 Vigia recognises carry their meaning and, where one is a known false positive on that distribution, a one-click accept that tells rkhunter to expect it.

Then the part that makes it real: a schedule of systemd timers Vigia 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 Vigia 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 Vigia 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 Vigia 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 Vigia 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.

Also read on this box. Scheduled tasks, the clock, automatic updates, auditd and the certificates are part of how exposed a box is, so the Overview reads them as well and counts them in its verdict — a row each, and a click lands on its tab under System Setup, where they are run. Scheduled tasks earn their place for one reason: persistence is where an intruder lives after the first day, and that list calls out the shapes it takes by name.