Sometimes, it’s more than the whole that accounts for quality. Sometimes, it’s in the details, even small details. Some people seem to have the opinion that running a service and offering features, keeping things up to date, secure, but evenly balanced and friendly for the client base, is a reactive task, or one they view as merely a task to perform.

The popular view on systems administrators, is one that if they are too involved and enjoy the job and take pleasure in it, that they will end up being a techno-geek that is rude, terse, unhelpful or essentially carry the attitude or manner about them that makes them unable or unwilling to communicate details to the client base in times of support or even pre-sales questions. This is sometimes the case, but as usual, it’s the person that fails to live up to the simple task, rather than the job details or enjoyment and delving into the subject that has this result.

One doesn’t have to be related to the other and should be the opposite of the negatives you see and hear (and experience) at the hands of support representatives, be it the local cable, dish, or phone provider, or calling with a simple inquiry if you happen to already know the answers and want a simple yes or no about supplies. Indeed, one’s enjoyment and growing interest and skillset should have different results, more positive, more helpful, knowledgeable staff, yet not losing touch with the important things or being unable to explain or help in a way that doesn’t require similar knowledge from the client base, and also still having respect and patience. For some reason, this is sadly uncommon in the technical field, and I fail to understand why. Luckily, this is something we don’t experience here between fellow staff and I’m glad for that fact.

What a difference the details do make, and the pride of service and quality. These things seem lost in the service world today and greed seems to be the primary motivating factor for the foundation of many businesses today. Why not have a successful business you can take pride in, instead of creating a business to create fear in your staff, having them worry about their financial future, all for the purposes of greed or egoism? Look at the Japanese, so many people living in such small areas of Tokyo, living in their own areas of commerce, the work force and private pleasures, and places that cater to those specifics; Each area is so specific in their services, they excel to a degree where these small details are magnified and it really shows. A small bar that only holds 6-8 people, a knife making factory, the art of arrangements and so much more. Details so defined and with so much care that you can find that simple pleasure of drinking at a neighborhood “pocket bar” that it’s nearly perfection. Adding all of these things together, makes it that much better, from the product to the service, the quality is there.

These simple things, the desire to delve deeper into a subject, the pride of craftsmanship, word of mouth, a good day of serving your client base and knowing everyone is happy at the end of the day or shift, is a good feeling. People don’t seem to care to strive for that much anymore, probably because they are busy worrying about profits, sales tricks, and have their head in the clouds and their feet elsewhere. It’s good to break away, relax and not worry about every little thing, but when it gets to the point of recklessness, uncaring and poor service, it starts to affect the clients. There’s always room for improvement, and a chance for a small detail to have a major impact now or later in a positive way, especially when you consider all of the small details that add up to the whole of the quality and experience. Unfortunately, this just isn’t the norm for many companies, and we all see it. It would be nice to see a mass change in this manner of thinking and view by some companies, though I won’t be holding my breath. Rather, I’ll enjoy perfection of things both big and small and always work for something better. I know there are those out there whom appreciate it, I know I do.

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.

Let’s face it; problems happen, people aren’t perfect and some things are inevitable. However, it is interesting to take notice of how many problems and disasters could have been prevented or dealt with before things escalated to a point of no return (being too late). Just like the Chernobyl nuclear reactor disaster, and the British Midland crash of flight 92 near Kegworth, Leicestershire, UK in 1989, looking at the historical facts, you realize how these tragic events were part design, part equipment failure, and, ultimately, part human failure, which played the final and tragic role in the chain of events.

The same holds true in the technology industry. One must have the experience to properly recognize and deal with the issue, the knowledge to take preventative measures initially by design and preparedness and the best methods to handle the situation, and above all, communication policies to ensure everyone knows what’s happening, what you’re doing and what they are doing. Poor management, poor decisions by owners to place unqualified people in certain positions or what tasks to perform, can add to this issue as well. Such as assigning their friend from high school into a general manager position, rather than doing so because this person possesses the related skills, experience or even a level head with a good idea of common sense to properly manage people and delegate tasks. Communication isn’t offered or encouraged within some companies, and their servers are just running on a wing and a prayer.

The Chernobyl incident unfolded because management demanded a less qualified and less experienced night shift crew run vital tests, and those members didn’t properly communicate with each other. While one crew member was performing pre-test checks by reducing the power and balancing the heat and steam of the system with the cooling tank in relation to the steam output (which involved reducing the number of control rods to get the turbines to turn enough to generate more steam, to in turn generate the power to pump water into the system), the other crew member was adding too much cold water to the system, and wasn’t getting enough steam due to too much water, and he therefore cut off the water supply to the cooling tank that lacked far too many control rods to ensure a safe balance, so it quickly overheated beyond their control and caused a meltdown. Had the crew member communicated that he reduced the number of control rods well below the minimum for safe operation, then the crew member that was operating the water cooling aspect would have known that there wasn’t enough control rods to keep the cooling tank in check and would have kept water flowing instead of cutting it to get the steam needed. Simple communication in an array of many variables could have allowed for a major disaster to be prevented.

The mention of British Midland Flight 92 could have been resolved by communication, as well as proper training with a flight simulator for the new Boeing 737-400 they were flying, which they only had under 50 hours of experience in, each. When a problem happened, they could have more accurately diagnosed the issue and prevented a disaster. The model was new and instruments were different. Key elements were different in this model that played a role where it gave the experienced pilots reason to believe that they resolved a problem. In fact, they had a bad engine and due to lack of communication and knowledge of the system, they shut down the wrong engine. Due to how the fuel system was designed, they thought the issue was resolved immediately after disengaging the good engine.

