We have not posted an update in a few weeks, things have been going relatively smoothly. We have finished the updates to cPanel 11. All accounts and servers should now be running cPanel 11. While its still likely that a few changes will trickle down from the cPanel developers regarding cPanel 11, the vast majority of things should stay the same.

We are also continuing our server upgrade program. Most of our older servers have been upgraded to bigger and more powerful servers. I think we still have a handful of servers that are queued to be upgraded. Individuals on those servers affected by this will receive a notice concerning this when the time comes. You should make sure that you have your contact information up-to-date with us, so you can be sure that you receive this e-mail.

We have also begun sending out notices to accounts that are utilizing their default address. This is a first step in a broader set of changes that are planned for later this year. The general basis is that your default address can represent an infinite number of e-mail addresses and handling mail for this can consume quite a bit of server resources. Its difficult to allocate server resources for other tasks when these resources are being used by the default address. If we can curb the amount of resource consumption that is used by the default address then this will allow better server performance and allow us to focus resources for more important tasks, such as spam prevention. We have written a guide that details how to set your default address to discard messages.

We have some other minor adjustments that we would like to make on the servers as we enter into 4Q 2007. The adjustments focus on server security and increasing server efficiency and production and aim to make your webhosting experience with us even better. Stay tuned to the blog for more information on these changes as they become available.

Scott Mutter

We have about three servers that are not running PHP as CGI. All of our other servers are running PHP as CGI with no problems at all. We are probably going to switch those three servers to PHP as CGI sometime next week (August 13 – August 17) just to bring all of our servers to a state of more uniformity.

Running PHP as CGI allows us to lock down PHP on the server a lot more and provide greater security. We have been converting servers over to PHP as CGI all summer long and really nobody has noticed the change. We have probably converted 3000 to 4000 accounts over to PHP as CGI and had maybe three minor issues. This really should be a seamless transition.

Running PHP as CGI allows us to track script and script exploits better. It also provides better security because open directories will no longer be required. We will also be able to disable most PHP functions that are used in PHP exploits by default and enable them on an account by account basis as needed, furthering the overall security of the server. On top of all of this, it also allows us to run PHP4 and PHP5 concurrently as we look to move towards a PHP5 default standard later this year.

We are not going to be sending out e-mail announcements concerning this because we just don’t view the change as being that big and warranting an e-mail message. Like I said, we have been converting servers over to PHP as CGI throughout the course of the summer during our server upgrade program and have not receive any substantial complaints. We are making an announcement here just so that our users will be aware of this.

Scott Mutter

We have had quite a few issues raised concerning Frontpage and Frontpage Extensions. Frontpage and Frontpage Extensions are a Microsoft developed product and system for publishing a website. The Extensions act a little bit like FTP, but it is different from FTP in that it is a proprietary communication method developed by Microsoft. The only product that understands Frontpage Extensions is Frontpage or Frontpage-based products. Likewise, Frontpage and Frontpage-based products require Frontpage Extensions in order to publish a website. As you can see, this requires a bit of involvement with Microsoft and their proprietary standards in order to use these products. This differs from FTP in that FTP is a recognized as an industry standard. For example, the FTP command PUT, used to upload files to a server, cannot change the way it performs a task because there are so many FTP servers and FTP clients available. If this were changed, none of the FTP servers and FTP clients would be able to communicate with one another.

Microsoft stopped development of Frontpage Extensions and Frontpage products late last year. There are no updates to the Frontpage Extensions that are on the server. Microsoft has shifted their attention to another product called Sharepoint Services. Sharepoint Servics act a lot like Frontpage Extensions, the downside is that Microsoft is not distributing the source for this project and therefor Sharepoint Services cannot be ported over to other operating systems. All of our servers are Linux based web servers and not Microsoft based. This means that Sharepoint Services will not work on our servers. Newer products released by Microsoft and some updates provided by Microsoft force Frontpage and Frontpage-based softwares from Microsoft to only work with Sharepoint Services. If you are having trouble publishing with Frontpage, this is probably why.

What can be done regarding this? I would recommend that you move away from Frontpage and to another product. Adobe’s Dreamweaver is a popular web publishing tool and it uses FTP to publish your website. Using something like Dreamweaver which uses FTP to publish your website makes your website that much more portable. If you decide to move your website somewhere else, chances are very good that it will have a FTP service available able to publish your website. This releases you away from using Microsoft’s proprietary standards. I know switching from Frontpage to Dreamweaver (or some other WYSIWYG HTML editor) is not going to be an easy task. I’m not saying it won’t be and I’m not saying that its a change that you can make overnight. I’m just saying that if you are publishing your website and making changes often or into web design, then I would recommend moving away from the Frontpage and Frontpage based products (such as Expression Web).

