My web server at work had two files uploaded to it that run remote commands via php. I'm not sure when, the files have last modified dates of 11/2005. I only have 4 user accounts on the server and they all have decent passwords...

My only thought is that I frequently chmod 777 -R my /var/www/html directory because I work on the websites with others and we get permissions problems sometimes... but someone would have to be a user first, before they could upload/save files to a directory... right?

Fedora Core 3 x86
dual opteron 2.0ghz

The server is on the DMZ of our sonicwall (firewall hardware). We've been getting the repetative ssh login attempts that seem to be going around, but they all seem to fail.

I don't know if it helps, but one of the files would only let you run commands if you authenticated yourself, on prompt, with the name "sh4rky" and the password "roxx"

and everything's in german.

What kind of measures can I take here to protect myself?

Once hackers have been able to hack into your system (bypassing security/firewalls), your system is compromised.
A full re-install is the only option. Sorry to bring you the bad news.

Hackers most likely try to obtain root access when they're inside, so your user authentication may be of secundary importance. But that depends on the security measures you've taken.

You talk about the PhP code. Was it run as root?

For the future, a few general tips may help prevent mayhem:
-regular backups;
-tighter security: less programs running as root, strict file permissions, no unnecessary opened ports,
latest updates - also for the firewall -, ... come to mind. An additional firewall on your webserver (iptables)
or access restrictions like tcpwrappers or something like tripwire may be handy.

Also, instead of chomoding the files with 777 make a group for your 4 users who need access to the files and give that group full permissions instead of having read, write and execute permissions for everyone.

My web server at work had two files uploaded to it that run remote commands via php. I'm not sure when, the files have last modified dates of 11/2005.
Are distro release, Apache PHP and any PHP apps updated to "latest"?
Do the system and application logs go that far back?


My only thought is that I frequently chmod 777 -R my /var/www/html directory because I work on the websites with others and we get permissions problems sometimes.
Even though it's clear the box is misconfigured (thats bad and purpose doesnt matter) it's more likely something flawed in any PHP apps or PHP.


but someone would have to be a user first, before they could upload/save files to a directory... right?
Right. Prolly Apache in your case :-]


I don't know if it helps, but one of the files would only let you run commands if you authenticated yourself, on prompt, with the name "sh4rky" and the password "roxx"
Save me a copy?


What kind of measures can I take here to protect myself?
In the first place please let the box be run by a capable admin or scale up your knowledge. Misconfiguration is one of the top-20 mistakes. Next to the other advice already given, please check out any recent thread about PHP-related compromises in this forum (we've been going over it quite extensively) and check out the LQ FAQ: Security references. We've added a piece at the end on LAMP security with emphasis on PHP.

* These are the days of the botnets and many crews are primarily interested in trying to getting their quota of slaves ready. Since obsolete, unrestricted, outdated and misconfigured installations of Apache/PHP apps/PHP already allow for enough rights to run whatever it is they need to run the chances of a full scale root account compromise appear to be less. Note: this is not to argue it did not happen to you! The reason I always recite the mantra "Repartition, Reformat, Re-install from scratch" is simply because newbies do not have the time and knowledge to set up a system in a way that provides enough clues to resurrect a box safely. Even then there will be no evidence passwords aren't nicked. Since you already have shown MAC-times for the files to be more than two months ago I agree you should have the box re-installed from scratch and hardened properly.

** Since this is a box in a work environment, see if you can get your hands on a staging box to fsck around with (on the intranet) and only copy over stuff to the (properly hardened) production box (in the DMZ) that's finalised and well-tested.

*** If you can't hand off the box to an admin you can ask questions here, but please make sure you have read enough of the core docs.

Once criminals have been able to hack into your system (bypassing security/firewalls), your system is compromised.
A full re-install is the only option. Sorry to bring you the bad news.

Criminals most likely try to obtain root access when they're inside, so your user authentication may be of secundary importance. But that depends on the security measures you've taken.

You talk about the PhP code. Was it run as root?

For the future, a few general tips may help prevent mayhem:
-regular backups;
-tighter security: less programs running as root, strict file permissions, no unnecessary opened ports,
latest updates - also for the firewall -, ... come to mind. An additional firewall on your webserver (iptables)
or access restrictions like tcpwrappers or something like tripwire may be handy.

doublejoon,

duely noted...

Thanks guys. Great idea Cramer.

I work for a small company that wants to move to linux but I'm the only one who knows anything, and I would like to defend myself a little and say I've been able to swap an entire e-commerce windows-hosted website with an as400 backend to a linux-hosted website with an as400 backend. It wasn't easy, and I learned a lot.

What I know about linux I've gotten from hating Windows in my private time (for about 5 years now, I might add), it's just that at home I have not had to protect myself from ravenous criminals.

I mean, I've installed and loved gentoo (2004.1 when it was new). That means I'm L33T, right?
No not stage 1.

Anyway, I've learned one thing at least: I would not be so stressed right now if this was someone else's problem. I should stop trying to do everything and just make websites.

Oh, right, so I forgot to say what else I've found since my first freak out.

I went through my apache logs (in urchin) for the day that the files had as their last modified dates. Just for kicks, I drilled down the domain starting from .de and one german domain stood out 10:1 traffic compared to others. Then I looked within a week radius of the date and the domain kept coming up... but not much outside of that week. What was the domain? uni-leipzig.de

So needless to say it may be a highjacked lab PC, or it may be the criminal. Either way one measure I've taken is to deny the domain (we don't sell outside of the US and Canada anyway).

I've also been able to deduce that they didn't run anything as root and couldn't use sudo. I WOULD format the machine, but I still haven't learned how to secure it so they could easily do the same thing again and then I would have wasted a lot of time giving myself a false piece of mind.

No damage has been done now. I will try to figure out how to secure my development server that is pretty similar, except that it's a single amd64 with fc3 64bit and not a dual opteron with fc3 32bit.

and now dually noted