Joomla is an awesome CMS and lots of people use it. It’s also one of the most commonly exploited pieces of software we see.

Securing Joomla can be a chore, and telling you how to do it completely is beyond the scope of one single blog post – but like WordPress, one of the most common Joomla issues that we see are people downloading and installing plugins that are vulnerable.

As with WordPress Plugins, Joomla plugins can open up holes on your software and your site that exploiters can drive a truck through.

Check Before You Download

Joomla does it’s best to let you know about these plugins that can decimate your site – but you’ll only find that information if you go look for it. Just like folks who don’t read the blog likely have no idea we were at HostingCon, got new stuff, and are making major changes, folks that don’t bother to ever look at Joomla’s documentation but who actively use Joomla have no idea that there are plugins being offered that can cause real havoc with their site.

http://docs.joomla.org/Vulnerable_Extensions_List

Joomla lists extensions that are being offered which are (1) Vulnerable and obviously (2) you should not use if they are on that list. One of the extensions we’re seeing being exploited repeatedly is:

RSMonials

http://www.rswebsols.com/downloads/category/14-download-rsmonials-all?download=23%3Adownload-rsmonials-component

XSS Exploit
190610
Believed to be 1.5.1 version

It’s on that list, and it’s highlighted in a really nasty red so you comprehend this is a real problem, there is no patch, and you shouldn’t use it. Ok, so what if you do use it?

What is an XSS Exploit?

http://www.cgisecurity.com/xss-faq.html

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website.

Remember that anything you install is your responsibility to secure. Finding the holes and patching them are considered your responsibility and can usually be dealt with by simply making upgrades a part of your site maintenance. In Joomla’s case, they provide a current list of those plugins considered dangerous and exploitable for you. If what you want to use is not on there or if you want wider information, searching for your software or plugin and the word “vulnerability” will give you an idea what the issues are.

For example, the search RSMonials vulnerability brings up an enormous amount of information on the problems with this plugin:

http://www.google.com/search?q=RSMonials+vulnerability

and this “security technique” (i.e. the simple Google Search on what you are using with the word vulnerability) is, again, a cross-platform technique that can be used on and is applicable to any software or plugin, not just Joomla.

This technique can also be used by web site novices who can’t install anything that doesn’t come with a button.

If you are a programmer, you can always sanitize and plug the hole after reading about the vulnerability. If you’re of the button-click software user variety, this technique will tell you what you should absolutely not use. Vulnerable software is not something anyone should gamble on.

What does this all mean for my DrakNet Site?

While we let you know after your site has been compromised, that’s truly not the way you want to find out because the moment we find the exploit, your clock starts ticking.

Repeated exploits will cause your site to be suspended and/or terminated, and if it’s an active exploit returning daily reports and re-infections, you’ll have only four days to get up to speed before it becomes a risk of you losing your site – as a host, we cannot knowingly let a site continue to serve things we know puts people at risk. The fourth exploit in a week, and we will take the site offline, and potentially not allow it back on again.

Any site running dynamically (forums, wordpress) on software is susceptible to attacks, but Joomla particularly so – especially in the realm of released plugins by independent people not associated with the Joomla project.

If you’re going to offer dynamic sites, always be aware of the things that can go dynamically wrong, and take some extra steps before you install your own welcome mat for site exploiters. Security experts put a lot of effort into getting the word out, so make sure you take advantage of the work they put in to try and keep your sites and your visitors safe.

A Soholaunch exploit has been found and there have been some problematic issues in dealing with the exploit. We don’t have much information, and some of what we do have is a bit confusing, so we’re going to try and break it down for you.

In a Nutshell: The exploit has been actively exploited for about a week. We cannot craft a signature to filter out this attempt without also breaking all Soholaunch installs (if someone has come up with a mod-security rule for it, email me. I’ll pay you. Seriously.) We can detect the exploits once found and clean them once found, though see the caveat below. We were given two patch scripts by Soholaunch and ran them on all servers. The first one didn’t work, the second one appears to potentially have worked as we did not pick up active infections last night.

