- 1 SUSE Linux Enterprise Server for SAP Comes to IBM Power
- 2 VMware Hints at Potential Evolution for Container Strategy
- 3 Windows Server 2003 Meets the Zombie Apocalypse
- 4 Tips and Considerations When Creating Virtual Machines in Azure
- 5 Securing Containers without the Need for Virtualization Technology
4 Passwords to LAMP Security
The Apache HTTP server has a great security record, at least when it runs on Linux or any proper Unix-type operating system. But plain old static read-only Web sites are an endangered species; now we have all this LAMP guff (Linux, Apache/Lighttpd, MySQL/PostgreSQL/SQLite, Python/PHP/Perl/Ruby) powering dynamic Web sites, which may or may not represent progress. It's easy to install a LAMP stack and throw up a dynamic Web site over a weekend -- the real toil comes in securing it. Here are four steps to help avert complacency and get you on the correct path.
Me, I liked the days of plain, static HTML because although browser support and site quality were just as iffy then as they are now, at least they didn't bog down or even lock up my entire system by running fat, inefficient, error-ridden scripts. If they're going to chew up my CPU cycles and memory, the least they could do is finance my system upgrades. And they did not have the power to infect my systems merely by visiting their sites were I foolish enough to surf with Windows and IE. But the bad guys are getting smarter all the time, so it's no good sitting around being all smug and complacent just because I run Linux.
Recent Articles About LAMP
» The Hybridization of the LAMP Stack
» Enterprise Unix Roundup: Will Sun's Shine Overshadow LAMP's Light?
Read More About Real World Open Source
But I digress, because this article is about proper LAMP security practices. It's very easy to install a LAMP stack and throw up a dynamic Web site over a weekend, thanks to Linux distributions like XAMMP and Ubuntu, and thanks to the enormous popularity of the PHP (PHP: Hypertext Preprocessor) scripting language. But this level of ease is not necessarily a good thing. I dislike raining on anyone's parade, but all wannabe-Web moguls must invest some serious time and energy into learning their LAMP stacks inside out. Any Internet-exposed server requires extra attention to security, and dynamic Web servers even more so because of their complexity. The risk for collateral damage is high. Bigtime organized crime is behind computer exploits these days, and malware is just a gateway to fraud, extortion, and theft. They're not going to break into your systems to hurt them, but to quietly steal data and to assimilate them into the worldwide botnet.
The single most important step you can take is to not use PHP. Before you fling the rotten fruit, please read on.
1. PHP = Trouble
PHP (PHP: Hypertext Preprocessor) is the major culprit in LAMP insecurity. It's relatively young; it was born in 1997, and is still evolving. The problems with PHP are three-fold: inherent flaws, inexperienced coders, and unmaintained sites that never patch or upgrade PHP.
When you peek under the hood of PHP, it's not a pretty sight. It's full of cruft and chaos. Naming conventions, syntax, and case-sensitivity are all inconsistent. Many of its built-in functions are redundant, doing pretty much but not quite the same thing, and are poorly documented so you're not sure which one does what. Without going into excruciating detail (visit Resources for links to excruciating details), this is an obvious recipe for programmer errors.
PHP is seemingly easy to learn. And in a way, it is; you can learn how to fling up a dynamic Web site in a matter of hours. But it takes years to learn where its unsafe quirks lurk and how to work around them. One of the most common security holes is unvalidated input all user input must be mistrusted, but PHP doesn't have much in the way of tools to help with this, so you have to write your own validation routines.
When you run PHP as an Apache module by using Apache's mod_php, PHP inherits all the credentials of the Apache process. So everything that is readable and writable by Apache is also readable and writable by PHP, which means a successful PHP exploit leads directly into Apache, and everything that it touches. Using mod_php on a simple site with a single user works OK, but on a shared system with multiple users it's a recipe for carnage, because all scripts run under the same Apache user. An alternative is to run PHP under either suEXEC or CGIWrap. These work with nice sane scripting languages too, like Perl, Python, and Ruby.
There are untold thousands of sites still running on PHP3 and PHP4, and untold thousands more that never apply so much as a bugfix or security patch. PHP5 was released in 2004, and PHP3 way back in 1998. Yes, this is foolish and unsafe, but updating to newer PHP releases almost always requires significant code rewrites. Adding to the fun is Apache, PHP, and MySQL are always at war; you have to have the correct, compatible versions all at the same time or they don't work together. There are many options for easy fresh installations, such as XAMMP and Ubuntu's LAMP packages. But the real fun comes later, when you try to update your system and they're out of sync.
In my occasionally humble opinion, you're better off using Perl, Python or Ruby. A little more work up front for a lot less work and worry over the long haul. Hosting services are notorious for clinging to antique, unsafe LAMP installations, so check out WebHosting Talk to help find a Web hosting service that doesn't suck.
2. Harden MySQL
Hardening MySQL depends on a few fundamental steps: no network access, run it under a unique group and user in a chroot, create a strong administrator's password, no anonymous access, and get rid of everything you don't need, such as sample databases and tables, and any test databases and tables. Security Focus has an excellent howto. It is part of a series, with links to securing Apache and PHP as well. The MySQL Reference Manual also has good chapters on security. And remember that a chroot is not a security device, but Security Focus recommends it anyway.
3. Lock Down Apache
This page is still one of the best howtos on securing Apache.
All sensitive sessions, such as user logins or any user input, must be protected with OpenSSL.
4. Lock Down Everything With SELinux or AppArmor
Fedora Linux comes with a nice pre-fab SELinux policy that includes an Apache policy, and a graphical administration utility, system-config-selinux. I'm not saying it's easy, but it's easier than starting from scratch. AppArmor is also worth investigating. It's supposed to be easier to administer than SELinux, and the debates over which one is better are fun and informative.
The short story is that just because you're running a Linux server, and Linux and Unix-y operating systems have such good security records, you can't be complacent. Security fundamentals always apply, you still need skills and experience, and there are always new nasties lurking in the bushes, especially now that organized crime has discovered the power of the Internet. Setting up a little test lab is easy and cheap, and there is a world of documentation and help at your disposal. The future of Linux security lies in tools like SELinux and AppArmor; unlike the familiar old methods of reacting to threats, also known as "locking the barn door after the horse has been stolen," these have the power to protect you from the unknown.
- "Little Bobby Tables, we call him"
- Data Validation
- Problems with PHP
- a href="http://thwarted efforts.org/problems-with-php/">(Other) Problems with PHP
- Top 7 PHP Security Blunders
- PHP4 has been officially retired and will no longer be supported after December 31, 2007, except for "critical security fixes available on a case-by-case basis until 2008-08-08".
- Fedora SELinux Apache
- Novell AppArmor Documentation
- Tips for Taming SE Linux
This story was originally published on Enterprise Networking Planet.