In meinem Fall war zuvor ein Update von Joomla 5.2.5 auf Joomla 5.4.x erfolgt. Nachdem anschließend Probleme mit einer Erweiterung auftraten, wurde ein Backup des älteren Joomla-5.2.5-Stands wiederhergestellt.

Danach funktionierte das Joomla-Backend wieder, das Frontend jedoch nicht. Stattdessen erschien:

Call to undefined method Joomla\Module\Menu\Site\Helper\MenuHelper::getItems()

Das Problem

Der Fehler deutet zunächst auf das Joomla-Menümodul beziehungsweise dessen PHP-Klassen hin.

Auffällig war jedoch der zeitliche Zusammenhang:

1. Joomla 5.2.5 funktionierte.
2. Das System wurde auf Joomla 5.4.x aktualisiert.
3. Danach traten Probleme auf.
4. Ein Backup des vorherigen Joomla-5.2.5-Stands wurde über die bestehende Installation zurückgespielt.
5. Backend-Zugriff war wieder möglich, das Frontend erzeugte jedoch den MenuHelper::getItems()-Fehler.

Damit lag der Verdacht nahe, dass nicht die komplette Installation wieder exakt auf den alten Zustand zurückgesetzt worden war.

Ursache: Ein Restore löscht nicht automatisch alle vorhandenen Dateien

Der wichtige Punkt ist, wie ein typischer Joomla-Backup-Restore funktioniert.

Beim Wiederherstellen werden Dateien aus dem Backup auf den Server geschrieben. Vorhandene Dateien mit demselben Namen werden dabei ersetzt.

Dateien, die bereits auf dem Server liegen, aber im Backup nicht vorkommen, werden dagegen nicht zwangsläufig gelöscht.

Das ist grundsätzlich sinnvoll. Ein Restore kann schließlich nicht sicher wissen, ob zusätzliche Dateien:

• zu einer neueren Softwareversion gehören,
• bewusst manuell abgelegt wurden,
• von einer Erweiterung stammen,
• oder aus anderen Gründen erhalten bleiben sollen.

Ein Restore ist deshalb nicht automatisch mit einer vollständigen Synchronisation des Dateisystems auf den Zustand des Backups gleichzusetzen.

Warum das bei Joomla-Versionen problematisch werden kann

Bei einem Joomla-Update können sich nicht nur Inhalte bestehender Dateien ändern.

Zwischen Joomla-Versionen können auch Dateien:

• neu hinzukommen,
• verschoben werden,
• umbenannt werden,
• oder vollständig entfallen.

Wird anschließend ein Backup einer älteren Joomla-Version über diesen neueren Stand zurückgespielt, entsteht deshalb möglicherweise ein Mischzustand:

Joomla 5.2.5 aus dem Backup
+
übrig gebliebene Dateien aus Joomla 5.4.x
=
potenziell inkonsistente Installation

Das war in diesem Fall die naheliegende Erklärung für den Methodenfehler im Frontend.

Wichtig ist die Unterscheidung:

Gesichert ist, dass ein Restore zusätzliche vorhandene Dateien nicht zwingend entfernt und dadurch nach einem Versionswechsel Dateireste bestehen bleiben können.

Nicht abschließend nachgewiesen wurde, welche konkrete verbliebene Datei den MenuHelper::getItems()-Fehler ausgelöst hatte.

Lösung: Joomla-Dateien vor dem Restore bereinigen

Statt das ältere Backup noch einmal einfach über die vorhandene Installation zu schreiben, sollte zunächst der bestehende Joomla-Core entfernt werden.

Vorher sollte selbstverständlich ein Rückfallpunkt vorhanden sein. Bei einem VPS kann dafür beispielsweise ein Snapshot verwendet werden.

Ein Snapshot eignet sich gut, um den kompletten Serverzustand vor solchen Änderungen kurzfristig wiederherstellen zu können. Er ersetzt allerdings nicht grundsätzlich ein dauerhaftes und extern verfügbares Backup.

Joomla-Core-Verzeichnisse entfernen

Vor dem erneuten Restore können insbesondere die Joomla-Core-Verzeichnisse entfernt werden:

administrator
api
cli
components
includes
language
layouts
libraries
media
modules
plugins
templates

Außerdem gehören zentrale Joomla-Dateien dazu, beispielsweise:

configuration.php
index.php

Danach wird das Backup erneut in das nun bereinigte Webverzeichnis eingespielt.

Achtung bei eigenen Dateien

Die Liste darf nicht blind auf jede Installation angewendet werden.

Vor dem Löschen muss geprüft werden, ob sich in diesen Verzeichnissen eigene Dateien oder nicht anderweitig gesicherte Inhalte befinden.

Das gilt insbesondere für:

media
templates

Dort können je nach Installation beispielsweise eigene Medien, Template-Anpassungen oder zusätzliche Dateien liegen.

Der entscheidende Punkt ist daher nicht:

Lösche immer exakt diese Verzeichnisse.

Sondern:

Stelle sicher, dass vor dem Restore keine Dateien einer anderen Joomla-Version im Zielsystem zurückbleiben.

Datenbank beim Restore

Auch die Datenbank sollte zum Backup-Zustand passen.

Beim Restore sollte derselbe Tabellenpräfix verwendet werden wie in der gesicherten Joomla-Installation.

Wenn das verwendete Restore-Werkzeug die Möglichkeit bietet, vorhandene Tabellen mit demselben Präfix vor dem Import zu entfernen, verhindert das ebenfalls einen Mischstand aus alter und neuer Installation.

Dateisystem und Datenbank sollten nach dem Restore gemeinsam zum selben Sicherungszeitpunkt gehören.

Optional: Joomla-Autoload-Cache neu erzeugen

Falls anschließend weiterhin Fehler auftreten, bei denen Namespaces oder Joomla-Klassen offenbar nicht zum Dateibestand passen, kann zusätzlich der Joomla-Autoload-Cache relevant sein.

Die entsprechende Cache-Datei liegt unter:

administrator/cache/autoload_psr4.php

Sie kann gelöscht werden, damit Joomla sie neu erzeugt.

Das ist jedoch ein zusätzlicher Reparaturschritt und ersetzt nicht die Bereinigung eines tatsächlich inkonsistenten Dateibestands.

Warum einfaches „Backup drüberspielen“ nicht genügt

Der entscheidende Unterschied ist:

Restore:
Backup-Dateien auf das vorhandene Dateisystem schreiben

ist nicht zwingend dasselbe wie:

Rollback:
Das gesamte Dateisystem exakt auf einen früheren Zustand zurücksetzen

Ein VPS-Snapshot kommt dem zweiten Fall deutlich näher, weil dabei der komplette gespeicherte Systemzustand zurückgesetzt wird.

Ein Joomla-Backup-Restore arbeitet dagegen innerhalb des vorhandenen Dateisystems. Deshalb können Dateien überleben, die zum Zeitpunkt des Backups noch gar nicht existierten.

Ergebnis

Für fehlgeschlagene Joomla-Updates ergibt sich daraus ein wichtiger Grundsatz:

Wenn ein Backup einer älteren Joomla-Version nach einem Update wiederhergestellt werden soll, sollte man vermeiden, es einfach über den neueren Dateibestand zu entpacken.

Sicherer ist:

1. Rückfallpunkt erstellen.
2. Eigene Dateien und Anpassungen sichern beziehungsweise identifizieren.
3. Vorhandenen Joomla-Core bereinigen.
4. Backup wiederherstellen.
5. Datenbank auf denselben Sicherungsstand bringen.
6. Frontend und Backend testen.
7. Bei Namespace-Problemen gegebenenfalls den Joomla-Autoload-Cache neu erzeugen.

Ein Fehler wie

Call to undefined method Joomla\Module\Menu\Site\Helper\MenuHelper::getItems()

muss damit nicht zwangsläufig bedeuten, dass das Menümodul selbst defekt ist.

Nach einem Restore über eine andere Joomla-Version hinweg sollte auch geprüft werden, ob schlicht Dateien unterschiedlicher Joomla-Versionen miteinander vermischt wurden.

Dieser Artikel beschreibt einen praktischen Weg, um eine gewachsene Joomla-Installation schrittweise zu untersuchen und aufzuräumen.

Wichtig: Vor Änderungen an der Datenbank sollte immer ein aktuelles Backup vorhanden sein.

Das Problem

Bei einer älteren Joomla-Installation fiel auf, dass die Datenbank ungewöhnlich groß geworden war. Gleichzeitig zeigte der Joomla-Bereich System → Discover mehr als hundert Erweiterungen an, obwohl viele davon längst nicht mehr bewusst genutzt wurden.

Die Fragen waren deshalb:

• Welche Tabellen belegen besonders viel Speicher?
• Welche Tabellen gehören zum Joomla-Core?
• Welche stammen von noch installierten Erweiterungen?
• Welche sind wahrscheinlich Reste längst deinstallierter Erweiterungen?
• Was bedeutet die lange Liste unter „Discover“?
• Können temporäre Dateien im Joomla-Verzeichnis gelöscht werden?

Statt sofort Tabellen zu löschen, lohnt sich zunächst eine Bestandsaufnahme.

1. Datenbanktabellen nach Größe untersuchen

Für eine erste Analyse braucht man nicht zwingend einen kompletten SQL-Dump mit allen Inhalten. Oft genügt eine Übersicht der Tabellen einschließlich Größe und ungefährer Zeilenzahl.

In phpMyAdmin kann innerhalb der betreffenden Datenbank folgende Abfrage ausgeführt werden:

SELECT
  table_name AS Tabelle,
  engine AS Engine,
  table_rows AS Zeilen,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS Groesse_MB,
  create_time AS Erstellt,
  update_time AS Letzte_Aenderung
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

Das Ergebnis lässt sich beispielsweise als CSV exportieren.

Die Abfrage liefert unter anderem:

• Tabellenname
• verwendete Storage Engine
• ungefähre Anzahl der Datensätze
• Größe von Daten und Indizes
• Erstellungs- und Änderungszeitpunkte, soweit verfügbar

Bei InnoDB ist die angegebene Zeilenzahl nicht zwingend exakt. Für eine erste Größenanalyse reicht sie aber aus.

2. Eine extrem große Joomla-Session-Tabelle

Besonders auffällig kann die Joomla-Tabelle

#__session

werden.

In dem untersuchten Fall enthielt sie mehr als vier Millionen Datensätze und belegte mehrere Gigabyte.

Dabei handelt es sich nicht um einen Datei- oder Bildcache.

Die Session-Tabelle speichert Sitzungsinformationen. Dazu gehören beispielsweise anonyme Besucher-Sessions und Sitzungen eingeloggter Benutzer beziehungsweise Administratoren.

Bilder, CSS-Dateien oder andere Mediendateien liegen dort nicht.

Alte Sessions zählen

Zunächst kann geprüft werden, wie viele Einträge älter als sieben Tage sind:

SELECT COUNT(*) AS aelter_7_tage
FROM #__session
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY);

Der Präfix #__ muss dabei durch den tatsächlichen Tabellenpräfix der Joomla-Installation ersetzt werden.

