How to find PHP injection through logs

URL Injection — attempt to inject / load files onto the server via PHP/CGI vulnerabilities

Sample log report including date and time stamp (1st field is “request”, 2nd field is the IP address or the domain name being attacked, and the 3rd field is the IP address or domain name of the attacker)

Request —– IP attacked —— IP of attacker


Request: 111.222.333.444 – – [19/Apr/2009:08:35:02 -0500] “GET /?custompluginfile[]= HTTP/1.1” 500 3572 “-” “Mozilla/5.0” SesohkAx1jYAAFNIEg0 “-”

Request: 111.222.333.444 – – [19/Apr/2009:08:35:03 -0500] “GET /fanzine/?custompluginfile[]= HTTP/1.1” 500 3572 “-” “Mozilla/5.0” Sesoh0Ax1jYAAFN@Eng “-”



Reference from

What is suPHP is:
On most Apache servers, PHP runs as an Apache module. This is the default method of installation. Many hosts have this setup because it is default and potentially they do not realize that it is also possible to configure PHP as a CGI. Running PHP as a CGI can be more secure whilst also avoiding file and directory ownership issues.

suPHP provides the facility to have all scripts running the relevant user account instead of under the Web Servers account. This facility allows the server Administrators to isolate and manage malicious or runaway script usage very quickly, avoiding unwanted or un-authorized scripts from running for a lengthy period of time. AptHost uses suPHP on all shared, semi-dedicated and reseller hosting servers.

What does suPHP Do?
777 Permissions
With non- suPHP configurations, PHP runs as an Apache Module it executes as the user/group of the webserver which is usually “nobody”, “httpd” or “apache”. Under this mode, files or directories that you require your php scripts to be able to write to need 777 permissions (read/write/execute at user/group/world level). This is not very secure because it allows the webserver to write to the file, it also allows anyone else to read or write to the file.

Under suPHP configurations, PHP running as a CGI with “suexec” enabled (su = switch user, allowing one user to “switch” to another if authorized) – Your php scripts now execute under your own user/group level. Files or directories that you require your php scripts to be able to write to no longer need to have 777 permissions. In fact, 777 permissions are no longer allowed, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a “500 internal server error” when attempting to execute them, this is done to protect you from someone abusing your scripts. Your scripts and directories can now, only have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else).

My script requires 777
So what about php scripts that say they require 777 permissions on some of their directory or files to work, such as a Joomla!, Forums, photo galleries and alike? Due to the transparent nature of suPHP this is solved very simply, any directories stated as requiring to be “writable” or “777” can safely be set to 755 (the maximum) instead. This is because, now that the web server runs under your own user account, only your own user account needs full write and execute permissions.

Goodbye “.htaccess” and Welcome “.ini”
Under the old Apache Module mode it was possible to manipulate the PHP settings from within a “.htaccess” file placed in the script’s top-level directory, this was also recursively applied to all other directories below it.

For example you could turn on the php setting “magic_quotes_gpc” with this line in .htaccess:

php_value magic_quotes_gpc on

Now, when PHP is running as a CGI and suPHP protected, manipulating the PHP settings is still possible however you can no longer make use of a “.htaccess” file. Using .htaccess with the required PHP prefix of “php_value” will cause a “500 internal server error” when attempting to access the scripts. This is due to php no longer running as an Apache module, thus Apache is unable to handle those directives any longer.

What is a php.ini file?
The php.ini file is a configuration file that the server looks at to see what PHP options have been made available to the server or what their setting are, if different from the server’s default php.ini. While the name may seem advanced to those unfamiliar with it, it is in essence a simple text file with the name php.ini

How to create a php.ini file
To create a php.ini file, just open up a text editor, add in the lines you need and save the file. You can name the file whatever you wish when saving, to ensure the correct FTP transfer mode is used, you might wish to name it “php.ini.txt”. Once you have configured all your settings, upload the file to the directory where your script is located and then rename it back to php.ini

For example you can turn on the php setting “magic_quotes_gpc” with this line in php.ini:

magic_quotes_gpc = on

In many cases, you might need to have multiple copies of the same php.ini file in different directories, unlike .htaccess files, php.ini files are not applied recursively to lower directories. If you need the same functionality across all lower directries also, you will then need to copy the php.ini file each directory in turn that will have .php scripts running from within them. Click here for a sample php.ini configuration file.

If you added a Mimetype to the system in order to run html files as php scripts (AddType as .htaccess command), you will have to remove it and add an ApacheHandler instead. This is easy to do though. Just log into your control panel, then click on Apache Handlers and add the following:

Extension: html (or htm)
Handler: application/x-httpd-php

Protecting your php.ini file:
To protect your php.ini you should set its permissions to 600. Additionally you can add the following line to your .htaccess file:

<Files *.ini>
Order deny,allow
Deny from All

Troubleshooting, something went wrong
My php script doesn’t work or I have an error message.

1. Check that the php script that you are attempting to execute has permissions of no more than 755 – 644 will work just fine normally, this is not something that will need to be changed in most cases.

2. Check that the directory permissions that the script resides within is set to a maximum of 755. This also includes directories that the script would need to have access to also.

3. Check that you do not have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script.
The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.

Invalid tgz file : Cpanel PEAR Installer problem

The problem is caused by differences in the way PHP 5.2.x parses code, and can be fixed by manually patching the listContent function in PEAR’s Archive_Tar package.

The fix is to track down the /usr/local/lib/php/Archive/Tar.php and/or /usr/lib/php/Archive/Tar.php files and change the following removing the line marked ‘-‘ and adding the lines marked ‘+’…

    function listContent()
        $v_list_detail = array();

        if ($this->_openRead()) {
+            $r = $this->_extractList('', $v_list_detail, "list", '', '');
+            if (!$r) {
-           if (!$this->_extractList('', $v_list_detail, "list", '', '')) {
                $v_list_detail = 0;

        return $v_list_detail;

Drop DDOS attack

1. Find.. to which IP address in the server is targeted by the ddos attack

netstat -plan  | grep  :80 | awk ‘{print $4}’ | cut -d: -f1 |sort |uniq -c

2. Find… from which IPs, the attack is coming

netstat -plan  | grep  :80 | awk ‘{print $5}’ | cut -d: -f1 |sort |uniq -c

3. Then find the TTL values of the attacking IP addresses

tcpdump -nn -vvv host xxxx |grep yyy (xxxx = ip attacking and yyyy = ip being attacked)

usually we need only tcpdump -nn -vvv host xxxx (as attack is coming from numerous ips)

4. Now block all the ips matching the TTL value obtained from the above script

iptables -A INPUT -p tcp -s -d yyyy -m ttl –ttl-eq=zzz -j DROP (zzz is the ttl value)


Install mod security and dos evasive


Harden the sysctl parameters (kernel params) to mitigate the current attack.

Increasing the backlog queue size and decreasing the backlog queuing time might help a bit.


Also install an open source script to prevent DDoS attack to certain extend.

MediaLayer was in need of a script to automatically mitigate (D)DoS attacks. The necessity started when MediaLayer was the target of a rather large, consistent attack originating from multiple IP addresses. Each IP would have a large amount of connections to the server, as shown as by:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

It became a general practice for us to be blocking IPs with a large amount of connections, but we wanted to get this automated. Zaf created a script mitigate this kind of attack. We kept improving it to meet our own needs and eventually posted it on Defender Hosting’s Forum. (D)DoS-Deflate is now recognized as one of the best ways to block a (D)DoS attack at the software level.

License Agreement

You can view a copy of the license agreement here.


chmod 0700


chmod 0700 uninstall.ddos

Reference :