UFW Firewall Hardening Checklist for Ubuntu Cloud Servers

When a new Ubuntu VPS is spun up, the first instinct is to install the application stack and go live. Too often, the default firewall configuration is left untouched, exposing the server to brute‑force attacks, port scans, and lateral movement. This field‑notes checklist captures the essential decisions, risks, and operational verifications you need to lock down Uncomplicated Firewall (UFW) without turning the server into a black hole.

Decision Point: Define Your Default Policy

Choosing the right default policy determines the baseline security posture. A “deny‑all” default forces you to explicitly whitelist services, reducing the attack surface.

# Set a default deny policy for incoming traffic
sudo ufw default deny incoming

# Allow all outbound traffic (most workloads need this)
sudo ufw default allow outgoing

• ✅ Confirm that ufw status verbose reports Default: deny (incoming), allow (outgoing).
• ✅ Document any exceptions before applying the policy to avoid accidental lock‑out.

Decision Point: Whitelist Essential Services

Only open ports that are strictly required for your workload. Common services include SSH, HTTP/HTTPS, and a database port if the DB is exposed externally.

# Example: allow SSH from a specific CIDR block
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp

# Allow HTTP/HTTPS for a public web server
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

• ✅ Use source‑address restrictions for privileged services (e.g., SSH).
• ✅ Prefer port numbers over service names to avoid ambiguity.
• ✅ Review the list with ufw status numbered after each addition.

Risk Assessment: Common Misconfigurations

Even a well‑intentioned rule set can create blind spots. Keep an eye on these pitfalls:

• Open “any” rules: ufw allow 3306 opens MySQL to the world. Restrict to trusted IPs.
• Duplicate rules: Multiple identical entries clutter the rule set and make audits harder.
• Forgotten IPv6 rules: If ufw enable activates IPv6, you must mirror IPv4 restrictions.
• Logging disabled: Without logging, you lose visibility into blocked attempts.

Operational Check: Enable and Tune Logging

UFW’s built‑in logging provides a low‑overhead view of denied traffic. Set the log level to “medium” to capture most events without overwhelming syslog.

# Enable logging at medium verbosity
sudo ufw logging medium

Verify that logs appear in /var/log/ufw.log (or via journalctl -u ufw) and rotate them with your existing logrotate configuration.

Deploying on a Cloud VPS

For teams that need a lightweight, cost‑effective compute layer, a Cloud VPS provides the perfect sandbox for firewall hardening. The minimal footprint (1 vCPU, 1 GB RAM) lets you iterate quickly, while the isolated network interface ensures that your UFW rules are the sole gatekeeper between the public internet and your applications.

Decision Point: IPv6 Considerations

If your VPS provider enables IPv6, you must replicate every IPv4 rule for IPv6. UFW treats them as separate entries.

# Allow SSH over IPv6 from the same CIDR (replace with IPv6 range)
sudo ufw allow from 2001:db8::/32 to any port 22 proto tcp

# Allow HTTP/HTTPS over IPv6
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

• ✅ Run ufw status verbose and verify both IPv4 and IPv6 sections.
• ✅ Document any IPv6 exclusions in your security policy.

Risk Mitigation: Rate Limiting and Bruteforce Protection

UFW can automatically throttle repeated connection attempts, a simple yet effective line of defense against credential‑stuffing.

# Apply rate limiting to SSH (default: 6 attempts per 30 seconds)
sudo ufw limit 22/tcp

Combine this with fail2ban for more granular bans if needed, but the built‑in limit is often sufficient for low‑traffic services.

Operational Check: Test from Inside and Outside

After the rule set is applied, perform a two‑phase verification:

1. Local validation: Use nc -zv 127.0.0.1 22 and nc -zv 127.0.0.1 80 to confirm allowed ports respond.
2. Remote validation: From a different machine, attempt connections to each allowed port and to a known‑blocked port (e.g., nc -zv your.vps.ip 3306). Expect a “Connection refused” or “Operation timed out” for blocked services.

Record the outcomes in a simple spreadsheet for audit trails.

Decision Point: Persistence Across Reboots

UFW automatically restores rules on boot, but it’s prudent to verify the service is enabled.

# Ensure ufw is enabled and will start on boot
sudo ufw enable
sudo systemctl is-enabled ufw

• ✅ If systemctl is-enabled ufw returns “enabled”, you’re good.
• ✅ Otherwise, run sudo systemctl enable ufw.

Risk Review: Emergency Access Procedure

Never lock yourself out. Keep a secondary admin account with a different SSH key or a console access method (e.g., provider’s VNC console) ready for emergencies.

• ✅ Store the secondary key in a secure password manager.
• ✅ Document the console URL and credentials in your run‑book.

Operational Check: Ongoing Monitoring

Integrate UFW logs into your central monitoring stack (e.g., ELK, Prometheus Node Exporter, or Netdata). Set alerts for spikes in denied connections, which often precede scanning or brute‑force attempts.

# Example: add a custom metric for denied packets (Prometheus node exporter)
cat >> /etc/node_exporter/textfile_collector/ufw_metrics.prom <<EOF
# HELP ufw_denied_total Number of packets denied by UFW
# TYPE ufw_denied_total counter
ufw_denied_total $(grep "DENIED" /var/log/ufw.log | wc -l)
EOF

Refresh the metric collector every minute and configure a Grafana alert for thresholds you define.

Checklist Summary

• Set default deny (incoming) and allow (outgoing) policies.
• Whitelist only required ports, restricting source IPs where possible.
• Enable medium‑level logging and verify log rotation.
• Duplicate IPv4 rules for IPv6 if applicable.
• Apply rate limiting to exposed services (e.g., SSH).
• Test connectivity locally and from an external host.
• Confirm UFW is enabled and set to start on boot.
• Maintain an emergency access plan (secondary key or console).
• Feed UFW logs into your monitoring stack and set alert thresholds.

Conclusion

Hardening a fresh Ubuntu VPS with a disciplined UFW checklist transforms a generic cloud instance into a resilient, auditable asset. By making each decision explicit, documenting risks, and embedding operational checks, you reduce the likelihood of accidental exposure and gain the visibility needed for proactive security management. Apply this checklist on every new server, and you’ll build a consistent, lock‑tight perimeter across your entire fleet.