Zusätzlich kann die Gesamtzahl ermittelt werden:

SELECT COUNT(*) AS gesamt
FROM #__session;

Im Praxisfall waren nahezu sämtliche Einträge älter als sieben Tage. Die Tabelle bestand damit fast vollständig aus alten Sessions.

3. Alte Session-Daten löschen

Eine vorsichtige Möglichkeit besteht darin, alte Einträge portionsweise zu löschen:

DELETE FROM #__session
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
ORDER BY `time`
LIMIT 100000;

Bei mehreren Millionen Datensätzen kann das allerdings sehr lange dauern.

Im konkreten Fall benötigte bereits das Löschen von 100.000 Datensätzen deutlich mehr als zwei Minuten. Auch größere Blöcke machten die Bereinigung entsprechend langwierig.

Alternative: Session-Tabelle vollständig leeren

Wenn die Website keine angemeldeten Frontend-Benutzer hat und es akzeptabel ist, dass momentan angemeldete Administratoren ihre Sitzung verlieren, kann die Session-Tabelle auch vollständig geleert werden:

TRUNCATE TABLE #__session;

Das ist erheblich schneller als Millionen einzelne Datensätze mit DELETE zu entfernen.

Die Folge ist:

• bestehende Sessions gehen verloren,
• Administratoren müssen sich gegebenenfalls neu anmelden,
• Dateien, Bilder und Inhalte werden nicht gelöscht.

Für eine reine Session-Tabelle kann das bei einer Wartung eine sinnvolle Lösung sein.

4. Warum bleiben nach einer Joomla-Deinstallation Tabellen übrig?

Bei älteren Joomla-Installationen finden sich häufig Tabellen von Erweiterungen, die längst nicht mehr verwendet werden.

Eine Deinstallation entfernt nicht zwangsläufig alle Daten.

Ob Datenbanktabellen beim Entfernen einer Erweiterung ebenfalls gelöscht werden, hängt davon ab, wie die jeweilige Erweiterung ihre Deinstallation implementiert.

Deshalb können über Jahre komplette Tabellenfamilien zurückbleiben.

Typisch sind Namen wie:

#__extensionname
#__extensionname_files
#__extensionname_statistics
#__extensionname_categories
#__extensionname_config

Solche Tabellen sollte man allerdings nicht allein aufgrund ihres Namens löschen.

Zunächst muss geklärt werden, ob die zugehörige Erweiterung noch installiert ist.

5. Prüfen, ob eine Erweiterung noch installiert ist

Joomla führt installierte Erweiterungen in der Tabelle

#__extensions

Eine einfache Abfrage kann beispielsweise so aussehen:

SELECT
  extension_id,
  name,
  type,
  element,
  folder,
  enabled
FROM #__extensions
ORDER BY name, type;

Bei einer bestimmten Erweiterung kann gezielter gesucht werden:

SELECT
  extension_id,
  name,
  type,
  element,
  folder,
  enabled
FROM #__extensions
WHERE LOWER(CONCAT_WS(' ', name, type, element, folder))
      REGEXP 'name-der-erweiterung';

Das ermöglicht eine wichtige Unterscheidung:

Erweiterung noch installiert

Dann sollten die zugehörigen Tabellen nicht einfach gelöscht werden.

Auch eine deaktivierte Erweiterung kann weiterhin vollständig installiert sein.

Erweiterung nicht mehr installiert

Existieren trotzdem noch passende Datenbanktabellen, handelt es sich sehr wahrscheinlich um Altlasten.

Vor dem Löschen sollte trotzdem geprüft werden, ob die Daten noch benötigt werden.

Manche Tabellen enthalten nicht nur Konfiguration, sondern tatsächliche Inhalte, Formulareingaben, Statistiken oder Dokumentinformationen.

6. Tabellen einer alten Erweiterung löschen

Ist eindeutig geklärt, dass eine Erweiterung nicht mehr verwendet wird und ihre Daten ebenfalls nicht mehr benötigt werden, können die verbliebenen Tabellen entfernt werden.

Die vorhandenen Tabellen lassen sich zunächst anzeigen:

SHOW TABLES LIKE '%extensionname%';

Eine nützliche Variante erzeugt zunächst nur die passenden DROP TABLE-Befehle:

SELECT CONCAT(
  'DROP TABLE `',
  table_name,
  '`;'
) AS drop_sql
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE '%extensionname%';

Die erzeugten Befehle können anschließend überprüft werden.

Erst danach sollte tatsächlich gelöscht werden.

Beispiel:

DROP TABLE IF EXISTS
  `prefix_extensionname`,
  `prefix_extensionname_files`,
  `prefix_extensionname_statistics`;

Das ist sicherer, als Tabellen anhand eines vermuteten Namensschemas automatisch zu entfernen.

7. Nicht jede große Tabelle ist eine Altlast

Eine wichtige Erkenntnis bei solchen Aufräumarbeiten:

Große Tabellen sind nicht automatisch überflüssig.

Zu Joomla selbst gehören beispielsweise Tabellenfamilien für Funktionen wie:

#__finder_*
#__redirect_links
#__action_logs*
#__workflow_*
#__scheduler_*
#__guidedtours*
#__history

Auch installierte Drittanbieter-Erweiterungen können große Tabellen besitzen, etwa für:

• Statistiken
• Revisionen
• Suchindizes
• Formulardaten
• Dateiverwaltung
• Protokolle

Solche Tabellen sollten nicht entfernt werden, solange die zugehörige Funktion oder Erweiterung noch verwendet wird.

Hier ist gegebenenfalls eine Bereinigung der Inhalte sinnvoller als das Löschen der gesamten Tabelle.

8. Was bedeutet „Discover“ in Joomla?

Unter

System → Discover

kann Joomla Erweiterungen anzeigen, die im Dateisystem gefunden werden, aber nicht regulär als installierte Erweiterungen registriert sind.

Das ist etwas anderes als eine übrig gebliebene Datenbanktabelle.

Ein Discover-Eintrag bedeutet im Kern:

Joomla findet Dateien einer Erweiterung, aber der entsprechende Installationszustand passt nicht dazu.

Solche Reste können beispielsweise in Verzeichnissen liegen wie:

administrator/components/
components/
plugins/
modules/
administrator/modules/

Das erklärt auch, warum eine längst deinstallierte Erweiterung weiterhin unter „Discover“ auftauchen kann.

Ihre Datenbanktabellen können bereits verschwunden sein, während Teile der Erweiterung noch auf dem Webserver liegen.

9. Discover-Einträge bereinigen

Ein Discover-Eintrag sollte nicht einfach blind entfernt werden.

Zunächst muss geklärt werden:

1. Wird die Erweiterung noch verwendet?
2. Ist sie regulär installiert?
3. Handelt es sich tatsächlich nur um übrig gebliebene Dateien?

Wenn eindeutig feststeht, dass die Erweiterung nicht mehr gebraucht wird, können die zugehörigen Dateireste entfernt werden.

Dabei reicht es nicht immer, nur

administrator/components/com_beispiel

zu löschen.

Eine Erweiterung kann zusätzlich Dateien in weiteren Bereichen besitzen, beispielsweise:

components/com_beispiel
plugins/...
modules/...
administrator/modules/...

Nach dem Entfernen der verbliebenen Erweiterungsdateien sollte Joomla sie bei einer erneuten Discover-Suche nicht mehr erkennen.

Datenbankreste und Discover-Einträge sind damit zwei getrennte Baustellen:

• alte Tabellen → Datenbank
• Discover-Einträge → meist übrig gebliebene Dateien beziehungsweise ein inkonsistenter Installationszustand

10. Was kann aus dem Joomla-tmp-Verzeichnis gelöscht werden?

Auch im Joomla-Verzeichnis

tmp/

können sich über Jahre Dateien ansammeln.

Joomla verwendet dieses Verzeichnis als temporären Arbeitsbereich, unter anderem bei Installationen und Updates von Erweiterungen.

Dort können beispielsweise liegen:

• heruntergeladene Installationsarchive,
• entpackte Erweiterungen,
• Reste abgebrochener Installationen,
• andere temporäre Dateien.

Alte Inhalte dieses Verzeichnisses können in der Regel entfernt werden, wenn gerade

• kein Joomla-Update,
• keine Erweiterungsinstallation,
• kein Restore
• und kein anderer Wartungsvorgang

läuft.

Der Ordner tmp selbst sollte dagegen bestehen bleiben.

Auch sollte der konfigurierte tmp-Pfad nicht verändert werden, wenn die Installation korrekt funktioniert.

11. Sinnvolle Reihenfolge beim Aufräumen

Für eine ältere Joomla-Installation hat sich folgende Reihenfolge als übersichtlich erwiesen:

1. Backup erstellen

Vor Änderungen an Datenbank oder Dateisystem.

2. Tabellen nach Größe analysieren

Mit information_schema.tables.

3. Extrem große technische Tabellen untersuchen

Zum Beispiel #__session.

4. Installationsstatus von Erweiterungen prüfen

Über #__extensions.

5. Verwaiste Datenbanktabellen identifizieren

Nur löschen, wenn die Erweiterung sicher nicht mehr benötigt wird.

6. Joomla „Discover“ kontrollieren

Übrig gebliebene Erweiterungsdateien identifizieren.

7. Dateireste entfernen

Dabei alle zugehörigen Erweiterungspfade berücksichtigen.

8. tmp bereinigen

Nur alte temporäre Inhalte entfernen, nicht den Ordner selbst.

Ergebnis

Bei einer über Jahre gewachsenen Joomla-Installation lohnt sich ein systematisches Aufräumen.

Der größte Speicherverbrauch muss dabei nicht einmal von alten Erweiterungen kommen. Im beschriebenen Praxisfall war zunächst die Session-Tabelle das deutlichste Problem: Millionen alter Sessions hatten sich angesammelt.

Gleichzeitig zeigte die Analyse, dass zwischen verschiedenen Arten von Altlasten unterschieden werden muss:

• alte Session-Daten,
• Tabellen deinstallierter Erweiterungen,
• Tabellen weiterhin installierter Erweiterungen,
• Dateireste im Joomla-Dateisystem,
• Discover-Einträge,
• temporäre Dateien.

Wer diese Bereiche getrennt betrachtet und Änderungen jeweils vorher überprüft, kann eine alte Joomla-Installation erheblich aufräumen, ohne dabei versehentlich noch verwendete Komponenten oder Daten zu entfernen.

Dieser Artikel dokumentiert die Schritte, mit denen sich eine solche Tabelle untersuchen und bereinigen lässt. Wichtig: Vor Änderungen an einer produktiven Datenbank sollte immer ein vollständiges Backup vorhanden sein.

Problem: Eine ungewöhnlich große Joomla-Datenbank

Der erste Schritt besteht nicht darin, auf Verdacht Tabellen oder Datensätze zu löschen. Zunächst sollte geklärt werden, welche Tabellen den Speicher tatsächlich belegen.

Mit dieser Abfrage lassen sich die Tabellen einer Datenbank nach ihrer Größe sortieren:

SELECT
    table_name,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_in_mb