They were unable to see which engine was the problem, and while diagnosing the issue initially, they had concluded that it was the right side (good) engine, because they could smell smoke in the air conditioning system. The system on these planes always came from the right engine. Unfortunately, this changed and used both in the newer model. They informed the passengers that they resolved the problem by shutting down the faulty engine on the right hand side and were preparing to land at the next available airport. Ironically, the passengers saw the flames coming out of the left side engine, but no one said anything or alerted the pilots, because the passengers simply assumed that the pilot is the professional in this case and must know what he’s doing. In this case, he did, but wasn’t familiar with the new model and lacked training for it when dealing with emergencies like this, because things were changed around. Communication to inform the pilots that the passengers observed the other engine as the issue, would have allowed them to quickly review and remedy the issue. By the time the bad engine completely broke down, they didn’t have time to start up the good engine (which they thought was bad). The initial report was that both engines must have failed, which is about 100 million to 1 of happening on a new plane. Unfortunately, not realizing any of these things while the incident unfolded was what ultimately caused the crash.

Problems will happen due to a variety of reasons, but how familiar are the staff with the technology, service, the equipment, the protocols, policies and how good is their communication? I’ve personally worked with companies that have terrible communication and that was the case the entire time I was working with them. No one was willing to fix or consider a review or consultation of what could benefit from being fixed, regarding communication or how tasks were performed. Therefore, you had support staff unaware what the admins were doing, and admins unaware what support staff were telling clients. Worse, you had owners and managers that didn’t have any technical knowledge or common sense making reckless announcements to the public, and only then informing the admins to act on it and “make it happen”, regardless of how uninformed their decision was or where it came from.

Support staff have clients asking questions they don’t know how to answer, because an admin was told to “make this happen right now”, which adversely affects the clients across the server farm, and the client gets rightfully upset when asking about a major change, only to have a support staff member clearly appear clueless, and by all accounts, they had no information passed to them about this major change. In fact, only the admin making the change was filled in on the change and no other admins were. This wasn’t even a situation where one admin was more senior, but simply was the one that the owner picked at random to request they make the change. Meanwhile, another admin on a newly started shift receives hundreds of reports of problems, sees the cause and fixed it, only to break what the other admin had done earlier, at the request of the owner. This is one of many examples and problems about how poor planning and lack of infrastructure cause problems.

Any major change needs to be discussed with staff that have the technical knowledge. If the owner has an idea, s/he should run it by the people they hired because of their knowledge and experience. Find out what’s possible, what’s likely, what options there are, how it will effect the clients and servers and the services ran. Will it pose a security issue? Will it pose a stability issue? Will it cause a disaster? Will the company be able to recover from such a disaster if it does? Should it even be considered? Is there a real, valid and relevant reason to offer this, or is the owner just in a mood that day? Has the owner lost their mind, were they even thinking? Rather than just come up with an idea and act on it, discussions need to be encouraged. Is this something the staff have a lot of experience in, or any experience in? What are the benefits, and what are the drawbacks? Should this be implemented immediately, soon, or in the future? How much notice can the company give to the clients?

Does it dictate that notice is a good idea? Will this force clients to make changes in their site’s code or how their programs run? How long should be given and what discussions should take place before we plan a major change? And many more questions. Somehow, these things simply aren’t considered or a concern for owners and managers. Why? Because they are truly not qualified. You hire people for their experience, skills, knowledge, insight, ideas and trust. If they are hired because they are more experienced, more skilled, more knowledgeable than the owner, the owner needs to trust them, and trust their input. Any staff member, on any level at all, should be allowed an opportunity to be heard and any relevant suggestion, concern or experience they can offer, should be allowed for consideration. Instead, if there are any, it’s usually only involving one person and what happens when that admin doesn’t know as much as another admin about a topic? What happens if they get hit by a bus? What happens if they don’t know everything? At this point, should they really be relying on the one admin that’s their best drinking buddy, or ensure that all admins are equally aware of the decisions and have an opportunity to allow input and perhaps a superior skill set and experience in that area? This is if they even go that far. You might be surprised on just how many companies, even very large one’s, operate in this way.

The more eyes, ears and brains looking at and hearing ideas and considering the options, benefits and issues it could bring up, the better. How any company can operate on the basis that they know best because they own the thing or are friends with the owner, to the point where they either dismiss all of the good things that their staff can being to discussions and ignore their value, all because of smug and ignorant management and owners, is a recipe for disaster. It could be on a technical level, a customer service level, or even right down to how the company represents itself and the services they offer and how they offer those services. Everything in business, especially dealing with so many services, reliability and security ramifications of everything you say or do, and how it impacts the clients and how it conveys the way your company operates to the world, sometimes dictates more consideration, and some type of policies to be encouraged where people are offered an opportunity to be property trained, offer input, and above all, to use good communication.

Sometimes lack of these things can cause issues here or there that can be resolved, assuming it’s not a constant and ongoing issue, but other times, it can cause significant and major issues that are effectively disasters. Anything from reputation, to lack of proper backups due to having systems wiped because security was lax. Now what are they going to do? I suppose if they are large enough, they’ll survive, and there will always be enough people tolerable enough of anything to simply proclaim that no one is prefect and problems happen. True enough, but could these things have been prevented, are the people in the positions because they are qualified to be, is the company being responsible, and do they ultimately care?

If you don’t think there’s a monopoly in the web hosting industry, you’re dead wrong. While none of us involved in BurlyHost.com, Inc. are new to this line of work, our company is fairly new, and being new you have to get the word out — which means advertising. Try going to any of the popular web hosting forums and tell them you’re willing and ready to pay their fees for advertising and you’ll quickly find that the current hosts in the industry have completely saturated and monopolized the market.

Some forums have only one company per area, say under “web hosting” and its sub forums, while others offer such campaigns as well as run of site (ROS). Some allow only a single company to have an ad, and some allow several. Regardless of this, the current advertiser is able to completely take over and keep their position and no slots are available for any new advertisers, regardless of the fees they’re ready to pay. The current companies have locked in their positions and they continue to renew their ad programs with these forums every month, quarter or year. They also have first rights to refusal, if they wish to continue the ads or not. The ads work well, so they continue to run them.

