HowTo: Gelöscht

[supervisior]

An den nächsten Nörgler!

Bitte nicht nörgeln, sondern überlegt Euch lieber, was man noch besser machen könnte. Alles andere ist nur sinnfreies Genörgel, das keiner haben will, geschweige denn interessiert.

[Hanzo2012]

Das Genörgel hat einfach Tradition, OK? Wäre doch langweilig sonst.

Was man noch besser machen könnte: Die URL der versteckten Seite "personalisieren". Also nicht jeder "Besucher" kriegt denselben versteckten Link geliefert, sondern darin geschickt kodiert sind die ersten 2 oder 3 Bytes der IP-Adresse oder andere Dinge wie der User Agent String. Wenn die beim späteren Aufruf der versteckten Seite nicht passen, wird nicht blockiert. So wäre es für mich als Bösewicht nicht so leicht, gutartige Bots (die du nicht in deiner Whitelist hast) oder Millionen unschuldiger Besucher bei dir sperren zu lassen bzw. deine .htaccess immer größer werden zu lassen und damit deinen Server immer langsamer zu machen (indem ich auf meiner stark frequentierten Seite ein iframe setze, das auf deine versteckte Seite verweist).

[supervisior]

Auf das "personalisieren" in Form von automatisch generierten Hash wäre ich nicht gekommen, weil sich so was bei mir verbietet. Mit einem HTTP Cache lässt sich nur schwer bis gar nicht etwas dynamisch generieren. Ich versuche zwar Dir zu folgen, aber ich kann Dir sagen, dass das Aufkommen sehr gering und überschaubar ist. Es ist nicht so, dass man jeden Tag Hunderte von Einträge hätte. Vorausgesetzt man nutzt das auch, was in der Text Datei steht. Andernfalls machts keinen Sinn.

Probiers doch einfach mal aus. Musst ja nicht gleich blocken, sondern einfach mal nur so zum Schauen.

[Hanzo2012]

OK, ich werde es demnächst mal ausprobieren.

Ich mache etwas Ähnliches schon für Bots, die automatisiert nach Verzeichnissen wie "admin" etc. suchen oder nach PHP-Skripten mit bekannten Schwachstellen. Da habe ich im Prinzip die gleiche Problematik.

[supervisior]

OK, ich werde es demnächst mal ausprobieren.

Ich mache etwas Ähnliches schon für Bots, die automatisiert nach Verzeichnissen wie "admin" etc. suchen oder nach PHP-Skripten mit bekannten Schwachstellen. Da habe ich im Prinzip die gleiche Problematik.

Das war das Allererste, was ich gemacht habe!

Die bekommen statt dessen das zu sehen. Aber nur 1x, weil sie beim nächsten Aufruf automatisch geblockt werden.

stinkefinger.gif (209.6 KiB) 1964 mal betrachtet

[staticweb]

> Tu Dich bitte mal einlesen. Zur Gefahrenabwehr ist nicht nur das Speichern von IP Adressen erlaubt, sondern auch das zustimmungsfreie Setzen von Cookies.

Eine vorübergehende Speicherung ist in der Tat möglich. Danach ist eine Anonymisierung notwendig.

> Aber wenn Du schon damit anfängst, dann verteufle bitte auch das Speichern der IP Adresse in die access_log. Bist Du jetzt päpstlicher als der Papst?

Das war nur eine Frage. Entscheiden tun darüber andere.

> Lass das sinnlose und an den Haaren herbeigezogene Genörgle. Du bist aber gern eingeladen meine Idee zu verbessern.

Bevor man etwas verbessert muss man die Punkte ansprechen und ausdiskutieren.

> Das kann nur der bewerten, der so was auch bewertet und wenn derjenige davon gleich überhaupt nichts mitbekommt, kann er auch nichts bewerten. Ist aber auch egal, die Seite hat keinen Content, also was soll das überflüssige Genörgle?

Es ging weniger um den honey pot, als um den Link dahin.

> Bitte nicht nörgeln, sondern überlegt Euch lieber, was man noch besser machen könnte. Alles andere ist nur sinnfreies Genörgel, das keiner haben will, geschweige denn interessiert.

Das war weder nörgeln noch dekonstruktive Kritik, sondern dass Ansprechen von Punkten die bei so einer Lösung im Vorfeld betrachtet werden sollten.

Verbessern kannst du deine Lösung wahrscheinlich nur selbst, indem du auf die angesprochenen Punkte eingehst und die dazugehörige Lösung zur temporären Sperrung unproblematischer IPs anbietest.

[supervisior]

Seh das mal von der ganz lockeren Seite, weil alles, was dieses Teil macht, ist das Schreiben von Daten in eine Text Datei und ist im Grunde genommen fast das Gleiche, das auch in der access_log steht und da diskutierst Du auch nicht erstmal drüber, oder?

