How to segregate your MU Online server's database network

The database is the most critical asset of any private MU Online server: it holds accounts, passwords (hashed), characters, items, transaction history, and moderation logs. A database leak or compromise isn't just a technical incident — it's the end of the community's trust in the server. Segregating the database network means treating it with a level of isolation and control above the rest of the infrastructure, even if the overall network is already segmented. This tutorial details how to do this in practice: network isolation, least-privilege service accounts, encryption in transit, and secure backup.

Why the database deserves extra isolation

Even in an already-segmented infrastructure (public ConnectServer, internal GameServer, internal database), the database is usually the only component where a compromise has a catastrophic, irreversible impact — items and Zen can be recreated, but leaked account data (even hashed) and purchase history cannot. That's why the database justifies an extra layer: its own network, access accounts more restricted than those used by the GameServer for other purposes, and stricter auditing of who accesses it and when.

Isolating the database in its own subnet

Even inside an already-segmented VPC, put the database in a dedicated subnet, with no outbound route to the internet (egress blocked by default, except for explicitly allowed backup destinations):

VPC: 10.0.0.0/16
├── Public Subnet:       10.0.1.0/24
├── Application Subnet:  10.0.2.0/24  → GameServer
└── Database Subnet:     10.0.3.0/24  → MSSQL/MySQL (no route to the internet)

The absence of an outbound route to the internet means that even if the database is compromised, an attacker can't easily exfiltrate data directly outward — they would first need to compromise another component with an outbound route, adding an extra layer of difficulty.

Database-specific firewall rules

No rule should ever open the database port to 0.0.0.0/0 (any source) — this is the most common and most severe misconfiguration found in compromised private servers.

Least-privilege service accounts

A frequent mistake is using the database admin account (sa on MSSQL, root on MySQL) directly in the GameServer's configuration. Instead, create dedicated service accounts per purpose:

-- MSSQL: service account for the GameServer, with specific permissions
CREATE LOGIN gameserver_svc WITH PASSWORD = 'StrongRandomPassword!2026';
CREATE USER gameserver_svc FOR LOGIN gameserver_svc;
ALTER ROLE db_datareader ADD MEMBER gameserver_svc;
ALTER ROLE db_datawriter ADD MEMBER gameserver_svc;
-- No DROP, ALTER, or server control permission

-- Separate, read-only account for the site/ranking
CREATE LOGIN site_readonly WITH PASSWORD = 'AnotherStrongPassword!2026';
CREATE USER site_readonly FOR LOGIN site_readonly;
ALTER ROLE db_datareader ADD MEMBER site_readonly;

With this separation, even if the site's credential leaks (for example, through a CMS vulnerability), the attacker can only read data, never alter characters, items, or Zen balance.

Differentiating application and administration accounts

Never reuse the same credential across different purposes — this eliminates the ability to trace which component performed which action in the event of an incident.

Encrypting the connection in transit

Enable TLS on the connection between the GameServer/site and the database, especially if the components aren't on the same physical machine. For MSSQL, this is configured in SQL Server Configuration Manager (Force Encryption) and in the GameServer's connection string:

[Database]
Server=10.0.3.10
Database=MuOnline
User=gameserver_svc
Password=StrongRandomPassword!2026
Encrypt=yes
TrustServerCertificate=no

For MySQL, use require_secure_transport=ON in the server configuration and ssl-mode=REQUIRED in the client connection string. TLS's performance cost is low compared to the risk of credentials and data traveling in plain text within the internal network.

Secure, isolated backup

The backup job should run within the same private segment as the database, never pulled from outside via an inbound connection. The recommended flow:

1. The database server (or an internal backup server in the same segment) runs the backup locally, generating the .bak/dump file.
2. An outbound (egress) firewall rule, not an inbound one, allows that server to send the file to an external destination (cloud storage, another datacenter).
3. The external destination has its own access control (encryption at rest, versioning, retention).

#!/bin/bash
# Runs locally within the database segment
BACKUP_FILE="/backups/mu_$(date +%Y%m%d).bak"
sqlcmd -S localhost -Q "BACKUP DATABASE MuOnline TO DISK='$BACKUP_FILE'"

# Send to external storage via egress opened specifically for this destination
aws s3 cp "$BACKUP_FILE" s3://mu-backups-private/ --sse AES256

Never open an inbound port on the database segment just to let an external script "pull" the backup — this reintroduces exactly the exposure segregation was meant to eliminate.

Auditing database access

Enable logging of connections and sensitive queries (login, DDL, permission changes) on the database itself:

-- MSSQL: login auditing
CREATE SERVER AUDIT MuServerAudit
TO FILE (FILEPATH = 'C:\AuditLogs\')
WITH (ON_FAILURE = CONTINUE);

CREATE SERVER AUDIT SPECIFICATION MuLoginAudit
FOR SERVER AUDIT MuServerAudit
ADD (FAILED_LOGIN_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP)
WITH (STATE = ON);

Review these logs periodically (ideally with automatic alerting) to detect login attempts with unexpected accounts or from unusual IPs.

Separating environments (production, staging, development)

Never share the same database between production and test environments. A staging database should run in its own subnet, with synthetic data or an anonymized copy of production (no real passwords, no payment data), preventing an error in a test script from affecting real players.

Common errors and fixes

Database network segregation checklist

• Database in its own subnet, with no default outbound route to the internet.
• Firewall allowing only specific sources (GameServer, backup, read-only site).
• Least-privilege service accounts, separated by purpose.
• TLS enabled on the connection between the application and the database.
• Backup run locally within the segment, sent via controlled egress.
• Login and sensitive action auditing enabled on the database.
• Production, staging, and development environments fully separated.

With the database properly isolated, also review the segmentation of the other infrastructure components — see the GameServer network segmentation tutorial to make sure the whole chain, from the client to the most sensitive data, is protected consistently.

Frequently asked questions