Ubuntu Server Hardening: USG, Livepatch, Pro and AppArmor

Ubuntu Server runs a large share of cloud and container hosts, and most of them are hardened only as far as the stock image goes. The image is a reasonable start, with AppArmor and automatic security updates on, but it leaves packages in Universe unpatched without Ubuntu Pro, kernel fixes waiting for a reboot that never comes, and CIS or DISA STIG settings unapplied. This guide covers the Ubuntu-specific layer: the support model and Expanded Security Maintenance, the Ubuntu Pro client and its attach token, the Ubuntu Security Guide (USG) for CIS and STIG, Livepatch, unattended-upgrades and needrestart, AppArmor, and the identities an Ubuntu host holds. It builds on the distribution-neutral Linux Server Hardening Guide and is written for Linux, cloud and platform engineers running Ubuntu 22.04, 24.04 and 26.04 LTS.

Key takeaways

Know which packages you are actually patching. Standard security maintenance covers Main for 5 years per LTS; Universe, where many server packages live, is covered by Expanded Security Maintenance (ESM Apps) only with Ubuntu Pro. Run pro security-status to see the gap.
Use USG for CIS and STIG, with tailoring. usg audit <profile> writes HTML and XML reports to /var/lib/usg/; usg fix changes the system, so audit and tailor first and pilot the fix.
Livepatch narrows the kernel window, not the reboot need. It patches high and critical kernel vulnerabilities on running machines, but kernel upgrades and other fixes still need scheduled reboots.
Automatic updates are on by default; reboots are not. unattended-upgrades applies security and ESM updates daily, Automatic-Reboot defaults to false, and from 24.04 needrestart restarts affected services automatically.
Keep AppArmor enforcing and treat tokens as credentials. Disabling AppArmor is on Canonical's own list of common security mistakes, and the Pro attach token, cloud-init user data and default cloud users need the same care as any secret.

How identity and access work in Ubuntu Server

Ubuntu uses the standard Linux stack: NSS for user lookup, PAM for authentication (configured through pam-auth-update rather than hand edits), sudo for privilege, and OpenSSH for remote access. What differs is how hosts are built and joined.

Deployment	Initial identity	Hardening point
Cloud image with cloud-init	A default user (named `ubuntu` on Canonical images) with the SSH key from instance metadata and passwordless sudo	Replace with named accounts or directory login; remove or restrict the default user's sudo; keep secrets out of user data, which is readable from the metadata service
Server ISO (Subiquity)	The user created during install, in the `sudo` group; root has no password	Keep root locked; import SSH keys at install and disable password authentication
Active Directory join	SSSD through `realm join`	Restrict login to AD groups and map sudo to a group. See the SSSD and Linux Active Directory Integration Guide
Central Linux identity	FreeIPA or LDAP through SSSD	Host-based access rules and sudo rules from the directory. See the FreeIPA and Red Hat Identity Management Guide

PAM changes: use pam-auth-update profiles so package upgrades do not overwrite manual edits in /etc/pam.d/common-*. See the Linux PAM Guide.
SSH: key-only authentication, no root login, and an allow list of groups. See the OpenSSH Server Hardening Guide for the server settings.

Admin roles and privileged access

The sudo group: on Ubuntu, membership of sudo grants full root through sudo. Keep it to named administrators and use narrow rules in /etc/sudoers.d/ for operators and automation. See the sudo and sudoers Security Guide.
Other powerful groups: adm can read most logs, lxd membership can be used to obtain root through privileged containers, and docker membership is equivalent to root. Audit these groups as privileged.
Root: root has no usable password on a default install; keep it that way and rely on a vaulted console path for recovery.
Who can change the subscription: pro attach, pro enable, pro disable and pro detach need root. Disabling ESM or USG on a host silently removes protection, so alert on these commands.
Unprivileged user namespaces: AppArmor can deny unprivileged user namespaces to applications without an explicit profile rule, closing a route that local privilege escalation exploits have used. Keep that restriction where your workloads allow it and grant exceptions per profile.

Integrations, API tokens and service accounts

Credential	What it does	Control
Ubuntu Pro attach token	`pro attach [token]` binds a machine to your subscription; the token comes from the Pro dashboard	Treat as a secret: keep it out of AMIs, Packer templates and Git; use `pro attach --attach-config` from a protected file, `pro auto-attach` on Pro cloud images, and `pro detach` at decommission
cloud-init user data	Runs as root at first boot; often carries keys and passwords	No long-lived secrets in user data; fetch secrets at runtime from a secrets manager with the instance's workload identity. See the Cloud Instance Metadata Services Compared Guide
Automation SSH keys	Ansible, Landscape or CI deploy users	Dedicated service users with narrow sudo, keys in a vault, expiry or SSH certificates. See the SSH Key Management Guide
Snap and APT repository credentials	Private PPAs, mirrors and artefact repositories	Signed repositories with `Signed-By`; scoped read tokens; never `[trusted=yes]`
Application service users	Run daemons	`/usr/sbin/nologin` shells, systemd sandboxing, AppArmor profiles. See the systemd Service Hardening Guide

