Beiträge von flotte

Wenn Du im Backend im Menü "Erweiterungen" -> Erweiterungen -> verwalten schaust und nach der id (letzte Spalte) sortieren lässt, kannst Du leicht alle Drittanbiter-Erweiterungen erkennen. Alles ab id 10.000

Zitat von Elwood

Schick mir mal den Link per PN. Würde mir das dann mal anschauen, falls noch nicht alles gelöscht. Backup vorhanden?

Du wilst nicht ernsthaft eine gehackte Website aufrufen??

Zitat von Elwood

Ich schau noch mind. 1x die Woche ins BE und mache dann gleich noch ein Backup.

Dann noch das Backup auch auf den PC runterladen.

Ich empfehle auch nicht alle alten Backups zu löschen. Behalte immer so die letzten 3-4 Backups.

Dem kann ich mich nur anschließen. Ein wachsamer Webmaster prüft regelmäßig seine Website(s). Mindestens durch Einloggen ins Backup mit Prüfung auf Updates, Sichtung der Serverstatistiken (Unregelmäßigkeiten fallen dort schnell auf) und auch kurzer Check und Sichtung auf Dateiebene. Viele Hacks hinterlassen sofort erkennbare fragwürdige Dateien bereits auf Webroot-Ebene. All das sind ein paar Minuten Aufwand, wenn man es regelmäßig und geübt macht.

PS:

Backups würde ich sehr lange aufbewahren. Welchen Grund sollte es geben Backups zu löschen? Dann lieber mal 50 Eur in ne größere Festplatte investieren.

An dieser Stelle geht es öffentlich nicht mehr weiter.

Hört sich nach einem schwerwiegenden Problem an. Wenn ein Hack nicht "frisch" ist und früher schon übersehen wurde oder gar aus Backups wieder aktiviert wurde, ist eine Bereinigung nur sehr sehr schwer möglich. Eine ordentliche Untersuchung erfordert das aktuelle Logs und unveränderte Datumsstempel aller Dateien vorliegen und -ganz wichtig- ein zeitlich VOR dem Hack vorhandenes sauberes Backup und natürlich SSH-Zugriff und (oft vergessen) die FTP-Logs. Die Analyse soll in erster Linie den Zeitpunkt des Ersthacks feststellen und die Einbruchsstelle lokalisieren, damit man dann mit einem unverseuchten Backup alles bereinigen und die Lücken sofort fixen kann.

Eine Bereinigung eines verseuchten Joomla ohne diese Vorgehensweise bzw ohne Kenntnis des Ersthack-Zeitpunkts und die benutzte Sicherheitslücke betrachten wir als fast unmöglich. In jeder die zigtausenden Dateien kann irgndwo ein kleines Codeschnipsel liegen, welches als Backdoor dienst. Das zu finden ist wie mit der Nadel im Heuhaufen. Ich weiss das einige auch eine solche Bereinigung für möglich halten, aber davon halten wir gar nichts - es sei denn Zeit und Geld spielen keine Rolle. Dann lieber die Seite neu aufsetzen.

Wenn das also schon der zweite Vorefall ist, was wurde denn beim ersten gemacht? Wie wurde bereinigt?
Ich vermute es wurde nichts oder nicht vollständig bereinigt. Keine Seltenheit mangelt Fachwissens.

Du findest hie rein Liste kompetenter Partner, die bei Hacks helfen können:

https://www.fc-hosting.de/info/partner.php

Einige davon sind auch hier im Forum vertreten.

Was genau sagt denn der Provider? Er sollte doch auf jeden Fall Angaben gemacht haben, an denen er Phishing erkannt hat.

Deine Versionsangabe stammt offenbar aus der Systeminformation des Joomla. Warum dort so etwss angezeigt wird und nicht die konkrete MySQL-Version ist mir ein Rätzel. In phpMyAdmin findest Du die Versionsangabe. Es wird jedoch 10.3.11 sein.

Zu Deiner weiter unten genannten Fejlermeldung beim Import:

Womit genau wurde der Dump erzeugt? Was ist "mittels der GUI MySQL-Admin"?

Meinst Du damit phpmyAdmin?

Falls ja, achte darauf das das Anlegen der Datenbank nicht mit im Dump steht. Man muss zuerste links inder Navigationsleites die Datenbank auswählen, so das rechts im Hauptfenster die Tabellen zu sehen sind. Dann darüber den Export ausführen:

Exportieren: https://www.fc-hosting.de/support/faq_phpmyadmin-export.php

Importieren: https://www.fc-hosting.de/support/faq_phpmyadmin-import.php

Wenn in Deinem Dump "CREATE DATABASE" im obenen Bereich steht, dann wurde der Dump nicht richtig erzeugt.

