We have upgraded all servers to cPanel 11.24, or “cPanel Accelerated“, which should be a souped up yet slimmer version of cPanel. Likely, you personally won’t see much of a difference though you resellers will see some added branding options.
The good news is Accelerated has implemented many security fixes that are default on current out of the box software installations that cPanel gathers into one package, as well as addressed cPanel’s woefully late butfinally here response to PCI Certification, something many of you merchants are clamoring to get before the deadline passes and you start to be fined.
(We know how you feel, we put it off as long as we could, too.)
The good news is that all servers should now pass a PCI Compliance scan, with some caveats. You’ll need to let us know your PCI Compliance company’s IP range so that we can exempt them from the firewall on the Apache port only. PCI Scans throw so many holes and exploits at the server that we inevitably wind up firewalling them, which is good for the security of your site - but not so good when they want to fully see how your web site responds to those attacks and where the holes are.
Please try and let us know when they’re coming beforehand so we can make sure that they can do and see what they need to do for you to pass. You’ll only need to do this the first time, as we’ll keep the range in there. If you want a company that we work with, we can guarantee that you’ll pass Security Metrics scan, as we did on the same servers and we already have their IPs.
The bad news? Well, it’s not bad, really, and this won’t affect the vast majority of you, but we have turned off the ability to include executables in SSI. The exec command executes a given shell command or CGI script, and as you can imagine, this is an incredibly exploitable aspect of your web site and we watch people hammer the server all day trying to shove them in there. We swat most of them away with mod-security.
After years of running with no sites ever being exploited on these servers, though, we have seen a recent rash of exploits from poorly coded CGI scripts, and we’re not going to allow it anymore by default. If you see:
[Mon Nov 10 19:11:03 2008] [error] [client XX.XX.XX.XX] unable to include potential exec “/script/here.cgi” in parsed file “/another/file.html”
You are trying to include an executable, and that’s no longer allowed just out of the box on everybody. You also need to turn on cgi scripts if you use them just to be safe.
In geekspeak IncludesNOEXEC is now the default, or more specifically, mod_include allows execution of CGIs and external commands using Server Side Includes and they are now disabled by default by the Options -IncludesNoExec directive.
Before you begin hyperventilating and wonder where you’ll get the time to recode your site, we do allow overrides, so you can take our security and turn it on its ear by creating an .htaccess file with the options you wish to have and blow your site wide open if that’s what you feel like doing.
If you wish to use a .htaccess file to permit the execution of CGI programs in a particular directory, you will need to create an .htaccess file that adds the executable option to that directory.
Options +ExecCGI
AddHandler cgi-script .cgi .pl
If you wish to use a .htaccess file to permit the execution of and including of CGI programs in a particular directory, you will need to create an .htaccess file that adds “Includes” to the Options (overriding the IncludesNoExec that exists by default).
Options +Includes +ExecCGI
AddHandler cgi-script .cgi .pl
Our current settings are:
-ExecCGI -FollowSymLinks Includes IncludesNOEXEC -Indexes -MultiViews SymLinksIfOwnerMatch
any of which you may override.
Just please remember that if you are deliberately turning off our security, if you are not keeping your scripts updated, if you disable the things meant to protect you and you wind up getting hacked, we’re going to suspend you outright should you get exploited. We can’t afford to do security consulting for $5 or $10 a month and the most we’ll do is install an older backup and tell you to fix your stuff. You’ll need to convince us that if we turn you back on, you’ll be able to secure your scripts and if you can’t, we will terminate the account, so please realize your responsibility in trying your hardest to keep your site secured is considered sacrosanct here.
We take our job to secure your sites very seriously - we expect you to do the same for our servers and out of respect for your neighbors.
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.
Can you whitelist my IP?
Can you explain exactly what I did so I won’t do it again?
I don’t know what a port scan is so I could not have done it.
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.
This morning when you go into your cPanel, you’ll see a new button under Software/Services called Old Script Finder. Old Script Finder searches your web site for old, out of date scripts by searching for signatures on some of the most popular, and most security issue-laden if not updated, scripts being used today.
After installing, we ran a report on all five servers. There’s only eight sites on the new server and half of the scripts (3 of 6) were out of date. Half of them. Before you take a deep breathe in shock at that news (considering the server hasn’t even been up a week), let’s get to all of you other folks on the older four servers… I’m sorry to say wasn’t a single one that didn’t have 80% of the scripts out of date - ranging from just a few steps behind to woefully, woefully so far behind that the message was “script obsolete”. Even we were a bit surprised at the statistics.
Currently, we have only the most basic options on this script enabled - every Saturday, it will search all the servers and it will take stock of who’s scripts are out of date. That report will appear in your cPanel. It will tell you what script is out of date, where that script is located, what version you have and what the current released version of the script is. There is also a button for you to run the script on your own to take a look in your own directory if you install something - please use it sparingly as this is a fairly resource intensive endeavor.
The catch is you need to look at it, and you need to take action.
Hopefully, this handy tool will help you get a handle on updates and give you information you didn’t have before. It should also help folks that have installed scripts and forgotten about them - I took a look at some of the things that were found and I get the feeling that a few of you are going to be shocked at what’s hanging out in your web site.
If the statistics don’t get significantly better, we’ll take the next step and have the server email you regarding your out of date scripts. If that doesn’t get a response, at some point, we may start locking them down after repeatedly warnings are ignored.
For a list of scripts that are looked at, click the more information button below.
When you sign up or install an account, we issue you a cPanel login - this login is essentially the “root” of your account with full administrative powers to do very nearly anything that it gosh darn well pleases, and since it has shell access to the server, it’s a pretty powerful little login. It’s one of the reasons that we force you to login to the servers using SSL, and we’re so adamant about keeping your site from obvious risks we also firewall your ability to get into cPanel from any other way other than in an encrypted manner.
Much to our chagrin, it can also work for FTP or logging into mail - and though you can use it that way, you shouldn’t, because those logins are not encrypted and you are sending a plain text password through the internet and through multiple networks in such a way that anyone can pluck it out of the air. This is extremely unsafe, and we highly recommend that you not do it at all.
All cPanel email accounts should be created in your cPanel - sending those passwords through the air in plain text isn’t really any better, either, but at least you are limiting the access that they can get to that email account only. (We will have an article regarding encrypting your logins, but that’s beyond the overview scope of this article).
All FTP accounts should be created in your cPanel - sending those passwords through the air in plain text isn’t really any better, either, but at least you are limiting the access that they can get to that FTP account only. The only exception to this would be if you use SFTP, which is actually run over shell and not over “FTP” - in that case, you are required to use your cPanel login as that login is the only true Unix login and hence the only way that you can have SFTP access.
You cannot simply login to SFTP on port 22, either - we hide all shell ports and we do not publish those ports anywhere. You’ll need to email the support department and request the port for your server as they are all different. This allows us to know exactly who has shell access, and to monitor its security with a little extra glance every now and then.
We do recommend SFTP for everyone on a Junior account or above (as Intros don’t have shell). It is a more secure way to get files back and forth between the server, and if you are on an ISP that throttles FTP upload speeds you can sometimes dramatically speed up your FTP sessions when uploading to your site by using SFTP as it’s not a (currently) commonly throttled port when ISPs are throttling ports common to file sharing to limit their end users ability to share files.
It addition, by creating your FTP and Email accounts yourself, you put the ability to reset passwords when you forget in your own hands, and you don’t have to wait for support to do it for you, which is a handy little thing to be able to do.
Trend Micro is reporting that a massive attack has been launched against web sites using old or poorly configured PHPBB installations.
This compromise is almost similar to the mass compromises that they and others have reported on earlier this year — visiting a compromised site leads to a series of redirections, which eventually causes the downloading of malware.
In this particular case, TROJ_ZLOB.CCW is on the tail-end. “In true ZLOB fashion, this variant poses as a video codec installer”, and appears as the graphic at left.
If you have PHPBB installed on your web site, take action now to make sure that it’s up to date and patched, and not being compromised. We seem to have a particular issue at times with folks trying out the software, and not using it - leaving it hanging out in an ignored subdirectory mis-configured, un-patched, and totally vulnerable because it’s still public and malicious folks can still find it. Unpatched and unused bulletin board systems often become a playground for hackers as they post spam after spam in your forgotten board, taking up resources on the server as well as putting your account and anyone who stumbles onto the unused software at risk.
Never leave unmaintained software hanging out in a public directory - if you are going to periodically play with new software but can’t give it adequate attention frequently or immediately, put it in a password protected directory so that it’s not available to the general public just in case you forget about it.
If anything in your directories are public, always make sure that they are patched, current, and maintained - and if you can’t use the most current version of a software for compatibility issues, make sure that the version you are using is not compromised. A simple Google search for the software name, version, and security advisory is usually enough to turn something up if there is one.
We will be doing an audit of the servers to find PHPBB versions subject to this risk, and will take them offline if we find them, so if you’re using it, get there before us and patch it.
This past week has brought up some very interesting illustrations of just how careful you have to be when downloading or purchasing software off of the Internet. Everyone knowns not to download “too good to be true” free programs to their computer, and almost everyone now runs virus and malware scanners for their desktop to protect their computer from a wrong decision. Can the same scheme that infects your computer infect your site?
You bet.
Just this week, it was discovered that a massive number of Wordpress Blogs were hacked by an organized scheme, including installations at ZDNet, utilizing an xml-rpc vulnerability. Some of the hacks also came in through users downloading Wordpress themes that were infected (likely deliberately, but maybe not). Remember the old Lost Boys vampire thing where you have to invite him in for the vamp to be able attack you in your own home? Yep, same thing.
Frankly, we here at DrakNet are not immune to this - this past week, I was toying around with the idea of installing a directory of Soholaunch hosts. I had looked at this software and when I tried to order, it checked me out at a different site - which should have been my first clue. $90 later I had software that I hadn’t checked out, and the awakening came only after I purchased it.
When I unpacked it, there were immediate indications that something was amiss - the files provided were all dated May of 2005. “Good” PHP practices in May of 2005 compared to April of 2008 have changed significantly, and what everyone thought it was a-ok to do back then in the intervening years has been shown in some cases to be insecure and downright dangerous, so I began to do the due diligences that I should have done before I plunked down my money.
What I discovered was that multiple XSS And SQL Injection Vulnerabilities were found in the software in May of 2006 - a year after all the files provided me were created. Checking their web site, I found that the company advertised that their last update to the files was in December of 2006, implying that the software had been updated after these vulnerabilities were found - and yet as I searched through the installation I had downloaded, there wasn’t a single file provided that was dated after 08-18-2005, two days before it’s first official release date, and a year before it’s landing on multiple security advisory lists.
Had I done a search for the company, I would have seen that their company name and the word “nightmare” comes up multiple times on their first search page and I would have gotten some indication that, perhaps, this software wasn’t exactly my best choice. Had I simply done a search for their company name and the word vulnerability, I would have seen that there were 9,390 entries. I was in a hurry, and I didn’t - it was my own fault, and I admit it. I do know better, but I was in a hurry, and skipped that part.
As a consequence, I’m now arguing for my $90 back. I first went to the company who, of course, doesn’t do refunds and offered to work out what the issue was. When I outlined and detailed what I perceived as a suspicion that the company fraudulently advertised an update that didn’t take place to make it seem that they had patched insecure software that they hadn’t, suddenly, they were silent.
I then went to their payment processor for a refund, and thusfar the company has refused to speak to them, either. I will likely wind up having to drive to my bank, fill out paperwork, print out all of this evidence, and file a chargeback. Lesson learned… again.
So, how do you not fall into a trap like this?
Remember that old software is usually insecure - there’s even a term for it. Abandonware. Abandonware is old software, no longer maintained by the company or creator, and is no longer updated or patched when security issues are found within it. Microsoft FrontPage is actually now abandonware - as of late 2006, it is no longer supported, updated, or patched. There are thousands of scripts like this floating around on the Internet.
Google the script and the company with the word vulnerability and security. See if problems have been found with the programs, and whether the software developers are actually paying attention to the security community - good software companies (or good open source software developers) will jump when a vulnerability is found in their software, and will report back to the alert lists that it’s been patched after they release that patch to protect their users. If they don’t, that should be a red flag.
Google the script and the company to see what people are saying about them - everyone that does business on the Internet is going to aggravate someone, and finding something negative isn’t always a reason to run. You should, though, find more good opinions than bad opinions about the software and the company, and if you don’t find any opinions the software may not be widely used enough to have had it’s vulnerabilities discovered. This is the Internet - people talk. If they aren’t talking about you… well…
Don’t download Wordpress Themes, scripts, and so on from spammy looking sites. Get it from spammy sites, get a spammy product. Realize that anything that you put on your site is potentially open door to the developer and/or anyone else if there’s a hole - make sure that developer is trustworthy insofar as you can both not to take advantage, and to stand behind what they created with a sense of responsibility towards the people that use their software.
Remember that your web site is a veritable playground of mischief, and be as selective as you can in what you decide to snag and put on there - any program has the ability to put a back door into your site and subvert your site for its own ends. Do as much as you can to make sure that it doesn’t happen - and don’t get lazy like we did - because it’s the one time when you decide to just hurry up and do it that you may get burned.
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 mostcertainly “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:
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?
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.
We admit it - both Horde and Squirrelmail leave a lot to be desired. Most people are looking for alternatives when it comes to email residing on your computer alone for many reasons, not the least of which is the security aspect. Benefits to using webmail over a client email account is, again, security (nothing to download that may automatically launch), an ability to get your email from any computer anywhere in the world by logging in, and an archive of mail that’s apart from your computer in case of a computer failure (because, let’s face it, no one backs up as much as they should).
Despite really not being a huge fan of Webmail (especially Horde and Squirrelmail), I found myself looking for an alternative in February after a nasty virus made it through my plethora of security and infected my Windows Machine. Thanks to a Linux Mint CD, I was able to immediately get back up and running as far as accessing DrakNet and working, but my personal email was separated between an infected WindowsXP installation, and newer mail that I could grab in Horde. It was not a pleasant situation.
I began investigating alternatives, and my husband had been using Gmail for a while (which I had essentially sneered at). Using a “free” service went totally and completely against every instinct I had as someone who made their living selling commercial internet services - and I had used Yahoo! back in the day and still shuddered at the memory. Advertising all over my emails was just… um, no. Just no. He was so pleased with it (and I so couldn’t stand Horde) that I decided to try it out as a stop-gap measure, anyway.
And, well, I haven’t left.
It may seem odd for the owner of a web hosting company to be speaking against one of the offerings we have, but the webmail that we offer is included in cPanel, and we don’t really have a choice about what to offer, just whether to offer it. If people wish to use it, if they like it, more power to them - I don’t particularly find it a “selling point” because the software choices seem to be bloated and clunky, or un-bloated but bare. cPanel is a great software package, and I certainly like its platform more than anything else we’ve been on, but waiting for newer, better features at times can resemble Waiting for Godot.
Pulling your mail into GMail, however, gets you several benefits aside from the ones outlined above.
First, you can save your account’s disk space. We’ve seen people lose mail because they set their email account quota to 20 megabytes and never noticed that they hit it. We’ve seen email accounts with 1 Gigabyte of mail stored on the server, eating into the space you could be using to put up really cute videos of your cat. Popping email into Gmail allows you to use free storage on their dime, and free up storage that you’re paying for.
Second, Gmail now allows you to respond from your domain name email account at no charge to you, so you can send out email from there with the from: and reply-to: email address that you’re used to.
Third, triple spam filtering. When an email hits our server, it only makes it in if the sending server isn’t on an RBL. Then your MailScanner settings take over and based on your chosen settings, it scrubs it some more. If you pop your mail into Gmail, Gmail further identifies even more spam, and puts it in a spam folder for you to peruse. This triple-scrub dramatically cuts down on the spam in your inbox.
Speed - Gmail’s servers are optimized for handling mail, and that’s all they do. As a result, webmail is faster when you’re navigating around Gmail then it could be on our servers, especially when you have thousands of emails, because our servers are serving web pages, processing databases, serving and parsing PHP, and so on. We’re fast, but the more mail you have in your webmail, the slower Horde becomes - that “hording” of email becomes a non-existent speed factor on Gmail.
Of course, using the infamous Google search algorithm on your email is just incredibly cool, and Gmail does not put advertisements or tags on YOUR email like… ahem… some other free email services. The ads within Gmail itself are, frankly, quite easily ignored and sometimes even good for a laugh depending on the email it’s using to target them.
Gmail has directions on how to use Mail Fetcher located here. If you need an invitation for a Gmail invite code, drop us a line at the support desk and we’ll send you one.
Trend Micro is reporting that a massive attack has been launched against web sites using old or poorly configured 
