It seems as if automated website attacks by compromised machines is something that all webmasters have to think about, because I made the mistake of installing an old version of Wordpress and was surprised to find that my server was now suddenly making a lot of outgoing connections. The sensible thing to do would of course have been to upgrade wordpress, but I did not feel like doing this, so I instead installed Mod Security, which stopped the attacks, but it also stopped some of my sites from working properly as well. This would normally be the point at which a lot of people would have given up on Mod Security and resigned themselves to the Wordpress upgrade treadmill, but I still did not feel like submitting, so instead decided to do what a real Mod Security user has no choice in doing, which is to instead sit down and work out which rules are being triggered, then disabling them one at a time. It is also possible to disable the rules for certain locations, but my sites are not used by many people at the moment, so I only disabled the rules that affected the normal functions that I use. If a server admin tries to tell you that Mod Secutity is not worth the hassle, then you might have to be caeful, because it could be just that they are a lazy admin. Mod Security is a bit like SELinux, because a lot of people will say just to disable it, likely because they just want to get paid for the quick and easy work, while still leaving their customers websites vulnerable to any exploits that they have not yet been attacked by. There is also a bash script that can be used to analyse the Apache logs, after an admin user has performed some work on the site, to see which paths the rules would have to be disabled on, so that the admin can do their work, while the paths that the normal users would use, would still have the rules enabled.
I still remember the time when I was helping with the security of a website, for one of the political parties and I ended up having to go through almost the whole list of modules and methods, that are available to stop Apache served websites from being attacked. In the end the attackers had to give up on the free attacks and it looks like they finally decided to pay a group to hit the site with a large quantity of robots. In the end I had to tell the company that I was doing the work for, that they would have to hire the services of one of the DOS prevention companies, if they wanted to keep the site online.
I have also had to write a little script, which has been acting as my last line of defence, when I don't have time to find out which site has been compromised. It is a little PERL script that I run when the attackers have managed to upload their files, which looks for scripts that make outgoing connections and terminates them. It has been running for a while and the log has a reasonable amount of entries, for the processes that it has terminated.