Keeping a site safe from malicious users (often referred to as “hackers”) depends on a great number of variables. All of our staff have faced these questions and concerns from clients at one time or another, or have responded to questions posed on a news group or forum community. Here, we’d like to outline some of the things users can do to in an effort to help protect themselves from such problems, with the below summary.

Firstly, it is a misconception that “nothing is 100% secure”. While it is true that very few services or scripts people often use are known to have a history of no known security issues, some things have a proven track record of being secure, such as Dan Bernstein’s Qmail MTA mail software and his dbjdns (tinyDNS) DNS services software. While we don’t claim there is no way to exploit his software, no one to date has been able to, with years of public challenges and a prize of money and credit for anyone that can.

Similarly, many of us being programmers ourselves and having written thousands of programs with thousands of lines of code each for popular web sites that have people very intend on breaking into them, we also have a track record of no exploits against our own developed scripts and programs. This is not to claim perfection, or say that it’s not possible, especially in light of API’s and wrappers the scripts run through, the environment they run in, the interpreter engines they use for languages such as Perl, PHP, Ruby and Python, but to simply point out that it’s not an issue to view as fatalistic, hopeless or to come to accept it as inevitable.

I know that programs I have written, and those of my coworkers, would be quite comfortable putting up a challenge or standing by them with the claim that they are, in fact, 100% secure. Coding securely is not a difficult task, if you are an experienced and knowledgeable programmer. Anticipating potentials and taking measures to prevent aspects you didn’t anticipate are a key role. Such as denying all functionality and input by default, and then build the functions to accept specific input, and to do so in a controlled manner. Selecting the proper environment and how it will run, the privileges it has, and above all, sanity and security checks, will go a long way. Of course, many scripts out there weren’t coded with these things in mind and many do suffer from exploits, which we’ll attempt to cover a little way down this blog.

The same thing can be said of account security itself. While there may me a lot to it, and thousands of specific incidents and potential security holes in a lot of software floating around out there, a few general things can help to prevent a lot of these, without specific targeted solutions for every type of software and its known or potential exploits. A few simple things can go a long way for a good basis, and some suggestions along the way can help as well. Should you follow such advise, truly, then combined with even only a reasonably secure server, you should not find you experience any of the site compromises that a very high percentage of the causes are (literally, 99% of the time).

If you use our services, then you already can rest assured that we take all reasonable and custom measures available to prevent a high level security issue, but ultimately your own account and script security will dictate how secure your site is — no matter how well we secure our services, if you host a script that acts as a gateway into your account, there’s only so much we can do to protect your site. We do offer some services that are unique to BurlyHost.com, Inc., which will help you to protect your site, even if you happen to be lazy about your site’s security, but, as our CEO says, “if you create a security hole in your site by how you use and store your own passwords, or what scripts you choose to run that might be insecure, then all bets are off”. While you shouldn’t worry, you should take the matter seriously. The below suggestions will help, and should you follow them, it would be unlikely that your site would ever be compromised.

#1: Keep up to date on all scripts. First, consider if you want to run certain types of scripts. Some are almost specifically asking for trouble, though most common one’s are safe in general. Subscribe to common security alert announcements and mailing lists, and especially keep up to date on any security issues that are posted on the script author’s site of the software you use. They will often be the first to release security patches you can apply to your current installs, or offer a new version that you can either install in place or your current one, or more likely, to allow you a means to upgrade. Of course, you will want to make a safe backup of the scripts, data and databases you are going to patch, replace, or upgrade, but be sure that backup isn’t publicly accessible, else you might forgot about it and have both a newer secure version running along side of an older version with a known security issue. The unfortunate drawbacks of this, is that is can be time consuming, especially if you use a large number of scripts, and even more so if you use a lot of scripts from a lot of different authors, for a lot of different interfaces. However, it is an absolute necessity. A major reason for sites being compromised, is that a lot of people install a script and leave it for years without ever updating it. Remember, just because it works, still, doesn’t mean it doesn’t suffer from a bug or security issue suddenly being introduced. Don’t be lazy about this. If you don’t have time, hire someone that does, or partner with someone to help you with your site that can help keep watch for updates and security notices related to your software/scripts.

#2: Don’t leave install/test scripts. Don’t start something and not finish it, this can spell disaster. Don’t ever install scripts as a test and leave it enabled, or any vital portion or extension of it. Many people will try out software, scripts or some new module or extension for a script they are either trying out, or one that they actively use, and then forgot about it, either not revisiting the install or idea or the extension on the programs they do actively run, and they can be left as sitting time bombs. Should someone access it and guess a URL location, they could use that against you and your site. Additionally to this fact, is that new installs often, until the setup is complete, will allow control over certain aspects of your site, so if someone accessed it before setup was complete, or if you kept the default password/login or set up an easy one because you weren’t sure if you wanted to use the script, then an attacker would still have access to run an install/setup script, which can allow for a lot of methods that most scripts won’t naturally allow due to the security ramifications.

#3: Passwords. This is a major factor as well. Always use secure, strong and unique passwords. Never use dictionary words. Never use the same password for your scripts, forum logins (including admin logins), databases or anything else, that you use for something else. In other words, if you use a password for your main email, FTP, control panel or other login, do not use this same password when setting up a database or when setting the admin login for a script, even just for the install steps. Never use the same database passwords for different databases. Never use the same password for a forum account that you use somewhere else. Clearly, this can start to become a hassle if you have a lot of scripts, databases, logins, etc., but once the database passwords are set, you shouldn’t have to remember them. They are going to be set in your script’s configuration files, and you can write it down elsewhere.

People far too often prefer to simply ignore the problem and instead go for the ease of using the same password across all of the dozens of web sites they visit online. If someone were to guess or obtain your password from one of those services online or otherwise, imagine how much data they could have access to. Some people use the same passwords for a web forum online somewhere, as they do for their hosting account, or for their online bank account, or for their paypal account, ebay account or even for their own forum admin login. Someone could log into your forum admin area and abuse that script to do things to read other passwords you have and then try those at the other sites you might visit. Always chose to go through the hassle instead of making it easy for a malicious user. Remember, if you’re using the same password to make it easy for you, all you’re doing is ensuring that you’re an easy target.

Also consider other than just where you use the password(s), but how you store them. The best method to store them, is to have a master password and use some method to have a local text file or database on your system, and that master password unlocks it. If you have a lot of passwords, consider having a file containing them, if you can’t remember them all, and putting an abbreviation of the site or service, without actually saying what site or service it’s for (that only you would know), and then consider encrypting that file with something like PGP, and make it so that difficult to remember, single password, is strong (only you know it). We also recommend against ever using a birth date, zip code, pet’s name, child’s name or birthday, favorite band, video game character, nickname, etc., even for a password reminder. That sort of information is far too easy to locate online, especially with how willing people are with the information they reveal about their lives in forums, blogs and their bio pages and so on.

#4: Script and program configurations. Pay attention to what information you supply when configuring a new program or script. Some settings will be more secure to not enable, and some will help the security of the install, even if from fraudulent signups, orders or memberships or posts on your site and script. Enabling login attempts and failures, if available in the script, is helpful, as are captcha (image code verifications) and so on. If given the option, try not to install the script at a common location, especially if it’s a popular script, and even more so if it’s an admin directory for the script. Should any exploits be known and you’ve not been keeping up on updates (let’s face it, most people just don’t do it), then an automated exploit “bot” can hit your site and submit and auto-compromise the exploitable feature in the script. Another good tip, is to disable access by adding password protection for a sub directory (such as an admin directory) that not everyone in the world should have a reason to access. Other options are to do such things as using a deny/allow rule and deny all IPs from access to the admin directory except from your IP or IPs (or IP ranges) known by yourself or staff you want to allow access to.