We’re hopeful, at this point, things are secure from an injection standpoint. We are not comfortable assuring you of that, however.

207 of you are currently using Soholaunch licenses. We had about 125 infections, across all servers. This was a widespread exploit that was actively used, and it was more than just here.

Ok, so what’s the caveat?

The caveat is your passwords to your Soholaunch install were able to be gleaned, so even if we patch the hole and clean the infections, if your login information is not changed your site is still at a high risk of exploitation.

We are suggesting the following for all Soholaunch installations:

1. All installations should be updated. v4.9.3 r42 (which includes additional security patches) has been re-released as a “latest” build. It is highly recommended that you install it. If for some reason it breaks, simply log-in to sohoadmin and “update” to the previous build (r41), which is still listed as the “stable” build.
2. All sohoadmin logins and passwords should be reset. Logins and passwords. If you saved FTP passwords in the program, change those as well.
3. If you saved any kind of secured information in the program, like logins shared between colleagues, go change those.
4. If you do not run a firewall/virus scanner, you got notice from us that you were actively infected, and you visited your own site, go get your computer scanned.

If you leave logins and passwords the same, your site is potentially at risk. I cannot stress that highly enough.

Malware Detection by Google

We are beginning to see notices from Google that sites have been picked up by them as Malware infected. Google will send notifications to:

abuse@yoursite.com, admin@yoursite.com, administrator@yoursite.com, contact@yoursite.com, info@yoursite.com, postmaster@yoursite.com, support@yoursite.com, webmaster@yoursite.com

and as all abuse notifications come to us, so we will get the notification as well if you miss it. Once Google pegs you as dangerous, people coming from Google to your site will see the following notice in the search results:

And the following when they click through (if they click through):

If we get the email, we will send you the notification after individually scanning your site. If you do not have a WebMaster account and you have a Soholaunch site, we would suggest that you go ahead and get one now, before you potentially get the notice so that you can have your site un-pegged as soon as we’re all sure the issue is passed.

We have set up a special email for this issue so if you have any questions, email security@drak.net.

Lecturing, begging, and pleading has done no good, so now we’re taking the next step.

Ok, it’s not really all your fault – sites are such a target these days that malware attempts are becoming ridiculously common, and while you sometimes (ok, a lot of the times) make it easy for them, sometimes it’s the software developers that miss a great big hole that you could drive a truck through. Once the truck’s parked, it’s sometimes hard to find – though Google’s getting good at it.

By the time Google finds it, you’re out of the search engine, we’ve suspended you, and frankly we’d like to help you all avoid those little “all stops” to your business, or those little infections you pass on to your visitors before we’re aware.

Last night, DrakNet installed a Malware Scanner on all servers. The malware hit management is a very simple anti-virus like quarantine system that moves offending files to a quarantine container and logs the exact source path and destination file name in quarantine locker in case we need to restore any data due to false positives (though this should never happen since we are using hashed detection). In addition, the quarantine function can search the process table for running tasks that contain the file name of the offending malware and stops any processes it may be running.

The scanner will scan daily all files changed on the server within the last two days ensuring that we get a look at any file that’s been changed whatsoever. It will let us know what it found, and what it did. It is programmed to automatically quarantine the file and infection, returning the file to its original location only if the infection was able to be removed and isolating the infected version of the file in a container so we can take a look at it. Not all infections will able to be cleaned and if that’s the case, the file will simply be removed and quarantined.

Currently, we’re running scans on every server, which we started last night. This could take a few days because of the sheer number of files on each server and depending on the number of infections, it could take us a bit to contact everyone who was found to be compromised.

Simultaneous to the full scan we began, last night’s daily scan ran as well. Each morning as we go over what was found, we will prepare emails to site owners who’s sites were found with Malware outlining what was done and general steps we recommend to check to avoid infections in the future. Those who had malware installed within the past two days are already in receipt of emails outlining the issues found.

We’re hopeful that by implementing this, we can avoid automatic suspensions and catch malware before it breeds like a cell dividing on your site, as once an entry point is established, infections tend to expand exponentially as the hacker realizes the infection has gone undetected.

