I'm currently working on a MUD server, which I encourage everyone who hasn't noticed the post in Your Announcements to check out. Now, as much as I've worked on other aspects of the project, I still haven't been able to find out much about how dangerous it is to leave a port open on my personal computer so others can connect. Perhaps it might help to explain my particular setup first. I'm using a cable modem, so I've got a static IP. I'd be hosting a MUD on one of two computers on the network hooked up to a router. I've successfully set things up to forward a port so that others outside the network can telnet to my IP and connect to the MUD fine. The only question I have, is does doing this also allow people to do anything malicious? I've read a lot of stuff that makes me pretty nervous about the situation but in all honesty I can't seem to see where they might be able to do something harmful. Is there some way crackers can use the open port to connect to something other than my MUD server? What can be done about that if so? Or is this danger regarding open ports more referring to other services, and not applications such as a server I've written? -Arek the Absolute

I wouldn't worry (much) about external users getting access to internal ports. Instead your main problem will probably be bugs (buffer overflows..) in the MUD server.
So be careful about the user that's running the server, eg. only allow the bare minimum of priviligies.

There's virtually no danger. There's nothing inherently dangerous about open ports as such, just the services that have opened the port. With regards to a mud server, you just have to watch for 2 things really:

1) make sure you bounds check the input you read from the socket. Most servers tend to use read or recv into a fixed length buffer, so as long as you're keeping within that buffer's size you're fine.

2) make sure the code contains no calls to process or shell functions that would allow a user to try 'creative' filenames or the like. A lot of muds have security problems where they allow a user to perform an operation on mud files (eg. showing a log file on the user's screen) but the user is able to put in a fake name to gain access to other files. Doublecheck any code that accesses local files or executes processes locally.

I would have to agree with the risks on ports. Its limited to what the "executable" can do with commands and responses. Buffer over runs are one of those types of issues. However implementing anything that might expose functionality that gains access to file system or user accounts on the system. This is more so when the user that the process is running as has privilages that can gain access to them.

This is why IIS is a security risk when ran as LocalService or any other user. IIS 6 fixes this issue but its still broken on win2k.

That page is just a description of the regular telnet service, which some machines ship enabled. If a user has a valid user name and password, they can log into your machine, if your machine runs the telnet service. The main security failing with telnet is that it's not encrypted, so someone with a network sniffer can snarf that password out of the network as it's being typed.

If you use the telnet protocol, but your MUD server is not the telnet service, then that page doesn't apply to you at all. What the others have said still holds true, though: make sure there's no way for the user to system() or fork() or read arbitrarily-named files. Validity check ALL input data ALWAYS. Make sure not to overrun any buffers. Make sure to force-terminate all C-style strings with a 0 at the end of the array, EVERYTIME. If you have no bugs, then opening your service to the public isn't dangerous.

Of course, if your service becomes popular, then the network and machine load may cause other problems for you, but that's a separate issue.

The usual danger of leaving ports open is that a trojan or rogue program will try and send data out / bring data in through open ports. Many of the recent Microsoft specific trojans installed a listner on a few port numbers which would allow a backdoor into your machine (Sasser, FTP server on port 5554 etc). Closing ports you are not using is a good security step.

Jay