Bastora Security Audit

Ændringslog

0.3.0

• Neuer Bastora-Schwarm (opt-in). Brute-Force-Angreifer werden anonym zwischen teilnehmenden Bastora-Sites geteilt. Erkennt eine Site einen Login-Bruteforce, schickt sie die Angreifer-IP an bastora.de/api/swarm-report.php. Andere teilnehmende Sites holen die Sperrliste über bastora.de/api/swarm-feed.php ab und blockieren die IP vorbeugend. Aktivierung im Onboarding-Wizard (dritte Opt-in-Karte) oder unter „Einstellungen → Bastora-Schwarm”.
• Versendet werden ausschließlich die Angreifer-IP, der Angriffs-Typ, die Plugin-Version und ein anonymer UUID-Token. Domain, Besucher-IPs, Owner-Daten und Benutzernamen bleiben auf Deinem Server. Der HTTP-User-Agent ist statisch („Bastora-Swarm/Version”), damit WordPress die Domain nicht über den Default-UA mitschickt.
• Bekannte Crawler (Googlebot, Bingbot, Cloudflare-Edges, Yandex, WordPress.org) werden serverseitig nie in die Sperrliste übernommen, damit echte Suchmaschinen niemals geblockt werden.
• Threshold-Logik: eine IP wird erst propagiert, wenn entweder ein einzelner Token sie ≥5 mal meldet ODER mindestens 2 unabhängige Tokens sie je ≥1 mal melden. Verhindert, dass eine kompromittierte Site die Sperrliste vergiften kann.
• Sperrlisten-Einträge verfallen 72 Stunden nach der letzten Meldung. Token können jederzeit über Einstellungen → Deaktivieren abgemeldet werden — der Server löscht den Token unmittelbar.
• Drei neue Server-Endpoints in der Privacy-Sektion vollständig dokumentiert (Register, Report, Feed, Disconnect).
• Beim Deinstallieren des Plugins wird der Token best-effort beim Schwarm-Server abgemeldet, bevor lokale Optionen gelöscht werden.

0.2.9

• Code-Review-Pass nach der Berichts-Entfernung. Verbliebene Referenzen auf die alte Berichts-Klasse geprüft (keine gefunden), Doc-Kommentar zur Kategorien-Reihenfolge auf die jetzigen Ausgaben (Dashboard-Liste, Onboarding-Card) umgeschrieben.

0.2.8

• Druckbarer HTML-Bericht entfernt. Der „Bericht öffnen”-Knopf im Dashboard und die Bericht-Sektion in den Einstellungen sind raus. Der vollständige, gedruckte Sicherheitsbericht bleibt dem Bastora-Schutz-Service vorbehalten. Das Plugin zeigt das Scan-Ergebnis weiterhin als interaktive Liste im Dashboard — alle 53 Audit-Punkte mit Ampel, Klartext-Erklärung und Werkstatt-Link.
• Berichts-Klasse, Berichts-Stylesheet und Berichts-Skript komplett aus dem Plugin entfernt — kleineres Plugin-Paket.

0.2.7

• Klickbare Status-Kacheln als Filter. Klick auf eine der vier Kacheln im Dashboard (Bestanden, Hinweis, Offen, Nicht prüfbar) filtert die Audit-Liste auf nur diesen Status. Erneuter Klick hebt den Filter wieder auf. Es ist immer nur ein Filter aktiv.
• Werkstatt-Link pro Audit-Punkt. Jeder Audit-Punkt zeigt einen kleinen „Lösung in der Werkstatt →”-Link, der direkt zum passenden Artikel auf bastora.de/werkstatt mit Schritt-für-Schritt-Anleitung führt. 52 von 53 Punkten haben einen Einzel-Artikel, der Rest fällt auf die Werkstatt-Übersicht zurück.
• Klartext-Hinweis bei offenen Punkten. Wenn der Audit offene oder Hinweis-Punkte zeigt, erklärt Bastora jetzt sichtbar im Dashboard, warum manche Lücken nicht im Plugin geschlossen werden können (Server-Punkte wie .htaccess, Dateirechte, Security-Header brauchen Hosting-Zugang) und verlinkt auf den Bastora-Schutz-Service als Option.
• Wizard-Häkchen harmonisiert. Das Opt-in-Häkchen heißt jetzt überall (Wizard + Einstellungen + readme.txt) konsistent „Versions-Abgleich erlauben”. Der Hilfetext im Wizard nennt jetzt auch explizit den Kerndatei-Auto-Repair als Folge — vorher las sich das wie ein reiner Plugin-Update-Check.

0.2.6