FROM information_schema.tables
WHERE table_schema = 'DATENBANKNAME'
ORDER BY size_in_mb DESC;

DATENBANKNAME muss durch den tatsächlichen Namen der Joomla-Datenbank ersetzt werden.

In meinem Fall gehörte die Joomla-Session-Tabelle zu den auffälligen Tabellen.

Die Joomla-Session-Tabelle untersuchen

Joomla verwendet ein individuell konfiguriertes Tabellenpräfix. Aus einer Tabelle wie

abc_session

kann daher bei einer anderen Installation beispielsweise

xyz_session

werden.

Die Struktur lässt sich mit DESCRIBE anzeigen:

DESCRIBE `abc_session`;

In der untersuchten Joomla-Installation hatte die Session-Tabelle unter anderem folgende Felder:

session_id
client_id
guest
time
data
userid
username

Für die weitere Analyse sind vor allem time und data interessant.

time ist ein Integer-Feld, über das sich alte Session-Einträge identifizieren lassen. data ist ein MEDIUMTEXT-Feld und kann entsprechend umfangreiche Session-Daten enthalten.

Wie groß sind die eigentlichen Session-Daten?

Um zunächst nur die gespeicherten Inhalte des Feldes data zu untersuchen, kann man deren Gesamtlänge ermitteln:

SELECT
    SUM(CHAR_LENGTH(data)) AS total_data_size
FROM `abc_session`;

In meinem Fall ergab die Abfrage:

687078044

CHAR_LENGTH() liefert hier die Anzahl der Zeichen, nicht unmittelbar die physische Größe der Tabelle auf dem Datenträger. Bei den vorliegenden Session-Daten entsprach die Größenordnung dennoch bereits mehreren hundert Megabyte Inhalt allein in diesem Feld.

Die tatsächliche Tabellengröße sollte deshalb zusätzlich über information_schema.tables bzw. die Tabelleninformationen von phpMyAdmin kontrolliert werden.

Wie viele alte Sessions gibt es?

Bevor Daten gelöscht werden, kann man zunächst prüfen, welche Datensätze von einer Löschbedingung betroffen wären.

Beispielsweise für Sessions, deren time-Wert älter als zehn Tage ist:

SELECT *
FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY)
LIMIT 10;

Noch übersichtlicher ist zunächst die reine Anzahl:

SELECT COUNT(*)
FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY);

Damit lässt sich kontrollieren, wie viele Datensätze die Bedingung überhaupt erfasst.

Wichtig: Der Zeitraum von zehn Tagen ist hier ein Beispiel aus der konkreten Bereinigung und keine allgemeingültige Joomla-Empfehlung. Welche Sessions gelöscht werden können, sollte zur Session-Konfiguration der jeweiligen Installation passen.

Alte Session-Einträge löschen

Ist geklärt, dass die entsprechenden Datensätze entfernt werden sollen, lautet die Abfrage beispielsweise:

DELETE FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY);

Bei sehr vielen Datensätzen kann eine solche Abfrage über phpMyAdmin allerdings problematisch werden. Bei der untersuchten Installation kam es bei einer größeren Operation zu einem HTTP-500-Fehler bzw. einem Verbindungsabbruch.

In einem solchen Fall kann es sinnvoll sein, nicht Hunderttausende Datensätze in einer einzigen Operation zu bearbeiten, sondern die Löschung in kleineren Portionen durchzuführen:

DELETE FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY)
LIMIT 1000;

Der Befehl kann wiederholt ausgeführt werden, bis keine entsprechenden Datensätze mehr vorhanden sind.

In der konkreten Datenbank wurden schließlich rund 300.000 Session-Datensätze entfernt.

Warum wird die Datenbank nach dem Löschen kaum kleiner?

Das war der überraschende Teil: Obwohl rund 300.000 Datensätze gelöscht worden waren, sank die angezeigte Gesamtgröße der Datenbank zunächst nur geringfügig.

Das bedeutet nicht, dass MariaDB die gelöschten Datensätze in einem „Papierkorb“ aufbewahrt.

Bei InnoDB führt ein DELETE jedoch nicht zwangsläufig dazu, dass der zuvor von einer Tabelle belegte Speicherplatz unmittelbar als kleinere Tabellendatei sichtbar wird. Frei gewordener Platz kann zunächst innerhalb der Tabelle wiederverwendbar bleiben.

Deshalb kann nach einer großen Löschaktion eine Neuorganisation der Tabelle sinnvoll sein.

Tabelle mit OPTIMIZE TABLE neu organisieren

Dazu kann man ausführen:

OPTIMIZE TABLE `abc_session`;

Bei der untersuchten InnoDB-Tabelle meldete MariaDB daraufhin:

Table does not support optimize, doing recreate + ...

Diese Meldung ist in diesem Zusammenhang nicht automatisch ein Fehler. MariaDB weist damit darauf hin, dass die Optimierung bei dieser Tabelle über einen Neuaufbau erfolgt.

Gerade bei einer großen Tabelle sollte man berücksichtigen, dass ein solcher Vorgang erheblich aufwendiger sein kann als ein gewöhnliches DELETE.

Größe anschließend erneut kontrollieren

Nach der Bereinigung kann die Tabellengröße erneut abgefragt werden:

SELECT
    table_name,
    ROUND(data_length / 1024 / 1024, 2) AS data_mb,
    ROUND(index_length / 1024 / 1024, 2) AS index_mb,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb
FROM information_schema.tables
WHERE table_schema = 'DATENBANKNAME'
ORDER BY (data_length + index_length) DESC;

Das ist auch für die weitere Analyse nützlich: Statt wahllos Joomla-Tabellen zu bereinigen, sieht man sofort, welche Tabellen tatsächlich relevant für die Gesamtgröße sind.

Ein zusätzlicher Joomla-Schalter: „Track Guest Session Metadata“

Bei der Analyse fiel außerdem die Joomla-Einstellung „Track Guest Session Metadata“ auf.

Da die untersuchte Installation gerade durch sehr viele Session-Datensätze auffällig geworden war, ist diese Einstellung ein naheliegender Punkt für die weitere Ursachenanalyse. Aus der hier beschriebenen Untersuchung allein lässt sich allerdings nicht belegen, dass diese Option das starke Wachstum verursacht hat.

Deshalb sollte man sie nicht allein aufgrund der Datenbankgröße deaktivieren, sondern zunächst prüfen, ob und wofür die Installation Gast-Session-Metadaten benötigt.

Was sich aus der Analyse ableiten lässt

Die wichtigste Erkenntnis war weniger ein einzelner SQL-Befehl als die Reihenfolge der Fehlersuche:

1. Zuerst die tatsächlichen Größen aller Tabellen ermitteln.
2. Bei einer auffälligen Session-Tabelle Struktur und Anzahl der Datensätze prüfen.
3. Den Umfang des Feldes data untersuchen.
4. Alte Datensätze zunächst nur per SELECT bzw. COUNT(*) identifizieren.
5. Erst danach gezielt löschen.
6. Bei sehr großen Datenmengen gegebenenfalls in kleineren Blöcken arbeiten.
7. Nicht erwarten, dass ein DELETE bei InnoDB die sichtbare Tabellengröße sofort entsprechend reduziert.
8. Nach größeren Löschaktionen prüfen, ob eine Neuorganisation der Tabelle erforderlich ist.

Vor allem sollte man nicht anfangen, vermeintlich alte Joomla- oder Erweiterungstabellen auf Verdacht zu löschen. Dass eine Tabelle groß, deaktiviert oder historisch gewachsen ist, beweist noch nicht, dass sie für die aktuelle Installation entbehrlich ist.

Die Session-Tabelle ist dagegen ein gutes Beispiel dafür, wie man eine auffällige Datenmenge zunächst nachvollziehbar analysieren kann, bevor man in die Struktur einer produktiven Joomla-Datenbank eingreift.

Wenn fremder PHP-Code mit den Rechten des Webservers ausgeführt werden konnte, muss man davon ausgehen, dass dieser Code auch auf Dateien zugreifen konnte, die für den Webserver lesbar waren.

Bei Joomla gehört dazu insbesondere die configuration.php.

Damit können nach einem solchen Vorfall verschiedene Zugangsdaten als potentiell offengelegt gelten.

Dieser Beitrag beschreibt, welche Zugangsdaten ich nach einem tatsächlichen Joomla-Webshell-Befall geändert habe – und in welcher Reihenfolge.

Ausgangslage

In meinem Fall waren über eine verwundbare Joomla-Erweiterung PHP-Webshells in den Webspace gelangt.

Damit war bestätigt:

Fremder PHP-Code konnte mit den Rechten des Webspace-Benutzers ausgeführt werden.

Das bedeutet noch nicht automatisch, dass der Server als root kompromittiert wurde.

Aber alles, was der Webspace-Benutzer lesen konnte, musste als potentiell bekannt betrachtet werden.

Dazu gehörte insbesondere:

configuration.php

In dieser Datei stehen unter anderem die Joomla-Datenbankverbindung und weitere Konfigurationswerte.

Erst bereinigen, dann Passwörter ändern

Bevor Zugangsdaten rotiert werden, sollte der offensichtliche Angriffsweg geschlossen sein.

Sonst besteht die Gefahr, dass ein weiterhin vorhandener Webshell die neuen Zugangsdaten einfach erneut ausliest.

Die Reihenfolge war deshalb grundsätzlich:

1. verwundbare Erweiterung aktualisieren bzw. Angriffsweg blockieren,
2. bekannte Webshells und Backdoors sichern und aus dem Webroot entfernen,
3. nach weiteren verdächtigen Dateien und Persistenz suchen,
4. erst danach Zugangsdaten rotieren.

Das bedeutet nicht, dass damit garantiert jede mögliche Hintertür ausgeschlossen ist. Aber neue Zugangsdaten in ein offensichtlich noch kompromittiertes System einzutragen wäre wenig sinnvoll.

1. Joomla-Administratorpasswörter ändern

Zunächst wurden die Passwörter aller aktiven Joomla-Administratoraccounts geändert.

Dabei sollte man nicht nur den Hauptadministrator berücksichtigen.

Im Joomla-Backend lohnt sich die Prüfung:

Benutzer → Verwalten

und dort insbesondere:

• Super Users
• Administratoren
• ältere oder kaum noch verwendete Accounts

Nicht mehr benötigte privilegierte Konten sollten deaktiviert oder entfernt werden.

Wichtig ist außerdem:

Das Passwort sollte neu sein und nicht lediglich eine Variante des bisherigen Passworts.

Wenn Zugangsdaten möglicherweise abgeflossen sind, sollte das alte Passwort auch bei anderen Diensten nicht mehr verwendet werden.

2. Bestehende Joomla-Sitzungen beenden

Ein neues Passwort beendet nicht zwangsläufig jede bereits bestehende Sitzung.

Ein Angreifer könnte theoretisch noch über eine gültige Session verfügen.

Deshalb habe ich zusätzlich die Joomla-Sitzungstabelle geleert.

Der Tabellenname hängt vom Präfix der jeweiligen Joomla-Installation ab und kann beispielsweise so aussehen:

abc_session

