Zur Info:
Malwarebytes blockiert die Seite und meldet eine Kompromitierung.
Das kann sein das dies von früheren Hacks stammt oder auch von Hacks auf dem betreffenden Server.
Die IP des Servers zeigt auf jeden Fall relativ aktuelle Einträge:
Beiträge von flotte
-
-
Leider viel zu viel Prosa Text. Denkbar schlechter Text - wer soll das alles lesen?
Solche Hilfeseiten sollten sich auf die nackten Fakten beziehen und so kurz wie möglich geschrieben werden. -
Sofern ein Hoster keine überlasteten Server einsetzt oder (bei vielen Massenprovider leider Fall) zentrale Datenbankserver (oftmals Flaschenhals), ist der Webserver selbst meistens nicht die Ursache für zu langsame Seiten. Viele der heutigen Scripte und Templates sind extrem komplex, laden massenhaft JavaScript und CSS-Files, basieren auf komplexen Frameworks und bremsen damit die Verarbeitung auf dem Server und (das ist meistens noch viel krasser) den Aufbau der Seiten im Browser.
Server- und scriptseitige Optimierungstools müssen mit entsprechender Fachkenntnis eingesetzt werden. Da hat JoomlaWunder vollkommen recht, denn blinder Einsatz ohne wirklich zu wissen wo man was optimieren kann, enden dann tatsächlich im Desaster.
Es ist nicht möglich hier den universell geltenen Performancetipp zu posten - zu unterschiedlich ist die Ausgangssituation.
-
Wenn nichts anderes hilft, installiere xampp neu - in derselben Version.
Vorher das htdocs und das data-Verziechnis von MySQL sichern (Mysql darf aber nicht laufen). Dnan kannst Du das zurücksichern.
Ggf. auch die php.ini, sofern Du dort Einstellungen verändert hast
-
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 anzeigen
Hallo,
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:
Generator - SPF-RecordMit dem SPF-Generator einfach und in wenigen Schritten zum korrekten SPF record. Lösen Sie E-Mailprobleme und schüzen Sie sich vor E-mail-Spoofing.www.spf-record.deBeispiel: 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.
