So have we hit a bit of a dead end? Did you get my "PM"
My first reply followed your email within aprox one hour IIRC and I posted my preliminary this morning. Basically it supports the suggestion PHP "include" is the culprit like you posted round about post #25.


I want to wipe the system either tomorrow or Sunday. Any further info I can get off it before I do?
No, not really IMHO. Well, OK, a tarball of the cruft found in your docroot wouldn't hurt :-]


Really want to avoid making the same mistake I obviously made this time so as to avoid the obvious.
That depends on what you want to invest, really. As far as I've seen this box is being utilised as both dektop and server. Based on risk, if you have the HW, that would be the first split I'd make: webserver in the DMZ, workstation in the LAN.

But let's work out the "plan" in a new thread, shall we?
I think it's appropriate in every aspect.

Oh oops. I turned off postfix through the mayhem and forgot to turn it back on.
So they/them/worm et al used the php include to upload a file to my server ? Didn't know that was possible, how can one avoid this ?


For sure. I think I have already done it.

No, its a server only and its been split in 2 with vmware running an Trixbox on top of it.
I think there maybe files on it (in /home) that indicate a Desktop environment from when I first set it up many years ago and used a GUI with Mandrake 9.1, I think. But no its not used as a desktop. It doesnt have X.

I think I will follow Marcus's thread on setting up a secure Debian server when I re-install today. I want to chroot apache with my new install.

Woke up this morning with bloody port 80 used by process 17159 was /sbin/syslogd EEEK!
Did a pcat of the process (see learning new things here ) and then had a little look through it with vi.



Sort of explains why these process's are not showing where they are really starting, which must be /tmp

I am going to give a LiveCD (Helix) a shot now before I wipe it out.

What do you recommend for the attached storage I have on the system thats not part of the OS ? All through IDE in RAID 1 hard disks.
Just scan them with a few AV's like ClamAV and NOD32 ?

Here is some more info about this exploit. I have only just started reading it.

http://www.geocities.com/hsia_joe/Tutorial.txt

And this is interesting.
http://www.howtoforge.com/apache_sec...ing_with_nikto
For testing the security of your apache install.

Its apt-getable too.

I have 7 issues with the way my apache is right now.
I am going to chroot and then apply mod_security on my install and then see how Nikto goes with a scan then.
Mod_security tut: http://www.howtoforge.com/apache_mod_security_p2


PS just trying to add info I have discovered for anyone reading this thread later on with the same issues.

Would I be right assuming the krad local kernel exploit to get root would of failed as its a fully updated system ? There wouldn't be any know exploits in the Debian stable kernel right ?

I also found this in the running binary

Woke up this morning with bloody port 80 used by process 17159 was /sbin/syslogd
Well, that's one reason I put emphasis on mitigation before investigation.
A compromised box shouldn't be allowed to interact with any network.


So they/them/worm et al used the php include to upload a file to my server ? Didn't know that was possible, how can one avoid this ?
First thing would be to read up on security in general and then application security. See for instance the LQ FAQ: Security references. Post #6 "Securing networked services" for details on the "AMP" part of LAMP.

Security is a multi-facetted approach and one layer is the basis for the next, so IMHO the first thing would be to make the installation w/o any network-facing and supporting daemons and services like Samba, Apache, MySQL and PHP. You can install those later on. Prepare, configure and harden the box itself in all details after installation (SW scrubbing, updating, backups, auditing facilities including logging and logreporting, user restrictions, network access restrictions). If you skip that layer the rest is a waste of time. For those that can run SELinux or GRSecurity I would recommend it. It may be an investment in time and effort and it does come with a learning curve but it also truely enhances the security posture of the box (if configured, monitored and adjusted right). Install Snort if you can also check out the Bleeding rulesets.

Wrt LAMP find out if Hardened-PHP or Suhosin are a possibility, basic php.ini settings you should apply wrt security and based on for example the OWASP "Top Ten Security Vulnerabilities", "extra" settings like "allow_url_fopen" if the application permits. ( For every ini switch you don't apply the more rigid/strict/fascist settings for, ask yourself if this is because the application doesn't work or if it's something else. If the application doesn't work, ask yourself if you should continue using that application. Some PHP-based apps explicitly note they won't work with for instance "safe-mode=on". If there's no way out then maybe compartmentalise things (virtualisation). ) Next would be configuring Apache and mod_security. Also see http://www.gotroot.com/mod_security+rules and the mod_security rule generator: http://leavesrustle.com/tools/modsecurity/. And yes, the Debian HOWTO by Marcus has most of the details on that.


Would I be right assuming the krad local kernel exploit to get root would of failed as its a fully updated system
Depends on the kernel version but since it's old I'd say yes.


I also found this in the running binary
Finders keepers, eh? :-]

Thanks heaps for all your time and efforts unSpawn. Much appreciated.

I have installed a new clean Debian install, following Marcus' howto. Takes so much long having to read as you install, but its worth it in the end.

I have also found other tut's etc whilst install in my searches. Turned several functions for php, even found apache's mod_security that sounds awesome!

Thanks again and we'll see how I go