Overview

Every port a machine listens on is a door an attacker can knock on, and every service behind those doors is code that can have bugs. Network hardening is the discipline of reducing that exposure: closing doors you do not need, locking the ones you do, and making sure the most-attacked service (SSH) is not an easy way in. The theme throughout is default-deny. Rather than trying to block every known bad thing, you allow only what is required and refuse the rest. That inverts the odds: a new vulnerability in an unexposed service cannot be reached, and a firewall that starts from “deny all” fails safe.

The attack surface, and how to shrink it

A remote attacker interacts with your host through listening services and the firewall in front of them. Three layers of work reduce what they can touch, and they reinforce each other.

Layer	Question it answers	Primary tool	Sibling page
Reducing exposed services	What is even listening, and does it need to be?	ss, systemctl	Reducing Exposed Services
Host firewall	For the listeners that remain, who may reach them?	ufw, nftables	Firewalls
SSH hardening	Is the one door I must leave open actually locked?	sshd_config, fail2ban	SSH Hardening

Finding and removing unneeded listeners

Before you can defend the attack surface you have to see it. ss -tulpn lists every TCP and UDP socket in the listening state along with the process behind it. A fresh install often exposes more than you expect: a resolver, a mail transfer agent, a print service. Anything that does not need to be reachable should be disabled or bound to localhost, because a service that is not listening cannot be exploited from the network at all. This is the cheapest and most effective hardening step, and it is covered in Reducing Exposed Services.

Default-deny host firewalls

Even after trimming services, a firewall gives you a second, independent gate. A default-deny policy drops all inbound traffic except the specific ports you allow, which means a service that accidentally starts listening later is still unreachable. On Ubuntu the friendly frontend is ufw; underneath, the modern kernel framework is nftables (the successor to iptables). You will usually drive ufw day to day and reach for nftables when you need finer control. See Firewalls for a minimal default-deny ruleset and how the frontends map onto the kernel.

Hardening SSH, the most attacked service

SSH is almost always the one service you must leave open, which makes it the single most probed port on the internet. Password authentication invites brute-force attempts; leaving root login enabled hands out the highest-value target. The fixes are well established: key-only authentication, no direct root login, an explicit allow-list of users, and rate limiting to blunt automated attacks. See SSH Hardening for the exact sshd_config settings and where fail2ban fits.

Seeing the surface in one pass

The whole discipline starts from measurement. Two commands show what is exposed and what guards it.

# What is listening, and on which address?
sudo ss -tulpn
# What does the firewall currently allow?
sudo ufw status verbose

Expected output:

tcp LISTEN 0.0.0.0:22    users:(("sshd",pid=""789,fd=3))
tcp LISTEN 127.0.0.53:53 users:(("systemd-resolve",pid=612,fd=13))

Status: active
Default: deny (incoming), allow (outgoing)
22/tcp                     LIMIT       Anywhere

A listener on 0.0.0.0 that the firewall does not explicitly allow is either dead weight to remove or a rule to add on purpose. Loopback listeners (127.0.0.53) are already unreachable from the network. This one snapshot tells you which of the three sibling pages to open first.

Practical Guidance

1. Work in this order: first remove services you do not need, then firewall what remains, then harden the services you must keep open. Each step shrinks the work of the next.
2. Adopt default-deny everywhere: the firewall should drop by default, and services should bind to localhost unless remote access is genuinely required.
3. Enumerate your listeners with ss -tulpn before and after changes so you can prove the attack surface actually shrank.
4. Give SSH special attention, since it is the most attacked service and usually the one door you cannot close.
5. Test firewall and SSH changes on a snapshot VM, and keep a second access path open (console or a separate session) so a bad rule does not lock you out.