If you publish anything to the internet — a website, a mail server, a booking portal, a VPN — you need to decide where it lives and what can reach it. Put it on the LAN and a compromise owns everything; put it nowhere and nobody can use it. The DMZ is the answer, and where you place your firewall(s) is the architecture.
A DMZ (demilitarised zone) is a network segment for the systems that must be reachable from the internet, positioned so that if one of them is compromised, the attacker still can't reach your internal LAN. That last clause is the entire point. Anything internet-facing is, by definition, the most likely thing to be breached; the architecture's job is to ensure a breached web server is a bad day, not a total loss.
The design is about firewall placement and traffic direction. The load-bearing rule is DMZ → LAN: deny — published services may talk to the internet and be reached from it, but they must not be able to initiate connections inward. Internal hosts reach out freely; the internet reaches only specific DMZ ports; nothing from outside or the DMZ reaches the trusted LAN uninvited. This builds on segmentation and the zone-based firewall, applied to the highest-stakes boundary you have.
01
A single firewall with three interfaces — internet, DMZ, LAN — and a policy between each pair. Cheapest and entirely adequate for most businesses.
The three-legged (or "three-homed") firewall is the pragmatic standard: one device, three zones, three sets of rules. Internet→DMZ permits the published ports (443 to the web server, 25/587 to mail). Internet→LAN denies everything unsolicited. DMZ→LAN denies (the critical rule). LAN→anywhere is permitted, statefully. It's simple, one place to manage, and for a hotel, office, or clinic publishing a couple of services it's exactly right. The theoretical weakness — one device is one thing to compromise or misconfigure — is managed with good change control and monitoring, not by reflexively buying two firewalls.
02
An outer firewall between internet and DMZ, an inner firewall between DMZ and LAN. The DMZ sits sandwiched between them. More robust, more expensive, and worth it above a certain risk threshold.
In the classic screened-subnet (back-to-back) design, an attacker who breaches a DMZ host still faces a second, separate firewall — ideally from a different vendor — before reaching the LAN. That defence-in-depth matters when the published services are high-value or the internal network is highly sensitive (payment processing, healthcare records, anything regulated). The cost is two devices, two rule sets, and more operational overhead. Reserve it for genuine risk, not prestige: a small business publishing a brochure site does not need two firewalls; a company processing card data in-house probably does.
Perimeter thinking fixates on the internet boundary, but the DMZ needs internal discipline too. If your DMZ holds a web server and a mail server, a compromise of one shouldn't trivially own the other — segment within the DMZ, or at least restrict DMZ-to-DMZ traffic. And the modern reality is that most attacks, once inside, move east-west; a perfect perimeter with a flat interior just means the attacker roams freely after the first foothold. The perimeter is necessary, not sufficient — pair it with internal segmentation and, ideally, zero-trust east-west control.
03
How a service actually gets exposed matters as much as where it sits. A few patterns keep the attack surface honest.
| Pattern | Why |
|---|---|
| Reverse proxy in the DMZ, app behind it | One hardened front door; the app server never faces the internet directly |
| Only the required ports, to the specific host | Publish 443 to the web VM — not "the DMZ"; deny the rest |
| Terminate VPN at the firewall/DMZ, not the LAN | Remote access lands in a controlled zone, not straight onto trusted infra |
| Outbound-initiated tunnels for CGNAT/Starlink sites | No inbound public IP needed; the service dials out to a broker |
| Log and monitor DMZ→anywhere | A DMZ host suddenly scanning the LAN is your breach alarm |
Takeaways
NOCTIS designs internet perimeters across Crete — DMZ placement, firewall architecture, and safe publishing patterns — so a compromised public service stays contained, not catastrophic.
Book a Discovery Call →