CryptoGuard Technical Reference
In-depth documentation covering the defense architecture, packet inspection models, sequential ACL evaluation, and OWASP security hardening applied to this platform.
Contents
Defense-in-Depth Architecture
Layered Security Model
Defense-in-Depth is a security strategy that employs multiple, independent layers of protection. If one layer fails, the next layer stops the attack. CryptoGuard implements this with three distinct network zones: the Untrusted WAN, the Demilitarized Zone (DMZ), and the trusted Corporate LAN.
Three-Zone Segmentation
The WAN zone contains all external, untrusted traffic from the internet. The DMZ is a semi-trusted buffer zone housing public-facing servers (web, mail). The LAN is the fully trusted internal network containing sensitive assets (databases, workstations).
Dual Firewall Design
Two independent firewall gates enforce policy between zones: • External Firewall (WAN ↔ DMZ): Permits only specific ports to DMZ servers • Internal Firewall (DMZ ↔ LAN): Strictly limits which DMZ services can reach internal systems This prevents a compromised DMZ server from directly accessing the LAN.
Stateful vs. Stateless Packet Filtering
Stateless (Packet Filter)
A stateless firewall evaluates each packet independently against a fixed rule set. It cannot distinguish between a new connection attempt and response traffic from an established session. This requires explicit rules for both outbound and inbound return traffic, which is operationally complex.
Stateful Inspection
CryptoGuard implements Stateful Packet Inspection (SPI). When an ALLOW rule matches an outbound packet, the engine creates a connection state entry tracking the 5-tuple: (srcIP, srcPort, destIP, destPort, protocol). Subsequent return traffic matching the reverse 5-tuple is automatically permitted via the state table, without requiring an explicit inbound rule.
Bidirectional Return Verification
When a response packet arrives, CryptoGuard first queries the connection state table for a matching established session. If found, the packet is immediately allowed as a STATEFUL HIT, bypassing full rule evaluation. Sessions expire after 1 hour of inactivity. This prevents spoofed ACK attacks on stateless firewalls.
Top-to-Bottom Sequential Rule Evaluation
Priority-Based Matching
CryptoGuard's rule engine sorts all active rules by priority number (ascending). When a packet arrives, the engine iterates through rules from lowest priority number to highest. The FIRST rule whose criteria match the packet terminates evaluation and its action is applied.
Rule Ordering Is Critical
A common misconfiguration is placing a broad "ALLOW any-to-any" rule before a specific "DENY" rule. The broad rule shadows the specific rule, making it permanently unreachable. CryptoGuard's Policy Auditor automatically detects these shadowing relationships.
Implicit Default Deny
If a packet traverses the entire rule base without matching any rule, the implicit default deny policy activates. The packet is silently blocked with no response to the sender. This "fail-closed" design ensures unknown traffic is never inadvertently permitted.
OWASP Top 10 & Security Hardening
Security Headers (A05:2021)
CryptoGuard enforces strict HTTP response headers: • Content-Security-Policy (CSP): Restricts script/style/font origins • X-Frame-Options: DENY — Prevents clickjacking • X-Content-Type-Options: nosniff — Prevents MIME sniffing • Strict-Transport-Security (HSTS): Forces HTTPS for 2 years • Referrer-Policy: strict-origin-when-cross-origin
Input Validation (A03:2021)
All user input in the Packet Injector is validated server-side using Zod schemas before processing: • IPv4 addresses validated with regex: 0.0.0.0 to 255.255.255.255 • Port numbers validated as integers in range 1–65535 • Protocol enforced as enum: TCP | UDP | ICMP This prevents injection attacks from malformed packet descriptors.
Permissions Policy & Zero-Trust
The Permissions-Policy header disables browser APIs not required by the application: camera=(), microphone=(), geolocation=(), interest-cohort=() Zero-Trust principles are applied to network zone design — no implicit trust between zones. Every cross-zone communication requires an explicit ALLOW rule.
Ready to Simulate?
Apply what you've learned. Inject packets, audit policies, and observe stateful behavior in action.
Open Live Engine