Außerdem ist der Link auch nur ein Link wie jeder andere, der zufällig nicht sichtbar ist. Es ist weder an dem Einen noch an dem anderen etwas dran, was man benörgeln müsste. Und die Seite auf die der Link zeigt ist leer und was leer ist, lässt sich schwer unterstellen, dass man damit einen Suchmaschinen relevanten Vorteil haben könnte.

Hab ich recht oder hab ich (wieder mal) recht?

[nerd]

Deine idee ist zwar naheliegend, aber an keiner ecke zu ende gedacht.

Gute/schlecht bots erkennt man keineswegs an IP, UserAgent oder Referer (kann man alles extrem leichgt verscheiern oder frei setzen!), sondern daran wie sie sich verhalten (wieviele pageviews pro session verglichen mit normalen besuchern), welche files sie aufrufen oder nicht (werden bilder, css, js files nachgeladen?) oder welche interaktionen (maus,keyboard oder touch events? captcha geloest?) es mit der seite gibt.

Abgesehen davon ist es 2020; jedes bessere framework und cms hat features eingebaut womit sich requests begrenzen lassen um missbrauch zu vermeiden oder scraper auszubremsen. Irgendwelche IPs direkt per PHP in die .htaccess zu schreiben ist schon ziehmlich ... mutig. Die .htaccess ist keine firewall die jeden request erstmal mit einer halben million verdaechtigen datensaetzen abgleich soll, und man kann mit einem falschen zeichen schnell mal die ganze seite lahm legen. Werden bei dir user-agent und referer richtig escaped wenn du sie direkt in die htaccess schreibst, oder was passiert wenn ich ascii-sonderzeichen, zeilenumbrueche oder utf8-character in den user-agent packe?
Noch dazu wechseln IP adressen extrem oft den besitzer, sodass man die IPs nach ein paar tagen wieder freigeben sollte.

Hast du bei deiner loesung A/B test gemacht, wie sich dein besucherblocker auf verkaeufe, werbeeinnahmen oder konversationen ausgewirkt?

Wie man es besser machen kann:
Bei Laravel (und anderen frameworks) gibt es eine list mit Routen die festlegt wie ein request auf eine bestimmt url behandelt werden soll. Am einfachsten ist es, routen fuer die bekannten ordner wie 'wp-admin' anzulegen, und von dort aus die ip in die entsprechende DB zu schreiben, ein captcha zu schalten oder ins log zu schreiben. Es gibt auch packages womit man logfiles auch in den firmeneigenen slack channel, sms, email usw. umbiegen kann, damit man nicht taeglich irgenbdwelche logfiles auf dem server ausgraben muss...

[supervisior]

Deine idee ist zwar naheliegend, aber an keiner ecke zu ende gedacht.

Natürlich ist sie zuende gedacht und Du scheinst die "Taktik" nicht zu verstehen. Wo steht bitte, dass man mit einer IP einen unerwünschten Aufruf von was auch immer erkennen kann?

Wie @Hansodingenskirchen es nicht besser hätte sagen können. Es ist ein HoneyBot, eine vergleichsweise simple Methode, die in diesem Fall nur zur Aufgabe hat das Target auf eine falsche Färte zu locken und im konkreten Fall ansonsten typische Informationen in ein File zu schreiben. Mehr macht das zunächst mal nicht, aber es obliegt dem Einzelnen mit den gesammelten Daten eine Entscheidung zu fällen. Punkt! Was ist daran bitte verwerflich? Und auch wenn wir inzwischen das Jahr 2020 schreiben.

Ich will Dir sogar ein Beispiel geben und versuchen Deinen leider etwas begrenzten Horizont zu erweitern.

Es sei nochmal daran erinnert, dass es sich um einen herkömmlichen Link handelt, der sich von anderen Links nur dadurch unterscheidet, dass er nicht sichtbar ist. Also pures HTML und CSS. Ein normal sterblicher Nutzer sieht diesen Link nicht, geschweige denn wird ihn jemals aufrufen (können). Und wenn doch, dann wundert er sich max., dass die aufgerufene Seite leer ist. In 5 Jahren mit zigtausend Besuchern ist das zumindest bei mir noch nie passiert.

Nehmen wir nun an, dass Du so wie ich diesen besagten Link in eine Listung innerhalb von Pagination Seiten platzierst und der Link auf jeder Listing immer wiederkehrend auftaucht. Nehmen wir weiterhin an, dass wir es mit einem Content Scraper zu tun haben. Aus Deinen Äußerungen lässt sich entnehmen, dass das Thema Content Scraping bislang spurlos an Dir vorübergegangen sein muss. Weil dann wüsstest Du, dass es für diese Funktion frei käufliche Anwendungen, wie auch Geschäftsmodelle gibt, die ungeachtet der verwerflichen Funktion Anwendungen wie Dienste für genau diesen Zweck anbieten. Es gibt sogar ein geniales kostenloses Plugin für Chrome und FF, das man bei Google und Mozialla downloaden kann. Diese Dienste und Anwendungen sind weder Hacker Tools noch bekommst Du diese im DarkNet und verhalten sich beim Scrapen zielgenauer als jeder komerzielle Bot das kann. Wie diese Anwendungen funktionieren, kann ich meiner leider nicht mehr vorhandenen Oma in 3 Minuten erklären und braucht dafür max. einen herkömmlichen PC und noch nicht mal einen Server.

