Bastora Security Audit -- WordPress 插件

开发者	mathiasva
更新时间	2026年10月1日 02:28
PHP版本:	7.4 及以上
WordPress版本:	7.1
版权:	GPLv2 or later
版权网址:	版权信息

Bastora prüft Deine WordPress-Installation gegen einen festen Katalog aus 62 Sicherheitspunkten, härtet sie automatisch und wehrt laufende Angriffe ab. Installieren, aktivieren, einmal „Sicherheitsprüfung starten" klicken. Mehr ist nicht zu tun. Drei Dinge macht Bastora anders:

Ehrliche Außensicht. Bastora prüft Deine Seite so, wie ein Bot sie sieht: Versionslecks im HTML, offene Verzeichnisse, fehlende Security-Header, sichtbare Endpoints. Die meisten anderen Plugins prüfen nur ihre eigene Konfiguration.
Konflikt-erkennend. Läuft schon Wordfence, Sucuri, Solid Security, All-In-One WP Security, MalCare, WP Cerber, Limit Login Attempts, Really Simple SSL oder ein vergleichbares Plugin, tritt Bastora in den überlappenden Bereichen zur Seite, statt einen Konflikt zu bauen. Im Dashboard steht pro Härtung im Klartext, warum sie aktiv oder inaktiv ist.
Null Konfiguration. Härtungen sind ab Werk aktiv, jede Verbindung nach außen ist ab Werk aus.

Was Bastora tut

Firewall. Prüft den ganzen Aufruf: Adresszeile, Formulardaten, Roh-Inhalt, hochgeladene Dateien und Kopfzeilen. Die Regeln gegen kritische Lücken im WordPress-Kern greifen in jedem Modus.
Login-Schutz. Fehlversuche zählen je Adresse, je Konto und für die ganze Website: fünf Fehlversuche sperren 30 Minuten, bei Wiederholung 4 und dann 24 Stunden. Dazu Honeypot, ein einmal gültiges Sicherheitswort im Formular und eine Rechenaufgabe, wenn es eng wird. Cloudflare- und Proxy-IPs werden korrekt erkannt, IPv6 auf dem /64-Präfix gesperrt. Feste Adressen wie das Büro stehen auf einer Whitelist, bekannte Geräte werden nie ausgesperrt.
Datei-Wache mit Auto-Reparatur. Täglicher Abgleich von Kern, Plugins und Themes gegen die Originale auf wordpress.org. Manipulierte Kerndateien ersetzt Bastora nach doppelter Hash-Prüfung selbst, die vorgefundene Fassung wandert in die Quarantäne.
Schadcode-Scanner. PHP, JavaScript, HTML und Server-Regeldateien, alle vier Stunden, neue und geänderte Dateien zuerst. Ein Fund nennt Plugin oder Theme beim Namen, dazu Pfad und Zeile.
Bot- und Scanner-Abwehr. Wer Adressen abfragt, die es auf einer WordPress-Website nie gibt, sperrt sich selbst aus. Das Dashboard zeigt, wie viel Deines Bot-Verkehrs von SEO-Diensten und KI-Sammlern kommt, und weist sie auf Klick ab. Suchmaschinen und Linkvorschauen bleiben zugelassen.
Kommentar-Wache. Spam hält WordPress zurück, räumt ihn aber nicht weg: die Einträge bleiben in der Datenbank stehen. Bastora zählt sie und löscht sie auf Klick endgültig. Dazu lässt sich die Kommentarfunktion schließen, ganz oder nur dort, wo noch keine Kommentare stehen. Jede Seite ist einzeln entscheidbar, und der Weg zurück steht in den Einstellungen.
Nachbarn auf demselben Webspace. Liegen mehrere WordPress-Installationen in einem Hosting-Paket, laufen sie unter demselben Benutzerkonto des Servers. Bastora sagt Dir, welche davon von Deiner Installation aus erreichbar sind. Gemessen wird nur von der eigenen Seite aus, eine fremde Installation fasst Bastora dabei nicht an.
Datenbank-Prüfung. Läuft täglich im Hintergrund und meldet untergeschobene Konten, geänderte Adressen und Code in den Einstellungen, ohne dass jemand das Backend öffnen muss.
Härtung. Versionslecks, RSD- und WLW-Verweise, XML-RPC, Pingbacks, REST-API-Benutzer, Application Passwords, X-Powered-By, Author-Enumeration, Security-Header, PHP-Sperre im Uploads-Verzeichnis, Revisions-Limit und HTTPS-Umstellung auf einen Klick.
Dashboard im Klartext. Score, jeder Prüfpunkt mit Erklärung, Tagesprofil der letzten 24 Stunden und alle ausgesperrten Adressen mit Grund und Restlaufzeit, einzeln wieder freizugeben.

