AddOn: Abwehr von Crawlern und Trojanern via php

[madiko]

letztes update 31.05.2017 (FK): Titel und damit Aufgabe auf Anregung der FOR geändert (siehe Kommentare unten)

########################

Hallo zusammen,

ich erzähle Euch nichts Neues, dass es regelmäßig zahlreiche sicherheitsrelevante Angriffe auf CMS weltweit gibt. Eine mir bekannte Form ist der Angriff von crawlern - unschuldig getarnt als "Webstats"-Backlink. Es gibt sogar die Progrnose, dass hier ein bösartiges Trojaner-Botnet aufgebaut wird. Die Zusammenfassung meines Wissensstandes findet Ihr unten.

Da ich eine Abwehr der entsprechenden Websites bzw. die Abwehr der Angriffe von crawlern / Trojanern für einen Kern eines CMS halte, schlage ich vor, dass wir auch für REX eine Lösung entwickeln. Dirk Schürjohann und Oliver Kreischer (DANKE!) schlugen mir vor, dass es als AddOn gelöst werden könnte. Ich sehe es eher als Kernfunktion für den Core.

Ich muss gestehen, dass ich selbst technisch nicht versiert genug bin, das gut genug einzuschätzen oder gar sinnvoll zu realisieren. Da die .htaccess davon betroffen ist, halte ich es jedoch für essentiell, dass sich FOR zumindest Gedanken macht (auch wenn Ihr es vielleicht verwerft).

Die bisher pfiffigste Lösung - soweit ich recherchieren konnte - entwickelte die Community rund um nabble: https://github.com/nabble/semalt-blocker

Meine erste Recherche ist von Januar 2015. Ich prüfte aktuell. Seither scheint es immer noch das am häufigsten eingesetzte System zu sein auf das letztlich alle wieder verweisen.

Wer nimmt sich der Sache an? Was haltet Ihr davon?

Besten Dank und viele Grüße, Franziska

######################## Hier noch die Zusatzinformation. Mein Original-Blogpost dazu stammt vom 27.01.2015 (letzter Abschnitt vor dem Fazit) http://madiko.com/zeitmaschine/article-?newsid=200

"In den letzten Wochen und Monaten kam eine wahre Schwemme von semalt-Links. Ich fand es zunehmend irritierend, wie häufig meine Seite von einem wild fremden gewordenen Webcontrolling-Service besucht wird. Dies widerstrebt mir schon deswegen, weil ich so die Daten meiner Leser nicht schützen kann. Mal ganz davon abgesehen, dass es meine Statistik erheblich verzerrt und ich die Daten mit viel Mühe rausrechnen muss #grml.

Jetzt habe ich mir endlich die Zeit nehmen können, um dem grundlegend auf die Spur zu gehen. Die kurze Fassung ist: Semalt ist ein Crawler, der nicht nur Referrer-Spam hinterlasst, sondern offensichtlich versucht, Backlinks anzulegen. Es wird in manchen Blogs sogar die Vermutung geäußert, dass hier die Verbreitung von Trojanern vorbereitet wird. Philipp schreibt dazu:

Gleichzeitig verdichten sich die Hinweise, dass Semalt dabei ist, über die Verbreitung von Trojanern ein weltweites Botnetz aufzubauen. Erste Meldungen hierzu stammten von VirusTotal.com, die ermitteln konnten, dass Semalt offenbar eine Software namens Soundfrost verwendet, um Computer zu infizieren. Im Nabble-Blog wird das genauer untersucht. Jorams Fazit lautet: Semalt verwendet die Software Soundfrost um Webspam zu verbreiten. […] Ich möchte an dieser Stelle darauf hinweisen, dass ich den Ansatz, die Semalt-Zugriffe nur in den Analyseprogrammen zu filtern, für zu kurz gegriffen halte. Wenn der Bot auf dem Server – und im Serverlog – aufschlägt, hat er sein Ziel bereits erreicht. An der Wurzel packt man das Problem nur über die Blockade der SPAM-Domains. Quelle: Philipp Clarin via PiliSEO Online Marketing

