=== Bastora Security Audit ===
Contributors: mathiasva
Tags: security, firewall, malware, brute force, hardening
Requires at least: 6.0
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 2.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: bastora-security-audit

62-Punkte-Sicherheits-Check mit Firewall, Schadcode-Scanner, URL-Reputation, Captcha, Schwarm-Schutz und Auto-Reparatur der WordPress-Kerndateien.

== Description ==

**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:

1. **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.
2. **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.
3. **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.
* **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.
* **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".

== Installation ==

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

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

== Frequently Asked Questions ==

= Brauche ich technisches Wissen, um Bastora zu nutzen? =

Nein. Bastora braucht keine Konfiguration. Installieren, aktivieren, scannen, fertig.

= Funktioniert Bastora neben Wordfence, Sucuri oder Solid Security? =

Ja. Bastora erkennt diese Plugins und tritt in den überlappenden Bereichen zur Seite. Das Dashboard zeigt, welche Härtungen deshalb inaktiv sind. Die Regeln gegen kritische Kern-Lücken bleiben in jedem Fall aktiv.

= Überträgt das Plugin Daten von meiner Seite? =

Ab Werk nichts. In den Einstellungen gibst Du einzeln frei: Versions-Abgleich gegen api.wordpress.org, Bastora-Schwarm, Schad-URL-Feed, Passwort-Leck-Check und die Einwilligung zur Sicherheitsforschung. Vor Deinem Häkchen geht kein einziger Request raus.

= Wie widerrufe ich die Einwilligung zur Sicherheitsforschung? =

Bastora → Einstellungen → Schalter aus → speichern. Ab da geht kein Datensatz mehr an bastora.de. Bereits übertragene Datensätze werden nicht rückwirkend gelöscht, weil sie keinen Bezug zu Deiner Website haben, sondern nur zu einer zufälligen UUID.

= Wo werden die Daten gespeichert? =

Auf deutschen Servern. Bastora arbeitet ausschließlich mit einem deutschen Hoster.

= Was passiert, wenn ich Bastora deinstalliere? =

Bei einfacher Deaktivierung bleiben die Einstellungen erhalten. Beim Löschen entfernt Bastora alle Einstellungen, Audit-Ergebnisse und Kennungen und rollt die Härtungen zurück. Ein aktiver Schwarm-Knoten wird vorher abgemeldet.

= Wie funktioniert der Bastora-Schwarm? =

Erkennt eine teilnehmende Website einen Brute-Force-Angriff oder einen Scanner, meldet sie die Angreifer-IP anonym an einen zentralen Server. Melden mehrere Websites dieselbe IP, wandert sie in einen Sperrkatalog, den alle teilnehmenden Websites abholen und vorbeugend anwenden. Einträge verfallen nach 72 Stunden ohne neue Meldung, bekannte Crawler wie Googlebot oder Bingbot werden nie übernommen. Deine Seite gibt dabei nur einen anonymen Token, die Angreifer-IP, den Angriffs-Typ und die Plugin-Version heraus, keine Domain und keine Nutzerdaten.

== Screenshots ==

1. Der erste Scan startet, Bastora prüft 62 Sicherheitspunkte in etwa 25 Sekunden.
2. Ergebnis des ersten Scans: Score plus klare Aufteilung in bestanden, Hinweise und offene Punkte.
3. Bastora schaltet die Härtungen scharf, wo ein anderes Sicherheits-Plugin schon zuständig ist, lässt Bastora die Hand davon.
4. Das Dashboard nach Aktivierung: aktueller Sicherheits-Score und jeder Prüfpunkt mit Klartext-Erklärung.

== Changelog ==

= 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.

== Upgrade Notice ==

= 1.9.1 =
Behebt eine Falschmeldung, die reguläre Administrator-Konten als untergeschoben meldete. Neu beurteilt Bastora die Umstände einer Konto-Anlage und einer Anmeldung und greift bei klarer Lage selbst ein, statt zu fragen. Rollen mit weitreichenden Rechten werden nur noch bei Änderungen gemeldet.

