A very common exam trap: treating the DMZ as simply "between the firewall and the internet." The correct architecture places the DMZ between two firewalls.
- First firewall (external): Faces the internet. Permits only specific traffic inbound (HTTP/HTTPS/SMTP) to the screened zone. Blocks everything else from the internet.
- Screened zone (DMZ): Contains public-facing servers — web, mail relay, DNS. These systems can receive internet traffic.
- Second firewall (internal): Sits between the screened zone and the trusted internal network. Blocks most traffic from the screened zone reaching the internal network. Permits only very specific, application-layer calls (web server querying DB on specific port/account).
- Trusted (internal) zone: Fully protected — no direct path from the internet; screened zone is contained by the internal firewall.
The exam question pattern: "A web server in the DMZ is compromised. The attacker attempts to access the internal database server. What PREVENTS this?" → The second (internal) firewall between the screened zone and the trusted zone. The attacker breached the first firewall's zone but hits the second firewall when trying to move to the trusted zone.
Why this trips people up: Students think of "the firewall" as a single device. A proper DMZ has two distinct firewall boundaries — the screened zone sits between them. Compromise of the DMZ does not mean compromise of the internal zone.
Students confuse honeypots with IDS/IPS sensors. The key difference is what generates the alert and how reliable it is.
- IDS/IPS sensor: Monitors real traffic. Generates alerts based on signature matching or behavioral anomaly detection. Has a false positive rate — legitimate traffic can trigger alerts if it matches a pattern. Requires tuning to reduce noise.
- Honeypot: Receives only traffic from devices that actively connect to it. Because no legitimate user or application should ever access a honeypot, any connection to it is suspicious by definition. Zero false positives — no tuning required. Every alert is real.
What honeypots do:
- Detect attackers who have already breached the perimeter and are exploring the internal network
- Detect lateral movement — a compromised internal device reaching out to a fake server it should never contact
- Reveal attacker techniques — what credentials they tried, what ports they probed, what commands they ran
What honeypots do NOT do:
- Prevent attacks — they observe and report, they do not block
- Protect real systems — the honeypot itself has nothing worth stealing
- Replace monitoring — they are one detection layer, not the whole security stack
Exam question pattern: "A security team wants a detection mechanism that generates no false positives for internal network reconnaissance." → Honeypot. "A security team wants to block known attack signatures from reaching internal servers." → IDS/IPS (inline mode). Not honeypot.
The exam tests whether students understand what TLS protects versus what IPsec protects — and crucially, what each does NOT protect.
TLS (application-level encryption):
- Encrypts the application session between the client and the server application
- Protects the payload of a specific protocol: HTTPS, SMTPS, IMAPS
- Works end-to-end between the client and the server — even if the network infrastructure is compromised, the data is encrypted
- Does NOT encrypt metadata: the source/destination IPs, timing, and connection volume are still visible
- Does NOT protect non-TLS applications using the same network link (SMB over the same wire is still unencrypted)
IPsec (network-level encryption):
- Encrypts all IP traffic between two network endpoints — the tunnel endpoints
- Protects everything in the tunnel, including protocols that have no native encryption
- Transparent to applications — they see a normal network; IPsec encrypts/decrypts below the application layer
- Does NOT protect data after it exits the tunnel (the endpoints receive unencrypted data)
- Does NOT protect application-layer attacks on the decrypted data
The exam question pattern: "An organization uses HTTPS for its internal web application. An attacker taps the network cable between the web server and its clients. What does the attacker capture?" → Encrypted HTTPS traffic — the payload is protected by TLS. "An organization's branch office connects via a third-party WAN. Unencrypted legacy database traffic flows over this link. What protects it?" → IPsec tunnel — TLS only protects specific applications, not legacy database protocols.
Many students understand that a jump server exists but miss the critical architectural detail: the firewall must block all direct administrative connections — the jump server is useless if admins can still SSH directly to servers.
How jump server security works:
- Firewall rule — all servers: SSH (port 22) and RDP (port 3389) are permitted ONLY from the jump server's IP address. Direct admin connections from any other source are blocked.
- Jump server itself: SSH from admin workstations is permitted to the jump server only. MFA is required. All sessions are logged and recorded.
- Result: An attacker who compromises an admin workstation cannot SSH to servers (blocked by firewall). An attacker who steals admin credentials cannot bypass MFA on the jump server. An attacker who somehow reaches a server cannot connect from it to other servers (no admin protocol permitted without going through jump server).
What fails if the jump server is configured but not enforced:
- If admin direct connections are still permitted alongside the jump server, the jump server provides zero security — admins use it when convenient, bypass it when not
- If the jump server has no MFA, a compromised admin credential reaches the jump server and proceeds normally
- If session logging is disabled, the audit trail value is lost even if access is correctly controlled
Exam question pattern: "Which control ensures that all administrative access to servers is logged and requires MFA?" → Jump server. "An organization deploys a jump server but finds admins still SSH directly to servers from their workstations. What is the MISSING control?" → A firewall rule blocking SSH to servers from any source other than the jump server IP.
Scenario A: A law firm is designing a new network for its 120 attorneys. The firm has the following requirements: (1) Attorneys need to access a case management system (internal application, no internet access required); (2) The firm's website must be publicly accessible and allow clients to upload documents; (3) Senior partners must be able to access the case management system remotely from home; (4) Guest Wi-Fi must be available in conference rooms for clients during meetings, with no access to any firm systems. Design a zone architecture with at least four zones, specify what belongs in each zone, and identify the traffic policy between each adjacent zone pair.
Show Answer
Zone architecture (five zones):
- Untrusted (Internet): The public internet. Source of client website visits; source of partner VPN connections.
- Screened Zone (DMZ): The law firm's public website with client document upload portal. Must accept internet traffic on HTTPS (443). Must NOT have any access to the case management system or internal databases — document uploads go to a staging area that internal staff retrieve through a controlled process.
- Trusted (Internal): Attorney workstations, the case management system server, file servers, printers. Not accessible from the internet. Attorneys access case management from their workstations here.
- Management Zone: VPN concentrator (terminates partner remote connections), jump server (required for server admin). Partners connect via VPN; VPN places them in a restricted segment that accesses case management only.
- Guest Zone: Conference room Wi-Fi. Internet access only. Completely isolated from the trusted zone, screened zone, and management zone. Clients can use the internet; they cannot reach any firm system.
Zone traffic policies:
- Internet → Screened: Permit HTTPS (443) only, to the document portal server only
- Internet → Trusted: Block all — no direct path from internet to internal systems
- Internet → Management: Permit VPN connections to VPN concentrator only (partners authenticating remotely)
- Screened → Trusted: Block all — document staging access is one-way (trusted staff pulls from screened zone, not pushed in)
- Trusted → Screened: Permit (staff access to staging area to retrieve client uploads)
- Management (VPN) → Trusted: Permit access to case management system only, on specific ports, with case management service account credentials
- Guest → Any internal zone: Block all — internet access only via NAT gateway
Additional control: All server administration (case management server, file servers) must go through the jump server in the management zone. Direct SSH/RDP to servers from attorney workstations is blocked at the firewall.
Scenario B: A security analyst reviews firewall logs and notices that a web server in the DMZ has been making outbound connections on port 445 (SMB) to the internal file server at 2:00 AM for the past three nights. This traffic pattern was not present two weeks ago. The web server is a Linux system; SMB is a Windows protocol. Analyze what this traffic pattern likely indicates, which security controls should have caught this earlier, and what immediate actions are required.
Show Answer
What this traffic indicates:
Three red flags converge to indicate compromise and likely lateral movement:
- A Linux web server initiating SMB (Windows file sharing) connections is anomalous — Linux systems do not natively initiate SMB connections to Windows file servers without an explicit configuration or tool
- The 2:00 AM timing is consistent with attacker-controlled scheduled activity — attackers use off-hours to avoid detection during active monitoring periods
- The pattern started two weeks ago — suggesting a persistent implant, not a one-time event. The web server was most likely compromised two or more weeks ago; the attacker has been staging a file server attack
Most likely scenario: the web server was compromised via a web application vulnerability. The attacker installed a persistent implant (reverse shell or scheduled task). The attacker is using the web server as a pivot point to attack the internal file server — attempting to exfiltrate data, encrypt files (ransomware staging), or establish persistence on the internal network.
Controls that should have detected this earlier:
- Internal firewall between DMZ and trusted zone: A correctly configured internal firewall should have blocked port 445 from the DMZ to the trusted zone entirely — web servers have no legitimate reason to initiate SMB connections to internal file servers. This traffic should never have reached the file server at all.
- IDS sensor at the DMZ/internal boundary: An IDS rule for "SMB connection from DMZ source to trusted zone" would have alerted on the first occurrence, two weeks ago.
- SIEM behavioral baseline: The web server's baseline behavior does not include initiating outbound connections to internal systems on any port. A SIEM with behavioral analytics would flag the new connection pattern as anomalous.
- Honeypot on the file server segment: A fake file server in the internal zone would have been probed by the attacker while mapping the network — generating an alert before the real file server was targeted.
Immediate actions:
- Block the DMZ → file server connection at the internal firewall immediately
- Isolate the web server (take it out of the load balancer pool; block outbound connections) — do NOT simply restart it, as this may destroy forensic evidence
- Preserve a forensic image of the web server's disk and memory before any remediation
- Audit the file server: what was accessed in the past two weeks during the 2 AM window? What data may have been exfiltrated?
- Rotate all credentials that the web server had access to (service accounts, API keys stored in web server config)
- Rebuild the web server from a clean image; apply all patches before returning it to the DMZ
Scenario C: A startup is launching a SaaS application. The CTO proposes allowing all developers to SSH directly from their laptops to any production server for "ease of debugging." The CISO objects and proposes a jump server architecture. The CTO argues: "We can just require strong passwords and MFA on each server — the jump server adds unnecessary complexity." Make the CISO's case: why is the jump server architecture superior to per-server MFA with direct SSH, even if each server individually requires MFA?
Show Answer
The CISO's case — five arguments the CTO's model cannot answer:
1. The audit trail is fragmented and unmanageable. With per-server SSH, each server maintains its own logs. An audit of "what did developer X do on Tuesday between 2 PM and 4 PM?" requires pulling and correlating logs from every server they touched — potentially dozens or hundreds. With a jump server, every session is recorded in one place: source IP, user, timestamp, destination server, and every command executed. One system to query for complete visibility.
2. MFA enforcement is inconsistent. Requiring MFA on each server individually means MFA is a configuration item that must be correctly deployed and maintained on every server. A new server deployed without MFA is immediately an exception. A misconfigured server that accepts password-only auth is invisible until audited. With a jump server, MFA is enforced at one entry point — every session through the jump server requires MFA. There is no per-server configuration drift to audit.
3. The attack surface is proportional to the number of servers. If there are 40 production servers, each with SSH open to the developer subnet, the administrative attack surface is 40 × the number of developer IPs. A compromised developer laptop can reach 40 targets directly. With a jump server, the attack surface is 1: the jump server. All servers have SSH blocked from everywhere except the jump server IP. A compromised developer laptop hits the jump server and encounters MFA — game over.
4. Session recording is impossible per-server. Full session recording (keystrokes + screen recording for RDP) requires centralized infrastructure. A jump server can record every session. Individual servers cannot provide equivalent recording without per-server agents that are expensive to deploy, maintain, and audit. Session recording matters for: incident investigation (what did the attacker do?), insider threat detection (what did the developer do?), and compliance (demonstrating that privileged access is controlled).
5. Offboarding a developer requires one change, not N changes. When a developer leaves, disabling their access on the jump server immediately removes all their production access — because the jump server is the only path in. With per-server SSH, offboarding requires removing the developer's public key from 40+ servers — a process prone to error and omission. A missed server is a persistent unauthorized access path.
Conclusion: The jump server is not complexity for its own sake — it is the architectural consolidation of MFA enforcement, logging, session recording, and access control into a single auditable system. The per-server model requires the same controls to be implemented correctly, independently, on every server — a scale that introduces inevitable inconsistency. The "simplicity" of direct SSH is illusory; the actual operational complexity is higher.