Harden the firewall on a VPS

This is for a self-managed VPS, not a shared-hosting account. Confirm that you have working SSH access and a provider-console recovery path before changing firewall rules. Keep your current SSH session open throughout the test.

1. Record the ports your site actually needs

List the current SSH port and every public service. A typical web server needs TCP 80 and 443; a private database should not be exposed to the internet. Mail, DNS, VPN or custom application ports need their own deliberate rules. If you do not know the existing port map, ask support before enabling a default-deny firewall.

2. On Ubuntu or Debian, add SSH access before enabling UFW

Check the current state with sudo ufw status verbose. If your office or VPN has a stable public IP, allow only that source to the actual SSH port: sudo ufw allow proto tcp from YOUR_STATIC_IP to any port YOUR_SSH_PORT. If your address changes, use an appropriately controlled VPN or temporarily allow the SSH port while you establish a safer access path. Never paste the placeholders literally.

For a public website, add sudo ufw allow 80/tcp and sudo ufw allow 443/tcp. Review the result with sudo ufw status numbered, then run sudo ufw enable. Rocky Linux uses firewalld instead; do not paste UFW commands into a different firewall.

3. Verify and keep a recovery path

From a second terminal, open a fresh SSH connection and load the website over HTTPS. Only close the first session after both work. If the second login fails, use the still-open session or the provider console to correct the rule; a support ticket is not an instant rescue console. Recheck rules after adding new services.

Network-level DDoS filtering does not replace a host firewall. The exact UFW syntax and status commands are documented in Ubuntu Server's firewall guide.