eigenartige URL im Access Log und in der Google Indizierung

Gnislew

Hallo zusammen,

mir ist heute beim durschauen meiner Access Log aufgefallen dass ich GET Anfragen bekommen die auch mit Code 200 zurückkommen auf Seiten, die es mMn gar nicht geben dürfte.

Beispielsweise: 218.28.15.130 - - [23/Jun/2015:13:39:45 +0200] "GET /?url=http://www.docin.com/p-994425148.html HTTP/1.1" 200 62247 "-" "Mozilla/4.0" "http://www.sneakfilm.de"

Ich sehe bei den Google Webmaster Tools auch, dass URLs mit http://www.sneakfilm.de/?url=XXX indiziert sind.

Meine Frage: Liegt hier eine Fehlkonfiguration in meinem Wordpress vor, die dies zulässt oder muss ich den Fehler woanders suchen?

Danke für Eure Hilfe
Gnislew

Werbepost

Hallo!

Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
✔️ Deutsche Server & DSGVO-konform
✔️ Persönlicher Support (kein 0815-Ticket-System)

Mehr erfahren

Putzlowitsch

Wordpress akzeptiert von Hause aus erstmal alle URL-Parameter, da wird nichts geprüft.

Möglicherweise versucht jemand eine URL-Weiterleitung zu nutzen, die es auf Deiner Website aber nicht gibt.

Idealerweise wird für ungültige Parameter eine Fehlerseite und der Statuscode 404 von Wordpress zurückgegeben. Ansonsten wird auch Google diese URLs als gültig ansehen und in den Index aufnehmen.

Gruß
Ingo

Gnislew

Danke schonmal.

Sprich ich muss die .htaccess anpassen? Wenn ja, kannst Du mir verraten wie? Es sollen auch weiterhin meine Permalinks geschrieben werden können.

Danke
Gnislew

Putzlowitsch

Mit der .htaccess ist das eher schwierig zu bewerkstelligen.
Es gibt dafür aber ein kleines Plugin, welches die URL-Parameter auf Vorhandensein in Wordpress prüft und ggf. den Fehlerstatus 404 setzt:
https://goo.gl/uK6Qcs

Gruß
Ingo

formateins

1. Das ist allgemeiner SEO-Spam, der leider als "üblich" anzusehen ist.
2. Lässt sich über die .htaccess über eine Umgebungsvariable regeln - dann werden die Referer direkt geblockt:

Code

# BEGIN Referrer Spam Stop
SetEnvIfNoCase referer sneakfilm\.de bad_bot=1


<FilesMatch "(.*)">
Order Allow,Deny
Allow from all
Deny from env=bad_bot
</FilesMatch>




# END Referrer Spam Stop

Alles anzeigen

Lässt sich beliebig erweitern/ergänzen. Manchmal (eher selten) ist der Referer selbst von einer Malware betroffen und weiß noch nix davon.

Gnislew

Zitat von formateins
1. Das ist allgemeiner SEO-Spam, der leider als "üblich" anzusehen ist.
2. Lässt sich über die .htaccess über eine Umgebungsvariable regeln - dann werden die Referer direkt geblockt:
Code
# BEGIN Referrer Spam Stop
SetEnvIfNoCase referer sneakfilm\.de bad_bot=1


<FilesMatch "(.*)">
Order Allow,Deny
Allow from all
Deny from env=bad_bot
</FilesMatch>




# END Referrer Spam Stop
Alles anzeigen
Lässt sich beliebig erweitern/ergänzen. Manchmal (eher selten) ist der Referer selbst von einer Malware betroffen und weiß noch nix davon.

Ich habe die .htaccess mal angepasst und gleich wieder rückgängig gemacht. Trotzdem danke schön schonmal. Du blockst ja so meine eigene URL. :-(

r23

Zitat von Gnislew

Du blockst ja so meine eigene URL. :-(

nö macht er nicht , wenn du eine alten apache <2.3 verwendest. ab apache 2.4 musst du den code selbstverständlich anpassen. Wie steht im Apache Handbuch

Putzlowitsch

Zitat von r23

nö macht er nicht ...

Doch, das macht er, sneakfilm.de ist seine eigene Domain.

Das sieht mir auch nicht nach Referrer-Spam aus, denn da werden üblicherweise existierende URLs verwendet und als Referrer die Spam-Adresse angegeben. Hier wird aber als Referrer die eigene Adresse verwendet.

Gruß
Ingo

formateins

a) Hirn aus und copy/paste ist nie gut. ;)
b) Mit den Umgebungsvariablen kann man noch viel mehr machen.
c) http://www.askapache.com/htaccess/setenvif.html

