How to set up layer 4/7 anti-DDoS protection for MU Online

MU Online servers are among the most attacked targets in the private server scene. The combination of fierce competition, disgruntled players, and the ease of hiring denial-of-service attacks for pocket change makes DDoS a constant threat rather than a distant hypothesis. A successful attack takes the server down, kicks players out at the most critical moment (an event, a launch), and destroys a reputation built over months. This advanced tutorial explains how to build defense in depth that covers both volumetric layer 4 attacks and sophisticated layer 7 attacks, always with examples that vary by provider/version.

The central idea you need to internalize is that there is no single magic solution. Effective anti-DDoS defense is built in layers, each covering a type of attack the other doesn't. Protecting only the website and forgetting the ConnectServer, or filtering packets in Windows while letting the datacenter link saturate, are mistakes that leave the door open. We'll build the defense from the outside in.

Prerequisites

To follow this guide you will need:

• Administrative access to the server (Windows Server 2016/2019/2022) that runs the ConnectServer, GameServer, and the emulator's other services.
• Access to your hosting or datacenter provider's panel, to check whether layer 4 mitigation is included or available for purchase.
• An account with a protection provider (Cloudflare, or a VPS provider with anti-DDoS scrubbing included). Names and limits vary by provider/version.
• Knowledge of which ports your emulator uses: typically the ConnectServer port, the GameServers' port range, and the web server port. Exact values vary by version.
• Access to your domain's DNS.
• A backup and a rollback plan before applying firewall rules, since a badly made rule can block your own players.

If the server is still being built, first follow the how to create a MU Online server walkthrough and only then armor the infrastructure with this guide.

Understanding the two types of attack

Before defending, you need to know what you're fighting. Attacks fall into two broad families, named after the layers of the OSI model.

Layer 4 (transport) — volumetric attacks. The goal is to clog the server's network link with a massive volume of packets: SYN flood, UDP flood, DNS/NTP amplification. The server never even processes the requests; the network cable itself saturates. The defense against this has to happen before the traffic reaches your server, on the provider's network (scrubbing).

Layer 7 (application) — exhaustion attacks. Here the attacker sends requests that look legitimate: login floods on the ConnectServer, repeated account creation attempts, HTTP floods on the website. The bandwidth volume is low, but each request consumes CPU and database. They are harder to distinguish from real players and require application intelligence to mitigate.

The attack vectors above are representative and the mix used in each attack varies.

Step 1: hide the server's real IP

This is the foundation of everything. If your server's real (origin) IP leaks, any proxy or mitigation you hire becomes useless, because the attacker simply sends the flood straight to the real IP, bypassing all protection. Therefore, the real IP must never appear publicly.

Common IP leak sources you need to close:

1. Old DNS records. A historical A record pointing to the real IP stays indexed in DNS history services. When migrating behind a proxy, swap the server's real IP for a new one, since the old one is already burned.
2. The server's own email. If the website sends password recovery emails directly from the server's IP, the email header reveals the IP. Use an external email service (SMTP relay).
3. Exposed subdomains. A direct.yourdomain.com or ftp.yourdomain.com pointing to the real IP gives it all away. Audit every DNS record.
4. The client file itself. The game client's ServerList or connection .dat contains the destination address. If it points to the real IP instead of the protected IP, hiding it in DNS is pointless. Point the client at the protected address.

After closing the leaks, configure the server's firewall to accept game traffic only from your mitigation provider's IPs, refusing direct connections from any other source. This ensures that, even if the IP leaks in the future, the direct attack is refused at the edge.

Step 2: layer 4 (volumetric) mitigation

Layer 4 cannot be defended inside your server, because by the time the packet reaches Windows, the link has already saturated. Mitigation has to happen upstream, on a network with the capacity to absorb and clean (scrub) the traffic. You have three main paths:

• VPS/dedicated provider with anti-DDoS included. Several providers offer layer 4 protection with example capacity in the range of hundreds of Gbps to a few Tbps of absorption. It's the simplest option: the scrubbing is transparent. Confirm the limits and whether there's a per-attack cost.
• GRE tunnel / protected IP. Some services provide a clean IP that receives the traffic, filters it, and forwards the legitimate portion to your server through a tunnel. It requires more advanced network configuration.
• Cloudflare Spectrum or equivalent for TCP. To protect game traffic (raw TCP from the ConnectServer and GameServer), a TCP proxy service with anti-DDoS is necessary, since the common web plan only covers HTTP/HTTPS.

