Beiträge von Sumeragi

    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.

    Was sagt denn

    Shell-Script
    1. /usr/local/pd-admin2/sbin/qmHandle -l

    Damit kann man sich die Mail-Queue ansehen. Dort kann man sich dann einzelne Mails heraus picken und mit

    Shell-Script
    1. /usr/local/pd-admin2/sbin/qmHandle -v12345

    sich die Mail anschauen. Für 12345 muss die Nummer/ID aus der Liste genommenen werden.

    Anhand der Mail-Headers kann man dann die Zustellung sehen. Dort sieht man dann auch ob die Mail z.B. per Skript oder per smtp-auth eingeliefert wurde.

    solange nicht klar ist woher es kommt sollte der SMTP Dienst deaktiviert werden. Wird dieser nicht gestoppt, landet man auf immer mehr Blacklists. Und das Delisting ist dann immer zusätzlich Aufwand.


    Es muss auch kein Kontaktformular sein. Eine Sicherheitslücke in einem Plugin reicht aus. Dazu sollte man sich das access_log anschauen. Meist hat man eine IP, welche viele POST Anfragen schickt.


    Ansonsten kann es auch eine kompromittierte Mailbox sein. Dann sollte eigentlich das Mail-Submission-Limit greifen... Aber hab schon gesehen, dass dieser Wert extrem hoch gesetzt wurde 🤷

    In dem Zusammenhang muss es dann auch nicht unbedingt nur Port 25 sein. Es kann auch über Port 465 und 587 eingeliefert werden.


    Die Ausschnitte aus den Logs sind für mich leider unbrauchbar. Ich konnte keine zusammenhängende Zustellung sehen. So hat man ein Indiz auf ein mögliches Problem. Große Logs sollten dann auch besser per txt Datei als Anhang gepostet werden. Macht das Lesen des Threads angenehmer 😉


    btw gehört dies eher in einen eigenen Thread, da es wohl nichts mit der Sicherheitslücke zu tun hat.

    Der Befehl du kann glaub ich nicht sortieren. Dies ginge höchstens mit

    Shell-Script
    1. du -h | sort -rh

    Ich nutze gerne

    Shell-Script
    1. find / -type d -exec du -Sh {} \+ | sort -rh | head -30

    Man darf sich nur nicht von den Fehlern mit /proc irritieren lassen.


    Ich würde aber Mal bei /usr/local und /var/log schauen. Das sind bei mir oft die ersten Stellen, wo schnell Mal Platz verbraucht wird.

    Ich vermute, bei Aktivierung der Weiterleitung auf HTTPS wird dies nur für die Subdomain aktiviert. Nicht aber für die Domain ohne www. Müsste man Mal in der httpd.conf schauen.


    Ich habe immer bei meinen Domains folgenden Eintrag in der htaccess stehen:

    Code
    1. RewriteEngine On
    2. RewriteCond %{SERVER_PORT} !^443$
    3. RewriteRule (.*) https://www.domain.de/$1 [L,R=301]

    Wenn dies bei Ihnen eingetragen wird, sollte auch domain.de weiterleiten.

    Wie lange läuft die Ausführung des Befehls? Der cronjob wird jede Minute ausgeführt. Vermutlich kommt es durch Mehrfachausführung zu den Fehlern.

    Es sollte der cronjob um flock erweitert und somit die Mehrfachausführung verhindert werden.