Record each in the service account inventory with an owner and rotation date; the Service Account Security Guide covers the lifecycle.

Support model, ESM and patching

Release	End of standard security maintenance	With Ubuntu Pro (ESM)
20.04 LTS	May 2025 (now ESM only)	10 years in total; Legacy add-on adds 5 more
22.04 LTS	May 2027	10 years in total
24.04 LTS	May 2029	10 years in total
26.04 LTS	May 2031 (released April 2026)	10 years in total
Interim releases	9 months	Not for production servers

Main vs Universe: standard maintenance covers Main; ESM Infra extends Main and ESM Apps covers Universe. Both arrive through APT from esm.ubuntu.com, and the Pro client pins ESM packages at priority 510 (in /etc/apt/preferences.d/ubuntu-pro-esm-infra and ubuntu-pro-esm-apps) so ordinary updates cannot replace a fix.
unattended-upgrades: installed by default and runs daily. /etc/apt/apt.conf.d/20auto-upgrades decides whether and how often it runs; 50unattended-upgrades sets Allowed-Origins (by default the release, security pocket and ESM pockets), blocked packages and reboot behaviour. Logs are in /var/log/unattended-upgrades.
Reboots: Unattended-Upgrade::Automatic-Reboot defaults to false. Either enable it with an Automatic-Reboot-Time in a maintenance window, or run a reboot orchestration process that reads /var/run/reboot-required.
needrestart: from 24.04 restarts affected services automatically after updates (configured in /etc/needrestart/needrestart.conf), so library fixes take effect without a reboot.
Livepatch: part of Ubuntu Pro; the client checks for, verifies and applies patches for high and critical kernel vulnerabilities on the running kernel. An on-premises Livepatch Server supports staged rollout and air-gapped networks. It complements, not replaces, kernel package upgrades.
Targeted fixes: pro fix CVE-xxxx-xxxxx (or a USN ID) inspects and resolves a specific issue; --dry-run shows what it would do, and exit code 2 means a reboot is required. See the Patch Management Guide.

Logging and detection

Authentication logs: SSH, sudo and PAM events go to the journal and, where rsyslog is installed (the server default), to /var/log/auth.log. Forward both centrally.
auditd: not installed on a default server; install auditd where the CIS or STIG profile requires it, and USG will configure rules. See the Linux Logging and auditd for Defenders Guide.
AppArmor denials: logged with PID, process, path, request and profile name, typically to /var/log/syslog or /var/log/audit/audit.log. A burst of denials for a service is either a bad update or code doing something it never did before.
Patch state: collect pro status --format json and pro security-status --format json from every host so the SIEM or CMDB knows which hosts lack ESM, Livepatch or USG.

Technique (ATT&CK v20)	What to watch on Ubuntu	Preventive control
T1098.004 SSH Authorized Keys	Changes to `~/.ssh/authorized_keys`, especially for the default cloud user and service users	Directory or certificate-based SSH, file integrity monitoring
T1543.002 Systemd Service	New or modified units under `/etc/systemd/system/`	Package-managed services only, change control
T1053.003 Cron	New files in `/etc/cron.d/` and user crontabs	USG rules on cron permissions, monitoring
T1548.003 Sudo and Sudo Caching	sudo by accounts outside the expected groups, edits in `/etc/sudoers.d/`	Narrow sudo rules, alerting on sudoers changes
T1068 Exploitation for Privilege Escalation	Crashes and AppArmor denials around setuid binaries and namespaces	ESM coverage, Livepatch, AppArmor user namespace restriction

Hardening baseline

