Beiträge von flotte

Echt jetzt? Jetzt postet Du auch noch Schadcode-Sourcen?
Hallo Moderator - bitte sofort löschen.

Im Ernst Leute:
Wer keinen Hack eindeutig analysieren kann und auch keinen Profi beauftragen möchte, sollte seine Seite unbedingt neu machen und alles löschen und überall neue Passwörter verwenden.

Und Voraussetzung für eine Analyse sind die originalen Webserverlogs und unveränderte Files in Webspace. Wer blind einfach schon mal ein Backup drübergebügel hat, kann sich die Analyse auch schenken.

Leider erschweren auch DSGVO-Vorgaben wie das Entfernen von IPs nach wenigen Tagen, die eindeutige Analyse ungemein. Ältere Hacks kann man daher nur ganz selten wirklich analysieren. Das nur nebenbei.

Quasi alle "Selbstbereinigsversuche" die wir so im Lauf der Jahre beobachten konnten sind gescheitert. Auch die Angaben die großen Massenhoster, die sich oft auf einige wenige Dateien beziehen, die deren Schadcodescanner zufälligerweise als kompromittiert erkennen, sind kontraproduktiv. Das suggerriert nur, das man die Files ersetzen muss und damit Problem erledigt ist. Typische Schadcodescanner erkennen zudem nur ein Bruchteil möglicher Hacks. Das liegt einfach daran, dass ein simpler Einzeiler, versteckt in irgend einer PHP-Datei schon eine Backdoor realisieren kann. Der Code ist unauffällig und könnte in ähnlicher Form ganz legal in php-Datein auftauchen.

Zitat von frieder

Ich habe ein Backup aufgespielt. Trotzdem teilt Strato mir mit, dass das Problem nach wie vor in der index.php besteht. Mangels Programmierkenntnisse finde ich das Problem nicht.

Kann mir jemand helfen und die index.php anschauen? Oder andere Frage: Gibt es eine Standard-index.php, die man aufspielen kann und mit der die Homepage trotzdem läuft.

Ohne Analyse des Hacks ist die Vorgehensweise fahrlässig. Ich kenne keinen einzigen Hack (und habe schon hunderte untersucht), wo nur eine Datei kompromittiert ist.
Ganz kurz: Erst-Hack druch Analyse ermittelt und dann ien Backup von VOR dem Hack aufspielen. Danach alle Sicherheitslücken schießen

Komplexer: Meine Website wurde gehackt - was tun?

Datei löschen oder umbenennen

Bin ich mir gerade selbst nicht sicher, wird aber sowieso in Kürze angepasst wegen J5.

Ich muss nun mal ein dickes Lob aussprechen. Es sind nun fast 4 Wochen seit dem Launch von J5 vergangen und bislang gab es kein schnelles Bugfixing irgendwelcher krassen Lücken. Das war bei diversen Versionssprüngen in der Vergangenheit anderes. Weiter so!

Kann es nicht ganz nachvollziehen. Bitte mal Link senden.

hab es mal getestet. Ist tatsächlich so! Wenn man das Formular beim Kontakt selbst deaktiviert ist es dennoch sichtbar.

Ebenso ist es so, das z.B. wenn man Kopie an Absender aktiviert, obwohl es global deaktiviert ist, dann erscheint das nicht.

Offenbar gelten nur die globalen Einstellungen und die individuellen überschreiben diese nicht.

@cs369
Schalte das Formular in den globalen Einstellungen aus (unter Kontakte -> Optionen)

Statt irgendwelche Scripte die Anmeldungen überwachen, einfach einen .htaccesss-Passwortschutz auf das administrator-Verzeichnis legen (sinnvolles Passwort natürlich). Das löst keine PHP-Scripte und Datenbankabfragen aus und nimmt extrem viel Last, wenn versucht wird massenhaft auf das Login zuzugreifen.

Zusätzliche Scripte sind zusätzliche potentielle Sicherheitslücken und erzeugen Last, anstatt diese zu vermeiden.

Ja das Astroid-Framework ist wirklich empfehenswert und übersichtlich.

Habe damit auch vor einiger Zeit die Seite meiner Frau gemacht. Blöd nur, das mir seit geraumer zeit auch ein Update des "UIkit 3 Framework Plugin" von 2.5.28 auf 2.5.29 gemeldet wird, aber das Update scheitert:
Paketdownload fehlgeschlagen. Manuell von https://www.joomlaplates.de/zip/ herunterladen und installieren.

Ich hatte eine Downloadlizenz beim hersteller der Templates, aber die läuft dann ja (ich glaube) nach 12 Monaten aus - und damit gibt dann auch keine Möglichkeit mehr dieses Update downloaden - jedenfalls hab ich nix gefunden.

Zitat

Diese Erweiterung ( Template & uikit) kann nicht direkt heruntergeladen werden

