How to Secure an Ubuntu 24.04 Server After Installation

The first hour after an Ubuntu 24.04 server is provisioned is a good time to establish a recoverable security baseline. Hardening is not one magic command: it is a sequence of access, patching, firewall, logging, and backup decisions. The safest approach keeps a working administrative path open while each change is tested.

This guide targets Ubuntu Server 24.04 LTS on a VPS or dedicated host managed with systemd. The commands are illustrative and must be checked against your provider's console, network rules, and application requirements. Before changing SSH or firewall settings, confirm you have out-of-band console access and an existing backup or snapshot. Do not apply these steps blindly to a customer production server.

1. Record the baseline before making changes

Identify the release, logged-in account, network listeners, and current firewall status. Preserve the output in a private change record so you can distinguish pre-existing exposure from a new mistake.

cat /etc/os-release
id
sudo ss -ltnup
sudo ufw status verbose
sudo systemctl --failed --no-pager

ss shows listeners, not necessarily internet reachability: a provider firewall may also block traffic. Look for unexplained services bound to 0.0.0.0 or ::. Investigate them before disabling anything used by the workload.

2. Create a named administrator and test access

Using a named account makes administrative actions more accountable. On a fresh Ubuntu host, the example creates a user and grants the distribution's sudo group. Replace operator with your approved account name. Add an SSH public key through your provider console or an existing secure channel; never paste a private key into a ticket or web form.

sudo adduser operator
sudo usermod -aG sudo operator
sudo -l -U operator

Open a second SSH session as the new user and verify sudo works before closing the original session. Check how cloud-init or your provider manages access keys; a later reprovision or image update may affect them.

3. Secure SSH in the right order

First make key-based login work for the named account. Only then consider disabling password authentication or direct root SSH login. Check /etc/ssh/sshd_config and any files under /etc/ssh/sshd_config.d/; a drop-in can override what you expected. Validate configuration with sshd -t before reloading.

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo systemctl status ssh --no-pager

The effective values from sshd -T are more useful than reading one file alone. Keep your verified session open while testing the new login path. Locking yourself out is not a security improvement.

4. Apply security updates with a maintenance plan

Refresh package metadata and inspect available upgrades. Kernel, OpenSSL, PHP, and database updates may require service restarts or a reboot. Coordinate these with the application's availability requirements and have a rollback plan.

sudo apt update
apt list --upgradable
sudo apt upgrade

apt upgrade changes installed software; run it only after reviewing the package list and maintenance window. Ubuntu supports automated security updates through unattended-upgrades, but automation still needs monitoring and a plan for restarts. Do not assume a package update is effective until the affected process has reloaded the new library or binary.

5. Add a firewall without cutting off SSH

Ubuntu documents UFW as a common firewall frontend. Before enabling it, allow the SSH port actually in use and any application ports required by your architecture. The commands below assume SSH on port 22 and a web server on 80/443; adapt them if your service differs.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered
sudo ufw enable

Confirm a new SSH connection still works. Review IPv6 separately if it is enabled. A host firewall is one layer; provider security groups, reverse proxies, and application access rules may impose additional restrictions.

6. Establish logs, monitoring, and recovery

Check that persistent journaling and application logs have appropriate retention. Monitor disk, memory, load, SSH failures, and service status. Set alerts to an address or system that will be read. Backups should be off-host where possible and periodically restored in a test environment; a backup job reporting “success” does not prove the data is recoverable.

sudo journalctl --disk-usage
systemctl list-timers --all --no-pager
sudo systemctl --failed --no-pager

Document who owns patching, backup restore testing, certificate renewal, and incident response. Hardening without operational ownership tends to decay as services and staff change.

Troubleshooting and common errors

• SSH stops working after UFW: use the provider console, verify the allowed port, and confirm whether the provider firewall also changed. Do not disable the firewall blindly on a shared host.
• A service disappears after updates: inspect systemctl status and its journal, then compare package and configuration changes before restarting the application.
• Unexpected listener remains: use ss -ltnup to identify the process and determine whether it belongs to the intended workload.
• Automatic updates restart a service at a bad time: review unattended-upgrades and needrestart policies, then schedule maintenance around stateful workloads.

Security considerations

Keep private keys and recovery-console credentials outside the server and out of support tickets. Grant sudo only to administrators who need it, and review those memberships periodically. Protect logs and backups because they can contain customer data. A firewall rule or SSH change should be audited with the operator, time, reason, and a tested rollback path.

FAQ

Is changing the SSH port enough to secure SSH?

No. It may reduce some noise, but account hygiene, keys, least privilege, update management, and monitoring matter more. A custom port must also be handled by the firewall and provider network rules.

Should I disable root login immediately?

Only after a named administrator's key-based login and sudo access have been tested in a second session and you have a recovery console. Otherwise you can lock yourself out.

Is UFW required if the provider has a firewall?

They protect different layers. A host firewall can limit traffic even if provider rules are changed, but overlapping rules must be documented and tested.

Continue reading

Compare a Debian-specific approach in Debian 12 server hardening, then build a backup and restore test plan. For a reviewed baseline and ongoing operations, discuss server management with East4Serv.

References: Ubuntu Server security suggestions, Ubuntu user management, and Ubuntu firewall guidance.