> The messages in the log file indicate that they used some command > injection in a script to call wget and download the files into /tmp. > I'm fairly sure it was via a bad script, and I'm trying to locate > which script was used, so far with no success.
Common PHP scripts in wide use (Nukes, phpbb etc). have been common vectors for script injections. Firstly, check for security warnings for all the PHP (or other) scripts you may be running. Secondly, if the box is mainly a web server, use 'pf' to egress filter. If the machine should not be making outgoing connections to the Internet, block all outgoing traffic. This will go a long way to neutering skript kiddie attacks like this (wget will no longer function). Many people seem to forget egress filtering - don't! It's as important to stop the box making outgoing connections that are not authorized as it is to stop it accepting inbound connections that are not authorized! If you need to make outgoing connections from your webserver, set up your egress pf rules using a default deny policy, and only authorize connections to known hosts. You should have no rules that allow outgoing connections to any address. If some users on the machine need to be able to make outgoing connections, pf allows you to allow some users (or groups) permission to call out, but deny others. Also make sure your outgoing email is secured - you don't want someone to exploit a buggy PHP script on your system and then turn your machine into a spamming or phishing zombie (it happens with depressing regularity, especially for web servers with decent connectivity - they are sought after by spammers/phishers especially if they are on spam-intolerant networks that haven't been blacklisted by RBLs). If your web server really must make SMTP connections to the outside world, consider ways of rate limiting it so it is useless to a spammer (and you can catch it). With a little time with 'grep' it's often not hard to find evidence of command execution exploits being used against PHP scripts running on your server, and from there you can find the originating IP - you can use the security warnings about the compromised PHP script to figure out what regular expression to use to do the post-mortem analysis on your Apache logs.
