Inbound firewall rules control connections trying to reach a cloud server. Outbound rules control connections leaving it. A strong cloud firewall policy starts with the smallest required exposure, scopes administrative and internal services to trusted sources, documents why every rule exists, and verifies the effective policy from outside the server.
For workloads on Raff Technologies, treat firewall policy as one layer of the security model—not as a substitute for SSH/RDP hardening, application authentication, patching, private networking, or monitoring. This guide explains the architecture and review process without assuming that every firewall product evaluates rules in exactly the same way.
Practical rule: public web traffic may need broad access to 80/443. Administrative ports, databases, caches, queues, dashboards, and internal APIs usually should not.
Cloud firewall rules at a glance
| Question | Safer default |
|---|---|
| What should be publicly reachable? | Only services intended for public users |
| SSH/RDP source | Trusted IP range, VPN/private path, or another controlled admin path |
| Database/cache source | Application/private network only |
| Inbound policy | Explicitly allow required traffic; deny unnecessary exposure |
| Outbound policy | Start from workload needs; restrict sensitive roles where the benefit justifies operational complexity |
| Rule ownership | Named service/owner and reason |
| Rule lifetime | Review and remove when the dependency disappears |
| Verification | Test from the network path users or administrators actually use |
The goal is not the largest ruleset. It is a policy your team can explain.
What is a cloud firewall rule?
A firewall rule describes network traffic that should be allowed or denied according to properties such as:
- direction;
- source and destination;
- protocol;
- port or port range;
- network/interface context;
- connection state, depending on implementation.
A typical inbound requirement might be expressed as:
Allow TCP 443 Source: public internet Reason: customer HTTPS traffic
An administrative rule should be narrower:
Allow TCP 22 Source: approved admin network Reason: Linux administration
Do not copy syntax or rule-order assumptions from one firewall product into another. Cloud firewalls, Linux nftables/iptables, UFW, Windows Defender Firewall, security groups, and network ACLs can have different evaluation and state models. Verify the implementation you actually use.
Inbound vs outbound firewall rules
Inbound rules control traffic attempting to enter a server or protected network boundary.
Examples:
- browser → HTTPS service;
- administrator → SSH/RDP;
- application server → database;
- monitoring system → metrics endpoint.
Outbound rules control traffic initiated toward another destination.
Examples:
- application → external API;
- server → package repository;
- database → backup destination;
- CI runner → source/package registry.
Return traffic for an established connection may be handled automatically by a stateful firewall. Stateless systems require a different rule design. Do not assume statefulness from the word “cloud firewall”; confirm the product behavior.
Stateful vs stateless firewalls
A stateful firewall tracks connection state. When an allowed connection is established, related return traffic can be recognized as part of that connection.
A stateless firewall evaluates packets without relying on the same connection-tracking model.
This matters because a rule such as “allow outbound HTTPS” can behave differently depending on the firewall architecture and where the rule is enforced.
The important operational lesson is:
Design from the documented behavior of the firewall you use, not from a generic diagram.
The same applies to rule ordering. Some systems use ordered rules, some use priorities, some combine allow/deny semantics differently, and some security-group-style models are not “first match wins.”
Least privilege for firewall rules
Least privilege means granting only the network reachability required for a workload to function.
For firewall policy, apply four constraints:
- Service: Which process needs to be reachable?
- Port/protocol: What exact network path does it use?
- Source: Which users, servers, networks, or services need access?
- Lifetime: How long should the rule exist?
For example, this is broad:
TCP 5432 from 0.0.0.0/0
This is narrower:
TCP 5432 from application private subnet
The second rule does not make PostgreSQL secure by itself. Database authentication, TLS where required, patching, roles, and application security still matter. It simply removes unnecessary network reachability.
Firewall rule best practices
Keep public exposure intentional
Public web servers commonly need HTTP/HTTPS. That does not mean their database, cache, application debug port, monitoring endpoint, or admin dashboard should also be public.
Before opening a port, record:
- service name;
- owner;
- source that needs access;
- business/technical reason;
- whether a private path can be used instead;
- review or expiry condition.
Restrict administrative access
SSH and RDP are management surfaces. Prefer a trusted source range, VPN/private-access model, bastion, or another controlled administrative path when the environment justifies it.
Changing SSH from port 22 to another port may reduce background scanning noise, but it is not a substitute for strong authentication and source restriction.
Use Bastion Host vs VPN vs Public SSH when choosing the administration model.
Keep databases and caches private where practical
Typical internal services include:
| Service | Common port | Preferred exposure |
|---|---|---|
| PostgreSQL | 5432 | Application/private sources only |
| MySQL | 3306 | Application/private sources only |
| Redis/Valkey | 6379 | Application/private sources only |
| Internal API | App-specific | Approved service/private sources |
| Metrics endpoint | App-specific | Monitoring sources only |
| SSH | 22 | Controlled admin sources |
| RDP | 3389 | Controlled admin sources |
| HTTP/HTTPS | 80/443 | Public only when the service is intentionally public |
These are common ports, not a universal template. Verify the actual service configuration.
Avoid oversized trusted CIDRs
A broad CIDR can accidentally grant access to far more systems than intended.
If one subnet needs access, scope to that subnet rather than a much larger private range merely because it is convenient. Document why the range exists so future operators can safely narrow or remove it.
Remove temporary rules
Temporary migrations, debugging sessions, vendor access, tests, and incident-response work often create temporary network exceptions.
Every temporary rule should have:
- an owner;
- a reason;
- an expiry or review point;
- a cleanup step.
Without lifecycle ownership, temporary access becomes permanent exposure.
A practical inbound policy by server role
| Server role | Public inbound | Restricted inbound |
|---|---|---|
| Public web/app | 80/443 as required | SSH/RDP from admin path |
| Database | Usually none | DB port from application/private path; admin from controlled path |
| Worker | Usually none | Admin/monitoring paths only |
| Monitoring server | Only if product requires it | Admin and monitored-source paths |
| Bastion | Admin entry port from trusted sources | Private access to approved targets |
| CI runner | Usually none | Admin access only when required |
A role-based policy is easier to review than a long list of ports with no architecture behind it.
Outbound firewall rules: when are they useful?
Outbound restrictions can reduce the destinations a compromised or misconfigured workload can reach, but they also add maintenance cost.
They are most useful when:
- a sensitive workload has a small, predictable set of dependencies;
- compliance or customer requirements demand egress controls;
- a database or internal service has little reason to reach the public internet;
- a deployment environment needs a deliberately constrained network path;
- exfiltration and command-and-control risk justify tighter egress policy.
They can be harder to operate when applications depend on large or frequently changing SaaS endpoints, CDNs, package repositories, or third-party APIs.
Do not build an outbound allowlist you cannot maintain. A stale security rule that repeatedly gets bypassed during incidents is not a strong control.
Do not use domain names as if they were static IP policy
A rule such as “allow only npm, Docker Hub, and GitHub” sounds simple but can be difficult at the network firewall layer because services may use changing IP ranges, CDNs, redirects, mirrors, and multiple domains.
Before enforcing destination allowlists, understand whether the firewall supports:
- IP/CIDR destinations;
- service tags or provider-managed lists;
- FQDN/domain-aware policy;
- dynamic updates;
- logging for denied egress.
Otherwise, maintenance can become fragile.
Private networking and firewall rules solve different problems
A private network reduces unnecessary internet exposure. A firewall decides which reachable systems may communicate.
A common multi-VM design is:
Internet ↓ Public application endpoint ↓ private network Application VM ↓ private network Database / cache / worker
The database can remain off the public internet while still accepting traffic from the application tier.
Use Raff VPC for supported private connectivity between Raff resources. Private networking should still be paired with appropriate authentication, host/service configuration, and network policy.
Cloud firewall vs host firewall
A network-level firewall and a host firewall can provide complementary boundaries.
Network or cloud firewall
Useful for:
- controlling traffic before it reaches the guest OS;
- reducing public exposure;
- applying infrastructure-level source/port policy;
- creating a policy boundary separate from the application.
Host firewall
Linux UFW/nftables/iptables or Windows Defender Firewall can provide guest-level controls such as:
- interface-specific policy;
- local service exposure;
- OS-managed rule automation;
- application or host-specific restrictions supported by that firewall.
Do not assume the two layers must contain identical rule syntax or features. Define the intended effective policy, then verify the combined result.
Avoid firewall lockouts
Firewall changes can remove your own administrative path.
Before changing production access:
- Confirm console or recovery access.
- Identify the current admin source IP/network.
- Add and verify the new allow path before removing the old one.
- Keep an existing administrative session open during the change where appropriate.
- Test from a second session.
- Roll back immediately if the expected path fails.
Do not disable the host firewall on a production system simply to test another layer unless you have an approved maintenance procedure and understand the exposure created by doing so.
Verify the effective firewall policy
Configuration is not evidence until the intended network path has been tested.
Useful checks include:
# Test a specific TCP port from an authorized client nc -zv server.example.com 443 # Scan selected expected ports from an external test system nmap -sV -p 22,80,443 server.example.com
A full port scan can also be useful when authorized and appropriate, but avoid scanning systems you do not own or have permission to test.
Verify both positive and negative cases:
- public HTTPS is reachable;
- SSH works from the approved admin path;
- SSH is not reachable from an unapproved source where restriction is intended;
- database ports are not publicly reachable;
- private application-to-database traffic works;
- monitoring reaches only the intended endpoint.
Test from the actual source networks. A localhost check does not prove public or private firewall behavior.
Logging and monitoring make firewall policy operable
Where supported, firewall logs can help answer:
- Which rules are being hit?
- What traffic is being denied?
- Is a temporary rule still used?
- Are repeated scans targeting an exposed service?
- Did a deployment introduce a new outbound dependency?
Do not enable unlimited verbose logging without a retention plan. High-volume deny logs can become expensive and noisy.
Connect firewall review to your broader Application Observability for Small Teams and monitoring process.
Build a firewall rule lifecycle
Treat network rules as maintained infrastructure:
REQUEST ↓ Identify service, source, port, owner ↓ REVIEW ↓ Confirm private/restricted path and least privilege ↓ APPLY ↓ VERIFY positive + negative cases ↓ MONITOR ↓ REVIEW / EXPIRE ↓ REMOVE when no longer required
A useful rule record contains:
| Field | Example |
|---|---|
| Service | Production web |
| Direction | Inbound |
| Protocol/port | TCP 443 |
| Source | Public |
| Owner | Web platform |
| Reason | Customer HTTPS |
| Added | Change/ticket reference |
| Review | Recurring or service retirement |
The record can live in infrastructure-as-code, a change system, or another controlled source. The important part is that another engineer can understand the rule later.
Firewall review checklist
Review production policies regularly and after architecture changes.
- Every public port maps to an active service.
- SSH/RDP is restricted where practical.
- Databases and caches are not unnecessarily public.
- CIDR ranges are no broader than required.
- Temporary/vendor rules have owners and expiry conditions.
- Old environments and services no longer have rules.
- IPv4 and IPv6 exposure are both reviewed where applicable.
- Private-network rules still follow least privilege.
- Outbound restrictions match current dependencies.
- Positive and negative connectivity tests pass.
- Recovery access is known before high-risk changes.
How this applies on Raff
For a Raff deployment, start with the architecture rather than assuming a particular firewall behavior.
Use Raff VM or Windows VM for the workload, Raff VPC for supported private resource-to-resource connectivity, and review the current Raff Security surface for infrastructure security capabilities available to the resource you are deploying.
A practical pattern is:
Internet ↓ only required public services Raff VM / Windows VM ↓ Raff VPC where applicable Private application, database, worker, or internal service
Inside the guest OS, keep the host firewall and service listeners aligned with the intended architecture. A service bound to every interface can still be a configuration risk even when another network layer currently blocks it.
Use the live product pages for current firewall/security capabilities instead of relying on old assumptions about default open ports, rule statefulness, security-group features, or enforcement location.