= 1.9.0 =
Grundschutz greift ab der Aktivierung, die Firewall prüft den kompletten Aufruf, Scanner und unerwünschte Bots sperren sich selbst aus, und die Datenbank wird täglich im Hintergrund geprüft. Aus der bisherigen anonymen Statistik wird die Einwilligung zur Sicherheitsforschung: gleicher Schalter, klarerer Zweck, neue Angaben erst nach Rückfrage.

== Privacy ==

= Externe Verbindungen =

Ab Werk baut Bastora keine einzige Verbindung nach außen auf. Jede der folgenden Verbindungen schaltest Du im Einrichtungs-Assistenten oder in den Einstellungen einzeln frei und kannst sie jederzeit wieder abschalten. Angesprochen werden dabei nur zwei Gegenstellen: **wordpress.org** und **bastora.de**.

**1. Abgleich gegen wordpress.org (Opt-in)**

Bastora fragt die offizielle WordPress-API nach der aktuellen Kern-Version, nach den Datei-Hashes Deiner Version und nach dem Update-Stand der installierten Plugins und Themes. Für den Datei-Abgleich und die Reparatur lädt Bastora zusätzlich die offiziellen Pakete von wordpress.org. Das ist dieselbe Schnittstelle, die WordPress für seine eigenen Update-Prüfungen nutzt.

Übertragen wird nur der Slug des jeweiligen Plugins oder Themes, keine Domain, keine Nutzerdaten, keine Besucher-IP. Antworten werden 24 Stunden zwischengespeichert, geladene Pakete liegen 7 Tage lokal im Quarantäne-Verzeichnis. Vor dem Ersetzen einer Kerndatei prüft Bastora deren Hash gegen den von wordpress.org gemeldeten Wert. Plugins und Themes, die nicht im offiziellen Verzeichnis liegen (Premium, Eigenentwicklung), werden als „extern, nicht prüfbar" geführt; bei Plugins repariert Bastora bewusst nicht, sondern meldet abweichende Dateien per Mail. Ohne diese Freigabe gelten die betroffenen Prüfpunkte als „nicht prüfbar" und es geht keine Anfrage raus.

**2. Bastora-Schwarm (Opt-in)**

Anonymer Austausch von Angreifer-Adressen mit anderen teilnehmenden Websites, über bastora.de. Beim Aktivieren vergibt der Server einen anonymen Token; übertragen wird dabei nur die Plugin-Version. Bei einem erkannten Angriff meldet Bastora Token, Angreifer-IP, Angriffs-Typ, Schweregrad und Plugin-Version. Im Gegenzug holt Bastora alle paar Minuten die Sperrliste und zweimal täglich die signierten Firewall-Regeln ab, jeweils nur mit dem Token im Header. Beim Abschalten oder Deinstallieren wird der Knoten sofort gelöscht.