• Bugfix — Sofort-Trigger nach manuellem Scan funktioniert jetzt wirklich. In 0.2.5 prüfte der Sofort-Trigger fälschlich auf denselben Hook wie der tägliche Cron — der tägliche war meist eingeplant, also wurde der Sofort-Job nie geplant. Jetzt eigener Single-Event-Hook (bastora_core_integrity_oneshot), der unabhängig läuft.
• Bugfix — Cron läuft auch bei stillen Plugin-Updates an. Bestehende Installationen, die per Auto-Update auf 0.2.5 wechseln, bekamen den täglichen Cron nicht eingeplant, weil der Activation-Hook nicht feuert. Ab 0.2.6 stellt das Plugin bei jedem plugins_loaded defensiv sicher, dass der Cron im Schedule liegt.
• Bugfix — Fataler Fehler ohne PHP-ZIP-Extension verhindert. Wenn die ZipArchive-Klasse auf dem Hoster fehlt, gibt Bastora jetzt einen sauberen Fehlerstatus zurück, statt den Cron-Lauf abzubrechen.
• Bugfix — Admin-Mail bei ZIP-Download-Fehler. Konnte die offizielle WordPress-ZIP nicht geladen werden (Beta-Versionen, Netzwerk-Aussetzer), erfuhr der Admin bisher nichts. Jetzt geht eine eigene Mail raus mit Liste der erkannten Dateien.
• Auto-Cleanup des ZIP-Caches bei WordPress-Updates. Beim WP-Update wandert der alte ZIP-Cache jetzt sofort in den Müll, statt 7 Tage als 25-MB-Leiche liegen zu bleiben.
• Neuer Admin-Block: „Kerndatei-Wache” im Einstellungen-Tab. Zeigt den letzten Repair-Status mit Zeitstempel und die letzten drei Repair-Vorgänge mit reparierten Dateinamen. Damit ist die Wache im Backend sichtbar, nicht nur in der Mail.
• Hinweis: Auf Sites ohne regelmäßigen Traffic läuft der WordPress-Cron seltener. Bei sehr stillen Sites bitte einen externen Cron-Trigger einrichten (z.B. den eigenen Hoster-Cronjob) — sonst kann sich der tägliche Repair-Lauf verzögern.

0.2.5

• Auto-Reparatur manipulierter Kerndateien. Der in 0.2.4 eingeführte Kerndatei-Abgleich repariert ab jetzt automatisch. Täglicher Cron-Job (bastora_core_integrity_run) holt die offiziellen Datei-Hashes von api.wordpress.org/core/checksums/1.0/, identifiziert veränderte oder fehlende Kerndateien und ersetzt sie durch die saubere Originalversion aus der offiziellen WordPress-ZIP (downloads.wordpress.org/release/wordpress-X.Y.Z.zip). Die ZIP wird einmal pro Version 7 Tage lokal gecacht, betroffene Dateien werden einzeln extrahiert. Vor dem Ersetzen prüft Bastora den MD5-Hash der extrahierten Datei gegen den erwarteten Wert (Doppel-Sicherung gegen Download-Pannen oder Manipulation der ZIP). Die kompromittierte Originaldatei wandert zur Spurensicherung in wp-content/uploads/bastora-quarantine/JJJJ-MM-TT/. Admin bekommt eine Mail mit der Liste der reparierten Dateien.
• Sofort-Trigger nach manuellem Scan: Wenn Du im Dashboard scannst und Bastora dabei manipulierte Kerndateien entdeckt, plant der Plugin einen Single-Event-Cron in 5 Sekunden — die Reparatur läuft im Hintergrund, ohne den Scan-Request zu blockieren.
• Lock-File gegen parallele Repair-Läufe (wp-content/uploads/bastora-quarantine/.bastora-repair-lock, 10 Minuten Gültigkeit).
• Hoster-Schreibrechte-Erkennung: Wenn der Hoster keinen Schreibzugriff auf das Quarantäne-Verzeichnis erlaubt, fällt Bastora elegant auf Anzeige + Admin-Mail zurück.
• Quarantäne-Verzeichnis wird per .htaccess (Deny from all) gegen Web-Zugriff geschützt.
• Privacy-Sektion erweitert um den neuen ZIP-Download-Endpoint.

0.2.4

• Neuer Audit-Punkt system.11 — Abgleich der WordPress-Kerndateien gegen das offizielle Original. Bastora holt sich von api.wordpress.org/core/checksums/1.0/ die digitalen Fingerabdrücke aller Core-Dateien Deiner WordPress-Version und vergleicht sie mit den Dateien auf Deinem Server. Veränderte oder fehlende Kerndateien werden im Audit-Bericht als kritisch ausgewiesen — der typische Indikator für eingeschleusten Schadcode. Bewusst NICHT geprüft: wp-content/, wp-config.php, readme.html, license.txt. Voraussetzung: Versions-Abgleich-Opt-in aktiv (gleiche Checkbox wie für die Update-Punkte). Ergebnis wird pro WP-Version 24 Stunden zwischengespeichert.
• Punktezahl wächst von 52 auf 53 Punkte. Systemabsicherung-Kategorie hat jetzt 11 statt 10 Punkte.
• Privacy-Sektion in der readme.txt um den neuen Checksums-Endpoint erweitert.

