Als erstes:Finden Sie heraus, woher diese Anfragen kommen. Es muss ein lokaler Prozess sein, nichts anderes ist wahrscheinlich in der Lage, einen TCP-Handshake auf einer modernen Linux-Plattform zu fälschen (also nichts, was dann verschwendet würde eine solche Leistung beim Anfordern zufälliger Bilder).
Wenn es wiederkehrende URLs gibt, können Sie diese hinter einem RewriteRule schattieren damit jede solche Anfrage tatsächlich ein Skript auslöst . Im Skript können Sie zusätzliche Überprüfungen durchführen, um festzustellen, ob die Anfrage legitim ist (und Sie geben dann die richtigen Header aus, als ob es das Bild wäre, das der legitime Client erwartet) oder ob es sich um eine der gefälschten Anfragen handelt. Gegen die Scheinanfrage kann man sich z.B. der eingehende Port. Damit bewaffnet, können Sie netstat abfragen und erfahre den Ablauf. Sie können auch ps ausführen und inspizieren Sie alle aktiven Prozesse im Moment der gefälschten Anfrage.
Ich bin mir ziemlich sicher, dass der Schuldige Apache selbst sein wird (ich hatte einmal ein "Cache-Priming" -Skript, das wegen einer vhost-Modifikation auf mich losging - ich hatte vergessen, das Skript in crontab zu setzen - und bekam wirklich seltsame Symptome, so etwas wie dein Fall, bis mir alles wieder eingefallen ist; aber dein Fall fühlt sich anders an).
Um die Szene weiter zu verfeinern und gleichzeitig die Kosten einzudämmen, können Sie PID/TID zu Apaches CustomLog hinzufügen . Dann werden Sie in der Lage sein, die Anfragen zu überprüfen, die von dem abtrünnigen Apache-Kind empfangen wurden.
Eine andere Möglichkeit besteht darin, genau wie zu bestimmen diese Anträge werden gestellt. Wenn durch Apache, bedeutet dies fopen_wrappers, cURL, Socket-Funktionen oder vielleicht Shell-Dienstprogramme (diese sollten beide in ps erscheinen Ausgabe und führen jedoch zu einer viel massiveren Serverüberlastung). Sie können eine Reihe von Skripten vorbereiten, die:
- Apache neu starten ohne Änderungen
- " " , deaktivieren vorübergehend eine dieser Funktionen
- " " , erneut aktivieren gleich
Nachdem Sie überprüft haben (nur um sicherzugehen), dass ein Neustart nicht erfolgt Um das Problem zu beheben (wenn ja, wäre es eine ganz andere Dose Würmer), können Sie damit fortfahren, eine Funktion nach der anderen vorübergehend zu deaktivieren - jeweils ein paar Dutzend Sekunden, nicht mehr. Angenommen, das Deaktivieren von curl führt dazu, dass das System sofort wieder normal wird:Dann könnten Sie Untersuchungen auf Skripte mit cURL beschränken und vielleicht sogar wrap die cURL-Funktion mit einem Logging-Wrapper.
Falls sich herausstellt, dass der Schuldige nicht Apache ist, können Sie immer noch feststellen, was tut dies; Installieren Sie dann entweder das betroffene Programm neu (auch wenn ich es für unwahrscheinlich halte, dass eine zufällige Anomalie ein Programm in einen Repeat-HTTP-GET-Requestor verwandelt) oder überprüfen Sie seine Konfiguration, Hilfsdatendateien, Skripte usw für jeden Unterschied zu einer bekannten sauberen Installation. Da ich normalerweise nicht an Gremlins glaube, erwarte ich, dass am Ende ein Unterschied auffällt.
Unix (und Linux) verfügt über eine Fülle von Tools zum Analysieren solcher Dinge. Meine erste Station wäre, die Ausgabe von netstat -nap zu holen, z. auf meinem lokalen Rechner...
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
...
Hier kann ich sehen, dass Chrome (PID 32588) mit Port 80 / httpd (PID 5281) verbunden ist. Da dies eine Pre-Fork-Installation von Apache ist, kann ich mehr Informationen über den httpd-Prozess erhalten, indem ich %P protokolliere oder in /proc/5281/fd nachschaue (letzteres erfordert wahrscheinlich Skripting, um die Daten zum Zeitpunkt der Anfrage zu erfassen ).
Dadurch können Sie den Client-Prozess identifizieren.
Die wahrscheinlichsten Kandidaten sind ein schlecht konfigurierter Proxy oder fehlerhafter Code.
Wenn dies mein Server wäre, würde ich einen strace ausführen auf Apache. Wenn Sie dies auf jedem untergeordneten Prozess im Prefork-Modus ausführen, kann dies ziemlich plattenintensiv sein, insbesondere wenn Ihr Server bereits überlastet ist. Sie müssen auch Ihren Speicherplatz im Auge behalten, denn wenn er knapp wird, stellt Apache die Bearbeitung von Anfragen ein.
Stellen Sie sicher, dass Sie eine Snap-Länge verwenden, die lang genug ist, um die gesamte Anfrage zu erfassen:-s 400 sollte.
Wenn Apache Anfragen an sich selbst stellt, erscheint jeder GET-String in den Strace-Dumps für zwei verschiedene PIDs:eine, die die Anfrage gestellt hat, und eine, die sie erhalten hat. In demjenigen, der die Anfrage gestellt hat, möchten Sie die Anfrage finden, die er empfangen und verarbeitet hat, als er die Anfrage an sich selbst gestellt hat.
Normalerweise mache ich so etwas:
for x in `ps -ef | grep apache | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Wenn Sie sich aus Leistungsgründen auf eine Teilmenge von Apache-Kindern beschränken möchten, fügen Sie eine head hinzu dort drin:
for x in `ps -ef | grep apache | head | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done
Beachten Sie jedoch, dass dies die Wahrscheinlichkeit verringert, dass Sie erfassen, was passiert.
Stellen Sie sicher, dass Sie zwei SSH-Sitzungen geöffnet haben, da all diese Hintergrundaufgaben weiterhin in Ihre Sitzung schreiben können. Wenn Sie das Stracing beenden möchten, starten Sie entweder Apache neu oder führen Sie dies in dem anderen aus:
for x in `ps -ef | grep strace | awk '{print $2}'`; do kill $x; done
Mein Bauchgefühl bei diesem ist ein "statisches" Modul, das in PHP geschrieben ist und Bilder vorverarbeitet (z. B. in der Größe ändert), bevor es sie an den Client sendet, und das mit include($image) . Wenn $image zufällig eine Bild-URL von Ihrer eigenen Seite statt eines Dateipfads aus dem lokalen Dateisystem enthält, sind rekursive Anfragen die Folge.
Es könnte den curl() verwenden funktioniert statt include() .