RSS-Feed für dieses Schlagwort (Tag)Schlagwort-Archiv:

WordPress

Limitiertes Login

Login Angeregt durch die neuerliche Erwähnung des WordPress-Plugins Limit Login Attempts – das auch bei der empfohlenen Änderung des Login-Namens durchaus sinnvoll ist, um es Möchtegern-Hackern schwerer zu machen – bei Sascha und dem Kommentar von Sylvi dort hab ich mal wieder in die Statistik des Plugins reingeschaut, wo aufgezeichnet wird, wie oft welche IP-Adresse mit welchem versuchten Loginnamen ausgesperrt wurde.

Ich weiß nicht genau, seit wann ich dieses Plugin installiert habe; die erste Mail über zu viele gescheiterte Login-Versuche, die ich in meinem Archiv gefunden habe, datiert jedenfalls vom März 2011. Wie dem auch sei, meine Limit-Login-Attempts-Statistik für dieses Blog sieht so aus:

  • „Admin“ 126x (max. 12 vom selben) von 55 IP-Adressen
  • „admin“ 427x (max. 32) von 212 IPs
  • „wp_admin“ 5x von 1 IP
  • „administrator“ 1x
  • „adm“ 2x von 2 IPs, einer davon hat auch „manager“ und „test“ versucht
  • „cimddwc“ 6x von 6 IPs

Ganz schön viele – jetzt stelle man sich mal vor, wie frei Möchtegern-Login-Hacker unzählige Passwörter ausprobieren können, wenn man noch „admin“ als Loginnamen und kein Plugin wie Limit Login Attempts laufen hat…

Der mit den 32 Lockouts mit „admin“ hat’s auch mit „wieder“, „numerologie“, „maria“ und „472“ versucht – warum auch immer. Wird wohl ein Bot gewesen sein, der diese Wörter gefunden und halt diesen Herbst mal ausprobiert hat. Die IP-Adresse gehört wohl einem Server in den Niederlanden und hat sich nun einen Eintrag in meiner .htaccess1 verdient, damit er sich gar nicht mehr bemühen muss…

Tja, und dann war da noch ein Texaner, der hat’s damit versucht:

Hawementynota

Offenbar kein gültiges Wort. Ob der sich im Blog geirrt hat und sich eigentlich bei sich einloggen wollte, wo er dies als Loginnamen hat? Oder warum sollte ein Hacker sowas versuchen?

 


  1. order allow,deny
    deny from 5.39.218.136

    …ggf. weitere…
    allow from all []

Links und Video der Woche (2011/9)

Links und Video der Woche (2011/7)

Akismet vs. Antispam Bee

Was macht der Blogger gegen Kommentarspammer? Meist Antispam-Plugins verwenden natürlich. Ein lange Zeit sehr beliebtes ist Akismet, das aber nicht ganz unproblematisch ist: So gibt es Datenschutzbedenken, weil alle Daten, die der Kommentator eingegeben hat, samt IP-Adresse an Akismets amerikanische Server übertragen werden – die diese dann bewerten und mit bekannten Spammern abgleichen, so funktioniert Akismet eben.