In other words, there is absolutely no room or availability for anyone else, even if they are willing to pre-pay for a month or quarter or year of advertising (we’re talking tens of thousands of dollars, potentially each month and beyond). They say there are no available positions and there won’t be any in the foreseeable future. Therefore, the current companies have locked into leaderboard, skyscraper and other prominent ad positions indefinitely and there is no way anyone else can advertise on the same level. This makes it very difficult to break into the same category on the same playing field as the hosts that have effectively and literally monopolized upon.

I have personally worked with and for some of these hosts in question and have been a member of these forums for 8-10 years (on one of them I’m user #45 out of over 200,000 members), and I can tell you with great accuracy and truth, that knowing these companies and how they operate, they will never let go of the ad positions they have, and they will quite literally outspend themselves to remain at the top (meaning, they’ll spend more money on ads to stay the top dog on these forums and hosting lists, than they’ll have coming in, and I mean in a perpetual fashion, not just them being down one month and up the next, but their willingness to be down every month, just to try and impress some people or try and intimidate others).

Therein lies another issue. The forums themselves. They are in this for the money, only. They will say otherwise and act like they are a community for the people and to offer help and a fair, unbiased web community, but they’ve made a business out of buying popular web related forums and directories that have been built up, so they can benefit from the traffic and make money (i.e., selling ads). This is fine, this is how it works, but to pick and chose and lock in only certain companies and not allowing the competition to compete and advertise on the same level, is disappointing to see. In fact, given the option to instead consider advertising on significantly less popular and trafficked “web hosting directories”, I had mentioned that new clients will not click on a company that doesn’t over sell at an extremely ridiculous level.

On a directory list, you would pay to be on a list with 30 other companies, and everyone would offer “unlimited” disk space and bandwidth, or TeraBytes of space and bandwidth for $5/mo. We will not lie to clients or trick people into using our services, so we’d be on a list of 30 choices and be the lowest (and only honest) one. No one new to hosting would see the specs, compared, and choose us. Thus, you’re paying for nothing other than the random illegitimate click through. Simply put, when you’re competing in specs, you can’t compete on a list of 30 dishonest, greedy companies and expect a good return on your investment. The only people that win in that situation, is the company you’re paying so you can appear on their list. These lists are completely biased, as almost every single top 10 and best web hosting guide is. It’s sad, but true.

Upon mentioning the lack of value in competing against hosts that post fraudulent numbers, without prompting this discussion, the staff member at the ad company explained that “this is why we don’t allow people to use the word UNLIMITED” on the ads, because, he says with a chuckle, well, physics dictate it’s not possible”. I agree, and this is why we’re not going to sink to that level. However, I said in response “You realize, that almost every company you have locked into and monopolizing the leader board and skyscraper ads on your forum offer unlimited plans, even if their banner ad doesn’t use that word? Even so, the banners DO use the words that claim you get 8 Terabyes of bandwidth for $5/mo.” His response was that they have no control over what the companies do on their own sites.

Clearly they do not control what’s on the company’s site, but they are aware of it, and while they think it’s unethical to allow advertisers to use the word unlimited on their ad because they say “it’s not possible”, they don’t mind allowing a dishonest company to post ads, just as long as it doesn’t have the dishonest verbiage right on the banner ad image itself. Interesting. So, they are uncomfortable with “unlimited” claims, but they do allow them to splash claims of 3, 5, 8, 15+ Terabytes on them, which is equally impossible. They have the sites to make money, which means they’re not going to care that much about what companies they allow to get ads and display for them, but why pretend you have an ethical line? You’ve locked those companies in and allowed them to monopolize your popular web hosting forum and you don’t really care what they really claim to offer, provided they continue to pay you… and really, who will complain if those are the only choices?

The fact is, users of the forum, this is all they ever see and while it’s hotly debated about how unethical unlimited and extremely impossible high limits of space and transfer limits on the forum, user’s get used to it and accept it as the norm. After all, why don’t any non extreme oversellers place ads there, it *must* be working, right? Wrong, it’s because they have managed to be the only one’s that are “allowed” to place the ads, which gives that impression. There are plenty of hosts that offer generous (more than a client would need) amounts of disk space and bandwidth, whom are honest, realistic and talented people running web hosts, and they respect their clients enough not to lie. Anyone can claim unlimited or high numbers that aren’t possible for the price charged, and hope and pray not many people actually use much, but if that’s the case, why play some childish game about numbers so high that it makes the company actually look like they don’t know what they are doing. After all, if they did, they’d know how those claims make them look and how poorly it reflects on them.

Of course, none of that matters, since the extreme oversellers have been allowed to monopolize the market so much, that no one gets much of a chance to see what other specialty services, custom services or high quality plans that any other host with their head on their shoulders and a clue of what they are doing, could offer to them (their potential clients). In other words, there’s not even a means for these other hosts to get the same type of ads to show people they have a choice or to start a healthy discussion about what host might be better and why. Instead, the people see the same few hosts everywhere they go, everywhere they look and every time they search, and they figure “why not, what have I got to lose?” They try it, and they usually are disappointed, even possibly thinking this is how hosting is, so still why look for anyone else that doesn’t offer impossibly huge amounts. These people seem fine being lied to. Out of those people that were ignorant about the facts and either don’t know or are content with being lied to, some will come to tolerate it. Enough people tolerate poor service, the bigger that company grows, the more ads they display and the more new ignorant clients they get and the cycle continues. Good for the greedy host that lies, bad for everyone else.

Just formulating a business model by outspending yourself to be the most overexposed host with ads, everywhere on the Web, offering unrealistic things for too good to be true prices (and it never is true), is the same mentality the banks had with the sub prime loans. You can only operate for so long, and the more hosts that compete with each other to offer things that aren’t tangible or true, just for the sake of underselling the competition to get that client before the other guy does, is not only chaotic and nonsense, but it will spell disaster. You can’t operate in that fashion forever and things collapse. Just like the housing bubble, they knew it was a risk and didn’t care, all for the sake of competition and now the economy has been severely impacted in a negative way. This is the absolute same problem with extreme overselling. It’s a model that isn’t mean to last, it’s to feed on the ignorant and make a quick buck. No plans for the future.

Nothing is going to be free, so they clearly can’t give it away now or plan to in the future, especially when you consider they sell for $5/mo. 3-8 TBs of disk space, yet their entire server only has 1 TB total, and has 80-300 clients (depending on the number of accounts they house). You don’t have to have a degree in mathematics to see the problem with the physical limits, nor do you have to have a degree in economics to see that it’s financially impossible and reckless. They live on a fine line that operates on the notion that they can keep making these promises as long as things hold up. Some companies last longer than others, but ultimately it’s a sure fire sign that they have no idea what they are doing, even on the very basic business sense. It’s no secret that a great number of online businesses, especially web hosting providers, are run by owners and managers that really have no business in the field and luck is usually the only contributing factor to any success they might see. However, anyone that continues down this reckless and greedy path of lies, is eventually going to run themselves out of business.

That is only a very small part of the problem with the companies themselves, but going back to the forums and hosting review sites, they just don’t care. The ad sales rep I spoke with recognized me, knew who I was and I know several people there who work on the forum/at the company that respect me. He said that he’s seen a lot of people try the business, but knows that I know what I’m doing — and without sounding egotistical, I do! I’ve been doing it for over 17 years, just regarding web hosting, not including computers, programming, communications before that. So, rest assured, I have some idea what I’m talking about. Even so, this doesn’t sway any policies or facts of the matter, and that they’ve given up their ad space to the same people that are knowingly reckless about their companies and make fraudulent promises all based on the odds that enough people won’t use enough to expose them and their lies.

This is how it is. So be it. However, here’s where the problem continues. Even on their forum alone, some moderators, as well as community liaisons have prominent links to their own “hosting review” sites of “the best hosts”, of which are nothing more than propaganda about how great such and such host is, how much you can trust their list or hosts and how honest the hosts and they are, yet every sub page with detailed information about the company they are promoting, allegedly without motivation or bias, all have affiliate links, which point to that host’s site and they are paid per referral. They argue that if you like a host and would refer them anyway, what difference does it make if you’re paid? Well, besides the financial motivation, they are a community representative, and this gives more credence to what they say, at least to the members. They rightfully assume they can trust them over just any random person raving about such-and-such web host. Also, consider their stance if they had another company that paid $500 per referral, instead of $100. Who do you think would be more recommended? This is out of place and biased and is allowed.

The fact is, people go to these “communities” for unbiased information and reviews. People understand the reason and need for the people to make money from running the site, and make it worth their while (maybe by a lot), but when they allow unethical hosts to place banners and corner the market there and lock out/deny any competition that has a different view and plans that are actually honest (maybe this will shatter the image of the lying hosts) and don’t care that they violate their own rules of not offering impossible limits, how does that make them look when they decide to turn their heads, provided they have money generated from displaying those ads? I guess you can’t blame them, right?

Money is money, they are selling advertising, not hosting and they “make no guarantees”. Great policy, especially when you know they aren’t able to give what they offer. So much for morals. Now, let’s consider them allowing moderators to “recommend” and “defend” hosts that do this, and how the mods and community liaisons are allowed to have their own “hosting review” sites that are nothing more than affiliate links. This is their entire activity throughout the day. They post as a trusted member and community leader, only to have vested interest sites promoted on their own link within the forum. So what if most members don’t know or realize how biased it is, if they are happy with their choice (assuming they were told of all of the choices they actually have, which they never are, for obvious reasons), right? Let’s not consider playing fair or being honest, because in the end, tricking someone into thinking they got the best deal at the best host, is better than them having risked the odds of making their own informed and unbiased choice. Surely someone with financial motivation knows more about what the client wants than the client does, right?

Heck, the one “community liaisons” that sticks out in my mind like a sore thumb, frequents several of the most popular web hosting forums, gaining trust of the new members, and makes an actual career out of posting (I mean this literally, it’s their job, they do all day), so people follow the links and they get paid for each referral (rather handsomely, I might add. I know of affiliates that do nothing more than post in forums (usually nothing really helpful, unless you count their “view” and “opinions” about “hosting recommendations” or enjoy seeing them argue with people while they defend a host that just happens to be on their “honest hosts” list — big surprise) who make over $50K per month). Usually these people post for the sake of posting, finding any excuse to discuss a topic and offer nothing of value, hopeful people will follow their signature link and trick another person so they get another $100 for that single referral.

Ironically, some of these hosts they defend on their list, I know more about than they do, having worked with some of them, and know exactly how they operate, so I can immediately see the financial motivation. All of that said, all of these activities and inconsistencies and going against what they claim is unethical by allowing it anyway, and so much more… considering these things, what value and purpose do the forums have any longer once they start operating like that? No wonder people lost their heads when they found that the forums were bought by ad companies after the original owner(s) sold them. They aren’t the same, but by all accounts, they can’t be the same. You have to take these things with a grain of salt.

Apparently, the trust, the non biased input and recommendations and all of these things everyone pretends to uphold, at this point is really nothing more than ensuring financial self preservation, ensuring they are the only one’s allowed to do it and benefit thusly in a financial sense. Only select people are allowed to actually have prominent banners, and only the community leaders/liaisons and special members can really get away with this, while I’ve seen new users come and go and be ripped apart for making their intentions obvious when they try and rave, recommend and post/ask about and bring attention to a company they are affiliated with and also get money in exchange… but that’s against the rules. This entire thing just smacks of the tactics of those that are involved in and allow this monopoly. The web hosting community forums are not what they used to be, they are not as I knew them. They are a money generator now, and nothing more. The intent to build a thriving community was clearly only with the goal of creating a monopoly. This is nothing different from the many, many “top ten hosting lists” and “honest hosts lists” or the “best ranked hosts” or other “hosting directory” or “hosting guide” sites.

Back in the day, people could buy ads in those “top lists” and “directories”, and the rest would be (usually categorized) areas for the list of known hosts that were not fly by night. Then the people that buy ads rightfully get the most exposure, and the other hosts are all ranked on reviews by real customers. They’d be pretty fair and non biased, so people could make informed decisions, not being tricked and swayed by only what they see (or can see) in a forum that claims to be a hosting community. Sadly, now they are only “portals” that are just lists of the top paying affiliate programs from the top 10 highest paying companies. They care nothing about the integrity of the companies and want to make money, nothing more. Any ranks or reviews are created and fraudulent in most cases. There are now thousands of these top 10 and hosting directories, and if you look closely, you’ll start noting that these directories and top 10 listing sites are paying for ads for people to come to their site. This includes google ad words. Most of the top paying sites you get results for, are the top 10 lists, and that alone should be a tip off.

Essentially, they operate like any other spammer and trick people into using their site, so they get paid when you are suckered or tricked into using their list. You’d hope that chances of avoiding such things by advertising in a trusted community that’s been around for years would help remove all of that clutter and give potential clients a fair shake at finding the right host for them, but that’s not the case, it’s the same product in different packaging and no one else is even allowed the opportunity to put their service out there. Sure, you can, but on a much, much smaller, trivial level, if you were to try on the same site. “Sorry, all of the good ad slots are taken by the same hosts that have taken all of the available slots on all of the other forums (hosts willing to outspend themselves to stay on top and offer specs we know are untrue), but you’re welcome to a small text link on a pay per click basis, which is located at the bottom of the forum where no one in their right mind would be looking.” God forbid, the last thing we want, is for the clients to have a good chance of seeing all of the different companies that they could choose from. Good luck finding a legitimate host that is interested in service and quality, rather than underselling in price and overselling in specs, to grab as much money as quickly as they can. That’s the way they want it, so that’s the way it is. Disappointing.

Note: To make matters worse about the above issues, is that these hosts practice tactics where they effectively recruit an army of spammers to go around forums and post or comment on blogs, etc. to get the word out, which goes to their fake “top hosting list” sites and has the affiliate links. Not less than 4 hours after posting this article, a spammer actually commented with some jibberish on this blog article (luckily we don’t auto-approve comments for this reason), which had a link to their hosting list and had the top 10 very spammed hosting providers. You notice in a lot of blogs, newsgroups and hosting sites, that this is common, the same hosts listed, the same hosts spammed and the sleazy army of people that just want to make money for a referral, so it breeds an army of spammers to promote their service. They don’t care how this reflects on them, because spamming generates business and money for both the spammer and the company they spam for. The depth of sleaze practiced by some people in this industry knows no bounds. This might explain why affiliates of these hosts are seen posting “hosting deals” on forums (only the company should be posting hosting deals, per the rules), when all they do is direct traffic to the host in question so they can get their money.

Try as I might to get Mozilla (SeaMonkey) and Firefox on Linux (CentOS 4.6 and 5.x), all versions of both browsers and all versions of Flash, either from source compiles, (tricking and modifying) install scripts, to RPM’s, some intended for the 64 bit platform, Adobe Flash would sporadically work or fail. It would work for minutes, hours or days, but eventually overload the browser and I’d end up hitting a page with dozens of flash files, each of which prompted for the plugin to be installed (even though it was, it just resulted in npviewer.bin segmentation fault (segfault) errors).

Adobe seems to have little or no interest in supporting Linux 64 bit. One developer at Adobe was thoughtful enough to offer some solutions, but ultimately, these versions failed. After the prompts for the plugin and sporadic instances of Flash working or not, the browser tabs and windows would disappear in an instant and instantly crash. Having tried every possible combination (I did get it to work, after all, in many different ways), never resulted in a stable install.

Therefore, I have finally gave in and simply decided to force the installs of the browsers as well as the Flash plugins, to use 32 bit (linux32). I was resisting this, because I hate to resort to accepting defeat with tasks and problems I have so closely almost resolved so many times, and I still had other ideas and tweaks, but since so many sites require or include Flash, it became too much of annoyance (and then worse, a legitimate problem). I was not liking the options presented altogether, since Adobe won’t release the source code. Even if they would, I really don’t have a lot of interest in spending time modifying their code in an attempt to fix it (and then what about the next update?) Luckily, I didn’t have the option, since they wouldn’t release the source anyway (not actually a good thing, but made the decision easier and therefore saved time).

After fighting a losing battle, and just saving time and hassle, after it become too frequent, I simply resorted to forcing 32 bit for Mozilla/SeaMonkey and Firefox. You can use linux32 to install the programs, if you need to (especially for the install script for Flash, or it’ll error with an x86_64 arch incompatibility and will not run (linux32 actually uses setarch so uname -m (machine/hardware info) outputs/sees in86/arch instead of x86_64)), but ultimately the primary and simple solution is to use the path to use linux32 before the command (the path to the browser binary file). I was well aware of this, but simply resisted in an all too long, waste of time, attempt to fix the issues of another company’s browser plugin/addon that is compiled so I can’t change it or have the control that would be needed to resolve the bugs anyway.

So here I am, finally enjoying the fact that my browser works in Flash (even if the browser has to run as 32 bit now), and not being prompted for plugins or seeing the browser crash and instantly lose all of my open tabs/windows. I gave it a good shot and in the end, it was better to just go with what will work. A little disappointing, but I didn’t have time to mess with that anyway. It’s just a browser and it just needs to work, securely and efficiently, and allow me to view sites I need to view (most of my day is spend in an SSH shell command line anyway). Sometimes it’s better to move on and not fight the inevitable. For those of you having random bugs with the Adobe Flash browser plugin on 64 bit Linux systems, I recommend you heed this advice, as I’ve tried all solutions and even many of my own and it was never 100% successful. Linux32 will serve you well in this case (also for the java browser plugin, in case you are wondering about that, too — everything else works great in 64 bit. Too bad it’s not a viable option at this time).

Here is a quick run down of a few of about 100 things we implement on our servers, and how they benefit our clients from a reliability and security stand point.

SuEXEC CGI Wrapper: All CGI scripts use the Apache SuEXEC CGI wrapper. This allows processes to run as your own user, rather than the global web server user. When CGI scripts run in the Apache web server, without the SuEXEC wrapper, it fails to perform security checks and all scripts on any account will be running as the same global user (world). This means, any script that the web server can (or has to) read, execute, write to, or otherwise has access or modify rights to, can be seen from other user’s CGI scripts.

To combat this, we implement the SuEXEC CGI wrapper on all servers by default, and have practiced this policy for many years. The advantages are that any files created by your script are owned by your own user, and not a different (web server) user, allowing you to control, remove, add, and edit them via FTP, the control panel, File Manager, web page editor, SSH/shell, email piping, etc. The checks it does ensures that you can’t set the permissions so other users script’s can access/write to your files. You can therefore set lower permissions to protect any read access, even, yet the web server itself can still execute the scripts. This prevents any other scripts from being exploited or intentionally coded to view files and such things as database passwords, script passwords or private information you store in databases and files, etc.

We automatically protect your site in this way, so no other users or processes can possibly access the files anywhere, and allows you to set real, beneficial permissions, whereby you can make directories that can store and retrieve data/content only through a script in a controlled manner, and make it so no web access can be allowed outside of your script. You can, of course, store those files outside of the web root path, so they are automatically outside of the web accessible areas, as well as password protect and set .htaccess rules to deny access to browsers, while your script still has control and access. This allows for the ultimate security regarding CGI scripts, so your site can be dynamic using them, but still remain secure.

The wrapper in question has the best benefit, where any abuses, spam, attacks, illicit processes, etc. are easier and more immediately tracked and controlled. This allows us to impose limits on the CGI script’s memory usage, CPU time usage, number of concurrent processes and the total time a process can run. We can white list specific users, processes, paths, and set different hard limits and soft limits for these resource restrictions. This allows us control, and you the security, and offers the ability for the server to automatically prevent any user’s script from going out of control (intentionally or not), so the server is never overloaded and negatively affects your site because of another user’s poor coding or if you happen to use a resource intensive script that would otherwise create a problem. We believe in preventative measures to keep things stable and clients happy, rather than only being proactive once a problem exists.

All CGI scripts run through this wrapper and can be coded in Perl, PHP, Python, Ruby, C, C++, shell scripts, and many more. CGI is only the protocol (or API) in question, and unlike what many people believe, CGI and Perl are two different things. CGI is the interface (Common Gateway Interface), and Perl is a language, so Perl is no more relevant to CGI than PHP or Ruby or C. Therefore, regardless of the language of choice, any of your CGI scripts automatically take advantage of all of the security, processing, ownership and permissive benefits that SuEXEC offers. This is not a new technology and has been widely used with great success for over a decade, so rest assured that these are only pros and there are absolutely no cons to the SuEXEC CGI wrapper.

Therefore, you should always ignore ANY script installation that instructs you to set world read, write and execute (chmod 0777) permissions on a file or directory, or that instructs you to set read and write to “world” as well (chmod 0666). Instead, CGI scripts themselves should be set to chmod 0700 (read, write and execute for your OWN user, only), or chmod 0500 for execute for only your user). The CGI wrapper will do the rest of the work. Chmod 0750 or 755 are fine, too, but you don’t ever need to allow “world” any read, or write, or execute permissions. This (world read access) is only needed for regular, non script/non executable files, such as text, HTML, images, and similar files, which aren’t executable or written to from their own http processes (since they aren’t a script/executable from the web server).

