MYTHOSAI

Linux security / PRACTICAL GUIDE

First security checks on a new Ubuntu server

Inventory the server, apply ordinary updates and reduce exposure without losing remote access.

Before you start

A supported Ubuntu Server installation with sudo and a recovery console.

Identify before changing

A new server may already be carrying monitoring, backup or application traffic. Record its role and access method before copying a hardening script. Do not change its hostname or network address as an incidental security step.

Start with a read-only inventory:

bash
cat /etc/os-release
hostnamectl
ip -brief address
sudo ss -lntup
systemctl --failed

The output identifies the release, addresses, listeners and failed units. It does not reveal which ports are reachable through routers, cloud firewalls or tunnels; those are separate controls.

Build a safe maintenance sequence

  1. Confirm a backup and a console or recovery route independent of SSH.
  2. Check pending packages with apt list --upgradable after refreshing repository metadata.
  3. Apply ordinary updates during a suitable maintenance window and inspect the result. A release upgrade is a separate project, not an automatic part of this checklist.
  4. Confirm the administrative user can use sudo and a second SSH session works before restricting authentication or network access.
bash
sudo apt update
apt list --upgradable
sudo apt upgrade

Read prompts instead of blindly accepting changes on a production machine. Service restarts and kernel updates may affect availability.

Reduce the exposed surface

For each listener, record the application owner and reason it exists. A service required only locally may be able to bind to loopback; a site collector may need a specific private interface instead. Review the application's documentation before changing its bind address.

Use a firewall rule plan matching real services. Preserve the actual SSH port and any authorised monitoring or backup paths. Cloudflare web protection does not automatically protect every non-HTTP service listening on the server.

Verify after maintenance

Reconnect through the normal administrative route, check failed units again and test the server's actual job. For a collector, confirm fresh data arrives. For a backup server, confirm the relevant client can connect. Look at time synchronisation because incorrect timestamps make incident investigation harder.

Common mistakes

Opening every port to resolve one connection makes future investigation harder. Disabling security updates indefinitely creates debt. Assuming a local listening socket proves external access ignores routing and firewall layers. Keep a short change record and test one security change at a time so failures can be traced.

Official references

Consult the current vendor documentation if your version or screen differs.

Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.