You can, at any time, email support for a scan on your site if you are concerned or worried that something is going on with your site. In addition, as opposed to passing the cleaning of the infections back to you, we will run the automated quarantine and cleaning scan at no charge to you hopefully securing the site and passing it back to you without malware (though some files that may be unable to be cleaned will need to be reinstalled or rebuilt by you).

Please let us know if you have any questions about this new policy.

DrakNet has added shared SSL on all accounts across all servers at no charge.

Shared SSL means using, or sharing, DrakNet’s SSL certificate to secure some of your site instead of using Private SSL, which costs quite a bit more. The difference between shared SSL and private SSL is in outward appearance and cost, but not in the actual security provided.

Private SSL

With Private SSL, we place your domain name on its own dedicated IP that no one uses but you – and that costs money each month ($5 to be exact). That private Dedicated IP enables you to install your own SSL certificate so that your domain name and any part of your file structure can be accessed securely simply by changing the URL from http:// to https://. That also costs money – secure certs run anywhere from $35 to hundreds of dollars per year depending on the level of assurance.

Shared SSL 

With shared hosting, unless you pay for your own IP address, you share an IP address with the server and everyone else on the server that doesn’t purchase their own IP address (which is almost everyone). This is a good thing, especially considering we’re all using IP’s up at a pretty fearsome rate. It also helps keep the cost of shared hosting down because you share even those resources (IPs) with everyone else.

Because standard accounts share an IP, that IP address can have a certificate installed on it and everyone on that shared IP can use it. SSL certificates secure a particular hostname, though, so when using a shared SSL certificate you have to use the hostname that the SSL Certificate was purchased to secure and not your domain name.

This saves you the cost of the Certificate itself, as well as the cost of a static IP since its not needed.

So, how do I use it?

To secure a page or pages on your site, you would use the URL https://servername.drak.net/~youruser/ – this URL also leads to the main directory of your site, and you would simply need to replace the servername above with your server name and youruser with your cPanel user id.

For example, your user is abc, and your site is mysite.com, and its on blastoid. The page you wish to secure is in the directory /order, and the file name is index.html. The non-encrypted URL:

http://www.mysite.com/order/index.html

becomes:

https://blastoid.drak.net/~abc/order/index.html

Some Things to Keep In Mind

If you have absolute paths in your code, you may need to change those paths to relative paths for your information to display properly. For more about the difference between absolute and relative paths, you can read this tutorial. If you use an absolute path with the SSL URL, the code:

<img src="/images/smiley.gif">

is assumed to be at the top of the hostname. While that will work with your domain name and the server will assume that the image is at:

http://www.mysite.com/images/smiley.gif

no matter where that image call is located, when you use shared SSL, the absolute call above is interpreted as:

https://blastoid.drak.net/images/smiley.gif

and it will cause a broken image because smiley.gif is not actually located there.

How do I find out what server I am on?

Log in to your cPanel, and look under “Stats”, then click “Expand Stats”. Scroll down to where the IP is displayed. If it says “Shared IP Address:” with a number next to it, you can use the shared certificate. Go a few about that and you’ll see the server name – add .drak.net to that server name, and /~yourcpanelid to that, and you have your SSL URL.

If you have any trouble figuring this out, feel free to email support and we’ll be happy to help you get the right URL.

When you fill out an order form with DrakNet, we ask your information – your email address, your phone number, your name. All of this information is important, and is used to identify you so that when you contact us, we know who you are.

If the account is an individual account, this is relatively easy – who you are doesn’t change. Your email might change, your phone number, your address may change but who you are remains a pretty good constant that we can count on. (And if your name changed, you can usually fax us the name change and establish the name changed, though that would only need to be done if you locked yourself out of your billing.)

With companies and organizations, this can become a little more complex.

What matters on the order form

When an order form is filled out for an organization or a company there are two pieces of information that are provided to us, the company or organization name and the name of the individual placing the order. When that’s done, the person listed as the individual placing the order is then listed as the representative who is authorized to make all decisions the account. Their information is the information we look to when we confirm that someone has rights to an account.