0.2.3

• Plugin-Header-Beschreibung und readme.txt auf Deutsch übersetzt — Plugin-Listing-Seite auf wordpress.org ist damit für die deutsche Zielgruppe lesbar.
• Screenshots-Sektion wieder aufgenommen, vier Bilder ergänzt (Scan-Start, Scan-Ergebnis, Härtung scharf schalten, Dashboard).
• Plugin-Assets (Icon, Banner) im WP.org-Plugin-Verzeichnis aktualisiert.

0.2.2

• Plugin Review Team feedback: all paid-tier markers removed. The dead premium_only_ids() list, the dashboard upsell block, the report’s premium section and the wizard’s paid-service step are gone. The wizard now has three steps (opt-in → scan → activation). No more references to a paid tier inside the plugin code, the admin UI or the printable report.
• Conflict-check marker constant renamed from BASTORA_PRO_SECURITY_LAYER_VERSION to BASTORA_MANAGED_LAYER_VERSION (neutral naming, no Pro/Premium connotation).
• readme.txt: paid-service section removed.
• Telemetry consistency: the opt-in toggle in the welcome wizard and in settings now clearly states that the bastora.de sender pipeline is not active in this plugin version, the toggle only records consent for a future release. readme.txt Privacy section aligned to match.
• Scanner: check_monitor_03 (captcha plugins detection) and check_monitor_07 (security plugin detection) now read active_plugins directly from the option instead of loading wp-admin/includes/plugin.php. One less require_once of a core file.

0.2.1

• Plugin-Name auf „Bastora Security Audit” gekürzt (deckungsgleich mit dem Slug, kein Sonderzeichen im Header).
• Donate link aus readme.txt entfernt (verwies auf die Produktseite, keine echte Spenden-URL).
• == Screenshots ==-Sektion temporär aus readme.txt entfernt. Wird wieder aufgenommen, sobald die Bilder im WordPress-Assets-Verzeichnis liegen.
• MU-Plugin-Konflikt-Check liest jetzt zusätzlich eine Marker-Konstante. Quellcode-Kommentar produktneutral formuliert.

0.2.0

• Neuer Onboarding-Wizard mit schrittweiser Aktivierung der Härtungen plus Vorher-Nachher-Vergleich.
• Härtungen werden erst nach dem ersten Klick auf „Jetzt absichern” im Wizard scharf geschaltet. Davor läuft das Plugin im reinen Mess-Modus.
• Bisheriges Welcome-Banner mit Zwei-Häkchen-Block durch den Wizard ersetzt.

0.1.6

• Plugin Review Team-Feedback: Author URI aus dem Plugin-Header entfernt, da identisch mit Plugin URI. Nur noch eine URI im Header.

0.1.5

• Welcome-Banner und Bericht: Inline-onclick-Handler durch enqueued JavaScript ersetzt (assets/admin.js, assets/js/report.js).
• Inline-style-Attribute im Welcome-Banner und im Login-Honeypot in Utility-Klassen (assets/admin.css, assets/css/login-honeypot.css) ausgelagert.
• Menü-Icon nutzt jetzt das WordPress-Standard-Dashicon dashicons-shield statt eines base64-Inline-SVG.
• $_POST-Werte im Welcome- und Settings-Handler durchlaufen jetzt zusätzlich wp_unslash + sanitize_text_field, auch wenn sie nur als Bool genutzt werden.
• Plugin-Header um Author URI und Domain Path ergänzt.

0.1.4

• Konflikt-Check liest die aktiven Plugins direkt aus der active_plugins-Option und lädt wp-admin/includes/plugin.php nicht mehr unnötig. Vermeidet einen require_once ohne unmittelbar folgenden Funktions-Aufruf.

0.1.3

• Konflikt-Check erkennt jetzt auch MU-Plugin-basierte Sicherheits-Schichten (Marker-Konstanten/Funktionen). Plugin zieht sich automatisch in den überlappenden Bereichen zurück (XML-RPC, REST users, Security Headers, Brute-Force, Honeypot, Application Passwords), damit Filter nicht doppelt feuern und der Bastora-Honeypot auf Whitelabel-Sites unsichtbar bleibt.

0.1.2

• External version-check calls to api.wordpress.org are now opt-in by default. Welcome banner uses two separate checkboxes (external calls + anonymous statistics), each independently toggleable in the settings page.
• Update-related audit points (update.06, update.07, monitor.04) report “not checkable” when the user has not enabled external calls.
• Privacy section in readme.txt expanded with the exact endpoint URLs and opt-in mechanics.

0.1.1

• Text domain aligned with plugin slug (bastora-security-audit)
• Printable report CSS moved from inline style to enqueued stylesheet
• Contributors list corrected to plugin author account

0.1.0

• Initial release
• Scanner covering all 52 audit points
• 11 conflict-aware filter hardenings
• Conflict detection for 13 known security plugins
• Admin dashboard with status card, findings list and hardening overview