Beiträge von flotte

Offensichtlich betreibst Du einen root-Server. Da solltest Du in der Lage sein die PHP-Einstellungen zu prüfen.

Das mod-PHP die denkbar schlechteste Variante für den Betrieb einen CMS wie Joomla ist, ist Dir klar? (-->wwwrun Problem)

Frage: Ist PHP 7.2 überhaupt auf dem Server installiert?

Nur das Aktivieren einen Apache-Moduls ist ja noch keine Installation.

Das Error-Level kannst Du in der configuration.php auf "Maximum" stellen, falls es keinen Zugriff mehr auf das Backend gibt.

Hier geht es ja um den Session-Speicher-Pfad und nicht um das joomlaeigene tmp-Verzeichnis. Beides hat nichts miteinander zu tun.

In Deiner php.ini steht dies:

session.save_path = "/tmp"

Dort kann PHP offenbar nicht lesen. Das ist ein Hoster/Serverproblem. Möglicherweise hängt es mit einer changeroot-Umgebung des Accounts zusammen. Kann man aus der Ferner nicht abschließend beurteilen. Dein Hoster ist hier Dein Ansprechpartner, der das Problem lösen sollte oder Dir miteilen können muss, was in der php.ini einzustellen ist.

Testweise würde ich dort mal den absoluten Pfad auf Dein tmp-Verzeichnis Deines Joomla einstellen. Wie gesagt, aber nur temporär, denn das kann nicht die entgültige Lösung sein. Schau auch mal in die Ordnerstruktur Deines Account. Vielleicht gibt es dort ein eigenes tmp-Verzeichnis?

Ich vermute mal das beim letzten Hack keine echte Analyse gemacht wurde und auch beim jetzigen Hack nicht wirklich geprüft wurde, wie der Angreifer reingekommen ist. Du vermutest FTP - auf Basis welcher Fakten? Nur die Logs können die Fragen tatsächlich beantworten. Dazu gehören Web- und FTP-Logs.

Einmal gehackte Seiten werden immer wieder "besucht" . Deshalb werden ja Backdoors eingerichtet, damit man wiederkommen kann. Mit hoher Wahrscheinlichkeit hängen also beide Hacks zusammen. Nach so langer Zeit wirst Du faktisch keine echte durchfreifende Analyse mehr machen können. Vermutlich gibt es gar keine Logs mehr und die Dateien auf dem Server haben längst neue Zeitstempel, sind verändert etc.pp.

Falls es tatsächlich ein FTP-Hack war, kann es sein das Du Trojaner auf dem PC hast oder - falls noch andere so zugreifen dürfen, das dort Trojaner sitzen und "mithören". Die Untersuchung aller beteiligter PC gehört also auch dazu.

