DMZ Reveal
You run a dmz reveal by scanning perimeter hosts and checking every open route. This check shows which public services talk to your private internal systems. Engineering teams set up this border zone to keep web servers away from core databases. Still, broad network rules or shared keys often give attackers a clear path inside. When a role has too much reach, one bad host puts all internal data at risk. How a dmz reveal works in your network A perimeter network sits between the public interne
Reveal: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run a dmz reveal by scanning perimeter hosts and checking every open route. This check shows which public services talk to your private internal systems. Engineering teams set up this border zone to keep web servers away from core databases. Still, broad network rules or shared keys often give attackers a clear path inside. When a role has too much reach, one bad host puts all internal data at risk.
How a dmz reveal works in your network
A perimeter network sits between the public internet and your private internal systems. To start a dmz reveal, the security team maps every server in this outer zone. They check firewall rules to see which ports take traffic from the outside world. Next, they trace how those border servers talk to internal apps and databases.
In a standard setup, an outer firewall blocks direct public traffic from reaching private hosts. A second inner firewall controls how the border servers send requests into the private zone. Teams use network scans and route tables to verify that these two walls hold firm. They also check host logs to find old services or test apps left open by mistake.
Identity roles also play a big part in this border check. Apps in the outer zone need keys or service roles to read internal data. During the review, engineers list every key stored on those public-facing machines. This step shows what an attacker could reach if they take over a border host.
What native border rules solve and what they miss
Native firewall rules and network zones do a great job of blocking random outside scans. They stop public users from sending direct network packets to your private database servers. By splitting the network into zones, you shrink the surface exposed to the open web. Network checks also help teams spot open ports and fix bad route rules fast.
Still, network walls and basic roles leave a big gap during live operations. A firewall only decides which machine can open a port to another machine. Once a border server or engineer logs in, the firewall does not read the commands. It cannot tell a safe read query from a command that drops a table.
Reveal: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The same problem happens when engineers log in to fix a broken border host. Teams often share broad admin roles so staff can fix outages without delay. Those roles let a user run any command or read raw tables with card numbers. Masking tools can rewrite emails and phone numbers in results, but basic firewalls cannot. Standard network logs also show packet counts rather than the exact queries a user ran.
Steps to tighten border host permissions
Start by removing static database keys and long-lived admin passwords from every border machine. When you store plain keys on disk, anyone who breaches that host can use them. Give each app a narrow role that only reads the specific tables it needs. Never let a public-facing web app use a root database role.
Next, review how your own engineers log in to manage those outer servers. Replace shared team accounts with individual user logins tied to your main identity provider. Set up clear rules so high-risk commands require a quick peer check before they run. Finally, log every command and query at the user level for fast security reviews.
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
What is the main goal of a dmz reveal?
The main goal is to find every exposed service and hidden route in your border zone. This helps your team close unused ports and remove broad keys before attackers find them.
Why are firewall rules not enough to protect internal databases?
Firewalls only check IP addresses and ports when a session starts. They do not inspect the actual SQL queries or shell commands running inside an open session.
How can teams protect sensitive data accessed from the border zone?
Teams should scope roles to the bare minimum and remove static keys from border hosts. They can also use data masking to rewrite card numbers and national IDs in query results.