The root of the PHP and Lamp security problem lies in the way most Apache servers are configured. In this article, you will improve the Linux security of a LAMP by using the capabilities of Apache’s Proxy’s directive mod_proxy module to isolate potential Linux security risks while maintaining the flexibility that tools like PHP provide.
Which problem? Is there some specific ‘LAMP’ issue that’s being touted as the LAMP problem?
99% of ‘LAMP’ security problems are down to people writing insecure PHP.
The article itself is worth reading, though; using a proxied setup in the manner described isn’t a bad idea at all. Just be aware that it (like every other individual security tweak) is no magic bullet: a SQL injection hole is a SQL injection hole, regardless of whether you can trample over other user’s files or not.
I inherited a LAMP setup. Our primary application ran in Perl. We did however also run a phpBB installation on the machine for forums.
We had one significant security incident – a DDOS tool installed itself on our machine via a security flaw in phpBB.
The solution we came up with for this was to install the Apache mod_security module, and write a load of rules to catch just about any potential security incursion.
After we’d done that the mod_security log showed loads of attempted attacks, however none of them were successful.
Setting up mod_security was trivial.
Whilst I never wrote any rules for mod_security on our server that would have trapped any SQL injections, I don’t see any reason why that couldn’t be done. Rejecting URLs containing “select%20”, “insert%20”, “alter%20”, “delete%20” and “drop%20” would probably do the trick.
Edited 2006-12-05 10:44
Nice hack; but not what I call Security.
Kind of like what suEXEC is for (normal) CGI:
http://www.howtoforge.com/apache2_suphp_php4_php5
Although it needs another patch make it work with Apache 2.2.x:
http://linuxfromscratch.org/pipermail/patches/2006-May/003034.html
(And mix in some FastCGI / mod_fcgid or the like maybe.)