| "Is PHP installed on your Python server?"
... This is what happens when people who don't understand security try to tell you how to secure something. Don't do that. There's only a handful of things you need to do to harden most servers, and one of those things is filesystem access controls and mount options. One of the others is configure your network services to only do exactly what you need right now. These two things will solve so many more problems than simply keeping your software stack small, they should be the very first thing you do when you secure any system. First, you secure your filesystem. That means scouring the whole thing for any setuid-root files and any files that are group-writeable or world-writeable and disabling those permissions - except /tmp of course (and /var/tmp, which should probably be symlinked to /tmp). You can also double check you have no overly-permissive posix ACLs, security extensions or capabilities set on any files. Once that's done, you can mount your user-writeable data partition using options which disable files from being executed, set a default security context, disable device files, and disable setuid files. Then it's on to configuring your services. In the case of PHP, there is no security concern by it just sitting on your hard drive. It's not setuid-root and it's not a service. The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of. The reason it was abused in the author's case was due to a misconfiguration of Apache. Starting with an empty Apache config file and adding only the parts they needed would have excluded PHP from being interpreted in most cases (the module could be compiled in, which can be checked for, but I don't think most default Apache installs are done so; in addition I think you still need to manually configure Apache to bind ".php" files to the PHP application mime type). This practice should be used for every service you have running on your server. It may be tedious, but when you do it once you'll become much more familiar with the software and it'll be easy to replicate in the future. |
> In the case of PHP, there is no security concern by it just sitting on your hard drive.
It's a surface area question. I could go into more details of the history of why it was there and configured (if you read further, you'd see that it was part of our puppet manifests, and for a reason). But you reduce the surface area of attack by reducing the number of things that can execute arbitrary code. And if you aren't using PHP at all, "yum remove php" saves you disk space and surface area, even if you have another colossal screw up (like we did).
> The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of.
Well, the most it could do is, if you've screwed up someplace else, execute arbitrary code as the webserver user on the machine, thanks to the backtick operator.