Bastora Security Audit

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/<slug>.<version>.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