Directories that need to store data, can be set to chmod 0700 as well, or if you need to allow web access to that directory and the files within it, set it to chmod 0711 or 0755 or 0751. Any files that need read only access for the script, should be set to chmod 0400, and read/write access 0600. The first 0 is a sticky bit you can ignore on the permissions (it’s just for a full example). The second number of your user, this is where the SuEXEC wrapper cares about permissions. The third number is for your user’s group. This is a value you can ignore, really and don’t need to set. The final value is world (or other), which means all of the users but your user, so you needn’t set permissions on it or CGI scripts to run, read or write to. In fact, SuEXEC will cause your script to error and not run, if it sees anything wrong with the permissions or ownership, and it does this to protect you from running a script with too open of permissions (which protects you from allowing other users to modify a script that would have its process actually run as your own user) or ownership issues, where it detects the script isn’t owned by your user and isn’t in your account’s web root path, and thus, rightfully, and luckliy, fails. This is a good thing.

suPHP: Similar to the above, is suPHP, which is almost exactly as outlined above with the SuEXEC wrapper. They key differences is that it works off of the PHP file extension and will execute normal PHP scripts with normal permissions (even chmod 0644, for example). The point is for it to run more safely, and in a more controlled way, allowing you better security, and without you needing to make any changes to your scripts. Few people ever notice unless they are doing specific tasks, and even then it shouldn’t require any modifications to the code. Some key things are different for suPHP in how it sees PHP flag/value settings in, for example, an .htaccess control file. Instead of adding them there, you’d simply put them in the (more appropriate) php.ini file, just as the main PHP install uses globally.

