Première chose :savoir d'où viennent ces demandes. Il doit s'agir d'un processus local, rien d'autre n'est susceptible de pouvoir usurper une poignée de main TCP sur une plate-forme Linux moderne (rien, c'est-à-dire, qui serait ensuite gaspillé un tel exploit de demander des images aléatoires).
S'il y a des URL récurrentes, vous pouvez les masquer derrière un RewriteRule afin que toute demande de ce type déclenche en fait un script . Dans le script, vous pouvez exécuter des vérifications supplémentaires pour voir si la requête est légitime (et vous afficherez alors les en-têtes appropriés comme s'il s'agissait de l'image attendue par le client légitime), ou s'il s'agit de l'une des fausses requêtes. Contre la fausse demande, vous pouvez vous connecter par ex. le port entrant. Armé de cela, vous pouvez interroger netstat et découvrez le processus. Vous pouvez également exécuter ps et inspectez tous les processus actifs au moment de la fausse requête.
Je suis à peu près sûr que le coupable s'avérera être Apache lui-même (j'ai eu une fois un script "d'amorçage du cache" devenu voyou sur moi en raison d'une modification de vhost - j'avais oublié de mettre le script dans crontab - et j'ai eu des symptômes vraiment étranges, un peu comme le vôtre, jusqu'à ce que tout me revienne ; mais votre cas semble différent).
Pour affiner davantage la scène tout en maîtrisant les coûts, vous pouvez ajouter un PID/TID au CustomLog d'Apache . Ensuite, vous pourrez recouper les requêtes reçues de l'enfant Apache devenu voyou.
Une autre possibilité est de déterminer exactement comment ces demandes sont faites. Si via Apache, cela signifie fopen_wrappers, cURL, fonctions de socket ou peut-être des utilitaires shell (ceux-ci doivent tous deux apparaître dans ps sortie et entraîner une surcharge de serveur beaucoup plus massive, cependant). Vous pouvez préparer une série de scripts qui :
- redémarrez Apache correctement sans aucun changement
- " " , désactivation temporairement l'une de ces fonctions
- " " , réactivation pareil
Après avoir vérifié (juste pour être sûr) qu'un redémarrage ne le fait pas résolvez le problème (si c'était le cas, ce serait une boîte de Pandore assez différente), vous pouvez procéder à la désactivation temporaire - quelques dizaines de secondes chacune, pas plus - une fonction après l'autre. Supposons que la désactivation de curl entraîne le retour immédiat du système à la normale :vous pouvez alors limiter les investigations aux scripts utilisant cURL, et peut-être même wrap la fonction cURL avec un wrapper de journalisation.
S'il s'avère que le coupable n'est pas Apache, vous serez toujours en mesure de déterminer quoi fait cela ; puis réinstallez le programme affecté (même si je trouve qu'il est peu probable qu'une anomalie aléatoire transforme un programme en un demandeur de répétition HTTP-GET) ou inspectez sa configuration, ses fichiers de données auxiliaires, ses scripts, etc., en regardant pour toute différence par rapport à une installation propre connue. Comme je ne crois généralement pas aux gremlins, je m'attends à ce qu'une différence ressorte à la fin.
Unix (et Linux) dispose d'une multitude d'outils pour analyser ce genre de choses. Mon premier arrêt serait de saisir la sortie de netstat -nap, par exemple. sur ma machine locale...
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
...
Ici, je peux voir que chrome (pid 32588) est connecté au port 80 / httpd (pid 5281). Puisqu'il s'agit d'une installation pré-fork d'Apache, je peux obtenir plus d'informations sur le processus httpd en enregistrant %P ou en regardant dans /proc/5281/fd (ce dernier nécessitera probablement un script pour récupérer les données au moment de la demande ).
Cela vous permettra d'identifier le processus client.
Les candidats les plus probables sont un proxy mal configuré ou un code bogué.
Si c'était mon serveur, j'exécuterais un strace sur Apache. L'exécuter sur chaque processus enfant en mode prefork peut être assez gourmand en disque, en particulier lorsque votre serveur est déjà surchargé. Vous devez également garder un œil sur votre espace disque, car s'il est épuisé, Apache cesse de traiter les requêtes.
Assurez-vous d'utiliser une longueur d'instantané suffisamment longue pour capturer l'intégralité de la requête :-s 400 devrait faire.
Si Apache fait des demandes à lui-même, toute chaîne GET apparaîtra dans les vidages strace pour deux PID différents :celui qui a fait la demande et celui qui l'a reçue. Dans celui qui a fait la demande, vous voulez trouver la demande qu'il a reçue et qu'il était en train de traiter lorsqu'il s'est fait la demande.
Je fais normalement quelque chose comme ça :
for x in `ps -ef | grep apache | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Si vous souhaitez vous limiter à un sous-ensemble d'enfants Apache pour des raisons de performances, ajoutez un head là-dedans :
for x in `ps -ef | grep apache | head | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Mais sachez que cela vous empêche de saisir ce qui se passe.
Assurez-vous que deux sessions SSH sont ouvertes car toutes ces tâches en arrière-plan peuvent toujours écrire dans votre session. Lorsque vous souhaitez arrêter le traçage, redémarrez Apache ou exécutez ceci dans l'autre :
for x in `ps -ef | grep strace | awk '{print $2}'`; do kill $x; done
Mon instinct sur celui-ci est un module "statique" écrit en PHP qui pré-traite les images (les redimensionnant par exemple) avant de les envoyer au client et il le fait avec include($image) . Si $image contient une URL d'image de votre propre site plutôt qu'un chemin de fichier du système de fichiers local, les requêtes récursives en sont le résultat.
Il pourrait utiliser le curl() fonctions plutôt que include() .