Der User-Agent ist statisch („Bastora-Swarm"), damit WordPress die Domain nicht mitschickt. Nicht übertragen werden Domain, URL, Besucher-IPs und Betreiberdaten. Reports werden serverseitig nach 14 Tagen gelöscht, Sperrlisten-Einträge verfallen nach 72 Stunden. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Angriffsabwehr).

**3. Passwort-Leck-Check (Opt-in, nur Backend-Login)**

Beim Backend-Login schickt Bastora höchstens einmal pro Nutzer und Woche die ersten fünf Hex-Zeichen des SHA-1-Hashes des eingegebenen Passworts an bastora.de. Mehr geht nicht raus: nicht das Passwort, nicht der vollständige Hash, kein Benutzername, keine Domain, keine Kennung. Der Server fragt damit die offizielle haveibeenpwned.com-API ab und liefert die Hash-Endungen zurück, der Abgleich passiert lokal in WordPress. Das Verfahren heißt k-Anonymity und wird auch von 1Password, Firefox und Chrome genutzt. Bei einem Treffer bekommt der Nutzer einen Hinweis, der Login wird nie blockiert. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO.

**4. Schad-URL-Feed (Opt-in)**

Einmal täglich holt Bastora eine Liste bekannter Schad-Domains von bastora.de, optional nur die Neuzugänge seit dem letzten Abruf. Es geht keine Domain, keine Besucher-Daten und keine Kennung raus. Die Antwort ist eine reine JSON-Liste aus Schad-Domain, Typ und Schweregrad, ohne ausführbaren Code. Quellen: URLhaus (abuse.ch, CC0 1.0) und der OpenPhish-Community-Feed. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO.

**5. Einwilligung zur Sicherheitsforschung (Opt-in)**

Nach der Einrichtung und danach alle 28 Tage schickt Bastora eine anonyme Zusammenfassung an bastora.de. Vor Deiner Einwilligung wird kein einziger Aufruf ausgeführt. Übertragen werden:

* eine zufällige anonyme Site-ID (UUID), lokal beim ersten Start erzeugt
* Versionen und Umgebung: Bastora, WordPress samt Update-Status, PHP, MySQL, Server-Software, Locale, Zeitzone, Multisite-Flag
* ein anonymer Hosting-Anbieter-Slug (z. B. „hetzner", „ionos"), ermittelt aus lokalen Markern und einer lokalen Namensauflösung der eigenen Server-IP. Die Server-IP selbst wird nicht gesendet.
* je installiertem Plugin (max. 200) und Theme (max. 75): Slug, Version, verfügbare Version, Update- und Auto-Update-Status, aktiv oder inaktiv
* Nutzerzahlen je Rolle und Inhaltszahlen (Beiträge, Seiten, Kommentare), nur Zahlen, keine Namen, keine Inhalte
* Konfigurations-Flags wie WP_DEBUG, DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN
* Punktzahl und je Prüfpunkt ein Status-Code (bestanden / Hinweis / offen / nicht prüfbar), einmalig auch der Stand vor der Härtung
* erkannte Sicherheits-Plugins und die Bastora-Härtungen mit Aktiv-Status und erkannten Konflikten
* zu abgewehrten Angriffen: das erkannte Muster, die aufgerufene Adresse, die Kennung des Aufrufers und die Uhrzeit, ausschließlich aus Adresszeile und Kopfdaten des Angriffs
* die Installationsart (self / agency / org) samt Erstwahl
* ein Tagesprofil des letzten vollständigen Tages: je Stunde fünf Zahlen (Seitenaufrufe, Bot-Anfragen, Fehlerseiten, Anmeldeversuche, abgewehrte Angriffe) plus Wochentag und Zeitzone

Nie übertragen werden: Domain, URL, Server-IP, Besucher-IPs, E-Mail-Adressen, Benutzernamen, Beitrags-, Datei- und Datenbank-Inhalte sowie alles, was jemand in ein Formular Deiner Website eingibt. Der Server loggt keine Aufrufer-IP und akzeptiert pro Site-ID höchstens einen Eintrag am Tag. Erweitert eine neue Plugin-Fassung den Umfang, fragt Bastora vorher im Backend nach. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Bei Deinstallation wird die lokale Site-ID gelöscht.

**Einordnung zur Quasi-Eindeutigkeit:** Die Kombination aus Plugin- und Theme-Inventar, Versionen, Hosting-Anbieter und Locale ist statistisch sehr individuell. Auch ohne Domain entsteht damit ein Fingerabdruck der Installation. Bastora wertet die Daten ausschließlich für die Sicherheitsforschung aus (häufigste Lücken, Update-Rückstände, neue Angriffsmuster) und führt sie nie mit anderen Datenquellen zusammen. Wenn das für Dich nicht in Ordnung ist, lass die Einwilligung weg, das Plugin funktioniert ohne sie vollständig.

**6. Rückmeldung an Bastora (nur auf Deinen Klick)**

Der Feedback-Knopf in den Einstellungen schickt Deine Nachricht an bastora.de. Name, Adresse und Website sind freiwillig, wer nur die Nachricht ausfüllt, schreibt anonym. Ohne Klick geht nichts raus.

= Datenschutzhinweis =

Vollständige Datenschutzerklärung: https://www.bastora.de/datenschutz
Verantwortliche Stelle laut Impressum: https://www.bastora.de/impressum
