- Know your SSH port.
- Keep an administrative session open.
- Have console access available before changes.
Write a short access plan
List the services intended for the internet. A web application commonly needs HTTPS, with HTTP where redirects or certificate validation require it. A database normally needs access from application hosts, not every public address.
Name each rule after its purpose. A short list of understandable exceptions is easier to maintain than a large unexplained collection of ports.
Allow management before enforcing a default
For an Ubuntu host using UFW and the standard OpenSSH profile, allow management before enabling enforcement. If SSH uses a custom port, allow that actual port first. Review the rules and keep the existing connection open.
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw status verboseCheck IPv4 and IPv6
An IPv4 restriction does not necessarily cover IPv6. If your application listens on both, review both paths. A public AAAA record can expose an IPv6 listener even when the IPv4 service appears restricted.
Bind internal listeners to their intended interfaces. A firewall adds a boundary; it does not replace authentication or software updates.
Keep the control-panel rules and guest rules aligned
Use the server’s Network section to review the inbound policy. Select protocol, port and source range, make one change and test reachability. Repeat the review after cloning or reinstalling a machine.
The optional enhanced DDoS service covers eligible network-layer attacks. It does not replace application rate limits, authentication or the operating-system firewall.
Recover from a lockout deliberately
Use the console to inspect the firewall and SSH service. Restore the last known-good access rule instead of removing every protection indefinitely. Verify a fresh external connection, remove temporary broad rules and record why the lockout happened.