Real-world examples of examples of setting up firewall rules

Why start with real examples of setting up firewall rules

Firewall documentation often starts with definitions and theory. That’s backwards. Most teams learn faster by looking at real examples of setting up firewall rules, then mapping those patterns to their own environment.

In 2024–2025, the pattern is clear in incident reports from organizations like CISA and NIST: attackers are still winning through the same doors—exposed remote desktop, overly permissive outbound rules, and flat internal networks. The best examples of firewall rules directly address those doors.

Below, we walk through practical scenarios:

• Home office and small office
• Corporate networks with remote workers
• Public web applications
• Cloud workloads (AWS/Azure/GCP)
• Zero-trust style internal segmentation

Each scenario gives examples of examples of setting up firewall rules you can adapt, along with the reasoning behind each rule.

Home office and small office: simple, opinionated examples of firewall rules

Let’s start with something almost everyone can relate to: a small router/firewall at home or in a tiny office.

Example of a locked-down inbound policy

For most home and small office setups, you should not expose any inbound services from the internet. A realistic example of a baseline inbound policy:

• Default inbound policy: deny all from WAN to LAN
• No port forwarding enabled by default
• Remote administration disabled from the internet

In plain language: nothing on the internet can start a conversation with your internal devices. You only allow traffic that your devices initiate out to the internet.

Where people get into trouble is when they add exceptions without a plan. Here are real examples of bad ideas:

• Forwarding TCP 3389 (RDP) from WAN directly to a Windows desktop
• Exposing a NAS web admin interface (often on port 5000/5001) to the world

These are exactly the kinds of misconfigurations that show up in CISA alerts and ransomware case studies.

Example of safe outbound rules for a small network

Most home routers ship with “allow any outbound” rules. That’s convenient, but noisy from a security perspective. A more controlled example of setting up firewall rules for outbound traffic might:

• Allow outbound HTTP/HTTPS (80, 443) from LAN to internet
• Allow outbound DNS (53) only to your chosen DNS resolver
• Block outbound SMTP (25) from user devices to the internet, except from the mail server (if you run one)

This pattern stops malware from easily turning your laptop into a spam relay or beaconing out on unusual ports. It’s one of the best examples of a low-effort, high-impact improvement that even non-experts can implement.

Small business: examples of setting up firewall rules for remote work

Now imagine a 50-person company with a single office and several remote workers. They host an internal file server and an internal HR web app. They want staff to connect securely from home.

Example of VPN-focused inbound rules

Instead of exposing RDP or SMB to the internet, a safer example of configuration would:

• Inbound from WAN: allow only VPN protocol traffic to the firewall (for example, UDP 1194 for OpenVPN, or UDP 500/4500 for IPsec)
• Deny all other inbound ports by default

Once users connect via VPN, they appear as part of a restricted “VPN network” or VLAN. Then you apply internal firewall rules between that VPN network and your core LAN.

Examples include segmented access from VPN

Here are real examples of how to segment remote access:

• Allow VPN network to access file server over SMB (TCP 445) and HTTPS (443) only
• Allow VPN network to access the HR web app over HTTPS (443) only
• Block VPN network from accessing internal admin interfaces (switches, firewall management, hypervisors) except from a dedicated admin subnet

This gives you clear, auditable examples of setting up firewall rules that match business intent: employees can reach what they need, but they can’t roam freely across everything.

Public web server: examples of exposing services safely

Now let’s talk about a classic scenario: hosting a public website and API.

Example of a DMZ-style setup

Assume you have:

• A public web server in a DMZ network
• A database server in an internal network
• A firewall between the internet and the DMZ
• A firewall (or internal rules) between the DMZ and internal network

A realistic example of setting up firewall rules here:

Internet → DMZ web server

• Allow TCP 80 (HTTP) and 443 (HTTPS) from anywhere on the internet to the web server’s public IP
• Deny all other inbound ports to that web server

DMZ web server → internal database

• Allow TCP 5432 (PostgreSQL) or 3306 (MySQL), only from the web server’s IP to the database server’s IP
• Deny all other DMZ-to-internal connections by default

Internal admin access → DMZ

• Allow SSH (22) or RDP (3389) to the web server only from a dedicated admin subnet or jump host

These are some of the best examples of least-privilege firewall rules: every rule has a specific source, destination, and purpose. No “any to any” shortcuts.

For more formal guidance on segmentation and least privilege, NIST’s publications on network security architecture are worth reading: NIST SP 800-125 (search for virtualization and network security) is a good starting point.

Cloud workloads: 2024–2025 examples of firewall rules in AWS, Azure, and GCP

Cloud platforms changed the tooling, but not the fundamentals. Security groups, network security groups, and VPC firewalls are just distributed versions of the same ideas.

Example of a locked-down AWS security group for an application server

Consider an EC2 instance running an API behind a load balancer. A realistic example of a security group in 2024–2025 would:

