Beiträge von Sumeragi

    Wenn ein SE Update PHP Aktualisierungen enthalten, müssen zusätzlich installierte Extension nachinstalliert werden.


    Ich hatte dazu Mal ein Skript gepostet. Dieses führe ich immer manuell nach einem SE Update aus. Sicherlich kann man dies auch weiter automatisieren.

    Der genannte Bug bezieht sich ausschließlich auf PHP 7.4. In dem genannten Bug Report wurde sogar mit PHP 7.2 und 7.3 getestet und der Bug trat nur bei PHP 7.4 auf.


    Der "memory allocation" Fehler deutet darauf hin, dass das Limit für den Arbeitsspeicher im Angebot des Endkunden zu niedrig eingestellt ist. Ich empfehle hier mindestens 768MB. Nextcloud selber empfiehlt bereits ein Minimum von 512MB.


    Die Angaben memory_cost, time_cost, threads sind zudem Parameter der password_hash()-Funktion. Daher wird ein Eintrag in der php.ini auch keinerlei Wirkung haben, da diese nirgends übergeben werden.

    dürfte eigentlich nicht sein. Ich habe Nestcloud 16 unter der SE 6 schon zum Laufen bekommen. Ich habe allerdings

    Code
    1. extension_dir=""
    2. extension=apcu.so

    in der php.ini stehen und nicht den vollständigen Pfad. Der kann sich ja mit einem Update der SE immer wieder ändern.

    Es kann nur eine Datei geladen werden. Wenn mehrere my.cnf Dateien gefunden werden, würde die erste genommen. Daher gibt es auch Probleme, wenn unter /etc/ eine my.cnf liegt.


    Die Datei unter /home/mysql/ sollte eigentlich ein Symlink zum genannten Pfad sein:

    Code
    1. # ls -al /home/mysql/my.cnf
    2. lrwxrwxrwx. 1 root root 31 24. Okt 09:27 /home/mysql/my.cnf -> /usr/local/pd-admin2/etc/my.cnf


    Der strict mode verhindert das Einfügen oder Ändern von Inhalten durch falsche oder leere Werte. Die kann bei manchen Anwendungen zu Fehlern führen. Daher sollte der strict mode testweise deaktiviert werden. Dadurch ist MySQL toleranter.

    Also das ist nur eine Vermutung... dies muss nicht die Ursache sein. Eigentlich sollte ja etwas im Apache/MySQL/Nextcloud Log zu finden sein.


    Zum strict mode:

    Zunächst sollte dies einmal geprüft werden:

    Shell-Script
    1. /usr/local/pd-admin2/bin/mysql -u root -p$(cat /opt/pdadmin/etc/mysql_rootpw.conf ) select @@sql_mode | grep -E 'ONLY_FULL_GROUP_BY|STRICT_TRANS_TABLES'

    Wenn dies keine Ausgabe gibt, ist der strict mode bereits deaktiviert.


    Dann muss man unter /home/mysql/my.cnf dies entsprechend setzen. Ich habe noch MySQL 5.5, aber dies sollte passen:

    Code
    1. [mysqld]
    2. sql_mode=IGNORE_SPACE,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

    Nach Änderung einmal

    Code
    1. svc -du /service/mysqld

    ausführen.


    Referenz: https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

    Ich habe den Pfad zur PHP Binary in der PATH Variable in ~/.bashrc angegeben. Soweit ich weiß trägt pd-admin dies automatisch in die .bash_profile ein, wenn der Nutzer die PHP CLI im Endkundenbereich konfiguriert wird.


    Ein Alias wird dabei nicht zum gewünschten Ziel führen.

    Wozu?


    Die Extensions sind keine Executables. Wozu also Ausführrechte?


    Die Standardberechtigung für Dateien ist 644. Somit ist mit der Datei alles gut. Nur weil alle anderen Dateien Ausführrechte haben, muss dies ja nicht richtig sein 😉


    Ich hab jedenfalls keine Probleme mit 644er Berechtigungen bei Extensions.

    Also heisst das Abwarten und Tee trinken???

    Das halte ich für eine schlechte Idee. Die Situation ist in meinen Augen nicht abschließend geklärt.


    Für mich stellt es sich so dar, dass die Mailboxen rudi@ullmert.de und jens@ullmert.de kompromittiert wurden und massenhaft Spam verschickt haben. Es ist nicht klar, ob weiterhin Spam in der Mail-Queue ist und versucht wird zugestellt zu werden. Zudem werden durch Löschung der Mailboxen weitere Bounce-Mails generiert. Der Ablauf:

    1. Spam-Mail wird versandt
    2. Empfänger lehnt Mail ab, weil
      1. Empfänger nicht vorhanden
      2. Mail als Spam erkannt
      3. Server auf Blacklist
    3. Empfänger schickt Bounce-Mail mit der Info
    4. Mail kann nicht zugestellt werden, da Mailbox auf vpscobra.service4it.com gelöscht (Sorry, no mailbox here by that name.)
    5. Es wird eine Bounce-Mail mit dieser Info verschickt
    6. Zurück zu Punkt 2 => Schleife

    Da das Problem nicht vollständig untersucht ist kann auch nicht ausgeschlossen werden, dass nicht doch noch eine Mailbox kompromittiert/gehackt ist.


    Mit gehackt ist übrigens nicht gemeint, dass da irgendwo ein Mensch sitzt und sich in 80er-Jahre-Manier "reingehackt hat". Eher war das Passwort zu schwach und wurde per Brute-Force-Attacken herausgefunden. Oder ein Trojaner hat die Zugangsdaten auf einem PC/Tablet/Smartphone ausgespäht. Auch kann es sein, dass Mail-Adresse und das gleiche Passwort bei einem Drittanbieter hinterlegt waren und dieser z.B. ein Datenleck hatte. Die Passwörter sollten daher nicht mehr verwendet werden.


    Hinzu kommt, dass man vielleicht nach und nach nicht mehr auf Spam-Blacklists landet, jedoch durch die Vielzahl an Bounces auf Blacklists wie backscatterer.org landet. Wenn hier nur abgewartet wird, kann man am Ende nur noch mehr Arbeit/Probleme bekommen. Zudem bedeutet abwarten, dass der reguläre Mail-Verkehr solange auch gestört ist. Ich weiß auch nicht in wie weit abwarten nicht auch fahrlässiges Verhalten ist.

    ... UND WAS HEISST DAS NUN ?

    Ich habe ein wenig den Eindruck, dass hier eine fertige Copy & Paste Lösung gesucht wird. Diese kann man hier aber nicht bieten. Das System ist unbekannt, da man kein Zugriff darauf hat. Die gegeben Informationen sind teils unvollständig. Daher können nur Hinweise und Tipps gegeben werden.


    Man sollte sich mit /usr/local/pd-admin2/sbin/qmHandle und /usr/local/pd-admin2/sbin/qmail-remove befassen. Führt man die Befehle ohne Argumente aus, erhält man eine kleine Hilfe. Zudem sollte man sich auch mit der Analyse von Mail-Header [1] [2] auseinander setzen. Ist man sich unsicher kann der Mail-Header hier gepostet werden. Hier mal zwei Beispiele, die bei Spam-Versand meist vorkommen:


    Received: from unknown (HELO ?127.0.0.1?) (info@beispiel.de@1.2.3.4) => info@beispiel.de@1.2.3.4 bedeutet, es wurde sich von der IP 1.2.3.4 mit dem Benutzernamen info@beispiel.de angemeldet. Hier kann auch die LoginID, anstelle der Mail-Adresse stehen.


    X-SCRIPT-FILENAME: /home/loginid/www.beispiel.de/skript.php => Hier wurde die Mail durch skript.php generiert. Dies kann ein Kontaktforumlar sein, eine Sicherheitslücke in der Anwendung oder auch eine kompromittierte Datei.


    Es sollte dann, wie zuvor angeführt, qmail-send gestoppt werden, damit keine weiteren Mails versandt werden. Nun muss man mit qmHandle die Mail-Queue sichten. Mails mit "Subject: failure notice" oder "From: MAILER-DAEMON@vpscobra.service4it.com" können dabei ignoriert werden bzw. imho sogar direkt mit qmail-remove aus der Mail-Queue entfernt werden. Dies sind Bounce-Mails. Damit wird man vermutlich auch schon ein Großteil an Mails wieder los. Wenn dann noch Spam-Mails vorhanden sind, muss man den Mail-Header analysieren. Ziel sollte es sein, dass in der Mail-Queue keine oder nur noch reguläre/legitime Mails vorhanden sind.

    Ich sehe gerade, dass ich ein Copy & Paste Fehler in meinem Post hatte. Es wurde "(rudi@ullmert.de@(" doppelt eingefügt. Mit -p gibt man ein Zeichenfolge an.

    Man muss sich zunächst Mails in der Queue anschauen und anhand des Mail-Headers schauen wie die Mail eingeliefert wurde. Bei dem Beitrag oben wurde die Mail über die Mailbox rudi@ullmert.de eingeliefert. Daher auch dies als Angabe bei -p

    Die Frage ist ja weiterhin "wie wird der Spam eingeliefert?".


    Anhand der letzten Beiträge schien es ja eine kompromittierte Mailbox zu sein. Dies halte ich auch weiterhin für am wahrscheinlichsten. Die Mail Queue enthielt zuletzt über 50.000 Mails. Diese gilt es nun zu sichten. Hat man identifiziert wie die Mail(s) eingeliefert wurde(n), kann man den Zugang sperren. Anschließend löscht man sämtliche Mails aus der Queue, die so eingeliefert wurden.

    Code
    1. Received: from unknown (HELO ?127.0.0.1?) (rudi@ullmert.de@200.49.55.66)

    hier sieht man es. Die Mailbox wurde gehackt. Als erstes das Passwort der Mailbox ändern. Das Passwort sollte nicht mehr verwendet werden.

    Danach sollte

    Code
    1. svc -d /service/qmail-send

    ausführen. Im nächsten Schritt bereinigt man die Mail-Queue. Mit

    Code
    1. /usr/local/pd-admin2/shin/qmail-remove -p "(rudi@ullmert.de@(rudi@ullmert.de@"

    Damit bekommt man eine Liste mit Treffern. Hängt man -d hinten dran, werden die Treffer gelöscht.

    Achtung!

    Bevor man löscht muss sichergestellt sein, dass qmail-send gestoppt wurde. Dies kann man mit

    Code
    1. ps aux | grep remote

    Hier darf es keine Treffer geben. Erst wenn es keine remote Prozesse mehr gibt, dürfen die Mails gelöscht werden. Ansonsten gibt's mit qmail Probleme.