Ein Scraper muss HTTP-Anfragen stellen und Inhalte abrufen. Wird eine solche Anfrage bereits durch nginx, einen vorgeschalteten Reverse Proxy oder eine Lösung wie Anubis abgewehrt, erhält der Scraper die angeforderten Inhalte nicht.
Das ist eine Binsenweisheit. Die Frage ist, wie genau der Scraper erkannt wird und - noch viel wichtiger - wie false positives vermieden werden.
Deine Unterscheidung zwischen dem Schutz vor Serverlast und dem Schutz vor Scraping ist deshalb in dieser Absolutheit nicht nachvollziehbar. Beides sind unterschiedliche Schutzziele, die sich technisch keineswegs ausschließen. Im Gegenteil, eine wirksame vorgelagerte Bot-Abwehr kann beide Probleme gleichzeitig adressieren.
Natürlich kann sie das. Genauer gesagt: Wer sich vor Contentklau schützen will wird sich automatisch in irgendeinem Ausmass auch vor Serverüberlast schützen. Wer sich aber "nur" vor Serverüberlast schützen will schützt sich dadurch nicht zwingend auch vor Contentklau.
Zwei einfache Beispiele:
Wenn ich mein Forum hinter Cloudflare hänge und 90% meines Contents über den CF-Cache ausliefere bin ich weitgehend vor Überlast geschützt - aber nicht vor Contentklau.
Wenn ich eine "geht so" Boterkennung habe, die 80% der Bots ausfiltert (wo auch immer), bevor sie den Content bekommen, bin ich wahrscheinlich auch in relevantem Ausmass vor Überlast geschützt, nicht aber vor Contentklau.
ergo: die Maßnahmen müssen zum Schutzziel passen. Dazu muss man sich als allererstes klar sein, was überhaupt das Schutzziel ist und welche Priorität es hat. Du bekommst z.B. schon einiges an Last vom System, wenn Du schlicht die Suche für Gäste deaktivierst und auch ansonsten dynamische Inhalte weitgehend für Gäste unzugänglich machst (z.B. die "what's new" Seite). Dafür brauchst Du weder Nginx noch Anubis.
Entscheidend ist nicht, wie viele Ressourcen das Add-on selbst benötigt, sondern welche Ressourcen bereits verbraucht wurden, bevor es überhaupt eingreifen kann.
In der Theorie ja, in der Praxis ist das nur dann relevant, wenn die Ressourcen vor dem Eingreifen verbraucht würden. Bei einem halbwegs performanten eigenen Server ist das nur bei deutlich grossen Botwellen der Fall (und da geht das dann schon in Richtung DDOS, wogegen eine Firewall auf dem Host keine hinreichend brauchbare Strategie ist), beim Shared Hosting deutlich früher, aber auch da braucht es schon ordentlich Anfragen, wenn man nicht gerade das allerbilligste Hosting gewählt hat.
Die Praxis hat bei mir gezeigt, dass die lokale Filterung per .htaccess und XF AddOn bisher ausgereicht hat. Das muss und wird natürlich nicht immer so sein - die Welle muss nur gross genug sein. Am Ende ist aber die Frage: Auf welches Szenario lege ich meine Ressourcen aus? Natürlich kann man auf ein hypothetisches Szenario optimieren - fragt sich, ob das zwingend sein muss. Wie Donald Knuth so schön sagte:
Premature Optimization is the root of all evil....
Auch Deine Aussage zur Sicherheitsarchitektur halte ich für fachlich fragwürdig.
Aha. Vielleicht liest Du mal ein bisschen was darüber - z.B. den über 25 Jahre alten Klassiker:
Kann man immer noch was draus lernen.
Du stellst eine Firewall oder nginx auf demselben Server hinsichtlich der Sicherheitsarchitektur weitgehend mit einem XenForo-Add-on gleich.
Nein, das tue ich nicht. Nicht mal im Ansatz. Es ist aber eine sicherheitsarchitektonische Binse, dass getrennte Entitäten deutlich sauberer und sicherer sind. Zum einen hinsichtlich Kompromittierung und Durchstichtsmöglichkeiten und zum anderen schlicht aus dem gleichen Grund, der Dir oben noch so wichtig war (aber nun offenbar egal ist): Resourcenauslastung bzw. -überlastung. Wenn es ordentlich rummst und Du alles auf einer Kiste laufen hast, in die Du Dich im schlimmsten Fall nicht mal mehr einloggen kannst oder jeder Tastendruck 30 Sekunden dauert, weil eh schon Rauchwölkchen rauskommen machst Du gar nichts mehr ausser traurig gucken. Bei getrennten Systemen kannst Du in so einer Situation die komplette Netzwerkarchitektur immer noch umbauen. Ich weiss ja nicht, ob Du sowas schon mal erlebt und gemacht hast. Ich schon und nicht nur einmal. Schon vor 20 Jahren.
Kurz: Es ist ein grundlegendes architektonisches Prinzip, Schutzsystem und zu schützendes System wenn irgend möglich hardwaremässig und logisch zu trennen. Du plädierst für softwareseitige Trennung und das ist besser als gar keine. Ordentlich und sauber geht anders.
Das ist der grosse Vorteil von Cloudflare: So eine getrennte Architektur gibt es da schlüsselfertig, endlos skalierbar, professionell entworfen und betrieben, laufend weiterentwickelt und das auch noch for free. Aber ohne Geld einzuwerfen halt nur limitiert konfigurierbar und mit ein paar durchaus bedenkenswerten Nachteilen. Es werfen aber nicht grundlos viele Firmen viel Geld Richtung Cloudflare, um ihre Systeme von der direkten Anfragelast weitgehend abzukoppeln
Wenn ein Betreiber keinen Zugriff auf nginx, Firewall oder vorgeschaltete Dienste hat, kann ein XenForo-Add-on eine sinnvolle und praktikable Lösung darstellen. Dagegen habe ich überhaupt nichts einzuwenden.
Aber aus der Tatsache, dass eine bestimmte Lösung unter eingeschränkten Bedingungen praktikabel ist, folgt nicht, dass sie technisch gleichwertig oder unter hoher Last ebenso effizient wäre.
Das hat auch nie einer behauptet. Im Gegenteil Z.B:
In Summe bin ich damit ziemlich zufrieden. Es läuft reibungslos und im Prinzip auch wartungsfrei, solange die Situation in Sachen Botquellen statisch bleibt. Architektonisch ist es natürlich suboptimal, die "Firewall" als XF add on zu haben, aber allen Bedenken und Unkenrufen zum Trotz gab es bislang keine Loadprobleme. Bot Guard wiederum bekommt ja nur einen kleinen, vorgefilterten Teil der Gesamtlast ab (was btw. auch im Manual empfohlen wird) und so kommt es auch da zu keinen Loadproblemen.
Es ist aber Unsinn, irgendwem, der es mit Mühe schafft, sein Forum zu administrieren und da kompetenzhalber schon hart am Wind segelt zu empfehlen, wilde Konstruktionen mit Anubis und Ähnlichem zu basteln, für die weder die Fähigkeiten noch das Interesse da sind. Ganz zu schweigen davon, dass es auf shared hosting eh nicht geht und das eben ein Regelfall ist. Auf XF Cloud geht das btw. auch nicht, da kannst Du noch nicht mal die .htaccess konfigurieren. Über Nginx und Anubis brauchst Du da gar nicht nachzudenken.
Ich bestreite weder, dass Bot Guard funktionieren kann, noch, dass es Scraping erschweren kann. Ich bestreite Deine Schlussfolgerung, dass die erfolgreiche Nutzung auf Deinem Shared Hosting die grundsätzlichen Nachteile einer Abwehr innerhalb der PHP-Anwendung widerlegen würde.
Auch das hat nie einer behauptet.
Eine frühzeitige Blockierung verhindert, dass nachgelagerte Verarbeitungsschritte überhaupt ausgeführt werden müssen. Das ist keine graue Theorie, sondern eine unmittelbare Folge der Systemarchitektur.
Ja. Und. Hättest Du den Thread, in dem Du postest, gelesen, hättest Du gemerkt, dass das bereits x-fach erwähnt worden ist. Unter anderem von mir. Gerade was Bot Guard angeht (an dem Du Dich, warum auch immer, festgebissen hast). Da steht sogar in der Doku, dass man vorfiltern soll, weil das lastmässig sonst unangenehm werden kann. Schon ohne eine extraordinär grosse Botwelle, schlicht mir dem aktuell normalen Wahnsinn. Was auch absolut niemanden verwundern sollte. Darum hängt auf meinem Shared Hosting da IP Threat Monitor davor. Auch ein XF Add On, aber wesentlich schlichter vom Gemüt und daher auch wesentlich ressourcenschonender bzw. auch mit Absicht so gebaut. Und davor hängt die .htaccess. Mehr geht auf shared hosting nunmal nicht, (und auch nicht auf XF Cloud) wenn man nicht mit Cloudflare oder ähnlichen Lösungen arbeiten möchte.
Und genau deshalb bleibt mein ursprünglicher Punkt bestehen: Eine Bot-Abwehr möglichst früh in der Verarbeitungskette ist aus Sicht der Ressourceneffizienz grundsätzlich vorzuziehen. Anwendungsspezifische Schutzmechanismen können diese sinnvoll ergänzen, ersetzen ihre Vorteile aber nicht.
Es hat nie jemand etwas anderes behauptet. Im Gegenteil: es steht seit Monaten x-fach hier im Thread. Wir sind aber im richtigen Leben und nicht bei Wünsch Dir was. Ergo geht es darum, was realistisch finanziell, zeitlich und kompetenzmässig leistbar ist für einen Forenbetreiber. Gelebter Pragmatismus bzw., professionell ausgedrückt: Was ist das für das gegebene Zielsystem realistisch angemessene, was das nötige und was das überhaupt erreichbare Schutzniveau? Das ist logischerweise sehr unterschiedlich. Es wird aber wohl kaum jemand für ein kleines Hobbyforum, das auf einem 10€ shared Hosting läuft, eine umfängliche Serverlandschaft mit professioneller Sicherheitsarchitektur hinstellen und erst recht nicht in der Lage sein die auf professionellem Niveauzu warten und monitoren. Wäre ja auch albern: Wenn so ein Forum mal zwei Stunden ausfällt: Wen interessiertes? Das ist schlicht nicht wichtig genug, um so einen Aufwand zu betreiben. Wenn das Forum hingegen x00.000 User und entsprechend Traffic hat und evtl. gar eine relevante Einkommensquelle ist sieht die Lage anders aus. Aber auch dafür wird realistisch keiner eine ganze Serverlandschaft hinstellen.
Also ist die relevante Abwägung, wie "schlecht" noch gut genug ist. Denn auch Deine gepriesene Lösung ist unter professionellen Gesichtspunkten "schlecht". Der eine landet dann bei IP Thread Monitor, der Andere bei Nginx, der Dritte bei Cloudflare und der Vierte macht schlicht gar nichts und setzt auf das Prinzip Hoffnung.
Angesichts der zunehmend aggressiven Bot-Wellen ist das längst keine graue Theorie mehr, sondern alltägliche Realität. Umso wichtiger ist es, die Kosten einer unerwünschten Anfrage für den eigenen Server so gering wie möglich zu halten und gleichzeitig den Aufwand für den angreifenden Bot so hoch wie möglich zu treiben. Genau das ist eines der grundlegenden Prinzipien einer effizienten Bot-Abwehr.
Es wäre ja schön gewesen, wenn Du statt lauter Theorie und mich destruktiv anmaulen mal konstruktiv irgendwas dazu gesagt hättest, wie genau das denn nun in der Praxis geht. Wovor genau Du Dich schützen möchtest und was das angestrebte Ziel ist. Was genau Du nutzt und wie genau welches Tool konfiguriert ist mit welchen Ergebnissen. Und wo genau auch die Schwächen Deiner Lösung liegen, basierend auf der gemachten Erfahrung. Dazu gibt es aber genau nichts von Dir. Alles sofamässige Rumschlaumeierei ohne jeden Praxisbezug. Und unterm Strich weder hilfreich noch ist da inhaltlich irgendwas Neues drin.
Wer einen eigenen Server betreibt, (hoffentlich) die Kompetenz dafür hat und die Zeit und den Spass am Basteln der kann natürlich mit Dingen wie Anubis eine Menge wegrocken. Man kann in so einem Konstrukt sich aber sehr prima selbst in den Fuß schiessen, das Forum unerreichbar machen und ohne Ende Zeit verballern. Ohne Unix Kenntnisse einen Server zu betreiben ist verantwortungslos und die sicherere Konfiguration (bzw. überhaupt Konfiguration) von Nginx, Anubis, fail2ban, CSF und Konsorten ist nun mal komplex. Nur ein Bruchteil derer, die ein Forum betreiben, hat die besagten Kompetenzen (und würde wahrscheinlich schon beim ssh-Zugang per Ke Authentisierung scheitern). Kann man blöd finden, ist aber so. Die kann man natürlich nun dissen und auslachen - das ist aber schäbig und macht die Lage gewiss nicht besser. Bei Shared Hosting und auf XF Cloud (und auch auf einem managed Server) sind die technischen Möglichkeiten zudem eh eingeschränkt. Da sind Tools wie besagte Add Ons oder bzw. auch in Kombination mit Cloudflare oder Ähnlichem dann doch hilfreich und im Vergleich mit einer niedrigen Lernschwelle versehen. Sich dann aufzuplustern und zu behaupten, dass ohne Anubis das alles nur Dreck ist ist sowohl albern wie auch an der Realität komplett vorbei. Sollen diese Leute alle ihre Foren dicht machen?
Vom Grundprinzip her, dass man architektonisch gesehen so früh bzw. so weit aussen wie im jeweiligen Setup möglich filtern sollte sind wir uns denke ich einig. Da gibt es ja auch nichts zu diskutieren. Nur bin ich offenbar einerseits deutlich pragmatischer bzw. praxisorientierter was die Anwendung bzw. Relevanz dessen in der jeweils konkreten Situation angeht und andererseits hört für mich Sicherheitsarchitektur nicht bei der Auslastung von PHP-Prozessen auf sondern hat noch reichlich andere Komponenten, Aspekte und Prinzipien.
