Hosting: 10 Things To Know

Alzie

I host a lot of things. At this time, 4 websites, 4 games, SSH Service, FTP Server, MySQL DB, DLNA Media Server and even a local git repository. Apache is the tool of choice, which some people will run away from and others will embrace. There are other options. Here are 10 things no one will tell you but everyone should know.

Rotate your DB logs
Everyone talks about rotating your server logs. Everyone talks about rotating your PHP or apache logs. No one talks about the fact that databases store a binary, per transaction log. They certainly don't tell you that this log can sometimes take up gigabytes of space given any query which has enough data in it or that runs off unattended or stopped. Contrary to popular belief, there is nothing to lose by deleting them or to gain by keeping them.

In *Nix, there are two locations:
/var/log/mysqld.log
/var/lib/mysql/ib_logfile*

In Windows, they are found:
%ALLUSERSPROFILE%\MySQL\MySQL Server X.Y\ - XP, Server 2003
%PROGRAMDATA%\MySQL\MySQL Server X.Y\ - Everything Else
Where X.Y are your version. They have the same name as the ones above.

Use Non Standard Ports
One of the easiest and most overlooked ways to prevent a large majority of intrusion attempts is to simply use a different port than what is normally used. If you want to host SSH, then don't use 22. That will stop a good chunk of people trying to get into your server without permission. Preferably, host using high numbers. Most ports between 1 and 9000 hold standard uses even if they aren't defined by the standards committee. So picking a number higher than 9000 is the best.
Don't allow root logins on SSH
If you are going to allow SSH logins, don't allow root logins on SSH. Let's say that again. Don't allow root logins on SSH. One more time. Don't allow root logins on SSH. This is easy to set up because it's a simple toggle in the sshd.conf file present in both Nix and Windows.
FTP is dangerous
FTP is quite possibly the most innocuous and dangerous thing you will ever host. Then again, so is any web system which lets users upload files to your server. If you are going to host FTP, do not use the default port ever and make sure that the user can only ever access their own home folder. If you use filezilla FTP server, it is easy to set a home folder and lock a person to that folder using the GUI provided. Be wary when allowing anyone access to uploading files. I recommend not allowing them to set files +x.
Virtual Hosts are actually easy
Virtual Host definitions for multiple websites and hosts may seem ambiguous but as it turns out, they're really not. I know lots of people struggle with them, but allow me to demystify them. At their base form, a virtual host definition only needs this much information.
<VirtualHost *:80> - This tells apache we want to serve this site to any ip address that connects on port 80. Unless you run a server that differentiates hosts based on ip, you will never the change the *.
ServerName <text> - Mostly likely, you differentiate based on host name. This is where you put that host name. So if your host name was www.vertinext.com then you would put www.vertinext.com where <text> is.
Optional: ServerAlias <text> - This is for aliases. A good rule of thumb is to put your address without www here. It can also match wildcards (*). This can be useful for matching subdomains if you have several for the same host but not separate websites for those domains. It can also be used to allow you to access it locally by a keyword, such as by putting in mysite in your web browser on your local machine.

And that's all. So at most you would have this.

<VirtualHost *:80>
   ServerName www.vertinext.com
   ServerAlias vertinext.com
</VirtualHost>

Use Prepared Statements
If you're going to write SQL, whether it is in softcode or any other language, write using prepared statements. While you can't achieve this in every language (You usually can using the native client drivers), you can usually mirror it. In softcode, you can call the sql statements using U, which is close as you can get to prepared statements as they're essentially paramaterized statements, which is what python does. This is important for several reasons. The first is that you always know where the input is going, the second is that the input is interpreted as that specific type (especially when using sqlescape in softcode and if you want to prevent softcode in the input use escape or decompose) which means it won't run it as interpreted code. Better yet, if you're going to use a sql statement a lot, create them as procedures on the server itself. Procedures will only ever interpret their input as just that, input. This assumes that you have created your stored procedures the right way and not by stuffing SQL statements without parameters into them. See http://blogs.msdn.com/b/brian_swan/archive/2011/02/16/do-stored-procedures-protect-against-sql-injection.aspx .

For those reading ahead, yes, that means that technically, you don't need to write any SQL on the mush, you could write it all as stored procedures and simply call sql(CALL <procedure>(input)) in game.