suPHP is a replacement for an older idea of a SuEXEC (see above) source hack called “phpsuexec”. While it worked well in its time for the purpose and intent, it was not a very good implementation, so suPHP was the official recommended replacement as of about 5+ years ago now. Therefore, you can rest assured that suPHP is a well tested, stable, and mature implementation, where you can seamlessly run PHP scripts as your own user, without having to modify them (even if only slightly) if you wanted them to run in CGI (to take advantage of the SuEXEC CGI wrapper). This uses a similar method, but still protects your scripts and your site from the fundamental drawbacks of running mod_php (Apache web server API) as a global web server user, where the need for world writable files existed and memory leaks were more prevalent with php processes embedded in the Apache httpd server process. While the benefit of using the Apache API was the speed increase due to the lack of CGI overhead (when a CGI script is ran, it spawns a new process, instead of using the already existing httpd process for the web request), the increase was very negligible and had too many security drawbacks on sites that weren’t hosted on their own dedicated server. Essentially, it’s win-win for you and us.

mod_security: The mod_security Apache module is an addon that allows us to globally, or individually, control certain elements of requests that are sent to our web servers that host your site(s). We can filter out a lot of known and common exploit attempts, spam bot spiders that harvest email addresses, and many wide spread or unique actions that are nefarious or our of malice, be it from a human or, more likely, a scan/attack bot from some person’s infected system. This covers all types of request methods (GET, POST, TRACE, HEAD, etc.) and can check the header, body and URI, USER_AGENT, IP, etc. of the person, browser or system making the request. This helps to protect from common exploit attempts on common scripts, which are bound to host some out of date/unpatched script with all of the clients running all of the various scripts that have been out for the last 5, 10 or 15 years on their sites. This allows us to add one more of a dozen additional steps to help protect our clients, even if they ultimately uploaded a vulnerable script. If detected, we’ll contact a client and help/advise them to get it updated or replaced with a more secure, equally feature-rich alternative, which are almost always open source (no charge to use the scripts).

