Debian 12 moved the authentication log
Debian 12 stopped installing rsyslog by default. System logs, SSH logins and failures included, are kept in the systemd journal, and /var/log/auth.log does not exist unless you install rsyslog yourself. Every guide, script and tool written on the assumption that the file is there now reads nothing. Some fail loudly: on Debian 12, fail2ban's SSH jail refuses to start until it is told to read the journal. Others simply report that all is quiet.
The events are all still there. "journalctl -u ssh" shows them, and tools can be told to read the journal instead. For fail2ban on Debian 12 that means "backend = systemd" and the python3-systemd package; the fail2ban package in Debian 13 sets that backend by default. What changed is only where to look, and that an upgrade from Debian 11 keeps rsyslog while a fresh Debian 12 or 13 install does not, so two servers on the same release can behave differently.
SecAI handles both shapes without configuration. The agent reads /var/log/auth.log where the file exists. Where there is no authentication log file at all and systemd is running, it reads sshd's lines from the journal instead, under either of the unit names distributions use for SSH.
Security updates are not automatic until you make them
Debian publishes security fixes through security.debian.org, in a suite named after the release: bookworm-security for Debian 12, trixie-security for Debian 13. Installing them is your job unless unattended-upgrades does it. The Debian installer does not install that package, so a server installed that way has no automatic updates until you add it; Debian's official cloud images do include it. Check rather than assume: "apt-config dump | grep -i periodic" should show both periodic settings as "1". The hardening guide has the commands and the verify step.
There is a second, quieter consequence. The package lists on the server are only refreshed when something refreshes them. SecAI reads pending updates with a simulated upgrade that changes nothing on the server and deliberately does not refresh the lists, so its count is as current as the last refresh. On a server where nothing refreshes them, "no pending updates" means nothing at all.
That is why SecAI does not rely on that count alone. Independently of apt, it matches the versions actually installed against published vulnerability data every 12 hours, so a package with a known CVE is reported even on a server whose package lists are months old. In the pending-update count, a package is treated as a security update when the archive it would come from is a security archive, such as Debian-Security.
The same package decides whether a pending reboot is visible. After a kernel update, /var/run/reboot-required is written by a hook that ships with unattended-upgrades. On a Debian server without that package nothing writes the file, so neither you nor SecAI, which reads the same file, can tell that the running kernel is older than the installed one. It is one more reason to install it.
How CVEs are matched to a Debian release
A CVE only matters to you if it affects the build your release ships. Debian backports fixes, so version numbers from the upstream project say little: the fixed package in Debian 12 usually has an older upstream version than the vulnerable one elsewhere. SecAI therefore queries OSV.dev for the Debian ecosystem of your exact major release and compares versions with dpkg's own ordering rules, not as plain numbers.
Two details keep the results honest. If the agent could not report the release, SecAI infers it from the version of the base-files package, which Debian versions per release, rather than skipping the server. And a finding is retired as patched only when the advisory itself names a fixed version and the installed build is at or past it. When an advisory names no fix, SecAI makes no claim either way and leaves the finding as reported.
A package you remove takes its findings with it on the next inventory, so the list reflects what is installed now, not what was installed once.
No firewall rules by default
A fresh Debian server accepts connections on every port that something listens on. nftables is the packet filtering framework underneath, the iptables commands are a compatibility layer over it, and nothing is configured until you configure it. ufw is not installed by default.
SecAI reports the state rather than assuming it. The agent asks ufw, firewalld, nftables and iptables in turn and reports which one answers, whether it is active, its default inbound policy and how many rules it has. It also reports whether the firewall really turns away traffic it does not list: a ruleset whose policy is accept and whose only rules ban single addresses looks busy and protects nothing, and SecAI says so.
Blocking uses the tool the server already runs: fail2ban, CrowdSec, CSF, firewalld or iptables, in that order for an SSH attacker. A minimal Debian server may have none of them. Installing ufw gives you a default-deny firewall and brings iptables with it, which is also what gives SecAI something to block with.
Accounts that packages create
Debian packages create system accounts as they install: some through adduser, numbered upwards from 100, and some through systemd-sysusers, numbered downwards from 999. On a monitoring tool that treats every new account as suspicious, a routine "apt install" looks like an intrusion.
SecAI checks where an account came from before rating it. When the account is declared in a sysusers.d file that belongs to an installed package, and dpkg verifies that file as unmodified, the finding is rated low. The rating stays higher regardless of origin when the account has a login shell, a home directory under /home, SSH keys, or user ID 0, because those are the properties an intruder's account has.
What is watched on a Debian server
- Authentication: SSH failures, successes after failures or from a new source, root logins, and which registered administrator key opened a session.
- Accounts and privilege: /etc/passwd, shadow, group and gshadow, sudoers and /etc/sudoers.d, authorized_keys, setuid binaries, and Debian's PAM stack in /etc/pam.d/common-auth and common-account.
- Persistence: /etc/crontab, /etc/cron.d, user crontabs in /var/spool/cron/crontabs, and units under /etc/systemd/system, with the text of each change.
- SSH configuration: the effective settings from "sshd -T", so a drop-in under /etc/ssh/sshd_config.d that re-enables passwords is seen.
- Packages: the dpkg inventory, matched against Debian advisories, plus pending updates and whether a reboot is pending.
- Web and network: web shell candidates in web roots, new outbound destinations, floods, and the certificates your sites actually serve.
Installing on Debian
One command, as root. The agent is a single static binary for x86_64 with no kernel module, so there is nothing to compile and nothing for a kernel upgrade to break. It needs systemd and the base tools a Debian server already has.
SecAI supports current Debian releases, which today means Debian 12 and Debian 13. The installer verifies the agent's Ed25519 signature before it installs anything, using an OpenSSL command that exists from OpenSSL 3.0; Debian 11 ships OpenSSL 1.1.1, so the installer stops there rather than install a binary it could not verify.