Securing a MOO

...or MUD, MUSE, MUSH, etc.

Target audience: An experience unix admin running a dedicated moo. Just mentioning the idea may be enough to spark the idea and you can do it on your own, but be sure to read the security section below.
This isn't for everyone. If it sounds confusing, then it's probably not worth trying to do this.

I recently discovered an archived copy of my old MOO from college. Having a cable modem, I thought, why not just host it on my Linux box and let my friends who used to play connect to it for some reminiscing. Then I thought about security. While it doesn't allow interaction with the host environment (my Linux box would still be safe), logins are done via telnet so the character passwords are vulnerable to sniffing.

So I set out to secure it while being as compatible as possible and not wanting to put too much effort into it. Since I'm not planning on keeping it up, just a quick "hey guys, remember this?"

The obvious direction is to use SSH. The basic idea is that users could SSH to my system and from there, telnet to localhost where they could login. Here's the steps I took:

1. Create a new user (I chose "moo"), make the password simple (e.g. "moo").
2. Change the login shell for moo to be /usr/bin/mooproxy
3. Save the code below to "mooproxy.c"
4. Compile it using: gcc -s -o mooproxy mooproxy.c
5. Move the new binary to /usr/bin/

/* mooproxy.c */
#include
int main(int argc, char *argv[]){
execl("/usr/bin/telnet", "telnet", "localhost", "7777", NULL);
}

Notes:

• Be sure to change the port number to match where your moo is running.
• Change /usr/bin/telnet if your telnet binary is located somewhere else.

Security:

• Set your firewall to block the moo port (7777 in my case) as the users will come in via SSH.
• Set your SSH server to disable port forwarding, SCP and SFTP access. ssh.com's server and Vandyke's Vshell server both allow per-user restrictions on port forwarding, but OpenSSH (the default for most Linux systems) does not. Leaving port forwarding enabled for a guest user is worse than the problem we're trying to solve here, so don't do it.

Disadvantage:

• Customized MUD clients won't work.
• Mis-configuring sshd can compromize the security of your whole network.

Advantages:

• Character passwords are secure.
• MOO server doesn't need changed, it doesn't even need restarting.

Variations on the idea:
If you're insistent upon running OpenSSH and want to allow port forwarding for yourself, but not the moo account, there are other options. You could pick an alternate port on your firewall and forward that to sshd on a different machine. That machine can have "AllowTcpForwarding no" in its sshd_config. It may even be possible to run two sshd's on the same machine using two different config files and listening on two different ports, but I've not tried that.

The only reason the C code is needed is because you can't put arguments to the login shell in the password file. Telnet needs at least one argument and in this case, two. Running telnet with no args would leave them at a "telnet>" prompt where they could then telnet to any TCP port on any system on your network... a bad idea. Using a shell script as the login shell also falls into the bad idea category. If you've got a suggestion on another way around having to compile the C code above, let me know.

If you have an sshd that allows very fine control of port forwarding, it's possible to allow the moo user to forward just to that one port. This would have the advantage of allowing the user the use of their preferred mud client, but at the cost of making it less user-friendly. Most sshd's aren't so configurable anyway.

Have I missed something? Do you have a suggestion for an improvement? Drop me a note.