#5: Permissions and Ownership: One important thing, is permissions of your files and directories. Our servers are set up so you can execute scripts through the web server over http (and secure https) with lower permissions than a lot of script’s install instructions tell you to use. Instead of using a world writable permission (777, 666, etc.), you can set scripts to run with chmod 700, so only your user had read, write and execute permission. “group” and “other” don’t need even read permission, so only your user can view and run the script. Since your user is the user that actually executes CGI and PHP scripts on our services, you can ignore any instructions to set world read/write or execute on your script installs. In fact, world writable scripts will error and not run, for your protection. Any files that are intended to be world readable, and are non executable (not scripts), should be chmod 644 (allowing only your user read and (re)write permission, and the web server only read). Directories should be chmod 755 for allowing directory listing to show the files located within it to web users, or chmod 711 to allow files to be accessed within it, but not allow people to see all of the files located within it. Chmod 700 can be used for directories that will hold data that’s only intended to be read from and written to a PHP or CGI script and not be directly publicly accessible, though you can also consider putting the non-directly publicly accessible files outside of your web root directory path. This (the lower permissions) prevents web users, as well as any other users on a shared server from viewing or running or modifying your files, as well as prevents them from seeing your script’s source code or passwords on the server.

#6: Secure connections (SSL/TLS, etc.) Another important factor, is to ensure that, when possible, you use SSL for connections for sending sensitive data. Ultimately, SSL, tunneling, TLS, sftp, ssh, etc. are not really at risk, as someone would need super user access on the server or your network (or the remote network) to control and listen to data being passed over the network, to “sniff” out passwords or other data, but if you have an office where there’s a LAN/WAN or you connect out to the WWW (Internet/Web) over a connection where someone can have a listening device, or if someone did take control of the remote server or network, that they could at least not likely obtain your data, such as the password you use. Unfortunately, if someone has root access on a server, even sending data over SSL still results in plain text data being submitted to the server, if someone with that access modified the script or service on the remote end to capture the data sent over SSL, but that would only be the server side — it wouldn’t work on the network side and all bets are off at that point anyway (but it would still help to protect you in such situations so there aren’t multiple points of failure in a security sense and what data is able to be obtained for all services, if someone did compromise one). This is mainly just good security practice and behavior, since “just in case”, you want to take every measure to prevent a third party from being able to obtain the sensitive data you send and receive, so it’s a good thing to do as a personal policy. We don’t intend to get into the gory details about all of it, and where it really does any good or not and in what situation, but there’s never any reason not to practice this, so always use a secure connection when its available, be it for web, ftp, ssh, imap, pop3, smtp, or anything else.

#7: Site structure/design and miscellaneous: Never use a browser-side check for security or anything that can impose a security issue on your site. Always do all checks server-side with a script (using a PHP, CGI script, rewrite rules, .htaccess env var checks, allow/deny rules, SSI tags calling a script or environment variable, etc.) Be sure that any data you allow users to add or submit to your site or database is properly checked. Do simple checking to ensure there can’t be any injections into the database, any data added to the site or a file that could be executed (such as someone adding an SSI tag or some type of PHP scripting within the site, or any JavaScript or anything that could cause other views, or you as the admin, to have your information obtained or crash your browser. Things such as stealing cookies or guessing sessions, etc. via an exploitable weakness or some type of cross site scripting attack). Also, keeping in mind the files you have, any loose files, old files, and their contents, can sometimes be a problem and provide information malicious users can use against you, especially if they are executable scripts, database dumps stored in the web root and things where files are renamed as copies or backups, such as mysqdata.sql or myscript.php.back (it will no longer be executable and people can view the file as a text file, for example). Also, other things such as upload scripts, where people can bypass the file extensions you try and limit it to, or upload a non image file (script) and execute it by uploading an .htaccess file to make all files executable, and image.gif is now a script or compiled binary they can run.

Other things to consider, such as your robots.txt file, and what directories you disallow search engines to access. Anyone can view that file (though you could disallow it for non valid search spiders, someone can fake the user agent), and that person could then see all of the directories or files you are hiding from search engine indexing. That is not an appropriate method to hide anything, and in fact, if you don’t have any links to that area that are able to be indexed (followed) or seen, you shouldn’t have to worry about a search engine indexing it anyway (it doesn’t know what files you have on your site, unless there’s a link in the public area or page for it to follow, like any browser would — and legitimate spiders don’t guess at file names). Also, if you suspect anything, watch the error and access logs for your site (but don’t get too worried when you see the very common exploit attempt request by exploit and spam bots that randomly go across the Internet trying every IP and domain for attempted, generic and usually very old exploits).