If that person leaves the organization, that person is still the person authorized to make changes on the account, close the account, or make requests. Someone that is not listed on the account, even if they are internally appointed to manage the account by the company or organization, does not have standing with us to make any changes or have any access because we have no idea who they are. In the interest of protecting the site and account, they will not be allowed to make changes.

So, what happens when the authorized contact is a position that’s kicked around like a soccer ball?

Please note that these are only for sites that are held in accounts that have a company or organizational name. Individual accounts are individual accounts and transfer of ownership cannot be accomplished this way.

Change Contacts The Easy Way

The easiest way to change a contact on an account is for the old contact to give the billing login to the new contact so the new contact can login to the account and change the information in billing (Name, Email Address, Phone Number), as it is this information we look to when we confirm someone’s identity as a person authorized to work with us on behalf of the account.

This is simple, quick, and takes relatively little time.

Change Contacts The Hard Way

The hard way happens when the original authorized contact leaves in a huff, refuses to hand over the site, refuses to allow access to the legal owners, or simply disappears with the keys.

Changes become more complicated if a handover did not occur.

Because we have an authorized contact that cannot or will not contact us or the company or organization’s behalf, we have to have hard documentation that we are handing the site over to the legal owner or the organization or corporation. Essentially, you need to prove to us that you should have the site.

In these cases, DrakNet required a signed, faxed letter on company or organizational letterhead that states:

1. who the previous contact was
2. why the previous contact cannot or will not contact us to make the change
3. who the new contact us, with their name, phone, and email
4. a specific request to drop the old contact
5. a specific request to add the new contact
6. what the role in the organization or company is of the person writing the letter, with a copy of that person’s ID on the latter itself.
7. A dated signature

and the fax must be accompanied by some official documentation showing the person sending us the request is affiliated or associated with the organization or company, and in what capacity. It could be a copy of an official bill, a dba, a contract, the incorporation papers, corporate minutes. Just something official and legal in some capacity.

We will make an attempt after getting the fax to contact the current contact and confirm the information and if we cannot confirm it, the change will be made as long as the information indisputably shows the person who signed the paper has the legal right to make the change.

The Moral of the Story is

We do the absolute best we can to keep the server secure, and the accounts secure – and part of that is knowing who’s on the server and who’s supposed to be talking to us. If the person that calls or chats or emails us isn’t an authorized person on the account, we don’t discuss things with them as a precaution against social engineering.

We assume that if you host here, we know who you are.

If you don’t host here, you don’t need to know what our random ssh port numbers are, and we don’t care if you swear up and down you are on the Board of such and such and its your account – if you hosted here, you would have known our ports were not on 22 and that firewall wouldn’t have happened. If we don’t know who you are, if you have no information with us on file so that we can substantiate who you are, we can’t tell you anything and we certainly can’t unblock you manually.

If you don’t know that, then you have had a failed changeover, and you need some help to become aware of our system, and our policies, and your site. We’re happy to help you with that – after we know for sure who you are.

It is very important for organizations to maintain their information, and for contacts to maintain current information. Have a pass through book, have more than one person as a contact, share the billing login with the Treasurer or President so problems can be dealt with easily.

If that doesn’t happen, we are going to require that you make changes “the hard way” because that’s the only way we can be absolutely sure that the account belongs to you or you have rights to it.

It is for the safety of your site, the safety of your company or organization’s web presence – and its also because we at DrakNet really don’t want to have to try and figure out who’s telling the truth in a dispute, or explain why we handed over a site to a rival faction bent on nefarious deeds to our client, or in court.

So, earlier today, DrakNet’s illustrious Brit staff member, Thomas, let me know that mod-security 2 doesn’t support overriding mod-security via .htaccess.

Of course it does, I argued – we’ve been passing out the code for it since we upgraded to Apache 2 and Mod-Security 2 and its been working since last summer. No, it doesn’t, he argued back- and I, of course, argued back that it does. So, we had to get a tie-breaker at Liquid Web, our data center, and 4 system administrators debating the issues later, it appears that in mod-security 2.5, you all no longer have the ability to turn off mod-security protection on your sites yourselves.