Wie in aktueller Situation vorzugehen ist, kann Dir hier niemand seriös sagen, ohne Kenntnis des Servers (ggf. liegen dort ja nich andere Webs und Backdoors außerhalb Deines Joomla?

Das sicherste wird vermutlich(!) in der Tat sein, ALLES zu löschen, den gesamten Account auf dem Server, alle Dateien, alle Zugänge neu setzen, PC prüfen und dann das Joomla neu installieren. Übernahme von Inhalten durch Paste&Copy oder Tools wie J2XML - sofern möglich.

Wahrscheinlich war gar kein Zertifikat installiert...

Laßt die Finger von so einer verseuchten Seite. Die autom. "Bereinigung" ist Schwachfug - geradezu verantwortungslos.

Hm... Datei und Ordnerrechte werden korrekt gesetzt. Hab es früher mal getestet und eben noch mal wiederholt durch willkürlich gesetzte falsche Rechte bei einem Test-Joomla. Kann da keinen Fehler finden. Richtig und besser wäre aber, das diese Funktion immer einen Zwischendialog anzeigen sollten, mit Erläuterungen und Abbruchmöglichkeit. Bei den meisten Funktionen ist das der Fall, aber eben nicht bei allen.

Wie auch immer, mir geht es ja hier nicht um die Bewertung dieses Tools. Es wurde nur als eines der Mittel genannt womit man leicht einen .htaccess-Backend realisieren kann.

Zitat von Pest

Die Admin Tools sind eine Geißel der Joomla Welt! Deren Einstellungsmöglichkeiten sind vergleichbar mit einem Amateur, dem man in einen fertigen OP schickt, Patient liegt da schon, und ihm dann den Skalpell in die Hand drückt und sagt er soll mal machen. Die Ergebnisse sind etwas die gleichen. Gerade in Bezug auf die htaccess möchte ich nicht wissen, wie viele Joomla "Leichen" da schon unbedarfte Klicks ausgelöst haben.

Ich kann diesen Aussagen leider nicht folgen...
Die kostenfreien Admin-Tools sind ziemlich harmlos und bieten aber einige Funktionen, die tatsächlich nützlich sein können. Alle Funktionen lassen sich allerdings auch mit den üblichen Bordmitteln eines Hostings realisieren, das ist wahr, aber längst nicht jeder User kann das.

Hier in diesem Thread geht es auch nur um einen simplem .htaccess-Passwortschutz des Backends, die die Admin-Tools oder andere Tools auf relativ ähnliche Weise realiseren. Das Ergebnis ist dasselbe. Eine "Joomla Geißel" kann ich nicht erkennen und ich weiss auch nicht was Du mit "unbedarften Klicks" meinst.

Ich vermute es geht Dir um die "Admin-Tools Professional" (kostenpflichtig), mit den deutlich erweiterten Funktionen. Als wo man beispielsweise eine ziemlich aufgeblähte .htaccess-Datei mit diversen "Schutzfunktionen" generieren kann. Aktuell hat ja mal wieder ein User in einem Parallelthread damit ein Problem. Wenn Du also diese Version der Admin-Tool meinst, stimme ich Dir zu.

Setze einen .htaccess-Passwortschutz für das Verzeichnis "administrator".

Das geht normalerweise mit Mitteln, die Dir Dein Hoster zur Verfogung stellt. So geht das bei uns. Ähnliches solltest Du auch bei Deinem Hoster finden. Falls nicht gibt es auch andere Tools, womit man das erreichen kann. Z.B. die Admin-Tool als Joomla-Komponente.

Ich kann mich Re:Later nur anschließen. Solche aufgeblähten .htaccess-Dateien suggerieren Pseudo-Sicherheit und haben fast immer früher oder später Quereffekte mit denen man nicht rechnet. Gut konfigurierte Webserver erfüllen bereits vieles was versucht wird in der .htaccess nachzukonfigurieren. Zum Beispiel die ganzen mod_gzip-Anweisungen. Im übrigen wird meist mod_deflate eingesetzt und nicht mehr mod_gzip. Auch sind oft Application-Firewalls im Einsatz, die solche und ähnliche Dinge kontrollieren. Sofern Du einen auf Joomla spezialisierten Hoster gewählt hast, sind ggf. sogar speziell auf Joomla ausgelegte Sicherheitsregeln vorhanden.

Es gilt auch zu beachten das jeder einzelne Seitenaufruf alle Zeilen der .htaccess abarbeitet. Dies ist bei überflüssigen Regeln dann kontraproduktiv, erhöht die Serverlast und die mindert damit die Performance.

Sinnvolle Maßnahmen zur Joomla-Absicherung kannst Du unten in der Signatur finden.

Zitat von breaker

Meine Vermutung: Der Webspace liegt zusammen mit 50 anderen Kunden auf einem ausgelasteten Server und Joomla kann nicht in das /administrator/cache schreiben

Theoretisch möglich, aber ich denke nicht.
Dann wäre auch die Seite im Frontend lahm, auch wenn dort kein Cache aktiv wäre.

Selber Effekt mit vielen anderen nicht php-Files:
https://www.buergerstiftung-re…/en-GB/en-GB.com_ajax.ini

Entweder via .htaccess blockiert oder eine serverseitige Einstellung beim Hoster oder ein Rechteproblem. Letzeren schließe ich eher aus.
Wenn tatsächlich die .htaccess schon am deaktiviert wurde und dabei nicht vergessen wurde auch übergeordnete .htaccess-Dateien zu berücksichtigen, dann bleibt nur eine serverseitige Restriktion. Beispielsweise das nur bestimmte Dateitypen aufgerufen werden dürfen. Vielleicht hast Du auch irgendein Regel-Set einer Application-Firewall aktiviert? Ich weiss nicht was der Hoster als Funktionen anbietet.

Zeig doch mal Deine .htaccess.

Mach auch mal einen Screenshot des Inhalts des Joomla-Ordnern, wo auch die EIgner/Rechte der Dateien zu sehen sind.

Wenn die lange Ladezeit nur im Backend vorhanden ist, wird es mit hoher Wahrscheinlichkeit mit Erweiterungen des Backends zu tun haben.

Du kannst daher testweise mal unter "Erweiterungen-Verwalten" die Erweiterungen nach Spalte "Bereich" sortieren lassen und dort alles was "Aministrator" zugeordnet ist und wo die ID größer/gleich 10.000 ist genauer ansehen. Einzelne Erweiterungen kannst Du testweise einfach mal deaktivieren und die Auswirkungen prüfen.

Zitat von j!-n

Hast du Zugriff auf die error.log Datei? Erst gestern hatte ich bei einem Kunden ein zu behebendes weisses Backend, bei dem es interessanter Weise das Quick Icon Plugin für die PHP Versionsprüfung war, welches einen (von mir geliebten) 500er Error warf. Allerdings war das eine 3.7.0, nach umbenennen per FTP des Plugin Verzeichnis war das Backend wieder da.

Das Phänomen ist mir auch bekannt. Sehr merkwürdig... Hatte neulich auch einen Kunden mit dem Problem.

Zitat von Stefanseiner

nunja, ich als Privatperson rechne erstens nicht in Stundenlohn bei meiner Privatseite,....

Hier ging es aber nicht um eine private Seite, sondern um eine neue Selbstständigkeit.

Das Thema "Domainame" erachte ich sogar noch für wichtiger. Den sollte man sich so schnell wie möglich sichern. Das macht man bei seinem Hoster seiner Wahl (Domain ist meist eh inklusive und damit kostenfrei). Entwickelt wird dann sinnvollerweise in der späteren technischen Umgebung. Domainname, SSL, Pfade, PHP-Konfig etc.pp. - alles bleibt gleich und man hat keine Probleme, muss nicht umziehen, muss kein neue SSL einrichten, Pfade oder sonst was anpassen. Solange man entwickelt legt man einen Passwortschutz drüber...

Auch EMailadressen sollte Selbstständige immer mit der eigenen Domain bilden und dazu braucht man nun mal ein Hosting.

Wer sich tatsächlich keinen Webspace für 3,90 Eur im Monat für zwei Monate leisten kann, der sollte sich auch nicht selbstständig machen

Ein Update:
https://www.datenschutzbeauftr…-suche-nach-einem-plan-b/

Nein seit Ewigkeiten kein Kontakt. Die Kontaktdaten stimmen schon lange nicht mehr.

Wer die Seite nun abgeschaltet hat, der Betreiber oder Hoster ist letztlich auch egal. Bei der alten Software kann es auch leicht einen Hack gegeben haben und der Hoster hat reagiert... wer weiss.

Wenn Stefan aber noch in irgend einer Form aktiv wäre, hätte er sicher eine Meldung auf die Seite gestellt. Vielleicht ist er ja auch erkrankt oder kann aus anderen Gründen nicht reagieren....

HTTP/2.0 ist von der Apacheversion abhängig. Das kann man unter Umständen also nicht sofort in jeder Serverkonfiguration einschalten. Dein Hoster ist aber der Ansprechpartner dafür.

Der Performanceboost wird allerdings, genauso wie bei jeder neuen PHP-Version, im Internet oft maßlos übertrieben dargestellt. Zum einen hängt es sehr stark von der Art der Seite ab und zum anderen von der Last auf dem Server. Bei performanten Serverm, die dann auch seitens des Hosters nicht überladen werden mit massenhaft Kunden, wird man kaum etwas spüren.

Ein Error 408 ist ein Timeout-Fehler. Das Script läuft also in den Timeout. Das die CPU-Last in die Decke geht passt meistens zu diesem Fehler. Oft gibt es aufgrund irgendwelcher Umstände Endloschleifen und die Last wird immer größer, bis der Server mit Error 408 oder auch 500er Error abbricht.

Die Ursache kann ma nicht einfach so ohne Kenntnis der verwendeten Scripte erraten. Es kann sein das Ressourcen nicht geladen werden können. Es kann auch aufgrund von Fehlern in der Datenbank dazu kommen.

Die Aktivierung des Error-Reportings ist der zunächst beste Schritt. Wurde ja schon genannt.

Wenn das zu keine sinnvollen Meldungen führt deaktiviere in der Datenbank alle Plugins, die im Backend wirken. Meistens führt letzteres zum Erfolg. Wenn nicht, muss man detaillierter schauen - aber ohne Kenntnis des Servers oder der Scripte von außen nicht mehr zu supporten.