Iptables & Software Firewalls: While we implement various methods of limiting and blocking and controlling traffic and when sites need protecting, we can use route rejects, iptables (software) firewall rules, hardware firewalls with our upstream provider, null routing, deny from directives for the web server, blocking and controlling access with tcpwrappers, deny rules for email, SSH and FTP, etc., the one major factor that allows a server to be incredibly dynamic and automate protections, is to use iptables. Iptables is a very mature software firewall, which allows us to control and limit and prevent issues on both incoming, outgoing, forwarding, etc. as well as tallying transfer usage with greater accuracy.

With iptables, we can prevent abuse from denying any ports to be bound to/listened on, unless approved, which prevents a great deal of backdoor exploits on scripts and servers, rate limit how many times an IP can make a request to a site or server in a specified amount of time to prevent attacks dynamically without having to specify a specific block on an IP or IP range, block or limit or break down packets by IP requested, source IP or the service/port and protocol used, block or limit per port or service, log all requests without it actually hitting the service/making the request, save bandwidth, fight attacks and control the type of connections both in and out, to prevent a great variety of issues. We implement complex, but well tested and proven firewall policies that we have modified and perfected over the last decade or more and are always careful to ensure that client’s sites can function without problems or restrictions based on these policies/rules, but add an extra layer of protection.

