Warum überhaupt Akeeba?
Lade doch einfach alle Joomla-Dateien vom Server auf Deinen PC in das lokale Web.
Lege eine Datenbank an und importieren den Dump vom Server.
Passe die configurationen.php an: Datenbankzugriff und zwei Pfade - fertig....
Natürlich eine passende lokale PHP-Version einsetzen, mit der Dein Joomla kompatibel ist.
nein es gibt keine Tools, die alle Schadcode-Files finden.
Ich habe es auch noch nie erlebt, das Schadcodefiles nur in einem Ordner liegen. Quasi immer gab es weitere versteckte Backdoors.
Es gibt kaum eine echte Chance auf eine wirklich sichere Bereinigung eines gehackten Webs. Denn dazu müsste man tatsächlich in JEDE Datei schauen und jede Codezeile prüfen. Eine Backdoor kann aus nur einer Zeile PHP-Code bestehen,
Wie Jan oben schon schrieb ist das wichtigste herauszufinden, wie es zu dem Hack kam und die Lücke zu finden die benutzt wurde. Der zeitlich Ersthack muss ermittelt werden, dann kann man mit einem zeitlich davor liegenden Backup das Web vollständig ersetzen und doe Lücke(n) schließen.
Ich rate dazu die Dateinamen der Bilder vor dem Hochladen umzubennnen.
Immer Kleinschrift und auf keinen Fall Sonderzeichen, auch keine Leerzeichen.
Das ist am kompatibelsten und sichersten und im Übrigen ist dann auch kein intl-Modul des PHP erforderlich.
Eine IP kannst Du wunderbar hiermit prüfen:
AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a time
Bei dir klappt der SMTP - Versand tatsächlich?
ja kein Problem. Ich bin aber nicht bei Strato 
Du nutzt doch sicher auch ein Emailprogramm mit Deiner Emailadresse bei Strato, die im Joomla als Absender dienen soll. Du musst im Joomla dieselben Einstellungen einstellen, wie für den Postausgang in Deinem Emailprogramm. So schwer kann das doch nicht sein!
UCEPROTEC kannste vergessen. Das ist nicht Dein Problem.
SMTP mit dem Gmail-SMTP-Sever smtp.gmail.com kannst Du auch vergessen. Funktioniert nicht mit Joomla, weil Joomla kein OAUTH kann.
Nutze den Strato-SMTP-Server und nutze Deine Domain als Absender, keine Gmail-Adresse!
Wenn dann der SPF so gesetzt ist das der Strato-SMTP erlaubt ist, dann sollte auch das Senden an Gmail-Adressen funktionieren.
Viel Text, wenig Infos mit denen man was anfangen kann.
Joomla läuft auf Strato. Das scheint klar zu sein.
Welches Mailverfahren ist im Joomla eingestrellt? (phpmail/SMTP/sendmail)
Wie lautet die Absender-Domain? Ist das Deine Domain oder sendest Du mit einer Gmail-Adresse?
Nachtrag:
Gmail unterstützt nicht mehr die Standard-Authentifizierung, sondern nur noch Oauth. So lange Joomla das nicht unterstützt, wird man den SMTP von Gmail nicht nutzen können. Gleiches gilt auch für MS365-Adressen von Microsoft...
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.