How to monitor intrusion attempts on your MU Online server

MU Online private servers with an active economy — rare items, premium currency, contested rankings — are real targets for intrusion attempts, ranging from simple brute force on admin accounts to SQL injection in website forms and exploitation of vulnerabilities in the admin panel. Unlike lag or a full disk, a successful breach can mean item duplication, stolen player accounts, or even full access to the server. This tutorial covers how to monitor access logs (SSH, web panel, MySQL), set up automatic defenses with fail2ban and a firewall, identify signs of compromise, and build an incident response plan to act fast when something falls outside the norm.

Why MU Online servers are a target

A popular private server moves a real economy (Zen sales, rare items, VIP), which attracts everyone from script kiddies testing known exploits on generic panels to individuals directly motivated to sabotage competing servers. The attack surface includes the web panel (account login, shop, signup), the server's admin SSH/RDP, and MySQL itself if incorrectly exposed to the internet.

Most common attack surfaces

Step 1 — Close unnecessary ports with a firewall

Before monitoring, reduce the attack surface. Expose publicly only the ports that are actually necessary (ConnectServer, web panel over HTTPS), and keep SSH and MySQL closed or restricted by IP.

# Example with ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp   # restrict by IP if possible
sudo ufw allow 443/tcp
sudo ufw allow 44405/tcp  # default ConnectServer port, adjust to your emulator
sudo ufw deny 3306/tcp  # MySQL never exposed publicly
sudo ufw enable

Step 2 — Install and configure fail2ban against brute force

Fail2ban monitors authentication logs and automatically bans IPs after a number of failed attempts in a short interval:

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
findtime = 600
bantime = 3600

[nginx-limit-req]
enabled = true

For the web panel, create a custom filter pointing to your system's failed login attempt log (Laravel, plain PHP, etc.), banning IPs that exceed login attempts within minutes.

Step 3 — Monitor SSH and web panel logs

Regularly review (or automate with a script) authentication logs looking for anomalous patterns: many attempts in a short time, attempts at unusual hours, or attempts coming from countries outside the server's target audience.

# View recent failed SSH login attempts
sudo grep "Failed password" /var/log/auth.log | tail -50

# Count attempts per IP
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

Step 4 — Protect the web panel against SQL injection

Confirm that all the panel's code uses prepared statements/parameterized queries instead of direct string concatenation for SQL — the most common cause of SQL injection in custom-built MU Online panels. Review especially the login, signup, password recovery, and shop forms, which are the most targeted.

// Wrong — vulnerable to SQL injection
$query = "SELECT * FROM MEMB_INFO WHERE memb___id = '$username'";

// Correct — prepared statement
$stmt = $pdo->prepare("SELECT * FROM MEMB_INFO WHERE memb___id = ?");
$stmt->execute([$username]);

Step 5 — Restrict and audit GM accounts

Game Master accounts have full power over items and characters, making them the most valuable target of any intrusion. Use strong, unique passwords, two-factor authentication on the panel if available, and keep an audit log of every GM action (item creation, teleport, ban) to detect misuse quickly.

Step 6 — Monitor MySQL for anomalous access

Even with MySQL closed off from the internet, monitor connection attempts from unusual internal IPs and queries outside the expected pattern (for example, mass updates to the item table outside a scheduled event). Enable MySQL's general log temporarily during an investigation, but avoid leaving it on permanently due to the impact on performance and disk space.

-- Temporarily enable the general log for investigation
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

Step 7 — Identify signs of a compromise that already happened

Some signs indicate an intrusion already happened, even without a real-time alert: GM accounts created without the team's knowledge, Zen or rare items duplicated on specific accounts with no corresponding event log, unknown processes consuming CPU on the server, and SSH access entries at times outside the team's schedule.

Step 8 — Build an incident response plan

Have a documented plan before the intrusion happens, not during the panic. At minimum, define: who has authority to isolate the server from the network, how to preserve logs before any restart, and how to communicate with the community transparently without exposing details that could help the attacker.

1. Isolate the server from the network (or block the source IP in the firewall).
2. Preserve current logs by copying them before any restart.
3. Rotate all admin credentials (SSH, MySQL, panel, GM).
4. Investigate the extent of the damage (duplicated items, affected accounts).
5. Restore from an intact backup predating the intrusion, if needed.
6. Communicate with the community transparently about what happened and the fixes applied.

Common errors and fixes

Security and intrusion monitoring checklist

• Firewall configured, exposing only the necessary ports.
• Fail2ban active for SSH and the web panel.
• Web panel reviewed against SQL injection (prepared statements).
• GM accounts with strong passwords, 2FA, and audit logging.
• MySQL never exposed directly to the internet.
• Signs of compromise reviewed periodically.
• Incident response plan documented and known by the team.

With the basic defenses monitored and active, the next step is to integrate these security alerts into the same dashboard where you track CPU, disk, and online players, for a single view of server health — review the MU Online server creation tutorial to make sure your infrastructure foundation is built with these protections in mind from the start.

Frequently asked questions