Kernels, grsecurity, policies: We always use the most stable, secure and efficient kernel versions, patches and configuration options. Everything from ensuring it’s a stripped down kernel with only secure features needed and no unnecessary protocols, drivers, etc., to ensuring we add specific and custom addons, including things like the grsecurity patch, which allow us to perform everything from process listing protection, including paths, chrooting, jailing, and mounting issues, to such things as process ID randomization, time randomization on encryption and session routines, to controlling memory heap and storage to prevent zero day exploits if there’s an exploit discovered in a kernel version before the new version comes out and before the public is notified on security lists, right down to standard things such as (real) partition mounting policies, segmentation, to the kernel being static without LKM (Loadable Kernel Module) support, to protect from lkm exploits.

We really would make this blog entry result in a 100 page long post with just describing the kernel compile options and customizations alone, but we go to great lengths to ensure the best security and reliability, from the bottom (from the kernel) to the most top level protocol and services. This is only a short run down of a few things, out of probably 100+ actions we take based on over 250 years of combined experience with our staff members, as they each have over a decade or more of high level, hands on experience working on every level and aspect of systems administration, security engineers, developers and even getting heavily involved in the support aspects, keeping in touch with and providing satisfaction to the customers. There’s more to come, stay tuned.

BurlyHost.com, Inc. offers something new and unique for our clients — IP pools! Having a dedicated IP for your site is a good thing. While shared IPs are fine, the option to have your own IP is a significant advantage in many different ways. However, for those that don’t have dedicated IPs with their plans or don’t wish to get one, we offer the next best thing to a Dedicated IP: our IP Pool!

IP Pool is a special service we offer where the hosting plan doesn’t have a dedicated IP, but you want to be on an IP that’s not shared by everyone else on the server. Our Pooled IP feature limits the total number of accounts hosted on a single IP to five accounts or less. This way, if a someone else’s site on the same shared server or reseller server gets massive traffic/heavy traffic or someone’s site is attacked, it will reduce the chances of your site being affected or someone else being affected by your site.

For example, a lot of hosts put every client on one main IP, which all sites share. This is technically fine, except for matters of providers blocking access if you have a script that needs to connect to another network/site to retrieve data, RSS feeds, gaming scores, news feeds, various XML and other data and they (the destination) have blocked access from too many connections due to another user on the same server making too many outgoing connections. Another example is RBL blocks if someone’s site sends out too many emails, since most or all accounts are on the same IP and email sends out from it.

More to the point, since we have configured the servers to send email out from the account’s own IP, this will greatly reduce the chances of your site being on a spam blacklist if another user’s script on the server is exploited by a spammer and enough emails go out before we stop the activity to result in an RBL block.

We take all measures to prevent spam outgoing from our servers and to protect our clients’ scripts (even if they are insecure) from being exploited and used as a spam gateway, but ultimately, an insecure script is the heart of the matter. We promptly track down and disable any problem scripts that are actively being abused/exploited and notify the client (and in advance, if possible), and we implement measures to prevent it from going too far, but on a shared server, there’s really no 100% effective way to prevent all potential problems (though to date, we’ve not had one single incident on any server with spam from exploited scripts or otherwise). This allows us to limit accesses per IP for better control, both in and out, which is one of the biggest issues when dealing with multiple accounts on a single IP, so we’ve broken up our IP range/class on all servers to offer this ability by default (it’s better for you and us). It makes sense, so we’ve thus created this service

