Cloud Firewall Best Practices: Inbound, Outbound, and Private Traffic

A cloud firewall controls which network paths are allowed to reach or leave a server.

The strongest default is simple: expose only the public entry points the workload needs, restrict administrative access, keep databases and internal services on private paths, and review both inbound and outbound rules as the architecture changes.

A firewall reduces reachability. It does not replace secure authentication, patching, application security, encryption, monitoring, or backups.

Cloud firewall best practices: quick answer

For a typical cloud application:

• allow public HTTP and HTTPS only when the workload serves public users
• restrict SSH and RDP to approved administrative paths
• keep databases, caches, queues, metrics, and internal APIs off the public internet
• deny other inbound traffic by default
• review outbound access where a compromised server could reach sensitive systems or exfiltrate data
• apply equivalent policy to IPv4 and IPv6
• document temporary rules with an owner and expiry

A useful rule is:

If a rule has no clear service, source, owner, and review date, it should not remain in production.

Begin with traffic flows, not port lists

Before writing rules, document the expected communication paths.

For example:

Users
  ↓ HTTPS
Public load balancer or reverse proxy
  ↓ private application port
Application VM
  ↓ private database port
Database VM

Then add administrative and operational paths:

Approved administrators
  ↓ restricted SSH or RDP
Application and database VMs

Monitoring system
  ↓ protected metrics endpoints
Application and database VMs

This approach is safer than copying a generic port list because it connects each rule to an actual dependency.

For every flow, record:

• source
• destination
• protocol and port
• public or private path
• purpose
• owner
• expected lifetime

Use deny by default for inbound traffic

A deny-by-default policy blocks inbound traffic unless a rule explicitly allows it.

This reduces the attack surface because unused services are unreachable even if they are installed or accidentally listening.

A public web VM might need:

Do not open development ports, database ports, or dashboards “temporarily” without an owner and removal plan.

Treat administrative access separately

SSH, RDP, control panels, hypervisor consoles, and database administration paths can change the system. They deserve stricter rules than user-facing traffic.

Preferred options include:

• a trusted source IP
• VPN access
• a bastion or controlled gateway
• private-network administration
• short-lived firewall access

Network restriction should be combined with strong identity controls:

• individual accounts
• SSH keys for Linux where appropriate
• strong Windows credentials and supported MFA or gateway controls
• least privilege
• rapid offboarding
• logging

Read Private vs Public Admin Access for the architecture trade-off.

Keep databases and internal services private

Database authentication is necessary, but it should not be the only boundary.

Services that usually should not accept broad public traffic include:

• PostgreSQL and MySQL
• Microsoft SQL Server
• Redis and other caches
• MongoDB and search services
• message queues
• metrics endpoints
• internal APIs
• container orchestration control planes

Allow the smallest approved source set, such as an application subnet, a named VM role, or a controlled admin path.

Private networking reduces public exposure, but private networks can still be too permissive. Apply least-privilege firewall policy inside the private network.

Read Private Networking in Cloud for public and private traffic design.

Review outbound traffic as well

Inbound filtering reduces who can reach a server. Outbound filtering limits where the server can connect.

Outbound controls can reduce the impact of:

• compromised applications
• malicious dependencies
• unexpected data transfer
• lateral movement
• misconfigured scripts

Not every small workload needs a complex egress policy. Start with systems that handle sensitive data or have narrow, predictable dependencies.

Examples include:

• a database server that needs only DNS, updates, backups, and monitoring
• a worker that should call one approved API
• an internal service that should not reach the public internet
• a production application that should reach specific storage, email, and payment endpoints

Be careful with domain-based dependencies because IP addresses may change. Use documented provider ranges, proxies, service endpoints, or monitoring where appropriate rather than creating brittle rules.

Apply policy to IPv4 and IPv6

A common dual-stack mistake is protecting IPv4 while IPv6 remains broadly reachable.

Review both address families for:

