A cloud firewall controls which network paths are allowed to reach or leave a cloud server. The safest default is to expose only the public services the workload actually needs, restrict administrative access, keep databases and internal services on private paths, and review both inbound and outbound rules as the architecture changes.
Raff Technologies workloads can combine host-level firewall policy with VPC private networking and the platform's current Security capabilities. A firewall reduces reachability, but it does not replace secure authentication, patching, application security, encryption, monitoring, or backups.
Cloud firewall best practices: quick answer
For a typical cloud VM or small application stack:
- deny unnecessary inbound traffic by default;
- allow public HTTP/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;
- review outbound traffic for sensitive or predictable workloads;
- apply equivalent policy to IPv4 and IPv6;
- use separate rules for different server roles;
- give temporary rules an owner and expiry;
- test allowed and denied paths after every meaningful firewall change.
| Traffic path | Safer default |
|---|---|
| Public web traffic | Allow TCP 80/443 only when required |
| SSH or RDP | Restrict to trusted IPs, VPN, gateway, or private path |
| Application runtime ports | Localhost or approved private sources |
| Database, cache, queue | Private network and approved sources only |
| Monitoring/admin dashboards | Private or strongly authenticated access |
| Outbound package/API access | Allow required destinations where practical |
| All other inbound traffic | Deny |
A useful rule is:
If a firewall rule has no clear service, source, owner, and reason to exist, it should not remain in production.
What is a cloud firewall?
A cloud firewall is a network control that filters traffic to or from cloud workloads according to rules such as source, destination, protocol, port, and direction.
A firewall can be enforced at more than one layer:
- provider or platform network boundary;
- virtual network or subnet boundary;
- operating-system firewall inside the VM;
- application gateway or reverse proxy;
- application authentication and authorization.
These layers solve related but different problems. A network firewall decides whether a connection can reach a service. The application still needs to decide whether the user or service is authorized to perform an action.
Start with traffic flows, not a generic port list
Before creating firewall rules, document the communication paths the application actually requires.
For example:
Internet ↓ HTTPS 443 Public web / reverse-proxy VM ↓ private application port Application VM ↓ private database port Database service
Then add management and operational paths:
Approved administrator ↓ restricted SSH or RDP Application / database VM Monitoring service ↓ approved metrics path Application / database VM
For each flow, record:
- source;
- destination;
- protocol;
- port;
- public or private path;
- purpose;
- owner;
- expected lifetime.
This is safer than copying a list of “common cloud ports” because every rule maps to a real dependency.
Use deny by default for inbound traffic
A deny-by-default inbound policy means connections are blocked unless a rule explicitly allows them.
This reduces attack surface because installed or accidentally listening services do not automatically become reachable from the internet.
A public Linux web VM might need:
| Service | Port | Source |
|---|---|---|
| HTTP | TCP 80 | Public internet, if used for redirect or certificate validation |
| HTTPS | TCP 443 | Public internet |
| SSH | TCP 22 | Approved admin source only |
| Application runtime | TCP 3000, 8000, 8080, or app-specific | Localhost or approved private source |
| Database | Engine-specific | No broad public access |
The exact ports depend on the workload. Do not open ports simply because an application documentation page lists them; confirm whether the port must be reachable publicly, privately, or only from localhost.
Inbound vs outbound firewall rules
Inbound firewall rules control connections initiated toward the VM. Outbound firewall rules control connections initiated by the VM toward another destination.
| Direction | Typical question | Example |
|---|---|---|
| Inbound | Who is allowed to reach this service? | Internet → HTTPS 443 |
| Inbound | Who can administer this VM? | Office/VPN → SSH 22 |
| Private inbound | Which application can reach the database? | App subnet → PostgreSQL 5432 |
| Outbound | Which services may this VM call? | App VM → payment/API endpoint |
| Outbound | Can this internal service reach the internet? | Worker → approved external dependencies |
Inbound policy is usually the first priority because public exposure is easy to understand and exploit. Outbound filtering becomes more valuable when a workload handles sensitive data, has predictable dependencies, or would create meaningful risk if compromised.
Restrict SSH and RDP separately from application traffic
Administrative services can change the system, so they deserve stricter controls than user-facing web traffic.
Prefer one or more of these patterns:
- trusted source IPs;
- VPN access;
- controlled gateway or bastion access;
- private-network administration;
- temporary, time-bounded firewall access.
Network restriction should be combined with identity controls such as:
- individual administrator accounts;
- SSH keys for Linux where appropriate;
- strong Windows credentials;
- least privilege;
- rapid offboarding;
- administrative logging.
Avoid leaving SSH or RDP open to the entire internet simply because credentials are strong. Reachability and authentication are separate security layers.
Read Private vs Public Admin Access for the architecture decision.
Keep databases and internal services private
Database authentication is necessary, but it should not be the only boundary.
Services that normally should not accept broad public traffic include:
- PostgreSQL and MySQL;
- Microsoft SQL Server;
- Valkey and other caches;
- message queues and brokers;
- search services;
- metrics endpoints;
- internal APIs;
- orchestration control planes;
- internal dashboards.
Allow the smallest approved source set, such as the application tier, a private subnet, or a controlled administrative path.
Private networking does not mean “trusted by default.” A VPC can still become overly permissive if every private host can reach every service. Apply least privilege inside the private network as well.
Use Private Networking in Cloud for the broader public/private traffic design.
Cloud firewall rules should follow server roles
Different server roles should not inherit one universal rule set.
| Role | Public ingress | Private ingress | Typical outbound |
|---|---|---|---|
| Public web/reverse proxy | HTTP/HTTPS | Admin, monitoring, backend | App dependencies, updates |
| Application VM | Usually none | Web tier, admin, monitoring | Database, cache, APIs |
| Database VM/service | None | Application tier, controlled admin | Backups, updates, monitoring as required |
| Worker VM | None | Queue/admin/monitoring as needed | Queue, database, storage, APIs |
| Bastion/gateway | Restricted admin protocol | Approved internal management | Limited management paths |
| Monitoring system | Usually none | Metrics/log paths | Notification or storage destinations |
Role-based rules are easier to review than one large collection of copied exceptions.
Review outbound firewall rules where the risk justifies it
Outbound restrictions can reduce the impact of:
- compromised applications;
- malicious dependencies;
- unexpected data transfer;
- lateral movement;
- misconfigured scripts;
- command-and-control traffic.
Not every small VM needs a complex egress allowlist. Overly strict outbound rules can also break package repositories, certificate renewal, DNS, time synchronization, APIs, object storage, email delivery, or monitoring.
Start with workloads that have narrow and predictable dependencies.
Examples include:
- a database host that should reach only updates, backups, DNS, and monitoring;
- a worker that should call one approved API;
- an internal service that should not initiate arbitrary internet connections;
- a production application with a known set of external services.
For external services whose IP addresses change frequently, do not build a brittle fixed-IP policy unless the service publishes stable ranges or another controlled egress mechanism is available.
Apply equivalent policy to IPv4 and IPv6
A common dual-stack mistake is protecting IPv4 while IPv6 remains broadly reachable.
Review both address families for:
- HTTP/HTTPS;
- SSH and RDP;
- database/cache ports;
- monitoring endpoints;
- administrative dashboards;
- outbound restrictions.
Do not assume a platform or operating-system firewall automatically mirrors every IPv4 rule to IPv6.
Read IPv4, IPv6, and Dual-Stack Networking before enabling dual-stack access in production.
Understand stateful firewall behavior
Many cloud and operating-system firewalls are stateful, meaning return traffic for an allowed connection is tracked and permitted automatically. Others may evaluate directions or interfaces differently.
Before designing complex rules, verify:
- whether the firewall is stateful;
- whether inbound and outbound policy are evaluated separately;
- what happens to established connections after a rule changes;
- whether NAT changes the apparent source or destination;
- whether health checks or monitoring require separate rules;
- whether IPv6 follows the same model.
Do not add broad “return traffic” rules unless the firewall model actually requires them.
Platform firewall vs OS firewall
A provider-level or platform firewall can reduce traffic before it reaches the VM. An operating-system firewall such as nftables, UFW, firewalld, or Windows Defender Firewall enforces policy inside the guest.
Using both can provide defense in depth, but duplicated rule sets can create operational confusion.
A practical ownership model is:
- platform/network policy for the broad exposure boundary;
- operating-system firewall for host-specific services and interfaces;
- application authentication for identity and authorization.
Document which layer owns each rule. If traffic fails, operators should know whether to inspect the network boundary, host firewall, service binding, reverse proxy, or application permissions first.
Managed firewall controls vs iptables or command-line rules
Some teams prefer provider-level controls because they do not want every exposure change to depend on editing iptables, nftables, UFW, or Windows Firewall manually.
That can reduce host-by-host drift, but it does not eliminate the need to understand the guest firewall. A service may still be reachable locally, bound to the wrong interface, or exposed through a different network path.
For important workloads, treat provider-level filtering and host-level configuration as complementary controls with clear ownership rather than assuming one automatically replaces the other.
Temporary firewall rules need an expiry
Temporary access is one of the most common ways a narrow rule becomes permanent exposure.
Every temporary rule should have:
- reason;
- requester;
- owner;
- creation time;
- expiry or removal event;
- affected workload.
Typical temporary cases include:
- migration access;
- vendor support;
- debugging;
- one-time data transfer;
- short-lived administrative work.
Remove the rule when the work ends instead of waiting for a future audit.
Test firewall changes from both allowed and denied paths
A firewall change can either expose a service or lock out an administrator.
Use a controlled change sequence:
- Record the intended traffic flow.
- Confirm an alternative access path or console exists before changing remote admin rules.
- Add the narrowest required rule.
- Test from an allowed source.
- Test from a disallowed source.
- Verify application health and monitoring.
- Remove obsolete or temporary rules.
- Record the result.
For production database and administrative changes, avoid changing several firewall layers at once unless the rollback sequence is clear.
Review firewall rules after architecture changes
Firewall policy can become stale when infrastructure changes even if nobody edits the firewall directly.
Review rules after:
- adding or removing servers;
- changing public IPs;
- enabling IPv6;
- moving a database to a separate service;
- introducing a VPC;
- replacing a reverse proxy;
- changing monitoring tools;
- retiring an administrator or vendor;
- migrating an application;
- exposing a new API or dashboard.
Look for:
- unused public ports;
- source ranges that are broader than necessary;
- old administrator IPs;
- rules pointing to retired systems;
- duplicate host and platform rules;
- temporary exceptions without owners.
Use Stale Infrastructure Cleanup when security policy is tied to servers or services being retired.
Firewall policy is only one part of cloud server security
A firewall cannot protect an application from every threat on an allowed port. If HTTPS 443 is public, the application behind 443 still needs secure authentication, authorization, input handling, patching, secrets management, logging, and recovery controls.
A production VM security baseline should also include:
- supported OS and package updates;
- secure SSH/RDP configuration;
- least-privilege users;
- protected secrets;
- TLS for public services;
- monitoring and alerting;
- backups and tested restore procedures;
- documented incident ownership.
Use Cloud Security Fundamentals for the broader security model and Cloud Snapshots vs Backups for recovery protection.
How this applies on Raff
For Raff workloads, the current architecture can use:
- Raff Cloud Servers for public or private application VMs;
- VPC for private service-to-service networking;
- Security for Raff's current platform security capabilities;
- Site-to-Site VPN when an approved private path between networks is required;
- Data Protection for snapshot and backup workflows after security or configuration changes.
A simple architecture can look like:
Internet ↓ only required public ports Public application / reverse-proxy VM ↓ private VPC path Application, database, and internal services
Do not depend on the public Load Balancer product page for this design while Raff's managed load-balancer availability is not currently confirmed as generally deployable. Traffic distribution can still be handled at the application architecture layer when required.
Raff VM public traffic currently uses a 3 Gbps connection with unmetered VM traffic and no VM egress fee. VPC traffic is private and unmetered. Network pricing does not change the security principle: private services should remain private even when traffic itself is inexpensive.