This also, and more importantly, allows us to segment the sites on the server and isolate sites so one doesn’t affect the other. Such as if a site is slashdotted or has an attack launched against it, while we do this in a broad sense already, we can more accurately and specifically rate limit the number of connections to a specific site’s IP, stop or slow down web attacks and email attacks, joe-job email bounce (attacks) and so on, so the targeted site doesn’t affect other accounts, sites or services on the server, and more easily handles the mass traffic/requests so we can have our attack prevention scripts more quickly break down packet headers and help that client avert the attack on their site, and no other clients feel the negative side effects that are usually associated with it (and always in the case of a shared server IP).

Again, we offer dedicated IPs, and we take all measures to prevent problems with the very lowest hosting plans that have larger IP pools, but for the mid plan clients, we offer this service to allow clients to benefit from this feature. This also allows us to segment our shared SSL certificates so only a few specific sites. Essentially, if you know the advantages of a dedicated/unique IP, but don’t have a plan that offers it by default and don’t wish to get an IP addon, you can understand the significant benefits in both an immediate and long term and preparative nature of such a feature.

This is smart, beneficial and cost effective, so we can pass those savings on to our clients at no extra cost. This is only one of many features we have uniquely created with our clients in mind and to offer a superior service both now and in the future, with many more unique and beneficial services to come. Please contact us for further information and details regarding this and other features.

This is the first, last, and only time I am going to discuss this topic. I can’t begin to describe how annoying, how generic and how tired it’s getting seeing companies boast about how “Green” (Eco-friendly) they are. A lot of people are all for helping the environment, and this is a good thing, in every regard. However, using the newest buzz words and hype to try and sell your services, is just wearing thin on a lot of people. Moreover, especially since people have been making _real_ efforts for many years, just jumping on the bandwagon to try and look like a “good company” that actually cares, just seems cheap and sleazy.

These people aren’t setting any examples, and really haven’t changed (for all intents and purposes), but they’ll gather all of the Earth friendly icons and images from across the Web and slap together an enormous blog page or sub page of their site, and even slap it all over their hosting plan pages to tell the world that they’ve “Gone Green”. Knowing some of these companies and the fact they they’ll harp on about anything they can use to get attention in the height of the hype about the subject, is not impressing people, especially since they don’t change and continue to have huge and unnecessary overheads.

It just gets old seeing people grab hold of the newest hype tactics to act like they are any different from every other hosting provider out there. Sure, pictures are fun, and nice words and claims of actions to help the environment aren’t hurting anyone, but it’s usually a misrepresentation and it just smacks of marketing desperation to have to tell the world every time you do something that you can put a positive spin on. Do your job well, run a good company, treat your staff well, treat your clients with respect and offer a quality service, but don’t resort to acting like a politician that has to make a big deal about any little thing to try and put a positive spin on a usually generic or even poorly ran hosting company.

Set yourself apart with service and honesty, rather than having to resort to playing spin marketing games to deter people from complaining about your company. Rather than giving them reason to complain and act like you’re a good company (”just look at the stuff we do for the world”) by defending yourself with irrelevant spin tactics, try and find ways to improve your quality, stability and integrity. Once again, we’re all for positive things, but don’t do positive things just to brag about it and tell everyone “See, look what we just did!”. Do it for the right reasons, really do it, and do it well, and stop abusing hype and buzz words to your benefit. This is web hosting, not an election ad.

Wow, what are the chances of this? Seriously! I’m not kidding, just consider it… I was browsing over Google’s various features areas and saw their “Google Sites” feature, and decided to read the overview about the service. It is nothing special or ground breaking and certainly nothing I’m interested in, but the first company and name of a person reviewing the service, is a guy I know, whom is a software developer, from years ago that’s on the east coast. With hundreds of millions of users and companies and billions of web pages online, and on one of Google’s pimped services, I see that I know this guy from many years ago (1996, maybe 1998 or so). Unexpected, I’ll have to shoot him an email.

Yes, it’s true. Not only are some hosts ignorant and unskilled in this area, but it seems that some are unwilling to take steps to improve security of their servers or their client’s scripts. Believe it. Worse, is some will even disable security measures, and for no good reason. I don’t mean for the sake of client friendly/open to any feature/service on the server without restrictions to “annoy” clients by giving up security policies or being lax, but actually where a poster on a usenet newsgroup was reporting a problem where when they tried to use Taint mode in their CGI script coded in Perl, that it would error. We all thought they must be mistaken, this would have to be an intentional action and a specialized build, and for what reason?

Just to remove a specific security feature to help clients code and use more secure scripts? This isn’t even forced on anyone, it’s simply an option in Perl to watch and warn or error in case of really bad, really insecure functions/practices. Yet, this host insisted they didn’t offer it and wouldn’t, and that they had disabled it, as it was their policy. This made everyone reading the thread take a double take and just ask why. Questions pondered with no rightful or sensible answers. It’s unimaginable that a web hosting provider, whom is supposed to specialize in this field, would intentionally remove a security feature that doesn’t whatsoever hinder the client’s experience or options, and is just intended to help them code more secure scripts, but only if they want to use it by specifically adding the switch -T in their shebang line (or calling a module). This is crazy, but it’s true.

Some hosts are more than just lazy or unwilling, but some apparently make actual efforts to make their systems and clients less secure. I’m still left pondering this. The only conclusion is that perhaps they are running mod_perl’s CGI emulation and since the Apache process CGI emulation has the global environment, that by the time they called it in their own script, it would warn that it was “too late” to use it and get an error to that effect. Still, it sounds like that’s not the case. I don’t usually encourage people to seek a different hosting provider, but in this case, that provider can only be bad news. I don’t get why people wouldn’t care about security, but to go as far as to disable good, default security options in the Perl interpreter, I’ll never understand that and find it even more troubling.