Beiträge von Nachtwaechter

    Eben habe ich die Meldung in meiner Feedkost gehabt.

    Zitat

    Das nächste, was wir anbieten, ist bbPress 2.0, Beta 1 – die erste öffentliche bbPress-Version, die ein Plugin für ihre selbstgehostete, mit WordPress betriebene Website ist. (…) bbPress ist nach wie vor in aktiver Entwicklung, und wir können ihnen nicht empfehlen, dass sie es [in dieser Beta-Version, meine Anmerkung] auf einer Produktionssite laufen lassen. (…) Wir planen, bbPress 2.0 Ende Juni zu veröffentlichen, damit es mit der Veröffentlichung von WordPress 3.2 zusammenfällt. Das tatsächliche Veröffentlichungsdatum hat etwas von einem »beweglichen Ziel«, abhängig davon, wie sich die beiden Beta-Versionen entwickeln. Je mehr Hilfe wir dadurch bekommen, dass getestet wird und dass Fehler behoben werden, desto früher wird die endgültige Version geliefert. (…)

    Die Beta 1 steht bereits zum Download -- jetzt natürlich als WordPress-Plugin in der Plugin Database.

    Nein, das mit dem falschen Sommerzeit/Winterzeit-Text ist kein Fehler in der Sprachdatei, sondern ein Fehler im bbPress-Code. Ich habe damals leider versäumt, ein Ticket im Trac aufzumachen, weil ich viel um die Ohren hatte -- tja, und dann wars ein reines Darstellungsproblem im Backend, so dass ich es wieder vergaß.

    Aber ein bisschen erstaunlich finde ich es schon, dass in gut anderthalb Jahren niemand anders diesen Fehler bemerkt zu haben scheint. Er scheint also im Zusammenhang mit der Verwendung einer Sprachdatei zu stehen, denn alle aktiven Entwickler verwenden die englische Version.

    Das Akismet-Plugin für WordPress ist wie russisches Roulette, wenn man sein Blog in Deutschland betreibt. Die nächste Abmahnwelle kommt bestimmt, und viele, die arglos ein bewährtes Plugin verwendet haben, werden sich wundern.

    Aber für WordPress gibt es immerhin Abhilfe (siehe oben verlinkten Beitrag).

    Das Akismet-Plugin für bbPress zieht die gleichen juristischen Unwägbarkeiten nach sich. Wer keine Lust darauf hat, dass an seinem Internet-Projekt der Sachverhalt mal vor einem Gericht geklärt wird -- das kann richtig teuer werden -- sollte sich nach Alternativen umschauen oder sich eine Strategie einfallen lassen, wie man leidlich rechtssicher mit dieser Situation umgehen kann.

    Das Folgende ist auf die Schnelle zusammengeschrieben und sollte gegebenenfalls ergänzt oder korrigiert werden.

    Möglichkeit Eins -- Alternative Plugins

    Es gibt nicht viele geeignete Plugins für bbPress.

    Human Test for bbPress kann so konfiguriert werden, dass die einfache Additionsaufgabe auch beim Posten gelöst werden muss. Hierfür ist es erforderlich, im Quelltext zu editieren.

    Project Honey Pot for bbPress kommt mit dem gleichen Problem daher, dass eine IP-Adresse an einem anderen Server gesendet wird.

    reCAPTCHA for bbPress könnte ebenfalls problematisch werden, da hier ein Google-Dienst verwendet wird und die Datenspeicherung auf Seiten Googles nicht gerade ein Musterbeispiel von Transparenz ist. Es sollte aber möglich sein.

    Clickcha ist einmal eine etwas andere Form eines Captchas, hier muss an die richtige Stelle geklickt werden. Es ersetzt den Submit-Button. Nachteil: Blinde werden ausgesperrt.

    Drei der Plugins sind also Captchas, die vom Forennutzer eine zusätzliche Interaktion fordern, was als störend empfunden werden kann. Und Project Honey Pot könnte zu vergleichbaren juristischen Problemen führen.

    Möglichkeit Zwei -- Nutzungsbedingungen

    Die zweite Möglichkeit ist, dass zusammen mit der Anmeldung ans Forum Nutzungsbedingungen vereinbart werden, denen der neue User zustimmt.

    Eventuell lässt sich das recht betagte Terms-of-Service-Plugin von _ck_ verwenden, ich habe es aber nicht getestet. In jedem Fall müssten darin die Text gegen deutsche Texte ersetzt werden, und natürlich sollte dabei auch gleich auf die Datenschutzerklärung fürs Forum hingewiesen werden. (Noch so ein Minenfeld...)

    In die Hinweise könnte etwa der folgende Text aufgenommen werden. (Fur Project Honey Pot anzupassen.)

    Sie erklären sich durch ihre Registrierung in dieser Foren-Site damit einverstanden, dass bei ihrer Nutzung des Forums Daten an den Anti-Spam-Dienst Akismet übermittelt werden, um sie gegen die Muster in typischer Spam abzugleichen und Spambeiträge zu erkennen. Dabei wird neben ihrem Posting auch ihre IP-Adresse übermittelt. Wenn sie mit diesem Vorgehen nicht einverstanden sind, sehen sie von einer Registrierung ab.

    Ich bin kein Rechtsanwalt und weiß deshalb nicht, ob so eine Vereinbarung im Zusammenhang der Registrierung bereits hinreichend ist.

    Als Problem bleibt in jedem Fall bestehen, dass eine derartige Vereinbarung nicht mit den bereits registrierten Usern getroffen wurde. Diese sind in anderer Form zu unterrichten -- und das Zusenden einer E-Mail kann ebenfalls problematisch werden, wenn nicht zuvor explizit ein Einverständnis in den Empfang von E-Mails gegeben wurde.

    Der sicherste Weg ist es von daher, entsprechende Hinweistexte in den Theme-Dateien von bbPress unterzubringen, was am besten geht, wenn man ein eigenes Theme verwendet. Das Formular zum Verfassen des Posts findet sich in post-form.php, das Formular für die Registrierung in register.php -- und die Texte sollten am sicherstens zwischen Eingabefeldern und Submit-Button liegen, nicht darunter, damit sie nicht leicht übersehen werden können.

    Ein möglichler Kandidat für Probleme sind noch die Datei-Zugriffsrechte des Ordners "my-languages" und natürlich der Sprachdatei. Der Ordner muss mit den Rechten des Webservers lesbar und auflistbar sein, die Sprachdatei muss mit den Rechten des Webservers lesbar sein.

    Wenn der Webserver unter einem technischen Benutzer wie "www-data" (oder das jeweilige Äquivlent unter dem verwendeten Linux oder Unix) läuft, sollte dem Ordner also ein chmod 755 und der Sprachdatei ein chmod 644 gegeben werden. Wie das geht, steht in der Dokumentation des verwendeten FTP-Clients.

    (Das mit den Zugriffsrechten ist selbst mir mal passiert, und ich habe viel zu lange an anderen Stellen nach dem Fehler gesucht...)

    derElch: Kein Sorge, die andere Seite der langsamen Release-Zyklen ist es, dass bbPress anderthalb Jahre lang kein ernsthaftes Security-Problem hatte. Die dort beschriebene Lücke ist mit der 1.0.3-Release gefixt.

    Bedenklich ists allerdings, dass es vom Fix in der Entwicklerversion bis zur Veröffentlichung einer Release mit dem Fix zwei Monate gedauert hat. Das lässt - zusammen mit der Kommunikationskultur auf Seiten der bbPress-Entwickler - nicht viel Gutes für die Zukunft ahnen, vielleicht wird es aber auch besser. Die 1.0.3 kann jedoch als robust und sicher betrachtet werden, und wenn in ein paar Wochen bbPress 1.1 veröffentlicht wird, ist auch niemand zu einem schnellen Upgrade gezwungen, der nicht gerade eines der neuen Features dringend benötigt. Tatsächlich könnte es für viele bbPress-Anwender eine gute Idee sein, erst einen Monat abzuwarten und zu schauen, wie sich die Dinge entwickeln, denn einige Probleme zeigen sich eben nur, wenn die Software im echten Einsatz auf realen Sites ist.

    Auf der anderen Seite: Wenn alle so denken, gibt es gar keine Entwicklung mehr - und das will doch auch niemand. ;)

    Ein fröhliches Hallo, wemaflo,

    natürlich kannst du, hast auch schon eine Mail von mir. Nur mein Engagement ist beendet. Aber was ich veröffentlicht habe, das ist veröffentlicht...

    (Und bbPress ist in meinen Augen eine gute Software, wenns auch manchmal... ach, das kennen wir ja alle.)

    WPMU geht und wird offiziell unterstützt. BuddyPress ist in seinem Kern WPMU, aber die Details möchte ich lieber richtigen BuddyPress-Experten überlassen.

    Der Code von bbPress ist völlig getrennt von der WP-, WPMU- oder BuddyPress-Installation, es werden lediglich die Benutzerdaten in der Datenbank gemeinsam verwaltet und es gibt einen gemeinsamen Login für die beiden Systeme. Etwas mehr habe ich an anderer Stelle geschrieben -- und hoffentlich auch deutlich genug gewarnt.

    Hihi, darüber könnte man glatt ein neues Thema aufmachen. Ich mag bbPress gerade für seine Schlichtheit, aber es ist nicht für jeden Anwendungsfall geeignet, insbesondere nicht, wenn man damit eine "Community" im modernen Sinn des Wortes aufbauen will. Aber ich sehe schon vor mir, wie sich das Ding in BuddyPress entwickeln wird, wenn das "bb" irgendwann nur noch für "Bloat Bloat" steht -- und es mit der Schlichtheit, die ich so schätze, schnell wieder vorbei ist...

    Ich glaube, ich werde denn zu jener Minderheit gehören, die dem ollen bbPress wirklich nachtrauert.

    So weit ich informiert bin, wird bbpress zum festen Bestandteil von BuddyPress werden und damit wohl auch "offizielle" Unterstützung bekommen. (Im Moment ist die Weiterentwicklung bei bbPress ein bisschen schleppend). Von daher würde ich, wenn nicht gerade ganz dringender Bedarf nach einem Forum besteht, eher davon abraten -- oder einfach schon einmal ein bbPress aufsetzen und das Forum irgendwie anders reinfummeln...

    Zum Einen hast du eine Action für das Publizieren eines neuen Posts registriert. Diese wird erst bei der Veröffentlichung eines neuen Blogbeitrages angestoßen. Aber so, wie es hier gemacht ist, jedes Mal, wenn ein neuer Blogeintrag geschrieben wird, so dass es schnell zu einer enormen Fülle an Seiten käme...

    Zum anderen (aber da bin ich mir nicht völlig sicher, und ich habe auch gerade die Quelltexte von WP nicht vor Augen) müsste post_status auf "published" statt auf "publish" stehen. Aber wie gesagt, da bin ich mir nicht völlig sicher...

    Zur leichten Offtopic-Frage, was dieses WPStats überhaupt tut, kann ich ein bisschen Aufklärung geben.

    WPStats fügt eine Aktion für den Footer des Blogs hinzu. Wenn der Leser am Blog angemeldet ist, wird nichts getan. Ansonsten wird ein Stück JavaScript von stats.wordpress.com nachgeladen.

    Das JavaScript trägt den Namen e-YYYYWW.js. Dabei steht YYYY für das Jahr, WW für die Woche, in der die Seite im WordPress-Blog erzeugt wurde. Warum die das so machen, weiß ich nicht genau, aber ich vermute, dass man auf diese Weise Zählungen aus dem Google-Cache oder aus web.archive.org verhindern will.

    In diesem JavaScript wird dann eine Funktion aufgerufen, die eine kleine GIF-Grafik nachlädt. Dabei wird zur WordPress übertragen, welcher Blogeintrag angezeigt wird, welche Hostname in der Adresszeile steht und was der Referer ist. Um das Laden dieser Grafik auch bei Browsern zu erzwingen, die immer den Cache benutzen, wird als weiterer Parameter eine Zufallszahl angehängt, die sich jedes Mal ändern dürfte.

    Daraufhin wird eine Funktion aufgerufen, die für jeden Link im angezeigten Dokument ein paar Aktionen hinzufügt, an Hand derer getrackt werden kann, wie der Surfer sich durch die Seite bewegt. Dabei werden auch Verweise auf externe Seiten getrackt.

    Es gibt keine Übertragung für Formulareingaben. Nur für Links.

    Inwieweit diese Daten bei WordPress.com gespeichert werden, ist unklar. Hierzu müsste WordPress.com eine Ansage machen, woran ich ehrlich gesagt nicht glaube.

    Natürlich können diesen Angaben auf Seiten von WordPress noch weitere Dinge hinzugefügt werden, nämlich die IP-Adresse des Surfers, die Uhrzeit des Zugriffs und eventuell (ich habe das nicht untersucht) ein Cookie, um Besucher zu identifizieren. Ich habe jedenfalls keine Cookies von stats.wordpress.com, aber ich surfe auch mit geradezu paranoider Filterung meines Netzverkehrs.

    @ Nachtwächter:

    Wenn ich dich richtig verstanden habe, tritt das Problem bei Blogs auf, die "gekapert" wurden.

    Das gilt für die Blogs, die ein Verzeichnis wp-content/1 enthalten, die wurden gekapert. Die gegenwärtige Trackback-Flut soll diese gekaperten Blogs verlinken. Das Schlimme an diesen Trackbacks war, dass Akismet sie nicht als Spam erkannt hat. Deshalb habe ich empfohlen, die Zeichenkette wp-content/1 in die Blacklist aufzunehmen.


    Ich habe meine Wordpressversionen auf blogpartei stets noch am selben Tag geupdatet (...)

    Über welches Einfallstor diese Angriffe erfolgen, ist zurzeit noch völlig unbekannt. Sie betreffen bis WP 2.2.3 auch die jeweils aktuellsten WP-Versionen. Das ist es ja, was diese von langer Hand vorbereitete Attacke so schlimm macht.

    Alles gelöscht und gedacht, die Sache sei ausgesessen...

    Auf alle Fälle solltest du noch zwei weitere Dinge tun. Wenn es dir möglich ist, lösche den Account "admin", indem du vorher einen anderen Account für einen Administrator anlegst, dich als dieser einloggst und damit den "admin" löschst. Und. Ändere alle Passwörter, denn es ist möglich, dass die Angreifer die Passwörter einsehen konnten.

    Ganz viel Text dazu habe ich hier geschrieben: Aktuelle Angriffe auf WordPress-Blogs bei Unser täglich Spam

    Doch nach meinem Update auf 2.5 kommen so dermaßen massenhaft Spams bei mir rein, dass ich im Moment alle Minute einen Spamtrackback á la groups.google.com etc. aus der Moderation löschen kann.

    Die Masche mit den Google Groups ist leider schon etwas älter und die Trackback-Spam für diese Malware-Schleudern ist seit Wochen massiv. Auch dazu habe ich mal etwas geschrieben:
    Click here to see video bei Unser täglich Spam

    Wenn Akismet regelmäßig oder häufig versagt, kann man sich behelfen, indem man "groups.google" in die Kommentar-Blacklist übernimmt, so wird wenigstens nicht das eigene Blog zu einem Hilfsmittel für Kriminelle.

    Was tun? Einfach abwarten und hoffen, dass Askimet bald updatet?

    Ich habe auch mal das „wp-content/1“ gesperrt, auch wenn das bei mir NICHT im Trackback steht.

    Ich schätze, dass Akismet bereits auf meine Meldung reagiert hat, aber ich werde mich angesichts des Trackback-Aufkommens hüten, die Zeile aus meiner Blacklist rauszunehmen. Leider wurde mir bis jetzt keine Antwort gemailt. Das muss aber nichts bedeuten, denn ich glaube, dass man dort heute einen ganz besonders schlechten und arbeitsreichen Tag hat. Dieser Trackback-Angriff ist nämlich verheerend wirksam.

    Als Ergänzung: Die Trackbacks nehmen immer dann massiv zu, wenn ich frisch gepostet habe. Ob einer meiner 3 Pings gekapert ist?
    http://rpc.pingomatic.com/
    http://ping.wordblog.de/
    http://rpc.technorati.com/rpc/ping

    Ich hab ja keine Ahnung, ob sowas technisch möglich ist, aber vielleicht fangen die den Ping ab und dann gehts los? Keine Ahnung :/

    Diese Pings gehen auf verschiedene Dienste, die über den geänderten Bloginhalt unterrichtet werden. Natürlich werden solche Dienste nicht nur von interessierten Menschen genutzt, um interessante Texte zu finden, sondern auch von kriminellen Spammern, um aktiv genutzte Blogs für den Missbrauch zu finden. Es ist kaum möglich, das eine zu erlauben und das andere zu unterbinden.

    Selbst, wenn nichts angepingt wird: Die Spammer bedienen sich reichlich aus den Suchergebnissen von Google. Wenn man von interessierten Menschen gefunden werden kann, denn kann man immer auch von Spammern gefunden werden.

    Übrigens ist der Ping auf rpc.technorati.com meines Erachtens nicht nötig, weil Pingomatic das bereits erledigt. (Lies aber aber besser noch irgendwo nach.)

    Das Entfernen der Pings wird ingesamt kaum eine Besserung bringen. Wenn du in deutscher Sprache bloggst und den Webserver vollständig unter Kontrolle hast, könnte allerdings etwas anderes helfen. (Das erfordert Sorgfalt und etwas Einlesen in die Materie.) Du könnest in der Konfiguration des Webservers die IP-Bereiche des asiatischen Raumes sperren. In meinen Blogs kommt aus diesem Bereich ungefähr 60 Prozent des Spams. Wie gesagt, es ist keine Kleinigkeit, und wenn du weißst, dass du "richtige" Leser dort hast (ich habe die zum Beispiel), denn ist dieser Weg nicht gangbar, da er diese Leser aussperrt. Außerdem könnten Spammer dies durch Verwendung von Proxyservern oder des Tor-Netzwerkes aushebeln. Es ist also eine Maßnahme von nur beschränktem Nutzen, über die ich für mich selbst einmal nachgedacht habe.

    Ist denn mittlerweile bekannt, wie die betroffenen Blogs überhaupt unter die Kontrolle der Spammer gekommen sind?

    Gruß
    Ingo

    Nein.

    Da auch WP 2.3.3 betroffen ist, habe ich die irreführenden Postings einiger WP-Entwickler ignoriert und in dieser Version nach einer möglichen Lücke gesucht. Bislang ist mir aber noch keine ins Auge gefallen. Die verwendeten Plugins der betroffenen Blogs decken eine große Bandbreite ab, so dass man hierüber auch keinen "Verdächtigen" finden kann.

    Ich kann zu diesem Thema nur sagen, dass ich selbst bislang verschont blieb. Das kann Glück sein, es kann aber auch heißen, dass sich eine gewisse Vorsicht bei mir auszahlt. Denn ich setze alle Dateirechte so, dass ein Überschreiben oder Anlegen von Dateien mit den Rechten des Webservers nicht möglich ist, außer im Ordner wp-content/uploads.

    Also kurz gesagt: Ich setze Dateien 644 (ich will sie ja noch selbst beim Upload überschreiben können) und Verzeichnisse 755 (außer wp-content/uploads, das kriegt 777). Damit funktionieren zwar einige Plugins nicht (etwa WP Database Backup, das will ein Verzeichnis anlegen), aber bislang wurde meine Installation auch noch nicht korrumpiert. Und für einen Backup der Datenbank habe ich zum Glück einen PHPMyAdmin...