Firewall Best Practices for Cloud Servers

Introduction

Firewall best practices for cloud servers start with a simple principle: your server should accept only the traffic it genuinely needs. A cloud firewall is a rule-based security control that allows or denies network traffic by protocol, port, source, destination, and direction. On Raff, this matters because cloud servers are provisioned quickly, exposed to the internet immediately, and often run multiple services unless you design the network carefully.

For many teams, the firewall is treated as a one-time setup task: open ports 22, 80, and 443, then move on. That approach works only until the workload changes, a new service is exposed by mistake, or an old rule remains in place long after it is needed. In cloud environments, the pace of change is faster than in traditional infrastructure, so firewall rules must be intentional, minimal, and reviewed regularly.

This guide explains what a cloud firewall is, how firewall rules fit into a broader security model, and which practices actually reduce risk for internet-facing servers. You will learn how to apply least privilege, how to segment public and private services, how to think about inbound and outbound rules, how to avoid rule sprawl, and how Raff features such as VM firewall rules, private networking, and DDoS protection fit into a strong baseline.

What a Cloud Firewall Actually Does

A cloud firewall is not a complete security strategy by itself. It is a traffic gate. It decides which connections are allowed to reach your server and which are dropped before they become useful to an attacker. That makes it one of the most important controls for reducing attack surface, especially on public-facing VMs.

At a practical level, firewall rules typically evaluate a small set of attributes:

• Source IP
• Destination IP
• Protocol
• Source port
• Destination port
• Direction

Microsoft describes this as a stateful packet inspection model in Azure network security groups, while Google Cloud similarly emphasizes per-instance and network-level allow and deny control for VM traffic. These patterns are not unique to one provider. They reflect the standard way modern cloud firewalls work.

The key point is this: a firewall does not make an insecure application secure. It does, however, reduce the number of ways that insecure application can be reached.

Examples include:

• If your database should be reachable only from your application server, the firewall enforces that.
• If SSH should be reachable only from your office IP or VPN, the firewall enforces that.
• If your workload never sends traffic to arbitrary destinations, outbound rules can enforce that too.

Firewalls are about exposure, not trust

A common mistake is treating internal network traffic as trustworthy and internet traffic as untrustworthy. That mental model is too simple for cloud systems.

Once a single server is compromised, flat networks and broad internal allow rules make lateral movement much easier.

That is why modern guidance increasingly pushes toward Zero Trust thinking.

In practical terms, Zero Trust means:

• You do not assume a connection is safe just because it originates inside your environment.
• Access must always be explicitly allowed.
• Each service should communicate only with the components it actually needs.

For example:

• Your web server should not talk to every database.
• Your CI runner should not reach every production instance.
• Your bastion host should not become a universal pass-through box.

Why cloud environments need stricter rule hygiene

Cloud infrastructure is dynamic.

Servers are:

• Resized
• Rebuilt
• Replaced
• Cloned from images
• Created from automation

Teams also add new services quickly.

This speed is useful, but it creates a temptation to use broad firewall rules because they are easier in the moment.

The problem is that broad rules become permanent.

Examples include:

• An emergency SSH exception for 0.0.0.0/0 surviving for months
• A temporary admin port left open after a migration
• An internal service accidentally exposed publicly

Good firewall practice is therefore less about clever rule-writing and more about disciplined operational habits.

Core Principles of Good Firewall Design

Good firewall design is built on a few repeatable ideas. They are simple to explain, but teams often skip them when moving quickly.

Least privilege by default

Least privilege means allowing the smallest set of network access necessary for a workload to function.

Google Cloud’s firewall guidance explicitly recommends blocking all traffic by default and allowing only the specific protocols and ports you need.

This principle appears across cloud security frameworks because it is one of the most effective ways to reduce unnecessary exposure.

In practice, least privilege means:

• Only open ports that serve a real purpose
• Restrict source ranges wherever possible
• Keep management access narrower than application access
• Separate human access paths from service-to-service access
• Remove rules when the underlying need disappears

For example, a basic public web server often needs only:

• 80/tcp
• 443/tcp

from the internet.

It does not need public access to:

• MySQL on 3306
• Redis on 6379
• Internal app ports such as 3000, 8080, or 9000.

Deny by default

A deny-by-default posture means traffic is blocked unless there is an explicit rule allowing it.

This is safer than trying to enumerate every bad thing you want to block. The internet changes too quickly for blocklists alone to be sufficient.

Deny-by-default also keeps rules understandable. When someone audits the firewall, they can see exactly what is permitted rather than guessing what remains exposed.

Segment by role

Not every server belongs in the same trust zone.

Public web servers, private databases, CI runners, logging nodes, and admin systems serve different functions and should not all share identical rules.

Microsoft’s network security guidance recommends logical subnet segmentation and warns against broad allow rules across large address ranges.

The principle is simple:

Group systems by role and control traffic between those groups deliberately.