Dies ist ein kommerzielles Produkt und Sie können es nur über Ihr Joomlaplates-Konto herunterladen.

Tja, zu blöd. Dann lass ich es halt

Danke für die Info. Jetzt kann ich das gegenüber den Endkunden auch besser kommunizieren. Die ungeplanten vorgezogenen Updates bleiben zwar, aber nun kenne ich den technischen Hintergrund.

Falls es so sein sollte, das die Entwickler meinen, die Mindestversion einfach ohne technische Notwendigkeit heraufzusetzen, weil mariaDB im EOL ist, muss ich wirklich scharf protestieren! Wenn man die mariaDB des (beispielsweise) Debian 10 benutzt (10.3.39) ist es mitnichten so, das es keine Updates mehr gibt. Debian selbst versorgt die Version mit weiteren rückportieren Updates noch bis Mitte 2024. Im übrigen gilt das auch für einige andere Software, die direkt vom Distributor angeboten werden.

Natürlich wird man als Hoster darauf bedacht sein sichere Software einzusetzen. Genau das ist im Fall von Debian 10 noch bis Mitte 2024 der Fall. Wir planten beispielsweise entsprechende Updates der letzten noch genutzten Debian 10 Server Anfang 2024 und lägen damit Monate vor dem entgültigen EOL (bezüglich mariaDB).

Wenn man als Hoster mit tausenden Joomla-Webs plötzlich ohne technische Notwendigkeit (wenn das so sein sollte!) eine neue Mindestversion serviert bekommt, dann ist das salopp gesagt eine Sauerei. Hier führt das beispielsweise zu einer ungeplanten Änderung der gesamten Updateplanung - mitten in einem gerade laufenden Updateverfahren der Serververwaltungssoftware.

Was soll man dann den Kunden sagen, die sich beschweren? Am besten auf Joomla verzichten und auf WP umschwenken - so wie es eh schon die allermeisten Kunden machen??? Die Kunden sind eh schon extremst genervt von J! - das merken wir fast jeden Tag.

Ich persönlich möchte Joomla gerne weiter empfehlen, aber wenn einem solche Klötze zwischen die Beine geworfen werden, dann reichts mir langsam auch.

Also: Was genau ist der technische Hintergrund dieser neuen Mindestvorgabe - BITTE!

Also die Entwickler sollten die Frage doch einfach beantworten können. Alles andere ist doch Rätzelraten.

Es muss eine Funktion geben, die zu mariaDB 10.4 zwingt, ansonsten wäre die Mindestangabe nicht erklärbar, zumal dies wie in einem anderen Thread schon erläutert, teilweise massive Probleme auslöst.

Würdemich freuen, wenn die Entwickler hier eine konkrete Antwort geben würden.

Welche Funktion von mariaDB 10.4 wird zwangsweise benötigt, die 10.3.39 noch nicht hatte?

Meine erste Reakton wenn neue Major-Versionsserien starten: Mist, nun wird es massenhaft Supportanfragen überforderter User geben.

Alle Empfehlungen SOFORT auf neue Major Versionen schon bei der ersten Ausgabe x.0.0 zu gehen (und auch noch die 5 weiteren) sind abseits jeglicher Realität für einen Otto-Normal-Webmaster. Ich weiss wovon ich rede, denn hier bei uns laufen dann diese ganzen Fragen tagtäglich auf und auch Foren füllen sich... Man muss doch nur mal zurückblicken auf die Zeiten der führen Launches neuer Major-Releases von Joomla.

Anders verhält es sich wenn erfahrene Webdesigner/Programmierer involviert sind, aber die vielen typischen Vereins- und Präsentationsseiten kleiner Firmen haben in der Regel nur engagierte Mitarbeiter und keine echten Webdesigner.

Hi!

Ich habe mich ja schon mal in einem anderen Thread über die SInnhaftigkeit der neuen Datenbank-Mindestvorgabe ausgelassen. Darauf will ich gar nicht weiter eingehen.

Ich habe nun mal spaßeshalber ein Joomla 5.0.0 auf einen Server mit Debian 10 kopiert, der noch die Datenbankversion 10.39 des Debian benutzt. Also nicht installiert, sondern eine auf einem kompatiblen Server installierte Version einfach umkopiert - Dateien kopiert, Dump importiert und die configuration.php angepasst.

Alles ohne Probleme, keine Fehler. Joomla läuft augenscheinlich einwandfrei. Ich habe aber nicht tiefgreifend getestet.

Meine Frage daher:

Warum genau wird bei mariaDB die Version 10.4 als Mindestvorgabe gesetzt?

Ist es vielleicht die nun mögliche DB-Verschlüsselung, die per Default ja aus ist und meistens wenig Sinn mach? Oder sind es andere Funktionen?

Wenn Du einzelne IPs prüfen willst, sind dies gute Anlaufstellen:
https://www.abuseipdb.com/

Cisco Talos Intelligence Group - Comprehensive Threat Intelligence

Ob es Sinn macht einzelne IPs oder Netze zu sperren ist umstritten. Temporär kann man das sicher machen, dauerhaft ist es eher sinnfrei. Dafür gibt es zu viele Bad-IPs und die Nutzung der IPs wechselt zudem stetig.

Was jedoch Sinn macht, ist den Zugriff anhand der Agent-Kennung zu sperren. Damit sperrt man i.d.R. diverse Bad-Bots aus. Crawler die zu massiv zugreifen etc.pp. Du findest im Netz massenhaft Bad-Bot-Listen. Das sorgt in erste Linie dafür das die last auf den Server minimiert wird.

Ebenso ist es sinnvoll bestimmte tyische Angriffsszenarien, die man anhand der URL/URI erkennen kann. Auch hier gibt es massenweise Infos im Netz.

Das sinnvollste ist natürlich immer sichere und aktuelle Scripte einzusetzen, die von sich aus die meisten Angriffsversuche ins Leere laufen lassen.

Da hast Du allerdings Recht. So wird es sein.

Zitat von JFS

Aktuell bietet Plesk Unterstützung nur bis zur Version 10.11. von MariaDB

....

Das ist ein kleiner Stolperstein auf meinem Server.

Die Versionsserie 10.11.x ist die aktuelle Long Term Version von mariaDB, welche 5 Jahres supported wird. Die vorherige LT Version war übrigens 10.6.x

Wenn Du also bereits 10.11.x nutzen kannst ist doch alles in Butter! Ich kenne kein Script, welches eine höhere Anforderung hat, zumal die wenigen größeren Versionen von mariaDB nur Kurzzeitversionen sind. Davon sollte man die Finger lassen.

Das Joomla leider 10.4 als Minimum fordert ist leider ärgerlich und ich würde gerne den konkreten Grund dafür erfahren. Es muss ein KO-Feature sein,.., denn aufgrund dieser Forderung wird Joomla erneut viele User vergraulen. Hintergrund ist, das Debian 10, welches von sehr vielen Hostern als Bestriebssystem genutzt wird noch bis Ende Juni 24 supported wird und dort mariaDB 10.3. die nativ unterstützte Version ist. Debian 11 hat auch erst mariaDB 10.5. in der eigenen Paketverwaltung.

Wir haben auch noch diverse Server mit Debian 10 und mariaDB 10.3 und damit trifft uns diese Problematik leider auch. Ursprüngliche waren die Updates im Laufe 2024 geplant. Wir haben daher beschossen, die Paketverwaltung von Debian für mariaDB zu verlassen und sämtliche Server einheitlich mit mariaDB 10.11 zu versorgen, auch diejenigen Server die bereits 10.5 nutzen. Dann sind wir hoffenlich für lange Zeit raus aus diesen teilweise nicht nachvollziehbaren Vorgaben einiger Scripte.

Das ist leider nicht immer so simpel wie es sich anhört, denn nicht ohne Grund sollte man die Pakete der eigenen Distribution eher vertrauen, als den Entwicklungen außerhalb davon.

Wo ich gerade am meckern bin:

Warum (zum Teufel) muss man unbedingt alle User mit Joomla 4 per Mail laufend darüber informieren, das man auf J 5.0.0 updaten sollte. Das System schickt immer wieder solche Mails. Man weiss doch ganz genau, das bei Einführung einer ganz neuen Versionsserie von Joomla die Probleme gross sind (siehe die letzten dieser Sprünge - würde mich wundern wenn es jetzt anders wäre - erst recht aufgrund der neun MySQL-Anforderungen).

Schlauer wäre es gewesen, noch ein paar Monate mit solchen Aufforderungen zu warten, bis 5.0.0 wirklich stabil ist und die Drittanbieter die Kompatibilität sicherstellen. Nun wird es massenhaft viel zu frühe Migrationsversuche geben und ich weiss jetzt schon, was für Supportanfragen es täglich geben wird. J 4 wird doch noch Ewigkeiten supportet - also es gibt gar keinen Grund vorschnell zu migrieren.

Zitat von firstlady

ja, leider. Supporter werden nicht so schnell arbeitslos

in erster Linie liegt das an den Updateproblemen von Joomla. Die Schuldzuweisungen gehen leider viel zu oft in Richtung User.

Ich würde ja nix sagen, wenn von offizieller Seite (joomla.de) das CMS nicht so angepriesen würde. Das Installieren ist in der Tat kein Problem, aber dann geht man auch davon aus das Updates/Migrationen simpel sind - und das ist oft mit nichten der Fall.

Zitat

Joomla! ist so aufgebaut, dass man es auch als unerfahrener Anwender auf einfache Weise installieren und einrichten kann.