Internetseite, 404-er Zugriffe, erst Chrome, jetzt auch Firefox 35.0

Hi,

404-er Zugriffe entstehen, wenn ungültige Zieladressen einer Seite aufgerufen werden, z.B. www.gibtesnichthier.de/dasauchnicht.php

Es ist möglich, dass z.B. Suchmaschinen veraltete Link listen, um die geht es hier nicht, alle Aufrufe scheinen interne Links zu sein.

Auf einer Internetseite mit Mitgliederbereich haben wir vor einigen Monaten festgestellt, dass auf einmal ein hoher Serverlast durch 404-Zugriffe entstanden ist.

Wir erfassen diese Zugriffe und versuchen die mit Hilfe eines Counters auch zu vermeiden. Anhand der Protokolle haben wir dann festgestellt, dass die meisten Fehlaufrufe durch den Chrome-Browser verursacht wurden..
Auf unsere Empfehlung verzichteten die User dann auf Chrome und sind auf Firefox umgestiegen ... siehe da, es funktionierte alles wunderbar.

Jau, seit eine Woche ist das Theater wieder losgegangen, diesmal scheint Firefox 35.0 Fehlzugriffe zu erzeugen.
Die Firefox-Version 35.0 ist nicht so alt, wird erst seit 2-3 Wochen angeboten.

Das Problem zeigt sich wie folgt:
Der User ist im Mitgliederbereich, klickt die internen Links an, die werden auch richtig angezeigt und nebenbei werden diese Fehlzugriffe erzeugt.
Diese Fehlaufrufe scheinen im Hintergrund zu sein, unsere 404-er Fehlerseite wird dem Besucher NICHT angezeigt, der sieht wie immer nur die aufgerufene Ziel-Adresse bei uns ... wir Admins sehen letztendlich diese zusätzlichen Zugriffe nur in den Logs und die sind schon 400-600 pro Stunde.

Etwa:
ein Klick auf dem Link und es werden 2 Links verfolgt: 1. gültige und eine 2.

