We have identified a couple of test servers that we will be changing the PHP set up on. This will involve swapping the precedence of PHP versioning on the server. Where as right now, everything is handled as PHP version 4 by default. Unless you have specifically written in regarding the PHP set up on your account, all of your PHP scripts are being handled as PHP version 4.

We are scheduling this upgrade to happen sometime early next week (December 3rd – December 7th). We are planning on the upgrade happening on December 3rd, but it may be pushed back to December 4th or December 5th. We will be posting updates on this blog for more specific times regarding the upgrade. There will be no downtime involved in this upgrade.

What this switching of precedence will do is change the default setting to PHP 5. Meaning that all PHP scripts will be parsed as PHP version 5 by default. PHP version 4 will remain on the server and we will be able to switch accounts back to PHP version 4 if needed.

Please Note: We ask that you please give PHP version 5 a try. We cannot continue to support PHP version 4 indefinitely. The developers of PHP are ending the life of PHP version 4 on December 31, 2007. Security updates to PHP version 4 will only be available until August 8, 2008. After this time there will be no further updates to the PHP version 4 tree. After December 31, 2007 the only updates to PHP version 4 will be major security flaws that pop up in PHP4. Because of all of this, we do ask that you at least give PHP version 5 a try. If for some reason your scripts do not work with PHP version 5, we can switch you back to PHP version 4, but please understand that you are going to have to fix your script or update it so that it will work with PHP version 5. Support for PHP version 4 will eventually have to completely cease.

This test rollout of PHP version 5 will serve as an indicator to see just how well our client-base responds to the PHP 5 upgrade. We feel it is better to perform this upgrade on a few servers first, rather than switch all of our servers to PHP 5 at the same time. We will evaluate the responses we see from this test rollout and from that will make a decision on how to roll this out to the rest of our servers.

If major problems are encountered with this rollout on these test servers, then we will switch everything back and likely postpone the rest of the servers as well until we can adequately deal with the issues that were presented in the test environment. Depending on how the test rollout goes, we may perform another, secondary round of testing with a few servers or we may decide to roll this change out to all of our servers at once.

It is because of these reasons that we really want clients on these test servers to try PHP version 5 so that we can know what, if any, problems there may be. We have been in contact with other web hosting companies that have done this switch and problems have been minimal, so we are not anticipating a wide-range of problem, but we are taking a cautious approach to this. This is an upgrade that will have to be done sooner or later.

Accounts that will be a part of this test roll out will receive an e-mail notification shortly. It is important that you keep your contact information with us up-to-date so that you can be informed of actions such as this. If you have any questions or comments concerning this upgrade, please feel free to contact our support department or leaving us comments on the blog.

Thank You
Scott Mutter

I was taking a look at the calendar the other day and realized that the holiday season is really upon us and the end of the year is not too far away. I would like to get a few things accomplished before the end of the year and begin looking at some other changes on into next year. I have to walk a fine line between keeping the servers up-to-date in terms of what the webhosting community is offering and making sure that the upgrades can be offered in a seamless manner.

To that end, below is a list of upgrades and additions that I am looking to have accomplished or researched by the end of the year.

· Script Installation Service – This is an idea that we have been tossing around for some time, we just weren’t sure if it would be feasible to offer. We’re still not sure if this something that will see wide-scale use or really what will become of the offering. The only way we are going to really see how something like this would be used is to make it available and evaluate its status.

We seem to be seeing a lot of issues where end users are installing scripts on their website and then never updating them. New versions of scripts are generally released to fix a security issue within the script. The security issue may be small or large, there’s no real way of knowing, but in any case the only way to avoid complications caused by the security issue is to keep the script up-to-date. For whatever reason, it seems that end users are not keeping their scripts up-to-date.

To help combat this problem, we are considering a Script Installation Service where our administrators would install a script on your account, catalog it, and stay up-to-date with script updates. We are still working out all of the specifics in regards to this project, I would stay tuned to the blog for a more formal announcement concerning this.

· PHP 5 Upgrade – All of our servers currently support both PHP4 and PHP5. PHP4 is the default PHP used on all of the servers. This means that if you have any .php file it is being processed as PHP4, unless you have written in with specific instructions to use PHP5 by default. PHP4 is going end of life according to the PHP developers and the GoPHP5 initiative has set a February, 5th 2008 deadline for major script developers and service providers to drop support for PHP4. We intend to honor this and make PHP5 the default offering on our hosting plans. This will basically entail swapping the default structure of PHP on the servers. Instead of PHP4 being the default, PHP5 will be the default. If you specifically need PHP4, you can submit a support request and we will have PHP4 turned back on for your account.

