The "Invisible" Attack — A 24-Hour Forensic Audit
Most website owners assume that if they don't have many visitors, they aren't a target. This case study proves that the moment a site goes live, it is discovered by automated global botnets. We left a an unhardened WordPress site—Alex Accounting—running for 24 hours to see who would come "fishing".
Project Fortress: Technical Diary
Transforming a "Standard" Install into a Hardened Digital Bastion
1. The Challenge: The "Default" Vulnerability
Most businesses deploy WordPress using "one-click" installers. While functional, these environments are "chatty" and insecure. Within 12 hours of deploying a raw EC2 instance, my logs recorded over 400 malicious hits from global botnets. The mission was to move to a professionally hardened, self-defending architecture.
2. Phase I: Identity & Transport Security
Before addressing the software, we secured the perimeter and the "Vault Door":
- SSL/TLS Achievement: Deployed Let’s Encrypt via Certbot, moving the site from an "F" grade to a Qualys SSL Labs Grade A.
- The Compliance Gap: I proved that a "Grade A" padlock is an illusion of security; while the tunnel was encrypted, the server was still broadcasting its "blueprints" to active scanners.
3. Phase II: Infrastructure "Silence" & Cloaking
To defeat automated reconnaissance, I implemented a policy of Information Obscurity:
- Header Masking: Reconfigured Apache and PHP to strip version numbers, preventing attackers from mapping the site against specific exploits.
- Identity Shielding: Restricted the WordPress REST API to stop "User Enumeration" attacks. Nmap scans now return zero results for admin discovery.
- Directory Hardening: Disabled Directory Indexing and moved sensitive assets (ledgers, backups) into a non-public vault.
Figure 1.2: Active Deterrence Architecture
Visualizing the "Bouncer" logic: Rejecting malicious patterns at the Kernel level.
4. Phase III: Active Intrusion Prevention (The Bouncer)
The final phase was transitioning to Active Deterrence. We engineered a real-time link between application logs and the Linux Kernel firewall (NFTables).
The Three-Tier Recidive Policy:
- Level 1: Monitors for 404/403 errors (Reconnaissance).
- Level 2: Issues a 10-minute "Cooling Off" ban for minor triggers.
- Level 3: Escalates to a 7-day Kernel-level ban for persistent, automated scanning.
5. The Results: Verified Hardening
Using a "Red Team" approach, I simulated attacks from geographically distributed VPNs. By the end of the audit, the server ceased to exist for anyone attempting to scan it—it is now a Reactive Black Box.
| Metric | Before Hardening | After Hardening |
|---|---|---|
| SSL Grade | F (Insecure) | A (Verified) |
| User Discovery | Success (Admin leaked) | Blocked |
| Aggressive Scan | Success (Full Map) | Total Lockout |
Is your infrastructure a "Sitting Duck"?
Project Fortress demonstrates that true security is a layered architecture.
Request a Technical Briefing