Beiträge von moggern

    Ich betreibe auf einem Webhosting8000 ca. acht Wordpress-Installationen mit jeweils separaten (Sub-)Domains und noch vier andere PHP-Anwendungen (Limesurvey, FreeScout, Grocy, Mautic). Seit ca. zwei Wochen ist das gesamte Hostingpaket von einem PHP-Rootkit, so nenne ich es jetzt einfach mal, befallen. In manche index.php-Dateien wird z.B. sowas geschrieben

    es werden neue Dateien wie radio.php erstellt

    oder auch wp-login.php (auch wenn es sich gar nicht um ein Wordpress handelt)


    Den größten Teil kann ich immer anhand von Zeitstempeln erkennen und händisch entfernen. Einige unwichtige Wordpress-Seiten habe ich gesperrt, alle anderen geupdatet, v.a. auch die Plugins, aber das Zeug kommt täglich wieder und liefert dann teilweise Gewinnspiele aus etc.


    Gibt es einen Lösung, um innerhalb des Webhostings Seiten voneinander zu isolieren? Es wäre ja blöd, wenn diese sich immer wieder gegenseitig infizieren.


    Welche Möglichkeiten gibt es zu Bekämpfung? Innerhalb der WP-Seiten habe ich schon gute Erfahrung mit dem Plugin Wordfence gemacht, aber das geht halt auch nur da und verhindert auch nicht, dass das wieder kommt.


    Vielen Dank vorab!

    Moin, moin,


    ich habe u.a. zwei EiWoMiSau und ein Webhosting 8000. Leider wird von nahezu allen Mailtestern wie z.B.

    beklagt, dass die DKIM keys bzw. Signatur fehlen.

    Im CCP sind im DNS unverändert die Standardwerte

    Code
    key1._domainkey CNAME key1._domainkey.webhosting.systems
    key2._domainkey CNAME key2._domainkey.webhosting.systems

    hinterlegt.


    Habt ihr eine Idee, woran das noch liegen könnte? Die können doch nicht alle falsch liegen.

    Hallo zusammen,


    nach einem lange Zeit vernachlässigtem und nun durch MySQL 8 erzwungenem Update auf die aktuelle LimeSurvey LTS v3.27.22 bekomme ich einen open_basedir Fehler. Die PHP Versionen 7.2, 7.3 und 7.4 ändern daran nichts. Auch habe ich schon beide Variante mit DOCROOT und WEBROOT durchprobiert. Habt ihr eine Idee?


    Webhosting 8000


    Eben noch ne die Berechnung der Prozentwerte für busy, idle, iowait und steal hinzugefügt.

    Vielleicht könnte man auch eine DB anlegen und die Auslastung über einen längeren Zeitpunkt tracken? Dann kann man wirklich über einen längeren Zeitraum sehen, wie es auf dem Host aussieht.


    Code
    [PHP] Error: Invalid argument supplied for foreach() at /var/www/vhosts/hosting123456.abcde.netcup.net/httpdocs/cloud/apps/serverinfo/lib/OperatingSystems/DefaultOs.php#120
    
    GET /settings/xxx/serverinfo
    from 79.140.aaa.bbb by xxx at 2020-04-09T13:27:11+02:00

    Seit ein paar Tagen kommt beim Aufruf der `nestcoud/settings/admin/serverinfo` Seite obiger Fehlermeldung. Blockt da netcup jetzt was?

    Die Statistik funktioniert jedoch nach wie vor.

    Wie kommst du zu deiner negativen Aussage?

    Offenbar interpretiere ich den Load-Wert falsch. Da die Nextcloud zu dem Zeitpunkt gerade unerträglich langsam war, passte das dazu.


    Ab welchem Wert wäre denn meine Annahme gerechtfertigt?

    Seit einiger Zeit habe ich neben ein paar Wollmilchsäuen ein Webhosting 8000, den größten Tarif in der Reihe. Dort läuft u.a. eine Nextcloud, die auch ein wenig Leistung benötigt.


    Beträgt in den Abend- und Nachtstunden die Last 1.4 bis 1.9, kann diese tagsüber schon mal im Bereich 4.5 bis 5 liegen.


    Wie sieht das bei euch aus?

    Kann man da was machen gegen "andere" Mitnutzer, die es übertreiben oder stopft netcup die Server einfach nur randvoll, egal welcher Tarif?

    Deaktiviere mal die intelligente Bearbeitung.

    Hat leider nichts gebracht.

    Wie siehts hier aus?

    Ich war schon bei PHP 7.3.15 und dort gibt es nur FastCGI. Ein Downgrade auf 7.2.28 und Umstellung auf FPM führte bei mir dazu:

    Wir betreiben eine Nextcloud, aktuell noch in v17.0.3 Im dortigen admin Menü werden folgender Fehler/Warnungen ausgeworfen:

    • Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Es wurde kein PHP-Memory-Cache konfiguriert. Zur Erhöhung der Leistungsfähigkeit kann ein Memory-Cache konfiguriert werden. Weitere Informationen findest Du in der Dokumentation.
    • Der "Referrer-Policy" HTTP-Header ist nicht gesetzt auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin". Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.

    Die Meldung mit dem PHP-Memory-Cache bekomme ich wohl aufgrund des Shared Hostings und den entsprechenden Voreinstellungen nicht weg. Was aber ist mit den anderen Meldungen? Die .htaccess hat gleich im zweiten Block u.a. das hier stehen:


    Wird die Datei ignoriert?


    HSTS läuft ja auch, wobei ich dieses in Plesk über die zusätzlichen Apache Header aktiviert habe:
    pasted-from-clipboard.png


    Für die anderen o.g. Fehler klappt das leider nicht :(


    Hat jemand eine Idee, wo ich noch etwas beeinflussen kann?

    Ich bin schon einen Schritt weiter. Die Tests aus dem lokalen Netz waren erfolgreich, da letztendlich die IP beider Geräte lokal erreichbar ist. Von draußen kennt er natürlich keine 192er Adressen.

    Habt ihr eine Idee wie ich das lösen kann?

    Das LAN wird über einen DynDNS-Namen aufgelöst.

    Ich habe mehrere Webhostings und möchte diese via Backup Manager auf einen lokalen FTP-Server sichern. Leider gibt es bei Eingabe der Zugangsdaten im Backup Manager immer eine Fehlermeldung:

    Zitat

    Fehler: Unable to access to the storage: Transport error: unable to list directory: Curl error: (7) Couldn't connect to server: Last FTP request: PASV Last FTP response: 227 Entering Passive Mode (192,168,1,2,217,36)


    Make sure you have entered the correct storage settings. You can check them independently with the command:

    curl -v --ftp-pasv --ssl -k -u ftpuser 'ftp://subdomain.example.com/home/'pasted-from-clipboard.png


    Ich bekomme die Meldung sowohl wenn ich als Server ein Debian 8 mit proftpd verwenden, als auch bei einem Synology NAS mit integriertem FTP Server.

    Logge ich zum Testen via mc (midnight commander) oder Nautilus unter Linux ein klappt die Verbindung sofort.


    Habt ihr eine Idee woran das liegen könnte?

    Vielleicht kannst du im Webhostingpanel verschiedene PHP-Versionen ausprobieren.

    Ich werd verrückt! Das ist es!


    Ich habe von der PHV Version laut 7.2.19 auf "7.2" gewechselt und siehe da, alle Logins funktionieren!


    Vielen Dank an euch!


    Nun ist dort aber das Problem, dass in dieser Version der OpCache fehlt... Man kann es drehen und wenden wie man will. Irgendwas fehlt immer.