It is our hope to begin switching servers over to a PHP5 by default setting sometime in early December and we hope to have the process completed by the end of December. We will likely do this switch in a phase-in procedure, we will first do this switch on a couple of servers and evaluate the procedure based on feedback from that test. Should there be major problems concerning this switch, we will not hesitate to switch everything back to PHP4 and then re-evaluate how we are going to lay this out.

The GoPHP5 initiative and the PHP developers are correct, PHP 5 has been released for over 3 years now and it is time for widespread adoption of PHP 5. PHP developers cannot continue to support an old and outdated language framework. Like it or not, the Internet is ever changing. PHP version 6 is already being talked about, and the Internet community has yet to see a widespread adoption of PHP 5.

Will upgrading to PHP 5 break your script’s functionality? I can’t say for sure. The vast majority of popular scripts have been updated within the past 3 years and those developers are aware of PHP5. You can check the GoPHP5 website for a list of projects that support PHP 5. Just because a script is not listed does not mean that it will not work with PHP5. If you are unsure, you should contact the developers or vendor of the particular script you are using and ask them if the script will work with PHP 5. If it does not work with PHP 5, you should inquire as to why this is the case. PHP 5 is coming whether the developers like it or not, the web hosting community cannot continue to support old and antiquated frameworks forever.

· Apache 2.2 Upgrade – This is a project that will not get completed before the end of the year and the timetable for the upgrade may be more Spring ’08 than early 2008. However I did want to mention it here as I’m sure there are a few users that are interested in this upgrade. Apache is the service that serves up webpages on the server, in affect it is the web server.

With the release of cPanel 11 this past summer and fall, cPanel now supports the newer Apache trees including version 2.2. Our servers are currently running the Apache 1.3 tree and are serving us very well. Apache 2.2 mainly includes a lot of code fixes that can improve overall performance of the server and just like PHP, it is becoming more and more difficult for the Apache developers to justify supporting the Apache 1.3 tree. We don’t want to be left so far behind that we receive an end-of-life statement regarding the Apache 1.3 tree and then have to scurry to upgrade our servers to a newer version of Apache.

Our Apache setups contain a little bit of custom work done by our server administrators, so translating all of this over to Apache 2.2 will take some time. We want to develop a procedure to where we can easily migration from Apache 1.3 to Apache 2.2 with as little downtime and as little affect on our end users as possible. Right now I don’t have a solid timetable for when this upgrade might be done. I would like to have it in place by the Spring of 2008, but we are just now getting to the point where we can perform test upgrades on our test servers. While I still think that a Spring ’08 timetable is very feasible, it could be postponed.

We have some other upgrades and new features that are also being planned but these are the main things that we are focusing on. Our aim has always been to give our users the best webhosting experience in terms of stability, security, usability, and features. We look forward to continuing to offer you this same webhosting experience throughout 2008 and the years to come.

Scott Mutter
Director of Administration

The end of the year is fast approaching and I would like to get some things done before the end of the year. I have a couple of items planned for the next couple of weeks, but then I should be in a better position to work on my to-do list. I hope to have a more comprehensive post within the next few days.

One thing that I am wanting to accomplish before the end of the year and something that is probably the easiest to do is to work on the control panel accessing issues. We have had a few users write in with complaints, especially with Internet Explorer, involving the self-signed certificate when you try to access your control panel or webmail.

The issue has to do with the nature of self-signed certificates. Self-signed certificates are free to create and use, the caveat being that a browser will never recognize a self-signed certificate as authoritative. A self-signed certificate is alright in a situation where you already trust the party that you are dealing with and you just want that connection encrypted. Control panel and webmail access is a perfect example of this. End users should already trust us (you are purchasing hosting from us) and you are not being asked to give any type of credit card or payment information. Yet, you also want your connection with between you and the control panel to be secure.

