I wanted to ask all the nice people in here which are the steps you follow to secure your PHP installation. In addition to basic active and passive system security (tmp set as noexec, limit permissions on system executables where possible, keep your system updated, aide, chkrootkit, rkhunter, watchdog, and so on), which are the steps you follow the secure php?
Safe mode has always been a dirty thing, but it was useful in some environments - now, as we know, Safe mode will be finally and definitely removed from PHP (PHP 6 builds already do not have it), so I wanted to know which will be your extra steps to secure your PHP-powered http server.
I have never chrooted apache on a live server, as it proved to be a pain to maintain (and Plesk didn't make things any easier) - grsec could be useful, but currently I have only SELinux's basic policy, with some easy customization done to use sendmail properly through php, as grsec had some issues running on my system.
So what do you do? If you ever chrooted apache on a Plesk server, can you give me some tips to make the process easier?
Securing PHP - death to safe mode!
-
scott
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
A security-in-depth model is the only real effective mechanism for securing the environment.
1) noexec - oft-cited and largely ineffective. This sets a flag on a file system to set it to not allow executions in that directory. Unfortunately its trivial to bypass, either by calling an interpreter to execute the application (a la: perl /tmp/foo) or even easier, uploading and executing from some other writable directory. This has been an automated process the badguys use for a few years now.
2) SELinux - this is amazingly powerful, and has a lot of potential. Ive got some high hopes for using the data labeling component to label what can run on the system and what cant (target is to do this in ASL 3.0). As shipped in fedora/centos/redhat the policies aren't that useful for now, and creating new policies isn't for the faint of heart.
3) GRsec, the TPE policy that ships by default does everything you really want to do with noexec, except its global, and driven by group id's. Its also more useful with logging, in that it tells you who did it, on what application, and how in the logs. PaX (stack overflow protection), and learning mode are the biggest advantages it has over SELinux, since the two do largely similar things with process ACL's and RBAC. ASL 1.0 was initially just a grsec'd kernel.
4) Mod_Security. noexec, selinux, and grsec are all post-exploit security control s. Mod_Security is performing input validation before you get to the application. 2.x+ suffers from some sever performance limitations over the 1.x series. So all the rules we developed at gotroot.com are currently killing the 2.x systems. That being said, 2 brings in much more granular capabilities, as well as the ability to do anomaly detection (think spamassassin).
5) OSSEC, file system integrity checking, security information management, active-response, root kit detection, and distributed logging. I cant say enough good things about ossec. Imagine if AIDE could shun you, or turn off your account, and you're just scratching the surface of what OSSEC can do.
All of these (with the exeception of noexec) are in ASL 2.0 now. As well as the GUI for tying this into plesk:
http://www.atomicrocketturtle.com/asl-interface3.png
1) noexec - oft-cited and largely ineffective. This sets a flag on a file system to set it to not allow executions in that directory. Unfortunately its trivial to bypass, either by calling an interpreter to execute the application (a la: perl /tmp/foo) or even easier, uploading and executing from some other writable directory. This has been an automated process the badguys use for a few years now.
2) SELinux - this is amazingly powerful, and has a lot of potential. Ive got some high hopes for using the data labeling component to label what can run on the system and what cant (target is to do this in ASL 3.0). As shipped in fedora/centos/redhat the policies aren't that useful for now, and creating new policies isn't for the faint of heart.
3) GRsec, the TPE policy that ships by default does everything you really want to do with noexec, except its global, and driven by group id's. Its also more useful with logging, in that it tells you who did it, on what application, and how in the logs. PaX (stack overflow protection), and learning mode are the biggest advantages it has over SELinux, since the two do largely similar things with process ACL's and RBAC. ASL 1.0 was initially just a grsec'd kernel.
4) Mod_Security. noexec, selinux, and grsec are all post-exploit security control s. Mod_Security is performing input validation before you get to the application. 2.x+ suffers from some sever performance limitations over the 1.x series. So all the rules we developed at gotroot.com are currently killing the 2.x systems. That being said, 2 brings in much more granular capabilities, as well as the ability to do anomaly detection (think spamassassin).
5) OSSEC, file system integrity checking, security information management, active-response, root kit detection, and distributed logging. I cant say enough good things about ossec. Imagine if AIDE could shun you, or turn off your account, and you're just scratching the surface of what OSSEC can do.
All of these (with the exeception of noexec) are in ASL 2.0 now. As well as the GUI for tying this into plesk:
http://www.atomicrocketturtle.com/asl-interface3.png
Scott, thanks for the extremely detailed information!
ASL is in the #1 spot in the list of things to do as soon as we have finished developing our CMS and we have enough resources upgrade our system(s).
Simply put, the possibility of having all this in a unique package saves dozens of hours we have to spend every time we start on a new server - not to mention the GUI, which looks great.
Which are the minimum system requirements you suggest for running ASL 2.0 on a live server?
ASL is in the #1 spot in the list of things to do as soon as we have finished developing our CMS and we have enough resources upgrade our system(s).
Simply put, the possibility of having all this in a unique package saves dozens of hours we have to spend every time we start on a new server - not to mention the GUI, which looks great.
Which are the minimum system requirements you suggest for running ASL 2.0 on a live server?