04 Jun, 2010, Sorressean wrote in the 1st comment:
Votes: 0
I was looking to set up a free mud hosting setup with my new server.

I'm worried about the following:
1) If some angry pissed off script kiddy gets shell, what he/she could do could cause a lot of problems. What sort of precautions are generally taken to prevent such things from happening? I would like to log outbound, but that could cause problems with size; logging outbound web requests if the mud scrapes or does anything else that could cause false positives. Besides that, just limiting them to resources should be enough I'd think, and that can be done through ulimit if I'm not mistaken. I would also like to allow only certain users inbound ports so it doesn't turn into a huge mess with joe stealing tommys favorite port.

Comments and ideas and etc would be welcome.

Thanks,
10 Jun, 2010, ProjectMoon wrote in the 2nd comment:
Votes: 0
-Disable external SSH if possible. If not possible, move it to a different port and accept only public key authentication.
-Disable any other service not essential to the operation of the server.
-Block all non-essential ports.
-Make sure the MUD and/or OS you are running is protected against buffer overflow.
-Do not run the MUD as root. The MUD user should have minimal permissions.
10 Jun, 2010, David Haley wrote in the 3rd comment:
Votes: 0
Quote
-Disable external SSH if possible. If not possible, move it to a different port and accept only public key authentication.

Meh. Changing the port can be very annoying for various reasons, for example if you need to ssh in from a network that allows outgoing connections on the standard ssh port but not other ports. Especially if you're only accepting public key authentication, there is relatively little reason to change the port unless you're extraordinarily paranoid.

But yes, you should be careful about dictionary attacks. Try using something like sshd_sentry. You might be interested in this hosts.deny file, which is a list of IP addresses that have attacked our server with repeated connection attempts (almost all of them stupid dictionary attacks). That file is kept up to date automatically, so you could in principle download it periodically and merge it into your own hosts.deny file. We use sshd_sentry to generate that list of IP addresses.


I agree with the other pieces of advice.
10 Jun, 2010, Mudder wrote in the 4th comment:
Votes: 0
What's a dictionary attack?
10 Jun, 2010, Orrin wrote in the 5th comment:
Votes: 0
Mudder said:
What's a dictionary attack?

This.
10 Jun, 2010, quixadhal wrote in the 6th comment:
Votes: 0
You shouldn't need to disable ssh. SSH is probably more secure than just about any other bit of software you have running. I would limit it to accept ONLY public-key authentication though, and also disable root logins.

It's also not a bad idea to setup chroot jails for the less-than-trusted public who will be getting shell access. Firewalling basic services from internal use is also a good idea. If you block outgoing SMTP traffic, they can't use your shell to bulk email, for example.

If I were going to do this, I'd probably consider setting up virtual machines for each client. That avoids many of the issues of trying to chroot jail people, but still keeps them isolated. Restrictions on the host OS can't easily be overridden since they shouldn't be able to get to the host, and you can restrict each VM further as needed. It's also the most fair for CPU sharing, since they can (try) to use whatever they want, it will just slow down.
10 Jun, 2010, ProjectMoon wrote in the 7th comment:
Votes: 0
Well the disabling SSH thing is just a "no reason not to" thing. Unless you are giving out remote shell access, then there is no reason to have SSH running.
10 Jun, 2010, David Haley wrote in the 8th comment:
Votes: 0
Presumably you need to ssh in yourself in order to administer it… I suppose that if you always had physical access to the box, you wouldn't need SSH, but it's relatively unusual to be in such a situation.
10 Jun, 2010, ProjectMoon wrote in the 9th comment:
Votes: 0
David Haley said:
Presumably you need to ssh in yourself in order to administer it… I suppose that if you always had physical access to the box, you wouldn't need SSH, but it's relatively unusual to be in such a situation.


Maybe a more appropriate way of phrasing it is "internet access." In that case, though, locking down SSH would be covered by router/firewall.
10 Jun, 2010, David Haley wrote in the 10th comment:
Votes: 0
No, I meant actual physical access. You said that you don't need SSH running, but if you turn it off, you can only administer the machine from a keyboard/monitor hooked up directly to that machine. In particular you cannot administer it from elsewhere on your local network. This has little to do with giving remote shell access to users (which could include yourself), in which case it would be internet access.

But yes, the security would be on the router/firewall level, at which point it doesn't really matter if you disable it as long as it's invisible to the external world – assuming of course that your firewall actually works. :wink:
(If the service itself were insecure, you might not want people to use the service from the server itself – although in ssh's case this is relatively unlikely.)
10 Jun, 2010, ProjectMoon wrote in the 11th comment:
Votes: 0
David Haley said:
No, I meant actual physical access. You said that you don't need SSH running, but if you turn it off, you can only administer the machine from a keyboard/monitor hooked up directly to that machine. In particular you cannot administer it from elsewhere on your local network. This has little to do with giving remote shell access to users (which could include yourself), in which case it would be internet access.

But yes, the security would be on the router/firewall level, at which point it doesn't really matter if you disable it as long as it's invisible to the external world – assuming of course that your firewall actually works. :wink:
(If the service itself were insecure, you might not want people to use the service from the server itself – although in ssh's case this is relatively unlikely.)


When I was talking about "it," I was talking about my original statement of "giving out SSH access." Hurrah ambiguity on the internet!
10 Jun, 2010, David Haley wrote in the 12th comment:
Votes: 0
Oh, sorry. I thought you were talking about physical vs. internet access. :smile: Yeah, I agree with you.
11 Jun, 2010, Noplex wrote in the 13th comment:
Votes: 0
I would worry more about giving them access to your actual game data, code, etc, unless you seriously trust who you are working with. When I was hosting a game on my own machine we gave programmers their own instance of the game and allowed them to go wild. I was the only person who could manually patch the actual game code and the builder's had symbolic links to most of the configuration files. Mind you, this was back in the day when (most) of the Realms of Despair areas got up on the Internet.

Nowadays I do not really care about sharing code. I would just make sure that you do not allow them to access anything else on the host that may be sensitive. I my game on a separate Linux box in the basement of my house, but I would suggest now looking into Virtual Box, Xen, or some other means of running a virtual machine simply for the security aspect itself.

But generally I agree that SSH is probably the most secure thing running on your machine. Your code, which is not running on damn near every Unix machine in the world, is probably the least secure along with any web application that may be installed. If you are running a web application that has access to the same MySQL database as your game be very careful, because some of the simplest attacks can be done by inserting some SQL into a search field on a poorly implemented PHP web application. I would suggest that the MySQL user you provision for both your game and web application does not have drop or create access to the tables.
0.0/13