Reduzieren wir das auf einen obligatorischen Bot, der Webseiten pushen will. Spam, Scam, einerlei. Im Fachjargon wird das als Referer-Spoofing bezeichnet.

Gibt auch Erweiterungen für die Browser, damit man was zum rumspielen hat: https://chrome.google.com/webstore/detai…bojoidoihckciin (Chrome)

Das Überprüfen auf ein URL-Segment, welches bei WP eh nicht vorkommt, kann auf verschiedene Weisen realisiert werden. Ich würd's serverseitig lösen, dann gibt's erst garnix zu guggn und/oder Du kannst einen 405 zurück werfen.

Putzlowitsch

Zitat von formateins

...
Reduzieren wir das auf einen obligatorischen Bot, der Webseiten pushen will. Spam, Scam, einerlei. Im Fachjargon wird das als Referer-Spoofing bezeichnet.
...

Nenne es, wie Du willst, nur kommt man da mit der Auswertung des Referrers nicht wirklich weiter, wenn als Referrer die eigene Domain/Webseite eingetragen ist.
Auch die Aufnahme einer solchen URL in den Google-Index kann man so nicht verhindern, da der Google-Bot nicht mit dem gefälschten Refferer zugreifen wird.

Zitat von formateins

...
Ich würd's serverseitig lösen, dann gibt's erst garnix zu guggn und/oder Du kannst einen 405 zurück werfen.
...

Ein Statuscode 405 ist an der Stelle einfach falsch, denn die Request-Methode GET ist ja durchaus richtig. Was sollten den die richtige Methode sein, POST oder HEAD?

Man könnte eventuell als alternative zum 404 einen 403 zurückgeben, ein etwas stärkeres Signal. Der wirkt auch bei Google etwas schneller. :-)

Gruß
Ingo

Gnislew

Oh ha,

scheint also gar nicht so trivial zu sein dieses Problem zu lösen. Habe auch schon gegoogelt und leider noch nichts dazu gefunden, deshalb bin ich ja bei Euch gelandet. Habe auch noch eine Support-Anfrage bei Host Europe laufen, vielleicht haben die ja eine Idee.

Den Referrer Spam blocke ich nun wie folgt über die htaccess:

## SITE REFERRER BANNING
RewriteCond %{HTTP_REFERER} semalt.com [NC,OR]
RewriteCond %{HTTP_REFERER} buttons-for-website.com [NC,OR]
RewriteCond %{HTTP_REFERER} seoanalyses.com [NC]
RewriteRule .* - [F]

Muss natürlich immer aktualisiert werden, wenn neue Spam-Referrer in den Statistiken auftauchen.

Für die Lösung meines Problems, käme dann wohl doch das Plugin von Putzlowitsch in Frage denke ich mal.

Putzlowitsch: Ist das Plugin mit der aktuellsten Wordpress-Version kompatibel und lässt es sich leicht realisieren, dass statt 404 eine 403 zurückgegeben wird?

Putzlowitsch

Ja, es läuft mit der aktuellen WP-Version. Das Plugin ist so simpel, es sollte auch mit zukünftigen WP-Versionen noch funktionieren, es sei denn, WP krempelt den Core komplett um.

Die Änderung in 403 ist auch kein Problem. Einfach im Quelltext die 404 durch eine 403 ersetzen. Allerdings wird dann nicht die Wordpress-Fehlerseite angezeigt. Aber der Statuscode paßt.

Gruß
Ingo

Gnislew

Danke. Dann werde ich das Plugin heute abend installieren.

Putzlowitsch

Kleiner Nachtrag noch zum Ausgangspost.

Bei der Beispielzeile aus der Logdatei ist das letzte Feld gar nicht der Referrer, sondern die Domain, welche aufgerufen wurde. Der Referrer steht zwischen der Anzahl übertragener Bytes und dem User-Agent, in dem Fall "-", also leer.

Daher gab es wohl die leichte Verwirrung darüber, welche Domain eigentlich geblockt werden soll. Da der Referrer leer ist, greifen da natürlich keine Regeln, die auf einen konkreten Referrer Bezug nehmen.

Gruß
Ingo

formateins

Zitat von Putzlowitsch

Nenne es, wie Du willst, nur kommt man da mit der Auswertung des Referrers nicht wirklich weiter, wenn als Referrer die eigene Domain/Webseite eingetragen ist.
Auch die Aufnahme einer solchen URL in den Google-Index kann man so nicht verhindern, da der Google-Bot nicht mit dem gefälschten Refferer zugreifen wird.

Ich nenne es beim Namen. Es geht um den Einsatz von Umgebungsvariablen - dort kann auch eine URI stehen. Und das verhindert erfolgreich das Indexieren.