Ein Vorteil davon ist, dass auch manuelle Kommentarspammer so erfasst werden können (wenn sie nicht zu neu oder zu abwechslungsreich sind=, ein Nachteil, dass auch Unschuldige im Spam landen können (false positives), was auf meinem Blog ein paar Mal pro Monat vorkam – was für den Kommentator unschön ist, insbesondere weil er standardmäßig nur eine Seite ohne seinen Kommentar geliefert bekommt (wogegen ich letztes Jahr eine entsprechende Lösung eingebaut hatte), was alle ohne Akismet-Erfahrung verwirren könnte. Und wenn der Blogger zu selten oder zu unaufmerksam in seinen Spam-Ordner schaut, kommt der eigentlich gute Kommentar nie ans Tageslicht – und je öfter das vorkommt, umso mehr hält Akismet den Kommentator für einen Spammer. Thomas hat gestern auch darüber geschrieben.

Ein weiteres Problem mit aktuelleren Versionen von Akismet ist/war, dass die wp_commentmeta-Tabelle mit u.U. Tausenden Einträgen zugemüllt wurde, in der das Plugin den Status der Spam-Abfrage für jeden Kommentar einträgt und selbst bei bereits gelöschten Spams nicht entfernte; letzteres müsste in der neuesten Version 2.5.3 aber behoben sein.

Ach ja, und Diskussionen über eine eventuelle Gebührenpflicht gab’s auch – zumindest Neu-Benutzer, die noch keinen API-Key haben, dürften auf diese Frage stoßen.

Wegen all dieser Dinge hatte ich mich nach einer Alternative umgesehen – d.h. eigentlich nicht groß umgesehen, denn Antispam Bee ist ja eh schon in fast aller Munde. Und die Biene macht ihren Job ganz ohne Inhaltsvergleiche auf einem Server sehr gut. Sie kann auch optional rein anhand der IP-Adresse mithilfe externer Dienste bestimmte Länder oder bekannte Spammer aussperren – was ich hier aber (noch?) nicht aktiviert habe. Deswegen erwischt sie manuelle Kommentarspammer aber nicht so gut, sodass man mitunter solche false negatives selbst löschen muss.

Vor ziemlich genau drei Wochen hab ich Antispam Bee installiert und hatte in dieser Zeit sieben solche nicht geblockten Spams (von fünf „Kommentatoren“). Vielleicht ein Grund, auch mal die angesprochenen IP-Prüfungen zu testen… Auf jeden Fall gab’s auch keinen false positive, und die automatischen Spams wurden sehr zuverlässig geblockt – ich bin also mit der Biene zufrieden und werde sie behalten.

Ich denke dann auch, ich kann nach der Testphase die Spams auch gleich löschen lassen, ohne dass die Biene sie in den Spam-Ordner schickt; dann wären dort nur solche, die wegen meiner Einträge in die WordPress-eigene Blacklist dort landen, was die Sache auch übersichtlicher macht (falls das mal vorkommt – ist selten, aber vorgestern hab ich dort z.B. eine IP einer (mutmaßlichen) Schule, von der eine Schulklasse hier blödel­chatten wollte, eingetragen…).

Aber ein Problem muss ich noch ansprechen:

Antispam Bee und Ajax Comment Preview

Nun besteht ein wesentlicher Punkt in der Spam-Bot-Abwehr der Biene darin, den Namen des Kommentarfeldes zu ändern – es heißt nicht mehr comment, sondern hat eine blogspezifische Zahl angehängt bekommen. (Die ID ist gleich geblieben, lässt sich also mit CSS wie sonst auch ansprechen.) Dadurch mag die Kommentar­vorschau­funktion von Ajax Comment Preview aber nicht mehr1 – es sei denn, man ändert ein bisschen in dessen JavaScript-Code. Meine Lösung mag nicht die eleganteste sein – insb. weil sie an jedes Blog angepasst sein muss –, aber sie funktioniert:

Man ersetze in ajax-comment-preview.js in der Funktion send diese drei Zeilen:

if ( !t.data.comment || t.oldData == $.param( t.data ) ) {
    return false; // Blank || Last AJAX request was the same, so bail on this one.
}

– sie befinden sich ab Zeile 28 direkt vor dem großen weit eingerückten Block, der mit jQuery.post beginnt – durch diese:

if (t.oldData == $.param( t.data )) { return false; } // Last AJAX request was the same, so bail on this one.
if (t.data['comment-12345']) t.data.comment = t.data['comment-12345']; //--ag fuer Antispam Bee
if ( !t.data.comment ) { return false; } // Blank

Wobei ihr die gelb hinterlegte Zahl 12345 an beiden Stellen durch die bei eurem Blog verwendete ersetzen müsst – diese findet ihr ganz einfach im Quelltext (oder mit FireBug o.ä.) einer Seite mit Kommentarfeld raus, sucht dort am besten nach einer textarea mit name="comment-, das sollte in den meisten Themes reichen. (Und wenn’s dann noch nicht gleich funktioniert, dran denken, die Seite im Browser explizit neu zu laden, damit das neue JavaScript auch geladen wird.)

So, gibt’s noch Fragen, Anregungen und sonstige Meinungen zu meinem Code oder zu den Plugings allgemein? Nur raus damit, die Chance, dass ihr fälschlicherweise im Spam landet, sind geringer als früher.^^

 


  1. und andere Ajax-Plugins können auch Probleme haben []

Links und Videos der Woche (2011/5)

 

 

Nachtrag: Zum Tod von Gary Moore: