Servidor Apache / Linux, ataque DoS desde su propia IP

Lo primero: descubre de dónde provienen estas solicitudes. Tiene que ser un proceso local, es probable que nada más sea capaz de falsear un protocolo de enlace TCP en una plataforma Linux moderna (es decir, nada que luego proceda a desperdiciar tal hazaña al solicitar aleatoriamente imágenes).

Si hay URL recurrentes, puede ocultarlos detrás de RewriteRule para que cualquier solicitud de este tipo active realmente un script . En el script puede ejecutar verificaciones adicionales para ver si la solicitud es legítima (y luego generará los encabezados adecuados como si fuera la imagen que espera el cliente legítimo), o si es una de las solicitudes falsas. Contra la solicitud falsa puede iniciar sesión, por ejemplo. el puerto entrante Armado con eso, puede consultar netstat y averiguar el proceso. También puede ejecutar ps e inspeccionar todos los procesos activos en el momento de la solicitud falsa.

Estoy bastante seguro de que el culpable demostrará ser Apache (una vez tuve un script de "primado de caché" que se deshonró en mí debido a una modificación de vhost; había olvidado poner el script en crontab) y tenía síntomas realmente extraños , algo así como el tuyo, hasta que todo volvió a mí, pero tu caso se siente diferente).

Para refinar aún más la escena mientras contiene los costos, puede agregar PID / TID a CustomLog de Apache. Luego, podrá realizar una verificación cruzada de las solicitudes recibidas del niño descarriado de Apache.

Otra posibilidad es determinar exactamente cómo se realizan estas solicitudes. Si a través de Apache, esto significa fopen_wrappers, cURL, funciones de socket, o quizás utilidades de shell (ambas deberían aparecer en la salida ps y resultar en una sobrecarga del servidor mucho más masiva). Puede preparar una serie de guiones que:

• reinicie con gracia Apache sin ningún cambio
• "", inhabilitando temporalmente una de esas funciones
• "", volver a habilitar igual

Después de verificar (solo para estar seguro) de que un reinicio no soluciona el problema (si lo hiciera, sería una lata de gusanos muy diferente), puede proceder a deshabilitarlo temporalmente. un par de segundos cada uno, no más - una función tras otra. Supongamos que deshabilitar el enrollamiento hace que el sistema vuelva inmediatamente a la normalidad: entonces podría restringir las investigaciones a los scripts usando cURL, y tal vez incluso ajustar la función cURL con un contenedor de registro.

En caso de que la parte culpable resulte no ser Apache, aún podrá determinar qué está haciendo esto; luego vuelva a instalar el programa afectado (incluso si encuentro que es poco probable que alguna anomalía aleatoria convierta un programa en un solicitante repetido de HTTP-GET) o inspeccione su configuración, archivos de datos auxiliares, scripts, y así sucesivamente, buscando para cualquier diferencia de una instalación limpia conocida. Como no suelo creer en los gremlins, espero que al final se destaque alguna diferencia.

Unix (y Linux) tiene una gran cantidad de herramientas para analizar cosas como esta. Mi primera parada sería tomar la salida de netstat -nap, por ejemplo. en mi máquina local ...

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
...
tcp        0      0 192.168.0.2:80              192.168.0.2:59875           ESTABLISHED 5281/httpd
...
tcp        0      0 192.168.0.2:59875           192.168.0.2:80              ESTABLISHED 32588/chrome
...

Aquí puedo ver que Chrome (pid 32588) está conectado al puerto 80 / httpd (pid 5281). Dado que esta es una instalación previa a la bifurcación de apache, puedo obtener más información sobre el proceso httpd registrando% P o buscando en / proc / 5281 / fd (este último probablemente requerirá scripts para capturar los datos en el momento de la solicitud) ).

Esto le permitirá identificar el proceso del cliente.

Los candidatos más probables son un proxy mal configurado o un código con errores.

Si este fuera mi servidor, estaría ejecutando un strace en Apache. Ejecutar esto en todos los procesos secundarios en modo prefork puede requerir bastante uso de disco, especialmente cuando su servidor ya está sobrecargado. También debe vigilar el espacio en el disco, porque si se agota, Apache deja de atender las solicitudes.

Asegúrate de usar una longitud suficiente para capturar la solicitud completa: -s 400 debería hacer.

Si Apache está realizando solicitudes a sí mismo, cualquier cadena GET aparecerá en los volcados de strace para dos PID diferentes: una que realizó la solicitud y otra que la recibió. En el que hizo la solicitud, desea encontrar la solicitud que recibió y estaba procesando cuando se hizo la solicitud a sí mismo.

Normalmente hago algo como esto:

for x in 'ps -ef | grep apache | awk '{print $2}''; do strace -s 2000 -p $x -o trace.$x & done

Si desea limitarse a un subconjunto de hijos de Apache por motivos de rendimiento, agregue un head allí:

for x in 'ps -ef | grep apache | head | awk '{print $2}''; do strace -s 2000 -p $x -o trace.$x & done

Pero ten en cuenta que esto hace que sea menos probable que captes lo que está sucediendo.

Asegúrese de tener dos sesiones SSH abiertas, ya que todas las tareas en segundo plano aún pueden escribir en su sesión. Cuando desee detener el stracing, reinicie Apache o ejecute esto en el otro:

 for x in 'ps -ef | grep strace | awk '{print $2}''; do kill $x; done

Mi primera impresión es que este es un módulo "estático" escrito en PHP que procesa previamente las imágenes (redimensionándolas, por ejemplo) antes de enviarlas al cliente y lo hace con include($image) . Si $image contiene una URL de imagen de su propio sitio en lugar de una ruta de archivo del sistema de archivos local, el resultado son solicitudes recursivas.

Podría estar usando las funciones curl() en lugar de include() .

Suena como un ataque típico de DOS. Probablemente esperan que el servidor responda a una solicitud de sí mismo y esperan obtener un bucle como el "ping de la muerte". También es una forma conveniente de evitar las reglas de firewall y causar dolores de cabeza en general. Bloquear la IP externa en el firewall es probablemente la mejor opción para que no puedan recibir las solicitudes en la puerta.

Suena como un ataque DDoS que está falsificando la IP del servidor. La mejor acción sería colocar un filtro de paquetes en el enrutador externo en lugar de usar reglas de firewall, ya que usar el enrutador reducirá la carga en el firewall. En un enrutador de Cisco, la solución simple sería escribir una lista de acceso con el origen como su bloque público y el destino como cualquiera, y luego aplicarlo a la interfaz externa como un "grupo de acceso IP en".

La limitación de velocidad ICMP también sería una buena idea, ya que pueden intentar hacer un ping que te inunde.

También debería pensar en limitar el tráfico válido, ya que el próximo ataque DDoS no falsificará sus propias IP, sino que utilizará direcciones IP válidas que no puede filtrar sin filtrar a sus clientes. Un límite de velocidad bien elegido evitará que su servidor se quede sin recursos.