You will still get those things in the log even if mod_security is install. The effect is that the attack won't stop, but nothing happens on your server. Every webserver is under attack from bots/scripts, ... and each attempt is typical logged in the log.

These attacks are really frequent.
There are 2 aspects to defense:
1 - prevent your site from being hacked
2 - gracefully send this attacks somewhere else

In a similar situation, I was lucky enough to be sure that NO legitimate use of my pages should have any "http://" type of content.
Thus I created a htaccess which returned an error 404 whenever "http://" was detected in the URL argument.
- the advantage is that this redirection, although it uses some CPU from the web server, does not launch any php resource, while at the same time effectively "hiding" these pages from those attacks which try to include code or to report to the "botnet shepherd"

In another situation, there were cases where http:// was in some cases part of a legitimate URL.
Since I am more comfortable on PHP than in mod_rewrite, I created a small php script that was then included at the beginning of each php script.
You might tailor it to your own use. See additional notes after the code
--------------------------
<?php
/** tests sur les hacks >**/
$la_ligne=trim('xxx'. @$_SERVER['QUERY_STRING']);
if (3 < strlen($la_ligne)) { //search for attack-specific patterns
$my_ligne= strpos ($la_ligne, 'absolute_p')
+ strpos ($la_ligne, 'catid=http://')
+ strpos ($la_ligne, 'option=http://')
+ strpos ($la_ligne, '_REQUEST')
+ strpos ($la_ligne, 'password')
+ strpos ($la_ligne, 'GLOBALS=')
;};
$my_ligne = (0 < $my_ligne);
if ($my_ligne) { // you might create some more elaborate defensive answers...
header("HTTP/1.1 404 Not Found");
exit; //stop processing if attacked
};
unset ($my_get, $la_ligne, $my_ligne, $his_host); //clears the defense variables
//proceed normal activity
?>
--------------------------
Notes on php code:
- put the include at the beginning of your code. be sure that there is no trailing space or other character
- adapt detect and answer to your special case
- this php code uses some CPU resources to run the php script... try to be as fast as possible in case of multiple botnets attacks

