Name: Bastora Security Audit
Author: Bastora

Bastora ist ein ehrlicher WordPress-Sicherheits-Check. Statt tausend Schalter ohne Erklärung prüft Bastora Deine Installation gegen einen festen Katalog aus 62 Sicherheitspunkten und zeigt Dir das Ergebnis als Klartext-Ampel direkt in Deinem Dashboard.

Bastora unterscheidet sich von anderen Sicherheits-Plugins in drei Punkten:

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.
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.
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 (15 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, Schadcode-Prüfung der Theme-Dateien, Schadcode-Prüfung des Uploads-Verzeichnisses
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 (8 Punkte): Transients, Revisions-Cleanup, Captcha, WordPress-Version, PHP-Version, /uploads/-PHP-Sperre, Sicherheits-Plugin-Status, Schutz vor Verlinkung auf bekannte Schadseiten

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
X-Powered-By-Header entfernt (verrät sonst die PHP-Version)
Beitrags-Revisionen auf 15 begrenzt (hält die Datenbank schlank, respektiert strengere Einstellungen)
Uploads-Verzeichnis gegen PHP-Ausführung abgesichert (index.html gegen Verzeichnis-Listing, auf Apache zusätzlich eine .htaccess, tritt zur Seite wenn ein anderes Plugin das schon macht)
HTTPS-Umstellung mit einem Klick: Bastora schreibt die eigenen http-Links Deiner Seite serialisierungssicher auf https um und richtet die Weiterleitung von http auf https ein. Auf reinen http-Seiten prüft Bastora vorab die HTTPS-Erreichbarkeit, schaltet mit einem 15-minütigen Probelauf um und dreht ohne Bestätigung von selbst zurück. Fremde Domains bleiben unberührt, ein laufendes SSL-Plugin hat Vorrang.
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 Plugins und Themes mit Versionsstand (max. 200 Einträge)
Audit-Score und Counter pro Status (bestanden / Hinweis / offen / nicht prüfbar)
Das Ergebnis des allerersten Scans, also der Stand vor der Einrichtung, als dieselbe Liste aus Prüfpunkt und Status. Daran ist ablesbar, was die Härtung bewirkt hat und welche Punkte offen bleiben. Auch hier nur Kennungen wie zugang.01 und eine Zahl, keine Inhalte.
Einmalig ein vollständiges Bild des Zustands vor der Härtung: dieselben Angaben wie oben, also Versionen, Erweiterungen und Prüfpunkte, festgehalten beim ersten Scan. Es wird genau einmal übertragen und danach nicht mehr. Auch hier keine Domain, keine Inhalte, keine Personendaten.
Zu abgewehrten Angriffen: das Muster, das die Firewall erkannt hat, samt aufgerufener Adresse, Kennung des Aufrufers und Uhrzeit. Ausschließlich aus der Adresszeile und den Kopfdaten des Angriffs. Inhalte aus Formularfeldern Deiner Website werden ausdrücklich nicht übertragen.
Installationsart (self / agency / org) samt Erstwahl, damit wir sehen, wer Bastora einsetzt. Nur diese drei Werte, keine Namen, keine Adressen.

Was nie übertragen wird: Domain, URL, IP-Adresse, E-Mail-Adressen, Benutzernamen, Beitragsinhalte, Dateiinhalte. 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=<version>&locale=en_US
pro erkennbarem Plugin nach dessen letztem Update-Datum: https://api.wordpress.org/plugins/info/1.0/<slug>.json
pro erkennbarem Theme nach dessen letztem Update-Datum: https://api.wordpress.org/themes/info/1.2/?action=theme_information&request[slug]=<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-<version>.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/<slug>.<version>.zip
https://downloads.wordpress.org/theme/<slug>.<version>.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. Bei Plugins findet eine automatische Reparatur bewusst NICHT statt; bei Funden bekommst Du eine Admin-Mail mit der Liste der abweichenden Dateien. Bei Themes aus dem WordPress.org-Repository schreibt Bastora ab Version 1.3.0 eine vom Original abweichende Datei selbst zurück und sichert die vorgefundene Fassung in der Quarantäne. Themes ohne Original bei wordpress.org bleiben vom Abgleich unangetastet; nur eindeutiger Schadcode (Webshell, Backdoor, Spuren-Verwischer) wird auch dort in die Quarantäne verschoben.

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=<unixts>, 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, 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, neueste verfügbare Version, Update-Status, Auto-Update, Eltern-Theme bei Child-Themes. Max. 75 Themes.
Aktives Theme: Slug, Version, 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)
Installationsart und deren Erstwahl (self = für mich selbst, agency = im Auftrag, org = für eine Organisation). Aus einem Wechsel gegenüber der Erstwahl lesen wir, wie oft sich die Rolle ändert. Nur diese Werte, keine Namen, keine Adressen.

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

Bastora Security Audit