Prima cosa:scopri da dove provengono queste richieste. Deve essere un processo locale, è probabile che nient'altro sia in grado di falsificare un handshake TCP su una moderna piattaforma Linux (niente, cioè, che andrebbe poi a sprecare una tale impresa nel richiedere immagini casuali).
Se ci sono URL ricorrenti, puoi nasconderli dietro un RewriteRule in modo che qualsiasi richiesta di questo tipo attiverà effettivamente uno script . Nello script puoi eseguire ulteriori controlli per vedere se la richiesta è legittima (e quindi produrrai le intestazioni corrette proprio come se fosse l'immagine che il client legittimo si aspetta) o se si tratta di una delle richieste fasulle. Contro la richiesta fasulla puoi accedere ad es. il porto di arrivo. Armato di questo, puoi interrogare netstat e scopri il processo. Puoi anche eseguire ps e ispezionare tutti i processi attivi nell'istante della richiesta fasulla.
Sono abbastanza sicuro che il colpevole si rivelerà essere Apache stesso (una volta ho avuto uno script di "cache priming" che mi ha fatto impazzire a causa di una modifica del vhost - avevo dimenticato di mettere lo script in crontab - e ho avuto sintomi davvero strani, un po 'come tuo, finché non mi è tornato tutto in mente; ma il tuo caso sembra diverso).
Per perfezionare ulteriormente la scena contenendo i costi, puoi aggiungere PID/TID al CustomLog di Apache . Quindi sarai in grado di effettuare un controllo incrociato delle richieste ricevute dal bambino Apache diventato rogue.
Un'altra possibilità è determinare esattamente come queste richieste vengono fatte. Se tramite Apache, ciò significa fopen_wrappers, cURL, funzioni socket o forse utilità della shell (dovrebbero apparire entrambe in ps output e si tradurrà in un sovraccarico del server molto più massiccio, però). Puoi preparare una serie di script che:
- riavvia correttamente Apache senza alcuna modifica
- " " , disabilitazione temporaneamente una di queste funzioni
- " " , riattivazione stesso
Dopo aver verificato (giusto per essere sicuri) che un riavvio non risolto il problema (se lo facesse, sarebbe un barattolo di worm completamente diverso), puoi procedere a disabilitare temporaneamente - un paio di dozzine di secondi ciascuno, non di più - una funzione dopo l'altra. Supponiamo che la disabilitazione di curl riporti il ritorno immediato del sistema alla normalità:allora potresti restringere le indagini agli script usando cURL, e forse anche wrap la funzione cURL con un wrapper di registrazione.
Nel caso in cui il colpevole risulti non essere Apache, sarai comunque in grado di determinare cosa sta facendo questo; quindi reinstallare il programma interessato (anche se trovo improbabile che qualsiasi anomalia casuale trasformi un programma in un richiedente HTTP-GET ripetuto) o ispezionarne la configurazione, i file di dati ausiliari, gli script e così via e così via, cercando per qualsiasi differenza rispetto a un'installazione pulita nota. Dato che di solito non credo nei gremlin, mi aspetto che alla fine emerga qualche differenza.
Unix (e Linux) ha una vasta gamma di strumenti per analizzare cose come questa. La mia prima tappa sarebbe prendere l'output di netstat -nap, ad es. sulla mia macchina 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
...
Qui posso vedere che Chrome (pid 32588) è connesso alla porta 80 / httpd (pid 5281). Poiché si tratta di un'installazione pre-fork di apache, posso ottenere maggiori informazioni sul processo httpd registrando %P o cercando in /proc/5281/fd (quest'ultimo richiederà probabilmente uno script per acquisire i dati al momento della richiesta ).
Questo ti permetterà di identificare il processo client.
I candidati più probabili sono un proxy mal configurato o un codice difettoso.
Se questo fosse il mio server, eseguirei un strace su Apache. L'esecuzione di questo su ogni processo figlio in modalità prefork può richiedere un uso piuttosto intensivo del disco, specialmente quando il server è già sovraccarico. Devi tenere d'occhio anche lo spazio su disco, perché se si esaurisce, Apache smette di servire le richieste.
Assicurati di utilizzare uno snaplength sufficientemente lungo da catturare l'intera richiesta:-s 400 dovrebbe andare bene.
Se Apache sta effettuando richieste a se stesso, qualsiasi stringa GET apparirà nei dump strace per due diversi PID:uno che ha effettuato la richiesta e uno che l'ha ricevuta. In quello che ha effettuato la richiesta, vuoi trovare la richiesta che ha ricevuto e che stava elaborando quando ha effettuato la richiesta a se stesso.
Normalmente faccio qualcosa del genere:
for x in `ps -ef | grep apache | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Se vuoi limitarti a un sottoinsieme di figli di Apache per motivi di prestazioni, aggiungi un head lì dentro:
for x in `ps -ef | grep apache | head | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Ma tieni presente che questo rende meno probabile che tu catturi ciò che sta accadendo.
Assicurati di avere due sessioni SSH aperte poiché tutte quelle attività in background possono ancora scrivere sulla tua sessione. Quando vuoi interrompere lo stracing, riavvia Apache o esegui questo nell'altro:
for x in `ps -ef | grep strace | awk '{print $2}'`; do kill $x; done
Il mio istinto su questo è un modulo "statico" scritto in PHP che pre-elabora le immagini (ridimensionandole per esempio) prima di inviarle al client e lo fa con include($image) . Se $image capita di contenere un URL immagine dal tuo sito piuttosto che un percorso file dal filesystem locale, il risultato sono richieste ricorsive.
Potrebbe usare il curl() funzioni anziché include() .