The non-negotiable point: game traffic (the ConnectServer and GameServer ports) must be covered by layer 4 mitigation, not just the website. Many administrators protect only the website with a proxy and leave the game port exposed, and that's exactly where the attack gets in.

Step 3: TCP stack hardening on Windows Server

Even with upstream scrubbing, hardening the server adds a layer of defense against whatever gets through the filter and against smaller attacks. Some registry and firewall tweaks help. These are examples and ideal values vary by Windows version and load.

:: Example: enable SYN flood protection (SynAttackProtect)
:: Adjust via registry at HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
:: SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried
:: The exact values vary by Windows Server version

In the Windows firewall, create rules that:

1. Allow inbound traffic only on the ports actually used (ConnectServer, GameServer range, web). Close everything else.
2. Restrict administrative ports (RDP, SQL Server) to specific administration IPs, never open to the world. Open RDP is a vector for both intrusion and attack.
3. Limit the rate of new connections per IP when the emulator or an application firewall allows it.

# Example: restrict RDP to an administration IP
New-NetFirewallRule -DisplayName "RDP Admin Only" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress YOUR_ADMIN_IP -Action Allow

Step 4: layer 7 defense on the ConnectServer and login

Layer 7 attacks on MU usually target the ConnectServer with connection floods and the login/account creation routine, which touch the database. Because the bandwidth volume is low, volumetric scrubbing doesn't detect them. The defense here is application intelligence:

• Per-IP rate-limit. Limit the number of login attempts and new connections per IP within a time window. A legitimate player doesn't try to log in 200 times per minute. The example limit varies by emulator version and firewall tool.
• CAPTCHA on registration and web login. Prevents automated mass account creation that overloads the database. Use a modern challenge solution.
• Connection queue. Some emulators or proxies support a queue that absorbs spikes of new connections without dropping the service.
• Optional geographic blocking. If the server only serves Brazil, restricting connections to national IP ranges drastically reduces the attack surface. Do it carefully so you don't block legitimate players using a VPN.

Step 5: protecting the website and web application

The server's website (registration, ranking, VIP shop) is the easiest and most visible layer 7 target. Put it behind a reverse proxy with a WAF (Web Application Firewall) and layer 7 DDoS protection. Essential settings:

• An actionable "under attack" mode. A button that, when activated during an attack, presents a challenge to every visitor before granting access.
• Rate-limit rules on sensitive endpoints: login, registration, password recovery, and payment endpoints.
• Aggressive caching of static pages (ranking, news) so a flood never reaches PHP and the database.
• Hide technologies. Remove headers that reveal web server and framework versions, which guide the attacker.

Step 6: monitoring and incident response

Defense without visibility is blind. You need to know you're under attack before the players complain. Set up a minimum of observability:

• Bandwidth and CPU usage alerts that fire when they exceed an example threshold.
• An external uptime monitor that tests the ConnectServer and the website every few minutes from outside the network.
• ConnectServer connection logs to identify flood patterns and recurring IPs.
• A written runbook: who does what when the attack starts (activate under attack mode, contact the scrubbing provider's support, communicate with the community).

Communication with the community during an attack is underrated. A transparent announcement ("we're under attack, working on mitigation") preserves trust far more than silence.

Common errors and fixes

Launch checklist

• Server's real IP changed and the old one discarded
• All DNS records audited without leaking the origin IP
• Transactional email moved to an external SMTP relay
• Game client pointing at the protected address, not the real IP
• Firewall accepting game traffic only from the mitigation provider's IPs
• Layer 4 mitigation confirmed for the game ports (not just the website)
• RDP and SQL Server restricted to administration IPs
• Login/connection rate-limit configured on the ConnectServer
• CAPTCHA active on registration and web login
• Website behind a WAF with "under attack" mode tested
• Static page caching enabled on the website
• Bandwidth and CPU alerts configured
• External uptime monitor active on the game and the website
• Incident response runbook written and shared with the team

Conclusion

Protecting a MU Online server against DDoS isn't buying a single service and forgetting about it. It's building defense in depth: hiding the real IP, hiring volumetric layer 4 mitigation that covers game traffic, hardening the Windows TCP stack, applying rate-limit and CAPTCHA against layer 7 attacks, and armoring the website with a WAF. Each layer covers a flank the other leaves open. The most common and most fatal mistake is protecting only the website and forgetting that the ConnectServer port is where the attack really hurts. With the layered architecture in this guide, calibrated to your provider's limits (which vary by provider/version), your server survives the attacks that take down the unprepared competition.

Frequently asked questions