Where the authentication log actually is
This detail causes more confusion than any other on Ubuntu, usually when configuring fail2ban. Ubuntu Server still installs rsyslog by default, so sshd events are written to /var/log/auth.log as they always have been, and tooling that reads that file works.
The exception is minimal, container and some cloud images that ship without rsyslog. There, sshd logs only to the systemd journal, /var/log/auth.log does not exist, and anything pointed at that file silently matches nothing while still reporting as healthy. Debian 12 removed rsyslog from default installs, which is why advice written for Debian often does not describe what you see on Ubuntu.
Before assuming a log-reading tool is misconfigured, check whether the file exists. SecAI reads authentication events from the file where it is present and handles the journald-forwarded timestamp format, so it works on both shapes.
unattended-upgrades: useful, and narrower than assumed
Ubuntu ships unattended-upgrades and enables security updates by default on server installs, which is a genuinely good default and does most of the routine patching for you.
Two limits matter. It applies updates from configured origins, by default the security pocket, so software installed outside apt, from a third-party PPA, or compiled from source is not covered by it at all. And a package can be upgraded while the running process keeps the old code in memory: a library update does not restart the services linked against it, so the vulnerable code is still executing until something restarts. This is why /var/run/reboot-required exists and why "apt says it is patched" is not the same as "the running system is patched".
SecAI inventories what is genuinely installed through dpkg and matches it against published CVE data, so the gap between what apt applied and what is actually exposed is visible rather than assumed.
UFW, nftables and where blocks actually land
Ubuntu presents UFW as the firewall interface, and behind it modern releases use nftables through the iptables-nft compatibility layer. That indirection is fine until two things interact.
The common surprise is Docker. Published container ports are handled in the DOCKER chain, which is evaluated before UFW rules, so a port you believe is closed by UFW is reachable if a container published it. Blocking an address in UFW does not necessarily protect a containerised service, and this catches people running an application in Docker behind a firewall that looks correct.
SecAI applies blocks using the tooling actually present on the server, and because it also watches connection state and process behaviour, an address reaching a service through a path the firewall does not cover is still visible.
systemd persistence paths worth watching
On a systemd distribution, persistence has more places to hide than crontab. An attacker who wants to survive a reboot has several options, and they are the paths worth monitoring.
- systemd units and timers in /etc/systemd/system, and user units under a user home directory, which are easy to overlook.
- Classic cron: /etc/crontab, /etc/cron.d and per-user crontabs.
- authorized_keys files, the most common way access is retained after a password change.
- sshd_config and its drop-in directory under /etc/ssh/sshd_config.d, where password authentication can be quietly re-enabled by a file that overrides the main config.
- Accounts and groups in /etc/passwd, /etc/shadow and /etc/group, plus sudoers and setuid binaries.
Typical Ubuntu server workloads and their exposure
Most Ubuntu servers run one of a small number of stacks: nginx or Apache with PHP-FPM serving WordPress or a framework application, a Node or Python application behind a reverse proxy, a database, or a Docker host running several of these.
Each has a characteristic first foothold. Web stacks are usually compromised through an application vulnerability that lets a file be written into a web-served directory. Docker hosts are more often reached through a published port that the operator believed was firewalled. Databases are typically reached with credentials taken from an application configuration file on the same machine.
Monitoring covers those shapes together: web content for webshells, processes and outbound connections for what runs afterwards, file integrity for persistence, and package inventory for the vulnerability that let it happen.
Installing on Ubuntu
One command. The agent is a single static binary with no kernel modules, so there is nothing to compile and no DKMS to break on a kernel upgrade, and it runs on current Ubuntu LTS releases including 22.04 and 24.04.
It does not require a control panel and does not conflict with one, and it coexists with fail2ban and UFW rather than replacing your existing configuration.