Description
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)
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>.ziphttps://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)
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
Installation
- Installiere das Plugin aus dem WordPress-Plugin-Verzeichnis oder lade den ZIP-Ordner nach
/wp-content/plugins/. - Aktiviere das Plugin im Menü „Plugins”.
- Ö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
Translate “Bastora Security Audit” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
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.phpals 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.