PHPStress – Denegacion de servicio PHP

Este ataque de denegación de servicio se reduce a una forma de la que se configuran los servidores web más modernas. En pocas palabras, las llamadas PHP simples y constante hará que los servidores web a llenarse de procesos PHP abiertas. Es una manera muy simple para una sola persona para acabar con un servidor web mediante el consumo de todos los recursos disponibles.

Usando una conexión de cable / DSL estándar, este ataque puede inundar la CPU de un servidor web Linux y RAM usando peticiones HTTP estándar. Este ataque Apache o efectos NGINX servidores web que manejan el contenido dinámico PHP usando PHP-CGI o PHP-FPM (que incluye los sitios web de WordPress). Además, las solicitudes formuladas por las configuraciones del servidor web de ataque (o por defecto) seguirán manteniendo los recursos del servidor en uso mucho más allá del final del ataque.

Para ejecutar el ataque, establecer sus parámetros de URL y el tiempo de retardo de destino y el guión se encargará del resto.

Lo que este ataque es capaz de alcanzar

Usando una conexión de cable / DSL estándar, este ataque puede inundar la CPU de un servidor web Linux y RAM usando peticiones HTTP estándar. Este ataque Apache o efectos NGINX servidores web que manejan el contenido dinámico PHP usando PHP-CGI o PHP-FPM (que incluye los sitios web de WordPress). Además, las solicitudes formuladas por el ataque seguirá manteniendo los recursos del servidor en uso mucho más allá del final del ataque.

También es importante señalar que este ataque tiene la misma premisa que Slowloris . La diferencia principal es que Slowloris se centra en comer hasta HTTP (Apache) conexiones, mientras que este ataque se centra en comer PHP-CGI o PHP-FPM conexiones (ya sea dentro de Apache o Nginx).

¿Por qué este ataque funciona PHPStress?

En la mayoría de los entornos, (PHP) contenido dinámico se maneja una de dos maneras. Ya sea con PHP-FPM o FastCGI PHP (mod_fcgid). Mientras que los paneles de control modernos de alojamiento compartido como Plesk, Cpanel, ISPConfig han comenzado a moverse hacia PHP-FPM como el estándar para el procesamiento de contenido dinámico, la mayoría (por defecto) proporcionar tratamiento de contenidos a través de PHP FastCGI.

nginx_php_process_flow

FastCGI / mod_fcgid

Una aplicación FastCGI se ejecuta fuera del servidor web (Apache o de otra forma), y espera a que las solicitudes del servidor Web utilizando una toma de corriente. Cuando FastCGI / PHP-CGI está sintonizada correctamente, ignorará las solicitudes en lugar de seguir para asignar memoria. Durante ese tiempo, los clientes tiempo de espera. Las cosas van a volver a la normalidad cuando el tráfico pesado se desploma.

Un punto importante a tener en cuenta: Cuando PHP-CGI se ejecuta fuera de los procesos disponibles, Apache entrará en funcionamiento y comenzar el desove procesos adicionales para tratar de satisfacer la demanda. Este proceso se llena rápidamente con el servidor de memoria pesada procesos httpd (que incluyen todo el intérprete de PHP incrustado en cada proceso). El número máximo de procesos de Apache engendrado será el número ajustado en su ServerLimit o MaxClients ajuste (normalmente 256 o 512). Esto llevará al servidor web mucho tiempo para recuperarse de lanzamiento de 256 procesos de Apache.

PHP-FPM (FastCGI Process Manager)

FPM (FastCGI Process Manager) es una implementación alternativa de PHP FastCGI con algunas características adicionales (en su mayoría) útiles para los sitios de carga pesada. En mi propia experiencia, PHP-FPM es considerablemente más rápido en el procesamiento y manejo de PHP.

Configuración del ataque

En primer lugar, descargar PHPStress de GitHub  o clonar el repositorio:

git clone https://github.com/nightlionsecurity/phpstress phpstress

Para ejecutar el ataque, establecer sus parámetros de URL y el tiempo de retardo de destino y el guión se encargará del resto. Con el fin de lograr los resultados a continuación, el script necesita ejecutarse utilizando un retardo de 0 para parámetros de la petición y de retardo.

php phpstress.php www.targeturl.com -d -r 0 0

Resultados

En ambos casos, los procesos de FPM y / o CGI están completamente consumidas por las solicitudes; la memoria del servidor está al máximo, y todo se paraliza. En el caso de los servidores Apache o PHP-NGINX ejecutan FCGI, hay algunas cosas interesantes a tener en cuenta.

PHP-FPM

En los servidores de PHP-FPM, el número máximo de procesos generados se mantiene sobre la base de lo que está en el archivo de configuración. Si sus
pm.max_children = 25, entonces el número máximo de procesos generados se quedará en 25.

Dependiendo de cómo se establecen los ajustes de tiempo de espera, los procesos permanecerán abiertas durante al menos esa cantidad de tiempo después del ataque (generalmente dos minutos).

PHPstress PHPStress PHPStress

PHP-FCGI

Los resultados con FastCGI son mucho más interesantes. Como tampón FastCGI filles arriba, las solicitudes se parecen conseguir en cola y procesadas por Apache. En lugar de seguir a desovar más procesos FastCGI, Apache entra en su directiva MaxClients y pone en marcha los procesos de igualar. El resultado es un servidor completamente invadida por cientos de procesos de Apache generados. Ver abajo

PHPStress PHPStress PHPStress

Ajustes a revisar para la mitigación

Éstos son algunos de los parámetros de configuración estándar para Nginx y FastCGI que tendrá que ajustar.Los ajustes siguientes son los valores por defecto, que no son óptimos y deben ser ajustados para adaptarse a sus necesidades. Yo por lo general mantengo mis ajustes de tiempo de espera de 1-2 segundos.

FCGID.CONF

/etc/httpd/conf.d/fcgid.conf

# El número de segundos de tiempo de inactividad antes de que un proceso se termina
FcgidIOTimeout 1000 # periodo máximo de tiempo, el módulo esperará al intentar leer o escribir en una aplicación FastCGI
FcgidMaxProcessesPerClass número 100 #maximum de los procesos por clase (usuario)
FcgidIdleTimeout procesos de aplicación # 240 que no han manejado una solicitud de este período de tiempo se dará por terminado
FcgidProcessLifeTime 3600 # máximo de por vida de un solo proceso (segundos)
FcgidMaxProcesses número 1000 #maximum de procesos de aplicación FastCGI que pueden estar activas al mismo tiempo.

Apache – HTTPD.CONF

/etc/httpd/conf/httpd.conf

Tiempo de espera 60
KeepAliveTimeout 15
KeepAlive Off
MaxKeepAliveRequests 100


	StartServers 8
	MinSpareServers 5
	MaxSpareServers 20
	ServerLimit 256
	MaxClients 256

Php-Fpm.Conf

/etc/php-fpm.conf

; Plazo de procesos hijo para esperar una reacción a las señales de maestro.
; Las unidades disponibles: S (egundos), (m inutos), h (el nuestro), o d (ays)
; Unidad por defecto: segundos
; Valor por defecto: 0
process_control_timeout = 10s

/etc/php-fpm.d/domain.conf

; Por defecto el desove uso OnDemand (esto requiere php-FPM> = 5.3.9)
pm = OnDemand
pm.max_children = 50
pm.process_idle_timeout = 60

 

Descarga: https://github.com/nightlionsecurity/phpstress

Fuente: https://www.nightlionsecurity.com/blog/news/2014/phpstress-dos-attack-php-nginx-apache/

Leave a Reply

%d bloggers like this: