Nach langer Zeit wollte ich mal wieder etwas mit einer Joomlaversion herumspielen.
Leider sind alle angebotenen gepackten Versionen inkompatibel mit aktuellen Packern unter Debian 10.
So müssen alle Dateien und Verzeichnisse einzeln auf den Server übertragen werden anstatt eine Datei die nur noch dort mit untar/unzip
entpackt wird.
Beiträge von joomladummy
-
-
Jedenfalls hat der angebliche Unsinn bestens funktioniert. Liegt wohl draan das es niemand von den Professionellen gesagt hat
Dann kann es natürlich nur Unsinn sein. Sorry aber ich sehr wohl in der Lage eine access.log zu analysieren auch wenn ich nicht jede der Dateien von Joomla auswendig kenne. Für denjenigen der so sein Joomla bereinigt ist es sicher was wertFirstlady: Die Standardinstallation 3.6.4 besteht aus 5641 Dateien in 1683 Verzeichnissen nicht zerstückelt? Und Mann oder Frau kennt die alle auswendig? Ist klar....
-
Ist man ja gewöhnt hier Jedenfalls ist bei mir nun alles sauber. Man kann nicht wissen welche Dateien orginal sind, dazu ist joomla viel zu aufgebläht und zerstückelt. Mit der access.log und zur Sicherheit noch mit der der transfer.log (pure-ftp) bekommt man es jedoch relativ schnell heraus. Wobei letztere sauber war. Die meiste Arbeit übernehmen die hacker selbst. Wenn man die accesslog mehrmals am Tag durchschaut und umbenennt wird eine neue erzeugt und diese bleibt dann recht übersichtlich. Man sucht einfach nach post und kann seine eigene IP schon mal ausklammern. Da hat man die entsprechenden Stellen in ein paar Minuten gefunden. Es ist meist der selbe Schadcode. Nebenbei läßt man schnell noch alle Dateien danach absuchen.
Die Angriffe kamen über Proxy aus Afrika, Asien und Südamerika.
Eine Möglichkeit ist die IPs via Banlist auszusperren. Joomla scheint wohl ein besonders beliebtes Ziel zu sein das es für Banlisten extra einen Autoupdater gibt.
https://www.ip-bannliste.de/autoupdater.html -
Lass mal https://sitecheck.sucuri.net/ drüberlaufen.
Wie schnell bei einem Hack professionelle Hilfe nötig ist finde ich schon erstaunlich
Wenn auf dem Server der securitymod läuft dürfte eine weitere Schwachstelle sicher sein. Kann natürlich durch Drittanbietersoft sein, nur ohne geht es fast nicht. Ich vermute auch ein Javascript. Leider wird immer mehr davon verwendet obwohl es nicht wirklich notwendig wäre.
Weiteren Hack gefunden. POST /components/com_joomgallery/views/downloadzip/search.php
Falls einer die Componente benutzt. -
firstlady: Was ich damit sagen will ist das selbst die 6.4 nicht sicher ist. So schnell wie die Hacks auftauchen kann man garnicht updaten. Ist man einmal zu langsam kann man alles frisch machen. Das heißt man verliert in der Regel alle Inhalte. Nicht Funktionen sollten an erster Stelle stehen sondern die Sicherheit.
Gibt es einer Übsicht aller Hacks der 3.xx Versionen die man abarbeiten kann oder ist es sinnvoll auf ein sichereres System zu wechseln?
Bei den alten Versionen kam ein Hack relativ selten vor und war meist schnell bereinigt. Ab der 3.. wird es echt übel. Meiner Meinung nach liegt es an der Unübersichtlichkeit des Systems. Nur noch Wenige Dauernutzer blicken da durch. Darum auch die Hinweise auf professionelle Hilfe.
Bei mir tauchen immer wieder Dateien auf die nicht dahin gehören wie eine javascript.php oder 404.javascript.php
Trotz 6.4 Version. Vermutlich noch ein Überbleibsel aus einer älteren Version. -
Ist immer noch aktuell.
-
Jetzt ist was schief gegangen.
Wenn ich ins backened will
Out of resources when opening file '/tmp/#sql_303_0.MAD' (Errcode: 24 "Too many open files") SQL=SHOW FULL COLUMNS FROM `#__users`Webworker: wurde vorher bereinigt.
Mit Sucuri und malwarededect. -
Du meinst sicher
PHP-Interface für den Webserver
cgi-fcgi -
Mysql Updates über phpmyadmin schmeißt auch nur Fehler.
#1146 - Table 'c1table.#__utf8_conversion' doesn't exist
Jetzt hats gefunkt. Nun habe ich 3.5.1
Datenbank aktuell.
Dafür bekomme ich auf der Startseite bei festen Links:
Warnung
JFolder::create: Der Pfad ist nicht in den „open_basedir“-Pfaden! -
Weil das update über das Backend nicht funktioniert. Darum manuell. Datenbank läßt sich wegen dem angezeigten Fehler nicht über Backend reparieren.
-
CurlY BracketS Danke. Wie ich sehe geht da nur von 3.4. auf 3.6.1
Mal sehen ob es mit überschreiben gehtGeht schon los:-)
Die Datenbankaktualisierungsversion (3.4.1) passt nicht zur CMS-Version (3.6.1).
COM_INSTALLER_MSG_DATABASE_UTF8_CONVERSION_UTF8MB4
Ein sql File fehlt oder habe ich es übersehen? -
Habe jetzt das upgrate genommen. https://downloads.joomla.org/cms/joomla3/3-5-0
This package is for performing updates from Joomla! 2.5 and previous 3.x releases to 3.5.0
Und jetzt einfach überschreiben durch hochladen? Die Readme gibt dazu leider auch nicht viel her. -
Darin sind aber nur dateien mit der endung .ini
Mit einfach überschreiben (Methode B) dürfte das nicht funktionieren.
Methode A Komponenten >Joomla > Aktualisierung ist nicht vorhanden.
Lediglich Nachinstallationshinweise. Damit geht es nicht. Schon probiert.Auf dem Server entpacken geht nicht. Das Problem hatte ich früher schon.
Befehl 'tar -xz --directory="." -f "admin_de-DE.zip"'
fehlgeschlagen mit Beendigungscode 2 und Fehlernachricht
gzip: stdin has more than one entry--rest ignored
tar: This does not look like a tar archive
tar: Skipping to next headerWenn ich den ganzen Download hochlade bekomme ich nur
Warnung
JFolder::create: Endlosschleife erkanntWarnung! - Die Datei kann nicht verschoben werden!
-
Ja danke, mach ich. Habe ja Backups. In letzter Zeit hatte ich Spamversand über Sicherheitslücken in Joomla. Muss jetzt noch die richtigen Versionen suchen. Finde leider nur Full Versionen. Geht es damit auch?
-
Methode A? Aus der Deutschen Anleitung. Im Prinzip von 3.4.1 direkt auf die aktuelle Version? Darüber steht aber auf 3.5.
Aktuell ist doch bereits 3.6?? -
Danke. Scheint sehr aufwändig zu werden.
-
Hallo,
ist ein manuelles update von 3.4.1 auf aktuelle Version möglich? Gibt es dazu eine Anleitung oder muss ich alle Schritte einzeln durchmachen? Also von 3.4 auf 3.5 und dann 3.6?