Das ist auch provider- und serverabhängig. Meistens ist es so, das bei Verwendung von phpmail() die Absenderadresse nicht als Return-Path gesetzt wird, sondern eine Systemadresse. Allerdings kannman das nicht verallgemeinern, weil das eben stark mit der Serverkonfiguration zusammenhängt. In diesen Fällen können dann keine Bounce-Mails empfangen werden.
Beiträge von flotte
-
-
Es sollte immer ein SPF, DKIM, DMARC-Record gesetzt werden.
Wie das geht, sagt Dir Dein Provider.
Bei uns so: https://www.fc-hosting.de/supp…q_mail_spf-dkim-dmarc.php
Da gibt es auch noch Erklärungen was das eigentlich ist.
Joomla auf jeden Fall auf SMTP einstellen. Dabei ist es wichtig das die Absenderdomain zum SMTP passt und der SPF-Record diesen SMTP auch beinhaltet.
Weil das alles sehr unterschiedlich je Provider und Situation sein kann, sollte Dein Provider hier der erste Ansprechpartner sein.
-
Offenbar bist Du dann bei einem Hoster, der nicht vom Joomla-Security-Teams über Core-Lücken informiert wird. Es wurde bei Erscheinen der Sicherheitslücke entsprechende Filterregeln verteilt, um solche Angriffe bereits auf Firewall-Ebene zu blocken.
Allerdings würde ich mich wundern, wenn Strato nicht informiert wird. Andererseits kann ich mir vorstellen, das denen das schei***egal ist.
-
Das ist ja fatal, wenn Ionos seine Server so konfiguriert, das lokale .htaccess oder Headereinstellungen nicht eine globale Konfiguration überschreiben können. Möglicherweise ist allowoverride deaktiviert.
core - Apache HTTP Server Version 2.4
Eine zentrale Konfiguration ist zwar performanter, aber auf Shared-Hostingserver hat ein Kunde ja keinen Zugriff auf die zentrale Apache-Konfigurationsdatei.
BTW:
Die Aussage des Supports zeigt mal wieder die gesammelten Kompetenzen der Call-Center-Agents bei solchen Massenhostern. Aber das schreib ich lieber nichts zu .... gerade erst einen Volldeppen aus dem GMX-Support gesprochen, wegen einer anderen Geschichte.
-
Google entscheidet bei Recaptcha auf Grundlage des Nutzerverhaltens, ob eine explizite Aufgabe abgefragt wird, oder ob der Nutzer auch ohne Aufgabe vertrauenswürdig genug ist.
Google geht mit dem Tracking sogar noch viele Schritte weiter, als bei der "normalen" Verlinkung mit einem Googleserver. DSGVO konform - klares Nein.
Tatsächlich gibt es momentan nicht viele Erweiterungen, die Bots erkennen. ECC+ ist aber auf jeden Fall eine guter Ansatz.
-
Typische Virenscanner finden nur selten auf PHP basierten Schadcode. Kann man als Teil einer Untersuchung mit versuchen, aber normalerweise würde eine Untersuchung direkt auf dem Server stattfinden, sofern alle benötogsten Mittel wie mindestens ein SSH-Zugang zur Verfügung stehen. Im Fall eines Hacks sollte der Datenbestand nach Vermutung eines Hacks auf keinen Fall verändert werden, weil all das die Untersuchung erschwert.
Hier haben wir eine FAQ-Seite bei uns, die ein sinnvolles Vorgehen zeigt.
Es gibt hier im Forum einige gute Fachleute, die Deine Seite untersuchen können. Du findet einige davon auch in unserer Partnerliste.
-
Nochmal zur Klarstellung: Die genannte Website muss nicht zwangsläufig kompromittiert sein. Viele Schutzdienste orientieren sich auch an der Webserver-IP. Die IP 178.254.10.204 ist auf jedem Fall bei mehrere Reputationsdiensten gelistet.
Z.B. hier: https://www.abuseipdb.com/check/178.254.10.204
Das heisst von dem Server aus wurden oder werden Hackversuche unternommen. Das kann nun die hier besprocherne Seite sein, aber auch eine andere auf dem Server.
Ob die eigenen Seite gehackt ist, sollte man leicht erkennen, indem man diese mal fachmännisch prüft. Ansonsten wäre mal der Provider zu infornieren. Sofern er das noch nicht weiss, sollte er drüber informiert werden, das von seinem Server aus gehackt wird.
-
Nur mal so an Rande: Ein Test bei Virustotal macht nur eine Aussage, wenn Schadcode gefunden wurde. Wird nichts gefunden, bedeuted das GAR NICHTS.
-
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:
-
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...
