Beiträge von tbc233

    Das hat nichts mit Deinen SSL Zertis zu tun, hier wird über das Zertifikat von database.clamav.net gemeckert.


    Bei einem Test auf einem meiner Server konnte ich das Problem jetzt nicht nachvollziehen. Bist Du mit der Serverumgebung soweit halbwegs up to date?

    Eventuell statt localhost mal 127.0.0.1 versuchen. Port mal 25 statt 587 probieren.


    Wenn das alles keine neuen Erkentnisse bringt, würde ich nicht länger nach dem Fehler suchen, sondern die Transportmethode von smtp auf den sendmail Befehl oder php-mail() umstellen, Gambio kann das soweit ich mich erinner.

    Der Cron Eintrag ci_dhe_params.sh ruft das Skript /usr/local/pd-admin2/share/mkdhparams auf, welches den Fehler bringt, dass /usr/local/bin/certtool nicht existiert.
    Warum lautet die IF-Bedingung 'test "gnutls" = "openssl"', welches nie Wahr sein kann
    Warum wird sich darauf verlassen, dass es /usr/local/bin/certtool gibt?

    Bei mir kommen jetzt auch Mails vom cron aufgrund des regelmäßigen Aufrufs von /usr/local/pd-admin2/share/mkdhparams und der Ausgabe dass es /usr/local/bin/certtool nicht gibt. Ich bin mir ziemlich sicher dass dieses Script vorher jahrelang problemlos durchgelaufen ist.


    Bin jetzt unsicher was der genaue Impact davon ist, dass das Script abbricht und ob ich certtool über die lokale Paketverwaltung installieren soll.

    Sieht mir bisher nach einem ganz normalen Spamversand unter Nutzung einer Deiner Domains aus. Tendentiell sieht es derzeit so aus als wäre das nicht über Deinen Server gelaufen.

    Durch sowas muss jeder der eine Domain hat alle Zeitlang mal durch. Sehr lästig, keine Frage. Ein SPF Record für die Domain kann ein bisschen helfen, führt er doch dazu dass viele Mailserver das ursprüngliche gefälschte-Absender Mail erst gar nicht annehmen.

    Erwähnenswert ist vielleicht diese Geschichte unter "Mitigation"

    Zitat
    Code
    qmail can be protected against the RCE (Remote Code Execution) by
    configuring the file "control/databytes", which contains the maximum
    size of a mail message (this file does not exist by default, and qmail
    is therefore remotely exploitable in its default configuration).


    Im databytes File wird ja ganz allgemein die maximale Größe einer Nachricht definiert, die qmail annimmt. Im Auslieferungszustand existiert diese Datei nicht. Das heißt, selbst ein 20GB Mail würde angenommen werden. Diese Datei sollte man daher meiner Meinung nach ohnehin anlegen um zu vermeiden dass irgendein Spezialist ein riesen Mail spoolt. Ein Punkt, den wir pd-admin Freunde tendentiell ohnehin etwas verschnachlässigen.

    Ich habe mir https://www.qualys.com/2020/05…-code-execution-qmail.txt mal angesehen. Mit meinem qmail Halbwissen find ich es etwas komisch.


    qmail-smtpd sind mal ziemlich sicher speichermäßig begrenzt aufgrund der tcpserver Aufrufe mit softlimit. Nun meinen die Entdecker dieser Lücke, dass auch qmail-local davon betroffen ist. Das ist ja eigentlich nur das Tool das die Nachrichten lokal zustellt. Ich persönlich denke nicht, dass es im pd-admin Setup speichermäßig begrenzt ist, andererseits ist mir derzeit nicht klar, wie jemand qmail-local so viel Speicher zumuten könnte.

    Okay, /usr/local/pd-admin2/bin/checksmtppasswd ist ja in Wirklichkeit ein Link auf /bin/checksmtppasswd. Das hat bei mir einen Zeitstempel von heute, stammt also aus dem SE Paket und blieb auch dort trotz meines Downgrades. Es muss also wohl eher ein Zusammenhang mit dem in der Fehlermeldung bemängelten mysql.so oder dynaloader.pm sein...

    Dankeschön.


    Jetzt habe ich doch was im syslog aus dem betroffenne Zeitraum gefunden:


    Code
    Apr 30 10:11:40 smtpd: 1588234300.875797 install_driver(mysql) failed: Can't load '/usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux/auto/DBD/mysql/mysql.so' for module DBD::mysql: libgcc_s.so.1: failed to map segment from shared object at /usr/local/pd-admin2/lib/perl5/5.10.1/x86_64-linux/DynaLoader.pm line 200.
    Apr 30 10:11:40 smtpd: 1588234300.875844 at (eval 5) line 3
    Apr 30 10:11:40 smtpd: 1588234300.875858 Compilation failed in require at (eval 5) line 3.
    Apr 30 10:11:40 smtpd: 1588234300.875871 Perhaps a required shared library or dll isn't installed where expected
    Apr 30 10:11:40 smtpd: 1588234300.876091 at /usr/local/pd-admin2/bin/checksmtppasswd line 16

    Ich werd mal auf jeden Fall die Stunnel Umstellung machen.

    Wenn ich alles richtig verstehe, dürfte diese ja auch bei dem 4-342, auf dem ich jetzt wieder zurück bin, keine Probleme machen. Dann probier ich meine pd-admin2 Ordner nochmal rück- rück-umzubenennen. Vielleicht hat das ja alles doch irgendwie miteinander zu tun.

    qmail-smtpd: qmail-smtpd/VC started


    bedeutet ja, dass zumindest der Dienst läuft.

    Korrekt, das würde ich auch bestätigen weil eingehende Mails soweit funktioniert haben und an die Mailboxen zugestellt wurden.



    Ich würde zunäcsht einmal mit telnet (Port 25) bzw. openssl (Port 465) versuchen händisch eine Mail einzuliefern. Dabei muss es dann ja eine Fehlermeldung geben.

    Das habe ich probiert als der Zustand bestand, jedenfalls die unverschlüsselte Variante auf Port 25. Der Dialog ging durch bis zum Schluss, wenn auch ohne Auth, weil ich auf die Schnelle nicht wusste wie ich ein smtp-auth in telnet machen kann.

    Ganz allgemein funktionierte es nur dann anscheinend nicht, wenn smtp-auth im Spiel war.

    Hätte eben einen Server auf 4-534 upgegradet. (vorher 4-0.342).


    Danach funktionierte der Versand via SMTP-Auth nicht mehr. Weder unverschlüsselt auf Port 25, noch verschlüsselt auf Port 465. Ich bekam dazu keine Meldungen im mail.log oder sonst wo, es kam einfach nur "qmail-smtpd: qmail-smtpd/VC started" und im Mailclient eine Meldung dass die Verbindung zum SMTP Server verloren ging.


    Eingehende Mails die von anderen Server daher kamen, wurden hingegen problemlos in die Mailboxen zugestellt.


    Aufgrund leichter Panik und absolut keiner Idee wo zu suchen beginnen ich könnte, habe ich das /usr/local/pd-admin2 Verzeichnis wieder auf die vorige Version rück-umbenannt. Damit geht es nun wieder.
    Möchte zu einem späteren Zeitpunkt wenn weniger User online sind die Mail benötigen, dann nochmal weiter rückstellen und schauen.


    Allerdings weiterhin unsicher wie ich das debuggen könnte. Jemand eine Idee?