It seems that the new version of Internet Explorer throws a big fit when it comes across a self-signed certificate. I consider this to be more of a lack of understanding from Microsoft’s point of view regarding self-signed certificates. They are correct in that self-signed certificates should be given an extra set of scrutiny by the end user, but I’m not sure a full warning page is really necessary. This can scare off some users and its really not that much of an issue. Now if you were just starting a business relationship with a company (purchasing something from a company for the first time) you certainly wouldn’t want that company to use a self-signed certificate for their order form. But in a place where a relationship already exists between an individual and a company, a self-signed certificate will serve to encrypt the connection.

At any rate, we have made the decision to switch over the certificates on the control panels and webmail access to real, authoritative certificates. We don’t have authoritative certificates for all of our servers, but we do have them for most of our servers. We hope to be setting up the servers with authoritative certificates sometime this week.

What does this mean for you?

This means that if you have trouble accessing your control panel or accessing webmail then you may be accessing it incorrectly. In order to access your control panel you need to use a link of:

http://yourdomain.com/cpanel

To access webmail you need to be using a link of:

http://yourdomain.com/webmail

Obviously you should change yourdomain.com to reflect your real domain name. If you have trouble accessing your control panel or webmail, please try using the links as described above.

If you continue to have problems accessing your control panel or webmail after you try using these links, please submit a support request so that our staff can look into your issue.

We have had a few more concerns regarding the register_globals issue. We talked about this in a previous post, which provided some good insight. However, we still have quite a few users that are requesting register_globals to be turned on and don’t understand why we can’t turn it on. This post aims to cover this in a bit more detail.

PHP’s register_globals can be a security risk. The keyword here is that it can be. In and of itself, register_globals is not an issue. Take someone who has a good strong programming background and register_globals doesn’t have to be an issue. Take that same person and ask them why register_globals should be left enabled, and you won’t get a reasonable response. If a programmer writes the code to their program correctly, then register_globals being on won’t be an issue. Any good programmer should know that securing their program is of the utmost importance. So the issue becomes, either a programmer spends more time securely defining their variables so that it can work in a register_globals enabled environment or they heed the advice of the entire PHP and PHP development community and code their script to work with register_globals off. A good programmer will recognize why having register_globals turned off and why writing a program in such a manner is a good thing.

The real issue here and to try and put this tactfully, is that PHP is a real easy language to learn. It is simple, yet powerful in creating dynamic websites. The end result is that there are a lot of PHP scripts out on the Internet that were written by programmers who had a lot less (if any) training than a seasoned programmer. These less trained programmers are not as adept at focusing on script security and input sanitation. I’m not saying that any of the PHP scripts I create are perfect in terms of security. I’m not saying that anyone can write a PHP script that is completely secure and will never have any security issues. I am just saying, if you had a project programmed, one by a 30 year programming veteran with 10 years of PHP coding versus someone that just wrote their first PHP program 2 months ago, whose program would you trust more?

The problem is there are a lot of PHP scripts available today are poorly written. They don’t take into account security of the script and they are not maintained or kept updated. They were just written one day by someone and forgotten about. This is where security issues pop up.

Ask anyone that has a website if they would prefer to have their website hosted on a server that is constantly blacklisted for sending spam or constantly being turned off due to phishing scams. They would all say no, everyone wants to be hosted on a reputable and secure hosting server. This is what we try to provide. If we relax our security procedures for even one account, then that relaxed setting can have ramifications for all of the webhosting accounts on that server. If by enabling register_globals for domain1.com on a server results in a hacker or malicious user breaking into that script and then using our server to send out spam, then we have effectively caused inconveniences for accounts, domain2.com, domain3.com, and domain4.com that are also hosted on this server. A server is not blacklisted based purely on the domain that was hacked into or exploited, when a server is blacklisted the entire server is blacklisted, regardless of what accounts are on that server or how the spam was sent out. Likewise a phishing scam on a server can result in connecting networks removing their connections to the server. Without network connectivity a webserver is as good as dead.

This is what users need to understand when raising concerns about register_globals being disabled on our servers. We as a webhosting company have to look after the well-being of all of our clients on the server. If we’re not, then we’re not doing our jobs. If we aren’t paying attention to basic security concerns, then we aren’t doing our jobs. For each account on a server that wants register_globals enabled there are atleast 100 other accounts on that same server that are grateful that we did not. If other webhosting companies are allowing register_globals to be turned on for any client requesting it, without offering to educate the client, then personally I would have to question that company’s dedication to offering a secure webhosting environment.

