How I Built Our Website Infrastructure — And Why It Matters

If you're going to advise companies on cybersecurity, your own infrastructure should reflect that. Practice what you preach.

This is a walkthrough of the principles behind how the CyberReadyLabs website is built and protected. It's not just a static site on shared hosting. It's a defense-in-depth architecture designed to demonstrate the same principles we recommend to clients.

Zero Exposed Ports

The server running this website has no ports exposed to the internet. None. Not 80, not 443, not SSH. The firewall's inbound rules are simple: deny all.

So how does traffic get here? An encrypted outbound-only tunnel.

The tunnel creates an outbound connection from our server to a global edge network. Traffic from the internet hits the edge first, gets filtered through web application firewall rules and DDoS protection, then gets forwarded through the tunnel to our origin server. The tunnel is authenticated and encrypted, so no one can inject traffic into it without proper credentials.

Hardened Containers

The site runs in a containerized deployment with security-first configurations:

• Read-only filesystem — The container's root filesystem is mounted read-only. Even if an attacker achieves code execution, they can't modify binaries or write persistence mechanisms.
• No privilege escalation — Security flags prevent the container from gaining additional capabilities through setuid binaries or other escalation techniques.
• Dropped capabilities — We drop all Linux capabilities and only add back the specific ones needed. The container can't mount filesystems, change network settings, or perform administrative operations.
• Resource limits — CPU and memory limits prevent denial-of-service conditions and container escape attempts that rely on resource exhaustion.
• Non-root execution — The web server process runs as an unprivileged user. Container compromise doesn't mean root on the host.

Behavioral Intrusion Detection

A behavioral intrusion detection system sits between the reverse proxy and web server, analyzing every request in real-time:

• Parses access logs looking for attack patterns
• Detects credential stuffing, web scanning, vulnerability probing
• Automatically bans malicious IPs at the proxy layer
• Shares threat intelligence with a global community, so attacks detected on our infrastructure help protect others and vice versa

When the system detects malicious behavior, it blocks the IP immediately. No manual intervention required.

Centralized Security Monitoring

The server runs an agent that reports to our centralized SIEM (Security Information and Event Management) platform. This gives us:

• File integrity monitoring — Alerts if any critical files change unexpectedly
• Log aggregation — Centralized visibility across all infrastructure
• Vulnerability scanning — Continuous assessment of installed packages
• Compliance checking — Automated security benchmark assessments
• Threat detection — Correlation rules for detecting attack patterns

Network Isolation

The web server lives on its own isolated network segment, completely separated from internal infrastructure. Even if it were completely compromised, the attacker gains nothing. There's no lateral movement path to internal systems, no credentials stored on the box, no access to customer data.

This is the principle of blast radius minimization: if (when) something gets compromised, limit the damage it can do.

Host-Level Hardening

The underlying server is hardened according to industry security benchmarks:

• Default-deny firewall — Host firewall blocks all traffic except explicitly allowed destinations
• SSH hardening — Key-only authentication, no root login, access limited to management networks
• Automatic security updates — Critical patches applied automatically
• Brute-force protection — Automated blocking of repeated failed login attempts
• Kernel-level audit logging — Comprehensive logging of security-relevant system calls
• Minimal attack surface — Unnecessary services disabled

Why This Matters

Is this overkill for a static website? Probably.

But that's not the point. The point is that if you're going to advise companies on security architecture, your own infrastructure should demonstrate those principles. Every recommendation we make to clients (network segmentation, defense in depth, least privilege, security monitoring) we've implemented ourselves.

When a client asks "how do we implement Zero Trust?" or "what does defense in depth look like in practice?" we can point to real experience. Not theoretical diagrams, but production systems we've built and operated.

Questions?

If you're curious about these principles or want to discuss how similar approaches could apply to your infrastructure, get in touch. Security architecture is what we do.