[sf-lug] Hacked RHEL4/PHP4 server

Rick Moen rick at linuxmafia.com
Thu May 22 02:21:08 PDT 2008

I wrote:

> The rebuild should (given root compromise) avoid re-using any existing
> program code, any existing server configuration files, and any existing
> user dotfiles and dotfile directories -- because all of those need to be
> considered suspect.  The only files you can just roll forward are
> non-program datafiles -- after, of course, getting rid of the Web site
> defacement.

Oh, and (again, assuming you conclude that root compromise has
occurred), you'd of course want to carefully avoid re-introducing any of
the same security weaknesses that are present in the current,
compromised system.  So, you'll want to disable all existing passwords
and keypairs previously usable for access, and do a careful security
check before letting any of the prior users back in, and before opening
up any public services (even the Web server).  

One of the things you will want to check is security of the PHP
interpreter itself (and of its http integration).  It's very common for
PHP to install in an appallingly security-risky configuration -- with
the packagers justifying that default by putting comment lines at the
top of the php.ini file saying (paraphrased) "This configuration is for
development and testing _only_ and should never be exposed to public

And the tragedy is that, of course, a huge number of sysadmins never
bother to look at php.ini, and without thinking expose that unsafe
configuration to the public Internet.  That could easily have been the
key weakness that let the bad guys in -- though I have no specific
reason to suspect that.

Some suggestions for tightening up PHP configurations:
"PHP" on http://linuxmafia.com/kb/Security/

Some thoughts about how you might, in the future, make sure you can
determine for certain if/when a system has become security compromised:

More information about the sf-lug mailing list