Check out the latest list of security vulnerabilities on Secunia which mention register_globals. At the time that I wrote this there were nearly 680 security vulnerabilities listed when you search for register_globals. I did not check all of these, but I suspect the vast majority of these include a line similar to “Successful exploitation of this vulnerability requires that register_globals is enabled.”

This is one of the best pieces of evidence as to why having register_globals disabled makes good sense in the webhosting community. There are new security vulnerabilities found in scripts everyday that require register_globals to be enabled in order to be successfully exploited. I don’t know when a particular script is going to be listed as vulnerable. Its entirely possible that there are scripts out there that are vulnerable right now and not listed with Secunia. Further, I don’t have any way of knowing specifically what scripts each account has installed. The safe bet is to disable register_globals. This way, whenever a new vulnerability comes out, if it states “Successful exploitation of this vulnerability requires that register_globals is enabled”, then with our servers having register_globals disabled, the vulnerability will have no affect on our servers.

To better understand how security can be circumvented in a register_globals enabled environment, I suggest reading a post from IBM’s website. Specifically read the section under the heading Unintended user input. This goes into a lot of detail as to how security can be circumvented in a poorly written PHP script. The author goes on to show that you can effectively reduce the risk of this behavior by defining your variables at the beginning of the script. This is probably not a bad idea itself, but if you are going to take the time to modify the script and define the variables at the beginning of the script, why not just go ahead and take the extra step and update the script to work with register_globals disabled? This is the part that I don’t understand. If register_globals is enabled, then chances are you are going to have to modify the script in order to define variables so that outside users cannot taint the variables. If you’re going to be modifying the script, why not just fix the script so that register_globals is not a requirement for the script.

The PHP language developers, the people behind the PHP language, recognize the security concerns with register_globals. They made the decision to remove register_globals completely in PHP version 6. Now PHP6 is a while away, but still, if you expect to use a script in a PHP6 environment, the script can’t require register_globals. So if you are having to modify the script, you might as well update the script to work better with future PHP releases.

This explains why having register_globals enabled on a webhosting server is a bad idea. Can a PHP script be written so that it is secure even with register_globals enabled? Yes, I won’t argue that point. The point I want to make is that I don’t believe that this happens very often. In order to really make this determination a script would have to go through a very extensive security audit. I don’t have the resources required to perform these individual script security audits. Even if a script was determined to be safe with register_globals enabled, this still doesn’t change the fact that PHP6 will deprecate register_globals completely. So even if your script is secure with register_globals enabled, you will have to modify the script again when PHP6 is released.

I just really cannot see a good reason to have register_globals enabled for a script. If a script is important to you, then you want that script to be secure. The best way to secure that script is to insure that it works with register_globals disabled. If you are running into an issue with a script that you downloaded or purchased, you should check to make sure that you are running the latest version of that script, as the issue with register_globals may have been taken care of with a script update.

I hope this helps explain the issues surrounding register_globals.

Scott Mutter

Director of Administration

We sent out notices yesterday to accounts that we found to be using weak and insecure mail passwords. Actually the subject of that message was incorrect, but this was not noticed until the message had already been sent out. I apologize for that, but I didn’t think it was worth the effort to resend the notice with an updated subject line.

Not every account received one of these notices, but its probably a good idea if all accounts take a look at their mail accounts and insure that they are using strong and secure passwords.

I suspect that a lot of accounts have mail accounts that are no longer being used. If you aren’t using a mail account for anything, it just makes better sense to remove it. It takes away a point where a hacker or malicious user can gain access to your account.

Lately we have been having a lot of problems with spammers gaining access to mail accounts on the servers and then using those accounts to send out spam. This causes our servers to get blacklisted. The best preventive measure that can be taken is to insure that all access points, points that require a login username and password, are using secure passwords. This includes your main FTP/cPanel password and all of the passwords for your mail accounts.

To help prevent further spamming problems on the servers, we are encouraging all of our users to check their mail account passwords and all of their passwords and insure that they are strong and secure. We have written a guide that details how to update passwords for mail accounts using the cPanel interface or the webmail interface.

The more accounts that are using strong and secure passwords the more difficult it will be for hackers and malicious users to gain access to those accounts and the less likely that our servers will become blacklisted due to this concern.

Scott