Beiträge von flotte

Ja, aber hier muss man auch darauf achten, das man keine downloadbaren Zip-Archive einfach rumliegen lässt. Das passiert leider immer wieder, wenn diese nicht autom. gelöscht und/oder noch mal extra per FTP gelöscht werden. Ebenso darauf achten, das liegengelasene Backups nicht beim nächsten Backuplauf mitgesichert werden. Dann vergrößert sich das Backup schnell sehr massiv. Bei zu großen Datenmengen stossen solche Scripte auch schnell aus Gründen von PHP-Begrenzungen an Limits (Laufzeit/RAM-Limits). Bei sehr großen Datenmengen sind Backups also durchaus nicht trivial.

Ein Provider sollte parallel dazu auch autom. sichern. Das werden sicher viele Provider in Ihren Paketen dabei haben. Für manuelle Backups sollte ein Provider ebenfalls serverseitige Funktionen zur Verfügung stellen, womit scriptunabhängig und auch Datenmengen-unabhängig jederzeit selbst gesichert werden kann, inkl. Downloadfunktion bei Bedarf.

Hervorragend!

Ein Restore auf eine Version 3.7.0 mit einer CORE-Lücke die auf einfache Weise die Übernahme der Website durch Dritte ermöglicht ist auf keinen Fall eine Lösung.
Was genau das Problem auf Deinen Seiten ist kann ich Dir allerdings auch nicht sagen. Schwer hier etwas von außen zu beurteilen, erst recht wenn man nicht weiss wie es eigentlich aussehen sollte.

Momentan ist nicht öffentlich um was für eine Lücke es geht. Folglich kann man nicht sagen, ob das Offline-Schalten alleine ausreicht. Hackangriffe können auch direkt auf Dateien des Joomla gehen, ohne "Umweg" über die index.php.
Besser wird es sein einen .htaccess-Passwortschutz zu schalten, damit nichts mehr aufrufbar ist.

Zitat

...ich habe auch viel gefunden, aber kaum etwas in Verbindung mit Joomla...

Das hat auch genau genommen mit Joomla nichts zu tun. Als Serveradministrator solltest Du die gängigen Server-Communities aufsuchen. Dies hier ist ein Joomla-Forum. Natürlich spielen Serverfragen auch eine Rolle und es gibt überschneidene Bereiche, aber Anleitungen für grundsätzliche Basisinstallationen von Serversoftware hat hier wirklich nichts zu suchen.

Möglicherweise hängt es hier zusammen:
http://www.joomlaportal.de/joo…-7-menu-verschwunden.html

Kann das Problem bestätigen. Hatten jetzt mehere Kunden mit mehrsprachigen Seiten mit diesem Problem.
Deaktivieren von plg_system_cache hat gehofen. opcache ist immer aktiv gewesen (per Default).
Die weisse Seite war nicht wie sonst üblich bei weissen Seiten ein Error-500, sondern der Webserver liefert ganz normal Code 200. Es gibt auch keine andere Fehlermeldung, wenn man das Error-Reporting hochschraubt.

System -> Konfiguration -> Tab "Textfilter"

Wie Later schon erläutert hat, sind HEAD-Anfragen ähnlich GET, mit dem Unterschied das keine Inhalte geladen werden, sondern nur der Header ausgeliefert wird. Wird legal benutzt, aber vielfach eben auch von Hackern, die damit auf das Vorhandensein bestimmter Dateien/URLs prüfen wollen. Weiter wird das benutzt um SEO-Spam zu übermitteln. Das ist offenbar bei Deinen geposteten Anfragen der Sinn, denn diese gehen relativ sinnfrei einfach nur per Abfrage auf "/" auf das Webroot. Die übermittelten Herkunfts-Links (Referrer) stehen dann aber in Deiner Logfilestatistik und verleiten zum Draufklicken, weil man ja wissen will woher Besucher kommen - und schon hat das Spamming funktioniert.
HEAD-Anfragen sind zu 99% Hacker-Recherchen und SEO-Spam.