There was much wailing and gnashing of teeth.

While from a security perspective on a server, this is a pretty good thing, the fact is on a shared server requiring these changes to be made in server configuration files is a gigantic pain in the keister for your web hosting company. In addition, this flies in the face of the security policies we’ve had and that we advise you to use, which is protect your site 100% and only turn mod-security off when using the administrative area (which is 99% of where ya’ll tend to get caught – this means you, WordPress widgits).

We hereby dedicate Hot N Cold by Katy Perry to ModSecurity for this change.

This does change how we handle requests regarding Mod-Security problems. Much to our chagrin.

If you are writing in for a mod-security issue, you have a few options and we’ll need a bit more information from you to resolve the issue for you. So, first, what should you send us when you have a mod-security error?

1. What time, approximately, the issue happened.
2. What you were doing at the time. What the link is, the file, and so on.
3. Your IP address.

Hopefully, this will be something simple, like you used a URL as a call and should have used a system path or some simple thing we can advise you to change. If you’re using an out of the box software installation from Fantastico, this issue’s resolution is likely not going to be simple.

If you have an out of the box installation that’s getting tripped up by mod-security, we’ll still need the above information. While its possible we’ll be able to change the rule or exempt the file universally, most often we won’t be able to do that and if that’s the case, you’ll have a few choices.

1. You can request us to exempt your site from the specific rule that’s catching you up.
2. You can request that we exempt a directory from the specific rule that’s catching you up.
3. We can turn off mod-security per directory.
4. We can turn off mod-security for your entire site.

Every time you lower security, you raise your chance of being compromised. The “easy” solution is to just turn it off – and its easy right up until the time you lose your site due to a hack. So, you’ll have some decisions to make if you need this done.

While ideally, we can turn things off and on for you like before, it’s just not practical. We may do it once for you but if this is something that will come up repeatedly, we’ll need to find a permanent solution.

The past week or so we’ve seen a rash of compromised accounts, more so than we’ve seen at any time in the past. It’s certainly not epidemic, but its more than we really want to see. We wanted to go over best practices (yes, again), and give you an overview of how we tend to handle compromises.

Best Practices

Upgrade. Please upgrade. Please, please, please, please, please upgrade.

No, really. We so, so, so want you to upgrade.

Those software versioning numbers? They actually, honestly mean something – so much so that there is a Wikipedia article written just to explain it it you.  Much of the time, compromises are not found until software has been widely released, and all software on your site is public, open to anyone that feels like trying to get a digital molotov cocktail in there through a window left cracked open.

There seems to be a common misconception that you will know when your site is hacked – that a hacked site will sport a “Ha ha, got you!” page telling you that you’ve been compromised, your stuff will stop functioning. While that does happen, it’s not the most common hack out there in the wild.  Frankly, the hackers that do that are practically doing you a favor, because they’re telling you so you can take steps to fix it. Many hackers feel that this is a noble calling for them, though if you get owned you may find yourself feeling differently.

The hackers you want to guard against are the ones you don’t see – these guys don’t announce it as its not a skills “thing”. They don’t want you to know what they’re doing, and they don’t want us to know, either. They want your site to stay up and running for as long as possible, so they can send spam through your site, or have people fill out a phishing form, or they can poke around trying to get everyone else’s information on the server. Stealth is key to carrying out these kinds of hacks, and many times you can be totally compromised with nefarious baddies using your site as a playground and you won’t know.

So, how do you keep them from targeting you in the first place?

Well, you can’t. You’re on the Net. That’s the reality – you’re a target. If there is a hole in your site, they will look for it. Everything you decide to do with your site should have that in mind.

So, how to you keep from cracking that window?

