Artikelformat

Wie man Hijack Proxys besiegt

Seit mehreren Jahren ist das Problem des Proxy Hijacking bekannt und noch immer funktioniert es. Deswegen ist es mal an der Zeit, dass ich dir zeige, was das genau ist und wie du dich dagegen schützen kannst.

Was ist ein Proxy Hijack?

Über einen Webproxy den du über die Browserzeile aufrufst, kannst du im Prinzip ganz normal durchs Web surfen. Nur, dass deine Daten über den Proxy laufen, so dass die Website die du besuchst gar nicht dich, sondern nur den Proxy sieht (User Agent, IP, usw.). Gründe einen Proxy zu verwenden gibt es diverse, wie das Bedürfnis nach mehr Anonymität oder um eine Sperre zu umgehen.

Dabei ändert ein Proxy natürlich alle Links auf den Seiten die du betrachtest so ab, dass auch ein Klick auf einen Link die entsprechenden Seite wieder über den Proxy aufruft. Nehmen wir nun an Proxy A hat die Domain proxya.tld und du betrachtest deine Webseite (example.com) über ihn. Dann steht in den Adresszeile proxya.tld/proxy/example.com (1) und wenn jetzt jemand böse ist und auf die Seite (1) linkt, dann findet Google sie und indiziert sie auch (vorausgesetzt der Proxybetreiber hat dem keinen Riegel vorgeschoben).

Da nun aber (1) den gleichen Inhalt wie example.com anzeigt wurde doppelter Inhalt erzeugt. Und wenn es neben Proxy A auch noch die Proxys B, C, D, usw. gibt und jemand sie alle anlinkt oder einen mit sehr starken Links versorgt kann es passieren, dass deine Website example.com von Google nicht mehr in den Suchergebnissen angezeigt wird.

Das ist kein ausgedachtes Horrorszenario sondern schon diversen Webmastern passiert. Teilweise durch böse Proxybetreiber die die Seiten mit Werbung vollklatschen, häufig aber auch durch Konkurrenten die example.com absichtlich in diverse Proxys gebracht haben.

Kann ich mich schützen?

Es gibt eine ganze Reihe von Methoden um es gar nicht erst so weit kommen zu lassen. Sechs gängige Methoden möchte ich hier vorstellen und kurz Vor- und Nachteile erläutern.

Version 1 (noindex, nofollow)

Eine Möglichkeit ist folgendes Script, welches ich jedoch nicht empfehlen kann, da es neben den Proxys auch alle nicht explizit von dir benannten Suchmaschinen aussperrt:

Die Idee ist recht simpel: Die Spider von Google & Co bekommen die normale Seite geliefert bei allen anderen Seitenaufrufen wird ein:

gesendet, was natürlich dazu führt, dass diese Meta-Information dann auch auf der Proxy-Seite angezeigt wird.

Mein Rat: Nur benutzen wenn es jemand auf dich abgesehen hat und du massive Probleme mit Proxy Hijacking hast.

Version 2 (PHP)

Eine Lösung um gegen einzelne Proxys vorzugehen ist folgende:

Diese Funktion kannst du in deine PHP Scripte einbinden und die Seite beim Aufruf mit einem Proxy  (in diesem Fall sslsites.de) einfach umleiten. Sinnvoller fände ich es dann jedoch die IP Adressen schon in der htaccess zu sperren und nicht erst auf PHP-Ebene abzufangen (spart Ressourcen).

Version 3 (htaccess)

Wie in 2. schon angesprochen: Einfach die IP Adressen via .htaccess blocken (nur auf Apache Webservern). Etwa mit:

Mit diesem Befehl würden die Adresse 192.168.0.1 und alle mit 192.167 beginnenden IPs gesperrt werden.

Version 4 (mod_rewrite)

Ähnlich wie in 3 kann man in der htaccess auch User-Agents oder Referrer abfangen.

Wobei du mit entsprechenden RewriteRules natürlich sehr viel anstellen kannst. Zum Beispiel alle abgefangenen Proxys auf einen anderen Proxy jagen (und über diesen direkt einen weiteren aufrufen). Hier musst du wissen was dir wichtiger ist. Willst du nur den Traffic sparen und dich vor Content-Diebstahl schützen oder den Proxys extra viel Arbeit machen?

Version 5 (Proxy-Sperre)

Wer es sich einfach machen will kann auch die fertige htaccess von Proxy-Sperre benutzen: Zum Download.

Version 6 (Bot-Trap)

Ein weiteres Rundum-Sorglos-Paket zum Schutz vor Content-Grabbern, Hijack-Proxies und anderem bietet Bot-Trap.de an. Leider informiert die Seite (aus Sicherheitsgründen) nicht über ihre Arbeitsweise, so dass ich auch nichts dazu sagen kann.

Welches ist die beste Version?

Alle diese Lösungen haben aber eines gemeinsam. Sie sind nicht perfekt! Mit 2, 3 und 4 hat man viel zu viel Arbeit, die 1 sperrt zu viele Suchmaschinen aus und bei der 5 ist man abhängig von Domain-Union und wenn die mal einen Fehler machen und den Google Bot sperren kann das ganz schön ins Auge gehen. Und zu 6 weiß ich gar nichts…

Wie kann ich mich wehren?

So, jetzt kommen wir zum spaßigen Teil. Was würde passieren wenn Google die eigene robots.txt missachtet und die eigenen SERP indiziert? Dann müsste Google einen Cache dieser gecrawlten SERP anlegt und dann den Cache indiziert und einen Cache das Cache anlegen und den Cache des Cache indizieren und…(Endlosschleife!)

Genau dieses Prinzip kannst du dir zu nutze machen und damit sich die Proxybetreiber nicht so einfach wehren können, solltest du gleich zwei Proxys verwenden. Zu nächst einmal sucht du die Proxys. Es bietet sich folgendes Google Suchkommando an:

Damit werden alle Seiten außerhalb der Domain example.com angezeigt die example.com in ihrer URL haben. Dann sucht du nach Ergebnissen die den Title oder das Snipped von deiner Seite haben. Diese findet man häufig unter URLs mit Einträgen wie …/nph-index/…

Wenn du nun mehrere Proxys hast (seien es Proxy A und B), dann gehst du auf Proxy A und rufst proxyb.tld auf und in dessen URL Feld dann Google.de. In diese Google Suchbox gibst du site:proxya.tld ein. Die Original Idee sieht vor die Advanced Search zu verwenden und den Zeitraum auf Ergebnisse der letzten x Wochen zu beschränken, das ist in meinen Augen jedoch unnötig.

Jetzt hast du eine URL in dieser Form:

Die musst du nur noch anlinken. Am besten nicht von einer eigenen Seite sondern über einen Social Bookmark Dienst oder mit einer kleinen Zubringerseite (z. B. ein Blog bei einem Freehoster).

Google folgt nun dem Link, ruft Proxy A auf, der ruft Proxy B auf und der ruft Google auf und Google sieht die eigenen Suchergebnisse und indiziert sie. Nur, dass Proxy A allen URLs sein ein proxya.tld/… voranstellt, genauso wie Proxy B ein proxyb.tld/ davor hängt und auf diesem Wege auch alle von der SERP Seite aus verlinkten Seiten wieder und wieder und wieder mit weiteren URL Präfixen indiziert werden.

Irgendwann sollte der Duplicate Content auf Proxy A und B ausreichen um beide aus dem Index zu kegeln und bis dahin werden ihre System Ressourcen mit dem Infinity Loop ein wenig belastet. Falls nur ein Proxy deinen Inhalt klaut kannst du als zweiten Proxy einen beliebigen wählen. Denn sie sind alle böse oder zumindest potentiell gefährlich! Außer sie sperren ihre Ergebnisseiten für Google, aber dann passen sie ja auch nicht in das Schema.

Bewerte diesen Artikel
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

15 Bewertung(en), durchschnittlich: 5,00 von 5

Loading...

