3 Legged Firewall
You set up a 3 legged firewall by linking one device to three separate network zones. One leg faces the internet, one holds public servers, and one guards internal systems. Teams use this layout to keep public traffic away from private data stores. Still, broad port rules and shared credentials still let attackers move between zones. How a 3 legged firewall works in practice A standard firewall sits between two networks and filters traffic passing through. A 3 legged firewall adds a third net
Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a 3 legged firewall by linking one device to three separate network zones. One leg faces the internet, one holds public servers, and one guards internal systems. Teams use this layout to keep public traffic away from private data stores. Still, broad port rules and shared credentials still let attackers move between zones.
How a 3 legged firewall works in practice
A standard firewall sits between two networks and filters traffic passing through. A 3 legged firewall adds a third network interface to that single security appliance. Network teams call these three zones the outside, the inside, and the DMZ.
The outside leg connects directly to your public internet link and untrusted traffic. The DMZ leg hosts web servers, mail relays, and public API endpoints. The inside leg protects your private apps, internal hosts, and production databases.
You write directional rules on the firewall to control packets between each leg. Public users can reach the DMZ on web ports, but never the inside zone. Servers in the DMZ can open limited sessions to specific hosts on the inside leg. Internal hosts can talk to the DMZ and reach the internet when needed.
If an attacker compromises a public web server, the DMZ rules contain the breach. The firewall drops any packet from the DMZ that tries to scan the private network. You get strong zone isolation without buying two separate hardware firewalls.
Why network zones alone cannot secure internal sessions
Setting up network zones solves packet routing, but it leaves a big operational gap. A firewall checks IP addresses and ports, not the commands inside an allowed session. Once a packet passes the port rule, the network firewall stops watching.
Engineers and support staff still need to log in to internal databases and hosts. To allow this, teams often open admin ports from a management subnet or VPN. They hand out shared database passwords or long-lived SSH keys to the team.
Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When an engineer opens a session, the firewall only sees an allowed IP and port. It cannot tell who the real person is behind a shared database user. It cannot read the SQL queries or shell commands running inside that encrypted tunnel.
A single bad query can drop a table or pull thousands of customer emails. If a developer machine gets compromised, the attacker inherits that same allowed network path. Network rules decide which machine can connect, not what a user does after logging in.
Closing the gap between network rules and user actions
To protect internal data, you must pair zone rules with controls at the session level. Start by trimming DMZ-to-inside rules down to the exact host IP and port required. Never let a whole DMZ subnet talk to an entire private database subnet.
Next, stop giving engineers direct network paths with static credentials stored on laptops. Tie every session to an individual identity from your main directory provider. When you inspect sessions at the protocol level, you can log every command and query.
You can also apply data masking rules that rewrite sensitive fields in query results. Masking rewrites matched emails, phone numbers, card numbers, and national IDs before results return. This keeps private data safe even when an engineer has an open network path.
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
What are the three zones in a 3 legged firewall setup?
The three zones are the untrusted outside internet, the semi-trusted DMZ, and the trusted inside network. Each zone plugs into its own dedicated physical or virtual interface on the firewall.
How does a 3 legged firewall differ from a dual-firewall DMZ?
A 3 legged firewall uses one appliance with three interfaces to separate all three zones. A dual-firewall setup uses two separate appliances with the DMZ sitting between them. The single appliance costs less to run, while two appliances add hardware redundancy.
Can a 3 legged firewall stop bad database queries from the DMZ?
No, a network firewall only checks IP addresses, ports, and basic connection states. Once you allow the DMZ app to reach the database port, all queries pass through. You need session-level controls to inspect queries or rewrite sensitive fields like card numbers.