Was Bastora bewusst nicht macht

Kein erzwungenes TOTP. Solopreneure sperren sich regelmäßig mit Authenticator-Apps aus. Bastora setzt stattdessen auf Brute-Force-Schutz, Rate-Limit und Anomalie-Erkennung.
Kein Verstecken der Login-URL. Eine umbenannte Login-URL macht den Passwort-Reset-Link kaputt, sobald das Plugin deaktiviert wird. Rate-Limit plus Honeypot ist die saubere Lösung.
Keine Verbindung nach außen ohne Deine Freigabe. Versions-Abgleich gegen wordpress.org, Bastora-Schwarm, Schad-URL-Feed, Passwort-Leck-Check und die Einwilligung zur Sicherheitsforschung sind einzeln zuschaltbar und ab Werk aus.

Einwilligung zur Sicherheitsforschung (Opt-in) Mit Deiner Einwilligung schickt Bastora nach der Einrichtung und danach alle 28 Tage eine anonyme Zusammenfassung an einen Server in Deutschland: Versionen, Punktzahl, Prüfpunkte, Plugin- und Theme-Liste, Hosting-Anbieter, dazu abgewehrte Angriffe samt erkanntem Angriffsmuster. Daraus entstehen neue Firewall-Regeln für alle Bastora-Websites. Nicht übertragen werden: Domain, IP-Adressen, Benutzernamen, E-Mail-Adressen und alles, was jemand in ein Formular Deiner Website eingibt. Erweitert eine neue Fassung den Umfang, fragt Bastora vorher im Backend nach. Jederzeit widerrufbar in den Einstellungen. Alle Einzelheiten stehen unter „Privacy".

Installiere das Plugin aus dem WordPress-Plugin-Verzeichnis oder lade den ZIP-Ordner nach /wp-content/plugins/.
Aktiviere das Plugin im Menü „Plugins".
Öffne das neue Menü „Bastora" und klicke einmal auf „Sicherheitsprüfung starten".

Mehr ist nicht zu tun. Bastora richtet sich selbst ein.

2.2.4

IP-Adresse Whitelist. In den Einstellungen unter „Aktiver Schutz“ trägst Du feste Adressen ein, etwa den Büroanschluss, einen Standort oder das Netz eines Dienstleisters. Jede Adresse bekommt eine Bezeichnung, damit auch nach Monaten klar ist, wozu sie gehört. Die Liste klappt auf, wenn Du sie brauchst, und bleibt auch mit vielen Einträgen übersichtlich.
Befristet freigeben. Ein Eintrag gilt dauerhaft oder für 1, 7, 30 oder 90 Tage, praktisch für einen Dienstleister oder eine Messe. Danach wirkt er nicht mehr und bleibt ausgegraut stehen.
Zuletzt aktiv. Zu jeder Adresse steht, wann sie zuletzt auf der Website war. Ist sie seit 90 Tagen still, weist Bastora darauf hin, denn eine Adresse, die niemand mehr nutzt, kann inzwischen jemand anderem gehören.
Bekannte Geräte werden nie ausgesperrt. Ein Gerät, mit dem sich ein Administrator angemeldet hat, erkennt Bastora wieder, auch wenn sich seine IP-Adresse zu Hause, im Mobilfunk oder unterwegs ständig ändert. Beim Login-Schutz gilt das nur für das eigene Konto. Die Geräte Deines Kontos vergisst Du mit einem Klick, etwa wenn ein Laptop weg ist, und ein neues Passwort räumt sie ebenfalls ab.
Eingetragene Adressen und bekannte Geräte kommen durch. Die Scanner-Sperre, die Login-Sperre nach Fehlversuchen, die Sperrliste aus dem Schwarm und die Netzsperre der Konto-Wache lassen sie aus. Bastora meldet sie nie als Angreifer an andere Websites. Die Firewall prüft trotzdem jede einzelne Anfrage.
Mit einem Klick aus der Sperrliste. Unter „Zurzeit ausgesperrt“ steht neben „Freigeben“ jetzt „Immer vertrauen“. Die Bestätigung erscheint direkt auf der Seite, auf der Du geklickt hast.
Klare Meldung bei einer Sperre. Wer nach zu vielen Fehlversuchen oder über den Schwarm gesperrt ist, liest das jetzt beim Anmelden, samt Wartezeit. Bisher stand dort „Login-Daten ungültig“, auch bei richtigem Passwort, und wer es daraufhin weiter versuchte, verlängerte die Sperre.
Hinweis bei einem vorgeschalteten Server. Kommen viele Besucher mit derselben Adresse an, weist Bastora darauf hin, denn ein Eintrag dieser Adresse würde für alle gelten. Eingetragen wird, was Du einträgst: jede gültige IPv4- oder IPv6-Adresse und jedes Netz.
Datenschutz vollständig beschrieben. Der Abschnitt „Privacy“ beschreibt jetzt auch alles, was Bastora auf Deiner Website selbst verarbeitet: Anmeldeschutz, Protokolle, Sperrliste, Gerätekennzeichen und Whitelist, jeweils mit Frist. Für Deine eigene Datenschutzerklärung liefert Bastora einen Textbaustein unter Einstellungen, Datenschutz.

2.2.0

Bastora urteilt über das Gesamtbild. Jede Auffälligkeit wird gegen die Lage der Website gewogen: Läuft gerade ein Update, ist die Website umgezogen, liegt die Datei in einer Sicherungskopie, entspricht sie dem Original? Gemeldet wird, was belegt ist. Ein einzelnes verdächtiges Muster reicht dafür nicht.
Updates laufen ungestört. Bastora erkennt ein laufendes WordPress-Update und Dateien aus einer anderen offiziellen WordPress-Version. Die Kerndateien prüft Bastora, sobald das Update abgeschlossen ist.
Umzüge erkennt Bastora selbst. Arbeitest Du nach einem Umzug unter der neuen Adresse, übernimmt Bastora sie als neuen Normalzustand.
Klare Ergebnisse. Die Prüfung endet mit einer von drei Aussagen: alles in Ordnung, etwas instand gesetzt oder Angriff festgestellt und beseitigt. Wo Bastora eine Stelle nicht selbst bereinigen darf, steht dabei, warum, und was zu tun ist.
Sicherungskopien bleiben Sicherungskopien. Die Rücksicherungen, die WordPress bei Plugin-Updates anlegt, und Bastoras eigene Dateien fließen in keine Bewertung ein.

2.1.2

Der Dialog beim Abschalten geht wieder auf. Wer Bastora deaktiviert, wird nach dem Grund gefragt. Bisher blieb die Nachfrage aus, weil Bastora den falschen Teil der Plugin-Liste angesprochen hatte. Die Antwort bleibt freiwillig, überspringen geht weiterhin mit einem Klick, und ohne Absenden wird nach wie vor nichts übertragen.

2.1.1

Bastora fasst gekaufte Erweiterungen nicht mehr an. Beim Abgleich mit wordpress.org hat Bastora bisher jede Installation gegen das dortige kostenlose Paket gemessen. Bei einer bezahlten Ausgabe ist das der falsche Maßstab: Sie trägt denselben Namen und dieselbe Versionsnummer, enthält aber anderen Code. Bastora hielt diesen Unterschied für eine Manipulation und bot an, die Dateien zu "reparieren", also die bezahlte Fassung durch die kostenlose zu ersetzen. Genau das ist auf Kundenseiten passiert. Bastora erkennt solche Pakete jetzt und lässt sie unangetastet.
Mitgelieferte Bibliotheken werden nicht mehr bewertet. Was in vendor/, freemius/ oder node_modules/ liegt, stammt aus einem Paketwerkzeug. Welche Version einer Bibliothek eine Erweiterung mitbringt, ist keine Frage der Sicherheit der Website. Eine Abweichung dort ist deshalb kein Befund mehr.
Keine zweite Runde an derselben Datei. Wurde eine Datei einmal auf das Original zurückgesetzt und weicht danach erneut ab, schreibt sie eine laufende Software neu. Bastora fasst sie dann nicht noch einmal an, statt in ein endloses Hin und Her zu geraten.
Bastora räumt in bezahlten Erweiterungen nichts mehr von selbst weg. Ein Fund dort bleibt sichtbar und lässt sich mit einem Klick behandeln, aber die Entscheidung trifft der Betreiber, nicht das Plugin.

2.1.0

