Screened Subnet
A screened subnet is an isolated network zone built between two distinct firewalls. You set it up to separate public traffic from your private internal systems. Teams place public web servers in this middle zone to keep private data safe. Still, teams often open broad network ports so engineers can fix servers fast. When roles or firewall rules are too broad, one breach exposes the inner network. How a screened subnet works in network design This architecture uses two routers or firewalls to
Subnet: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A screened subnet is an isolated network zone built between two distinct firewalls. You set it up to separate public traffic from your private internal systems. Teams place public web servers in this middle zone to keep private data safe. Still, teams often open broad network ports so engineers can fix servers fast. When roles or firewall rules are too broad, one breach exposes the inner network.
How a screened subnet works in network design
This architecture uses two routers or firewalls to build a safe middle zone. The outer firewall faces the public internet and filters incoming external web requests. It only lets approved traffic reach the public servers inside the middle zone. These servers handle web requests, email routing, or domain name lookups for users.
The inner firewall sits between the middle zone and the private internal network. It blocks public users from reaching your core databases and internal company systems. If an attacker breaks into a web server, they stay trapped in the middle. The inner firewall stops them from moving deeper into your private network zone.
To make this work, admins write strict routing rules on both firewall devices. Public traffic stops in the middle zone and never crosses the inner boundary. Internal apps in the private zone only accept requests from specific middle servers. Admins also block direct traffic from the internet to the private network zone.
How teams manage roles and traffic rules
Setting up the network zones is only the first step for security teams. Engineers still need a way to log in and update the middle servers. They also need to query private databases to fix bugs and check logs. Teams usually add firewall exceptions that allow admin traffic across both network boundaries.
Over time, these port rules grow complex and hard for teams to track. A team might open a database port for a short test and forget it. Another common issue is sharing static keys or admin accounts across multiple servers. Once a user crosses the inner firewall, they hold broad database role permissions.
Network teams review firewall rule lists every few months to remove stale entries. Yet, removing an active rule might break a live app or block an engineer. Because of this risk, many teams leave broad network paths open by default.
Subnet: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network zones solve and what they miss
A dual-firewall layout does a great job of blocking raw network packet attacks. It keeps public internet scanners away from your private servers and data stores. It also limits how far an outside attacker can move after a server breach.
Still, network rules only check IP addresses and port numbers at the border. Once an engineer or app logs in, the firewall stops checking their actions. The firewall cannot read the actual database queries or shell commands in flight. It decides who can cross the border, not what commands they run inside.
If an approved user runs a bad query, the firewall lets it pass. If a query returns sensitive emails, phone numbers, or card numbers, it passes through. Network zones alone cannot rewrite sensitive fields or block single destructive commands in flight. Teams need controls that inspect individual commands and mask sensitive results in real time.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How is a screened subnet different from a standard firewall?
A single firewall only puts one barrier between public traffic and private data. The subnet approach uses two firewalls to create an isolated middle buffer zone. This adds a second barrier that protects private systems if a public server fails.
What servers belong inside the middle network zone?
You should place any system that talks directly to the public internet there. Common examples include web servers, mail relays, and public file transfer hosts. Core databases and internal business tools must stay behind the inner firewall instead.
Why do inner databases still face risks from approved users?
Firewalls only check network ports and IP addresses when a session starts. Once an engineer logs in, the network allows any query their role permits. The firewall cannot stop an approved user from running a bad delete command.