Conclusion and further options: These are just a few very simple and common things, which, if followed, should greatly reduce the chances of an account/script being exploited or defaced. It ultimately comes down to how secure the script is that you decide to run. For further protection of your site and reducing the chances of an exploitable script you might run on your account from causing damage to your files, please feel free to contact us, as we offer a very unique file locking service GUI for our users, which allows you great control over the files on your site. Stay tuned for an announcement about this service in the next few days.

Some companies really try too hard. Often, they are doomed from the start. Even if they are “successful”, it’s usually attributed to nothing more than luck. Few operate or value experience and skills and appreciate their clients. Often, owners and managers that (poorly) run these companies will proclaim themselves “entrepreneurs” and “clever businessmen”, believing they are the reason for the company’s success, when it’s usually their staff that they ironically lack appreciation and respect for that really explains any small or large amount of success they might have. Yes, being a child of wealthy parents that are willing to shell out tons of cash to over expose their child’s web hosting business, doesn’t actually make you the reason for the company being a success.

Moreover, they outspend themselves for the sake of trying to impress “bigness” and “importance” upon potential clients, and even more sadly and ironic, other companies in the web hosting industry. They will stop at nothing to stay “on the top” of lists, paying affiliates 10 to 50 times what a client would pay them for hosting even if that client stayed on them for many years, just to get the client in the first place. Further to this, then toss in a free domain for life. Even more crazy, they will promise unrealistic and impossible hosting plan limits, in the hundreds of gigs to many terabytes of both disk space and bandwidth, or even claim there is “no limit” (unlimited). They offer these unrealistic limits for only a few dollars per month, even though their entire server they host a 100 or more clients on, costs them $1,000 per month, and only holds 1/10th of the space they promise for just one single client’s account.

Let’s face it, stuff costs money. There’s no way around it. You don’t pay a thousand dollars per month for a dedicated server that has 1 (one) Terabyte of disk space and 5 terabytes of bandwidth and then sell 2 terabytes of space and 15 terabytes of bandwidth for $5/mo. You don’t have to have a degree in mathematics or physics to understand that they would lose hundreds of dollars per month to host that one $5/mo. account, if they actually intended to live up to their promise and provide the disk space and bandwidth the client paid for.

They rely on extreme overselling to “average” out the usage, claiming that if 100 clients on the server only use 100 megs of disk space and 1 Gig of bandwidth, that they can offer the other “high usage” clients their promised limits. This isn’t true, at all. This still means that they don’t have enough physical disk space to meet that single client’s needs if that client did use anywhere near their promised limit. I personally know of a very popular, very large and known web hosting provider that promises huge limits and unlimited, yet I know for a fact that they can’t deliver what they promise, so they find reasons to kick users for not using too much CPU or memory resources, but because they are presenting a risk of financial loss (because they can’t give away that much resources).

That company claims to have large disk arrays so each server can offer that much. Well, they actually don’t. Their disks (in total) on the servers range from 250 gigs to 750 gigs, with only one or two available, or in a raid array to total about 1.5 terabytes. Yet, even then, without any other users and without any OS install, logs, etc., not disk usage at all, it’s still not physically possible. They then changed their story to say all sorts of things about using different technologies to cluster servers and their disk space to “overall” average out the total across the server farm. They have no such method implemented and regardless of how you view it, those disks and that bandwidth still cost money (a lot of money), and once again, once a single client poses a risk to the usage of the server’s disk space or bandwidth, they are now a financial burden, because their extreme overselling tactics backfired on them.

They have an easy out though, and often use it, claiming the site was getting too many accesses, using too much CPU time or too much memory. Sometimes this is true and a legitimate cause, and this is a case that any web host, extreme overseller or not, will have to take corrective action to protect the server, its services and the other clients (assuming it’s a shared or reseller server). However, in these cases, it’s often not true and is claimed because it’s an easy excuse to kick the client without having to face public ridicule if the client could prove they were kicked off the host because they tried to use their promised resources that they paid for! The theory by extreme oversellers is flawed and is essentially saying that “if a site used that much disk space and/or that much bandwidth, they will use up too much CPU and/or memory on the system before they ever became a financial threat and we’d kick/suspend them anyway”. This isn’t always the case, but you can bet that it’s the case claimed when they suspend/kick them.

