Staq’s Multi-Layer Security Architecture
Understanding Staq’s Multi-Layer Security Architecture
At Staq, every WordPress site runs on a secure, multi-layered architecture designed to protect your websites from network attacks, malware injections, spam, brute-force attempts, and automated bots.
Security isn’t just a plugin or feature — it’s integrated into every layer of our platform, from the server level down to your WordPress application.
1. AWS Infrastructure Security
All Staq servers are hosted on Amazon Web Services (AWS) inside a Virtual Private Cloud (VPC).
This ensures all components — EC2 servers, RDS databases, Redis ElastiCache, and internal services — operate within a private, isolated network protected by strict Security Group rules.
Key highlights:
- Only required ports (HTTP, HTTPS, Redis, SFTP, etc.) are open.
- Ports like 22 (SSH) and 21 (FTP) are blocked by default at the AWS level.
- SSH and SFTP are only accessible through randomly generated, private ports unique to each server — making them nearly impossible to guess.
- Outbound traffic is tightly controlled, and only trusted communication within the VPC is allowed.
This VPC-based isolation forms the foundation of Staq’s secure environment.
2. Iptables – Operating System-Level Firewall
Every server runs a hardened Linux firewall using iptables, which is the first layer of defense when a request reaches the server.
It filters traffic before it even touches Nginx or PHP, blocking common attack patterns like null packets, XMAS scans, and SYN floods.
Only allowed ports (e.g. HTTP, HTTPS, Redis, SFTP) are accepted — everything else is rejected.
This guarantees that any unauthorized or malformed network traffic is immediately dropped before reaching Nginx.
3. Nginx – Application Gateway Protection
Once a request passes iptables, it reaches Nginx — our web gateway that performs a second layer of filtering.
3.1 Nginx ModSecurity
We use ModSecurity rules to identify and block known web attack signatures such as SQL injection, cross-site scripting (XSS), and request smuggling attempts.
3.2 Bad Bot and Referrer Blocking
After ModSecurity, requests are checked against a dynamic list of bad bots and malicious referrers sourced from the open-source project:
nginx-ultimate-bad-bot-blocker
- This list updates daily.
- Offending requests receive an immediate HTTP 444 response (Nginx silently drops them).
- Known SEO crawlers (e.g. Semrush) are blocked by default, but users can allow them via the “Allow Known SEO Bots” option at either the account or site level by following this guide to enable SEO bots on Staq.
- If an IP is banned by the application firewall (see below), Nginx can also block it directly for efficiency.
Additional Nginx optimizations:
- SSL protocols: TLS 1.2 and TLS 1.3
- Hidden version headers for both Nginx and PHP
- PHP execution disabled inside
wp-content/uploads/ - Blocked access to
wp-login.php(default) to stop brute-force attacks (accessible via/wp-admin) - Optional bot rate limiting to restrict excessive hits from non-verified bots
- Built-in static cache that serves HTML directly from disk, greatly reducing server load during DDoS spikes
4. Staq WAF – PHP-Level Application Firewall
Before WordPress even loads, Staq automatically injects a lightweight, high-performance Web Application Firewall (WAF) at the PHP layer using auto_prepend_file.
This allows us to inspect and block malicious traffic before PHP or WordPress resources are consumed — unlike plugin-based firewalls that run too late.
4.1 Real-Time Rules
Each request is evaluated against multiple rule sets:
- SpoofingRule: Detects IP or header spoofing attempts
- DisallowedURIRule: Blocks access to disallowed URLs or offensive content
- IPBlacklistRule: Checks against an offline CleanTalk database (premium license that Staq subscribes and pays for)
- ServiceBlacklistRule: Blocks known cloud scrapers (e.g. Alibaba, Tencent)
- PageEnumerationRule / UserEnumerationRule: Limits page or user probing activity
4.2 POST Request Scanning
For non-logged-in users submitting forms or comments, the WAF scans the request payload for spam or malicious content:
- FormSpamRule: Filters spam and adult content
- CommentSpamRule: Detects abusive comment submissions
- EmailBlacklistRule: Checks sender emails against the CleanTalk database
All lookups are cached for efficiency, minimizing false positives and overhead.
4.3 Adaptive Intelligence and Rate Limiting
The WAF continuously adapts based on IP history and behavior:
- Known editors/admins or verified bots (e.g. Googlebot) are exempted before being banned.
- If an IP is borderline suspicious, the system may present a reCAPTCHA challenge before enforcing a ban.
- A background process analyses logs every minute to detect patterns such as:
- Repeated requests to sensitive files (
/.env,/wp-config.php, etc.) - High 404 error ratios
- DDoS-like behavior or geographic anomalies (e.g. stricter limits for non-local regions)
- Repeated requests to sensitive files (
When a permanent ban is applied:
- The IP is logged and synced to the Staq dashboard (so you can view, whitelist, or unblock it).
- If required, it is also pushed to iptables for operating-system-level blocking — saving server resources for legitimate users.
- Ban data is securely cached under a hidden folder inside the WordPress app (not publicly visible).
5. WordPress Firewall Rules (MU Plugin)
Beyond the automatic protection, Staq gives users full control at the WordPress level via our MU Plugin.
From the WordPress Admin, users can:
- Ban traffic by IP, IP range, User-Agent, Country, or Hostname
- Define rate limits (e.g. max requests per defined interval)
- Choose whether the ban is strict (server-level block) or soft (user can solve a CAPTCHA to unblock)
- Exclude certain logged-in roles (e.g. allow “Editors” but restrict “Customers”)
Other built-in protections include:
- Login rate limiting with automatic lockouts
- Hidden login pages (renamed from
wp-login.phpby default) - No disclosure of whether a username exists during failed logins
- Disabled XML-RPC and RSS version leaks
- Enforced REST API authentication (with exceptions for public endpoints)
6. Additional Security Enhancements
- SSL Certificates: All sites include free Let’s Encrypt SSL. Certificates are generated automatically as soon as DNS points to the correct IP. Users can also upload custom SSL certificates.
- Secure One-Click Login: From the Staq Dashboard, users can log in to WordPress securely without sharing or remembering passwords.
- Custom Login URL: Users can rename both
wp-login.phpandwp-adminfor additional obfuscation, without needing a separate plugin. - Whitelist IP Addresses accessing login page: You can even whitelist IP addresses that can access the login page only.
- Bot-aware Caching: Static caching synced with Nginx ensures DDoS spikes and invalid bot traffic minimally reach PHP or the database.
7. Server Firewalls Summary
Staq’s multi-layered security stack provides defense in depth — each layer independently reinforces the next:
| Layer | Component | Purpose |
|---|---|---|
| 1 | AWS Security Groups | Isolates services within a private VPC |
| 2 | iptables | Filters bad traffic at the OS level |
| 3 | Nginx + ModSecurity | Blocks known attack patterns and bad bots |
| 4 | Staq WAF (PHP) | Early PHP firewall with intelligent behavioral rules |
| 5 | WordPress Firewall Manager | User-configurable rules and rate limits |
Each site benefits from an adaptive, continuously updated, and performance-focused protection system that stops attacks long before they can reach WordPress.
8. CDN-Level Protection
On top of all server and application security layers, Staq offers built-in CDN integration with both CloudFront (AWS) and Cloudflare.
You can enable and configure these directly from the Staq Dashboard — no technical setup required.
This adds an additional global security layer that filters and absorbs threats before they even reach your Staq server:
- DDoS Mitigation: Large-scale traffic attacks are absorbed by Cloudflare and AWS CloudFront’s edge network.
- WAF at the Edge: Known malicious IPs and attack signatures are blocked automatically at the CDN layer.
- Bot and Spam Protection: Cloudflare’s bot management filters abusive crawlers and scripts.
- Global Anycast Network: Requests are served from the closest location, improving both performance and security.
- Integrated SSL: End-to-end encryption from CDN → Staq → WordPress, ensuring traffic is secure across all layers.
By combining Staq’s firewalls with CDN-level protection, users benefit from a comprehensive, multi-tier defense — from the cloud edge to the application core.
Security White Paper
You can download and share our security white paper.
Need some help?
We all do sometimes. Please reach out to our support team by dropping us a support ticket. We will respond fast.