Ich weiss nicht ob dies Dein Problem ist... schau einfach mal.

Wenn ich das Eingangsposting richtig verstande habe, geht es darum das ein Import nach MySQL nicht funktioniert, weil utf8mb4 genutzt wird. Das steht in MySQL bis 5.5 nicht zur Verfügung. Im Dump kann man utf8mb4 geben utf8 ersetzen. Einfach mit einem Editir editieren. Aber bitte kein Notepad! Die Codierung der Dump-Datei darf nicht verändert werden.

I.d.R. hat das herabssetzen von utf8mb4 auf utf8 keine besondere Auswirkung, es sei denn es wird tatsächlich der mit utf8mb4 erweiterte Zeichensatz zwangsweise benötigt. Das ist nur wirklich selten der Fall.

Möglicherweise funktioniert aber die Installation einer Komponente unter MySQL 5.5 nicht? Dann bleibt normalerweise nur die Möglichkeit die Datenbankversion zu wechseln. Welche Möglichkeiten es hier gibt, kann Dir nur Dein Hoster beantworten. Du brauchst dann MYSQl 5.6 oder höher oder MariaDB 10.1 oder höher.

Zunächst: Das sind Warnungen, keine Fehler. Warnungen sind oft bedeutungslos.

In diesem Fall würd eich mal das Error-Reportung auf Maximum stellen und schauen, was sonst noch gemeldet wird. Möglichlerweise hilft das weiter.

Vorsicht bei der Veröffentlichung der Website-URL (steht inder Fehlermeldung) mit Angabe der veralteten Versionsnummer. Im Ernstfall sind das nützliche Informationen für allerlei böser Buben...

Langfristig fährt man mit eigener Shopsoftware wie Shopware besser als mit einer Komponente für Joomla. Daher empfehle ich das auch und ja, 500 Artikel sind nicht wirklich wenig.

Einen "besten Shop" gibt es aber nicht. Zu unterschiedlich die Randbedingungen, das Backoffice, die Lager/Artikelverwaltung etc. pp.

Ggf. auch einfach mal einen anderen Browser benutzten, um die Änderungen als normaler User zu sehen. Also eingeloggt im Backend mit einem und Ansicht der Website mit einem anderen Browser. Vereinfacht oft die schnelle Prüfung von Änderungen ohne sich ständig ein/ausloggen zu müssen.

Hm... also dann hätte es ja auch ohne Symlink nicht funktionieren dürfen.

Oh zu nginx kann ich leider nicht allzu viel sagen...

Ich denke Du kannst das aber hierüber erreichen:

http {    disable_symlinks off;
}

Ich habe das gerade mal in einem Testaccount nachgestellt und funktioniert via Symlink problemlos. Der Symlink zeigte innerhalb des Hostingaccounts auf ein anderes Verzeichnis.

Ich kann mir eigentlich nur vorstellen, das serverseitig Symlinkverfolgung nicht erlaubt ist. Diese also bereits global oder in der vhhost-Konfiguration verboten wurden.

Leute bleibt geduldig!

Je besser das Release vorbereitet wird, desto weniger Bugs wird es geben - und ja es wird welche geben.

Auch Meisen sollten Rechte haben und sich nicht einfach so beobachten lassen dürfen

Immer dieselbe Laier... wenn man keine Ahnung hat, holt man sich Hilfe - aber zeitnah.
Das man Programme die sogar online erreichbar sind auch regelmäßig updaten muss, sollte man schon als grundlegendes Basiswissen eines Webmasters voraussetzen. Das nicht zu wissen, kann ich nicht mehr nachvollziehen. Auch sollten Update-Hinweise im Backend des Joomla im Laufe der Jahre mal irgendwann aufgefallen sein - oder nicht?

Es sollte klar, das der Betreiber einer Homepage für eventuelle Schäden haftbar gemacht werden kann. Abmahungen wegen Spam etc. sind da noch das kleinere Übel. Stell Dir vor über Deine Seite werden Phishingseiten betrieben - ist kein Problem, Seite ist ja sofort hackbar.

Hier im Forum gibt es genug Leute die Migrationen und Wartungsverträge anbieten. Auch auf unserer Website findet Du Partner die das machen (sind auch alle hier im Forum verteten). Wenn Du es nicht findest schreib mir ne PM.

Zitat von Dirk Lehmann

Wäre ein Umzug von Domains (beispielsweise zu fc-hosting.de) möglich, ohne den gesamten Content neu erstellen zu müssen? Falls ja, wie?

Dazu nur ganz kurz ohne zu viel Werbung zu machen: Natürlich geht das - wir machen das sogar kostenfrei

Im Ernst:
Was willst Du mit einem root-Server?

Buche eine passendes Hostingpaket oder einem managed Server und schlafe dann ruhiger.