1. Be Selective with the Scripts you install – half the time, you let them in yourself. Just like someone handing you a bag at the airport isn’t a good idea to take, there are scripts floating around out there saying they do one thing, and doing another. If it’s a WordPress Theme or plugin and not on the WordPress site where the listing is free, stop and wonder why its not. Is the software active? Is it being updated? Does the site look like software developers that take things seriously, or does it have that spammy feel? Was the last release in 2006?
2. Keep your software updated! – If your software is actively maintained by decent developers, the developers will address security issues. Google the software name and “vulnerability” – chances are you’ll find something. You can use that info to see how quickly an update was released and an issue addressed so that you know as far as you can tell whether something is well maintained – but an update being released is meaningless to you if you don’t upgrade your software. This is a serious issue here at DrakNet, and can be a terminable offense.
3. If you disable security, realize you’re asking for it – Mod-security and our PHP settings are instrumental in our ability to protect you against your own worst instincts to use bad code, not update your scripts, and transform a site’s original code into something you want when you aren’t a developer and aren’t wholly sure what the heck you are doing. Yes, we let you override – we expect that when you override you know the potential consequences, and that you accept them and are prepared for them, which brings us to…
4. Backup Your Stuff – A backup is the only fool proof method to be completely secure against recovery from compromises, far enough back that the site is secure. If your site is compromised and allowed to run with it, they potentially will be useless, but most of the time they save your site and save you hours of work. You can utilize the Backup feature in cPanel to take complete website backups of your account settings, files, emails, databases, etc. Keep them. We maintain only a weekly, and a monthly. If you’re compromised a month or two ago, you’re looking at a site nuke.

OK, you’re hacked. Now what?

If we find it, you’ll be suspended, instantly. We will not call you to discuss the situation, we will not conference to debate what to do, we will not send you an email asking if its ok to take you off line. We will lock down the script and/or the entire site if there is any suspicion that the hack went farther, immediately. We cannot continue to allow sites that are:

1. spamming
2. phishing
3. hacking
4. serving viruses
5. serving malicious software
6. out of the direct control of the authorized admin

to continue to blissfully function on a server we control. If you put our machine at risk in any way, shape, or form from malicious activity, we will shut you down. Yes, even if its “not your fault” because, folks, just because you didn’t choose to do it doesn’t mean that the real world consequences of what’s going on are simply suspended due to your non-active role in the malicious activity. The rest of the clients who share the box with you are still at risk, and your site simply will not be allowed to put their services at risk.

Once your script is locked or your site is suspended, we’ll send you an email, letting you know about it. From there, you have a few choices:

1. We can completely delete your install, install you fresh, and you can start over. Before anyone screams that this is grossly unfair, I’d like to remind you that this is what we do if a server is compromised, and its no fun for us, either. If our server is hacked, the only foolproof way we have to secure it is to rebuild it from the ground up, and so that’s what we do. So, we’re not giving you an option without being aware of (a) what an unmitigated pain in the keister it is or (b) without being willing to do this ourselves on a much grander scale.
2. If you know enough to secure it, and we are reasonably sure it is related to a script only (and you’re reasonably sure you can track it down and remove all of the offending code and fix all underlying security vulnerabilities before putting your site back online), we can unlock most of the domain while keeping the site offline for everyone but you based on your IP so that you can upgrade and patch what needs to be upgraded and patched or reinstall things so they are secure. You can also hire an admin company to do the same type of thing.
3. You can pay us to secure the site, and rebuild what we can, with no guarantees regarding what we will be able to salvage, for $75 an hour.

Shared hosting is managed around your site. We control the building and the utilities – however, if you set the office we rented you on fire after pouring gasoline on the floor and lighting a candle, the cleanup is not included as part of your hosting fees, especially when your security practices go outside of the recommended security practices.

Taking your site offline is not meant as punishment – it is done not only to protect our other clients, but also in order to keep from putting your site’s visitors and your customers at risk.

If you find that you’re hacked first, finding and removing a specific block of bad code that a hacker has inserted can clean your site for a time, but keeping your site from being infected in the future will require fixing the security vulnerabilities that allowed the hacker to insert the code in the first place.

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 but finally 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.

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.

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.

(more…)