Zitat von Putzlowitsch

Ein Statuscode 405 ist an der Stelle einfach falsch, denn die Request-Methode GET ist ja durchaus richtig. Was sollten den die richtige Methode sein, POST oder HEAD?
Man könnte eventuell als alternative zum 404 einen 403 zurückgeben, ein etwas stärkeres Signal. Der wirkt auch bei Google etwas schneller. :-)

Der Statuscode 405 ist an der Stelle exakt richtig, erfordert aber einen gezielten Einsatz (QUERY_STRING).

Lesen/Verstehen: http://httpd.apache.org/docs/2.4/mod/mod_setenvif.html

Putzlowitsch

Zitat von formateins

...
Der Statuscode 405 ist an der Stelle exakt richtig, erfordert aber einen gezielten Einsatz (QUERY_STRING).
...

Es gibt keine HTTP-Request-Methode QUERY_STRING.
Lesen/Verstehen: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9

Der Fehler 405 zeigt eine nicht erlaubte Requestmethode an. In der Antwort sollte eine Liste der erlaubten Methoden stehen. Welche wäre das denn z.B. um Unterschied zur verwendeten GET-Methode?
Lesen/Verstehen: http://www.w3.org/Protocols/rfc2….html#sec10.4.6

Klar kann man viel mit der .htaccess und den diversen Modulen machen. Nur ist das aus meiner Sicht für das konkrete Problem keine vernünftige Lösung.
Und ja, kann natürlich eine lange Liste mit bekannten Wordpress-URL-Parametern in der .htaccess Pflegen, die sich dann auch noch durch Plugins ändern kann. Viel Spaß! :-)

Gruß
Ingo

formateins

Wenn ein Querystring an einer URL dran klebt, ist die Request-Methode offensichtlich. So schlau ist der Apache.

Zudem nicht gelesen und somit auch nicht verstanden: Request_URI

Zitat

[COLOR=#333333]In der Antwort sollte eine Liste der erlaubten Methoden stehen.[/COLOR]

Von mir aus. Juckt keinen, weil das Spoofing unterbunden werden soll. Wenn ich den Kandidaten schon _vorher_ den Zugriff verweigere, bleibt mir das eh erspart.

Keine vernünftige Lösung ist es, für jeden Mist in WordPress ein Plugin zu installieren. Da wünsche ich auch viel Spaß! :D

Putzlowitsch

Zitat von formateins

Wenn ein Querystring an einer URL dran klebt, ist die Request-Methode offensichtlich. So schlau ist der Apache....

Eben, wenn an der URL Parameter dranhängen, ist es ein GET-Request. Mit dem 405 sagst Du dem Aufrufenden, daß die Methode GET nicht erlaubt ist, und welche ist es dann?

Ein schönes Beispiel, wie der 405 richtig verwendet, ist z.B. die xmlrpc.php in Wordpress. Die gibt den 405 aus, wenn sie einfach so in der Browserzeile (mit GET) aufgerufen, mit dem Hinweis, daß nur POST-Requests erlaubt sind.

Für das konkrete Problem ist der 404 vollkommen ausreichend und passender, würde ich sagen.

Zitat von formateins

... Zudem nicht gelesen und somit auch nicht verstanden: Request_URI ...

Danke für den Hinweis, das Modul kenne ich und verwende es auch.

Zitat von formateins

... Keine vernünftige Lösung ist es, für jeden Mist in WordPress ein Plugin zu installieren. Da wünsche ich auch viel Spaß! :D

Wenn es sowieso nur Mist ist, kann man es ja ganz weglassen.
Aber ich gebe Dir recht, so eine einfache Parameter-Prüfung gehört nicht in ein Plugin, sondern eigentlich in den WP-Core.

Gruß
Ingo

Gnislew

Ich muss den Thread noch einmal hochholen.

Für URLs imt dem Aufbau http://www.sneakfilm.de/?url= habe ich nun folgende Lösung im Einsatz:

RewriteCond %{QUERY_STRING} url=
RewriteRule .* - [F]

Damit werden die Anfragen erfolgreich abgelehnt und bekommen eine 403.

Ich bekomme allerdings auch anfragen an URLs mit http://www.sneakfilm.de/page/xx/?url=

Dafür habe ich mir folgendes überlegt:

RewriteCond %{QUERY_STRING} page\/[0-9]\+/?url=
RewriteRule .* - [F]

Allerdings greift die Regel nicht.

Könnt Ihr mir helfen die Regel ans Rennen zu bringen?

Danke
Gnislew

Willkommen! Melden Sie sich an oder registrieren Sie sich.

eigenartige URL im Access Log und in der Google Indizierung

Jetzt mitmachen!