DMZ Ports
You set up dmz ports by opening only required listener numbers on your perimeter firewall. Then you block all direct traffic from public networks into your private internal zone. Most teams place web servers and mail relays inside this buffer subnet. Still, broad port rules often let attackers reach internal data stores after one server breach. How dmz ports work in a split network A buffer zone sits between the public web and your private internal network. You use two firewall layers or one
Ports: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up dmz ports by opening only required listener numbers on your perimeter firewall. Then you block all direct traffic from public networks into your private internal zone. Most teams place web servers and mail relays inside this buffer subnet. Still, broad port rules often let attackers reach internal data stores after one server breach.
How dmz ports work in a split network
A buffer zone sits between the public web and your private internal network. You use two firewall layers or one multi-zone firewall to control the flow. The outer wall accepts public requests on specific dmz ports for web or mail traffic. For example, web servers listen on standard encrypted web ports for outside users. Mail servers use standard mail transport ports to get messages from other domains.
The inner wall sits between the buffer zone and your private data zone. This inner wall blocks almost all inbound requests from the public buffer subnet. When a web app needs data, it opens a strict path to the internal database. Network admins restrict that path to one source host and one target port. They also block all outbound web traffic from the buffer servers by default. This stops a breached host from downloading bad tools from outside servers.
Common traffic rules for public services
Each service in the perimeter zone needs a clear, narrow rule. Web servers need encrypted web ports open from the outside world. Name servers need domain lookup ports open for both packet types. File transfer servers need secure shell or encrypted transfer ports open for partner uploads. Every other port on the outer wall stays closed by default.
Engineers also need a way to manage and patch these perimeter hosts. Many teams open remote shell ports from a fixed office address to the buffer zone. Others route admin traffic through an internal management subnet first. In both setups, you should never open database ports to the public internet. Data stores belong inside the private zone behind the second firewall wall.
What port rules solve and what they miss
Strict firewall rules reduce your public attack surface right away. They stop outside scanners from talking to your private database servers. They also limit how far an attacker can move across your network. If a web server falls, the inner firewall blocks random scans of internal hosts.
Ports: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Yet port rules only check where a packet starts and where it goes. A firewall sees an allowed address and an open port number. It does not check which person is inside that session or what they run. Once a user or app logs in through an open port, the network steps aside. A developer with valid keys can run a bad query over an allowed database port. A breached web app can pull sensitive rows like emails, phone numbers, or card numbers. Port controls decide which host can talk, not what each command or query does.
Why teams pair network zones with command checks
Modern teams still use perimeter zones to separate public apps from private data. Network boundaries remain a strong first line of defense against broad internet scans. Still, compliance and security audits now ask for deeper records of live sessions. Auditors want to know who ran a command and what data came back.
To close this gap, teams pair strict port rules with session level controls. You keep your database inside the private zone and block public ports. Then you check every query and command before it hits the target server. You can also mask matched fields like national IDs or card numbers in query results. This approach protects your data even when traffic crosses an open internal port.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Which dmz ports should keeps the session active to the internet?
Open only the ports your public apps need, such as encrypted web ports. Keep all database, cache, and internal management ports closed to public traffic.
Should a database ever sit inside the DMZ subnet?
No, databases belong in your private internal zone behind the inner firewall. Only specific app servers in the buffer zone should talk to the database port.
Do firewall port rules stop bad database queries?
No, a port rule only checks network addresses and port numbers. It cannot read SQL statements, block drop commands, or mask emails in results.