General notes:
- your logs show that in most cases the page was successfully run (return code 200), even if the attack itself failed; this tells the robot that it can try some other attack; returning the 404 tells the robot there is nothing to find there: it will then switch to some other page of your site, and later to some other site
- be sure to protect everything that needs to.
-- Usually all dirs should be chmod 705, except directories where file might be uploaded
-- check that every directory has an index file, whether index.htm, index.html or index.php: without an index, the directory might be readable, giving some ideas of scripts etc. The minimum would be an empty index.htm file, but you can put a simple index.php file
<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: /");
exit;
?>
-- check that all your script files are chmod 444 (or 544 in some cases), including all your index.* files
-- if you have any 'install', 'installation', 'config' or 'administration' directory... you should probably delete it or (more safely) chmod it to 000; same for script with similar names: chmod them to 000 [you might need some config files to be chmod 400)
-- chase ALL your directories for files which look foreign, just in case one hack succeeded and a trojan is now running on your site... if there are: a/ take (but don't run!) a backup copy; b/ either delete or chmod 000 the file
- in your case, the attack relies on a library of exploits currently hosted on the server http://www.m-comp.nl; in most situations, these sites are legitimate and do not even know that they have been hacked! you should send a mail to postmaster, webmaster and abuse@m-comp.nl giving them the info that your site has been highly attacked by robots trying to force the use of resources extracted from their site, and that they have probably been infected, and that you would appreciate if they could clean this library and any other extra files that a hacker might have put there.
- this part of the log shows that a large number of attacks come from IP address 124.217.243.21 ; you might consider emailing the corresponding ISP http://www.ip-adress.com/whois/124.217.243.21 (but don't hold your breath, this will probably have no impact); anyway, this IP has now been blocked by your ISP and should not bother you anymore
- this part of the log shows also that queries are sent from 127.0.0.1 which is YOUR SERVER, which presumably has already been hacked... some of the suggestions above will probably have cleaned that!

Using cpanel, you have access to the file directories, right?
- You can then check and clean the directories for unwanted "eggs" in your "nest"
- you can add "index.htm" or "index.php" in the directories where needed.
- You can change access right sto the directories

<<I cannot do it per script basis, those script might belong to our hosting client.>>
I presume you mean "hosting provider"
I presume you have installed scripts thru cpanel. The scripts (eg php) present on your site are now "your copy" and you may change them to your will (check that with your provider, of course) although you will get no support for your changes.
Changing php scripts need some php knowledge, but not to be a complete expert.
You might also ask for some (charged) assistance from your provider.

But, actually we are the hosting provider and we received the report as the attached email from my previous post saying that our shared hosting server has been used to maliciously hack other people server using PHP Inject Scripts.

I have around 300 domain hosted on the server.

The problems are :

1. I have no idea which scripts or domain that cause the error that make me think mod_security is the best way to block it.

2. I cannot alter my client php file or .htaccess without their knowlege and some more i dont even know which hosting account or scripts that has been used for the PHP inject activities.

- Are you the piradius.net reported in the mail?
- Is the IP address 124.217.243.21 part of yours? are there specific host on this machine?
- if this is the case, then certainly your server has been hacked. YOU NEED TO BE SURE THIS IS NOT DAMAGING YOUR CUSTOMERTS' SITES...

Some random thoughts/ questions

- mod_security seems to be htaccess/mod rewrite based and I would think you cannot use them without your customers' consent and so should be ruled out as a general solution.

- what does your clients' contract say? who is responsible for their own account security?

- the logs should tell which site is targeted. If this does not appear, it is YOUR site, not theirs, which is under attack. (which does not mean that their logs, if scrutinized, would not exhibit similar attacks against their won site).

- are their site hosted physically on the same machine as yours? are they in the same disk hierarchy, or are yours and theirs distinct? If this is not the case and if this is possible, you should plan for doing that at the first occasion (don't do it under pressure).
- I presume you are taking backup of everything, including their sites. If not, you should until things sem fairly back to normal: it will ensure that, in case of a major problem, the diruption will be as short as possible.

- Is the IP address 124.217.243.21 part of yours? are there specific host on this machine?

>> Yes, 124.217.243.21 is the main shared IP for this server.

- if this is the case, then certainly your server has been hacked. YOU NEED TO BE SURE THIS IS NOT DAMAGING YOUR CUSTOMERTS' SITES...

>> I don't think so, refer to the logs, 127.0.0.1 and 124.217.243.21 is normal when access on APACHE 2.28 webserver . It is the way apache is logged now (New Version). 100++ of my other server also having the same logs style when people accessing the websites hosted on the server.

Some random thoughts/ questions

- mod_security seems to be htaccess/mod rewrite based and I would think you cannot use them without your customers' consent and so should be ruled out as a general solution.

>> We are providing shared hosting service in which for security wise we can alter any of our terms of services and SLA.

- what does your clients' contract say? who is responsible for their own account security?

>> Own account security is off course their responsibility but the overall server setup is our responsibility.

- the logs should tell which site is targeted. If this does not appear, it is YOUR site, not theirs, which is under attack. (which does not mean that their logs, if scrutinized, would not exhibit similar attacks against their won site).

>> No , this is the overall apache server logs that logged everything accessed using apache 2.28.

- are their site hosted physically on the same machine as yours? are they in the same disk hierarchy, or are yours and theirs distinct? If this is not the case and if this is possible, you should plan for doing that at the first occasion (don't do it under pressure).

>> Off course no, we managed more than 5000 hosting account on few of our servers.

- I presume you are taking backup of everything, including their sites. If not, you should until things sem fairly back to normal: it will ensure that, in case of a major problem, the diruption will be as short as possible.

>> Yes, we have a mirror backup . daily, weekly and monthly backup on separate server.

Therefore, and since your clients' directories are not under your own, you can do "whatever you want" on your own web site: you can change your own script as needed etc.

The problem is then
a - your site, and probably some others as well, are under attacks from one or several hacked sites at IP address 124.217.243.21
b - one of those is most probably your own site (127.0.0.1)
c - you have found no easy way to check which of the sites is/are originating the "sniffing" of the attacks.

My thoughts:
1 - your own site needs to be cleaned, using all or some of my suggestions or equivalent.
2 - Once this is done (ie, you have found and cleaned at least one source of the scripts), check in the logs if the attacks still persist. If no, MAYBE the problem is solved for now. If yes... are there still attacks coming from 127.0.0.1? if no... MAYBE your machine is cured, and some other is not.
3 - To chase other machines: if you have the legal right to do so, look to their sites' logs file: are there other sites under attacks? from which IPs? are there any from 127.0.0.1? if yes, then probably these very sites have been hacked. But here you need to work with your client to clean their sites...

4 - The sites are running on Apache, presumably on Linux. Check the whole disks with anti-viruses. Most recent anti-virus also look for this type of trojan...

Featured Post

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Nothing in an HTTP request can be trusted, including HTTP headers and form data. A form token is a tool that can be used to guard against request forgeries (CSRF). This article shows an improved approach to form tokens, making it more difficult to…

Learn how to match and substitute tagged data using PHP regular expressions. Demonstrated on Windows 7, but also applies to other operating systems. Demonstrated technique applies to PHP (all versions) and Firefox, but very similar techniques will w…