• Inbound: allow TCP 443 only from the load balancer’s security group
• Inbound: allow SSH (22) only from a specific admin IP range or a bastion host security group
• Outbound: allow HTTPS (443) to the internet for OS and application updates
• Outbound: allow database port to the RDS instance’s security group only

This pattern prevents the classic misconfiguration where developers expose SSH to the entire internet or leave database ports wide open. Many cloud breach reports, including those summarized by organizations like ENISA, still trace back to exactly those mistakes.

Examples include containerized workloads

If you’re running Kubernetes, you get another layer of firewall-like control with network policies. Real examples of setting up firewall rules at this layer might include:

• Only allowing front-end pods to talk to back-end pods on a specific port
• Blocking direct pod-to-pod access across namespaces, except for a logging or metrics namespace

These examples of internal rules complement your cloud provider’s perimeter firewall, giving you defense in depth.

Internal segmentation: examples of zero-trust style firewall rules

The phrase “zero trust” gets abused in marketing, but the core idea—never assume internal traffic is safe—does show up in the best examples of firewall design.

Example of segmenting user devices from critical servers

Imagine you have:

• A user VLAN for laptops and desktops
• A server VLAN for domain controllers, file servers, and application servers
• A management VLAN for switches, firewalls, and hypervisors

Examples of setting up firewall rules between these networks:

• User VLAN → Server VLAN: allow only the ports required for business apps (for example, HTTPS to web apps, SMB to file servers); deny everything else
• User VLAN → Management VLAN: deny all, except from a dedicated admin subnet or jump host
• Server VLAN → User VLAN: allow only necessary responses; no server should initiate arbitrary connections to user devices unless there is a documented reason (for example, software deployment tools)

This pattern limits lateral movement. If a user device is compromised via phishing or malicious downloads (topics covered by health and safety guidance at sites like CDC.gov when discussing cyber hygiene in public health contexts), the attacker can’t easily pivot to domain controllers or hypervisors.

Example of microsegmentation for sensitive apps

For particularly sensitive systems—think finance, healthcare, or regulated data—you can go further. Examples include:

• Creating a dedicated VLAN for payment processing or EHR systems
• Only allowing traffic from a specific application front end to those systems
• Forcing all admin access to go through a hardened jump host with MFA

These examples of setting up firewall rules aren’t theoretical; they’re modeled on patterns recommended in many sector-specific security frameworks and audits.

Practical tips for designing your own examples of firewall rules

Looking at examples of examples of setting up firewall rules is helpful, but you still have to translate them into your environment. A few practical patterns:

Start with “deny by default” and add only what you can explain.
If you can’t describe in one sentence why a rule exists—who needs it, from where, to what, and why—it probably doesn’t belong.

Prefer named groups over IP ranges where possible.
In cloud environments, using security group references or tags makes your rules easier to understand than long IP lists.

Log first, then tighten.
Enable logging on your firewall and review which ports and destinations are actually used. This gives you your own real examples of necessary traffic, instead of guessing.

Review rules regularly.
Stale rules accumulate. Quarterly reviews, especially after major projects, help you retire old exceptions. Organizations that skip this step often show up in incident writeups when an old, forgotten rule becomes the entry point.

For structured guidance on access control and network security, NIST’s Cybersecurity Framework provides a policy-level view you can tie back to your technical rules.

FAQ: common questions and examples of firewall configurations

What are some simple examples of firewall rules for a home user?

Simple examples of home firewall rules include blocking all inbound connections from the internet, allowing outbound web traffic (ports 80 and 443), and restricting outbound SMTP (port 25) from user devices. These examples of basic rules already reduce exposure to common attacks.

Can you give an example of blocking risky services without breaking business apps?

A practical example of this is blocking inbound RDP (3389) and SMB (445) from the internet entirely, while allowing those same ports only over a VPN from trusted networks. These examples of setting up firewall rules preserve functionality while removing the riskiest exposure.

What are the best examples of rules for remote workers?

Some of the best examples for remote workers are: allowing only VPN traffic from the internet to your firewall, segmenting VPN users into their own network, and allowing that network to reach only specific internal services (file shares, HR apps) on specific ports. These real examples of VPN-focused firewall rules reflect how many mature organizations operate in 2024–2025.

How often should I review and update my firewall rule examples?

At minimum, review your rules every quarter, and any time you add or retire a major application. Use logs to find inactive rules and compare your current setup against known-good examples of examples of setting up firewall rules from vendor guides, security frameworks, and internal standards.

Where can I find more authoritative guidance and examples of network security practices?

For policy and framework guidance, NIST and CISA publish reference architectures and best-practice documents. For broader security awareness, public health and safety organizations like CDC.gov sometimes include cyber hygiene in their emergency preparedness and public guidance materials, which can help you frame your own internal training around safe network use and firewall behavior.

The bottom line: you don’t need exotic technology to improve your firewall posture. You need clear, opinionated examples of setting up firewall rules that match how your organization actually works—and the discipline to keep those examples updated as your environment and the threat landscape evolve.