Mit anderen Worten: Eine Prüfung Eurer Statistik kann ich Euch nur anraten. Der beste Artikel dazu ist meiner Meinung nach der oben zitierte von Philipp Clarin. Danke an dieser Stelle vielmals für die umfassende Anleitung und die weiterführenden Links! Zweiter Dank gilt Joram van den Boezem vom Nabble Blog, dem ich mein Anti-SPAM-update für die .htacces verdanke."

Wichtige Anmerkung: Mittlerweile sind es so viele zu überwachende Seiten, dass meine .htaccess nicht mehr aktuell ist. Daher auch mein Bestreben, das mit dem neuen System REX5 zu lösen.

[alxndr-w]

Warum ist das nicht Aufgabe des Hosters? Warum ist das die Aufgabe eines CMS?

[DanielWeitenauer]

Welche .htaccess meinst du? Für das Frontend wird für den Core keine mehr mitgeliefert, da auch kein Rewriting mehr eingebaut ist.

[schuer]

Ich habe mir das mal genauer angeschaut, und es benötigt gar keine Anpassungen an der .htaccess. Das ist nur ein Weg, den man gehen kann, der aber nicht unbedingt empfehlenswert ist, weil er die Performance der Website aufgrund der vielen Regeln offenbar merklich beeinträchtigt.

Der bessere Weg ist, die PHP-Komponente zu laden. Und sowas als REDAXO-Addon umzusetzen, wäre aus meiner Sicht in wenigen Minuten zusammengesteckt.

Ich habe gerade noch andere offene REDAXO-Tasks, und ich finde dieses Blocker-Thema leider auch nachwievor nicht sinnvoll. Deshalb kann ich leider nicht anbieten, es umzusetzen, sorry :-/

[madiko]

@alexplusde Selbstverständlich ist Safety/Security im Web auch ein Thema für Hoster. Dein CMS / Deine Kunden / Deine Webnutzer vor Hackern zu schützen bleibt jedoch immer Deine Verantwortung und ein Service an Deiner Firma und Deiner Community.

[madiko]

@DanielWeitenauer Hallo Daniel. Pardon, ich wusste gar nicht, dass REX da unterscheidet (mein Fehler). Ich meine die vom Frontend. Wenn ich das Thema jedoch richtig verstehe, würde es beide betreffen. Doch das könnt Ihr Nerds vermutlich viel besser beurteilen als ich semi-professioneller Laie. ¯_(ツ)_/¯

[madiko]

@schuer Danke Dirk, dass Du da noch mal genauer draufgeschaut hast. Ich bin weiter offen, was die FOR hier diskutieren und entscheiden. Mir ist Eure Einschätzung sehr wertvoll und ich hoffe der Community auch.

Vielen Dank allen, die diesen Weg mitgehen. :-)

[polarpixel]

Ich bin mir absolut sicher, dass das Core-Team so eine Komponente in einem externen AddOn am besten aufgehoben sieht. Mit der Version 5 wurde ja sogar der Core selbst bewusst in einzelne AddOns aufgeteilt, um das System leichter wartbar und schlanker zu gestalten.

@madiko: Mein Rat wäre, dass Du Dir in der Community einen interessierten Entwickler suchst und das mit ihm zusammen als FOR-AddOn umsetzt. Wie Dirk ja schon schrieb, wird der Aufwand dafür recht gering sein, und wie bereits im Slack geschrieben lassen sich viele der AddOns im Zuge von Kundenprojekten gut finanzieren.

[DanielWeitenauer]

@madiko Mir ging es vor allem um die Frage, ob das System zwingend an Dateien aus dem Core gebunden sein müsste, was aus meiner Sicht am ehesten für eine Core-Komponente gesprochen hätte. Wenn es das weder in der .htaccess-Variante (die für das Frontend wird inzwischen nur noch von Rewriter-Addons angelegt) noch in der PHP-Version tut, ist die Variante als eigenständiges Addon auch aus meiner Sicht die am besten zum Redaxo-Konzept passende.

[madiko]

@DanielWeitenauer Danke für das Erläutern. Klingt stimmig und einleuchtend für mich. Sehr hilfreich.

[madiko]

@polarpixel: Danke für Deine Einschätzung. Sie hilft mir sehr im Verständnis für Eure Herangehensweise und Euer Konzept. Ich verstehe FOR immer besser, was die Kooperation und Kollaboration vereinfacht. :-)

