|
Web Hosting Best Practices, Part 2 Web security always comes down to a single common denominator: application security. Because of that, this follow-up to last week's article, "Learn Best Practices for Web Server Security," will focus wholly on the Achilles heel of Web servers.
Without the applications that run on a Web server, be they horribly insecure or not, there would not be much point to hosting Web sites. The Web host's hierarchy of needs goes something like this: first obtain customers, so we can eat; second, secure the servers against total compromise when a bad application gives too much access, to ensure job security; third, focus on making customers happy through improved service, automation of tasks, and so forth. Finally, the Web host's self-esteem comes into question. Perhaps blurred with the third level a bit, since automation is likely, but more focused on a company's image, the reputation of a Web host comes into question. Vulnerable Web applications can wreak havoc on a hosting provider's sanity. Botnet clients are not only for Windows anymore; they can also be small Perl scripts that get run via exploitable Web sites. That's right, all the evilness associated with bot'ed computers can also be applicable to Linux Web servers. DDoS attacks and spam floods are commonly—and more frequently these days—seen originating from Web servers. An Internet site's reputation will quickly become tarnished when such evilness emanates from their IP address space. Remote sites will block e-mail, upstream service providers may degrade service levels, and generally, the Internet would be about as hostile to the Web host as it is to dynamic IP addresses. To conquer the self-actualization level, Web hosts must somehow figure out a way to save face. We must find a way to prevent the initial attack from happening in the first place. Many will deploy vast (read: expensive) technologies designed to detect misbehaving servers, which can eventually be traced to a specific Web site. Most likely, it turns out to be a vulnerable PHP application that someone downloaded from the Internet. Not all PHP applications are inherently insecure, but the most popular ones with more diverse contributors frequently have security issues. What, then, can we do about all of the popular applications that nobody updates? In a perfect world, each user would subscribe to the security announcements mailing list for every application he uses. When an announcement came in, our dutiful user would dutifully update their installation. This never happens. Fresh out from Cult of the Dead Cow, is goolag, a Web site scanner that uses Google to find vulnerable applications. Give it a try against your own sites; that is after all what these tools are for, in the hands of a good guy. It's very clear that with tools such as goolag, people are going to be looking for well-known vulnerabilities. There's just too many exploitable Web sites in the world for the crackers to need to worry about manually attacking an application that they don't have an exploit for already. A really interesting realization happens right around the time a Web service provider realizes that they're getting compromised way too frequently. Most, if not all, of these security incidents gain their foothold through a very small handful of applications! Wikis, WordPress, Mambo, Drupal, Gallery, etc are all extremely common applications that have had their share of vulnerabilities. Sure, somebody's custom PHP app will get hacked eventually, but the vast majority of exploits seen in the wild result from automated scans of well-known vulnerabilities. Users demand a very limited set of applications, so why not just manage these for them. Seriously, it is not difficult to provide a scripted way to allow a user to install a new phpBB, for example. Most Web applications' installation simply consists of copying files in and updating a configuration file with things such as the URL of the site. Follow-up configuration is sometimes necessary, but this is generally done via the Web page itself, which allows users to complete the task when they visit their new site for the first time. You can then have a definitive list of what applications are installed in what sites, for the most part anyway. Dreamhost, for example, offers one-click installs. It's really more of an input-information-and-maybe-create-a-database-to-use and then one-click install, but it's extremely simple for the average user to comprehend. There is zero chance that the install will be left in an insecure state if you're managing the application for them. This may involve adding a quick 'chmod 755' at the end of a configuration routine in the worst case, but it's well-worth verifying that every supported application is properly secured. You only need to do it once, yet thousands of customers will reap the benefits. Furthermore, and more to the point, you can provide a way for users to automatically update their applications. Updating user-installable Web applications is not as difficult as it sounds. More often than not, a quick security update simply involves replacing a single file within their installation. Major version upgrades generally take more work, however. It's certainly a worthwhile endeavor; imagine knowing that your thousands of phpBB (sorry to pick on the easy target again) installs are 100% up-to-date. Now, if you were to allow users to choose whether or not they update these applications, they will not. The average user is more likely to update, but most will not. We'll leave this as an exercise for the reader. In tough security situations, when you know many sites are vulnerable to something that is being actively scanned for, you as the hosting provider can make the call to force an automatic upgrade for all instances. Many would say that this is crossing the line between "service provider" and "applications maintainer." It is true, but as things evolve, we generally must move more in a direction of control, perhaps in territory we don't really want to be. Remember when people used to cite "end to end!!" all the time? Or when spam filtering was considered harmful? We simply cannot live without spam filtering now, and that's the nature of the business. |