Lo primero:averiguar de dónde vienen estas solicitudes. Tiene que ser un proceso local, es probable que nada más pueda falsificar un protocolo de enlace TCP en una plataforma Linux moderna (nada, es decir, que luego procedería a desperdiciar tal hazaña al solicitar imágenes aleatorias).
Si hay URL recurrentes, puede ocultarlas detrás de un RewriteRule para que cualquier solicitud de este tipo active 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, p. el puerto de entrada. Armado con eso, puede consultar netstat y conoce el proceso. También puede ejecutar ps e inspeccionar todos los procesos activos en el instante de la solicitud falsa.
Estoy bastante seguro de que el culpable resultará ser el propio Apache (una vez tuve un script de "cebado de caché" que se volvió deshonesto debido a una modificación de vhost; había olvidado poner el script en crontab, y obtuve síntomas realmente extraños, algo así como tuyo, hasta que todo volvió a mí; pero tu caso se siente diferente).
Para refinar aún más la escena y contener los costos, puede agregar PID/TID al CustomLog de Apache. . Entonces podrá cotejar las solicitudes recibidas del hijo de Apache que se volvió deshonesto.
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 tal vez utilidades de shell (ambos deberían aparecer en ps Sin embargo, el resultado es una sobrecarga de servidor mucho más masiva). Puede preparar una serie de guiones que:
- reiniciar Apache correctamente sin ningún cambio
- " " , deshabilitar temporalmente una de esas funciones
- " " , rehabilitación mismo
Después de verificar (solo para estar seguro) que un reinicio no solucione el problema (si lo hiciera, sería una lata de gusanos bastante diferente), puede proceder a deshabilitar temporalmente, un par de docenas de segundos cada uno, no más, una función tras otra. Supongamos que deshabilitar curl da como resultado que el sistema regrese inmediatamente a la normalidad:entonces podría restringir las investigaciones a los scripts que usan cURL, y tal vez incluso wrap la función cURL con un contenedor de registro.
En caso de que el culpable resulte no ser Apache, aún podrá determinar qué está haciendo esto; luego, reinstale el programa afectado (incluso si me parece poco probable que una anomalía aleatoria convierta un programa en un repetidor HTTP-GET-requestor) o inspeccione su configuración, archivos de datos auxiliares, scripts, etc., 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, p. 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 iniciando sesión en %P o buscando en /proc/5281/fd (este último probablemente requerirá secuencias de comandos para obtener 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 cada proceso secundario en modo prefork puede consumir bastante disco, especialmente cuando su servidor ya está sobrecargado. También debe vigilar su espacio en disco, porque si se agota, Apache deja de atender las solicitudes.
Asegúrate de usar una longitud de instantánea lo suficientemente larga para capturar la solicitud completa:-s 400 debe hacer.
Si Apache realiza solicitudes a sí mismo, cualquier cadena GET aparecerá en los volcados de seguimiento para dos PID diferentes:uno que realizó la solicitud y otro 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 razones de rendimiento, agregue un head ahí:
for x in `ps -ef | grep apache | head | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Pero tenga en cuenta que esto hace que sea menos probable que capture lo que está sucediendo.
Asegúrese de tener dos sesiones SSH abiertas, ya que todas esas tareas en segundo plano aún pueden escribir en su sesión. Cuando desee dejar de rastrear, reinicie Apache o ejecute esto en el otro:
for x in `ps -ef | grep strace | awk '{print $2}'`; do kill $x; done
Mi intuición en este caso es un módulo "estático" escrito en PHP que preprocesa las imágenes (cambiándolas de tamaño, 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 el curl() funciones en lugar de include() .