Example architecture

This pattern is easier to manage and safer than placing every VM on the public internet with slightly different open ports.

Inbound vs Outbound Rules: Both Matter

Many teams focus only on inbound filtering. That is understandable because inbound exposure is the most visible risk.

But outbound rules deserve more attention than they usually receive.

Inbound rules protect the surface

Inbound rules define who can reach your server.

Strong habits include:

• Publish only the services meant for public use
• Restrict administrative access to known IP ranges
• Prefer private networking for internal services
• Avoid opening ports “just in case”

If your workload is a static site or reverse proxy, the public rule set should be very small.

Outbound rules reduce blast radius

Outbound filtering becomes valuable when a compromised server should not be able to connect freely to arbitrary destinations.

Examples include:

• Preventing databases from initiating outbound connections
• Restricting services to only required APIs or update mirrors
• Preventing unexpected data exfiltration

Outbound rules add complexity, so they should be used where they create meaningful security improvements.

Common Firewall Mistakes That Create Risk

Many firewall incidents are not caused by sophisticated attackers. They happen because of operational shortcuts.

Allowing SSH from anywhere

Opening 22/tcp to the world is still common during initial setup. It is convenient, but it guarantees constant exposure to scanning and brute-force attempts.

A better pattern is to restrict SSH to:

• A fixed office IP
• A VPN range
• A bastion host
• A temporary maintenance IP that is removed immediately after use

If your IP changes often, a VPN or bastion design is usually cleaner than permanent open SSH access.

Exposing databases publicly

Databases rarely need direct internet access.

Safer alternatives include:

• Private networking
• Bastion access
• SSH tunneling
• Application-layer access

Public database ports create unnecessary attack surface.

Reusing rules across unrelated workloads

Copying one firewall configuration to every server leads to excessive exposure.

Different services have different needs:

• A CI runner
• A WordPress server
• A PostgreSQL node

should never share identical firewall rules.

Keeping temporary exceptions forever

Temporary rules often become permanent.

Examples include:

• Migration access rules
• Vendor troubleshooting rules
• Emergency debugging access

Every temporary rule should have an expiry or review date.

Ignoring logging and review

Firewall rules that are never reviewed become historical artifacts.

Logging helps identify:

• unused rules
• unexpected traffic
• misconfigured services

Routine audits keep the rule set healthy.

A Practical Decision Framework

You do not need enterprise-scale complexity to implement strong firewall discipline.

You need consistent decisions.

Comparison and Decision Framework

Best Practices You Can Apply Consistently

1. Start from a baseline template

Define role-based firewall templates:

• Public web server
• Private app server
• Database server
• Bastion host

Templates reduce mistakes.

2. Minimize broad CIDR ranges

Large IP ranges increase the chance of unintended access.

Always prefer narrow source ranges.

3. Separate public and private traffic

Public interfaces should serve public services.

Internal traffic should use private networking.

4. Treat management access differently

Administrative access (SSH, RDP, admin panels) should be more restricted than application traffic.

5. Enable useful logging

Log:

• internet-facing rules
• sensitive services
• troubleshooting sessions

Avoid logging everything unnecessarily.

6. Review rules regularly

Monthly or quarterly firewall audits help detect stale rules.

Ask:

1. Is this rule still required?
2. Can the source range be reduced?
3. Can this service move to private networking?

7. Keep rules aligned with architecture

If documentation says a service is private but the firewall exposes it publicly, the firewall configuration wins.

Always update documentation accordingly.

8. Remember the firewall is only one layer

A firewall complements:

• OS hardening
• Patch management
• SSH key authentication
• TLS encryption
• Application security

Security works best when layers reinforce each other.

Raff-Specific Context

Raff supports this firewall strategy with several platform features.

Raff includes:

• configurable VM firewall rules
• always-on DDoS protection
• private networking
• hourly billing
• NVMe SSD storage
• AMD EPYC CPUs

CPU-Optimized VMs start at $3.99/month, making it practical to split workloads across multiple smaller servers rather than running everything on one exposed instance.

A typical Raff architecture might look like this:

• Public VM running Nginx with ports 80 and 443
• SSH restricted to an admin IP or VPN
• Private database VM using Raff private networking
• DDoS protection enabled
• Monthly firewall rule review

This design significantly reduces exposure.

Conclusion

A strong cloud firewall strategy is not about creating complex rule sets. It is about reducing unnecessary exposure and maintaining clear, intentional policies.

The most effective practices are:

• least privilege
• deny by default
• network segmentation
• restricted admin access
• regular rule review

For many teams, the biggest improvement comes from simply closing unused ports and moving internal services onto private networks.

With Raff’s VM firewall rules, private networking, and built-in DDoS protection, you can implement these practices without complex infrastructure or high cost.

From here, the natural next reads are:

• understanding virtual private clouds
• cloud backup strategies
• SSH hardening tutorials for Linux servers