Additional information regarding this can be found on Microsoft‘s website. You may be able to use a product like Expression Web to design a webpage, but you won’t be able to publish with it.

I do apologize for the inconvenience that this has caused. But please understand, it was not our decision to remove and stop developing Frontpage Extensions. This was a decision made by Microsoft, to shift their attention to Sharepoint Services. I know that this is affecting a lot of users, but there’s just really nothing we can do in regards to this because we don’t control Frontpage Extensions or Sharepoint Services.

We have received a few complaints throughout the past few days concerning the disabling of register_globals on all of our servers. What needs to be understood is that there are very few, if any, webhosting companies that are still allowing register_globals to be on by default.

For a quick overview of what register_globals is, imagine that you have a form constructed like:

<form name=”formname” action=”file.php” method=”post”>
Color: <input type=”text” name=”color”>
<input type=”submit”>
</form>

Now with register_globals enabled, you can access the data that submitted by this form in the file.php file by using variable names like:

echo $color;

Note how the name of the color text box is named color. Notice how in the PHP file you just reference that as $color. This is with register_globals enabled.

With register_globals off, you need to reference the variable as:

echo $_POST[‘color’];

Notice how the method part of the form says post. This means that you are POSTing data. So in order to access the information in the color text box, you have to use the $_POST array identifier.

Now that you understand what register_globals is, its easy to see how having register_globals on can open you up for various exploits. The manual page for register_globals offers some good details regarding this. I look through all kinds of security vulnerabilities that are disclosed every day. Practically all of those vulnerabilities come about because variables in a PHP script are not sanitized and because PHP does not require variable initialization. This opens up a script a cross-site scripting vulnerability, where a malicious user will inject PHP code from a remote source into your script and use your script for malicious intent. All of this becomes much less of an issue if register_globals are turned off.

It is also worth mentioning that register_globals is an option that the PHP developers are deprecating (to deprecate something means that it is being removed or taken away). You can see this from the minutes in a recent PHP language developers meeting.

What does this mean to you as an end-user? This means that if you have a script that requires register_globals in order to work, then the script needs to be fixed. This may mean that you as an end-user needs to fix the script if you wrote the script, you may need to contact the developers of the script if you purchased or downloaded a script, or you may just need to upgrade the script to a later version. Yes, register_globals can be enabled on a server, but this is not a fix, this is just applying a patch to a water pipe that is ready to burst.

You may hear that if a script properly sanitizes its variables then its just as safe with register_globals being on as it is being off. This is actually true, but there are very, very few PHP scripts that properly sanitize their variables and do variable initialization for all variables. The entire webhosting community is moving towards having register_globals disabled and even the PHP developers are deprecating register_globals. This means that it is really more of a waste to sanitize and initialize variables in a PHP script when that time and effort can be applied to restructuring the script to work with register_globals off.

This is why we have disabled register_globals on our servers and to be honest, this is something that we should have done a couple of years ago. It basically comes down to how secure do you want your webhosting company to be? If you want us to be lax in our security efforts, then this means that spammers and phishing attacks will be rampant on the servers, causing blacklisted servers and server lockdowns from upstream providers. I don’t think this is what anybody wants. This is why you have to trust our security efforts and realize that we are doing this for the betterment of all of our clients.

The one exception that I know of concerning register_globals is osCommerce. I am not a big fan of osCommerce because I think they have abandoned their project. Like I said, issues with register_globals have been know for several years now. All of the other popular scripts have rewritten their code so that register_globals is not required. Some scripts won’t even install if they detect register_globals as being on, because this justifies a lax security model by the server administrator and if register_globals is left on, there may be other security details that a server administrator has overlooked. osCommerce continues to lag behind the field and continues to require register_globals to be enabled. We will enable register_globals on accounts that are using osCommerce, but I would ask that you either consider moving to a different shopping cart application. This lack of attention by the osCommerce developers really leaves me worrying, what if a major issue with osCommerce comes about? What if a vulnerability in osCommerce allows a malicious user to steal credit card information or other confidential information from a potential buyer? Will osCommerce take 5 years to patch that security hole? Because osCommerce seems to not care about its client base, the client base should really rethink their participation in the osCommerce package.

Hopefully this will provide some insight into the register_globals issue.

Scott Mutter
Director of Administration

We have begun to receive a few more concerns regarding the disappearance of the autoresponders link in your control panel after the upgrade. We have received enough concerns that we have now re-enabled autoresponders in everyone’s control panel.

The points that were raised in the previous post are still valid and it should be worth mentioning that just because autoresponders are enabled by default now, does not mean that it is a good idea to use them.

We will likely revisit this later in the year. Perhaps by going through all of the accounts that do have autoresponders set up. At any rate, if you do have autoresponders set up on your account or if you are thinking about setting up autoresponders on your account, please have a read of the previous post concerning this matter and use good judgement.