[polarpixel]

@madiko: gern. Vielleicht noch zwei Ergänzungen ...

Zur Modularität des Cores: Es ist dadurch denkbar (auch wenn es zunächst erstaunlich klingt), Redaxo z.B. ohne Struktur oder ohne Backend-Verwaltung laufen zu lassen, weil das nun alles AddOns sind. Wenn man Redaxo z.B. als Basis für eine Web-App nutzt, braucht man möglicherweise nur Frontend-User und keine Backend-User. Und vielleicht auch keine Struktur. So nutzt man nur das, was man wirklich braucht.

Und bei FOR ist halt der Grundgedanke, dass nicht nur einer für sein AddOn allein verantwortlich ist und so die Weiterentwicklung besser gesichert ist. Außerdem macht's auch gemeinsam mehr Spaß, und manchmal wird ein anderer ein Feature dranbauen, das man selbst nicht leisten kann. Und man bekommt als FOR-Gemeinschaft mehr Aufmerksamkeit.

[madiko]

Hallo zusammen. Ihr habt mich überzeugt! ;-)

AddOn it is. Bitte Freiwillige vor, die es mit mir umsetzen. Ich bitte die FOR noch einen Namen für das AddOn vorzuschlagen.

Vielen Dank!

[schuer]

@madiko Klasse, vielleicht hast du ja bald Lust, bei FOR mitzumachen! Jedes Open-Source-Projekt benötigt bekanntlich nicht nur Entwicklung, sondern auch ganz viel drumrum: Ideen, Planung, Dokumentation, Motivation, Testing, Kommunikation nach innen und außen… usw.

[alxndr-w]

Das vorgeschlagene Stück Software https://github.com/nabble/semalt-blocker wird scheinbar nicht mehr gewartet, obwohl die Verwendung sehr einfach aussieht.

Generell, da eine R4-Seite bei uns jetzt auch mal unter Beschuss war, wäre vlt. eine Erkennung nützlich, die Anfragen im Millisekunden-Bereich von derselben IP oder von problematischen URLs unterbindet, ganz sinnvoll. Kenne mich selbst zu wenig dabei aus.

Man könnte selbst was bauen, vlt. gibt es dennoch eine bessere Lösung.

[staabm]

In meinen augen kann man einen viel besseren schutz erreichen indem man einen kostenlosen cloudflare plan (oder vergleichbares produkt) vor seine seite schaltet.

Ausserdem ist man nicht von schlecht gepflegten und veralteten Bibliotheken abhängig

[alxndr-w]

@staabm ich habe so eine Einrichtung eines Cloudflare-Pakets noch nie vorgenommen und auch nach dem Lesen von 1-2 Artikeln ist mir nicht so ganz klar, wie die Einrichtung vonstatten läuft. (wieso wird bspw. bei Wordpress ein Plugin benötigt? Wie wäre das mit REDAXO?)

Konkret habe ich den Artikel hier gelesen und bin verwundert, dass man seine kompletten Nameserver-Hoheit abgibt: https://j0e.org/howto-so-richtest-du-cloudflare-fuer-dein-wordpress-blog-ein/ - was passiert da mit Subdomains, MX-Einstellungen und TXT-Records?

Gerne würde ich ein Tutorial dazu schreiben, wenn man mir ein paar Happen aus der Praxiserfahrung hinwirft - und damit auch dieses Issue schließen.

[staabm]

man muss sein dns nicht abgeben, man kann. Man braucht auch keine plugins dafür, wenn man die api von cloudflare anbindet, kann man aber agressiver cachen.

[alxndr-w]

@staabm danke, werde das mal ausprobieren und ggf. berichten und ein Tutorial für die Trickkiste schreiben. @madiko wärst du damit einverstanden, das Issue hier zu schließen?

[madiko]

Ok, Community. Danke für Euer Feedback. Sieht so aus, als müsste ich für mich eine eigene Lösung finden. Danke dennoch für Eure Offenheit, die Idee zumindest zu prüfen.

@alexplusde, sofern Du ein Tutorial verfassen wirst, würde ich mich freuen, wenn Du mich anpingst, sobald es verfügbar ist. :-)