• public web ports
• SSH and RDP
• database and cache ports
• monitoring endpoints
• outbound rules

Do not assume an operating-system or platform firewall automatically mirrors IPv4 rules to IPv6.

Read IPv4, IPv6, and Dual-Stack Networking for the broader deployment path.

Understand stateful firewall behavior

Many cloud firewalls are stateful: return traffic for an allowed connection is automatically permitted.

This simplifies common client-server flows, but behavior varies by platform and rule type.

Before designing complex policy, confirm:

• whether rules are stateful
• whether inbound and outbound policies are evaluated separately
• how established connections behave after a rule change
• whether network address translation is involved
• whether health checks require separate rules

Do not add broad return-path rules without understanding the firewall model.

Separate rules by server role

Different workloads should not inherit one universal rule set.

Role-based policy is easier to review than one large collection of copied exceptions.

Use platform and operating-system firewalls deliberately

A platform firewall filters traffic before or around the VM. An operating-system firewall filters traffic inside the guest.

Using both can provide defense in depth, but duplicated rules can also create troubleshooting confusion.

A practical model is:

• platform firewall for the broad network boundary
• operating-system firewall for host-specific enforcement and local interfaces
• application authentication for identity and authorization

Document which layer owns each rule. When traffic fails, operators should know where to inspect first.

Give temporary rules an expiry

Temporary rules are a common source of long-term exposure.

Every temporary rule should include:

• reason
• requester
• owner
• creation time
• expiry or removal event
• affected workload

Examples include migration access, vendor support, debugging, or one-time data transfer.

Review temporary rules immediately after the work ends rather than waiting for the next quarterly audit.

Log and review meaningful changes

Useful records include:

• firewall rule creation, modification, and deletion
• repeated attempts against administrative ports
• blocked database or cache traffic
• unusual outbound destinations
• rules with no observed use

Logging every packet may create too much noise. Prioritize high-impact paths and configuration changes.

Review frequency should match environment change rate. Fast-moving production environments may need monthly or event-driven reviews; stable environments may use a quarterly review plus checks after major changes.

Test firewall changes safely

Firewall changes can expose services or lock administrators out.

Use a simple change process:

1. Record the intended traffic flow.
2. Confirm an alternative access path or console is available.
3. Add the narrow rule.
4. Test from an allowed source.
5. Test from a disallowed source.
6. Verify application health and monitoring.
7. Remove the old or temporary rule.
8. Record the result.

For production database and administrative changes, avoid editing several layers simultaneously unless the rollback plan is clear.

How this applies on Raff

Raff provides Security, Private Cloud Networks, Linux VMs, and Load Balancers as building blocks for controlled public and private traffic.

A practical Raff pattern is:

Internet
  ↓ TCP 80/443
Raff Load Balancer or public application VM
  ↓ Raff Private Cloud Network
Application and database services

Use the current dashboard and product documentation to confirm firewall scope, stateful behavior, supported protocols, IPv6 handling, and private-network integration before relying on a rule design.

Common mistakes

Opening SSH or RDP broadly

Restrict management paths even when credentials are strong.

Exposing a database because authentication exists

Use both network restriction and database authentication.

Protecting only IPv4

Apply equivalent policy to every enabled address family.

Ignoring outbound access

Sensitive and predictable workloads may benefit from egress restrictions and monitoring.

Copying the same rules to every server

Match policy to workload role and dependencies.

Leaving temporary access indefinitely

Assign an owner and expiry at creation time.

Using a firewall instead of patching

Reachability control and vulnerability remediation are separate responsibilities.

Conclusion

Cloud firewall policy should describe the traffic the system needs and deny the rest.

Keep the public surface small, restrict administrative access, place databases and internal services on private paths, review outbound dependencies, protect both IPv4 and IPv6, and treat temporary rules as expiring changes.

The best firewall configuration is not the largest rule set. It is the smallest understandable policy that supports the application safely.

Sources

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
• Raff Security
• Raff Private Cloud Networks