In all fairness, some hosts might have some type of affiliation or sponsorship with the high usage client, because a well trafficked site that provides ads for your hosting service, can benefit both parties. Such as a “hosting site index”, which sadly will usually overexpose their vested interest “sponsor” by putting their ads more prominently and even make it appear on a “top 10 list” as if their sponsor has the better ranking or quality, which is even more unfair to the other hosts that (sadly, too) have to pay to be on that top 10 hosting site list, because their services are less appealing to the naive web user looking at those lists for the best, top 10 web hosting providers. Of course, those are all essentially portals where someone has affiliate links and gets paid per client, and puts up a list of the 10 highest paying referral programs and makes it appear as though all hosts on the list are high quality, well ranked (by votes of happy clients), when in fact, they are nothing more than a trick to get themselves money and the affiliate couldn’t care less if the host was any good, or even a legal operation for that matter.

This issue is broad and varied, and it’s difficult for a client to find honest, real hosts, and hosts that have experience, skills and really know what they are doing (from running the company, to offering support and keeping a secure and stable hosting environment). The competitiveness goes to what I was speaking of originally, above, where these companies literally outspend themselves, creating excessive and unnecessary overhead, where just to stay on top and saturate the market, they’ll pay more for advertising than they have coming in. Everything from getting the top spots on certain web hosting forums and web hosting centric sites, to paying $10, $20, $40+ per click on their ad link (where only 5-10% of the users will actually order service anyway, and the one’s that do, will only be paying a couple of dollars per month). These people are happy to hemorrhage money just to look bigger, and therefore, in their minds, appear better.

With this sort of mentality, no one wins. Not them, not their clients, not their staff, no one. Their staff have no job security, and the methods used to run and manage the company by unqualified owners and managers only drive the qualified staff to leave and seek employment at a company that has a better head on their corporate shoulders. They have no future, unless they revert back to normal plans where they stop trying to only undersell the competition by lowering prices and offering more, when it’s not a truthful limit they claim to offer (they can be very generous and still be realistic and make the same amount of money). The fact is, companies that operate like this, regardless of how much they believe they are marketing geniuses, are only staying afloat, because they are managing to keep enough new clients coming in due to overexposure, for now. When that stops, new marketing money goes away, people get laid off, more clients start getting kicked and the company eventually folds.

No matter how you cut it, no matter what irrelevant and poor examples companies give about cell phones, airlines and the generic word “overselling”, this is a completely other animal altogether. Common sense and very little or even no education about the hosting industry dictates that certain things aren’t possible. With a cell phone, you and thousands of others can leave them on a call 24/7, all day long, all month long and be within the contracts’ terms. Airlines, while they might bump passengers from a flight, will still get you on a flight and still give you the service promised, even if you have to wait several hours. Neither of those examples try and overload circuits from a single client’s use, or overload the weight limit on a plane and claim it’s safe. It’s economically foolish and reckless, and it’s a terrible business model with no future.

Companies will continue to skirt around the laws of physics, because it’s hard to prove that they won’t offer what they claim, when they claim a client abused the system’s resources and kick them when they start to cost more than the client pays them for hosting. If they want to play that game and disrespect their existing and potential clients, and just try and impress people with the biggest numbers for the lowest price, fine. However, let’s not pretend it’s possible. The fact is, they undersell because they have no real service to sell people on. If you offer quality and honest service, people will flock to you, you’ll earn their business and they will be happy. Companies like that only have happy clients, because those clients haven’t had a need for truly exceptional service and probably have never experienced it and have nothing to base their opinions on in comparison. If the client is happy enough, that’s great…. until they get bitten in the end for using a reckless, irresponsible company that has no business in this industry. However, then they will look for the quality, legitimate and honest hosts, whom still offer great service and generous limits (more than they’d need anyway, without making up ridiculous limits that can’t be met), and things balance out in the industry. Unlike those that are overselling to some extreme level that just destroys the integrity of the web hosting industry, because they aren’t helping to make things better at all.