|
Recent
Articles |
Oracle To Buy Red Hat Or BEA? Matt asks (almost as an aside to a post on a related topic): My question: why not just buy Red Hat? Before Red Hat buys MySQL, and gives those database numbers a run for their money?Then, Larry Dingnan writes...
Date Math In Linux Shell Script Within a Linux shell script to be used as a cron job, how do I calculate the current date, the current date - n days, and the current date + n days ? This script is to be used to partition an oracle database, and automatically drop old partitions (n+1) and create a new partition...
Microsoft And "The World's Easiest Desktop Linux" Yesterday, Microsoft and Linspire Inc. announced a ‘protection deal' for the small Linux vendor. Linspire develops and markets the Linspire distribution of Linux, marketed as ‘The World's Easiest Desktop Linux'.
Adding Risk Into The OSS Customer Equation Finally catching up on some reading…I came across this post at ZDNet that discusses an upgrade of Red Hat's stock by Credit Suisse. The analyst (Jason Maynard) seems to be on the same point that David Skok...
IBM And OSS - Burning Boats Okay, I do not speak for IBM in any way (read full disclaimer here). But after reading the following from Matt Asay's post, I couldn't resist. "IBM uses Apache/BSD to burn boats…everyone else's. :-) The company builds...
|
|
|
08.16.07
Quick Tip On Preventing PHP Exploits
By Scott Horne
Exploits happen but with some planning you can prevent the worst of them.
Planning for an exploit includes considering how to mitigate the damage, how to recover from it, and prevention.
Mitigating damage means trying to limit access to the system via exploited systems. In my case I run php as a cgi and have it run as the owner. This makes it more difficult to damage things that don't belong to the owner of the script.
Planning for recovery means having a backup, knowing how to restore from that backup, and knowing what other actions you'll need to take to recover.
If your running PHP some of the worst exploits involve executing shell commands on your server. Luckily though it is also one of the most avoidable. A simple way to prevent this is to add all the functions that allow execution of shell commands to the "disable_functions" line in the php.ini file.
Here's what how mine is configured:
# I'm not a security professional but I've been around the block. Here are some places I go to for advice:
• Linux Security Cookbook - A good book by O'Rielly that presents simple "recipes" to configuring a secure server. The book is that it explains why you take the actions it lays out providing you with a good starting point when thinking abuot security.
• The forums over at Serverbeach are full of great howto's and tutorials.
• Securityfocus has a great database that tracks vulnerabilities
Comments
About the Author:
Scott Horne is a software developer and President of Takeshi Media a firm that specializes in creating profitable and easy to use solutions for search marketers. You can use his free tools, code, and read his thoughts on search marketing on his blog, Web Professor.
|