How to Configure a Cloud VM Firewall Safely

A new VM can be online in minutes. An exposed admin port can be found by automated scanners just as quickly. When you configure a cloud VM firewall, the goal is not to block everything blindly. It is to allow only the traffic your business needs, from the sources that should have access, while keeping management access recoverable.

For a small business site, agency client environment, or application server, firewall setup is one of the highest-value tasks you can complete before going live. It reduces avoidable risk without adding expensive tools or enterprise-level complexity.

Start With the Services Your VM Actually Needs

Firewall rules should follow the workload, not a generic checklist. A WordPress server generally needs public web traffic on ports 80 and 443, plus restricted administration. A database VM should usually accept connections only from an application server on a private network. A staging server may need no public access at all.

Before creating a rule, write down four details: the service, the port and protocol, who needs access, and whether that traffic should arrive through the public internet or a private network. This keeps rule sets lean and makes them easier to audit later.

Here is a practical baseline for a public website VM:

Do not open a port because a tutorial listed it. If a service is not installed, not in use, or only needed internally, leave it closed. Ports such as 21, 23, 3306, 5432, 6379, 27017, and control panels are frequent targets when exposed publicly.

Use Two Layers When Available

Most cloud environments provide a network firewall in the VM dashboard, often called a security group, cloud firewall, or network access rule. Your operating system can also run its own firewall, such as UFW, firewalld, or nftables. Using both is a sensible approach because each layer protects against a different type of mistake.

The cloud firewall acts as the outer gate. It can stop unwanted traffic before it reaches the virtual machine. The host firewall provides a second gate inside the server, where you can apply rules tied to local services and interfaces.

For a straightforward deployment, configure matching inbound restrictions in both places. Keep the cloud layer simple: permit only required public ports and trusted administrative addresses. Then use the host firewall for the same core controls and any more specific local rules.

There is a trade-off. Two layers mean two places to troubleshoot if a service stops responding. That is manageable when rules are named clearly and documented. It becomes painful only when permissions are added randomly over time.

Configure Cloud VM Firewall Rules Before Opening the App

Create the network rules before you announce the IP address, connect a domain, or install a public-facing application. Start with a default-deny inbound posture: traffic is blocked unless a rule explicitly permits it.

Outbound traffic is different. Most web and application servers need outbound DNS, package updates, certificate renewal, APIs, email delivery services, backups, or object storage. Allowing outbound traffic by default is common for smaller workloads. For regulated systems or tightly controlled production networks, restrict egress after you have identified every legitimate dependency.

When adding inbound rules, follow these principles:

• Allow TCP 80 and 443 from the public internet only if the VM serves a public website or API.
• Limit SSH, RDP, control panels, and monitoring dashboards to known IP addresses or a private VPN range.
• Keep databases, caches, queues, and internal APIs on private addresses whenever possible.
• Create separate rules for production, staging, and development instead of reusing a broad rule set.

A /32 CIDR block represents one IPv4 address. For example, allowing 203.0.113.25/32 on port 22 grants SSH access only to that address. If your home internet provider changes your IP frequently, a VPN with a fixed exit IP, a bastion host, or a cloud console access method is safer than opening SSH to the entire internet.

Set Up the Linux Host Firewall Without Locking Yourself Out

On Ubuntu and Debian, UFW is usually the fastest option. On Rocky Linux, AlmaLinux, CentOS Stream, and Fedora, firewalld is common. The commands differ, but the order of operations matters more than the tool.

First, keep your current SSH session open. Then open a second terminal session and confirm that you can still connect after each change. Never enable a deny-by-default firewall remotely until you have explicitly allowed your own management access.

For a typical Ubuntu web VM, the sequence looks like this:

bash sudo ufw allow from YOUR.PUBLIC.IP.ADDRESS to any port 22 proto tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw enable sudo ufw status numbered

Replace YOUR.PUBLIC.IP.ADDRESS with your actual public IP. If SSH uses a custom port, allow that port instead of 22. A custom port can reduce background noise from automated scans, but it is not a substitute for key-based authentication, restricted source IPs, and disabled password logins.

For firewalld, first identify the active zone and network interface. Then permit only required services or ports, make the configuration permanent, and reload it. Avoid copying commands from a different Linux distribution without checking the active firewall service. Running UFW and firewalld together can create confusing results.

Protect Administration First

Public web ports are expected. Public administration ports are where many avoidable incidents begin. SSH and RDP should be treated differently from visitor traffic because they provide direct control of the server.

For Linux VMs, use SSH keys rather than passwords. Disable root login over SSH when your operating process supports a named sudo user. Limit the allowed SSH source to your office, VPN, or management network. If several team members need access, give each person a separate key and remove keys immediately when responsibilities change.

For Windows VMs, restrict RDP port 3389 to trusted IP addresses or access it through a VPN or bastion service. Do not leave RDP open to 0.0.0.0/0 simply because a contractor needs access for an hour. Add a temporary narrow rule, confirm the work is complete, then remove it.

IPv6 deserves the same attention. If your VM has a public IPv6 address and you only restrict IPv4, you may have left the same service exposed over IPv6. Either define equivalent IPv6 rules or disable public IPv6 where it is not required.

Test From the Outside, Not Just From the Server

A firewall can look correct in a dashboard while the site remains unreachable due to the wrong network interface, an application binding issue, or a host-level rule. Test from an external connection, such as a mobile hotspot or a device outside your office network.

Confirm that HTTPS loads, HTTP redirects correctly if used, and SSH or RDP works only from an approved address. Also test the negative case: a non-approved connection should fail. If a database is meant to be private, verify that it cannot be reached from the public internet.

When troubleshooting, work from the outside inward. Check the cloud firewall first, then the host firewall, then confirm the service is listening on the correct port and interface. A web server bound only to 127.0.0.1 will not be public even if port 443 is open. Conversely, a service listening on all interfaces is not safe if the firewall rule is too broad.

Keep Rules Clean as Your Business Grows

Firewall configurations tend to become messy after migrations, urgent fixes, and new team members. Review them every quarter and whenever you deploy a new service. Remove temporary access rules, old office IPs, unused ports, and permissions for retired servers.

Use meaningful descriptions such as “Production WordPress HTTPS” or “Agency VPN SSH access.” A rule named “test2” may save thirty seconds today and cost an hour during an outage later.

Centralized infrastructure makes this operational work easier because domains, hosting, cloud VMs, storage, and business services are easier to track from one place. ACMMAX customers can use that visibility to keep a clearer separation between public websites, private applications, and administrative access.

A good firewall is not the one with the most rules. It is the one that permits exactly what your workload needs, gives your team reliable access, and leaves everything else outside the door.