In jedem Fall simulieren diese Anwendungen ein realen Nutzer, der sich von diesen nur dadurch unterscheidet, dass diese Anwendungen in vergleichsweise kurzer Zeit eine hohe Anzahl an Content verkonsumieren. Ansonsten gibt es kein weiteres Erkennungsmerkmal, sodass kein noch so gutes PHP Framework in der Lage wäre, was sie ohnehin in Ermangelung solcher Funktionen nicht können, diese Art "Nutzer" zu erkennen/identifizieren. Nur zu Deiner Info, dafür brauchts dann etwas mehr als ein PHP Framework. Google bietet solche Dienste für Enterprise Kunden an. Nur um Dir eine Orientierung zu geben.

Nun haben wir also mal so einen Fall, wo so ein Pseudo Nutzer Deine Seite crawled, Seiten rendert, Javescript ausführt, also all jenes, was jeder andere natürliche Nutzer auch hat und macht, nur eben viele Aufrufe in deutlich kürzerer Zeit, was sich per Einstellung sogar anpassen lässt, sodass ein womöglich installiertes IDS nicht den Verdacht hegen könnte, dass hier ein Content Scraper unterwegs ist.

Dieser besagte Pseudo Nutzer == Scraper ruft nun Deine Seiten auf und verwendet dafür einen herkömmlichen UA für ein Android Smartphone. Also etwas alltägliches, allerdings passt die Kombination aus dem UA, dem Aufruf des besagten Links mit der Menge an aufgrufenen Seiten nicht zusammen. Das ist dann nicht nur ein Indiz, sondern ein Garant dafür, dass das kein normaler Nutzer sein kann. Dass man den UA leicht ändern kann, tut hier nichts zu Sache, weil einzig die Kombination aus Fakten den Nachweis liefert.

Hat man nun z.B. Matomo installiert, das mir eine Echtzeit Anzeige an Aufrufen ermöglicht, habe ich die Möglichkeit in nahezu Echtzeit solche Aufrufe zu sehen. Nun kommt aber die entscheidende Frage an Dich:

Was bitte spricht dagegen solche Aufrufe, bzw. die IP dieser Aufrufe temporär über die .htaccess zu blockieren? Ich mache das zwar nicht über die .htaccess, sondern mit 1 Click über die Firewall, die diesen Eintrag nach 3 Tagen automatisch wieder löscht, aber nochmal, was ist daran bitte verwerflich?

Und nur der Neugierde halber, verrate mir doch bitte konkret das PHP Framework, das eine IDS Funktion besitzt und in der Lage ist solche Art Nutzer von einem realen Nutzer unterschieden kann, ohne versehentlich den falschen zu blocken?!

[nerd]

Alles klar, Herr Dunning Krueger...

[supervisior]

Danke, dass ich Deinen Horizont erweitern durfte....

[Bodo99]

Bitte streitet doch nicht soviel. Sachliche Diskussion ist ja gut, aber werdet doch nicht immer alle so schnell persönlich. Danke Supervisor für dein Script und das du es mit uns teilst.

[supervisior]

Hier streitet doch niemand?! Wenngleich der eine oder andere Kommentar überflüssig war, wo es doch nur um eine wirkliche simple Sache, aber mit großem Nutzen geht. Es liegt aber an jedem einzelnen verantwortungsvoll damit umzugehen.

[staticweb]

> Wer es gerne Hardcore habe will, so wie ich , der lässt die IP Adresse gleich in die .htaccess schreiben, aber das ist jedem selbst überlassen.

> $userAgent = $_SERVER[HTTP_USER_AGENT];
> $userAddress = $_SERVER['REMOTE_ADDR'];
> $userRequestTime = $_SERVER['REQUEST_TIME'];
> $userReferer = $_SERVER['HTTP_REFERER'];
> $userRequestUri = $_SERVER['REQUEST_URI'];

Verbesserungs-Möglichkeit:

Mir fehlt hier eine Validierung / Bereinigung der $_SERVER Variablen. Du hast vergessen zu erwähnen, dass nicht alle $_SERVER Variablen sicher vor einer Manipulation sind und nicht ungeprüft weiterverarbeitet / gespeichert werden sollten. Vielleicht gibt es hier unerfahrene User die deiner obigen Anregung folgen und die Werte direkt ohne Validierung / Bereinigung weiterverwenden.

[supervisior]

Kritik gerechtfertigt, darfst Deinen verbesserten Code aber gern posten. Also nicht nur zu recht kritisieren, sondern auch bitte gleich den Verbesserungsvorschlag posten. Ansonsten hat keiner was davon und lässt Deinen Vorschlag nur offen stehen.