Web Application Firewall (WAF) to protect your MU Online server's site

The site of an MU Online server — with account login, ranking, donation shop, and admin panel — is one of the most targeted assets by competitors and malicious players. A Web Application Firewall (WAF) is the layer that sits in front of that application and filters malicious requests before they reach your code: SQL injection attempts against the login form, XSS in the site's chat, brute force against the admin area, and bots scraping the ranking to clone your server. This tutorial shows how to plan, configure, and test a WAF end to end, both cloud-based and self-managed.

Why an MU site needs a dedicated WAF

Unlike a static blog, an MU server's site has multiple sensitive surfaces: the account registration form, login (often shared with the game), the donation code redemption panel, a ranking API consumed by third parties, and sometimes a publicly exposed admin panel. Each of these surfaces is a different attack vector, and a well-configured WAF covers all of them from a single control point, without needing to change the application code every time a new threat is discovered.

Types of attacks a WAF blocks

Choosing between a cloud WAF and a self-managed one

For most MU servers, starting with Cloudflare (even on the free plan) already covers a large share of automated attacks, leaving ModSecurity as a complement for rules very specific to your panel.

Step 1 — Put the domain behind a proxy with a WAF

If you haven't already, point the domain's DNS to Cloudflare (or an equivalent provider) and enable the proxy (orange cloud). This already hides the web server's real IP and enables the default managed WAF. Confirm the SSL certificate is set to Full (strict) mode, not just Flexible, to avoid redirect loops and keep end-to-end encryption.

Step 2 — Enable the managed rule set (OWASP)

In Cloudflare's security panel (or an equivalent WAF), enable the managed rule set based on the OWASP Core Rule Set. Run it in log mode for 3 to 7 days initially, observing which requests would be blocked, before switching to active blocking mode — this avoids taking down legitimate traffic due to false positives.

Step 3 — Create custom rules for sensitive endpoints

Generic rules don't cover everything. Add rules specific to your MU site:

# Example rule (Cloudflare Rules syntax)
(http.request.uri.path eq "/login" and rate(1m) > 20) => Block
(http.request.uri.path contains "/api/ranking" and rate(1m) > 60) => Challenge
(http.request.uri.path eq "/admin" and ip.geoip.country ne "BR") => Block

• Login: rate limit per IP in a short window, blocking brute force.
• Ranking API: a challenge (captcha) above a volume that only a bot would reach.
• Admin panel: geographic or fixed-IP restriction, if the team is a known set of people.

Step 4 — Configure ModSecurity as a complementary layer (optional)

For those self-hosting the web server (Nginx/Apache), ModSecurity with the OWASP Core Rule Set adds a second layer, useful even with Cloudflare in front (defense in depth):

# nginx.conf — enabling ModSecurity
load_module modules/ngx_http_modsecurity_module.so;

server {
    listen 443 ssl;
    server_name panel.yourserver.com;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location /admin {
        modsecurity_rules '
            SecRuleEngine On
            SecRule REQUEST_URI "@streq /admin" "id:1001,phase:1,deny,status:403,chain"
            SecRule REMOTE_ADDR "!@ipMatch 203.0.113.10"
        ';
    }
}

This example blocks any IP other than the team's fixed IP from accessing /admin, even if the request passes the generic rules.

Step 5 — Protect the donation/payment form

The donation panel processes sensitive data even when the payment itself is handled by an external gateway (PagSeguro, Mercado Pago). Make sure the WAF validates: maximum field length, expected character types (a name field shouldn't accept HTML tags), and aggressive rate limiting on the payment confirmation endpoint, which is a common target for replay-based fraud attempts.

Step 6 — Test the WAF without breaking the site

1. Run a basic scan with a security testing tool (e.g., OWASP ZAP) pointed at a staging environment, never production without warning.
2. Manually send a harmless test payload (' OR '1'='1 in a search field) and confirm it gets blocked.
3. Test the normal player flow (registration, login, code redemption) to make sure no legitimate rule got blocked by mistake.
4. Monitor the WAF's event dashboard for the first 48 hours after enabling blocking mode.

Adjusting false positives

Ongoing monitoring

Set up alerts (email or Discord webhook) for when the WAF blocks an abnormal volume of requests in a short period — this often signals an ongoing attack, not just background noise. Review the WAF's event log weekly during the first weeks after the server launches, the period of highest exposure to attacks from competitors.

Common errors and fixes

WAF security checklist

• Domain behind a proxy with SSL Full (strict).
• OWASP rule set enabled, tested in log mode before blocking.
• Custom rules for login, ranking, and the admin panel.
• ModSecurity as a complementary layer (if self-managed).
• Donation form with validation and rate limiting.
• Malicious payload tests performed in staging.
• Anomalous-block alerts configured.
• WAF event log reviewed weekly at launch.

With the WAF active and protecting the site, the natural next step is to review the security of the infrastructure behind it — the GameServer and database itself — to close the loop on complete protection, as described in the MU Online server creation tutorial.

Frequently asked questions