Unsere Logs führen seit einigen Tagen den Browser Firefox 35.0 als Übeltäter auf und anscheinend je mehr User updaten um so mehr werden diese Zugriffe ;-(

Wir können die Zugriffe in Realzeit dokumentieren und den Zugriff für die Verursacher-IP-Adresse sperren, aber aktuell wären dann etwa 30%-40% der User gesperrt, also haben wir vorläufig die Sperrfunktion deaktiviert.

Welcher Admin hat schon vergleichbare Erfahrungen gemacht?
Habt ihr einen Idee, was machen die Browser Chrome und die neue Firefox 35.0 im Hintergrund?
Versuchen die evtl. alte Lesezeichen aktuell zu halten?
... und wie kriegt man das Problem wieder los?

Danke Euch!

Vielleicht ist das eine Art von DDoS-Attacke. Am besten Allmy stellt die 404-Fehlermeldungs-Seite mal ganz ab?

keine ahnung...wuerde aber lesezeichen ausschliessen

was ich anbieten könnte wäre diesen thread mit vers. browsers zuzumuellen.

eine dos attacke wuerde anders ausschauen

anbei einige zeilen aus dem server-log:

xxx.xx.xx.xxx als Anonymisierung der IP

xxx.xx.xx.xxx - - [21/Jan/2015:10:41:56 +0100] "GET /404.php HTTP/1.1" 200 165 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0"

xxx.xx.xx.xxx - - [21/Jan/2015:11:19:44 +0100] "GET /404.php HTTP/1.1" 200 165 "-" "Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101 Firefox/35.0"

xxx.xx.xx.xxx - - [21/Jan/2015:12:21:31 +0100] "GET /404.php HTTP/1.1" 200 165 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0"

@Tilt001
DDoS verhält sich anders - da bekommen wir auch die Parameter
ebenso veraltetete Suchmaschinen-Links - die finden wir recht schnell

hier sin die Protokoll-Zeilen nichtssagend - kein Paramtere dabei, keine Quelle, aber seit einigen Tagen diese Firefox-Version immer dabei ...
... die IPs sind immer unterschiedlich, es sind auch andere User

interessant auch:
die Sperre besteht für den User für eine Stunde, wenn der nach eine Stunde Wartezeit wieder online ist, ist es durchaus möglich, dass der ohne Probleme für einige Stunden im MItgliederbereich ist ... und dann geht es wieder von vorne los mit den 404-er Zugriffen

@drachenflieger

Vielleicht sind es nur die Werbeblocker in Chrome und Firefox? Die arbeiten ja mit Listen und wenn sie erkennen da ist eine Seite mit Allmystery.de/Banner/*.* dann brechen sie den angefangenen Ladevorgang aber ab, damit der Banner eben nicht erscheint.

Der Allmyserver registriert den Teilaufruf dann allerdings noch als falschen 404-Link!

@Tilt001
mit dem Allmy-Server hat mein Anliegen nichts zu tun

mit ads-protokollen komme ich klar, da sind u.U. auch Zeiten (Aufenthaltsdauer, Reload) zu beachten

mein Anliegen ist in der Realität so:
User x klickt internen Link A auf der Seite - geht klar
User x klickt internen Link B auf der Seite - geht klar
User x klickt internen Link C auf der Seite - geht klar

jau, dann
User x klickt internen Link D auf der Seite - geht NICHT klar, landet auf 404

nächster User y klickt Link D auf der Seite - geht klar

kommt user x wieder:
User x klickt Link D auf der Seite - geht klar

Die Links sind permanent online, da ändern wir nichts.

Evtl. irre ich mich, aber ist es laut dem log nicht so dass der Client die Resource namens '404.php' anfordert und der Server diese einwandfrei mit dem Statuscode 200 (OK) ausliefert?

Wikipedia: List of HTTP status codes#2xx Success

@Zerp
ich glaube dein Ansatz ist richtungsweisend

die logzeile sieht ja so aus:

xxx.xx.xx.xxx - - [21/Jan/2015:10:41:56 +0100] "GET /404.php HTTP/1.1" 200 165 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0"

200 ist drin (Auslieferung wird Verarbeitet) und scheittert weil Code 165 geliefert wurde?

Darüber habe ich noch nie nachgedacht und ich weiss es nicht:
Was bedeuten die zwei Zahlen 200 165 in der Log-Zeile?

grad mit dem provider geklärt

200 165 in der Log-Zeile bedeutet :

200 Anfrage erfolgreich erledigt (laut Provider, bei 404-er Seite bezieht sich das auf die Seite woher die Weiterleitung an 404-er erfolgte ... warum erfolgt dann eine Weiterleitung?)

165 ist die Traffic-Grösse der Anfrage, deshalb auch immer 165 (in der Datei 404.php ist ja auch nichts aufregendes)

@drachenflieger

drachenflieger schrieb:die logzeile sieht ja so aus:

xxx.xx.xx.xxx - - [21/Jan/2015:10:41:56 +0100] "GET /404.php HTTP/1.1" 200 165 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0"

Das ist nicht dein Ernst, oder?? Dieser Auszug ist das Serverlog, also das, was der Server antwortet (200 - ok). Wenn du wissen willst, was da schief läuft, und du schon den Client im Verdacht hast, solltest du mal einen Auszug vom Client posten, die komplette HTTP-Anfrage, den gesamten Header, incl. Referrer und Cookies. Aber wenn ich sowas da oben sehe, bin ich echt geschockt...

Schau doch mal anhand des logs anhand einer spezifischen IP und Zeit welcher Aufruf der Umleitung auf die '404.php' vorrausgeht.

Wenn es so viele Benutzer betrifft is es vielleicht eine im HTML-Dokument falsch referenzierte Ressource (javascript, css, image)?

@KillingTime
ja, das ist eine Zeile aus dem Server-Log
ja, ich habe den Client im Verdacht, genauer den Browser Firefox Version 35.0, seit dem die User die Version haben scheint das Problem zu bestehen
ich selbts nutze Iceweasel (Debian) - damit funktioniert alles richtig

wir kennen seit Moanten das Problem mit Chrome, da gab es die gleiche Geschichte, nach dem wir die User informiert haben, dass für unsere Seite kein Chrome benutzt werden sollte, kehrte Ruhe ein und war alles o.k.

@Zerp
ich habe heute Nacht die Logs der letzten Tage angeschaut und auch ausgewertet, klar nach IP sortiert, nach Zeit sortiert ... nichts davor, keine Besonderheiten, auch keine Fehlerhafte Zugriffe davor von den IPs
was zwichendurch sporadisch aufgeführt ist, dass mal die Fav-Icon-Datei "permanent umgezogen" ist (Code 301), das dürfte aber nicht die Ursache dafür sein - die Seiten wurden ja auch richtig ausgegeben und sind mit Code 200 vermerkt

natürlich, wie du auch geschrieben hast:
404-er Zugriff im Log suchen, Zugriffe davor prüfen und es sollte eine Zeile z.B. mit 4xx vermerkt sein, dann weiss man auch welche Datei davon betroffen ist

wie schon geschrieben, die User sehen nichtmal die 404.php Seite, bei denen scheint alles richtig zu laufen ... deshalb habe ich auch die Vermutung, dass dieses Verhalten mit irgendwas zusammenhängt, was Firefox und Chrome für sich selbst zwichendurch updatet, wie Lesezeichen oder Check auf Aktuallität von gespeicherten Links - deshalb auch kein Referrer, weil ein direkter Aufruf vom Cleint erfolgt ist

die Log-Einträge, wenn z.B, Suchmaschinen veraltete Links listen und dann Zugriffe erfolgen, die kenne ich, damit kann ich auch umgehen und die Seiten auch ändern - da sind ja Log-Zeilen nach IP und Zeit nachvollziehbar und man sieht es auch welche Seite tatsächlich aufgerufen wurde (URL-Referrer) und auch welche Suchmaschine den Zugriff generierte

Wir führen auch eigene Logs in Echtzeit und speichern die Zugriffe für 24 Std., inkl. Referrer, IP, Zeit, ... dort sieht die Zeile vergleichbar aus - keine Information was tatsächlich helfen könnte

Unser eigene Protokoll führt die Zugriffe so auf wie unten (zeitlich von unten nach oben, selbe IP), um 23.01.2015 15:27:06 noch alles o.k. und dann geht es in Sekundentakt mit den 404-er Zugriffen los - wenn der User selbst wieder einen internen Link aufruft, dann wird der Zugriff richtig und ohne Probleme durchgeführt und wird auch vollständig protokolliert im Server-Log UND auch in unseren eigenem Log (vollständig identisch), dass zwischendurch diese Pings an 404.php erfolgen, das kriegt der User einfach nicht mit

(user selbst aktiv, alles o.k.)
23.01.2015 15:33:35 xx.xx.xx.xx Seite: /file3.php
Parameter: sessionid=abc123456789
Quelle: www.xxxxx.de/members/file2.php?sessionid=abc123456789

(user selbst inaktiv)
23.01.2015 15:33:19 xx.xx.xx.xx Seite: /404.php
Parameter:
Quelle:

(user selbst inaktiv)
23.01.2015 15:30:09 xx.xx.xx.xx Seite: /404.php
Parameter:
Quelle:

(user selbst inaktiv)
23.01.2015 15:27:33 xx.xx.xx.xx Seite: /404.php
Parameter:
Quelle:

(user selbst aktiv, alles o.k.)
23.01.2015 15:27:06 xx.xx.xx.xx Seite: /file2.php
Parameter: sessionid=abc123456789
Quelle: www.xxxxx.de/members/file1.php?sessionid=abc123456789

Meine Co-Admine hat diese Woche ein Firefox-Update auf 35.0 automatisch erhalten, seitdem hat sogar sie das gleiche Problem, einfach so über Nacht.

Während der letzten 24 Stunden waren:
17.037 Seitenzugriffe
1.631 davon waren 404-er ... und das ist schon eine ganze Menge ;-(

Vielleicht ist das auch die Politik irgendeines Geheimdienstes, alle Foren die als leicht subversiv gegenüber der eigenen Regierung eingestuft werden, unauffällig durch ein uns noch unbekanntes Exploit im Browser mit sinnlosen Serveraufrufen zu belasten? Das sind ja schließlich auch Kosten, auf Dauer könnten die damit Erfolg haben?

Die haben vielleicht die Hintertür im Chrome und Firefox Browser auch extra dafür eingebaut. Jemand sollte mal bei Mozilla anrufen! :|

@Tilt001
jau ;-)

als Idee kam mir jetzt grad dies:
wäre es möglich, dass nach Update der Browser die tmp-files (Verlauf) auf Gültigkeit überprüft, z.B. Grafik-Files, damit die nicht immer neu geladen werden und wenn es erledigt ist, dann ist es wieder Ruhe im Kasten?

@drachenflieger

Dann müsste sich das Problem ja bald von selbst erledigen.

Wenn nicht sollte Allmy mal was anderes machen, nämlich die 404 Seite auch umgestalten, so das sie in jedem Fall voll von jedem User aufgerufen wird! Am besten noch mit was großem drin, irgendein symbolisches 404 Riesen-Hintergrundbild vom Hubble-Telescop von der NGC 404 Galaxie oder so!

Wenn die User den Fehler den sie produzieren nämlich auch mal selber sehen, dann werden sich viele bestimmt auch mal darüber bei Mozilla darüber beschweren, einfach über die Minutenlangen vollkommen sinnlosen Ladezeiten hier!

@Tilt001

Tilt001 schrieb:Dann müsste sich das Problem ja bald von selbst erledigen.

Yepp, ich werde mal das beobachten, das kann ma ja nach User auswerten und der Zugriff sollte nachlassen und wenn der Verlauf komplett aufgeräumt und gelöscht wird, dann dürfte sogar ausgepingt haben.

Ist an sich komisch, die Parsetime sieht noch recht gut aus:
während der letzten 24 Stunden:
Durchschnittliche Ladezeit: 0.563037 Sekunde pro Seite
Datenbank-Zugriffe, gesamt: 209.497 Zugriffe

es muss was ganz banales sein ... apropo bana..., ich sollte jetzt einkaufen ;-)

Das ist die 404 Seite der Mozilla Fondation:
https://www.mozilla.org/en-US/404 (Archiv-Version vom 03.06.2015)

am besten man macht erst mal in die Allmy.de/404.php eine ganz normale Umleitung dahin, dann haben die schon mal den Traffic die ihn auch verursachen!

drachenflieger schrieb:Versuchen die evtl. alte Lesezeichen aktuell zu halten?

Das ist gar nicht so eine schlechte Idee, denn ich hatte auch mal was ähnliches. Ich hatte auch mal ein Lesezeichen, bei dem sich der Link zu der Webseite geändert hat. Als ich drauf gegangen bin, bekam ich eine Fehlermeldung, dass die Seite nicht gefunden wurde. Da ich das Lesezeichen aber wieder aktualisiert habe kommt diese Fehlermeldung nicht mehr.

@Yotokonyx
Danke für den Hinweis.

@Tilt001
Danke dir auch, ich selbst wäre nie auf die Idee gekommen nachzuschauen, wie andere Seiten ihre 404-er Umleitung gestalten.

Ich habe die 404.php abgeändert, wenn kein Referer übermittelt wird, dann erfolgt eine sofortige Scriptausstieg und wenn der Zugriff von Firefox 35.0 erfolgte, dann erfolgt auch eine Weiterleitung (redirect in 404.php) zu der seite

https://www.mozilla.org/en-US/without_referer_its_your_own_shit

... somit wird auf die Fehlerseite 404.php von Mozilla-Firefox zugegriffen.

Der User hat ja von diesen Zugriffen nie was gemerkt, dem wird diese Fehler-Seite auch nie angezeigt.