Beiträge von kitepascal

Hast du denn ein individuelles upload Verzeichnis angegeben?

Du kannst die Formulardaten (inkl. Anhänge) automatisch löschen lassen:
Daten automatisch löschen

Wo die Dateien (temporär) liegen, sollte ja eigentlich egal sein, solange vor Aufrufen geschützt.

Du kannst

1. den Link deaktivieren. Download-Link anzeigen auf nein.
2. Du kannst/solltest ein eigenes (geschütztes) Verzeichnis anlegen/einstellen.
   /tmp/ ist scheinbar das Standardverzeichnis.

In der Doku ist alles recht umfangreich beschrieben.
File-Uploads schützen

Du kannst, bisherige /administrator/.htaccess und .htpasswd gelöscht, die angehängte ZIP Datei als Erweiterung installieren für einfache/geführte Einrichtung des Passwortschutzes.

Löscht sich anschließend selbst wieder.

Siehe auch https://website-bereinigung.de/blog/joomla-ad…-passwortschutz

Ich find diese Erweiterung sehr praktisch:

aiFavicon, by Web Central - Joomla Extension Directory

A system plugin to add the favicon to a site as generated by realfavicongenerator.net.

extensions.joomla.org

• Plugin installieren, aktivieren

• https://realfavicongenerator.net/

  Favicon package als ZIP downloaden mit allen Varianten

• Verzeichnis "favicon" im Child Template erstellen und die Dateien aus dem ZIP darin platzieren
• Fertig

Siehe auch

aiFavicon Documentation - Joomla Web Central - Support - Extensions - Components - Plugins

Gruß

Pascal

Was ist denn die Intention dahinter? Nur Sicherheit?

Es gibt genügend Angriffe auch aus Deutschland und aller Herren Länder - eine kollektive Sperrung ist nicht sinnvoll.

Ich würde eher die Absicherungsmaßnahmen generell optimieren.

1. /administrator Verzeichnis mit einem Verzeichnisschutz versehen.
2. Spamschutz für alle Formulare (z. B. OSpam-a-not mit Honeypot + Zeitsperre).
3. Zusatz-Absicherung per erweiterter Haupt-.htaccess mit Blocking verdächtiger/unerwünschter Requests/User-Agents statt Geoblocking (wie sie z. B. der Akeeba Admin Tools Pro .htaccess Maker konfigurierbar erstellt)
4. Webhoster mit vernünftiger serverseitiger Firewall - ordentlichem Fail2Ban & ModSecurity Setup wählen.
5. RSFirewall oder Admin Tools Pro als WAF/Monitoring Lösung.

Ja, das sieht eindeutig nach einer kompromittierten Installation mit .shtml/SSI-Droppern aus.
Der enthaltene #exec-Befehl dekodiert Base64-Code und schreibt daraus eine PHP-Datei - typisch für das Nachladen einer Webshell/Backdoor.

Ich würde daher nicht nur die .shtml-Dateien löschen, sondern auch nach den erzeugten .php-Dateien suchen, alle .htaccess-Dateien prüfen - bestenfalls ein Backup wiederherstellen bzw. Joomla samt Erweiterungen/Templates gegen saubere Originaldateien ersetzen.

Kurz: als vollständigen Hack behandeln.

Läuft da Astroid, Tassos oder keins von beiden?

Kann man machen, jedoch nur als Ergänzung - nicht als Ersatz.

Brute Force findet häufig über sehr viele wechselnde IPs statt.

Durch Honeypot + Zeitsperre (OSpam-a-not) kommen die meisten Bot-typischen Login Versuche gar nicht erst durch.

Welche öffentliche Login Formulare gibt es denn auf der Seite, inkl. Joomla Standard Frontend Login URL? Die funktioniert immer, auch wenn es keinen Menüpunkt dazu gibt.

OSpam-a-not, by Joomlashack - Joomla Extension Directory

OSpam-a-not is the easiest way to protect your Joomla site from spam bots filling out your forms. OSpam-a-not uses a clever and unobtrusive technique to…

extensions.joomla.org

würde ich empfehlen. In den Plugin Einstellungen die Zeitsperre auf z. B. 5s und das Logging aktivieren - dann weißt du, über welches Login Formular es läuft.

Gruß

Pascal

Ja, dürfte klappen. Die Datenbank solltest du dann auch noch etwas gründlicher checken. User Tabelle.. Verwaiste Extension Einträge (von mglw. eingeschleusten Plugins)..

Wo klappt das nicht - im Backend, um die Menüpunkte zu bearbeiten?

Im Frontend bei mir keine Probleme..

Meldet die Browser Konsole (Rechtsklick - untersuchen, Console Tab) etwas beim Klick auf den Link?

Welche Änderungen? Am Inhalt?

Welchen caching Mechanismus hast du aktiv?

Ist das System - Page Cache plugin aktiv - darin das Browser Caching?

Werden die Änderungen in einem privaten/inkognito Browser tab direkt sichtbar?

Das Plugin creationDate ist nicht das Einschleusungsdate - da ist eher der Datei-Zeitstempel relevant. Nach dem 3.3. wurde es meist eingeflößt.

Wenn es gepackte (Akeeba?) Backups sind (JPA, ZIP) kannst du die bedenkenlos nehmen, wenn ansonsten zu viele neuere Inhalte verloren gehen würden.

Bei einer Kompromittierung kann sich Schadcode bei Strato grundsätzlich auch in benachbarte Verzeichnisse / auf andere Domains ausbreiten, weil es keine isolierten Accounts/User je Domain mit eigener isolierter Berechtigung gibt.

Wenn die andere Domain keinerlei Symptome zeigt, kannst du Glück gehabt haben.

Vor dem Backup Restore am besten auch das Datenbank Passwort ändern.
Die Seite(n) dann in geleertem Verzeichnis in vorher geleerter Datenbank wiederherstellen.

Ich hatte heute früh um 03:27 gemailt.

Welchen Timestamp hat denn die Datei
https://petrihaus-frankfurt.de/plugins/system…d/blpayload.xml wenn du mal per FTP Verbindung schaust?

Im /www_logs Verzeichnis auf dem Webspace sollten sich bei Evanzo auch Access Logs befinden, die du durch die KI schieben kannst, um den Angriffszeitpunkt zu bestimmen - vorausgesetzt die reichen ausreichend lange zurück.

Zitat von tommynatar

und dann schauen, ob du ein sauberes Backup hast

Sonst einfach ein Backup um Mitte Februar nehmen - da gab es nach aktuellem Infostand noch keine Astroid Angriffe.

Es liegen wahrscheinlich .htaccess Dateien in diversen Unterverzeichnissen inkl. /administrator, die durch die ausgenutzt Sicherheitslücke im Astroid Framework zustandekommen.

Hast du ein Backup von Anfang März? Am einfachsten und sichersten wäre es, wenn du das wiederherstellst.

Wann der Angriff genau stattgefunden hat, kannst du den Access Logs entnehmen.

Die gz log Datei kannst du am einfachsten von chatgpt o. ä. analysieren lassen.

Ich habe am Wochenende bis heute früh rund 800 Seiteninhaber im DACH-Raum informiert, auf deren Websites entweder blpayload oder jcachepro installiert ist.
Zusätzlich sind rund 2.500 Warnmails an Kandidaten mit einer Astroid-Version unter 3.3.11 ohne Backend-Schutz rausgegangen.

Ich denke, viele weniger aktive Betroffene werden erst spät bemerken, dass etwas nicht stimmt - und dann schon außerhalb des üblichen Backup-Zeitraums ihres Hosters liegen.

Taucht Wichtel denn noch in der Search Console irgendwo im Quelltext auf, wenn du diese Seite aus dem Index abrufst (kein Live Test)?

Dass Titel und Description sich nicht gleichzeitig normalisieren, hab ich auch schon beobachtet.

Bis sich das komplett erholt hat, vergeht die ein oder andere Woche.

Nach zwei Tagen ist das schon wieder ein solider Stand - gut reagiert 👍🏼

Checkbox aus dem Frontend entfernen hätte wohl auch gereicht.

Denn genau das ist ja die Einladung zum Spammen - nicht das für viele Anwendungsfälle nützliche Auto-Reply Feature an sich.

Ginge sonst auch umständlicher per JavaScript über ein kleines geclaudetes System Plugin.

Ein Override ist aber auf jeden Fall vorzuziehen, wenn es klappt.

Stimmt denn der http header beim Direktaufruf?

Dass die sitemaps sporadisch mal nicht abgerufen werden können, habe ich auch sehr häufig, systemübergreifend.