Title: Bastora Security Audit
Author: Bastora
Published: Òkúdù 10, 2026
Last modified: Agẹmọ 14, 2026
---
Ṣàwárí àwọn plugin
# Bastora Security Audit
Láti ọwọ́ [Bastora](https://profiles.wordpress.org/mathiasva/)
[Ṣe ìgbàsílẹ̀](https://downloads.wordpress.org/plugin/bastora-security-audit.1.3.8.zip)
* [Àwọn àlàyé](https://yor.wordpress.org/plugins/bastora-security-audit/#description)
* [Àwọn àgbéyẹ̀wò](https://yor.wordpress.org/plugins/bastora-security-audit/#reviews)
* [Ìgbéwọlẹ̀](https://yor.wordpress.org/plugins/bastora-security-audit/#installation)
* [Ìdàgbàsókè](https://yor.wordpress.org/plugins/bastora-security-audit/#developers)
[Ìrànlọ́wọ́](https://wordpress.org/support/plugin/bastora-security-audit/)
## Àpèjúwe
**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:
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 (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)
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=&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. 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=`, 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Ìtumọ̀ Yorùbá: ″)
* 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)
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
## Àwọn àwòrán ìbòjú
[⌊Der erste Scan startet, Bastora prüft 62 Sicherheitspunkte in etwa 25 Sekunden.⌉⌊
Der erste Scan startet, Bastora prüft 62 Sicherheitspunkte in etwa 25 Sekunden.⌉[
Der erste Scan startet, Bastora prüft 62 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.
## Ìgbéwọlẹ̀
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).
## Àwọn àgbéyẹ̀wò
Kò sí àwọn àgbéyẹ̀wò fún plugin yìí.
## Àwọn Olùkópa & Olùgbéejáde
“Bastora Security Audit” jẹ́ ètò ìṣàmúlò orísun ṣíṣí sílẹ̀. Àwọn ènìyàn wọ̀nyí ti
ṣe ìkópa sí plugin yìí.
Àwọn Olùkópa
* [ Bastora ](https://profiles.wordpress.org/mathiasva/)
[Túmọ̀ “Bastora Security Audit” sí èdè rẹ.](https://translate.wordpress.org/projects/wp-plugins/bastora-security-audit)
### Ṣe o nífẹ̀ẹ́ sí ìdàgbàsókè?
[Ṣàwárí koodu](https://plugins.trac.wordpress.org/browser/bastora-security-audit/),
ṣàyẹ̀wò [ibi ìpamọ́ SVN](https://plugins.svn.wordpress.org/bastora-security-audit/),
tàbí ṣe àgbékalẹ̀ sí [àkọsílẹ̀ ìdàgbàsókè](https://plugins.trac.wordpress.org/log/bastora-security-audit/)
nípasẹ̀ [RSS](https://plugins.trac.wordpress.org/log/bastora-security-audit/?limit=100&mode=stop_on_copy&format=rss).
## Àkọsílẹ̀ àwọn àyípadà
#### 1.3.8
* **Deutsche WordPress-Installationen werden korrekt geprüft.** Bastora hat die
Kerndateien bisher gegen die englische Ausgabe von WordPress abgeglichen. Auf
einer deutschen Installation galt dadurch `wp-includes/version.php` als verändert,
obwohl sie in Ordnung war. Bastora prüft jetzt gegen das Sprachpaket, aus dem
WordPress tatsächlich installiert wurde, und lädt für eine Reparatur auch die
passende Ausgabe.
* **Keine unnötige Reparatur mehr an dieser Datei.** Aus demselben Grund hat die
Kerndatei-Wache diese eine Datei bei jedem Durchlauf ersetzt und dabei die Sprachkennung
von WordPress überschrieben. Das passiert nicht mehr.
* **Auch der Kern rät nicht mehr zur Neuinstallation.** Weicht eine Kerndatei ab,
holt Bastora das Original zurück und sichert die vorgefundene Fassung in der
Quarantäne, wie bei Plugins und Themes auch.
* **Der Login-Schutz lässt sich nicht mehr über gefälschte Kopfzeilen austricksen.**
Die Brute-Force-Sperre bestimmt die Besucher-Adresse jetzt genauso vorsichtig
wie der übrige Schutz und wertet Proxy-Kopfzeilen nur bei einem bekannten Proxy
aus.
* **Gesicherte Fundstücke sind nicht mehr aufrufbar.** Dateien, die Bastora in
die Quarantäne verschiebt, werden mit unschädlicher Endung abgelegt und der Ordner
zusätzlich gegen direkten Zugriff gesperrt.
* **Keine internen Adressen im Schwarm.** Private und reservierte IP-Adressen werden
weder gemeldet noch gesperrt.
* **Ein verändertes Theme wird nicht mehr als sauber ausgewiesen.** Weicht das
aktive Theme vom Original ab, zeigt der zugehörige Punkt das als Hinweis, statt„
alles in Ordnung” zu melden.
#### 1.3.7
* **Status erneuert sich nach einem Update von selbst.** Nach einem Plugin-, Theme-
oder WordPress-Update erhebt Bastora den Sicherheitsstatus jetzt im Hintergrund
neu, ohne dass Du das Dashboard öffnen musst. Der Schutz war auch vorher durchgehend
aktiv, die Anzeige hängt nun nicht mehr hinterher.
* **Verfügbare Updates fallen auf einen Hinweis zurück.** Steht für ein Plugin
oder Theme ein Update bereit (auch bei abgeschaltetem Auto-Update), zeigt der
passende Prüfpunkt das als Hinweis, statt weiter „alles aktuell” zu melden.
* **„Dateien reparieren” statt Neuinstallation.** Weicht ein Plugin oder Theme
vom Original auf wordpress.org ab, rät Bastora nicht mehr zur riskanten Neuinstallation.
Ein Klick ersetzt gezielt nur die abweichenden Dateien durch das Original; die
vorgefundene Fassung wird vorher in der Quarantäne gesichert. Einstellungen und
Inhalte bleiben unangetastet.
#### 1.3.6
* **Login-Captcha wird im Einrichtungs-Assistenten mitaktiviert.** Im Schritt „
Absichern” schaltet Bastora das Captcha jetzt sichtbar zusammen mit den übrigen
Schutzschichten scharf. Der zugehörige Punkt steht danach von selbst auf grün,
statt nur einen Hinweis ohne Weg zu zeigen.
* **Kein Doppel-Scan neben anderen Security-Plugins.** Erkennt Bastora ein Plugin,
das den Schadcode-Scan oder die Datei-Integrität bereits übernimmt (etwa Wordfence,
Sucuri, MalCare, Solid Security oder WP Cerber), hält es den eigenen Scanner
und die Datei-Wachen zurück. Das spart Last und vermeidet widersprüchliche Meldungen;
der betroffene Punkt nennt klar, welches Plugin die Aufgabe übernimmt.
#### 1.3.5
* **Ehrlichere Score-Gewichtung.** Nicht mehr jeder Prüfpunkt zählt gleich viel:
kritische Schutzpunkte wiegen jetzt schwerer als kleine Kosmetik-Punkte. Der
Score spiegelt damit den tatsächlichen Sicherheitsgewinn ehrlicher wider.
* **Kein doppelter Hinweis mehr.** Wo ein Knopf den Punkt direkt behebt, blendet
Bastora den zusätzlichen „Lösung in der Werkstatt”-Link aus. Ein klarer Weg statt
zwei.
* **Stabilität und Tempo.** Umfassender Code-Durchgang mit Fehlerkorrekturen und
Performance-Feinschliff, damit Bastora die Website praktisch nicht ausbremst.
#### 1.3.4
* **Restlicher Mixed Content verschwindet.** Nach der aktiven HTTPS-Umstellung
weist Bastora den Browser an, jeden verbliebenen http-Verweis automatisch über
https zu laden (upgrade-insecure-requests). Das räumt auch Links auf, die fest
im Theme stehen und ein Datenbank-Ersetzen nie erreicht. Der HTTPS-Punkt steht
danach auf grün.
#### 1.3.3
* **Scoring zieht nach jeder Umstellung nach.** Löst Du die HTTPS-Umstellung über
den Knopf aus, erkennt das Dashboard die Änderung sofort, bewertet den Punkt
neu und passt den Score an. Auch das Rückgängigmachen wirkt sich direkt aus.
#### 1.3.2
* **Frischer Status direkt nach dem Update.** Nach einem Plugin-Update erhebt Bastora
den Sicherheits-Status von selbst neu, statt ein altes Ergebnis mit alten Einstufungen
anzuzeigen. Ein Hard-Refresh im Browser ist nicht mehr nötig.
* **Betreuter Schutz trägt wieder das blaue “Pro”-Abzeichen.** Die Ebene zeigt
ihr Abzeichen jetzt zuverlässig, auch wenn das gespeicherte Ergebnis noch vom
Vorgänger stammt. Die Kachel “Nicht prüfbar” und ihr Filter zählen dieselben
Punkte.
* **Sicherheits-Header setzt Bastora jetzt selbst.** X-Frame-Options, X-Content-
Type-Options, Referrer-Policy und Permissions-Policy liefert Bastora auf sicheren
Werten aus, sofern sie nicht schon vom Server oder einem anderen Plugin kommen.
Doppelte Header entstehen dabei nicht.
* **Autosave und Pingbacks werden automatisch gelöst.** Statt eines Knopfes streckt
Bastora das Autosave-Intervall auf 5 Minuten und schaltet aus- und eingehende
Pingbacks ab, jeweils konfliktgeprüft.
* **Fremdverwaltete Updates: kein leerer Schalter mehr.** Verwaltet eine Hosting-
Schicht wie Installatron die automatischen Updates, zeigt Bastora nur noch den
Hinweis, keine wirkungslose Checkbox.
* **Assets brechen den Cache zuverlässig.** Alle mitgelieferten Skripte und Stile
laden nach einer Änderung sicher neu.
* **Child-Themes werden erkannt.** Nutzt Du ein Child-Theme (etwa Hello Elementor
Child), gleicht Bastora das Eltern-Theme mit dem Original auf wordpress.org ab,
statt das Child fälschlich als „Pro-Theme ohne Referenz” zu behandeln.
* **Captcha-Hinweis verständlich.** Der Punkt zum Login-Captcha spricht nicht mehr
vom „Onboarding”. Nach abgeschlossener Einrichtung schützt das Bastora-Captcha
den Login automatisch und der Punkt steht auf grün.
* **Sichere Verbindung mit Knopf.** Meldet der Punkt zur sicheren Verbindung noch
offene Stellen, führt ein Knopf direkt zur Umstellung.
* **Klarere Update-Empfehlung im Assistenten.** Der Einrichtungs-Assistent empfiehlt
automatische Updates für Plugins, Themes und den WordPress-Kern in einem Zug.
Das Häkchen greift jetzt zuverlässig, sodass die Update-Empfehlung nach der Einrichtung
nicht mehr fälschlich erneut erscheint.
* **HTTPS stellt Bastora nicht mehr von selbst um.** Die Umstellung auf sichere
Links bleibt eine Empfehlung, die Du im Dashboard oder in den Einstellungen selbst
auslöst und jederzeit wieder rückgängig machen kannst. Die Prüfung auf unsichere
Links (Mixed Content) bleibt erhalten, ein vorhandenes SSL-Plugin bleibt unangetastet.
* **Reverse-Proxy sauber erkannt.** Liefert Dein Hoster oder ein Proxy die Seite
bereits über https aus, während WordPress intern noch http kennt, zeigt Bastora
dafür einen ruhigen Hinweis mit klarer Erklärung statt einer falschen „unverschlüsselt”-
Warnung.
#### 1.3.0
* **Veränderte Theme-Dateien werden ersetzt, statt gemeldet.** Weicht eine Datei
vom Original auf wordpress.org ab, schreibt Bastora das Original selbst zurück
und sichert die vorgefundene Fassung in der Quarantäne. Danach steht dort eine
Information, keine Aufgabe.
* **Die Herkunft entscheidet, nicht das Muster.** Code, der bitgenau so im Original
des Themes steht, gehört zum Theme und taucht nirgends mehr als Verdacht auf.
* **Ohne Original bleibt der Punkt ehrlich grau.** Bei gekauften Themes, ausgelagerten
Builder-Themes und Child-Themes gibt es nichts zu vergleichen. Das sagt Bastora
jetzt so, statt Vermutungen anzuzeigen. Eindeutiger Schadcode wie eine Webshell
wird dort trotzdem erkannt und behandelt, denn dafür braucht es kein Original.
* **Eindeutiger Schadcode wandert von selbst in die Quarantäne.** Trägt eine fremde
Datei ein eindeutiges Muster (Webshell, Backdoor, Verwisch-Routine), verschiebt
Bastora sie in die Quarantäne und legt eine Sicherungskopie ab. Muster, die auch
harmlos sein können, entfernt Bastora nicht von allein: dort steht ein Knopf
mit kurzer Empfehlung. Bindet das Theme die Datei ein, bleibt sie unangetastet.
* **Der Audit-Punkt bewertet sich nach jedem Eingriff neu.** Bisher konnte er von
Funden sprechen, die längst behoben waren.
* **Bastora misst nach Änderungen selbst nach.** Bemerkt es eine Änderung am System,
meldet es das im Dashboard und erhebt den Status sofort neu. Währenddessen dreht
sich der Ring um den Score. Die Aufforderung, selbst einen Scan zu starten, entfällt.
* **Fünfte Kachel im Dashboard.** “Bastora Pro” zeigt die Punkte, die der bezahlte
Dienst übernimmt, mit derselben Filterung wie die übrigen Kacheln. Die Ebene “
Betreuter Schutz” trägt dazu ein blaues Abzeichen.
* **Rot heißt jetzt “Zu beheben”.** Der bisherige Begriff “Offen” ließ sich zu
leicht mit “Nicht prüfbar” verwechseln.
* **Passwort-Warnung lässt sich ausblenden.** Ein Knopf “Ich kenne das Risiko”
legt die Meldung still. Sobald ein sauberes Passwort gesetzt ist, meldet Bastora
bei einem künftig geleakten wieder.
* **Datei-Inspektor repariert.** Der Vergleich mit dem Original lädt die Referenz
jetzt bei Bedarf, statt auf einen zwischenzeitlich geleerten Zwischenspeicher
zu warten.
* **Menü aufgeräumt.** Dashboard, Status, Einstellungen und Pro. Die Detailseiten
bleiben über ihre Links erreichbar.
## Àkójọpọ̀ Meta
* Ẹ̀yà **1.3.8**
* Ìgbàgbọ́hùn tó kẹ́yìn **ọjọ́ 1 sẹ́yìn**
* Àwọn ìgbéwọlẹ̀ tó ṣiṣẹ́ **Tó kéré sí 10**
* Ẹ̀yà WordPress ** 6.0 tàbí ju bẹ́ẹ̀ lọ **
* Dánwò dé **7.0.1**
* Ẹ̀yà PHP ** 7.4 tàbí ju bẹ́ẹ̀ lọ **
* Èdè
* [English (US)](https://wordpress.org/plugins/bastora-security-audit/)
* Àwọn àmì
* [Brute Force](https://yor.wordpress.org/plugins/tags/brute-force/)[firewall](https://yor.wordpress.org/plugins/tags/firewall/)
[hardening](https://yor.wordpress.org/plugins/tags/hardening/)[malware](https://yor.wordpress.org/plugins/tags/malware/)
[security](https://yor.wordpress.org/plugins/tags/security/)
* [Ìwòye Tó Péye](https://yor.wordpress.org/plugins/bastora-security-audit/advanced/)
## Àwọn ìbò
Kò sí ìwádìí tí a tíì fi ránṣẹ́.
[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/)
## Àwọn Olùkópa
* [ Bastora ](https://profiles.wordpress.org/mathiasva/)
## Ìrànlọ́wọ́
Nǹkan wà tí o fẹ́ sọ? Ṣé o nílò ìrànlọ́wọ́?
[Wo àpéjọ ìrànlọ́wọ́](https://wordpress.org/support/plugin/bastora-security-audit/)