100 MUD Security resources for MUD players

Configure Fail2Ban to monitor MUD log files for failed login attempts or rapid connection cycling to automatically drop IP addresses via iptables.

Never run the MUD binary as the root user. Create a dedicated service account with restricted shell access and limited filesystem permissions to the 'lib' and 'src' directories.

Disable password authentication in /etc/ssh/sshd_config and require SSH keys for all administrative access to the hosting environment.

Wrap the MUD process in a Docker container to isolate the game environment from the host OS, preventing directory traversal attacks from reaching system files.

Implement 'recent' module rules in iptables to limit new connections to the MUD port (typically 4000) to 5 per minute per IP to mitigate low-level DDoS and botting.

Use rsync or rclone to push encrypted copies of player files (pfiles) and the world database to a secondary cloud provider or off-site server every 6 hours.

Configure logrotate for game logs and implement a script to scan for keywords like 'segmentation fault' or 'SIGSEGV' to identify potential exploit attempts.

Modify /etc/sysctl.conf to enable TCP SYN cookies and disable ICMP redirects to harden the network stack against common spoofing and exhaustion attacks.

If using a separate port for administrative tools or web-based control panels, restrict access to a specific VPN subnet or IP whitelist.

Use ulimit or systemd service limits to restrict the maximum memory and CPU usage the MUD process can consume, preventing a crash from locking the entire server.

Search for all instances of 'strcpy', 'strcat', and 'gets' in the C source. Replace them with 'strncpy', 'strncat', and 'fgets' to enforce explicit buffer length limits.

Ensure that 'send_to_char' or 'sprintf' calls do not pass user-provided strings directly as the format argument; always use a static format string like '%s'.

Audit currency and XP addition functions. Implement checks to ensure that adding a value does not cause a variable to wrap around to a negative or zero value.

Verify that 'get' and 'drop' commands are atomic. Ensure that an item is removed from the source container before being added to the destination to prevent race conditions.

Run Cppcheck against the entire source directory to identify uninitialized variables, memory leaks, and out-of-bounds array accesses before compiling.

Run the MUD binary through Valgrind in a test environment to identify memory leaks and invalid writes that could be leveraged for remote code execution.

Compile the MUD with the '-fstack-protector-all' GCC flag to add canary values to the stack, causing the program to abort if a buffer overflow is detected.

Filter player input to remove or escape ANSI escape sequences that could be used to spoof system messages or clear the screens of other players.

Implement a 'wait state' or 'pulse' check on all player commands to prevent macro-based spamming and brute-force guessing of hidden command names.

Ensure the host OS has ASLR enabled (echo 2 > /proc/sys/kernel/randomize_va_space) to make it harder for attackers to predict memory addresses for exploits.

Replace legacy plaintext or DES-based password storage with a modern library like libxcrypt using the Blowfish (bcrypt) algorithm with a high cost factor.

Audit player files (pfiles) and remove unnecessary personally identifiable information such as real names or exact birthdates to reduce liability in case of a breach.

Force-enable 'snoop' or 'log' on all characters with administrative flags to create a permanent audit trail of all staff actions and world changes.

Refactor 'trust' levels to use a granular permission system. An 'area builder' should not have the permission to 'shutdown' the server or 'set' player stats.

Set pfile directory permissions to 700 (drwx------) so only the MUD service user can read player data, preventing other local users from seeing passwords.

Implement an idle-timeout for characters with administrative privileges to prevent hijacked sessions if a staff member leaves their terminal unattended.

If player emails are displayed in 'whois' or 'finger' commands, ensure they are only visible to administrators or are masked to prevent scraping by spambots.

Implement a basic TOTP (Google Authenticator) check for 'Imp' or 'God' level logins, requiring a 6-digit code before granting access to high-level commands.

Hard-code or config-lock specific administrative characters to only be accessible from known, static IP addresses or CIDR ranges.

If using MySQL or PostgreSQL for player data, enable transparent data encryption (TDE) to protect the data files on the physical disk.