USG profile	Benchmark	Typical use
`cis_level1_server`	CIS Ubuntu Linux Benchmark, Level 1 Server	Default for commercial servers
`cis_level2_server`	CIS Level 2 Server	High-value or regulated servers; more breakage risk
`cis_level1_workstation` / `cis_level2_workstation`	CIS Workstation profiles	Desktops and developer machines
DISA STIG profile	DISA STIG for the Ubuntu release (for example V2R8 for 22.04, V1R1 for 24.04 per Canonical's table)	US federal and defence workloads

Attach and enable: attach the host to Ubuntu Pro, confirm ESM Infra and ESM Apps are enabled with pro status, and enable Livepatch and USG with pro enable. Enable FIPS only where required and only after reading Canonical's FIPS pages, since FIPS kernels and modules change what is supported.
Audit: sudo usg audit cis_level1_server; review the HTML report in /var/lib/usg/ with the service owner.
Tailor: compliance is not all-or-nothing; generate a tailoring file, disable rules that conflict with the workload and record why, and set values for rules with options.
Pilot: apply with sudo usg fix <profile> on a snapshot or a pilot ring, or produce a script with sudo usg generate-fix <profile> --output fix.sh to bake into an image. Rollback is the snapshot or a rebuild from the previous image.
Bake it in: apply the tailored profile in the image pipeline so new instances start compliant, then re-audit on a schedule to catch drift.
Close the network: enable ufw or nftables with default deny inbound and only required ports, since unnecessarily open ports are on Canonical's list of common mistakes.
Keep AppArmor enforcing: put custom services into complain mode only while building profiles, then enforce. See the AppArmor Guide.
Kernel and sysctl: avoid the dangerous sysctls Canonical warns about and follow the Linux Kernel Hardening and sysctl Guide.

Common misconfigurations

Assuming "security updates on" covers everything: without Pro, Universe packages such as many language runtimes and web components get no security maintenance; pro security-status shows how many installed packages are in that state.
Downloading .debs by hand: Canonical lists direct downloads from the archive and from untrusted sources as common mistakes; packages installed that way never update. Use signed repositories. The XZ Utils backdoor showed how much rides on repository and maintainer trust. See the Linux Package Signing and Repository Trust Guide.
Livepatch as a reason never to reboot: uptime of hundreds of days with Livepatch on still leaves non-kernel components and kernel fixes outside Livepatch's scope.
Running usg fix untailored: a full Level 2 profile applied in place breaks SSH access patterns, mounts or services in production.
Disabling AppArmor to fix an application: another item on Canonical's list; write or adjust the profile instead.
Pro tokens and secrets in images: an attach token or deploy key in a public image or repository lets anyone consume your subscription or log in to your fleet.

Decision guidance and framework mapping

Pro or not: Ubuntu Pro is worth it wherever Universe packages run in production, where you need USG, Livepatch or FIPS, or where a host will outlive 5 years of standard support. Without it, minimise Universe packages and plan upgrades to the next LTS within standard support.
CIS or STIG: CIS Level 1 Server for most organisations, STIG where contracts require it. Pick one per host class.
Small vs large: small teams can rely on unattended-upgrades with automatic reboots in a window, USG audits and AppArmor defaults; large fleets should manage Pro attachment, Livepatch policy (or an on-premises Livepatch Server), USG tailoring and reboot orchestration centrally, for example through Landscape or Ansible.

Ubuntu control	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1
USG audit, tailoring and fix	CM-2, CM-6	PR.PS-01	4
ESM, unattended-upgrades, Livepatch, pro fix	SI-2, RA-5	PR.PS-02, ID.RA-01	7
Supported LTS lifecycle	SI-2	ID.AM-08	2
sudo, groups, SSH, SSSD	AC-2, AC-6, IA-2	PR.AA-01, PR.AA-05	5, 6
AppArmor, ufw	AC-3, CM-7, SC-7	PR.PS-01, PR.IR-01	4, 13
Logging and audit	AU-2, AU-6, AU-12	PR.PS-04, DE.CM-09	8

Metrics: percentage of hosts attached to Pro with ESM Infra and ESM Apps enabled; installed packages without security coverage per pro security-status (target near zero); hosts on an LTS past standard support without ESM (target zero); median days with /var/run/reboot-required present; USG audit pass rate per profile against the tailored baseline; and services running unconfined that have an available AppArmor profile.

Practitioner checklist

Inventory Ubuntu releases and plan upgrades before standard support ends; attach Pro where hosts will outlive it.
Run pro security-status on every host and enable ESM Apps where Universe packages are installed.
Audit with USG, tailor the profile, pilot usg fix and bake the result into images.
Confirm unattended-upgrades covers security and ESM origins, and define how and when hosts reboot.
Enable Livepatch for hosts with long reboot cycles, without dropping scheduled kernel upgrades.
Replace default cloud users with named or directory accounts and restrict the sudo, lxd and docker groups.
Keep Pro attach tokens, deploy keys and secrets out of images, user data and repositories.
Keep AppArmor enforcing and profile custom services.
Forward auth logs, AppArmor denials and Pro status to central monitoring.

Ubuntu Server Security Hardening Guide: USG, Livepatch, Ubuntu Pro and AppArmor in Practice