Mein Gott, von einem halbwegs gebildeten Menschen, hätte ich nicht derart viel Beratungsresistenz erwartet. 
Manche sind eben schlauer als andere, besonders die mit Doktor-Titel offenbar.
Zitat
...keine Ahnung, was an meiner Website so verwerflich sein soll...
An der Seite ist verwerflich, das das ein Pulverfass ist und andere schädigen kann und das massiv. Dabei geht es nicht darum, ob Du viele Besucher hast oder nicht. Aber was erzähle ich hier, kommt beim Empfänger eh nicht an. 
Allerdings ist eine Migration von 1.5 -> 4.2 mit so vielen einzelnen Zwischenschritten verbunden, das das keinen Sinn macht.
Besser, schneller und sicherer ist es ein neues Joomla aufzusetzen und die Inhalte zu übertragen. Das eleminiert auch gleich ggf. vorhandene Backdoors im dem alten Web.
Du wirst hier keinen Support für diese Uraltversion erhalten.
Mann kann nur hoffen, dass diese Seite schnellstens abgeschaltet wird und die Gefahr, die von deiner Seite ausgeht, so schnell wie möglich endet!
Vielleicht kann die Administration des Forums noch den Link im Eingangs-Thread des TE entfernen?
Vor allen Dingen war die Seite simpel und sicherlich völlig problemlos auf ein aktuelles Joomla übertragbar. Zwar nicht mit dem alten Template, aber das war wedder resonsive noch sonstwie ansprechend.
Alles anzeigenHallo,
ich arbeite aus verschiedenen Gründen noch mit einer Joomla-Version aus der Steinzeit, sozusagen... ich habe da jetzt das Problem, dass ich zwar einen ein neues Slide erstellt habe, dieses aber nicht mit einem zugehörigen Beitrag verknüpfen kann bzw. nicht weiß, wie das geht... meine Website ist vor Urzeiten mal von einem Studenten von mir erstellt worden...
Schöne Grüße
Sven
Bei uns wäre die Seite spätestens jetzt vom Netz "gegangen worden".... unfassbar
Noch ein Nachtrag:
Du könntest CloudFlare vorschalten und dort Geoblocking providerunanhängig aktivieren. Aber wie gesagt: Das ist (fast) sinnfrei.
Lass es sein.....
Geoblocking funktioniert nicht. Hacker und Angreifer sperrst Du damit nicht aus.
In erster Linie blockierst Du legale User.
Das das nicht überall geht hängt damit zusammen das kaum ein Provider dieses Modul installiert haben wird.
Mal ein bißchen Theorie:
Von entscheidener Bedeutung ist mit welcher Absenderadresse eine EMail über welchen Mailserver versendet wird.
Der sendene Mailserver muss über den SPF-Record als erlaubter Mailserver für die Absenderdomain eingestellt sein.
Gmail und andere lehnen Emails ab, wo diese Prüfung scheitert!
Wie man einen SPF-Entrag richtig konfiguriert kann man ein einfachsten hier lernen:
Beispiel: Eine Email mit einer gmail-Adresse wird via phpmail() über den Hostingserver versendet. Gmail erkennt, das der Hostingserver kein für Gmail-Adressen erlaubter Mailserver ist und lehnt den Empfang ab. Das kann man eigentlich leicht verstehen.
Komplizierter wird es wenn es Weiterleitungen gibt. Also z.B. sendet ein User eine Email an eine Emailadresse und diese leitet weiter an ein Gmail-Postfach.
Der Gmail-Mailserver "sieht" dann folgendes: Da kommt eine Email von einem Nicht-Gmail-Server (dem Weiterleitungsserver) und - ja, lehnt den Empfang ab.
Diese Problematik kann man mit SRS (Sender Rewriting Scheme) umgehen. Das haben jedoch längst nicht alle Provider auf ihren Mailservern implementiert. Dabei wird die Absenderadresse so "umcodiert" das der Empfänger eine andere Absenderdomain "sieht" - und zwar eine erlaubte Domain des Weiterleitungsservers. Im Zielpostfach selbst sieht der Empfänger jedoch die richtige Absender-Domain und kann auch direkt darauf antworten.
Zur Einstellung im Joomla:
Man sollte immer SMTP benutzen und dabei den SMTP einstellen, der für die eigene Absenderdomain gültig ist. Sendet man also mit einer Gmail-Adresse, muss man den Gmail-SMTP benutzen, bei einer T-Online-Adresse den T-Online SMTP usw.
phpmail() sollte man gar nicht benutzen und sendmail auch nicht (es Serverkonfigurationen geben, wo man das allerdings nutzen muss).
Zusätzlich zum SPF-Record ist auch ein DMARC und DKIM-Record sinnvoll. Letzteres (DKIM) ist muss inder DNS und auf dem Mailserver eingerichtet werden. Alles zusammen verbessert die Reputation einer Domain.
Die ganze Mailproblematik ist nicht so trivial wie man oft denkt. Und es gibt Abhängigkeiten aufgrund der Serverkonfiguration, weshalb man keine 100% allgemeingültige Einstellung vorgeben kann. Normalerweise sollte der eigene Provider hier der Ansprechpartner sein.
Ein anderes Problem wird gerade im Schweizer Forum diskutiert:
Da geht es darum das die Search-Console zu kleine Schriftarten für mobile Darstellung erkennt und daher meckert. Hintergrund scheint zu sein, das bei Verwendung von JT ALDEF die Search-Console das on-the-fly-Herunderladen der Fonts verhindert. Ob das nun das Herunterladen vom Google-Server oder der lokalen Seite betrifft kann ich nicht sagen. Aber wenn der GoogleBot JS ignoriert und das Laden der Fonts wegen JT ALDEF via JS funktioniert, dann werden die Fonts (egal von wo) nicht geladen.
Ich weiss nicht ob deren Server automatisch komprimieren. Das kann man doch leicht testen.
Da stimme ich Dir zu Volkmar!
Aber letztlich geht es auch nicht ohne wenigstens minimaler Kenntnisse, damit man sich so ein Tool nicht umsonst kauft. Sich einfach ein Tool zu installieren, weil man dann glaubt damit was zu bewirken (hier den opcache löschen) macht nur Sinn, wenn die Serverkonfiguration das auch erlaubt. Wie in dem verlinkten Artikel zu lesen ist, kann man den cache gar nicht überall löschen (z.B. PHP als cgi oder FastCGI). In anderen Fällen (PHP-FPM) müsste man sogar einen Serverdienst restarten. Das wäre PHP gar nicht erlaubt... aber egal, führt hier weit. Die sinnvollste Variante hatte ich in Post #6 genannt.
BTW:
Lese ich hier richtig? DF bietet neuerdings 64-Bit Hosting an? Das ist ja kaum zu glauben..... 
Ich kann mich gar nicht mehr an 32-Bit erinnern 
Ich glaube vor ca. 10 Jahren hatten wir auch mal ein paar Server mit 32-Bit.... 
Den opcache kann man leicht löschen. Dafür braucht mal kein kostenpflichtiges Tool.
<?php
opcache_reset();
?>Geht nur nicht bei der Server-Konfig:
https://ma.ttias.be/how-to-clear-php-opcache/
Vorgeschalte Proxyserver können leider auch Nachteile haben...
Ganz allgemein:
Den OPcache würde ich auf gar keinen Fall deaktivieren.
Gzip im Joomla auch nur einschalten, wenn der Server nicht bereits per Defaul komprimiert, Doppeltes komprimieren ist kontraproduktiv und die Komprimierung auf Serverseite ist immer performanter, als wenn das auf PHP-Seite aktiviert wird.
Ich denke die vom Security-Team für die Hoster mitgeteilten mod-security-Regeln kann man auch mit htaccess realisieren.
Ich möchte das hier nicht veröffentlichen, weil das ggf. auch potentiellen Angreifern hilft.
Ja ich auch nicht - umso wichtigr sind die Firewall-Regeln.
im heise-Forum steht:
Zitatder patch lässt schlimmes befürchten...
Der Patch ist jetzt auf github. Sieht aus als könnte ich ungepatcht jede nicht-öffentliche API mit 'public' als Query Parameter wie eine offene API aufrufen.
Das wäre Joomlas Log4Shell...
Das Security Team ist in Kontakt mit einer Vielzahl von Hostern. Zum Zeitpunkt des Release stellen wir den Hostern Regelsätze bereit, die in die von den Hostern betriebenen Firewall-Applikationen eingespielt werden können.
Das ist auch absolut super David!
Wenn ich mal spaßeshalber quer-beet über die Server schaue sind nicht einmal 50% aller 4er-Joomla geupdated worden - trotz direkter Anspache an alle Kunden, als das Update das erste mal angekündigt wurde.
Meine Meinung ist hier eigentlich ganz simpel:
Natürlich sollten alle Services/APIs etc. deaktiviert sein, die nicht zwangsweise für ein Default-Setup genutzt werden und nur aktiviert werden müssen, wenn man sie tatsächlich einsetzen will. Das sollte doch überhaupt gar kein Problem sein.
Die Installation auf gar keinen Fall aufblähen, sondern immer so schlank wie möglich halten.
Die Lücke war nicht so undurchschaubar, dass nicht schon andere sie ggf. zuvor rausbekommen haben.
Ja diese Unsicherheit bleibt immer, auch wenn gesagt wird das "in freier Wildbahn" noch kein darauf basierender Hack gesichtet wurde.
So, die vom Security-Team gelieferten Infos sind in die Firewall eingetragen. Damit sollte hier schon mal alles sicher sein.
Ping .....
Ich benutze Akeeba-Backup-Pro und kann die damit die Dateien überschreiben sowie die Datenbank löschen.
Löscht die Pro-Version alle Dateien von Joomla und sichert dann zurück oder werden vorhandene Dateien nur überschrieben, wenn diese zur Rücksicherung gehören. Letzteres wäre ja fatal, denn dann würden typische Hacker-Backdoors größtenteils bestehen bleiben.
Grundsätzlichg bin ich kein Fan von Akeeba und anderen internen Backup-Scripten eines CMS, die dann meistens auch noch innerhalb der jeweiligen CMS-Ordnerstruktur sichern, anstatt in einem externen Ordner außerhalb des Webs. Ja ich weiss man kann Akeeba und andere Tools oft auf andere Ordner einstellen, aber in der Praxis macht das kaum jemand.
Als Ergebnis hat man dann sehr häufig extrem aufgeblähte Datenmengen in seinem CMS - hauptsachlich bestehend aus Backupfiles. Das ist ein grunsätzliches Designproblem dieser Backuplösungen.
Rücksicherungen sind dann auch oft mit langwierigen Vorbereitungszeiten verbunden, wie das löschen des Altbestands (mit FTP bei zehntausenden Files eines typischen CMS dann eine Geduldsprobe) und der Bereitstellung von Setupscripten samt einer oder mehrere Backupfiles (sofern man die nicht aus Versehen vorher mit weggelöscht hat).
Eine weitere Gefahr ist das Liegenlassen dieser Rücksicherungsfiles - ich weiss nicht wie oft ich schon auf eine kickstarter.php samt jpa-Daten in Webroot gestossen bin - kann es nicht mehr zählen.... Hacker-Bots suchen genau solche Files und was dann passiert ist nicht lustig.
Meines Erachtens sollte es Aufgabe des Providers sein, schnelle und effektive Backuplösungen anbieten - als Bestandteil eines Hostingtarifs. Backups erzeugen und Rücksichern per Klick und ohne Vorbereitungen und ohne Abhängigkeiten zu einem CMS. Bereinigung vor einer Rücksicherung automatisch etc. Viele machen das ja, aber offenbar längst nicht alle oder User vertrauen diesen Lösungen nicht (ob das im Einzelfall berechtigt ist, kann ich nicht beurteilen).
