Title: Bastora Security Audit
Author: Bastora
Published: June 10, 2026
Last modified: June 30, 2026
---
Search plugins
# Bastora Security Audit
By [Bastora](https://profiles.wordpress.org/mathiasva/)
[Download](https://downloads.wordpress.org/plugin/bastora-security-audit.1.2.5.zip)
* [Details](https://mfe.wordpress.org/plugins/bastora-security-audit/#description)
* [Reviews](https://mfe.wordpress.org/plugins/bastora-security-audit/#reviews)
* [Installation](https://mfe.wordpress.org/plugins/bastora-security-audit/#installation)
* [Development](https://mfe.wordpress.org/plugins/bastora-security-audit/#developers)
[Support](https://wordpress.org/support/plugin/bastora-security-audit/)
## Description
**Bastora** ist ein ehrlicher WordPress-Sicherheits-Check. Statt tausend Schalter
ohne Erklärung prüft Bastora Deine Installation gegen einen festen Katalog aus **
58 Sicherheitspunkten** und zeigt Dir das Ergebnis als Klartext-Ampel direkt in
Deinem Dashboard.
Bastora unterscheidet sich von anderen Sicherheits-Plugins in drei Punkten:
1. **Ehrliche Außensicht.** Bastora prüft Deine Seite so, wie ein Bot sie sieht: Versionslecks
im HTML, offene Verzeichnis-Listen, fehlende Security-Header, sichtbare Endpoints.
Die meisten anderen Plugins prüfen nur ihre eigene Konfiguration.
2. **Konflikt-erkennende Auto-Härtung.** Härtungen sind ab Werk aktiv. Bastora prüft,
ob ein anderes Sicherheits-Plugin (Wordfence, Solid Security, AIOS, Limit Login
Attempts und andere) denselben Punkt schon übernimmt, und tritt elegant zur Seite,
statt einen Konflikt zu bauen.
3. **Null Konfiguration.** Installieren, aktivieren, einmal „Sicherheitsprüfung starten”
klicken, fertig. Bastora richtet sich selbst ein.
#### Was Bastora prüft
* **Zugangssicherheit (11 Punkte):** HTTPS-Login, Brute-Force-Schutz, Salt-Keys,
geteilte Konten, Login-Verhalten
* **Systemabsicherung (13 Punkte):** Datei-Editor, Verzeichnis-Listings, wp-config-
Sperre, Debug-Modus, Dateirechte, Revisionen, **Kerndatei-Abgleich gegen das
Original von wordpress.org mit automatischer Reparatur**, **täglicher Abgleich
aller Plugins gegen wordpress.org**, **täglicher Abgleich aller Themes gegen
wordpress.org**
* **Informationsschutz (10 Punkte):** Generator-Tag, RSD-Link, WLW-Manifest, XML-
RPC, REST-API-Benutzer, Pingbacks, X-Powered-By
* **Security-Header (5 Punkte):** X-Frame-Options, X-Content-Type-Options, Referrer-
Policy, Permissions-Policy, HSTS
* **Pingbacks (2 Punkte):** ausgehende und eingehende Pingbacks
* **Auto-Updates (7 Punkte):** nächtlicher Schutz, Minor-/Major-Auto-Updates, Plugin-/
Theme-Auto-Updates, verwaiste Erweiterungen
* **Monitoring und Betrieb (7 Punkte):** Transients, Revisions-Cleanup, Captcha,
WordPress-Version, PHP-Version, /uploads/-PHP-Sperre, Sicherheits-Plugin-Status
#### Was Bastora härtet (wenn kein Konflikt erkannt wird)
* WordPress-Version aus HTML und RSS-Feed entfernt
* RSD-Link und WLW-Manifest entfernt
* Login-Shake-Effekt deaktiviert
* Login-Fehlermeldung verallgemeinert (verrät nicht mehr, welche Benutzer existieren)
* Author-Seiten umgeleitet (verhindert das Aufzählen von Benutzernamen)
* XML-RPC abgeschaltet (außer ein konkurrierendes Plugin übernimmt das schon)
* Pingback-XML-RPC-Methoden gesperrt
* REST-API-Endpoint /users für nicht eingeloggte Anfragen gesperrt
* Application Passwords deaktiviert
* **Login-Honeypot:** verstecktes Formularfeld in der Login-Maske, das Bots ausfüllen
und sich damit als Bot zu erkennen geben
* **Brute-Force-Schutz mit IP-Sperre:** 5 Fehlversuche 30 Minuten Sperre. Bei
wiederholten Sperren: Eskalation auf 4 Stunden, dann 24 Stunden. Zähler setzt
sich nach erfolgreichem Login zurück. IPv6 wird auf dem /64-Präfix gesperrt.
Cloudflare- und Reverse-Proxy-IP-Erkennung ist eingebaut.
* **Kerndatei-Auto-Reparatur:** Bastora vergleicht täglich Deine WordPress-Kerndateien
mit den offiziellen Hashes von wordpress.org. Wird eine Datei manipuliert oder
fehlt, lädt Bastora die saubere Originaldatei aus der offiziellen WordPress-ZIP,
validiert ihren Hash doppelt und ersetzt die kompromittierte Version automatisch.
Die alte Datei wandert zur Spurensicherung in `wp-content/uploads/bastora-quarantine/`.
Du bekommst eine E-Mail mit der Liste der reparierten Dateien. Voraussetzung:
Versions-Abgleich-Opt-in aktiv. Bei Hostern mit schreibgeschützten Core-Dateien
bleibt die Anzeige + Mail erhalten.
* **Bastora-Schwarm (opt-in):** Sobald eine teilnehmende Bastora-Website einen
Brute-Force-Angriff erkennt, wandert die Angreifer-IP anonym in einen geteilten
Sperrkatalog. Deine Seite holt diesen Katalog alle paar Minuten ab und blockiert
die IPs, bevor sie überhaupt anklopfen. Im Gegenzug meldet Deine Seite Angreifer,
die Du erkennst. Versendet wird ausschließlich die Angreifer-IP samt Angriffs-
Typ und ein anonymer UUID-Token, keine Domain, keine Besucher-IPs, keine Owner-
Daten. Aktivierung erfolgt im Onboarding-Wizard oder unter Einstellungen.
#### Konflikt-erkennend
Wenn eines der folgenden Plugins schon läuft, erkennt Bastora das und deaktiviert
nur die überlappenden Bereiche:
* Wordfence Security
* Sucuri Security
* Solid Security (früher iThemes)
* All-In-One WP Security & Firewall
* MalCare Security
* WP Cerber Security
* Limit Login Attempts Reloaded
* Disable XML-RPC
* Disable Application Passwords
* Really Simple SSL
* HTTP Headers
Im Dashboard siehst Du pro Härtung im Klartext, warum sie aktiv oder inaktiv ist.
#### 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 in der Mail kaputt, sobald das Plugin deaktiviert wird. Rate-Limit
plus Honeypot ist die saubere Lösung.
* **Keine Cloud-Verbindung ohne Zustimmung.** Alle externen Verbindungen (auch
Versions-Abgleich gegen wordpress.org) sind ab Werk aus. Sie schalten sich erst
ein, wenn Du sie im Welcome-Wizard oder in den Einstellungen ausdrücklich freigibst.
#### Optionale anonyme Statistik (Opt-in)
Wenn Du das Häkchen „Statistik aktivieren und teilen” in den Einstellungen setzt,
schickt Bastora einmal sofort und danach nur alle 28 Tage eine kompakte anonyme
Zusammenfassung per HTTPS-POST an `https://bastora.de/v1/telemetry/`. Vor dem Häkchen
geht kein einziger Request raus. Die niedrige Frequenz ist bewusst: Bastora will
Masse-Infos über viele Sites sammeln, kein dichtes Zeitprofil einzelner Sites.
Übertragen werden ausschließlich:
* Eine zufällige anonyme Site-ID (UUID), lokal beim ersten Plugin-Start erzeugt
* Plugin-Version, WordPress-, PHP- und MySQL-Versions-Strings
* Locale (zum Beispiel de_DE)
* Multisite-Flag (ja/nein)
* Liste der installierten Plugin-Slugs (max. 200, ohne Versionen)
* Audit-Score und Counter pro Status (bestanden / Hinweis / offen / nicht prüfbar)
Was **nie** übertragen wird: Domain, URL, IP-Adresse, E-Mail-Adressen, Benutzernamen,
Beitragsinhalte, Dateiinhalte, Plugin-Versionen pro Slug. Der bastora.de-Server
loggt keine Aufrufer-IP. Pro Site-ID wird maximal ein Eintrag pro Tag akzeptiert(
UPSERT), die normale Sende-Frequenz pro Site liegt ohnehin bei einem Datensatz alle
28 Tage. Bei Deinstallation des Plugins werden die lokale Site-ID und alle Bastora-
Optionen entfernt.
### Privacy
#### Externe Verbindungen
Bastora kontaktiert externe Server in zwei klar getrennten Fällen. **Beide sind
opt-in. Ab Werk macht das Plugin keine externen Verbindungen.**
**1. Versions-Abgleich gegen api.wordpress.org (opt-in)**
Wenn Du im Welcome-Wizard oder in den Einstellungen „Versions-Abgleich erlauben”
aktivierst, fragt Bastora bei einem manuellen Scan die api.wordpress.org nach:
* der aktuellen WordPress-Core-Version: `https://api.wordpress.org/core/version-
check/1.7/`
* den offiziellen Datei-Hashes der installierten WordPress-Version (für den Kerndatei-
Abgleich): `https://api.wordpress.org/core/checksums/1.0/?version=&locale
=en_US`
* pro erkennbarem Plugin nach dessen letztem Update-Datum: `https://api.wordpress.
org/plugins/info/1.0/.json`
* pro erkennbarem Theme nach dessen letztem Update-Datum: `https://api.wordpress.
org/themes/info/1.2/?action=theme_information&request[slug]=`
Wenn Bastora bei der täglichen Prüfung manipulierte oder fehlende Kerndateien entdeckt,
lädt Bastora zusätzlich die offizielle WordPress-ZIP herunter, um die saubere Originaldatei
zu extrahieren:
* `https://downloads.wordpress.org/release/wordpress-.zip`
Die ZIP wird einmal pro Version 7 Tage lokal in `wp-content/uploads/bastora-quarantine/
_core-cache/` gespeichert, um wiederholten Bandbreitenverbrauch zu vermeiden. Vor
dem Ersetzen einer Datei prüft Bastora deren MD5-Hash gegen den von api.wordpress.
org gemeldeten Wert (Doppel-Sicherung gegen Download-Pannen).
Ab Plugin-Version 0.4.0 lädt Bastora für die tägliche Plugin- und Theme-Wache zusätzlich
pro installiertem Plugin/Theme die offizielle ZIP aus dem WordPress.org-Repository,
um die einzelnen Dateien gegen das Original abzugleichen:
* `https://downloads.wordpress.org/plugin/..zip`
* `https://downloads.wordpress.org/theme/..zip`
Die ZIPs werden 7 Tage lokal in `wp-content/uploads/bastora-quarantine/_asset-cache/`
gespeichert. Plugins und Themes, die NICHT im offiziellen WordPress.org-Repository
liegen (z.B. Premium-Plugins, Custom-Themes), werden als „extern, nicht prüfbar”
markiert, es geht kein Request raus außer dem ersten API-Lookup, der mit 404 antwortet
und das Ergebnis 24 Stunden zwischenspeichert. Eine automatische Reparatur findet
bei Plugins und Themes bewusst NICHT statt; bei Funden bekommst Du eine Admin-Mail
mit der Liste der abweichenden Dateien.
Das ist dieselbe API, die WordPress selbst für seine eigenen Update-Checks nutzt.
Übertragen wird nur der Slug pro Plugin oder Theme. Keine Domain, keine Nutzerdaten,
keine Besucher-IP. Die Abfragen laufen nur bei manuellem Klick auf den Scan-Button,
nie automatisch im Hintergrund. Antworten werden 24 Stunden zwischengespeichert.
Wenn Du diesen Punkt nicht aktivierst, werden die update-relevanten Audit-Punkte
als „nicht prüfbar” markiert und es geht keine Anfrage raus.
**2. Bastora-Schwarm (opt-in, ab Plugin-Version 0.3.0)**
Wenn Du den Bastora-Schwarm im Welcome-Wizard oder unter „Einstellungen Bastora-
Schwarm” aktivierst, tauscht das Plugin Brute-Force-Angreifer-IPs anonym mit anderen
teilnehmenden Sites aus. Drei Endpoints sind beteiligt:
* `https://bastora.de/api/swarm-register.php`, Einmaliger POST beim Aktivieren.
Der Server vergibt einen anonymen UUID-Token. Übertragen wird: die Plugin-Version.
Nicht übertragen wird: Domain, URL, IP-Adresse Deiner Besucher, Owner-Daten.
Die Server-IP des HTTP-Requests wird nur als gesalzener SHA-256-Hash für ein
Rate-Limit gespeichert und ist nicht zurückrechenbar.
* `https://bastora.de/api/swarm-report.php`, POST bei Erkennung eines Brute-Force-
Angriffs. Übertragen wird: der anonyme Token, die Angreifer-IP, der Angriffs-
Typ („login_bruteforce”), die Severity, die Plugin-Version. Nicht übertragen
wird: alles andere.
* `https://bastora.de/api/swarm-feed.php`, GET-Abruf der aktuellen Sperrliste,
alle 5 Minuten via WP-Cron plus on-demand bei Login-Versuchen, jeweils mit 60-
Sekunden-Cache und ETag-Optimierung. Im HTTP-Header geht der anonyme Token mit,
sonst nichts.
* `https://bastora.de/api/swarm-disconnect.php`, POST beim Opt-out in den Einstellungen
oder beim Deinstallieren. Übertragen wird: der anonyme Token. Der Server löscht
den Knoten unmittelbar.
Der HTTP-User-Agent ist bei allen vier Endpoints statisch „Bastora-Swarm/”, damit
WordPress die Domain nicht über den Default-UA mitschickt. Rechtsgrundlage ist Art.
6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Angriffsabwehr). Eingegangene Reports
werden serverseitig nach 14 Tagen automatisch gelöscht (Datenminimierung). Sperrlisten-
Einträge verfallen nach 72 Stunden ohne neue Meldungen.
**Pwned-Passwords-Abgleich (Opt-in, nur Backend-Login)**
Wenn Du in den Einstellungen den Passwort-Leak-Check aktivierst, schickt Bastora
bei jedem Backend-Login (max. 1× pro 7 Tage pro Nutzer) die ersten fünf Hex-Zeichen
des SHA-1-Hashes Deines eingegebenen Passworts an `https://bastora.de/v1/pwned/<
prefix>`. Übertragen wird ausschließlich dieses 5-Zeichen-Prefix. Nicht übertragen
wird: das Passwort selbst, das vollständige Hash, der Nutzername, die Domain, irgendeine
ID. Der bastora.de-Proxy fragt die offizielle haveibeenpwned.com-API mit dem Prefix
an, cached das Ergebnis 7 Tage lokal in einer deutschen MySQL-Datenbank und schickt
die Liste der Hash-Suffixe zurück. Der Abgleich passiert lokal in WordPress. Das
Verfahren heißt k-Anonymity und wird auch von 1Password, Firefox und Chrome genutzt.
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO. Bei Treffer wird der Nutzer im Backend
per Notice aufgefordert, das Passwort zu ändern, der Login wird nie blockiert.
**Schad-URL-Feed (Opt-in)**
Wenn Du den Schad-URL-Feed in den Einstellungen aktivierst, holt Bastora einmal
pro Tag eine aktualisierte Domain-Liste von `https://bastora.de/v1/url-feed/`. Übertragen
wird ausschließlich ein anonymer GET-Request, optional mit dem Zeitstempel des letzten
erfolgreichen Abrufs als `?since=`, damit nur neu hinzugekommene Einträge
geliefert werden. Es geht keine Domain Deiner Seite, keine Besucher-Daten und kein
Identifier raus. Die Antwort ist eine reine JSON-Liste mit Schad-Domain, Typ („malware”
oder „phishing”) und Severity, sie enthält keinen ausführbaren Code. Quellen, die
der Bastora-Server aggregiert: URLhaus (abuse.ch, CC0 1.0) und der OpenPhish-Community-
Feed. Die Liste wird lokal in einer WP-Option gespeichert (Hard-Cap 50 000 Einträge,
30 Tage Plugin-seitige TTL) und vom URL-Watch-Modul zusätzlich zur eingebauten Startliste
für die Prüfung von Beiträgen und Kommentaren genutzt. Rechtsgrundlage: Art. 6 Abs.
1 lit. f DSGVO. Vor dem Opt-in-Häkchen wird kein einziger Aufruf an `bastora.de/
v1/url-feed/` ausgeführt.
**Anonyme Sicherheits-Telemetrie an bastora.de (Opt-in)**
Wenn Du in den Einstellungen den Schalter „Statistik aktivieren und teilen” setzt,
schickt Bastora einmal sofort und danach nur alle 28 Tage einen JSON-POST an `https://
www.bastora.de/v1/telemetry/`. Vor dem Häkchen wird **kein** Aufruf ausgeführt.
Ab Plugin-Version 1.0.3 ist das Datenpaket bewusst umfangreicher, damit Bastora
das gemeinsame Bedrohungsbild für die WordPress-Welt schärfen kann. Die niedrige
Frequenz ist bewusst: Bastora will Masse-Infos über viele Sites sammeln, kein dichtes
Zeitprofil einzelner Sites. Übertragen wird:
* Eine zufällige anonyme Site-ID (UUID), lokal beim ersten Plugin-Start erzeugt
* Bastora-Plugin-Version
* WordPress-Version + die zum Zeitpunkt der Erfassung aktuelle Core-Version + Update-
Status (ja/nein)
* PHP- und MySQL-Versions-Strings
* Server-Software-String (z.B. „Apache/2.4″)
* Anonymer Hosting-Provider-Slug (z.B. „hetzner”, „ionos”, „kinsta”), ermittelt
aus Konstanten-Markern bekannter Managed-Hoster, Reverse-DNS auf die Server-IP,
sowie DOCUMENT_ROOT-Pfad-Pattern. Die Server-IP selbst wird NICHT gesendet.
* Locale (zum Beispiel de_DE), Zeitzone, Multisite-Flag
* Pro installiertem Plugin: Slug, installierte Version, Autor, neueste verfügbare
Version (Quelle: api.wordpress.org-Cache), ob Update bereitsteht, ob Auto-Update
aktiv ist, ob Plugin aktiv oder inaktiv. Max. 200 Plugins.
* Pro installiertem Theme: Slug, installierte Version, Autor, neueste verfügbare
Version, Update-Status, Auto-Update, Eltern-Theme bei Child-Themes. Max. 75 Themes.
* Aktives Theme: Slug, Version, Autor, Eltern-Theme
* User-Counts pro Rolle (nur Zahlen, keine Namen oder Mails)
* Content-Counts: Anzahl veröffentlichter Beiträge, Seiten, Kommentare (total /
approved / spam)
* WordPress-Konfigurations-Flags: WP_DEBUG, DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS,
FORCE_SSL_ADMIN, geschätzte autoload-Options-Größe in KB
* Audit-Summary (Counter pro Status) + Audit-Findings-Map: pro Audit-Punkt-ID ein
kompakter Status-Code (0=bestanden, 1=Hinweis, 2=offen, 3=nicht prüfbar). Damit
wertet die Server-Statistik die häufigsten Sicherheitslücken aus.
* Erkannte Sicherheits-Plugins mit Klassifizierung free / Pro / lizenz-aktiviert(
z.B. Wordfence Free vs. Wordfence Premium per API-Key-Konstante)
* Bastora-eigene Härtungs-Schalter mit Aktiv-Status und erkannten Konflikten (welche
Bereiche andere Sicherheits-Plugins schon übernehmen)
Was **nie** übertragen wird: Domain, URL, Server-IP, Besucher-IPs, E-Mail-Adressen,
Benutzernamen, Beitragsinhalte, Datei-Inhalte, Datenbank-Inhalte. Der bastora.de-
Server loggt keine Aufrufer-IP. Pro Site-ID akzeptiert der Server maximal einen
Eintrag pro Tag (UPSERT, der jeweils neueste Stand bleibt). Rechtsgrundlage: Art.
6 Abs. 1 lit. f DSGVO. Bei Deinstallation des Plugins wird die lokale Site-ID gelöscht.
**Wichtige Einordnung zur Quasi-Eindeutigkeit:** Die Kombination aus Plugin-Inventar,
Theme-Inventar, jeweiligen Versionen, Hosting-Provider-Slug und Locale ist statistisch
sehr individuell. Auch ohne Domain entsteht damit ein „Fingerprint” der Installation.
Bastora nutzt die Daten ausschließlich für die anonyme Statistik (häufigste Plugins,
häufigste Lücken, Update-Rückstände) und führt die Telemetrie-Datenbank nie mit
anderen Datenquellen zusammen. Wenn diese Einordnung für Dich nicht akzeptabel ist,
lass das Telemetrie-Häkchen leer , das Plugin funktioniert auch ohne.
**Lokale DNS-Anfrage zur Hosting-Provider-Erkennung (nur als Teil der Telemetrie-
Funktion)**
Wenn die Telemetrie aktiv ist, ermittelt Bastora einmalig den anonymen Hosting-Provider-
Slug (z.B. „hetzner”, „ionos”, „kinsta”). Dafür ruft Bastora die lokale PHP-Funktion`
gethostbyaddr()` mit der eigenen Server-IP auf, was eine PTR-Anfrage am Resolver
des Hosters auslöst. Es geht KEIN Aufruf an einen Bastora-eigenen Server, keine
externe API und keine Domain raus, nur die normale lokale Namensauflösung am Hoster-
DNS. Das Ergebnis wird 30 Tage in einer WP-Option zwischengespeichert, damit das
nur einmal alle 30 Tage passiert. Vor dem Telemetrie-Opt-in läuft auch diese Funktion
nicht.
#### Datenschutzhinweis
Vollständige Datenschutzerklärung: https://bastora.de/datenschutz.php
Verantwortliche
Stelle laut Impressum: https://bastora.de/impressum.php
## Screenshots
[⌊Der erste Scan startet, Bastora prüft 58 Sicherheitspunkte in etwa 25 Sekunden.⌉⌊
Der erste Scan startet, Bastora prüft 58 Sicherheitspunkte in etwa 25 Sekunden.⌉[
Der erste Scan startet, Bastora prüft 58 Sicherheitspunkte in etwa 25 Sekunden.
[⌊Ergebnis des ersten Scans: Score plus klare Aufteilung in bestanden, Hinweise
und offene Punkte.⌉⌊Ergebnis des ersten Scans: Score plus klare Aufteilung in bestanden,
Hinweise und offene Punkte.⌉[
Ergebnis des ersten Scans: Score plus klare Aufteilung in bestanden, Hinweise und
offene Punkte.
[⌊Bastora schaltet die Härtungen scharf, wo ein anderes Sicherheits-Plugin schon
zuständig ist, lässt Bastora die Hand davon.⌉⌊Bastora schaltet die Härtungen scharf,
wo ein anderes Sicherheits-Plugin schon zuständig ist, lässt Bastora die Hand davon
.⌉[
Bastora schaltet die Härtungen scharf, wo ein anderes Sicherheits-Plugin schon zuständig
ist, lässt Bastora die Hand davon.
[⌊Das Dashboard nach Aktivierung: aktueller Sicherheits-Score und jeder Prüfpunkt
mit Klartext-Erklärung.⌉⌊Das Dashboard nach Aktivierung: aktueller Sicherheits-Score
und jeder Prüfpunkt mit Klartext-Erklärung.⌉[
Das Dashboard nach Aktivierung: aktueller Sicherheits-Score und jeder Prüfpunkt
mit Klartext-Erklärung.
## 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.
## FAQ
### Brauche ich technisches Wissen, um Bastora zu nutzen?
Nein. Bastora braucht keine Konfiguration. Installieren, aktivieren, scannen, fertig.
### Funktioniert Bastora neben Wordfence/Sucuri/Solid Security?
Ja. Bastora erkennt diese Plugins beim Aktivieren und tritt in den überlappenden
Bereichen zur Seite. Das Dashboard zeigt Dir, welche Härtungen wegen eines Konflikts
inaktiv sind.
### Überträgt das Plugin Daten von meiner Seite?
Ab Werk nichts. Externe Verbindungen schaltest Du in den Einstellungen einzeln frei:
Versions-Abgleich gegen api.wordpress.org, Bastora-Schwarm, Schad-URL-Feed, Passwort-
Leak-Check, anonyme Statistik. Jede dieser Verbindungen ist standardmäßig aus und
sendet erst nach Deinem Häkchen Daten.
### Wie nehme ich die anonyme Statistik wieder zurück?
Bastora Einstellungen Häkchen bei „Statistik aktivieren und teilen” raus speichern.
Der tägliche Cron wird sofort gestoppt, ab da geht kein Eintrag mehr an bastora.
de. Die bereits gesammelten Datensätze werden serverseitig nicht von uns rückwirkend
gelöscht, weil sie keinen Bezug zu Deiner Domain haben (nur eine zufällige UUID).
### Wo werden die Daten gespeichert?
Auf deutschen Servern. Bastora arbeitet ausschließlich mit einem deutschen Hoster.
### Was passiert, wenn ich Bastora deinstalliere?
Bei normaler Deaktivierung bleiben die Bastora-Einstellungen erhalten. Wenn Du das
Plugin per „Löschen” entfernst, werden alle Einstellungen, Audit-Ergebnisse und
Site-IDs gelöscht. Härtungen werden automatisch zurückgerollt. Bei aktivem Schwarm-
Schutz meldet das Plugin den anonymen Token vorher beim Schwarm-Server ab.
### Wie funktioniert der Bastora-Schwarm?
Der Bastora-Schwarm ist ein opt-in-basierter Pool aus teilnehmenden Bastora-Sites.
Erkennt eine Site einen Brute-Force-Angriff (5 fehlgeschlagene Logins von derselben
IP), schickt sie die Angreifer-IP samt Angriffs-Typ anonym an einen zentralen Server.
Wenn mehrere unabhängige Sites dieselbe IP melden oder eine einzelne Site dieselbe
IP häufig meldet, wandert die IP in einen Sperrkatalog. Alle teilnehmenden Sites
holen diesen Katalog alle paar Minuten ab und sperren die IPs vorbeugend. Eintragungen
verfallen automatisch nach 72 Stunden, falls keine neuen Meldungen reinkommen. Bekannte
Crawler (Googlebot, Bingbot, Cloudflare etc.) werden serverseitig nie übernommen,
damit sie nicht versehentlich gesperrt werden.
### Welche Daten verlassen meine Seite, wenn der Schwarm aktiv ist?
Ausschließlich: die Angreifer-IP, der Angriffs-Typ („login_bruteforce”), die Bastora-
Plugin-Version und ein anonymer UUID-Token, der beim Aktivieren einmalig generiert
wurde. Nicht versendet werden: Deine Domain, Deine URL, Deine Besucher-IPs, Deine
Benutzernamen, Deine E-Mail-Adresse, irgendetwas zu Deiner Konfiguration. Auch der
HTTP-User-Agent ist statisch („Bastora-Swarm/Version”), damit WordPress die Domain
nicht über den Standard-UA mitschickt. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f
DSGVO (berechtigtes Interesse an Angriffsabwehr).
## Reviews
There are no reviews for this plugin.
## Contributors & Developers
“Bastora Security Audit” is open source software. The following people have contributed
to this plugin.
Contributors
* [ Bastora ](https://profiles.wordpress.org/mathiasva/)
[Translate “Bastora Security Audit” into your language.](https://translate.wordpress.org/projects/wp-plugins/bastora-security-audit)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/bastora-security-audit/),
check out the [SVN repository](https://plugins.svn.wordpress.org/bastora-security-audit/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/bastora-security-audit/)
by [RSS](https://plugins.trac.wordpress.org/log/bastora-security-audit/?limit=100&mode=stop_on_copy&format=rss).
## Changelog
#### 1.2.5
* **Sieben Audit-Punkte sind als „Pro-Feature” markiert,** weil sie strukturell
nur über den Bastora-Schutz-Service mit MU-Plugin lösbar sind: Dateirechte, X-
Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, HSTS,
PHP-Sperre für das uploads-Verzeichnis. Sie zählen mit Gewichtung null im Score,
der maximale Free-Score liegt damit unter 100. Jede Pro-Markierung kommt mit
einem Klartext-Satz, warum dieser Punkt am Web-Server sitzt und im Pro vom MU-
Plugin verwaltet wird.
#### 1.2.4
* **WAF, Schadcode-Scanner und Aktivitäts-Log werden erst beim Wizard-Schritt scharf,
nicht mehr beim Plugin-Activate.** Vorher liefen die drei Module ab dem Moment,
wo Du das Plugin aktiviert hast , das hat den ersten Audit-Scan geschönt, weil
der WAF-Schutz schon stand bevor Du gemessen hast. Ab jetzt: der erste Scan zeigt
ehrlich die Lage Deiner Site vor Bastora, der zweite Scan nach dem Wizard zeigt
den echten Sprung. Bestands-Sites mit bereits abgeschlossenem Setup werden per
Migration einmalig auf den neuen Aktiv-Marker gehoben, das Plugin läuft dort
unverändert weiter.
* **Audit-Score zählt jetzt „nicht prüfbar”-Punkte mit 0.5 Gewicht** statt sie
komplett aus der Berechnung auszuschließen. Vorher konnte ein Score von 100 vorgegaukelt
werden, wenn der User zwar 10 von 58 Punkten bestanden hatte, aber 48 wegen fehlender
Opt-ins als „nicht prüfbar” markiert waren. Jetzt ist der Score ehrlich.
* **Werkstatt-Links ohne Ziel-Artikel werden weggelassen,** statt auf eine generische
Übersichtsseite zu zeigen. Sechs Audit-Punkte (system.11/12/13/14/15, monitor.
08) haben noch keinen dezidierten Artikel, bei denen erscheint jetzt einfach
kein Link , das ist ehrlicher als ein irreführender Verweis.
#### 1.2.3
* **Rollback Tested up to 7.0.** Die in 1.2.2 fälschlich auf 6.7 gesetzte Angabe
ist zurück auf 7.0.
* **Audit-Punkt zugang.08 sauberer geprüft.** Statt der semantisch leeren Prüfung
auf `has_filter('authenticate_username_password')` jetzt der korrekte Check auf`
has_filter('authenticate', 'wp_authenticate_email_password')`. Damit erkennt
der Audit echte Deregistrierungen des E-Mail-Login-Default und nicht bloß irgendwelche
fremden Filter-Hooks.
* **Audit-Punkt monitor.03 präziser.** Bisher prüfte der Check nur das Honeypot-
Härtungs-Flag und behauptete dabei trotzdem vier Schichten. Jetzt prüft der Check
den Setup-Complete-Marker plus die Existenz der Bastora_Captcha-Klasse, das ist
der korrekte Indikator für das Vier-Schichten-Captcha (Honeypot, Time-Trap, JS-
Proof-of-Work, Math-Fallback ab dem dritten Login-Fehler).
#### 1.2.2
* **Bugfix Telemetrie-Option.** Die Telemetrie hat die Option `bastora_external_calls_enabled`
geprüft, korrekt hieß sie schon immer `bastora_external_calls_allowed`. Folge:
die latest-Version-Felder der Plugin- und Theme-Inventur blieben leer, weil der
Update-Check nicht angestoßen wurde. Plus das Telemetrie-Payload meldete `external_calls`
immer als aus. Gefixt.
* **Quick-Action Auto-Updates ohne 25-Sekunden-Hänger.** Der Klick auf „Auto-Updates
für alle Themes/Plugins aktivieren” lief vorher synchron durch einen kompletten
Re-Scan, was bis zu 25 Sekunden Admin-Lockup bedeutete. Jetzt patcht Bastora
den betroffenen Audit-Punkt direkt im Scan-Cache und antwortet sofort.
* **Tested up to** auf 6.7 korrigiert (war fälschlich 7.0).
* **Texte aufgeräumt.** „Scharf schalten” überall ersetzt durch „aktivieren”. Status-
Karten der Wachen vereinheitlicht (kürzer, ohne Architektur-Lecks, „andere Bastora-
Sites” durch „Schwarm-Netzwerk” ersetzt). Negationen aus update.04 und update.
05 raus. Child-Theme-Hinweis in update.05 für Laien lesbar formuliert. Pwned-
Erklärung präzisiert: „nur ein anonymer Hash” statt „verschlüsselt”.
#### 1.2.1
* **Quick-Action im Audit-Finding update.04 und update.05.** Wenn Plugin- oder
Theme-Auto-Updates noch nicht aktiv sind, steht im Detail des jeweiligen Audit-
Punktes ein Knopf „Auto-Updates für alle Plugins (bzw. Themes) aktivieren”. Ein
Klick setzt eine Bastora-Option, Bastora registriert beim nächsten Page-Load
den entsprechenden WordPress-Core-Filter (auto_update_plugin / auto_update_theme),
und der Audit-Punkt springt im sofortigen Re-Scan auf grün.
* Werkstatt-Artikel zu update.05 präzisiert. Die irreführende „wie bei Plugins”-
Formulierung ist raus, plus klarer Hinweis: Bei aktivem Child-Theme zeigt das
WordPress-Backend keinen Auto-Update-Schalter beim Child, sondern beim Parent-
Theme. Bastora-Quick-Action umgeht diesen Pfad und setzt den Filter global.
* Plugin-Audit-Text für update.05 ergänzt um den Child-Theme-Hinweis.
#### 1.2.0
* **UI radikal reduziert.** Die Submenüs „Firewall”, „Verkehr & Sperren”, „Aktivität”
und „Datei-Inspektor” sind weg. Es gibt jetzt nur noch Dashboard, Härtung, Einstellungen
und den Pro-Tab im Header. Endkunde soll sehen: läuft. Mehr nicht. Memory feedback_bastora_pitch_sorgenfreiheit.
md.
* **Härtungs-Seite zeigt die sieben Bastora-Wachen** (Web Application Firewall,
Bot-Schutz, Schadcode-Scanner, Kerndatei-Wache, Plugin- und Theme-Wache, Schwarm-
Schutz, Schad-URL-Liste) jeweils mit „Aktiv”, „Inaktiv” oder „Inaktiv (Konflikt)”.
Keine Zahlen, keine Trefferzähler, keine Protokoll-Tabellen.
* Funktionen laufen unverändert weiter: WAF prüft jede Anfrage, Block-Rules sperren,
Audit-Log loggt sicherheitsrelevante WP-Aktionen, Asset- und Core-Integrity laufen
täglich. Die Daten gehen in das 28-Tage-Telemetrie-Aggregat an die zentrale Bastora-
Datenbank.
* Dashboard-Status-Karten der Wachen sind vom Dashboard auf die Härtungs-Seite
gewandert, dort ohne Zahlen.
#### 1.1.2
* **Dashboard-Texte abgespeckt.** Die Übergangs-Anzeigen der Schad-URL-Liste und
des Schwarm-Schutzes nennen keine Quellen-Namen mehr und sind kurz wie ehrlich(„
Bastora baut die Schutzliste im Hintergrund auf. In den nächsten Minuten siehst
Du hier die Zahlen.”)
* **Schwarm-Sperrliste serverseitig mit anerkannten Bad-IP-Quellen vorgefüllt.**
Sechs öffentlich frei zugängliche Bedrohungslisten (BlocklistDE Login/SSH/Mail,
CINSScore, GreenSnow, FireHOL Level 1) werden alle 6 Stunden auf bastora.de aggregiert
und in die zentrale Sperrliste eingespeist. Damit liefert jede frisch aktivierte
Bastora-Free-Installation ab dem ersten Schwarm-Pull eine substantielle Sperrliste,
statt bei null IPs zu starten.
#### 1.1.1
* **Wizard-Loader erweitert um sechs zusätzliche Hintergrund-Wachen.** Bisher hat
der „Härtung scharf schalten”-Loader nur die 13 klassischen Filter-Härtungen (
Generator-Tag, RSD-Link, XML-RPC, REST-Users, Honeypot, Brute-Force usw.) gezeigt.
Ab 1.1.1 laufen sechs weitere Schritte in der gleichen AJAX-Choreografie sichtbar
mit: Bot-Schutz, WAF, Aktivitäts-Log, Schadcode-Scanner, Kerndatei-Wache und
Plugin/Theme-Wache. Jeder Schritt hat eigene Konflikt-Erkennung (z.B. Bot-Schutz
zieht sich bei aktivem Wordfence/Cerber/StopBadBots zurück), die Wachen, die
Versions-Abgleich-Opt-in brauchen (Kerndatei + Plugin/Theme), zeigen einen freundlichen
Hinweis, wenn das Häkchen fehlt. Bot-Schutz wird im Wizard echt aus dem Default„
aus” auf „an” geschaltet.
* **Dashboard-Karten Schad-URL-Liste und Schwarm-Schutz** zeigen jetzt einen ehrlichen
Übergangs-Text, solange der erste Pull noch ansteht, statt einer nackten „0 Domains”/„
0 IPs”. Plus: nach dem Wizard-Finish wird der erste URL-Feed-Pull schon nach
10 Sekunden statt 60 Sekunden angestoßen, und der Schwarm pullt sofort.
* Formulierungsfix: Settings-Hilfetext für KI-Bot-Häkchen redet jetzt von „setze
das Häkchen” statt von einem Schieberegler.
#### 1.1.0
* **Neuer Bot-Schutz mit vierstufiger Klassifikation.** Suchmaschinen-Crawler (
Google, Bing, DuckDuckGo, Yandex, Apple, Mojeek, Baidu) und Social-Preview-Bots(
Facebook, X, LinkedIn, WhatsApp, Telegram, Discord, Pinterest, Mastodon) werden
automatisch verifiziert (Forward-Confirmed Reverse-DNS) und nie blockiert. Vulnerability-
Scanner und Spam-Bots (Nikto, sqlmap, Acunetix, Nessus, Burp, OWASP-ZAP, masscan,
Shodan, HTTrack und 40 weitere) werden gesperrt. Drei Häkchen in den Einstellungen:
Bot-Schutz an/aus, KI-Bots sperren (GPTBot, ClaudeBot, PerplexityBot, Bytespider,
Google-Extended, Amazonbot, …), SEO-Tool-Bots sperren (Ahrefs, Semrush, Majestic,
Moz, BLEX, …). Default: Schutz an, schadhaft sperren, KI und SEO nur loggen.
Klartext-Erklärung pro Häkchen.
* **Konflikt-Erkennung Bot-Schutz.** Wenn Wordfence, Cerber, BBQ, StopBadBots,
Blackhole-Bad-Bots oder Solid Security parallel aktiv sind, zieht sich Bastoras
Bot-Sperre zurück und loggt nur. Memory-Regel feedback_konflikt_check.md.
* **Bot-Log mit kompaktem Aggregat-Schema.** Pro (Bot, Tag, Pfad-Hash) genau eine
Zeile mit Hit-Counter, kein Event-Stream. Keine IPs, kein User-Agent in Klartext.
Retention 28 Tage. Skaliert auch bei Millionen Crawler-Hits.
* **Telemetrie 28-Tage-Aggregate.** Der bereits auf 28 Tage-Frequenz reduzierte
Snapshot enthält jetzt zusätzlich aggregierte Statistik der letzten 28 Tage:
WAF-Hits + Top-10-Regeln + Top-10-Pfade, Block-Rule-Treffer + aktive Regeln,
Brute-Force-Sperren + Lifetime-Counter, Audit-Log-Events pro Typ, Bot-Hits pro
Klasse + Top-20-Namen, Top-Pfade aller Bots. Aggregate-Methoden in jedem Modul,
nie Roh-Events, nie IPs.
* **Atomarer Lock-Mechanismus** in Kerndatei- und Asset-Integrity bleibt aus 1.0.5.
Sucuri-Pro-False-Positive aus 1.0.4 bleibt gefixt. Telemetrie-Frequenz 28 Tage
aus 1.0.7 bleibt.
#### 1.0.7
* **Telemetrie-Frequenz von täglich auf alle 28 Tage gesenkt.** Initial-Send beim
Aktivieren bleibt, danach sendet jede Site nur noch alle 28 Tage. Hintergrund:
Bastora will Masse-Infos über viele Sites sammeln, kein dichtes Zeitprofil einzelner
Sites. Bestands-Installationen werden beim ersten plugins_loaded automatisch
vom alten daily- auf das neue 28-Tage-Schedule migriert, ohne dass der User den
Toggle anfassen muss.
* Wizard- und readme-Texte zur Sendefrequenz angepasst.
#### 1.0.6
* **Bugfix sichtbarer Schwarm-Aktivierungs-Fehler.** Wenn das Schwarm-Häkchen im
Settings angeklickt und gespeichert wurde, aber der Bastora-Schwarm-Server in
dem Moment kein Token liefern konnte, blieb die Option im stillen auf „aus” und
das Häkchen verschwand beim Reload. Es gab nur die grüne „Gespeichert”-Notice,
keinen Hinweis auf den Server-Fehler. Jetzt: rote Notice mit dem konkreten Fehler-
Text vom Server (HTTP-Code oder Antwort-Detail), und das Häkchen bleibt im UI
optimistisch sichtbar, damit klar ist, dass der lokale Toggle gewollt war.
#### 1.0.5
* **Atomarer Lock-Mechanismus** für Kerndatei-Auto-Reparatur und Plugin/Theme-Asset-
Integrity. Bisher gab es eine kurze Lücke zwischen „prüfen ob Lock aktiv” und„
Lock setzen” (TOCTOU), in der zwei parallele Cron-Trigger gleichzeitig in die
Repair-Logik einsteigen konnten. Jetzt mit fopen-Mode ‘x’ (POSIX O_CREAT|O_EXCL),
race-frei.
* **Transparenz-Hinweis Telemetrie-Eindeutigkeit** in readme.txt ergänzt. Auch
ohne Domain ist die Kombination Plugin-/Theme-Inventar + Versionen + Hosting-
Provider + Locale statistisch sehr individuell. Bastora führt die Telemetrie
nie mit anderen Datenquellen zusammen, aber die Eindeutigkeit gehört in die Doku.
#### 1.0.4
* **Bugfix Sucuri-Pro-Erkennung.** SucuriScanFirewallAPI::getKey() existiert auch
in der Free-Variante, liefert dort nur kein Schlüssel zurück. Bisher wurde jeder
Sucuri-Install fälschlich als Pro markiert. Jetzt wird nur dann Pro gemeldet,
wenn der Schlüssel auch tatsächlich befüllt ist.
* **Bugfix Mehrfach-Aggregation in Telemetrie.** `wp_count_comments()` wurde drei
Mal nacheinander aufgerufen statt einmal zwischengespeichert (drei SQL-Aggregat-
Queries statt einer). Plus zusätzliche Null-Checks bei `wp_count_posts()`-Resultat.
* **Telemetrie-Timeout auf 12 s erhöht.** Der ab 1.0.3 deutlich größere Body und
der ein-malige Reverse-DNS-Lookup für die Hosting-Erkennung brauchen Luft. 30-
Tage-Cache sorgt dafür, dass der Lookup nur einmal alle 30 Tage anfällt.
* **Reverse-DNS hart umkapselt.** Exception aus disable_functions-Listen wird abgefangen,
blockt nicht mehr den Telemetrie-Send.
* **External-Services-Sektion in readme.txt vervollständigt** um die lokale gethostbyaddr-
Auflösung der eigenen Server-IP (kein externer Bastora-Call, nur die PTR-Anfrage
am Resolver des Hosters).
#### 1.0.3
* **Telemetrie deutlich vollständiger.** Wenn Du das Häkchen gesetzt hast, gehen
jetzt zusätzlich übermittelt: Plugin- und Theme-Autor, jeweils die zum Zeitpunkt
der Erfassung neueste verfügbare Version (Quelle: api.wordpress.org), ob ein
Update bereitsteht und ob Auto-Update für den Eintrag aktiv ist, Eltern-Theme
bei Child-Themes, ob WordPress selbst aktuell ist und welche Core-Version aktuell
ist. Plus: Bastora-eigene Härtungs-Schalter (welche scharf, welche durch andere
Sicherheits-Plugins übernommen), erkannte Sicherheits-Plugins mit free/Pro-Klassifizierung,
Audit-Findings als Status-Map pro Prüfpunkt-ID. Domain, IP und Benutzer-Daten
bleiben weiter komplett raus.
* **Hosting-Provider-Erkennung (anonymisiert).** Heuristik in drei Stufen (Konstanten-
Marker, Reverse-DNS auf die Server-IP, DOCUMENT_ROOT-Pattern) liefert einen anonymen
Provider-Slug wie “hetzner”, “ionos”, “kinsta”, “all-inkl”, “udmedia”. Die Server-
IP selbst geht nicht raus, nur der ermittelte Provider-Name. Ergebnis wird lokal
30 Tage gecacht.
* **Audit-Findings-Map.** Plugin sendet pro Audit-Punkt einen kompakten Status-
Code (0=bestanden, 1=Hinweis, 2=offen, 3=nicht prüfbar). Damit kann die Server-
Statistik die häufigsten und seltensten Lücken aggregieren.
* **Telemetrie-Body-Cap auf 96 KB erhöht.** Plugin-Cap 200, Theme-Cap 75 (vorher
150/50). Server akzeptiert jetzt bis 96 KB pro Send.
* Aktives Theme: zusätzlich Autor und Eltern-Theme bei Child-Themes.
#### 1.0.2
* **Activation-Redirect-TTL erhöht.** Der Wizard-Auto-Aufruf nach Plugin-Aktivierung
wartet jetzt bis zu 5 Minuten auf den ersten `admin_init`, vorher nur 30 Sekunden.
Verhindert verlorene Redirects bei langsamen Hardening-Boots.
* **Telemetrie-Body-Größe begrenzt.** Plugin-Inventar auf 150 Einträge, Theme-Inventar
auf 50 Einträge gekappt. Schützt vor 413-Antworten auf Hostern mit 32 KB-HTTP-
Body-Limit.
* **Endpoint-Migration räumt jetzt die Datenbank auf.** Schwarm-, Pwned-, Telemetrie-
und URL-Feed-Endpoints schreiben den korrigierten www.bastora.de-Wert einmalig
zurück in die Options-Tabelle, statt bei jedem Aufruf neu zu korrigieren. Bewusst
gesetzte abweichende Werte (Test-Domains, eigene Mirrors) bleiben dabei unangetastet.
#### 1.0.1
* **Onboarding-Bruch geschlossen.** Nach Plugin-Aktivierung wird der Admin automatisch
in den Wizard geleitet, parallel eine Setup-Erinnerung im Backend gezeigt, plus„
Einrichten”-Link in der Plugins-Übersicht.
* **Wizard erweitert.** Alle fünf Opt-ins (Schwarm, Versions-Abgleich, Schad-URL-
Feed, Passwort-Leck-Check, anonyme Statistik) werden im Wizard direkt freigegeben.
JS-Übertragung der zwei neuen Felder Pwned und URL-Feed nachgezogen.
* **Endpoint-Migration auf www.bastora.de.** Schwarm-Register, Pwned-Proxy, Telemetrie-
Pipeline und URL-Feed-Pull nutzen jetzt direkt `www.bastora.de`. Behoben: 301-
Redirect auf der Bare-Domain hatte POST-Requests in GET verwandelt und damit
Schwarm-Aktivierung blockiert.
* **Dashboard-Status-Karten** für Kerndatei-Wache, Plugin/Theme-Wache, Schwarm
und Schad-URL-Liste direkt am Dashboard, nicht mehr in den Einstellungen.
* **Findings-Kategorien** standardmäßig eingeklappt, mit Statusanzeige (X offen/
Y Hinweise / alles grün) im Header. Klick auf Summary-Kacheln öffnet automatisch
die passenden Kategorien.
* **Telemetrie maximal erweitert.** Jetzt mit Plugin-Versionen und Aktiv-Status,
Theme-Inventar, aktivem Theme, User-Counts pro Rolle, Content-Aggregaten und
WP-Konfigurations-Flags.
* **Audit-Punkt monitor.03** erkennt jetzt das Bastora-eigene Vier-Schichten-Captcha
als aktiv, statt es als „kein Captcha” zu melden.
* **Pro-Hinweis-Box** wegklickbar, eigener Top-Nav-Tab „Pro” mit Verlinkung auf
die neue Landing-Page `bastora.de/pro.php`.
* **Lange Striche entfernt.** Em-Dash und En-Dash aus allen User-facing-Strings
und allen Code-Files. Memory `feedback_keine_langstriche.md` geschärft.
* **Brute-Force-Sperrtext** klarer formuliert.
#### 1.0.0
* **Lokale Firewall (WAF).** 42 Regeln gegen SQL-Injection, Path-Traversal, RCE,
XSS, bekannte WordPress-Exploits und CVE-Marker. Drei Modi: aus, nur protokollieren,
blockieren. Default beim Einrichten: protokollieren. Bei aktivem Wordfence, Sucuri,
Solid Security, AIOS, MalCare, WP Cerber oder NinjaFirewall zieht sich Bastora
automatisch zurück. Eigene Hit-Tabelle mit 30 Tagen Retention. Eingeloggte Nutzer
werden vor Self-Lockout durch False-Positives geschützt (Block wird zu Log degradiert).
* **Schadcode-Scanner.** Täglicher Cron + Sofort-Trigger nach manuellem Scan. Prüft
PHP-Dateien unter wp-content/themes und wp-content/uploads gegen einen lokalen
Pattern-Katalog (~50 Signaturen: C99, R57, WSO, b374k, IndoXploit, MadSpot, eval(
base64_decode), preg_replace mit /e-Modifier, WP-spezifische Backdoors wie wp_create_user
mit User-Input). MD5-Hash-Cache pro Datei verhindert Re-Scan unveränderter Dateien.
Max 500 Dateien pro Cron-Lauf, Resume-State, 2 MB Max-Dateigröße. Admin-Mail
bei neuen kritischen Funden.
* **URL-Reputation in Posts und Kommentaren.** Hooks in wp_after_insert_post und
preprocess_comment. Findet bekannte Spam-/Phishing-/Malware-Domains und klassische
Bot-Spam-Pattern (Cialis, Casino-Bonus, Crypto-Doubler, IP-URLs, URL-Shortener).
Memory-Vorgabe: kein Auto-Reject, nur Audit-Findung.
* **Block-Rules.** Eigene Sperrliste für IP, CIDR (IPv4), Hostname (Reverse-DNS-
Substring), User-Agent-Substring und Referrer-Substring. Optionaler Auto-Verfall.
Verkehrs-Tabelle hat Quick-Block-Buttons, die direkt eine /24-Sperre aus einem
auffälligen Event erzeugen.
* **Live-Traffic-Log.** Sicherheitsrelevante Events (Login-Fail, Login-OK, 404,
WAF-Hit, Block-Hit) im Ringbuffer (max 1000 Einträge). Optionaler all-Modus mit
1/10-Sampling für jeden Pageview. DSGVO: IP-Adressen werden nicht im Klartext,
sondern als rotierender SHA-256-Tagesschlüssel + /24- bzw. /64-Prefix gespeichert.
* **Eigenes Vier-Schichten-Captcha (ohne Cloud).** Honeypot-Feld + Time-Trap (Submit
unter 1,5 s wird verworfen) + JavaScript-Proof-of-Work (SHA-256-Mining mit drei
Hex-Nullen, ~200 ms im Browser) + Math-Fallback ab dem dritten Login-Fehler.
Keine Cookies, keine externen Calls, keine reCAPTCHA-/Turnstile-Abhängigkeit.
Zieht sich bei aktivem Wordfence, Solid Security, AIOS, WP Cerber, Limit Login
Attempts, reCAPTCHA-/Turnstile-Plugins automatisch zurück.
* **Pwned-Passwords-Check (Opt-in).** Bei Login von Backend-fähigen Nutzern wird
das Passwort lokal SHA-1-gehasht und nur die ersten 5 Hex-Zeichen an den Bastora-
Proxy auf bastora.de geschickt (k-Anonymity, DE-Hosting, 24 h Cache). Bei Treffer:
Admin-Notice mit Aufforderung, das Passwort zu ändern. Login wird NICHT blockiert,
damit niemand sich selbst aussperrt.
* **Verkehr & Sperren** und **Firewall** sind eigene Submenüs unter Bastora. Settings-
Bereich um Pwned-Toggle erweitert.
* **Drei neue Audit-Punkte:** `system.14` (Themes ohne Schadcode-Verdacht), `system.
15` (Uploads ohne Schadcode-Verdacht), `monitor.08` (Keine Verlinkungen auf bekannte
Schadseiten). Punktezahl wächst auf 58.
* **Schad-URL-Feed (Opt-in).** Optionaler täglicher Pull einer aktualisierten Domain-
Liste von `bastora.de/v1/url-feed/` (Quellen: URLhaus + OpenPhish). Lokal verschmolzen
mit der eingebauten Startliste, in URL-Watch zusätzlich für die Prüfung von Beiträgen
und Kommentaren genutzt. Hard-Cap 50 000 Einträge lokal, 30 Tage TTL. Standardmäßig
aus, aktives Häkchen in den Einstellungen.
* **Aktivitäts-Log für WordPress-Aktionen.** Eigene Tabelle mit User-Erstellung,
Rollen-Wechsel, Plugin-/Theme-Installation, Updates, Admin-Logins. 90 Tage Aufbewahrung,
IP-Adressen DSGVO-konform als /24- bzw. /64-Prefix plus rotierender Tagessalt.
Eigenes Submenü „Aktivität” mit Filter pro Ereignistyp.
* **WP-CLI-Integration.** `wp bastora scan/status`, `wp bastora waf [--mode=…]`,`
wp bastora blocks list/add/delete`, `wp bastora content-scan`, `wp bastora url-
feed pull/status`, `wp bastora swarm enable/disable/status`.
* **Datei-Inspektor mit Side-by-Side-Diff.** Bei Asset-Integrity-Funden in Plugins
oder Themes lässt sich die veränderte Datei direkt im Browser gegen das offizielle
Original auf wordpress.org vergleichen. Nutzt den vorhandenen ZIP-Cache der Asset-
Wache, kein zusätzlicher Cloud-Lookup.
* **Anonyme Sicherheits-Telemetrie real (Opt-in).** Statt nur die Zustimmung „vorzumerken”
sendet Bastora ab dem Häkchen sofort eine erste anonyme Statistik an `bastora.
de/v1/telemetry/` und danach einmal pro Tag. Keine Domain, keine IP, keine User-
Daten. Pro Site-ID maximal ein Datensatz pro Tag.
#### 0.4.0
* **Neuer Audit-Punkt `system.12`, Plugin-Integrity-Abgleich gegen wordpress.org.**
Bastora vergleicht täglich (Cron) und nach jedem manuellen Scan alle installierten
Plugins gegen die offizielle ZIP im WordPress.org-Repository. Geprüft werden
alle Dateien, die im Original enthalten sind, per MD5-Hash. Veränderte oder fehlende
Dateien werden im Audit als kritisch ausgewiesen, der typische Indikator für
Backdoor-Code, der in ein vorhandenes Plugin eingeschleust wurde.
* **Neuer Audit-Punkt `system.13`, Theme-Integrity-Abgleich gegen wordpress.org.**
Analog für alle installierten Themes.
* Punktezahl wächst von 53 auf 55. Systemabsicherung-Kategorie hat jetzt 13 statt
11 Punkte.
* Auto-Reparatur bewusst NICHT eingebaut. Plugins und Themes schreiben legitim
Daten in ihre Verzeichnisse (Settings-Files, Caches, generierte Assets), eine
automatische Überschreibung würde harmlose Änderungen zerstören. Bastora meldet
ausschließlich und schickt eine Admin-Mail.
* Plugins/Themes, die NICHT im WordPress.org-Repository liegen (Premium, Custom),
werden als „extern, nicht prüfbar” markiert. Der API-Lookup wird 24 Stunden negativ
gecached, damit kein wiederholter 404 erzeugt wird.
* Quellen ausschließlich aus dem offiziellen WordPress.org-Repository: `plugins_api()`/`
themes_api()` (WP-Core-Funktionen, also `api.wordpress.org/plugins/info/1.2/`
und `api.wordpress.org/themes/info/1.2/`) plus `downloads.wordpress.org/plugin
|theme/..zip`. Es findet kein Aufruf an kommerzielle Dritt-APIs
statt.
* Neuer Admin-Block „Plugin- und Theme-Wache” in den Einstellungen mit Status,
Zähler-Übersicht und Detail-Liste der abweichenden Dateien.
* Eigener Single-Event-Hook für Sofort-Trigger nach manuellem Scan (Lehre aus Kerndatei-
Wache: `wp_next_scheduled` würde sonst durch den täglichen Hauptlauf blockiert).
* ZIP-Cache wird automatisch aufgeräumt, sobald ein Plugin/Theme deinstalliert
oder geupdated wurde.
#### 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
## Meta
* Version **1.2.5**
* Last updated **2 days ago**
* Active installations **Fewer than 10**
* WordPress version ** 6.0 or higher **
* Tested up to **7.0**
* PHP version ** 7.4 or higher **
* Language
* [English (US)](https://wordpress.org/plugins/bastora-security-audit/)
* Tags
* [Brute Force](https://mfe.wordpress.org/plugins/tags/brute-force/)[firewall](https://mfe.wordpress.org/plugins/tags/firewall/)
[hardening](https://mfe.wordpress.org/plugins/tags/hardening/)[malware](https://mfe.wordpress.org/plugins/tags/malware/)
[security](https://mfe.wordpress.org/plugins/tags/security/)
* [Advanced View](https://mfe.wordpress.org/plugins/bastora-security-audit/advanced/)
## Ratings
No reviews have been submitted yet.
[Your review](https://wordpress.org/support/plugin/bastora-security-audit/reviews/#new-post)
[See all reviews](https://wordpress.org/support/plugin/bastora-security-audit/reviews/)
## Contributors
* [ Bastora ](https://profiles.wordpress.org/mathiasva/)
## Support
Got something to say? Need help?
[View support forum](https://wordpress.org/support/plugin/bastora-security-audit/)