Skip to content

Smart WAF & Security

Bot detection, SQL injection prevention, fraud signals — invisible to your customers, lethal to attackers.

Magento is one of the most targeted e-commerce platforms on the internet. Card skimming, credential stuffing, inventory scraping, SQL injection — every Magento store in production is under constant automated attack. Accelerate Guru's in-process WAF sits at the network edge and stops these attacks before they reach PHP.


#How the WAF works

Every inbound request passes through a multi-stage scoring pipeline that runs in under 10 microseconds:

Request arrives
      │
      ▼
[1] IP reputation check
      │  (known-bad IPs, runtime blocklist, CIDR ranges)
      ▼
[2] TLS fingerprint analysis (JA4)
      │  (identifies bot clients masquerading as browsers)
      ▼
[3] Header coherence check
      │  (detects mismatched User-Agent / Accept-Language / TLS fingerprint)
      ▼
[4] Path and payload heuristics
      │  (SQL injection, path traversal, WordPress probes, known exploit patterns)
      ▼
[5] Rate limiting
      │  (per-IP request rates, login attempt rates)
      ▼
[6] Score threshold decision
          │                    │
          ▼                    ▼
      ALLOW                  BLOCK
   (forward to cache)    (403 / rate limit)

No request is blocked by a single signal alone — the WAF accumulates evidence and only acts when confidence is high. This means near-zero false positives on legitimate traffic.


#Default protections (enabled out of the box)

The WAF blocks the following without any configuration:

  • SQL injectionUNION SELECT, OR 1=1, ' OR ''=', hex-encoded variants, URL-encoded variants, and dozens of other patterns.
  • Path traversal../, %2e%2e%2f, %2e%2e/, mixed-case encodings, and null-byte variants.
  • Admin brute force — Rate limiting on /admin login attempts. Blocks IPs that exceed the threshold automatically.
  • WordPress probes — Requests to /wp-login.php, /wp-admin/, /xmlrpc.php are blocked immediately (a Magento store has none of these; they are always scanners).
  • Known bad user agents — Malicious bots, credential stuffing tools, and scrapers identified by their user-agent strings.
  • Suspicious TLS fingerprints — Automated tools often have distinctive JA4 fingerprints that differ from real browsers. High-confidence bot fingerprints are challenged or blocked.
  • Oversized requests — Requests with abnormally large headers or bodies (common in DDoS and overflow attempts).

#Configuration

All WAF settings live in the [security] section of magento_ultra.ini:

[security]
enable_smart_waf     = true
disable_waf_on_admin = true
admin_path           = /admin
block_threshold      = 3
log_file             = /var/log/accelerate-guru/waf.log
enable_bot_detection = true

#block_threshold

This is the number of WAF violations an IP accumulates before it is added to the runtime blocklist automatically. The default is 3.

A "violation" is any request that fails a WAF check but is not immediately blocked (e.g. one suspicious header, one marginally unusual path). Three violations means the traffic pattern is clearly hostile; the IP is blocked for the rest of the session.

Tip

Set block_threshold = 1 if you are under an active attack to block on the first violation. Return to 3 after the attack subsides to avoid blocking legitimate visitors with misconfigured clients.

#disable_waf_on_admin

Magento admin POST bodies can look like SQL injection or XSS to a naive WAF — product descriptions with <script> tags, category names with quotes, custom code blocks in CMS pages. Setting disable_waf_on_admin = true skips WAF checks on your admin path while keeping full protection everywhere else.

Warning

Never set admin_path to a value that matches a public-facing URL. If your admin URL contains customer-visible content, the WAF will be disabled for those pages.


#IP blocklist (blocklist.ini)

The file /etc/accelerate-guru/blocklist.ini is your manual IP/CIDR block list. It is hot-reloaded within 500 ms — edit it and blocks take effect immediately, no restart needed.

#Syntax

; Block a single IP
203.0.113.42

; Block an entire /24 subnet
198.51.100.0/24

; Block a /16 subnet (large range — use carefully)
192.0.2.0/16

; Allow-override: this IP is always allowed, even if its subnet is blocked
!203.0.113.1

; Comments start with ; or #
# This is also a comment

Rules are evaluated top-to-bottom. Allow-overrides (!) win over any block rule, regardless of order.

#Automatic blocking from WAF

When the WAF's block_threshold is reached, the IP is added to an in-memory runtime blocklist automatically. These automatic blocks are visible in the /stats-ag dashboard and can be cleared from there without editing any file.


#Bot detection

When enable_bot_detection = true, Accelerate Guru applies additional heuristics beyond pattern matching:

  1. User-agent analysis — known scraper UAs (Scrapy, curl with default headers, Python requests without Accept headers, etc.) are flagged.
  2. Header coherence — a real Chrome browser always sends specific headers in a specific order. Bots that fake User-Agent: Chrome but send headers in a different order are detected.
  3. TLS fingerprint (JA4) — every TLS client library has a unique fingerprint. Bots that set User-Agent: Mozilla/5.0 ... but connect with a Go or Python TLS stack are identified by the fingerprint mismatch.
  4. Behavioral rate patterns — human visitors access URLs in human-readable patterns (homepage → category → product). Scrapers access URLs in sorted or sequential patterns, often at machine speed.

Detected bots are either:

  • Blocked immediately if confidence is high.
  • Served a degraded response (e.g. cached HTML only, no personalisation) if the bot might be a legitimate search engine crawler.
  • Allowed through if the bot identifies as a known-good crawler (Googlebot, Bingbot) and the TLS fingerprint is consistent.

#Admin access protection

If you want to restrict access to the Magento admin panel to specific IPs (e.g. your office or VPN), use HTTP Basic Auth:

[security]
auth_mode  = 1          ; 1 = admin paths only, 2 = entire site
auth_user  = admin
auth_pass  = your-strong-password
admin_path = /admin_xyz123   ; use a custom admin URL for extra security

With auth_mode = 1, only requests to admin_path require the password. auth_mode = 2 gates the entire site — useful for staging environments.


#Reading WAF logs

The WAF log at /var/log/accelerate-guru/waf.log records every blocked request:

2026-05-08T12:34:56Z BLOCK ip=203.0.113.42 path=/wp-login.php reason=wordpress_probe ua="Go-http-client/1.1"
2026-05-08T12:34:57Z BLOCK ip=203.0.113.42 path=/admin reason=rate_limit count=32/60s
2026-05-08T12:35:01Z BLOCK ip=198.51.100.10 path=/catalog/product/view/id/123 reason=sql_injection pattern="' OR '1'='1"

Each line contains:

  • Timestamp (ISO 8601 UTC)
  • Action (BLOCK, CHALLENGE, ALLOW for near-misses when verbose logging is on)
  • IP address
  • Request path
  • Reason (rule that triggered)
  • User agent (truncated)

#Security dashboard

The /stats-ag dashboard includes a Security panel showing:

  • Top blocked IPs (last hour)
  • Block events per minute (sparkline)
  • Current runtime blocklist (with one-click unblock)
  • WAF rule hit counts (which rules are firing most)
  • Bot detection rate

#Best practices

  1. Use a non-default admin URL. Rename your Magento admin from /admin to something obscure (e.g. /admin_gXk7m2). Update admin_path in the config. This alone eliminates the majority of brute-force attempts.

  2. Enable auth_mode = 1 for admin access from untrusted networks. Use auth_mode = 2 on staging/UAT environments.

  3. Review your blocklist monthly. Remove IPs that were auto-blocked if you are not under active attack.

  4. Monitor WAF logs after deploying new Magento extensions. Third-party code sometimes triggers false positives with legitimate-looking inputs that match injection patterns.

  5. Set block_threshold = 5 for stores with global traffic from diverse IP ranges. More conservative thresholds occasionally block legitimate users on shared IPs (corporate NAT, mobile carriers).