You didn’t really think we were going to tell you that, did you?

Actually, some of you likely will have clicked on this thinking that’s exactly what we were going to do.

Security is one of the most challenging aspects of running a shared hosting company. After all, the existence of hosting that’s “shared” seemed like it shouldn’t exist at all - most networks are closed to everyone and open only to those that need them. By definition, a shared hosting network and server has to be open to everybody that’s needs access no matter where in the world they are, but closed to everyone that would harm the network no matter where in the world they are.

Because of the inherent oxymoron-ness of shared hosting, security on the servers is quite extensive and has to be fine-tuned nearly every day. We employ mod-security, a software firewall, blacklisting services, scanners, and a host of other things to catch problems as they come up. Despite our choice to not automate any set ups are installs, our security is automated and will kick in immediately when there are certain defined problems.

We get at least 2-5 people firewalling themselves per day. In response to being told they firewalled themselves, we get these frequent responses back.

1. Can you whitelist my IP?
2. Can you explain exactly what I did so I won’t do it again?
3. I don’t know what a port scan is so I could not have done it.
4. But I was using the right login!

None of these are the correct responses, and they won’t get you anywhere. Here’s why.

Can you whitelist my IP?

OK, so, a firewall is designed to spot things that people do against the servers. The means people outside our network, and believe it or not, those who we gave access to that maybe we shouldn’t have. What you are asking us to do is to tell our servers to ignore anything that you do wrong so that if you do something wrong, your access won’t be blocked and you can keep doing the wrong thing until you get it right (or so you can keep banging on the server until you email support).

When you see it explained like that, can you understand why, maybe, that’s not a good idea?

The firewall is there to protect the server as a whole, and you are not the only client on it. In addition, many clients that we have are not savvy enough to recognize when their computer has been unwittingly drafted into being a member of a botnet. Even if you are sure you didn’t do that portscan yourself, it doesn’t mean that your computer or another computer on your network didn’t.

Can you explain exactly what I did so I won’t do it again?

We can, in general, tell you how to do it right - what we can’t do is explain step by step what you did wrong. This is especially true for orders that are flagged and refused for install - and in that case, we won’t even take the time to explain to you fully how to do it right as we feel the order form is fairly self-explanatory.

While the slice of the server you have is “yours”, the machine is our responsibility to secure. One of the ways we do that is making sure that exactly what we do for security remains a tightly held secret.

We’ll tell you that we use mod-security, but you won’t get a copy of our rules. We’ll let you know the server firewalled you for performing a certain action too many times, but we won’t tell you exactly how many times it was that set it off. We’ll tell you that you were temporarily firewalled but we won’t tell you how long the ban will last before it expires. All that information can be used to piece together a picture of our practices that no one should have a picture of but us.

I don’t know what a port scan is so I could not have done it.

See the response to whitelisting - many clients that we have are not savvy enough to recognize when their computer has been unwittingly drafted into being a member of a botnet. Even if you are sure you didn’t do that portscan yourself, it doesn’t mean that your computer or another computer on your network didn’t.

If we are picking up scans that you know you didn’t or couldn’t have physically done, you need to look to other explanations. It could be as simple as your computer being infected, it could be as complex as your wife suspects you are talking to a mistress through email and is trying to hack into your mail account to get evidence. There are a lot of explanations for firewalling from the simple (I forgot my password and refuse to email support so I’ll just hack away until I get it) to the complex (someone wants to hack your account and they live under your roof).

But I was using the right login!

This one’s just thrown in here because we are like the omnipotent and unknowable deity within the metal confines of these boxes. We know what you typed in. We probably even know what you did last summer since we likely have it archived somewhere.

If we tell you we see that you typed in “groggy” to log in and your login is really “eueytgdfy”, just believe us. It saves time.

We are going to actually block port 2082, which is the non-encrypted cPanel port. For a while now (over a year), we’ve directed the servers to forward you when you log in to the server name (to prevent browsers from freaking out when you don’t have an SSL certificate), and to the encrypted cPanel login port (which is 2083). If you logged in by typing in yourdomainname.com/cpanel, it would forward you to https://server.name:2083 so that you could safely log in and so that your login and password was sent encrypted. We programmed this through the server settings, and thought that since we told the server to forward you so you were encrypted, it would do so and not let you be unencrypted at all.

Guess what? Not quite.

Thanks to a client coming on chat this morning, we discovered that those of you who bookmarked pages within cPanel itself using the non-encrypted link could bypass this security mechanism, and happily fly your logins and passwords through the air in plain text. To help combat this, we are firewalling port 2082 on all servers - those of you that have bookmarked unencrypted pages will find yourselves unable to reach your cPanel in the manner you are used to through your bookmark. If you find yourself locked out, you should also take this as a sign that you should log in “the regular way” (http://www.yourdomainname.com/cpanel) so that we can protect you from plain text password volleyball, and should also immediately change your password (as you’ve been using it without encrypting it) as soon as you get in.

If you ever find yourself within your cPanel, Web Host Manager, or Webmail and the link in your browser is http:// and not https://, you are most certainly “doing it wrong”, as we have all logins programmed to operate using SSL. Despite that, it appears cPanel is not foolproof, so make sure that you’re protected.

We have also changed some of the settings on our firewall in general. Previously, we permanently banned IPs caught doing nefarious things. We have changed those bans to expire within 2 hours, so if you or your clients screw up, the port and action will become available to you again after the two hours passes. After a few chances, though, the software will put you back on perm ban, so you still can’t spend all day trying to guess your password. If you don’t know what your cPanel password is, email support and we’ll reset it. If you lose track of your email password, login to your cPanel securely, and simply reset it.

Quite frequently on the chat list, we get an email sent to it that asks the proverbial question “Is XXXXX.com down, or is it just me?”. Well, now there’s a web site that lets you ask the same question:

http://downforeveryoneorjustme.com/

Type in a domain name, and the site will let you know is the site is down for everyone, or if it’s just you. If it winds up being just you, grab a staff member on chat, or email support with your IP address so that we can check our firewall and see if you set it off and got yourself blocked, which is usually the most likely scenario when it winds up being “just you”. Don’t know how to figure out what your IP address is?

http://whatismyip.com/

will tell you your IP address - we need your computer’s IP when those things happen, not the IP of your web site. We already know the IP of your web site.