Ob das ein Joomla-Problem oder Serverproblem ist muss erst einmal geklärt werden.
Rufe eine Datei ohne Joomla via https auf. Z.B. die robots.txt oder eine Datei die Du kurz mal dafür ins Web kopierst. Wenn SSL dann nicht klappt, obwohl SSL für die Domain eingerichtet ist, dann liegt ein Serverproblem vor.

Du verwaltest den Server selbst und bist der Administrator? Dann solltest Du auf Deinem eigenen Server selbst die Ursache finden können. Wir kennen Deinen Server ja nicht und auch nicht wie Lets-Encrypt dort eingebunden ist. In der Regel kann man LE-Zertifikate nur installieren, wenn die Domain schon auf den Server zeigt. Falls DUe LE also zu früh installiert hats, ist hier ggf. eine Ursache zu finden.

Wenn SSL funktioniert, aber Joomla damit nicht, dann ist es ein Joomla-Problem.
Hier dann die Frage meines Vorposters: Wurde in der Joomla-Konfig auf SSL-Erzwingen gestellt?

Bei mir auch mit FF und Chrome dieselbe fehlerhafte Darstellung wie bei Elwood

Ein wirklich merkwürdiges Problem.
Mein Bauchgefühl sagt mir, schalte mal die gzip-Komprimierung aus.

Da kann man nichts besonderes erkennen.
Was passiert, wenn Du SEO im Backend deaktivierst und die .htaccess durch umbenennen deaktivierst?
Lösche auch den INhalt des /cache Ordners und deaktiviere Cache-Funktionen im Joomla.
Browser-Cache auch löschen

Deaktiviere doch mal die .htaccess oder zeige den kompletten Inhalt.
Eine einzelne Datei aus dem Web kann ich problemlos via SSL aufrufen:
https://www.herzundverstand.at/robots.txt

Sobald der Aufruf aber über Joomla und der index.php läuft, wird umgeleitet auf http:
Irgendwo muss eine solche Regeln/Funktion aktiviert sein.

Hast Du schon dies versucht?
* anderen Broewser benutzt
* anderen PC benutzt
* Cookie-Bestätigungs-Plugin deaktiviert

Hast Du schon versucht in der configuration.php diese Zeile anzupassen?
public $force_ssl = '1';

--> von 0 auf 1 stellen.

Das setzen eines .htaccess-Passwortschutzes für das administrator-Verzeichnis wurde shcon als richtig erkannt. Damit erschwerst Du Bruteforce-Attacken deutlich, verringerst die dabei entstehende Last massiv und schützt alle Direktzugriffe auf Bereiche des Backends. Jedes Joomla sollte so einen Schutz haben.

Ländersperren sind mit äußerster Vorsicht zu genießen. Zum ändern ändern sich auch IP-Bereiche und weiterhin sperrst Du dann auch Touristen aus usw. Viele Angreifer nutzen zudem Proxies und ähnliches und verschleiern die Herkunft auf diese Weise. Auch viele "normale" User nutzen heute VPN-Verbindungen für den Internetzugang und die geografische Zuordnung gemäß IP zeigt hier dann nicht mehr die tatsächliche Herkunft des Users an. Die .htaccess sollte auch nicht extrem aufgebläht werden, um die Performance nicht zu gefährden.

Die Darstellungsprobleme liegen vermutlich an der Codierung der Seite. Ohne Link auf eine Seite wo das Problem zu sehen ist, kann ma nur raten. Es kann auch andere Ursachen geben, die mit der Codierung zusammenhängen (PHP, Datenbank). Deshalb auch die PHP und MySQL-Versionen nennen.

Nein, meines Wissen gibt es so was nicht.

Vergiss die SSL-Proxies. Gibt nur Probleme mit Cookies etc.pp. LetsEncrypt kannst Du nur selbst installieren, wenn Du root bist - also vergiss es. Du bist auf Deinen Provider angewiesen.
SSL-Zertifikate kosten doch kein großes Geld mehr, die Nutzung ist aber mittlerweile Pflicht. Wenn Dein Provider Dir nichts anbieten kann, dann zieh halt um. Fast überall sind SSL-Zertiufikate bei neuen Verträgen inklusive.