If you store passwords as plain text you deserve to die
Does that seem harsh? Well it is and you should feel bad if you've done this. Encryption is ruefully easy now. There is no excuse. Decide what data should be encrypted and encrypt it in the database. Mostly, the data that should be encrypted is data that users wouldn't want released to others. This includes passwords (Since they may have reused a password - because no one does that right), email addresses (because believe it or not, you can use an email address to find people) and any data relating to real names and locations. In PHP, encryption is as simple as using Defuse in the following way: https://github.com/defuse/php-encryption/blob/master/example.php
Also, for the love of all that is holy, stop using mcrypt.
Caching is important
So you know that thing they call caching? You're gonna want that. No matter what you choose to use, make sure it supports caching and see if you need to turn it on manually. Then turn it on. Caching can be the cause of weird errors but all of those weird errors are easily solved by deleting the server's cache which takes about 3 seconds. The bandwidth and time saved (As well as the reduction in comments on slowness) make caching a necessity.
The default method of running more than one mush sucks
Tinymux and Pennmush, also rhost mush, all have a method for setting up a configuration for more than one game on one server. It sucks. Don't bother with it. The solution is an attempted wrap around server that tries to differentiate each of the games based on very fine lines. This doesn't always work (Assuming that it makes the folders for the new game correctly at all or that it starts). There's a far easier way. Before starting your new game, change the name of the PID file. In the game directory you'll find a restart script, change Netmush to some other name and make sure that name is changed in the other CONF files. Then start your mush the normal way. This is by far an easier way to run multiple mu's than the way found in the make file. It also makes it far easier to tell which mush actually crashed when one does, if it does at all, because this changes the name of the process when it is launched.
Your router may not forward port 80
Depending on the software in your router, it may not support forwarding port 80. Some do, some don't. Before you decide 'i'm going to host a website,' you should test and see if forwarding port 80 kills all your web browser traffic. If so, your software doesn't support it. There are options though! You can see if you can get dd-wrt on your router or openwrt. These are two open source firmwares that support port 80 forwarding correctly based on iptables.

Staked

Pretty decent tips, though I disagree with running SSH on a non-standard port. If somebody wants to try to get in, nmap is going to find it on that other port anyway. Plus moving it to a port above 1024 also takes away the safety net of knowing SSH was properly started by root since any user can start a service above 1024.

Install fail2ban and leave ssh on 22, imo.

Arkandel

@Staked said:

Pretty decent tips, though I disagree with running SSH on a non-standard port. If somebody wants to try to get in, nmap is going to find it on that other port anyway.

True, but why make it easier on them? I mean they are basically scanning huge ranges of IPs for known ports (and then for known exploits), so every bit of a delay is to our collective advantage.

Glitch

Security through obscurity is rarely a viable solution. I otherwise also think these are good tips/tricks.

Alzie

Since it's been brought up several times, Security through Obscurity is a perfectly fine, viable solution as long as it's not your only security layer. Changing the default port of SSH or any other service will never stop a targeted attack, however as an additional layer of security, it will defeat the non-targeted attacks that are employed regularly that look for a specific opened port.

Additionally, Services like fail2ban or sshguard have their own issues, such as someone recognizing that they are being employed and locking you out of your own server. They're not particularly good solutions given that danger unless you have local access to the server.

Chime

@Alzie said:

Since it's been brought up several times, Security through Obscurity is a perfectly fine, viable solution as long as it's not your only security layer. Changing the default port of SSH or any other service will never stop a targeted attack, however as an additional layer of security, it will defeat the non-targeted attacks that are employed regularly that look for a specific opened port.

Additionally, Services like fail2ban or sshguard have their own issues, such as someone recognizing that they are being employed and locking you out of your own server. They're not particularly good solutions given that danger unless you have local access to the server.

Please forgive a bit of thread necromancy, but I just saw this.

Security by obscurity is generally pretty stupid. Running ssh on another port doesn't hide it from very many people and is pretty annoying to the rest of us.

Correctly configured fail2ban should be generating ip-localized rules in response to auth failures. If Attacker A on address ip-A hammers ssh trying to get in as root, fail2ban should block ip-A on port 22 (and maybe other ports). Even if they know my username and hammer that, it only blocks it for the IPs they come from.

Now if they can spoof IPs (not all that hard), then things get more complicated, but usually that results in other problems first.

Source: Me! I've run mechanipus in various forms for several years and AccelaNET before it. I'm quite familiar with operating on the internet at large and in distinctly hostile network environments (woo, DEFCON!). All of my machines run fail2ban and have for many years. Additionally I have a variety of adaptive firewall rules constructed using rate-limiting hash buckets, which tend to make portscanners unusable. I can elaborate on how that works if anyone is interested--

-- but that's part of my point exactly: none of my security relies on obscurity. It's strong without it and spreading knowledge about how it works only raises the strength of internet users as a whole. For the safety of everyone, we must all know how these things work.

...Geez I sound like the Free Council now.

Thenomain

@Chime said:

...Geez I sound like the Free Council now.

Say that with pride, woman!

Alzie

@Chime said:

Now if they can spoof IPs (not all that hard), then things get more complicated, but usually that results in other problems first.

To elaborate what she means for those unaware, I will translate.

Chime: 'Applications that can ban ips after a certain number of authorization failures are great!' slight shift in posture 'Until someone that knows that you're using one modifies their headers and blocks your IP so you can't log into your own server.'

You might even be asking, how hard is it to tell that these programs are being used? Not hard. Trivial even. They're not even recommended. By anyone. Anywhere. Except here I guess.

However if we're being fair, Security by Obscurity isn't a recommended solution either, it's just one of those things that you tack on as an after thought because you can.

Case in point (For thread necro): If you rely on either of these things for your security you've already lost.

2nd Case in Point: This is why my thread wasn't entitled: How to secure your hosting box.