Spamschutz in Drupal
Je offener eine Website gehalten wird, desto mehr lädt sie Besucher um Mitmachen ein; zu diesen Besuchern zählen heutzutage jedoch nicht nur interessierte Leser, potenzielle Co-Autoren und - bei Online-Shops - auch Kunden, sondern auch allerlei zwielichtige Gestalten, Cyberkriminelle, Trittbrettfahrer, Betrüger, antisoziale Elemente, unterbeschäftige Kinder und offensichtlich Geistesgestörte, die kommerziell motivierten Spam in Gästebüchern hinterlassen, Foren mit thematisch irrelevantem Müll füllen, offene Wikis als Schmierzettel mißbrauchen usw. Jede sinnvolle technische Innovation wie Trackbacks wird binnen kürzester Zeit mißbraucht, und dieser Mißbrauch übersteigt auch auf Websites - ebenso wie bei E-Mail - bei weitem die bestimmungsgemäße Nutzung - mit diesen Fakten muß man sich im heutigen Internet abfinden, auch im Internet sind die "guten alten Zeiten" leider vorbei.
Dem Spamschutz in Drupal kommt daher eine essentielle Bedeutung zu, da zugespammte Kommentar-Threads den Sinn dieser Annotationsfunktionen ad absurdum führen und sich der Website-Betreiber durch das bloße Zulassen illegaler Botschaften haft- und strafbar machen kann. Allerdings ist Drupal konzeptionell eher auf Offenheit und Kooperation denn auf Gefahrenabwehr im Sinne der berüchtigten "Internet-Verkehrssicherungspflicht" [# OLG München, Az. 21 U 1914/02, 15. März 2002; vgl. hierzu bspw. Mischa Dippelhofer, http://www.jurpc.de/aufsatz/20020304.htm (2002)] ausgelegt. Die Spamabwehr in Drupal ist daher zeit- und arbeitsaufwändig und belastet CPU und Arbeitsspeicher des Servers - zumindest so lange man seine Website halbwegs offen halten möchte.
Drupal ist mittlerweile verbreitet genug, dass die Cyberkriminellen ihre Skripte angepasst haben; von wenigen Ausnahmen abgesehen ist daher davon auszugehen, das Kommentar- und Trackback-Spam nicht von Menschen gepostet wird, sondern einfach im Batchbetrieb durch Bots verstreut wird; viele momentan funktionierende Schutzmaßnahmen basieren daher schlicht und ergreifend darauf, Aktivitäten von nichtmenschlichen Benutzern zu unterbinden. Da die Cyberkriminellen ihre Sktipte permanent anpassen, läuft das auf ein wechselseitiges Hochrüsten hinaus, das letztlich in den meisten Fällen auf ein weitestgehendes Deaktivieren interaktiver Elemente hinausläuft.
Contents
Missbrauch der Community-Funktionen
Das Haupteinfallstor für Spam bilden in Drupal - zumindest nach unseren Erfahrungen - die Community-Kernfunktionen; erlaubt man anonymen Benutzern das Erstellen oder Bearbeiten von Seiten oder das Anlegen von Kommentaren, wird man mit einiger Sicherheit bereits wenige Wochen nach dem Launch der Website mit ersten Spam-Beiträgen konfrontiert sein.
Nach unseren Erfahrungen gibt es hier vor allem drei Schutzmechanismen:
- Umschalten der Standard-Aktion von "Speichern" auf "Vorschau" - Neue Beiträge müssen dann zunächst als Preview betrachtet werden und können erst danach gespeichert werden. Die meisten Spam-Skripte sind derzeit noch nicht in der Lage, dies zu erkennen. Leider scheinen auch viele echte Benutzer von solchen Maßnahmen überfordert zu sein, jedenfalls stellten wir nach Aktivieren der entsprechenden Funktion einen deutlichen Rückgang von (themenbezogenen und konstruktiven) Kommentaren fest.
- Installieren eines Textimage- oder Captcha-Moduls - Vor dem Absenden von Daten muß der Benutzer hier zusätzlich eine Art "Menschlichkeitsprüfung" ablegen und Zeichenkombinationen aus einem Bild herauslesen oder eine kleine Rechenaufgabe lösen; der Beitrag wird erst gespeichert, wenn ihm das gelungen ist. Wie alle Drupal-Module können sich solche Erweiterungen kontraproduktiv auf die Systemstabilität auswirken, da nicht alle Captcha-Module zuverlässig arbeiten; weiterhin wird man zusätzliche, vor allem nicht-technische Benutzerschichten verlieren und schmeist prinzipbedingt alle Accessibility-Bemühungen über Bord. Auch hier haben die Web-Spammer längst nachgerüstet und ihre Skripte mit OCR-Funktionen versehen, man muß also regelmäßig die Komplexität von Textimages erhöhen. Wir verwenden das Captcha-Modul, das uns recht brauchbar erscheint, während bei uns Alternativen wie das Text Image-Modul zu fehlerträchtig arbeiteten.
- Zugriffsberechtigungen für anonyme Benutzer entziehen - In Drupal kann man unter admin/user/access zumindest partiell den Zugriff auf Community-Funktionen erschweren; beispielsweise kann das Anlagen aller Standard-Inhaltstypen aus Drupal Core für anonyme Benutzer gesperrt werden. Natürlich werden hier weitere legitime Benutzerschichten verloren gehen, außerdem wird die Anzahl von illegitimen Benutzerregistrierungen zunehmen.
Der vierte Schutzmechanismus setzt manuelle Arbeit und damit kontinuierliche Überwachung der Website voraus: Man konfiguriert Drupal, so weit dies möglich ist, dahingehend dass Inhalte grundsätzlich erst nach Freigabe durch einen Administrator oder Moderator veröffentlicht werden:
- Moderations-Warteschlange - In der der Inhaltstypen-Verwaltung (admin/content/types) kann man für jeden Inhaltstyp eine Standardoption einstellen; möchte man seinen Benutzern auf die Finger schauen, stellt man einfach alle neuen Beiträge in die Moderationswarteschlange. Der offensichtliche Nachteil dieser Methode besteht im Verwaltungsaufwand, die Warteschlange kontinuierlich zu überwachen; bleiben legitime Beitäge dort zu lange hängen, wird man höchstwahrscheinlich den betreffenden Benutzer dauerhaft vergraulen.
- Beispiel: Neue Kommentare werden zunächst in eine Moderartions-Warteschlange gestellt (Abbildung)
Möglicherweise sinnvoll könnte auch ein Community-basierter Mechanismus sein, bei dem die Benutzer einer Drupal-Website gemeinsam darüber entscheiden, ob ein Beitrag eher wertvoll oder eher zu verwerfen ist; entsprechende Mechanismen nutzen beispielsweise die Websites Slashdot und Kuro5hin, Drupal kann das nach unserem bisherigen Kenntnisstand jedoch leider nicht.
Mißbrauch von Benutzeraccounts
Erlaubt man neuen Benutzern, eigene Accounts anzulegen und diese ohne Freischaltung durch einen Administrator zu nutzen (z.B. über das LoginToboggan-Modul), wird dies bereits nach kurzer Zeit von Spammern entdeckt und nach unseren Erfahrungen auch intensiver genutzt als durch reguläre Benutzer.
- Installieren eines Textimage- oder Captcha-Moduls - Auch hier kann man Spam-Bots wieder die Arbeit erschweren, indem man Captchas beim Anlegen von Benutzeraccounts oder sogar beim Login erzwingt. Die bereits beschriebenen Nebeneffekte sind auch hier zu erwarten.
- Erzwingen einer Authentifizierung der E-Mail-Adresse - Der sicherlich einfachste Weg besteht darin, Accounts grundsätzlich erst freizuschalten, nachdem die vom neu registrierten Benutzer angegebene E-Mail-Adresse verifiziert wurde. Die meisten Spammer nutzen nach unseren Erfahrungen Freemailer wie mail.ru und verfügen zwar über gültige Adressen, kümmern sich aber häufig nicht um die Bestätigung der Mail-Adresse - vermutlich nicht zuletzt, weil unsere Bestätigungs-Mails in deutscher Sprache verfasst sind; englischsprachige Websites dürfen hier wohl eher mit unerwünschtem "Feedback" rechnen. Der Nebeneffekt dieser Maßnahme besteht darin, dass der Mailserver bei konzertierten Spam-Attacken heißlaufen kann. Auch hier erfolgt dann wieder ein arbeitsintensives Wettrüsten, wenn man beispielsweise in Postfix die restrictions verschärft - all dies will konfiguriert, getestet und gewartet werden.
Mißbrauch der Trackback-Funktion
Jenseits der Kernfunktionen von Drupal haben sich in der Blogosphäre Trackbacks als unverzichtbares Instrument erwiesen, sich wechselseitig über neue Postings und Kommentare zu informieren; Trackbacks zählen - neben Blogrolls etc. - zu den Mitteln, die die Blogosphäre zusammenhält und zu mehr als der Summe ihrer Teile macht.
Natürlich haben auch dies die Spammer längst erkannt und widmen sich mit größter Penetranz Websites, die Trackbacks akzeptieren. Drupal-Anwender haben hier ein Problem, da die Trackback-Funktionalität nicht einmal im Drupal Core enthalten ist. Um Trackbacks nutzen zu können, muß das Trackback-Modul von installiert werden, das - wie alle 3rd-Party-Erweiterungen - potenziell inkompatibel ist zu anderen Drupal-Erweiterungen. Um nun wieder die Trackbacks zu schützen, ist ein weiteres 3rd-Party-Modul erforderlich, das Spam-Modul - was die möglichen Wechselwirkungen weiter potenziert. Will man unter Drupal Trackbacks zulassen, führt nach unserer Einschätzung allerdings kein Weg am Spam-Modul vorbei: Selbst auf neuen Drupal-Sites stellt sich binnen weniger Tage massiver Trackback-Spam ein, sobald man das Trackback-Modul aktiviert hat.
- Installieren des Spam-Moduls - Das Spam-Modul ist relativ komplex, daher erweist sich die Installation als etwas aufwändiger als gewohnt, sie ist - mit etwas Tüftelei - jedoch zu bewältigen. Das Modul enthält verschiedene Mechanismen zur Spam-Filterung, von denen sich bei uns der Bayesiansische Filter und der Keyword Filter als am nützlichsten erwiesen. Ein Großteil des eingehenden Spams kann damit recht zuverlässig automatisch gefiltert werden.
Die Probleme dieses Moduls liegen - zumindest in Drupal 4,6/4.7 - anderswo:
- die Wartung der Keyword-Listen ist zeitaufwändig,
- das Modul frisst enorm Systemressourcen,
- tendenziell nimmt die eingehende Spam-Menge nicht ab, sondern steigt eher deutlich an.
Wir hatten das Spam-Modul in einer älteren Version auf kefk.org über mehrere Monate zu laufen, als die Website noch relativ neu war. Der wöchentliche Verwaltungsaufwand lag zunächst bei etwa einer Stunde, während der die Keyword-Listen bzw. die regulären Ausdrücke ergänzt und modifiziert wurden. Wir beobachteten während dieser Testphase einen dramatisch ansteigenden Spam-Anteil; so kippte beispielsweise das Verhältnis zwischen relevanten Trackbacks und purem Spam binnen weniger Wochen auf über 100:1 (ein legitimer Trackback auf 100 Spam-Trackbacks), und das bei rapide steigender Tendenz. Wir hatten bis dahin zwar relativ ausgefeilte und umfangreiche Filterlisten aufgebaut, dafür stieg die Systembelastung durch das Modul auf inakzeptable Werte - der reguläre Betrieb wurde gestört. Verantwortlich ist dafür natürlich nicht primär das Spam-Modul, sondern die ungeheure kriminelle Energie der Website-Spammer, dennoch blieb uns keine andere Wahl, als hier letztlich das Spam-Modul und damit auch Trackbacks zu deaktivieren.
Eine kleine Beobachtung am Rande: Seit weit über einem Jahr sind Trackbacks auf kefk.org deaktiviert, dennoch füllen sich die Logfiles noch immer täglich mit Anforderungen von trackback/{nid} - Spammer scheinen also überhaupt nicht zu prüfen, ob ihr Werbekot überhaupt angenommen wird. Ab einer gewissen Menge dürften solche Aufrufe von nichtexistierenden Seiten auch den Webserver selbst zu belasten beginnen. Man sollte sich daher gut überlegen, ob man sich überhaupt auf Trackbacks einlassen möchte - anscheinend führt kein Weg zurück.
Ergänzung (Juli 2007): Das Spam-Modul wurde Anfang Juni in einer ersten Version für Drupal 5.x freigegeben; es muß nun nicht mehr zusätzliche Software installiert werden, da es sich jetzt um eine native Implementation handelt. Es könnte sich also lohnen, einen Blick auf diese neue Version zu werfen.
Ergänzung (August 2007): Die neue Version des Spam-Moduls lief jetzt einige Tage und brachte es fertig, die Systemlast des AMD-Doppelkernprozessors auf kontinuierlich 100% auf beiden Kernen hochzutreiben. Auch diese Version des Moduls ist also, zumindest wenn man reguläre Ausdrücke nutzen möchte, leider nicht für den Praxiseinsatz geeignet. Das Spam-Module und damit zwangsläufig uach das Trackbacks-Modul wurden daher wieder deaktiviert.
Monitoring
Um einen Überblick zu bekommen, was auf der eigenen Website überhaupt vor sich geht, ist kontinuierliches Monitoring zwingend erforderlich. Server-Logfiles des httpd oder der Watchdog von Drupal helfen hier leider nur bedingt weiter, außerdem gibt es keine zentrale "Sammelstelle", in der wirtklich alle Verändungen der Druapl-Site registriert wären. Wieder wird die Installation zusätzlicher Module erforderlich; folgende Mechanismen haben sich bewährt:
- Definieren eines "Tracker"-Views, der möglichst alle Aktivitäten anzeigt - Ein solcher View kann als Block eingebunden werden. Der Webmaster beommt dann zumindest einen ungefähren Einblick darüber, welche neuen Artikel gerade angelegt wurden.
- Installieren des Modr8-Moduls - Auch dieses Modul kann als Block eingebunden werden; es zeigt dann die Warteschlange mit allen dort auflaufenden Einträgen an, beispielsweise von Inhaltstypen, die automatisch in die Warteschlange gestellt werden oder von neuen Trackbacks.
- Aktivieren des Administration-Blocks - Dieser Block zeigt beispielsweise die Trackback queue und die Comment queue an; man kann die Beiträge dort einsehen und auch direkt löschen.
Für die jeweiligen Blöcke sollte man in den "rollenspezifischen Sichtbarkeitseinstellungen" konfigurieren, dass diese nur für bestimmte Benutzergruppen wie Administratoren/Sysops oder Moderatoren angezeigt werden.
Netmarks
Je offener eine Website gehalten wird, desto mehr lädt sie Besucher um Mitmachen ein; zu diesen Besuchern zählen heutzutage jedoch nicht nur interessierte Leser, potenzielle Co-Autoren und - bei Online-Shops - auch Kunden, sondern auch allerlei zwielichtige Gestalten, Cyberkriminelle, Trittbrettfahrer, Betrüger, antisoziale Elemente, unterbeschäftige Kinder und offensichtlich Geistesgestörte, die kommerziell motivierten Spam in Gästebüchern hinterlassen, Foren mit thematisch irrelevantem Müll füllen, offene Wikis als Schmierzettel mißbrauchen usw. Jede sinnvolle technische Innovation wie Trackbacks wird binnen kürzester Zeit mißbraucht, und dieser Mißbrauch übersteigt auch auf Websites - ebenso wie bei E-Mail - bei weitem die bestimmungsgemäße Nutzung - mit diesen Fakten muß man sich im heutigen Internet abfinden, auch im Internet sind die "guten alten Zeiten" leider vorbei.
Dem Spamschutz in Drupal kommt daher eine essentielle Bedeutung zu, da zugespammte Kommentar-Threads den Sinn dieser Annotationsfunktionen ad absurdum führen und sich der Website-Betreiber durch das bloße Zulassen illegaler Botschaften haft- und strafbar machen kann. Allerdings ist Drupal konzeptionell eher auf Offenheit und Kooperation denn auf Gefahrenabwehr im Sinne der berüchtigten "Internet-Verkehrssicherungspflicht" [# OLG München, Az. 21 U 1914/02, 15. März 2002; vgl. hierzu bspw. Mischa Dippelhofer, http://www.jurpc.de/aufsatz/20020304.htm (2002)] ausgelegt. Die Spamabwehr in Drupal ist daher zeit- und arbeitsaufwändig und belastet CPU und Arbeitsspeicher des Servers - zumindest so lange man seine Website halbwegs offen halten möchte.
Drupal ist mittlerweile verbreitet genug, dass die Cyberkriminellen ihre Skripte angepasst haben; von wenigen Ausnahmen abgesehen ist daher davon auszugehen, das Kommentar- und Trackback-Spam nicht von Menschen gepostet wird, sondern einfach im Batchbetrieb durch Bots verstreut wird; viele momentan funktionierende Schutzmaßnahmen basieren daher schlicht und ergreifend darauf, Aktivitäten von nichtmenschlichen Benutzern zu unterbinden. Da die Cyberkriminellen ihre Sktipte permanent anpassen, läuft das auf ein wechselseitiges Hochrüsten hinaus, das letztlich in den meisten Fällen auf ein weitestgehendes Deaktivieren interaktiver Elemente hinausläuft.
Contents
|
Missbrauch der Community-Funktionen
Das Haupteinfallstor für Spam bilden in Drupal - zumindest nach unseren Erfahrungen - die Community-Kernfunktionen; erlaubt man anonymen Benutzern das Erstellen oder Bearbeiten von Seiten oder das Anlegen von Kommentaren, wird man mit einiger Sicherheit bereits wenige Wochen nach dem Launch der Website mit ersten Spam-Beiträgen konfrontiert sein.
Nach unseren Erfahrungen gibt es hier vor allem drei Schutzmechanismen:
- Umschalten der Standard-Aktion von "Speichern" auf "Vorschau" - Neue Beiträge müssen dann zunächst als Preview betrachtet werden und können erst danach gespeichert werden. Die meisten Spam-Skripte sind derzeit noch nicht in der Lage, dies zu erkennen. Leider scheinen auch viele echte Benutzer von solchen Maßnahmen überfordert zu sein, jedenfalls stellten wir nach Aktivieren der entsprechenden Funktion einen deutlichen Rückgang von (themenbezogenen und konstruktiven) Kommentaren fest.
- Installieren eines Textimage- oder Captcha-Moduls - Vor dem Absenden von Daten muß der Benutzer hier zusätzlich eine Art "Menschlichkeitsprüfung" ablegen und Zeichenkombinationen aus einem Bild herauslesen oder eine kleine Rechenaufgabe lösen; der Beitrag wird erst gespeichert, wenn ihm das gelungen ist. Wie alle Drupal-Module können sich solche Erweiterungen kontraproduktiv auf die Systemstabilität auswirken, da nicht alle Captcha-Module zuverlässig arbeiten; weiterhin wird man zusätzliche, vor allem nicht-technische Benutzerschichten verlieren und schmeist prinzipbedingt alle Accessibility-Bemühungen über Bord. Auch hier haben die Web-Spammer längst nachgerüstet und ihre Skripte mit OCR-Funktionen versehen, man muß also regelmäßig die Komplexität von Textimages erhöhen. Wir verwenden das Captcha-Modul, das uns recht brauchbar erscheint, während bei uns Alternativen wie das Text Image-Modul zu fehlerträchtig arbeiteten.
- Zugriffsberechtigungen für anonyme Benutzer entziehen - In Drupal kann man unter admin/user/access zumindest partiell den Zugriff auf Community-Funktionen erschweren; beispielsweise kann das Anlagen aller Standard-Inhaltstypen aus Drupal Core für anonyme Benutzer gesperrt werden. Natürlich werden hier weitere legitime Benutzerschichten verloren gehen, außerdem wird die Anzahl von illegitimen Benutzerregistrierungen zunehmen.
Der vierte Schutzmechanismus setzt manuelle Arbeit und damit kontinuierliche Überwachung der Website voraus: Man konfiguriert Drupal, so weit dies möglich ist, dahingehend dass Inhalte grundsätzlich erst nach Freigabe durch einen Administrator oder Moderator veröffentlicht werden:
- Moderations-Warteschlange - In der der Inhaltstypen-Verwaltung (admin/content/types) kann man für jeden Inhaltstyp eine Standardoption einstellen; möchte man seinen Benutzern auf die Finger schauen, stellt man einfach alle neuen Beiträge in die Moderationswarteschlange. Der offensichtliche Nachteil dieser Methode besteht im Verwaltungsaufwand, die Warteschlange kontinuierlich zu überwachen; bleiben legitime Beitäge dort zu lange hängen, wird man höchstwahrscheinlich den betreffenden Benutzer dauerhaft vergraulen.
- Beispiel: Neue Kommentare werden zunächst in eine Moderartions-Warteschlange gestellt (Abbildung)
Möglicherweise sinnvoll könnte auch ein Community-basierter Mechanismus sein, bei dem die Benutzer einer Drupal-Website gemeinsam darüber entscheiden, ob ein Beitrag eher wertvoll oder eher zu verwerfen ist; entsprechende Mechanismen nutzen beispielsweise die Websites Slashdot und Kuro5hin, Drupal kann das nach unserem bisherigen Kenntnisstand jedoch leider nicht.
Mißbrauch von Benutzeraccounts
Erlaubt man neuen Benutzern, eigene Accounts anzulegen und diese ohne Freischaltung durch einen Administrator zu nutzen (z.B. über das LoginToboggan-Modul), wird dies bereits nach kurzer Zeit von Spammern entdeckt und nach unseren Erfahrungen auch intensiver genutzt als durch reguläre Benutzer.
- Installieren eines Textimage- oder Captcha-Moduls - Auch hier kann man Spam-Bots wieder die Arbeit erschweren, indem man Captchas beim Anlegen von Benutzeraccounts oder sogar beim Login erzwingt. Die bereits beschriebenen Nebeneffekte sind auch hier zu erwarten.
- Erzwingen einer Authentifizierung der E-Mail-Adresse - Der sicherlich einfachste Weg besteht darin, Accounts grundsätzlich erst freizuschalten, nachdem die vom neu registrierten Benutzer angegebene E-Mail-Adresse verifiziert wurde. Die meisten Spammer nutzen nach unseren Erfahrungen Freemailer wie mail.ru und verfügen zwar über gültige Adressen, kümmern sich aber häufig nicht um die Bestätigung der Mail-Adresse - vermutlich nicht zuletzt, weil unsere Bestätigungs-Mails in deutscher Sprache verfasst sind; englischsprachige Websites dürfen hier wohl eher mit unerwünschtem "Feedback" rechnen. Der Nebeneffekt dieser Maßnahme besteht darin, dass der Mailserver bei konzertierten Spam-Attacken heißlaufen kann. Auch hier erfolgt dann wieder ein arbeitsintensives Wettrüsten, wenn man beispielsweise in Postfix die restrictions verschärft - all dies will konfiguriert, getestet und gewartet werden.
Mißbrauch der Trackback-Funktion
Jenseits der Kernfunktionen von Drupal haben sich in der Blogosphäre Trackbacks als unverzichtbares Instrument erwiesen, sich wechselseitig über neue Postings und Kommentare zu informieren; Trackbacks zählen - neben Blogrolls etc. - zu den Mitteln, die die Blogosphäre zusammenhält und zu mehr als der Summe ihrer Teile macht.
Natürlich haben auch dies die Spammer längst erkannt und widmen sich mit größter Penetranz Websites, die Trackbacks akzeptieren. Drupal-Anwender haben hier ein Problem, da die Trackback-Funktionalität nicht einmal im Drupal Core enthalten ist. Um Trackbacks nutzen zu können, muß das Trackback-Modul von installiert werden, das - wie alle 3rd-Party-Erweiterungen - potenziell inkompatibel ist zu anderen Drupal-Erweiterungen. Um nun wieder die Trackbacks zu schützen, ist ein weiteres 3rd-Party-Modul erforderlich, das Spam-Modul - was die möglichen Wechselwirkungen weiter potenziert. Will man unter Drupal Trackbacks zulassen, führt nach unserer Einschätzung allerdings kein Weg am Spam-Modul vorbei: Selbst auf neuen Drupal-Sites stellt sich binnen weniger Tage massiver Trackback-Spam ein, sobald man das Trackback-Modul aktiviert hat.
- Installieren des Spam-Moduls - Das Spam-Modul ist relativ komplex, daher erweist sich die Installation als etwas aufwändiger als gewohnt, sie ist - mit etwas Tüftelei - jedoch zu bewältigen. Das Modul enthält verschiedene Mechanismen zur Spam-Filterung, von denen sich bei uns der Bayesiansische Filter und der Keyword Filter als am nützlichsten erwiesen. Ein Großteil des eingehenden Spams kann damit recht zuverlässig automatisch gefiltert werden.
Die Probleme dieses Moduls liegen - zumindest in Drupal 4,6/4.7 - anderswo:
- die Wartung der Keyword-Listen ist zeitaufwändig,
- das Modul frisst enorm Systemressourcen,
- tendenziell nimmt die eingehende Spam-Menge nicht ab, sondern steigt eher deutlich an.
Wir hatten das Spam-Modul in einer älteren Version auf kefk.org über mehrere Monate zu laufen, als die Website noch relativ neu war. Der wöchentliche Verwaltungsaufwand lag zunächst bei etwa einer Stunde, während der die Keyword-Listen bzw. die regulären Ausdrücke ergänzt und modifiziert wurden. Wir beobachteten während dieser Testphase einen dramatisch ansteigenden Spam-Anteil; so kippte beispielsweise das Verhältnis zwischen relevanten Trackbacks und purem Spam binnen weniger Wochen auf über 100:1 (ein legitimer Trackback auf 100 Spam-Trackbacks), und das bei rapide steigender Tendenz. Wir hatten bis dahin zwar relativ ausgefeilte und umfangreiche Filterlisten aufgebaut, dafür stieg die Systembelastung durch das Modul auf inakzeptable Werte - der reguläre Betrieb wurde gestört. Verantwortlich ist dafür natürlich nicht primär das Spam-Modul, sondern die ungeheure kriminelle Energie der Website-Spammer, dennoch blieb uns keine andere Wahl, als hier letztlich das Spam-Modul und damit auch Trackbacks zu deaktivieren.
Eine kleine Beobachtung am Rande: Seit weit über einem Jahr sind Trackbacks auf kefk.org deaktiviert, dennoch füllen sich die Logfiles noch immer täglich mit Anforderungen von trackback/{nid} - Spammer scheinen also überhaupt nicht zu prüfen, ob ihr Werbekot überhaupt angenommen wird. Ab einer gewissen Menge dürften solche Aufrufe von nichtexistierenden Seiten auch den Webserver selbst zu belasten beginnen. Man sollte sich daher gut überlegen, ob man sich überhaupt auf Trackbacks einlassen möchte - anscheinend führt kein Weg zurück.
Ergänzung (Juli 2007): Das Spam-Modul wurde Anfang Juni in einer ersten Version für Drupal 5.x freigegeben; es muß nun nicht mehr zusätzliche Software installiert werden, da es sich jetzt um eine native Implementation handelt. Es könnte sich also lohnen, einen Blick auf diese neue Version zu werfen.
Ergänzung (August 2007): Die neue Version des Spam-Moduls lief jetzt einige Tage und brachte es fertig, die Systemlast des AMD-Doppelkernprozessors auf kontinuierlich 100% auf beiden Kernen hochzutreiben. Auch diese Version des Moduls ist also, zumindest wenn man reguläre Ausdrücke nutzen möchte, leider nicht für den Praxiseinsatz geeignet. Das Spam-Module und damit zwangsläufig uach das Trackbacks-Modul wurden daher wieder deaktiviert.
Monitoring
Um einen Überblick zu bekommen, was auf der eigenen Website überhaupt vor sich geht, ist kontinuierliches Monitoring zwingend erforderlich. Server-Logfiles des httpd oder der Watchdog von Drupal helfen hier leider nur bedingt weiter, außerdem gibt es keine zentrale "Sammelstelle", in der wirtklich alle Verändungen der Druapl-Site registriert wären. Wieder wird die Installation zusätzlicher Module erforderlich; folgende Mechanismen haben sich bewährt:
- Definieren eines "Tracker"-Views, der möglichst alle Aktivitäten anzeigt - Ein solcher View kann als Block eingebunden werden. Der Webmaster beommt dann zumindest einen ungefähren Einblick darüber, welche neuen Artikel gerade angelegt wurden.
- Installieren des Modr8-Moduls - Auch dieses Modul kann als Block eingebunden werden; es zeigt dann die Warteschlange mit allen dort auflaufenden Einträgen an, beispielsweise von Inhaltstypen, die automatisch in die Warteschlange gestellt werden oder von neuen Trackbacks.
- Aktivieren des Administration-Blocks - Dieser Block zeigt beispielsweise die Trackback queue und die Comment queue an; man kann die Beiträge dort einsehen und auch direkt löschen.
Für die jeweiligen Blöcke sollte man in den "rollenspezifischen Sichtbarkeitseinstellungen" konfigurieren, dass diese nur für bestimmte Benutzergruppen wie Administratoren/Sysops oder Moderatoren angezeigt werden.
