kitepascal

Hast du denn ein individuelles upload Verzeichnis angegeben? Du kannst die Formulardaten (inkl. Anhänge) automatisch löschen lassen: https://docs.joomla-6.visforms.vi-solutions.de/docs/subscription/form-data/general/data-delete-automation/ Wo die Dateien (temporär) liegen, sollte ja eigentlich egal sein, solange vor Aufrufen geschützt.

Du kannst den Link deaktivieren. Download-Link anzeigen auf nein. Du kannst/solltest ein eigenes (geschütztes) Verzeichnis anlegen/einstellen. /tmp/ ist scheinbar das Standardverzeichnis. In der Doku ist alles recht umfangreich beschrieben. https://docs.joomla-6.visforms.vi-solutions.de/docs/visforms/fields/secure-file-upload-field/

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-administrator-passwortschutz

Ich find diese Erweiterung sehr praktisch: https://extensions.joomla.org/extension/aifavicon/ 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 https://www.joomlawebcentral.com/joomla-extensions/aifavicon/documentation 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. /administrator Verzeichnis mit einem Verzeichnisschutz versehen. Spamschutz für alle Formulare (z. B. OSpam-a-not mit Honeypot + Zeitsperre). Zusatz-Absicherung per erweiterter Haupt-.htaccess mit Blocking verdächtiger/unerwünschter Requests/User-Agents statt…

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:…

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. https://extensions.joomla.org/extension/ospam-a-not/ 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…

Ich hatte heute früh um 03:27 gemailt. Welchen Timestamp hat denn die Datei https://petrihaus-frankfurt.de/plugins/system/blpayload/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. […] Sonst einfach ein Backup um Mitte Februar nehmen - da gab es nach aktuellem…