Vorher sollte man natürlich prüfen, welche Tabelle tatsächlich zur Installation gehört.

Das Leeren der Session-Tabelle meldet alle aktuell angemeldeten Benutzer ab.

Danach müssen sich auch legitime Administratoren erneut anmelden.

Je nach Joomla-Version und verwendeten Funktionen können außerdem persistente Login-Schlüssel existieren. Auch diese sollten nach einem relevanten Sicherheitsvorfall geprüft bzw. invalidiert werden.

3. Datenbankpasswort rotieren

Dieser Schritt ist besonders wichtig, weil Joomla seine Datenbankzugangsdaten normalerweise in:

configuration.php

speichert.

Wer diese Datei über eine Webshell lesen konnte, konnte damit unter Umständen auch Benutzername und Passwort der Joomla-Datenbank erfahren.

Das Datenbankpasswort sollte deshalb geändert werden.

Dabei gibt es allerdings eine kleine Falle:

Datenbankserver und Joomla müssen anschließend dasselbe neue Passwort kennen.

Ändert man nur das Passwort des MySQL-/MariaDB-Benutzers, kann Joomla keine Datenbankverbindung mehr herstellen.

Ändert man nur configuration.php, gilt dasselbe.

Sinnvolle Reihenfolge beim DB-Passwort

Vorher unbedingt ein Backup der Joomla-Konfiguration anlegen.

Zum Beispiel:

cp -a configuration.php /root/configuration.php-before-db-password-change

Dabei ist zu beachten:

Diese Sicherung enthält anschließend das alte Datenbankpasswort im Klartext.

Sie sollte deshalb:

• außerhalb des Webroots liegen,
• nur für root lesbar sein,
• und nach erfolgreichem Abschluss später sicher gelöscht werden.

Dann:

1. neues Datenbankpasswort erzeugen,
2. Passwort des Datenbankbenutzers ändern,
3. Joomla-configuration.php unmittelbar auf dasselbe Passwort setzen,
4. Datenbankverbindung testen,
5. Webseite testen,
6. Joomla-Backend testen.

Während dieses kurzen Übergangs kann die Webseite vorübergehend einen HTTP-500-Fehler liefern, wenn Datenbank und Joomla-Konfiguration noch nicht synchron sind.

Das allein ist in diesem Moment noch kein Hinweis auf einen neuen Defekt.

Datenbankverbindung direkt testen

Nach der Änderung sollte nicht nur die Webseite getestet werden.

Sinnvoll ist auch ein direkter Verbindungstest mit PHP oder dem MySQL-/MariaDB-Client.

Bei PHP kann beispielsweise ein sehr kleiner Test verwendet werden, ohne das Passwort in der Shell-History zu hinterlassen.

Wichtig ist vor allem:

Verbindung erfolgreich

und anschließend ein normaler Aufruf der Joomla-Seite.

Bei meinem System wurden danach sowohl Startseite als auch Administratorbereich erneut kontrolliert.

Beide mussten wieder HTTP 200 liefern.

4. Passwort des Webspace-/Hosting-Benutzers ändern

Wenn ein Angreifer Code mit den Rechten des Webspace-Benutzers ausführen konnte, ist auch dessen Zugang relevant.

Bei Plesk gibt es dafür typischerweise einen Systembenutzer für die jeweilige Subscription bzw. Domain.

Dieser Benutzer kann je nach Konfiguration beispielsweise für:

• SFTP,
• SSH,
• Dateizugriff,
• Deployment

verwendet werden.

Auch dessen Passwort wurde deshalb geändert.

Selbst wenn keine erfolgreiche SSH-Anmeldung dieses Benutzers nachgewiesen wurde, ist die Rotation sinnvoll, wenn dessen Zugangsdaten irgendwo für den kompromittierten Prozess erreichbar gewesen sein könnten.

5. Private SSH-Schlüssel prüfen

Ein Punkt, den man leicht übersieht:

Im Home-Verzeichnis des Webspace-Benutzers können private SSH-Schlüssel liegen.

Beispielsweise:

~/.ssh/id_rsa

In meinem Fall existierte dort tatsächlich ein privater RSA-Schlüssel ohne Passphrase.

Da der Webshell mit den Rechten dieses Benutzers lief, musste angenommen werden, dass der Schlüssel ausgelesen worden sein könnte.

Der Schlüssel wurde deshalb nicht weiter verwendet.

Bei einem kompromittierten privaten SSH-Schlüssel gilt:

Nicht nur die Datei löschen oder verschieben, sondern auch prüfen, wo der zugehörige öffentliche Schlüssel als authorized_key hinterlegt wurde.

Dort sollte der alte Schlüssel entfernt und gegebenenfalls durch einen neuen ersetzt werden.

6. Muss das Root-Passwort ebenfalls geändert werden?

Nicht zwangsläufig aufgrund der Webshell allein.

Hier ist die Unterscheidung wichtig.

Eine PHP-Webshell beweist zunächst die Kompromittierung des PHP-/Webspace-Kontexts.

Sie beweist nicht automatisch:

root wurde kompromittiert

Das Root-Passwort sollte natürlich geändert werden, wenn es Hinweise gibt auf:

• erfolgreiche unbekannte Root-Logins,
• manipulierte authorized_keys,
• verdächtige Systemdienste,
• Root-Persistenz,
• kompromittierte Administrationszugänge,
• oder eine mögliche Privilege Escalation.

In meinem Fall wurde das Root-Passwort im Zuge der Sicherheitsarbeiten ebenfalls erneuert.

Für die Bewertung des Vorfalls blieb die Formulierung trotzdem:

Webspace-Kompromittierung bestätigt, Root-Kompromittierung nicht nachgewiesen.

Diese Unterscheidung hilft, Beobachtungen und Vermutungen nicht miteinander zu vermischen.

7. Plesk- und Provider-Zugang nicht vergessen

Je nach Hostingumgebung können außerdem weitere Zugangsdaten relevant sein:

Plesk
Hosting-Provider
DNS-Provider
Domain-Registrar
Backup-System
Deployment-Dienste
Git-Zugänge

Ob sie tatsächlich geändert werden müssen, hängt davon ab, ob die entsprechenden Zugangsdaten für das kompromittierte System erreichbar waren.

Ein im Browser gespeichertes Provider-Passwort ist beispielsweise durch eine PHP-Webshell auf dem Server nicht automatisch kompromittiert.

Ein API-Key in einer für den Webserver lesbaren Konfigurationsdatei dagegen schon.

Die bessere Frage lautet also:

Konnte der kompromittierte Benutzer dieses Geheimnis lesen?

8. Auch Mail-Zugangsdaten und API-Keys berücksichtigen

Viele Joomla-Installationen enthalten mehr Geheimnisse als nur die Datenbankverbindung.

Mögliche Beispiele:

SMTP-Passwörter
API-Keys
Cloud-Zugangsdaten
Backup-Credentials
OAuth-Secrets
externe Datenbankzugänge
FTP-/SFTP-Zugangsdaten

Sie können in:

configuration.php
.php-Dateien
.env-Dateien
Backup-Dateien
Erweiterungskonfigurationen

liegen.

Nach einer Webshell-Kompromittierung lohnt sich deshalb die Suche nach weiteren Secrets im Webroot.

Nicht jedes gefundene Passwort muss automatisch geändert werden.

Aber alles, was der kompromittierte Benutzer lesen konnte und noch gültig ist, sollte bewertet werden.

9. Vorsicht mit alten Backups

Während einer Reparatur entstehen schnell Dateien wie:

configuration.php.bak
configuration.php.old
configuration.php-before-change

Diese Backups enthalten häufig dieselben Passwörter wie das Original.

Noch problematischer wird es, wenn solche Dateien versehentlich im öffentlichen Webroot liegen.

Deshalb:

• Konfigurationsbackups möglichst unter /root oder einem anderen nicht öffentlichen Ort ablegen,
• restriktive Dateirechte setzen,
• nach erfolgreicher Reparatur nicht benötigte Kopien löschen.

Ein Passwortwechsel hilft wenig, wenn anschließend zehn alte Konfigurationsbackups mit dem vorherigen Passwort herumliegen.

10. Nach jeder Änderung testen

Bei mehreren gleichzeitigen Passwortänderungen kann es sonst schwierig werden herauszufinden, welcher Schritt eine Anwendung beschädigt hat.

Deshalb habe ich die Änderungen nacheinander durchgeführt und jeweils getestet.

Typische Tests:

curl -I https://example.org/

Erwartet:

HTTP 200

Zusätzlich:

Frontend aufrufen
Joomla-Backend aufrufen
Administrator-Login testen
Datenbankzugriff prüfen

So lässt sich ein Fehler unmittelbar dem letzten Änderungsschritt zuordnen.

11. Neue Zugangsdaten nicht in der Shell-History hinterlassen

Gerade bei der Arbeit als root sollte man vermeiden, Passwörter direkt in Befehle einzutragen wie:

mysql -u user -pSUPERGEHEIMESPASSWORT

Denn je nach Shell und Konfiguration kann dieser Befehl in der History landen.

Besser ist:

mysql -u user -p

Danach fragt der Client das Passwort interaktiv ab.

Dasselbe Prinzip gilt für andere Programme, sofern sie eine sichere Passwortabfrage anbieten.

12. Reihenfolge aus der Praxis

Nach dem konkreten Vorfall hat sich für mich folgende Reihenfolge als sinnvoll erwiesen:

1. Sicherheitslücke schließen.
2. bekannte Webshells und Backdoors entfernen bzw. quarantänisieren.
3. nach weiterer Persistenz suchen.
4. Joomla-Administratorpasswörter ändern.
5. Joomla-Sessions invalidieren.
6. Datenbankpasswort ändern und configuration.php synchron aktualisieren.
7. Datenbank und Webseite testen.
8. Passwort des Webspace-/Hosting-Benutzers ändern.
9. vorhandene private SSH-Schlüssel bewerten und gegebenenfalls ersetzen.
10. weitere für den Webserver lesbare Secrets prüfen.
11. Plesk-, Provider- und DNS-Zugänge nach Risikolage bewerten.
12. alte Backups mit inzwischen ungültigen oder sensiblen Zugangsdaten aufräumen.
13. anschließend erneut Logs, Prozesse und Dateisystem kontrollieren.

Was ein Passwortwechsel nicht leistet

Eine Credential-Rotation ist wichtig.

Sie beseitigt aber keine Malware.

Wenn weiterhin eine Webshell aktiv ist, können neue Passwörter möglicherweise sofort wieder abgegriffen werden.

Umgekehrt bedeutet eine erfolgreiche Bereinigung des Webroots nicht, dass alte Zugangsdaten weiterhin bedenkenlos verwendet werden sollten.

Beides gehört zusammen:

Bereinigung + Zugangsdatenrotation

Kurzfassung

Nach einem bestätigten Joomla-Webshell-Befall würde ich mindestens folgende Dinge prüfen bzw. erneuern:

Joomla-Administratorpasswörter
Joomla-Sitzungen
Datenbankpasswort
Webspace-/Hosting-Benutzer
private SSH-Schlüssel
SMTP-/API-/sonstige Secrets

Weitere Administrationszugänge wie:

root
Plesk
Hosting-Provider
DNS
Domain-Registrar

sollten abhängig davon bewertet werden, ob es einen realistischen Zugriffspfad oder konkrete Hinweise auf eine Kompromittierung gibt.

Die wichtigste Grundregel lautet:

Alles, was ein kompromittierter Webspace-Benutzer lesen konnte, sollte als potentiell offengelegt betrachtet werden.

Und genauso wichtig:

Eine PHP-Webshell beweist nicht automatisch eine Root-Kompromittierung.

Diese beiden Aussagen helfen, nach einem Vorfall weder zu wenig noch unnötig viel aus den vorhandenen Spuren abzuleiten.

Beispiele sahen sinngemäß so aus:

m.example.org/...
admin-v2.example.org/...
monitor.example.org/...
wildcard.example.org/...

Das wirkte zunächst so, als hätte jemand diese Subdomains auf dem Server angelegt.

Die eigentliche Ursache war aber eine Kombination aus zwei Dingen:

1. Die Joomla-Seite war zuvor kompromittiert worden und Google hatte dabei ungewöhnliche bzw. manipulierte URLs entdeckt.
2. Für die Domain existierte ein Wildcard-DNS-Eintrag, durch den praktisch jede beliebige Subdomain auf denselben Webserver zeigte.

Der Wildcard-DNS-Eintrag war also nicht die Ursache des Hacks. Er wirkte aber wie ein Verstärker für die unerwünschte Indexierung.

Was ist ein Wildcard-DNS-Eintrag?

Ein Eintrag wie

*.example.org   A   203.0.113.10

bedeutet:

Jede nicht ausdrücklich definierte Subdomain von example.org soll auf diese IP-Adresse zeigen.

Damit funktionieren nicht nur bewusst angelegte Hosts wie:

www.example.org
mail.example.org

sondern grundsätzlich auch:

test.example.org
abc.example.org
m.example.org
admin-v2.example.org
monitor.example.org
irgendwas.example.org

sofern dafür kein spezifischerer DNS-Eintrag existiert.

Ein Test ist einfach:

dig zufallsname-12345.example.org A +short

Wenn dort dieselbe Server-IP zurückkommt, obwohl diese Subdomain nie eingerichtet wurde, ist sehr wahrscheinlich ein Wildcard-DNS-Eintrag aktiv.

DNS allein reicht noch nicht

Ein wichtiger Punkt:

Der Wildcard-DNS-Eintrag allein sorgt noch nicht dafür, dass eine Webseite unter jeder Subdomain erscheint.

DNS beantwortet zunächst nur die Frage:

Auf welche IP-Adresse soll dieser Hostname zeigen?

Danach entscheidet der Webserver, was mit dem HTTP-Request passiert.

Wenn Apache, nginx oder die Hosting-Konfiguration unbekannte Hostnamen einfach an dieselbe Joomla-Installation weiterleitet, kann die Webseite tatsächlich auch unter beliebigen Subdomains erreichbar sein.

Dann wird aus:

https://www.example.org/artikel

möglicherweise ebenfalls:

https://m.example.org/artikel
https://monitor.example.org/artikel
https://abc.example.org/artikel

Wenn diese Varianten öffentlich erreichbar sind, können auch Suchmaschinen sie entdecken.

Der Zusammenhang mit einem Joomla-Hack

In meinem Fall war zuvor eine Joomla-Erweiterung kompromittiert worden.

Dabei waren unter anderem ungewöhnliche URLs entstanden, die von Google gecrawlt wurden.

Eine davon verwies beispielsweise auf eine hochgeladene PHP-Datei innerhalb einer Joomla-Komponente.

Google kann solche URLs unter anderem über externe Links, Crawling, Sitemaps, interne Verweise oder bereits bekannte URL-Muster entdecken.

Wenn gleichzeitig jede beliebige Subdomain auf dieselbe Joomla-Seite zeigt, vervielfacht sich die Zahl potentiell erreichbarer URL-Varianten.

Aus einer URL kann dann theoretisch eine ganze Familie werden:

example.org/pfad
m.example.org/pfad
admin-v2.example.org/pfad
monitor.example.org/pfad
foo.example.org/pfad
bar.example.org/pfad

Das bedeutet nicht zwangsläufig, dass ein Angreifer jede dieser Subdomains bewusst eingerichtet hat.

Sie können schlicht deshalb funktionieren, weil:

*.example.org

auf denselben Server zeigt.

So habe ich den Wildcard-Eintrag gefunden

Zunächst wurde die öffentliche DNS-Konfiguration überprüft.

Ein Test mit einer frei erfundenen Subdomain ist dafür besonders hilfreich:

dig diesegibtesgarantiertnicht.example.org A

Wenn die Antwort beispielsweise lautet:

diesegibtesgarantiertnicht.example.org. 86400 IN A 203.0.113.10

ist klar:

Auch nicht eingerichtete Subdomains werden aufgelöst.

Anschließend sollte man die DNS-Zone beim tatsächlichen DNS-Provider prüfen.

Gesucht wird nach einem Eintrag wie:

*

bzw.

*.example.org

mit einem A- oder AAAA-Record.

Zusätzlich prüfen, ob der Webserver die Subdomain annimmt

Nach der DNS-Prüfung sollte getestet werden, was der Webserver mit einem erfundenen Hostnamen macht.

Zum Beispiel:

curl -I https://zufall-12345.example.org/

Wenn die Seite dort normal mit:

HTTP/2 200

antwortet, wird der unbekannte Hostname tatsächlich von der Webseite bedient.

Für einen gezielten Test gegen eine bestimmte Server-IP kann curl auch ohne Änderung des öffentlichen DNS verwendet werden:

curl --resolve zufall-12345.example.org:443:203.0.113.10 \
  -I https://zufall-12345.example.org/

Damit wird für diesen einzelnen Test so getan, als würde der Name auf die angegebene IP zeigen.

Wildcard-DNS entfernen

Wenn beliebige Subdomains nicht benötigt werden, kann der Wildcard-Eintrag entfernt werden.

Danach sollte ein Test wie:

dig zufall-12345.example.org A +short

keine Server-IP mehr zurückgeben.

Wichtig ist dabei die DNS-TTL.

Bei einem Eintrag mit beispielsweise:

86400

beträgt die maximale Cache-Zeit:

86400 Sekunden = 24 Stunden

Ein bereits aufgelöster Wildcard-Eintrag kann deshalb noch eine Zeit lang in DNS-Caches vorhanden sein.

Das bedeutet nicht, dass die Änderung nicht funktioniert hat.

DNS entfernen reicht langfristig nicht immer aus

Zusätzlich zur DNS-Bereinigung ist es sinnvoll, den Webserver so zu konfigurieren, dass unbekannte Hostnamen nicht einfach dieselbe Joomla-Seite ausliefern.

Ein Server sollte idealerweise nur die ausdrücklich vorgesehenen Hosts akzeptieren, zum Beispiel:

example.org
www.example.org

Unbekannte Hosts können stattdessen:

• abgewiesen werden,
• einen Fehlerstatus liefern,
• oder kontrolliert auf die kanonische Domain umgeleitet werden.

Welche Variante sinnvoll ist, hängt von der jeweiligen Server- und Hosting-Konfiguration ab.

Der Vorteil:

Selbst wenn später versehentlich wieder ein DNS-Eintrag auf den Server zeigt, liefert der Webserver nicht automatisch die eigentliche Joomla-Seite aus.

Canonical-Tags helfen, lösen das Problem aber nicht allein

Joomla bzw. SEO-Erweiterungen können sogenannte Canonical-URLs ausgeben.

Beispielsweise:

<link rel="canonical"
      href="https://www.example.org/artikel">

Damit wird Suchmaschinen signalisiert:

Diese URL ist die bevorzugte Version des Inhalts.

Das ist hilfreich, ersetzt aber keine saubere DNS- und Webserver-Konfiguration.

Wenn hunderte oder tausende alternative Hosts öffentlich dieselben Inhalte ausliefern, sollte die Ursache behoben werden, statt sich nur auf Canonical-Tags zu verlassen.

Warum Google die alten URLs trotzdem noch zeigt

Nachdem der Wildcard-DNS-Eintrag entfernt wurde, verschwinden die betreffenden URLs nicht sofort aus der Google Search Console.

Google kennt diese Adressen weiterhin aus seinem bisherigen Crawl.

Erst wenn Google sie erneut besucht und feststellt, dass sie nicht mehr erreichbar sind oder korrekt umgeleitet werden, kann sich der Index entsprechend ändern.

Das kann deutlich länger dauern als die DNS-Umstellung selbst.

Deshalb sollte man unterscheiden:

DNS

Die Änderung kann – abhängig von der TTL – innerhalb von Stunden wirksam werden.

Google-Index

Bereits bekannte URLs können noch Tage, Wochen oder länger in Berichten auftauchen.

Eine alte URL in der Search Console ist deshalb nicht automatisch ein Hinweis darauf, dass sie aktuell noch funktioniert.

Stichproben nach der Änderung

Nach Ablauf der DNS-TTL lohnt sich ein erneuter Test:

dig zufall-67890.example.org A +short

Erwartetes Ergebnis:

keine Ausgabe

Danach können einige der zuvor von Google gefundenen Hosts geprüft werden.

Beispielsweise:

dig m.example.org A +short
dig admin-v2.example.org A +short
dig monitor.example.org A +short

Wenn diese Namen nie benötigt wurden, sollten sie nach der Bereinigung nicht mehr auf den Webserver zeigen.

Wildcard-DNS ist nicht grundsätzlich schlecht

Ein Wildcard-Eintrag ist kein Sicherheitsproblem per se.

Es gibt legitime Anwendungen, beispielsweise:

kunde1.example.org
kunde2.example.org
kunde3.example.org

wenn eine Anwendung dynamisch beliebige Subdomains verwendet.

Problematisch wird ein Wildcard-Eintrag vor allem dann, wenn:

• er gar nicht benötigt wird,
• niemand mehr weiß, warum er existiert,
• der Webserver jeden beliebigen Host akzeptiert,
• oder ein kompromittiertes System dadurch unter vielen Hostnamen erreichbar wird.

In einer normalen Joomla-Webseite mit wenigen fest definierten Domains gibt es häufig keinen Grund, jede denkbare Subdomain auf dieselbe Installation zeigen zu lassen.

Was der Wildcard-Eintrag nicht beweist

Bei der Untersuchung eines Hacks ist auch hier Vorsicht bei Schlussfolgerungen wichtig.

Ein Eintrag wie:

*.example.org

beweist nicht:

Ein Angreifer hat hunderte Subdomains angelegt.

Tatsächlich wurde möglicherweise keine einzige davon individuell eingerichtet.

Ebenso beweist eine bei Google auftauchende Adresse wie:

admin-v2.example.org

nicht automatisch, dass dort tatsächlich ein Administrationssystem existierte.

Der Name kann vollkommen beliebig sein.

Der entscheidende Test ist deshalb immer:

Warum löst dieser Hostname überhaupt auf und was liefert der Server bei einem Request dorthin aus?

Kurzfassung

Symptom

Google kennt plötzlich viele unbekannte Subdomains wie:

m.example.org
admin-v2.example.org
monitor.example.org

Mögliche Ursache

In der DNS-Zone existiert:

*.example.org

und zeigt auf denselben Webserver wie die eigentliche Webseite.

Zusätzliche Voraussetzung

Der Webserver akzeptiert die unbekannten Hostnamen und liefert dafür ebenfalls die Joomla-Seite aus.

Folge

Beliebig viele Hostnamen können auf dieselben oder auf kompromittierte Joomla-URLs zeigen und von Suchmaschinen entdeckt werden.

Lösung

Wenn Wildcard-Subdomains nicht benötigt werden:

1. Wildcard-DNS-Eintrag entfernen.
2. DNS-TTL abwarten.
3. Zufällige Subdomains mit dig testen.
4. Webserver so konfigurieren, dass nur vorgesehene Hostnamen akzeptiert werden.
5. Canonical-URLs kontrollieren.
6. Google die alten URLs anschließend neu crawlen lassen.

Fazit

Der Wildcard-DNS-Eintrag war in meinem Fall nicht die Ursache der Joomla-Kompromittierung.

Er erklärte aber, warum völlig frei erfundene Subdomains dieselbe Joomla-Webseite auslieferten und warum Google ungewöhnlich viele Hostvarianten kennen konnte.

Die wichtigste Erkenntnis war deshalb:

Bei merkwürdigen Subdomains nach einem Website-Hack nicht automatisch davon ausgehen, dass diese einzeln angelegt wurden. Zuerst DNS-Wildcards und die Host-Konfiguration des Webservers prüfen.

Gerade die Kombination aus kompromittierten URLs, Wildcard-DNS und einem Webserver, der unbekannte Hostnamen akzeptiert, kann einen einzelnen Vorfall im Suchmaschinenindex deutlich größer erscheinen lassen, als er technisch tatsächlich ist.

Stattdessen antwortete die Seite mit:

HTTP 500 Internal Server Error

Das ist ungünstig, weil eine nicht vorhandene Ressource semantisch kein Serverfehler ist. Für Browser, Suchmaschinen und Monitoring sollte eine nicht mehr existierende Datei mit HTTP 404 Not Found beantwortet werden.

In meinem Fall ließ sich das mit einem sehr kleinen Patch beheben.

Betroffene Datei

Der Fehler trat in folgender RSFiles-Datei auf:

components/com_rsfiles/views/rsfiles/view.html.php

Dort wird zunächst versucht, die angeforderte Datei zu laden:

$this->file = $this->get('File');

Wenn weder ein passender Datenbankeintrag noch eine physische Datei vorhanden war, lieferte das Model false zurück.

Die Verarbeitung lief anschließend jedoch weiter.

Später landete der Fehler in der allgemeinen RSFiles-Fehlerbehandlung, die in dieser Konstellation eine Exception mit HTTP-Status 500 erzeugte.

Damit wurde aus einer simplen „Datei existiert nicht“-Situation ein interner Serverfehler.

Der Patch

Direkt nach:

$this->file = $this->get('File');

habe ich folgende Prüfung eingefügt:

// Return a proper 404 for missing files
if (empty($this->file)) {
    throw new Exception(Text::_('COM_RSFILES_CANNOT_FIND_FILE'), 404);
}

Damit wird eine nicht vorhandene RSFiles-Ressource unmittelbar als HTTP 404 behandelt.

Vorher sichern

Vor Änderungen an Erweiterungsdateien sollte die Originaldatei gesichert werden.

Zum Beispiel:

cp -a \
components/com_rsfiles/views/rsfiles/view.html.php \
/root/rsfiles-view.html.php-before-404

Anschließend kann der Patch in die Live-Datei eingefügt werden.

PHP-Syntax prüfen

Nach der Änderung sollte die Datei unbedingt auf Syntaxfehler geprüft werden.

In meinem Setup mit Plesk und PHP 8.2:

/opt/plesk/php/8.2/bin/php -l \
components/com_rsfiles/views/rsfiles/view.html.php

Erwartetes Ergebnis:

No syntax errors detected

Test

Anschließend habe ich bewusst nicht vorhandene RSFiles-Pfade aufgerufen.

Vor dem Patch:

HTTP 500

Nach dem Patch:

HTTP 404

Unter anderem wurden ein frei erfundener Dateiname sowie eine zuvor entfernte verdächtige Datei getestet.

Die Joomla-Startseite lieferte gleichzeitig weiterhin:

HTTP 200

Damit war sichergestellt, dass nicht versehentlich eine allgemeine Fehlerbehandlung beschädigt worden war.

Warum das relevant ist

Der Unterschied zwischen 404 und 500 ist nicht nur kosmetisch.

HTTP 404

bedeutet:

Die angeforderte Ressource existiert nicht.

Das ist bei einer gelöschten oder unbekannten Datei korrekt.

HTTP 500

bedeutet:

Bei der Verarbeitung auf dem Server ist ein interner Fehler aufgetreten.

Das suggeriert einen Defekt der Anwendung oder des Servers.

Gerade nach einem Sicherheitsvorfall kann das relevant sein, wenn Suchmaschinen noch URLs zu inzwischen entfernten Dateien kennen.

Ein sauberer HTTP-404-Status signalisiert dann:

Diese Ressource ist nicht mehr vorhanden.

Wichtig: Updatefest ist der Patch nicht

Die Änderung liegt direkt in einer RSFiles-Komponentendatei:

components/com_rsfiles/views/rsfiles/view.html.php

Ein späteres RSFiles-Update kann diese Datei überschreiben.

Deshalb sollte der Patch dokumentiert und nach Updates kontrolliert werden.

Idealerweise sollte ein solcher Fall natürlich direkt in der Erweiterung selbst korrekt behandelt werden. Ein lokaler Patch ist vor allem dann sinnvoll, wenn kurzfristig ein sauberes HTTP-Verhalten benötigt wird.

Kurzfassung

Problem

Nicht vorhandene RSFiles-Dateien erzeugten:

HTTP 500

Ursache

Das RSFiles-Model lieferte bei einer fehlenden Datei false, die View behandelte diesen Zustand aber nicht unmittelbar als „nicht gefunden“.

Patch

Direkt nach:

$this->file = $this->get('File');

einfügen:

if (empty($this->file)) {
    throw new Exception(Text::_('COM_RSFILES_CANNOT_FIND_FILE'), 404);
}

Ergebnis

Fehlende Dateien liefern anschließend korrekt:

HTTP 404

statt:

HTTP 500

Hinweis: Der Patch wurde an einer konkreten RSFiles-Installation getestet. Vor Änderungen sollte die betroffene Datei gesichert und nach jedem RSFiles-Update geprüft werden, ob die Anpassung noch notwendig ist.

In einer von mir administrierten Joomla-Installation war diese Schwachstelle tatsächlich ausgenutzt worden.

Dieser Beitrag dokumentiert die wichtigsten Spuren, die Bereinigung und einige Erkenntnisse aus dem Vorfall.

Die Sicherheitslücke

RSJoomla veröffentlichte am 10. Juli 2026 RSFiles! 1.17.12 und schloss damit eine Schwachstelle im Frontend-Upload.

Nach Angaben des Herstellers konnte die fehlerhafte Upload-Funktion von nicht angemeldeten Besuchern verwendet werden und erlaubte dabei auch Dateitypen, die dort niemals hätten landen dürfen – einschließlich PHP-Dateien.

Die Schwachstelle wurde mit RSFiles! 1.17.12 behoben.

Wer eine ältere Version eingesetzt hat, sollte deshalb nicht nur aktualisieren, sondern auch prüfen, ob die Lücke bereits ausgenutzt wurde.

Das erste sichtbare Symptom

Die Webseite selbst wirkte zunächst weitgehend normal.

Auffällig wurde der Vorfall unter anderem durch ungewöhnliche, von Google indexierte URLs. Eine davon sah beispielsweise so aus:

/component/rsfiles/details?path=Nx_164.php&Itemid=...

Eine PHP-Datei mit einem Namen wie Nx_164.php hat in einem normalen Downloadbestand nichts verloren.

Bei der anschließenden Untersuchung fanden sich tatsächlich zahlreiche verdächtige PHP-Dateien im RSFiles-Downloadbereich.

Gefundene Dateien

Unter den Funden waren unter anderem Namen wie:

Nx_*.php
shell.php
shell.PHP
sh.phtml
se.phar
se.inc
rsfiles_cache.php
bob_ipob4.php
bob_ipob4.php5
bob_ipob4.php7

Daneben existierten weitere PHP-, PHTML- und PHAR-Dateien mit zufällig wirkenden Namen.

Wichtig: Ein verdächtiger Dateiname allein beweist noch nicht, was eine Datei tut.

In diesem Fall zeigte die Inhaltsanalyse jedoch eindeutig Funktionen, die in einem normalen Downloadverzeichnis nichts zu suchen haben, darunter Datei-Uploads, Base64-Verarbeitung, PHP-Informationen und Möglichkeiten zur Ausführung von PHP-Funktionen.

Damit war klar: Es handelte sich nicht nur um erfolglose Angriffsversuche. Auf dem Webspace lagen tatsächlich Webshells.

Was ein solcher Fund bedeutet – und was nicht

Eine ausführbare Webshell unter dem Benutzer des Webservers ist ein ernstzunehmender Sicherheitsvorfall.

Sie bedeutet in diesem Fall:

Fremder PHP-Code konnte mit den Rechten des Joomla-/Webspace-Benutzers ausgeführt werden.

Das ist allerdings nicht automatisch gleichbedeutend mit:

Der gesamte Server wurde als root kompromittiert.

Diese Unterscheidung ist wichtig.

Ein PHP-Prozess kann beispielsweise:

• Joomla-Dateien lesen und verändern,
• configuration.php und damit Datenbankzugangsdaten lesen,
• Dateien im Webspace anlegen,
• weitere Schadsoftware nachladen,
• erreichbare Dienste ansprechen.

Ob darüber hinaus Root-Rechte erlangt wurden, muss separat untersucht werden.

In meinem Fall gab es Belege für eine Kompromittierung des Webspace-Benutzers, aber keinen belastbaren Nachweis einer erfolgreichen Root-Kompromittierung.

Die Access-Logs waren besonders hilfreich

In den Webserver-Logs ließen sich Upload-Versuche nachvollziehen.

Auffällig waren unter anderem Requests auf:

index.php?option=com_rsfiles&task=upload

bzw.

index.php?option=com_rsfiles&task=rsfiles.upload

Der Hersteller selbst empfiehlt nach Bekanntwerden der Schwachstelle, insbesondere nach entsprechenden POST-Requests zu suchen.

Eine einfache Suche kann beispielsweise so aussehen:

grep -Rni \
'option=com_rsfiles.*task=.*upload' \
/var/www/vhosts/system/DOMAIN/logs/

Dabei sollte man beachten:

Eine IP-Adresse im Log bezeichnet zunächst nur die Quelle eines Requests. Daraus lässt sich nicht ohne Weiteres ableiten, welche reale Person hinter einem Angriff stand.

Nicht einfach alles löschen

Bei einem solchen Vorfall ist die Versuchung groß, verdächtige Dateien sofort zu löschen.

Für eine spätere Analyse ist es sinnvoller, sie zunächst außerhalb des Webroots zu sichern.

Beispielsweise:

mkdir -p /root/incident-quarantine
chmod 700 /root/incident-quarantine

Verdächtige Dateien können anschließend dorthin verschoben und nur für root lesbar gemacht werden.

Vor dem Verschieben sollte man – sofern möglich – mindestens festhalten:

stat DATEI
sha256sum DATEI
file DATEI

So bleiben Dateigröße, Zeitstempel, Dateityp und kryptographischer Hash dokumentiert.

Ein SHA256-Hash ist beispielsweise hilfreich, um später festzustellen, ob mehrere unterschiedlich benannte Dateien tatsächlich identisch waren.

Weitere Kopien außerhalb des Downloadordners

Die Untersuchung sollte nicht beim offensichtlichen Fundort enden.

In meinem Fall fanden sich weitere verdächtige PHP-Dateien außerhalb des ursprünglichen Upload-Verzeichnisses, unter anderem in Bereichen wie:

administrator/cache/
modules/
templates/

Das ist ein typisches Problem bei Webshell-Befall: Eine zunächst hochgeladene Datei kann dazu verwendet werden, weitere Kopien oder Backdoors anzulegen.

Deshalb wurde anschließend der gesamte Joomla-Dateibaum nach bekannten Mustern und den bereits gefundenen Dateinamen durchsucht.

Beispielsweise:

grep -RIl \
'DataBase_Cache_\|Nx-' \
/var/www/vhosts/DOMAIN/httpdocs \
2>/dev/null

Solche Suchmuster sind immer nur Indikatoren. Ein Treffer muss geprüft werden, bevor eine Datei entfernt wird.

Auch temporäre Verzeichnisse prüfen

Besonders interessant wurden außerdem:

/tmp
/var/tmp
/dev/shm

Dort fanden sich in diesem Fall mehrere versteckte ausführbare Dateien unter harmlos klingenden Namen.

Beispiele für solche Tarnnamen waren sinngemäß:

.dbus-session-temp-runtime
.firefox-browser-profile-cache
.libreoffice-auto-save-tmp
.nautilus-metadata-cache

Mehrere dieser Dateien waren binär identisch.

Sie lagen in einem privaten temporären Verzeichnis des Apache-Dienstes und gehörten dem Webspace-Benutzer.

Vor der Quarantäne wurde geprüft, ob sie aktuell ausgeführt oder von einem Prozess geladen wurden, beispielsweise mit:

lsof

sowie über /proc.

Zum Zeitpunkt der Untersuchung gab es dafür keine Hinweise.

Auch das ist eine wichtige sprachliche Unterscheidung:

Keine laufende Instanz gefunden

ist nicht dasselbe wie:

Diese Datei wurde niemals ausgeführt.

SSH-Schlüssel des Webspace-Benutzers

Im Home-Verzeichnis des Webspace-Benutzers fand sich außerdem ein privater SSH-Schlüssel.

Er war nicht mit einer Passphrase geschützt.

Da die Webshell mit den Rechten dieses Benutzers lief, musste davon ausgegangen werden, dass dieser private Schlüssel ausgelesen worden sein könnte.

Der Schlüssel wurde deshalb aus dem Webspace entfernt und in die Root-Quarantäne verschoben.

Das ist ein Punkt, der bei Webshell-Vorfällen leicht übersehen wird:

Nicht nur Joomla-Passwörter können betroffen sein. Alles, was der kompromittierte Benutzer lesen konnte, muss als potentiell bekannt betrachtet werden.

Zugangsdaten nach der Bereinigung ändern

Nach der Dateibereinigung wurden deshalb unter anderem folgende Zugangsdaten rotiert:

• Joomla-Administratorpasswörter
• Joomla-Datenbankpasswort
• Passwort des Hosting-/Webspace-Benutzers

Zusätzlich wurden bestehende Joomla-Sitzungen invalidiert.

Beim Datenbankpasswort ist wichtig, dass Passwortänderung und Joomla-Konfiguration zusammenpassen. Wird nur das Datenbankkonto geändert, kann Joomla anschließend keine Verbindung mehr herstellen.

Nach der Änderung sollte deshalb sowohl eine direkte Datenbankverbindung als auch die Webseite getestet werden.

RSFiles! aktualisieren

Der entscheidende erste Schutz ist selbstverständlich die Aktualisierung von RSFiles!.

Die konkrete Upload-Schwachstelle wurde mit:

RSFiles! 1.17.12

behoben.

Bei einer späteren Bereinigung sollte jedoch nicht gezielt auf 1.17.12 aktualisiert werden, sondern auf die jeweils aktuelle vom Hersteller bereitgestellte Version.

Nach einem Update sollte außerdem geprüft werden, ob wirklich der neue Code ausgeführt wird und ob nicht alte Kopien der Erweiterung im Webroot liegen.

Frontend-Upload zusätzlich blockieren

In meinem Fall wurde der öffentliche RSFiles-Upload überhaupt nicht benötigt.

Deshalb habe ich zusätzlich auf Webserver-Ebene den öffentlichen Upload-Endpunkt gesperrt.

Die Regel wurde vor den normalen Joomla-Rewrite-Regeln in .htaccess eingefügt:

# Block public RSFiles frontend upload
RewriteCond %{REQUEST_URI} !^/administrator/ [NC]
RewriteCond %{QUERY_STRING} (^|&)option=com_rsfiles(&|$) [NC]
RewriteCond %{QUERY_STRING} (^|&)task=(rsfiles\.)?upload(&|$) [NC]
RewriteRule ^ - [F,L]

Danach wurden unter anderem folgende Varianten getestet:

task=rsfiles.upload
task=upload

und mussten mit HTTP 403 beantwortet werden.

Die normale Startseite musste gleichzeitig weiterhin HTTP 200 liefern.

Wichtig

Diese Regel ist nur sinnvoll, wenn Frontend-Uploads tatsächlich nicht benötigt werden.

Wer RSFiles! bewusst dafür einsetzt, darf den Endpunkt natürlich nicht einfach sperren.

Die Aktualisierung der Erweiterung ersetzt diese zusätzliche Schutzmaßnahme ebenfalls nicht.

Downloadverzeichnis gegen direkte Ausführung schützen

RSJoomla empfiehlt außerdem, Download- und Briefcase-Verzeichnisse zu schützen.

Je nach Serverkonfiguration wird dafür beispielsweise eine .htaccess verwendet, die direkten Zugriff verhindert.

Auf dem untersuchten System existierte im Downloadverzeichnis bereits eine entsprechende Schutzdatei.

Trotzdem war die Schwachstelle zuvor ausnutzbar gewesen.

Daraus folgt:

Ein geschützter Downloadordner ersetzt kein Sicherheitsupdate.

Mehrere Schutzschichten sind sinnvoll, aber die verwundbare Anwendung selbst muss trotzdem aktualisiert werden.

Joomla- und RSFiles-Datenbank ebenfalls prüfen

Die Untersuchung beschränkte sich nicht auf das Dateisystem.

Auch die RSFiles-Datenbank enthielt Einträge zu den hochgeladenen Dateien.

Dabei konnten verdächtige Einträge identifiziert und nach vorheriger Sicherung entfernt werden.

Wichtig ist auch hier die Trennung:

Verdächtig aussehende Zeichenketten in einer Datenbank beweisen nicht automatisch eine erfolgreiche SQL-Injection.

Sie können beispielsweise einfach Eingaben eines Angreifers sein, die eine Anwendung gespeichert hat.

Prüfen, ob noch PHP-Dateien in schreibbaren Bereichen liegen

Nach der Bereinigung wurde gezielt nach PHP-Dateien in typischerweise schreibbaren Verzeichnissen gesucht.

Besonders relevant sind beispielsweise:

images/
cache/
tmp/
downloads/

Ein möglicher Check:

find \
images cache tmp downloads \
-type f \
\( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) \
-print

Ein leerer Treffer ist beruhigend.

Er beweist allerdings nicht mathematisch, dass ein System vollständig sauber ist.

Prozesse kontrollieren

Auch nach der Dateibereinigung sollte geprüft werden, ob noch Prozesse unter dem Webspace-Benutzer laufen, die dort nicht hingehören.

Beispielsweise:

ps aux

und gezielter:

ps -u WEBUSER -f

Außerdem lohnt sich ein Blick auf Netzwerkverbindungen und offene Ports.

Bei einer beobachteten SSH-Verbindung ist allerdings Vorsicht bei der Interpretation nötig:

Eine bestehende TCP-Verbindung auf Port 22 beweist noch keinen erfolgreichen SSH-Login.

Im konkreten Fall zeigte die anschließende Prüfung der Authentifizierungslogs lediglich fehlgeschlagene Loginversuche.

Cronjobs und Persistenz

Ein Angreifer könnte versuchen, Schadcode über Cronjobs oder andere Autostartmechanismen dauerhaft zu machen.

Deshalb wurden unter anderem geprüft:

root-Crontab
Crontab des Webspace-Benutzers
systemweite Cron-Verzeichnisse

Dort fanden sich keine offensichtlichen Hinweise auf eine zusätzliche Persistenz.

Weitere sinnvolle Prüfstellen sind:

systemd-Units und Timer
/etc/rc.local
Shell-Startdateien

Was man aus einem leeren Malware-Scan nicht ableiten darf

Nach der Bereinigung ergaben verschiedene Suchläufe keine Treffer mehr auf die bekannten Indikatoren.

Das ist wichtig – aber die Formulierung sollte korrekt bleiben.

Richtig ist:

In den untersuchten Verzeichnissen wurden keine weiteren Dateien gefunden, die den bekannten Suchmustern entsprachen.

Nicht richtig wäre:

Der Server ist damit garantiert sauber.

Insbesondere nach einer bestätigten Webshell-Kompromittierung bleibt eine Neuinstallation bzw. Migration auf ein frisches System die robusteste langfristige Lösung.

Root-Kompromittierung nicht ohne Beleg behaupten

Ein weiterer wichtiger Punkt aus diesem Vorfall:

Die Existenz einer Webshell beweist eine erfolgreiche Codeausführung im Kontext des Webservers.

Sie beweist nicht automatisch, dass ein Angreifer Root-Rechte hatte.

In meinem Fall gab es:

• bestätigte fremde PHP-Dateien,
• Webshell-Funktionalität,
• verdächtige Binärdateien unter dem Webspace-Benutzer,
• Zugriffsmöglichkeiten auf Joomla-Konfiguration und andere für diesen Benutzer lesbare Dateien.

Es gab jedoch keinen belastbaren Beleg dafür, dass Root-Rechte erlangt wurden.

Für die Entscheidung über eine spätere Neuinstallation ist der Vorfall trotzdem ernst genug.

Meine Kurzfassung des Vorgehens

Bei einem bestätigten RSFiles-Webshell-Befall würde ich heute in ungefähr dieser Reihenfolge vorgehen:

1. RSFiles! auf die aktuelle sichere Version bringen bzw. den verwundbaren Upload sofort unterbinden.
2. Verdächtige Dateien nicht blind löschen, sondern zunächst dokumentieren und außerhalb des Webroots quarantänisieren.
3. Access-Logs auf RSFiles-Upload-Requests untersuchen.
4. Joomla-Webroot vollständig nach weiteren Backdoors durchsuchen.
5. /tmp, /var/tmp und /dev/shm prüfen.
6. Prozesse und Netzwerkverbindungen kontrollieren.
7. Cronjobs und weitere Persistenzmechanismen untersuchen.
8. Alle für den kompromittierten Webuser lesbaren Zugangsdaten als potentiell offengelegt behandeln.
9. Joomla-Admin-, Datenbank- und Hosting-Zugangsdaten rotieren.
10. Sitzungen invalidieren.
11. Downloadbereiche absichern.
12. Wenn Frontend-Upload nicht gebraucht wird, ihn zusätzlich auf Webserver-Ebene blockieren.
13. Nach der Bereinigung erneut nach den bekannten Indikatoren suchen.
14. Langfristig eine Migration auf ein frisches, unterstütztes System erwägen.

Fazit

Der wichtigste Punkt dieses Vorfalls war für mich, einen zunächst relativ unauffälligen Joomla-Hack nicht nur als „ein paar PHP-Dateien im Downloadordner“ zu behandeln.

Sobald eine ausführbare Webshell vorhanden war, musste davon ausgegangen werden, dass der Angreifer alle Möglichkeiten des Webspace-Benutzers hatte.

Gleichzeitig ist es wichtig, bei der Analyse nicht weiterzugehen, als die Belege tragen: Eine kompromittierte Joomla-/PHP-Umgebung ist noch kein Beweis für einen kompromittierten Root-Account.

Die Kombination aus Log-Auswertung, Dateisystemanalyse, Quarantäne, Credential-Rotation und zusätzlichem Hardening hat den konkreten Vorfall bereinigt.

Langfristig ersetzt das jedoch nicht die Überlegung, ein kompromittiertes Altsystem auf einer frischen und unterstützten Plattform neu aufzubauen.

Quellen

• RSJoomla!, „Unauthenticated File Upload fixed in RSFiles! version 1.17.12 – update NOW!“, 10.07.2026
• RSJoomla!, RSFiles! Changelog, Version 1.17.12 und folgende Versionen

Die Herstellerinformation bestätigt, dass RSFiles! 1.17.12 die unauthenticated-file-upload-Schwachstelle behebt und empfiehlt ausdrücklich, Download- und Briefcase-Verzeichnisse sowie die Webserver-Logs auf verdächtige Uploads zu kontrollieren.

Call to undefined method Joomla\Database\Mysqli\MysqliDriver::nameQuote()

Die EasyBlog-Übersichten und die auf der Startseite eingebundenen „Latest Blogs“-Module funktionierten weiterhin. Erst beim Aufruf eines einzelnen Blogbeitrags trat der Fehler auf.

Hier dokumentiere ich Ursache und Lösung, weil sich der eigentliche Fehler erst nach einem Vergleich der installierten EasyBlog-Dateien mit dem offiziellen Installationspaket zeigte.

System

Zum Zeitpunkt des Fehlers:

• Joomla 5.4.8
• EasyBlog 6.0.18
• PHP 8.2
• Plesk

EasyBlog selbst zeigte im Backend korrekt die Version 6.0.18 an.

Die Fehlermeldung

Die Meldung

Call to undefined method Joomla\Database\Mysqli\MysqliDriver::nameQuote()

deutet zunächst auf alten Datenbankcode hin.

In verschiedenen EasyBlog-Dateien fanden sich noch Aufrufe wie:

$db->nameQuote(...)

Beim normalen Joomla-Datenbanktreiber steht diese alte Methode unter Joomla 5.4 nicht mehr zur Verfügung. Die aktuelle Methode heißt:

$db->quoteName(...)

Ein globales Suchen und Ersetzen von nameQuote() durch quoteName() ist trotzdem keine gute Lösung, weil EasyBlog teilweise eine eigene Datenbank-Kompatibilitätsschicht verwendet.

Entscheidend ist also auch, welches Datenbankobjekt an der jeweiligen Stelle verwendet wird.

Auffälliger Code

Bei der Fehlersuche fanden sich beispielsweise Konstruktionen wie:

$db = $this->getDBO();

$query = 'SELECT ... ' . $db->nameQuote(...);

$this->getDBO() liefert hier den normalen Joomla-Datenbanktreiber.

Andere EasyBlog-Bereiche verwenden dagegen:

$db = EB::db();

EasyBlog besitzt dafür eine eigene Kompatibilitätsschicht.

Damit stellte sich die Frage, warum in einer Installation, die bereits als EasyBlog 6.0.18 ausgewiesen wurde, unterschiedliche Code-Stände vorhanden waren.

Der entscheidende Test: Vergleich mit dem offiziellen EasyBlog-Paket

Ich hatte das originale Installationspaket von EasyBlog 6.0.18 noch vorliegen.

Daraufhin wurden die installierten Dateien per SHA256 mit den entsprechenden Dateien aus diesem offiziellen Paket verglichen.

Dabei zeigten sich sechs Abweichungen im Verzeichnis:

administrator/components/com_easyblog/tables/

Betroffen waren:

oauth.php
meta.php
feedburner.php
tag.php
adsense.php
teamblog.php

Andere Dateien aus demselben Verzeichnis entsprachen dagegen exakt dem offiziellen 6.0.18-Paket.

Damit war die eigentliche Ursache gefunden:

Die Installation meldete zwar EasyBlog 6.0.18, der Dateibestand entsprach aber nicht vollständig dem offiziellen EasyBlog-6.0.18-Paket.

Es handelte sich also nicht einfach um eine generelle Inkompatibilität von EasyBlog 6.0.18 mit Joomla 5.4, sondern um einen gemischten bzw. unvollständig aktualisierten Dateibestand.

Die Lösung

Zunächst wurden die vorhandenen sechs Dateien gesichert.

Beispielsweise:

mkdir -p /root/easyblog-backup

cp -a \
administrator/components/com_easyblog/tables/oauth.php \
administrator/components/com_easyblog/tables/meta.php \
administrator/components/com_easyblog/tables/feedburner.php \
administrator/components/com_easyblog/tables/tag.php \
administrator/components/com_easyblog/tables/adsense.php \
administrator/components/com_easyblog/tables/teamblog.php \
/root/easyblog-backup/

Anschließend wurden genau diese sechs Dateien durch die entsprechenden Originaldateien aus dem offiziellen EasyBlog-6.0.18-Paket ersetzt.

Danach wurden die neuen Live-Dateien erneut per SHA256 gegen das Originalpaket geprüft.

Alle sechs Dateien ergaben:

OK

Zusätzlich wurde jede Datei mit PHP auf Syntaxfehler geprüft:

/opt/plesk/php/8.2/bin/php -l DATEI.php

Bei allen sechs Dateien lautete das Ergebnis:

No syntax errors detected

Ergebnis

Unmittelbar nach dem Austausch ließen sich die EasyBlog-Beiträge wieder normal öffnen.

Der Fehler

Call to undefined method Joomla\Database\Mysqli\MysqliDriver::nameQuote()

war verschwunden.

Auch sämtliche auf der Startseite über das EasyBlog-LatestBlogs-Modul verlinkten Beiträge funktionierten wieder.

An der Datenbank musste für die eigentliche Reparatur nichts verändert werden.

Was während der Diagnose nicht geholfen hat

Vor der eigentlichen Ursache wurden unter anderem folgende Möglichkeiten untersucht:

• EasyBlog-Smart-Search-Plugin deaktiviert
• alte EasySocial-Plugins kontrolliert
• EasyBlog-Menüeinträge und Routing untersucht
• verschiedene EasyBlog-URL-Präfixe getestet
• einzelne nameQuote()-Aufrufe testweise auf quoteName() geändert
• OAuth-Code als möglicher Fehlerpfad untersucht

Diese Schritte halfen bei der Eingrenzung, behoben das Problem aber nicht dauerhaft.

Nebenbefund: EasyBlog-Routing

Während der Fehlersuche fiel auf, dass EasyBlog für dieselbe Kategorie mehrere technische Menüeinträge zur Verfügung hatte.

Dadurch wurden je nach aktiviertem Menüpunkt URLs wie

/easyblog-aktuelles-template/artikelname

oder

/mzffm-aktuelles/artikelname

erzeugt.

Das war jedoch nicht die Ursache des nameQuote()-Fehlers. Das Ändern des Menüeintrags änderte lediglich die URL, während der PHP-Fehler bestehen blieb.

Warum ich nicht einfach nameQuote() global ersetzt habe

Ein pauschales

nameQuote() → quoteName()

über die gesamte EasyBlog-Installation hätte zwar einzelne Fehlerstellen beseitigen können, aber nicht die eigentliche Ursache gelöst.

Da EasyBlog teilweise eigene Datenbank-Wrapper verwendet, kann derselbe Methodenaufruf je nach Kontext unterschiedlich problematisch sein.

Der zuverlässigere Ansatz war:

1. installierte EasyBlog-Version feststellen,
2. originales Installationspaket derselben Version heranziehen,
3. Dateien vergleichen,
4. abweichende Dateien sichern,
5. diese durch die offiziellen Originaldateien ersetzen,
6. Prüfsummen und PHP-Syntax kontrollieren.

Empfehlung bei ähnlichen Fehlern

Wenn unter Joomla 5.4 mit EasyBlog die Meldung

Call to undefined method Joomla\Database\Mysqli\MysqliDriver::nameQuote()

erscheint, würde ich nicht zuerst massenhaft PHP-Code ändern.

Stattdessen sollte geprüft werden, ob der tatsächliche Dateibestand wirklich vollständig der angezeigten EasyBlog-Version entspricht.

Eine Versionsnummer in der Joomla-Erweiterungsverwaltung garantiert offenbar nicht zwangsläufig, dass jede einzelne Datei tatsächlich aus diesem Versionsstand stammt.

Kurzfassung

Fehler

Call to undefined method Joomla\Database\Mysqli\MysqliDriver::nameQuote()

Umgebung

Joomla 5.4.8
EasyBlog 6.0.18
PHP 8.2

Ursache

EasyBlog meldete Version 6.0.18, mehrere installierte PHP-Dateien wichen jedoch vom offiziellen EasyBlog-6.0.18-Paket ab.

Lösung

Die abweichenden Dateien wurden identifiziert, gesichert und durch die entsprechenden Originaldateien aus dem offiziellen EasyBlog-6.0.18-Paket ersetzt.

Ergebnis

Die EasyBlog-Beiträge funktionieren wieder und der nameQuote()-Fehler ist verschwunden.

Hinweis: Die EasyBlog-Originaldateien stelle ich bewusst nicht zum Download bereit. EasyBlog ist kommerzielle Software. Für diese Reparatur wird ein legitimes Installationspaket der jeweils verwendeten Version benötigt.