5 Kommentare

  1. Nett, daß sich immer mehr Leute diesem Thema zuwenden.
    Eines der größten Probleme ist es aber, daß die Täter die möglichen Lösungsansätze auch lesen und darauf sofort reagieren.

    Was Deine Idee mit der .htaccess anbelangt – vergiß’ es!

    Diesem Problem ist nicht mit statischen Sperren beizukommen. Und was Deine Spaßidee anbelangt: Hast Du schon einmal darüber nachgedacht, weche Kollateralschäden damit verursacht werden können?

    Antworten
  2. Ich wurde auch schon mehrfach von einigen Proxy-Diensten gehijakt. Auf der Suche nach einer Lösung stieß ich auf deinen Blogeintrag. Die besten Ergebnisse erzielte ich mit der Proxy-Sperre. Ist auch von der Umsetzung und Pflege her am wenigsten aufwändig und auch für weniger erfahrene Webmaster einfach umzusetzen.

    Antworten
  3. Allow

    Was du allerdings damit zerstörst ist die Zahl deiner Proxy-Besucher. Du solltst lieber versuchen nur Crawling via Proxy zu unterbinden, was auch im Interesse von Google und Co ist.

    Antworten
    • Was du allerdings damit zerstörst ist die Zahl deiner Proxy-Besucher: Das ist richtig, aber welcher seriöse Besucher kommt schon via Proxy? Der Verzicht auf Proxyuser zugunsten der Sicherheit, ist nach meiner Einschätzung, nicht eine Alternative, sondern ein Muß.

      Wobei der Lösungsansatz Version 2 bei weitem nicht ausreicht. Die Proxies, die mit URL-Hijacking in Erscheinung treten, sind NPH-Proxies, die die Variable HTTP_X_FORWARDED nicht zur Auswertung zur Verfügung stellen. Ein NPH-Proxy kann vom Server nicht erkannt werden – daher auch der vielfache und erfolgreiche Mißbrauch. Google crawlt sogar seine eigenen Suchergebnisse via NPH-Proxy. Zur sicheren Erkennung eines NPH-Proxies bedarf es einer PHP-Routine!

      Du solltst lieber versuchen nur Crawling via Proxy zu unterbinden: Wie soll das gehen? Es stehen lediglich die Daten zur Verfügung, die der Proxy bereit ist, zu übermitteln. Und die können unzureichend, ganz oder teilweise gefaked sein!

      Nur Crawling via Proxy zu unterbinden, was auch im Interesse von Google und Co ist: Furchtbar diese falschen Tatsachenbehauptungen! Wenn Google nicht in der Lage ist, einen NPH-Proxy überhaupt zu erkennen, dann kann Google diesbezüglich auch keinerlei Interessen bekunden, ganz gleich, wie diese auch immer geartet sein mögen.

      Und nocheinmal zu bot-trap.de/: Das kann die Lösung nicht sein!
      bot-trap.de/ erkennt und sperrt nur das, was bereits unangenehm aufgefallen ist. Jeder neue Proxy und jeder neue Contentklauer hat Freie Fahrt, bis er erwischt wird. Danach geht das Spielchen mit einer neuen 95-Cent-Domain wieder von vorne los.
      bot-trap.de/ vermag demnach lediglich Kollateralschäden und Trittbrettfahrer abzuwehren.

      Antworten
  4. Yeti

    Ein hijackender Proxy muß nicht unbedingt im Googleindex aufzufinden sein. Es gibt Proxies, die glatt Deine Position übernehmen, und es gibt auch Proxies, die nur mit einer absoluten Intensivsuche aufzufinden sind – je nach Antriebskraft und Ziel.

    Nachdem nun alle nur erdenklichen Abwehrmaßnahmen von uns entwickelt und eingesetzt wurden, mit gutem aber letztlich nicht ausreichendem Erfolg, ist der Weisheit letzter Schluß, daß der angreifende Proxy in das Umfeld des Senders weitergeleitet werden muß. Eine mit Notwehr zu umschreibende Maßnahme.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.