Die Anmeldewache sperrt kein Konto mehr aus. Bisher konnte sie einen Zugang für 24 Stunden schließen, wenn eine Anmeldung ungewöhnlich aussah. Ein Fehlalarm hat damit den Betreiber selbst ausgesperrt. Diese Sperre ist ersatzlos entfallen, offene Sperren werden beim Update aufgehoben. Der Schutz gegen falsche Passwörter bleibt unverändert.
Statt der IP-Adresse zählt jetzt das Gerät. Deutsche Anschlüsse bekommen bei jeder Einwahl eine neue Adresse, im Mobilfunk wechselt sie noch öfter. Eine Liste vertrauter Netze wächst damit endlos und erkennt trotzdem nichts. Bastora merkt sich stattdessen das Gerät und lässt es beim nächsten Mal still durch.
Bei einem neuen Gerät bekommst Du eine Nachricht, keine Sperre. Die Anmeldung geht durch, und an die hinterlegte Adresse geht eine kurze Mail. Beim zweiten Mal von demselben Gerät bleibt es still.
Nur bei einem harten Anhaltspunkt fragt Bastora nach. Etwa wenn kurz zuvor das Passwort dieses Kontos in Serie geraten wurde und der nächste Versuch dann klappt, oder wenn die Anmeldung nicht aus einem Browser kommt, sondern von einem Programm. Dann geht ein Bestätigungslink an das Konto: klicken, erneut anmelden, fertig. Das ist keine Sperre, und wer den Link nicht klickt, bekommt beim nächsten Versuch einfach einen neuen. Ein neues Netz, eine ungewohnte Uhrzeit oder ein Schadcode-Fund auf der Website reichen dafür ausdrücklich nicht mehr, auch nicht zusammen.
Lässt sich die Mail nicht zustellen, wird durchgelassen. Eine Rückfrage ohne Rückweg wäre eine Falle. Der Betreiber bekommt dann stattdessen einen Hinweis.
Keine Netzsperre, solange jemand angemeldet ist. Eine Sperre auf ein ganzes Netz trifft die komplette Website, nicht nur die Anmeldung. Sitzt gerade ein Betreiber im selben Netz, wäre er damit vollständig ausgesperrt.
Ein Platzhalter ist keine Herkunft. Kennt der Server die Adresse des Aufrufers nicht, entstand daraus bisher eine Sperrregel auf ein Scheinnetz. Auf manchen Installationen hätte die jeden Besucher getroffen. Solche Werte werden jetzt abgewiesen.
Bastora sieht, wer auf demselben Webspace wohnt. Liegen mehrere WordPress-Installationen im selben Hosting-Paket, laufen sie alle unter demselben Benutzerkonto des Servers. Dateirechte trennen sie deshalb nicht: Wird eine davon übernommen, kann der Angreifer von dort aus in die anderen schreiben. Genau so kehrt eine bereinigte Infektion zurück. Bastora erkennt solche Nachbarn und sagt, welche von hier aus erreichbar sind. Dabei wird keine fremde Installation angefasst, gemessen wird ausschließlich von der eigenen Seite aus.
Bastora greift dabei bewusst nicht ein. Trennen lassen sich solche Installationen nur auf Server-Ebene, und eine zu eng gesetzte Grenze legt eine Website so still, dass kein Plugin sie wieder aufmachen kann. Bastora meldet die Lage deshalb und nennt den Weg: Dein Hoster kann die Installationen gegeneinander abgrenzen.
Spam-Kommentare lassen sich mit einem Klick wegräumen. WordPress hält Spam zurück, aber es räumt ihn nicht weg: die Einträge bleiben in der Datenbank stehen. Bastora zählt sie, sagt Dir wie viele es sind und löscht sie auf Klick endgültig, in Paketen, damit auch eine übervolle Datenbank nicht ins Zeitlimit läuft. Freigegebene Kommentare bleiben unberührt.
Die Kommentarfunktion lässt sich schließen, ganz oder nur dort, wo noch keine Kommentare stehen. Über ein Kommentarformular ist es möglich, dass jemand ohne Anmeldung etwas direkt in Deine Datenbank schreibt. Wer Kommentare nicht benötigt, schließt damit eine potenzielle Angriffsfläche. Vorhandene Kommentare bleiben in beiden Fällen sichtbar, geschlossen wird nur die Annahme neuer.
Der Weg zurück steht in den Einstellungen. Bastora merkt sich, welche Seiten es geschlossen hat, und öffnet auf Klick genau diese wieder. Was Du selbst geschlossen hattest, bleibt zu.
Bots werden auf Server-Ebene abgewiesen. Wo der Server es zulässt, trägt Bastora die Abweisung in die Serverkonfiguration ein. Sie greift damit, bevor WordPress überhaupt startet, und ein Crawler-Ansturm kostet Deine Website nicht mehr die Arbeit einer ganzen Seitenauslieferung. Suchmaschinen und Linkvorschauen bleiben zugelassen.
Der Einrichtungsassistent fragt nach KI- und SEO-Crawlern. Zwei getrennte Fragen, weil die Folgen verschieden sind: KI-Crawler auszusperren kostet Sichtbarkeit in KI-Antworten, SEO-Crawler auszusperren kostet die eigenen Auswertungen in Ahrefs und Semrush. Beides steht bei der Frage dabei.
Angriffswerkzeuge werden an ihrer eigenen Kennung erkannt. Wer sich als Sicherheits-Scanner ausweist, wird als solcher behandelt, unabhängig davon, welche weiteren Wörter in derselben Kennung stehen.
Eine leere Datei mit auffälligem Namen im Hauptverzeichnis wird als Hinweis gemeldet. Automatisierte Angriffe legen solche Marken ab, um sich zu merken, wo sie schon waren. Der Fund steht ausdrücklich als Hinweis da, nicht als Einbruchsbeleg.
Bastoras eigene Werkzeuge werden als solche erkannt. Ein Notfall-Werkzeug, das nach Schadcode sucht, trägt dessen Merkmale im Klartext. Die Ausnahme dafür hängt an der Prüfsumme: ein einziges verändertes Byte, und die Datei wird ganz normal geprüft.
Die Serverkonfiguration bleibt sauber. Gibt es nichts zu sperren, hinterlässt Bastora dort auch keinen leeren Abschnitt.

2.0.0

Bastora findet jetzt die Hintertür, die eine Neuinstallation überlebt. Wer WordPress nach einem Einbruch neu aufsetzt und die Datenbank mitnimmt, nimmt den Angreifer oft mit. Bastora sieht deshalb an den Stellen nach, die kein Dateiscanner erreicht: gepackte Nutzlasten, die unter einem Zufallsnamen in der Datenbank liegen, Auslöser, die beim Schreiben eines Kommentars selbsttätig ein Administrator-Konto anlegen, zeitgesteuerte Aufgaben und gespeicherte Routinen der Datenbank, und Code-Schnipsel, die als Einstellung oder Beitrag abgelegt sind.
Versteckte Administrator-Konten fallen auf. Schadsoftware blendet die eigenen Konten aus der Benutzerliste aus, dann sieht im Backend niemand sie. Bastora zählt die Administratoren direkt in der Datenbank und vergleicht das mit dem, was WordPress anzeigt. Stehen dort mehr, blendet jemand aus. Das ist eine Aussage über die Manipulation und überlebt jede Umbenennung.
Zwei Merkmale, an denen ein untergeschobenes Konto sich verrät. Ein Kennwortwert, den WordPress so nie vergibt, weil er per Datenbank direkt hineingeschrieben wurde. Und ein Anlagezeitpunkt, der vom allerersten Konto der Website abgeschrieben ist, damit das fremde Konto in der Liste wie eine Altlast aussieht.
Eine hochgeladene Datei mit ausführbarem Code kommt gar nicht erst an. Bastora prüft jeden Upload, bevor er im Verzeichnis landet, und weist ihn ab, wenn Code darin steckt. Ein Bild bleibt ein Bild, ein Archiv wird durchgelassen, damit Installationen weiter funktionieren.
Dateien an Orten, an denen keine sein dürfen. Eine versteckte Datei mit Zufallsnamen im WordPress-Kernverzeichnis. Dieselbe Datei in mehreren PHP-Endungen nebeneinander, weil der Angreifer sucht, welche der Server ausführt. Eine PHP-Datei im Upload-Ordner. Ein Verzeichnis, das sich betreten und beschreiben, aber nicht auflisten lässt.
Wo eine bekannte Lücke sitzt, wird schärfer gehandelt. Meldet der tägliche Abgleich eine Sicherheitslücke in einer Deiner Erweiterungen, blockt die Firewall Angriffe auf genau diesen Bereich, statt sie nur zu vermerken. Der übrige Verkehr bleibt davon unberührt.
Angriffe, die aus echten Vorfällen stammen. Neun neue Erkennungsmuster und zwölf Prüfsummen kommen aus der Untersuchung eines tatsächlichen Einbruchs, nicht aus einer Liste. Darunter: eine vorgeschaltete Datei in der Serverkonfiguration, das Auslesen der Zugangsdatei über einen Umweg, das Einsammeln der Sicherheitsschlüssel und nachgeladener Code, der vor der Ausführung von seinen Marken befreit wird.
Der Angriffszähler trennt jetzt Rauschen von echten Angriffen. Ein Aufruf der Hinweisdatei oder die Frage nach der Autorenliste ist kein Angriff, auch wenn Bastora ihn vermerkt. Beide Zahlen stehen nebeneinander, die alte bleibt unverändert erhalten.
Deine Anmeldedaten werden gesichert, bevor Sitzungen beendet werden. Sperrt Bastora ein Konto, waren Anmeldezeitpunkt, Adresse und Browserkennung bisher weg. Genau die braucht man danach, um zu beurteilen, wer betroffen war. Sie bleiben jetzt 90 Tage auf Deiner Website liegen und werden nirgendwohin übertragen.
Behoben: Bastoras eigene Sicherung der Zugangsdatei war lesbar. Beim Ändern der wp-config.php legte Bastora eine Sicherung daneben, die der Server als reinen Text ausgeliefert hätte: mit Datenbank-Kennwort und allen Sicherheitsschlüsseln. Die Sicherung trägt jetzt eine Endung, die nie als Text ausgeliefert wird, und ist zusätzlich per Serverregel gesperrt. Eine Sicherung aus einer früheren Fassung bringt Bastora beim nächsten Prüflauf selbst in diese Form, statt sie Dir als fremden Fund vorzuhalten. Jede andere Kopie der Zugangsdatei im Verzeichnis wird gemeldet.
Behoben: Auskommentierte Zeilen in der Zugangsdatei wurden für gültig gehalten. Stand oberhalb der wirksamen Zeile ein alter, auskommentierter Eintrag, hat Bastora diesen gelesen. Die Datei wird jetzt so ausgewertet, wie PHP sie liest, nicht mit einer Textsuche.
Behoben: "Alles grün" stand auch dann da, wenn Bastora nichts messen konnte. Punkte, die sich nicht prüfen lassen, etwa weil der Versions-Abgleich mit wordpress.org nicht freigegeben ist, galten intern als bestanden. Deshalb zeigte eine Ebene "alles grün", in der nichts gemessen war, und der Hinweis auf die Pro-Version lobte eine Punktzahl, die Deine Website gar nicht erreicht hatte. Beides hängt jetzt am tatsächlichen Ergebnis. Was ungemessen bleibt, steht als "nicht prüfbar" daneben.
Behoben: Beim Deinstallieren kam die Abmeldung vom Schwarm nie an. Sie ging an eine Adresse, die auf die richtige weiterleitet, und einer Weiterleitung folgt dieser Aufruf nicht. Der Eintrag blieb dadurch auf dem Server stehen. Die Adresse ist korrigiert, und beim Entfernen bleibt jetzt nichts mehr zurück: keine Einstellung, keine Tabelle, keine Datei, keine Zeile in der Serverkonfiguration.
Verteilte Firewall-Regeln schalten sich ab, wenn sie hier falsch liegen. Trifft eine zentral verteilte Regel wiederholt eine angemeldete Redaktion, nimmt Bastora sie auf dieser Website aus dem Verkehr und meldet das zurück. Sie kommt durch den nächsten Abruf nicht wieder. Jede neue Regel läuft ohnehin erst im Beobachten mit und wird vor der Verteilung gegen einen Bestand echter, harmloser Aufrufe geprüft.

1.9.2

Bastora sucht jetzt dort, wo ein Scanner von außen nicht hinkommt. Ein Angreifer, der sich festsetzen will, legt selten eine auffällige Datei ab. Er schiebt eine Datei vor jeden einzelnen Seitenaufruf, hängt sich an eine Datei, die WordPress noch vor allen Erweiterungen lädt, oder legt seinen Code gleich in der Datenbank ab. Bastora sieht an all diesen Stellen nach, weil es von innen schaut.
Was vor jedem Aufruf geladen wird, wird geprüft. Bastora liest die Serverkonfiguration aus und beurteilt die vorgeschaltete Datei: Steckt Schadcode darin, liegt sie an einem Ort, an dem so etwas nichts zu suchen hat, oder verweist sie ins Leere. Reicht eine Datei den Wert an eine zweite weiter, geht Bastora diesen Schritt mit.
Die vier Dateien, die WordPress vor allen Erweiterungen lädt, werden auf Schadcode geprüft. Bisher liefen sie mit, ohne dass jemand hinsah.
Schadcode in der Datenbank wird gefunden. Ein Eintrag mit ausführbarem Code fällt jetzt auf, egal wie er heißt: ob er unter tausend harmlosen Einträgen mit knapp einem Kilobyte liegt oder mehrere hundert Kilobyte groß ist und den Code erst ganz am Ende trägt. Nur Dateien zu löschen half bisher nichts, wenn sich der Code aus der Datenbank wieder herstellt.
Verschleierung zählt in der Häufung. Ein einzelner verschleierter Codeabschnitt kann in einer gekauften Erweiterung stehen, deshalb löst er allein weiterhin keine Meldung aus. Treffen mehrere Verschleierungs-Verfahren in derselben Datei zusammen, ist es keine gekaufte Erweiterung mehr. Damit fällt auch ein untergeschobenes Plugin auf, das sich mit erfundenem Autor unter die echten mischt.
Eine PHP-Datei mit zufälligem Namen fällt auf, ebenso eine PHP-Datei, die um ein Vielfaches größer ist, als sie sein dürfte.
Große Dateien werden nicht mehr übersprungen. Bis zu einer bestimmten Größe hörte die Prüfung vorher einfach auf. Genau darin haben sich Angreifer eingerichtet: Code an eine aufgeblähte Datei zu hängen, war der einfachste Weg, ungesehen zu bleiben. Bastora prüft jetzt Anfang und Ende jeder Datei.
Ein Kommentar ist kein Versteck mehr. Bestimmte Marken erkennt Bastora jetzt auch dann, wenn sie als Kommentar getarnt sind.
Bekannte Sicherheitslücken werden benannt. Bastora gleicht Kern, Plugins und Themes täglich gegen die bekannten Schwachstellen ab und sagt, welche Erweiterung betroffen ist, unter welcher Nummer die Lücke geführt wird und ab welcher Version sie behoben ist. Der Abgleich lädt nur die Liste herunter, über Deine Website wird dabei nichts übertragen.
Behoben: Schalter sprangen beim Speichern aus der Reihe. Die Bestätigung „Gespeichert" erschien rechts neben dem Schalter, schob ihn nach links und blieb danach als unsichtbarer Platzhalter stehen. Die Bestätigung steht jetzt links vom Schalter und verschwindet restlos. Der Schalter bleibt, wo er ist.
Behoben: Das Feedback-Formular saß an der falschen Stelle. Es rutschte unter das Menü und war nur halb lesbar. Feedback und Kontakt haben jetzt eine eigene Seite im Bastora-Menü, erreichbar auch über den Link unter jeder Bastora-Seite.
Behoben: Die Anmeldewache sperrte Nutzer mit wechselnder Internet-Adresse aus. Die meisten deutschen Anschlüsse bekommen bei jeder Einwahl eine neue Adresse, im Mobilfunk wechselt sie noch häufiger. Die Wache hielt jede davon für ein fremdes Netz. Lag zusätzlich ein offener Schadcode-Fund vor, waren das zwei Verdachtsgründe und das Konto wurde für 24 Stunden gesperrt: bei jeder Anmeldung aufs Neue. Bastora erkennt jetzt, wenn ein Anschluss ohnehin ständig wechselt, und wertet ein neues Netz aus demselben Anbieter-Bereich nicht mehr als Verdachtsgrund. Alle anderen Verdachtsgründe zählen unverändert weiter.

1.9.1

Behoben: Bastora meldete reguläre Administrator-Konten als untergeschoben. Der Abgleich mit der eigenen Aufzeichnung fragte eine Spalte ab, die es in der Tabelle nicht gibt. Jedes nach der Installation angelegte Administrator-Konto galt dadurch als an WordPress vorbei entstanden, mit Mail an die hinterlegten Empfänger.
Was sich nicht belegen lässt, wird nicht gemeldet. Antwortet die Aufzeichnung nicht oder fehlt sie, schweigt die Prüfung. Maßgeblich ist außerdem, seit wann das Protokoll wirklich mitschreibt, nicht seit wann Bastora installiert ist.
Bastora beurteilt die Umstände, unter denen ein Administrator-Konto entsteht. Wer legt an, ist derjenige angemeldet, kommt er aus einem gewohnten Netz, entsteht ein einzelnes Konto oder eine ganze Reihe, wie ist die Lage auf der Website. Der Alltagsfall wird gar nicht erst gemeldet.
Bei klarer Lage handelt Bastora, statt zu fragen. Zwei unabhängige Anhaltspunkte genügen: Administrator-Rechte entzogen, Sitzungen beendet, Herkunft 24 Stunden gesperrt, eine halbe Stunde Notbremse für jedes weitere neue Administrator-Konto. Die Mail berichtet, was passiert ist, und jede Maßnahme lässt sich mit einem Klick zurücknehmen.
Auch die Anmeldung wird beurteilt. Meldet sich ein Administrator aus einem Netz an, aus dem sich dieses Konto noch nie angemeldet hat, prüft Bastora die Lage. Ein neues Netz allein ist harmlos. Kommt ein zweiter Anhaltspunkt dazu, ist der Zugang 24 Stunden zu, und an das Konto geht ein Link für ein neues Passwort. Damit ist der Zugang sofort wieder frei.
Bastora sperrt Dich nicht aus Deiner eigenen Website aus. Ein Netz, aus dem sich schon einmal ein Administrator angemeldet hat, wird nie gesperrt. Gesperrt wird nur, wenn die Mail mit dem Link auch rausgeht. Jede Sperre endet nach 24 Stunden von allein.
Rollen mit weitreichenden Rechten werden nicht mehr pauschal gemeldet. Shop- und Mitglieder-Erweiterungen richten solche Rollen absichtlich ein. Bastora hält den Grundzustand fest und bewertet nur noch Änderungen daran: erklärt eine Installation oder Aktualisierung das neue Recht, bleibt es still. Der Knopf entfernt dann nur die neu hinzugekommenen Rechte, nie den Bestand.
„Feedback & Kontakt zu Bastora“ steht jetzt auf jeder Bastora-Seite, unten mit Abstand, zusammen mit dem BSI-Hinweis. Vorher lag das Feld ganz unten in den Einstellungen.
Die Karte zur abgewehrten Kern-Lücke nennt die Lücke beim Namen. Vorher stand dort „Diese Lücke“, ohne dass irgendwo stand, welche gemeint ist.

1.9.0

Die Firewall prüft den ganzen Aufruf. Adresszeile, Formulardaten, Roh-Inhalt, hochgeladene Dateien und Kopfzeilen. Die Regeln gegen kritische Kern-Lücken gelten in jedem Modus und auch neben anderen Sicherheits-Plugins.
Grundschutz ab der ersten Minute. Login-Schutz, Uploads-Sperre, Enumerationsschutz, Fehlerprotokoll und Datei-Wache arbeiten ab der Aktivierung. Der Assistent regelt nur, was in den laufenden Betrieb eingreift.
Login-Schutz gegen verteiltes Raten. Fehlversuche zählen je Adresse, je Konto und für die gesamte Website. Anmeldungen ohne Formular haben eine engere Grenze, jedes Formular trägt ein einmal gültiges Sicherheitswort, und wenn es eng wird, kommt für alle die Rechenaufgabe dazu.
Scanner sperren sich selbst aus. Wer Adressen abfragt, die es auf einer WordPress-Website nie gibt, oder im Sekundentakt ins Leere läuft, wird abgewiesen: 15 Minuten, dann 2, dann 24 Stunden. Angemeldete Benutzer und geprüfte Suchmaschinen bleiben ausgenommen. Ausgesperrte Adressen stehen mit Grund und Restlaufzeit unter Statistik und lassen sich einzeln freigeben.
Bot-Verkehr wird sichtbar. Das Dashboard zeigt den Anteil von SEO-Diensten und KI-Sammlern an den letzten 28 Tagen, mit den häufigsten Namen und einem Knopf, der sie abweist. Suchmaschinen und Linkvorschauen bleiben zugelassen.
Fremde Adressen im Suchmaschinen-Bestand fallen auf. Bastora zeigt das Muster mit Beispielen. Auf Klick antworten diese Adressen mit „410 Gone", damit Suchmaschinen sie zügig aus dem Bestand nehmen. Eigene Inhalte werden nie angeboten, die Entscheidung lässt sich zurücknehmen.
Der Schadcode-Scanner deckt mehr ab. Neben ausführbaren Dateien jetzt auch HTML, JavaScript und Server-Regeldateien, alle vier Stunden, neue und geänderte Dateien zuerst. Bei PHP zählt nur der Code, der auch ausgeführt wird. Ein Fund nennt Plugin oder Theme beim Namen, dazu Pfad und Zeile. Die Quarantäne liegt außerhalb des Medien-Verzeichnisses in einem Ordner mit unvorhersehbarem Namen.
Die Datenbank-Prüfung läuft täglich im Hintergrund, mit Nachricht an die gewählten Empfänger. Untergeschobene Konten, geänderte Adressen und Code in Einstellungen fallen damit auf, ohne dass jemand das Backend öffnet.
Die Uploads-Sperre setzt ihre Regeln nach vorn. Eine vorgefundene Regeldatei wird gesichert, eine fremde als Fund gemeldet. Wo der Server solche Dateien nicht liest, sagt Bastora das offen.
Gewissheit bei der Lücke, die gerade massenhaft ausprobiert wird. Bastora prüft Konfigurationsdatei, Einstellungen, WordPress-Kern und Zwischenspeicher des Servers und zeigt das Ergebnis mit der Zahl der Versuche und dem Prüfzeitpunkt. Ein Klick bereinigt, jede Fundstelle wird vorher gesichert. Wer nie betroffen war, sieht nichts davon.
Ein Tagesprofil zeigt, wann auf Deiner Website etwas los ist. Je Stunde fünf Zahlen: Seitenaufrufe, Bot-Anfragen, Fehlerseiten, Anmeldeversuche, abgewehrte Angriffe.
Bastora hält sich selbst aktuell. Sicherheits-Updates des Plugins spielen sich von allein ein, unabhängig davon, wie die übrigen Auto-Updates eingestellt sind.
Neue Angaben in der Sicherheitsforschung werden einzeln freigegeben. Erweitert eine Fassung den Umfang, fragt Bastora im Backend nach und sendet den neuen Teil erst nach Deiner Zustimmung. Wer beim Bisherigen bleibt, behält ihn, und die Frage kommt kein zweites Mal. Ältere Einträge stehen in der Datei changelog.txt im Plugin-Ordner.

Bastora Security Audit

标签

下载

详情介绍:

安装:

屏幕截图:

升级注意事项:

常见问题:

更新日志: