Beiträge von Sumeragi

    Ich denke nicht, dass es an der Python Version liegt. wenn alles über den Packetmanager installiert wurde, sollten alle notwendigen Abhängigkeiten vorhanden sein.

    Gibt es mit anderen Filtern die gleichen Probleme? Tritt der Fehler auch mit dem qmail Originalfilter, ohne die hinzugefügte Zeile, auf? Wegen

    IndexError: string index out of range

    nehme ich eher an, dass etwas mit dem Filter nicht passt.

    Der Fehler sieht mir danach aus, dass der Filter nicht korrekt verarbeitet werden kann. Vermutlich wird in der pdsmtp-qmail.conf ein Fehler sein. Oder irgendwas inkompatibel zu der fail2ban Version sein. Wie sieht denn die pdsmtp-qmail.conf aus?


    Davon mal ab liefert Fail2ban bereits eine Filterdatei für qmail mit (filter.d/qmail.conf). In meinen Augen muss man sich gar nicht die Mühe machen und eine eigene Datei erstellen. Es ist viel einfacher die vorhanden Filter zu erweitern. Einfach den jeweiligen Filter von .conf in .local kopieren und editieren. So ist die Konfiguration bei Updates sicher. Dieses Vorgehen wird auch von den Entwicklern empfohlen.


    Ich würde daher einmal die Filterzeile

    Code
    User [-/\w]+.*(?:[a-z]{2,6}): smtp-auth login failed from <HOST> \(no such user\)

    in die kopierte qmail.local einfügen und damit fail2ban-regex ausführen.

    Da hat wohl wer versucht Mails ohne smtp-auth auf Port 587 einzuliefern. Die Zeile

    Jan 5 06:26:14 nyx pdadmin[24054]: User rtc: smtp-auth login failed from 103.151.122.30 (no such user)

    wird tatsächlich nicht von fail2ban beachtet. Unter /etc/fail2ban/filter.d/qmail.conf gibt es standardmäßig nur die Filter

    Code
    failregex = ^%(__prefix_line)s\d+\.\d+ rblsmtpd: <HOST> pid \d+ \S+ 4\d\d \S+\s*$
                ^%(__prefix_line)s\d+\.\d+ qmail-smtpd: 4\d\d badiprbl: ip <HOST> rbl: \S+\s*$
                ^%(__prefix_line)s\S+ blocked <HOST> \S+ -\s*$

    Ich habe folgende Anpassung gemacht

    Code
    $ cd /etc/fail2ban/filter.d/
    $ cp qmail.conf qmail.local

    und in die qmail.local dann den Filter eingefügt

    Code
    failregex = ^%(__prefix_line)s\d+\.\d+ rblsmtpd: <HOST> pid \d+ \S+ 4\d\d \S+\s*$
                ^%(__prefix_line)s\d+\.\d+ qmail-smtpd: 4\d\d badiprbl: ip <HOST> rbl: \S+\s*$
                ^%(__prefix_line)s\S+ blocked <HOST> \S+ -\s*$
                User [-/\w]+.*(?:[a-z]{2,6}): smtp-auth login failed from <HOST> \(no such user\)

    anschließend kann dies mit fail2ban-regex getestet werden

    Code
    $ fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/qmail.local
    [schnipp]
    Results
    =======
    
    Failregex: 50 total
    |-  #) [# of hits] regular expression
    |   4) [50] User [-/\w]+.*(?:[a-z]{2,6}): smtp-auth login failed from <HOST> \(no such user\)
    `-
    [schnapp]

    Bei mir werden die smtp-auth Loginversuche unter /var/log/maillog geloggt. Es sollte bei fail2ban sichergestellt werden, dass das richtig Log verwendet wird.

    Man muss in der Serverkonfiguration awstats von statisch auf dynamisch stellen. Dann kann man nach der nächsten Generierung alle Monate anschauen und nicht nur den aktuellen Monat.

    Was mich verwundert, der Server läuft so seit bestimmt 10 Jahren … warum tritt das Problem jetzt auf einmal auf :/

    Wenn der Server 10 Jahre ound Updates laufen würde, wäre es sicherlich merkwürdig. Da aber sicherlich Updates eingespielt werden, können sich Bedingungen immer Mal ändern.

    Oder wurde ein SE Upgrade auf Version 4 durchgeführt? Dadurch wurden dann auf 64bit Bibliotheken umgestellt. Die vorherigen SE Versionen hatten 32bit Bibliotheken. Durch die Umstellung können dann höhere Limits notwendig sein, da durch 64bit auch größere Adressräume benötigt werden.


    Gleiches gilt dann für die segfault Fehler.

    tja, wie kann ermittelt werden, bei welchem Kunden das Problem aufgetreten ist? :/

    Das ist schwierig. Es könnte ebenfalls ein zu geringes Speicherlimit sein oder auch eine fehlerhafte PHP Extension.

    Ich habe bei mir in den logs auch ein, zwei Einträge gefunden. Jedoch keine Relation zu einem konkreten Aufruf oder anderen Fehlern.

    Man kann versuchen core dumps für PHP zu aktivieren und so den Fehlern auf die Spur zu kommen. So aus dem Stehgreif weiß ich jedoch gerade nicht wie dies zu konfigurieren ist. Man muss wohl zuerst core dumps im Kernel aktivieren. Bei FPM muss in der Konfiguration dann

    Code
    rlimit_core = unlimited


    angegeben werden. core dumps können dann mit gdb ausgewertet werden.

    Die Meldungen direkt auf der Konsole sind schon merkwürdig. Auf meinem VPS kann ich dies nicht beobachten und habe auch keinerlei derartige Log Einträge.

    Dec 22 11:49:49 mail qmail-smtpd: qmail-smtpd/VC started

    Hier wurde ein neuer qmail Prozess gestartet um, vermutlich, eine Mail einzuliefern. Bei Sekunde 51 gab es dann die segfault Meldung im messages log. Dies passt in meinen Augen zusammen. Bliebe weiterhin die Frage, wieso es dazu kommt.


    Bei der free Ausgabe sieht man bei Zeile -/+ buffers/cache und Spalte free, dass 19GB zur Verfügung stehen. Sieht also OK aus.


    Wie hoch ist denn das softlimit für den smtpd Dienst? Eventuell kann man dies testweise einmal erhöhen.


    smtp_greylist.pl wird bei "rcpt" ausgeführt (Datei /var/qmail/control/greylist). Man kann versuchen das Skript durch ein Wrapper Skript zu ersetzen. In dem Wrapper Skript wird dann ein strace von smtp_greylist.pl ausgeführt.

    Konnte das Problem denn schon nachgestellt werden? Was genau heißt "auf der Konsole"?

    KiB Mem: 24735704 total, 24502880 used, 232824 free, 952884 buffers
    KiB Swap: 9765620 total, 0 used, 9765620 free. 19200836 cached Mem

    Hier sind ~230MB frei und ~950MB als Buffer verfügbar. Der Großteil des Arbeitsspeichers ist jedoch belegt. Eventuell stehen dem Prozess tatsächlich nicht genug Ressourcen zur Verfügung. Wie sieht die "free -ht" Ausgabe aus? Da gar kein Swap genutzt wird, ist die swappiness auf dem Server eventuell auf 0 gestellt?


    Ich würde aber zuerst einmal versuchen das Problem nachzustellen. Vielleicht einmal den Zeitpunkt der Meldung im messages/system Log und dem maillog abgleichen. Vermutlich wird sich da die Einlieferung einer Mail finden. Dies muss man sich dann genauer anschauen. Wenn dies keinen Treffer gibt, dann einmal die Zustellung selber testen.

    Das komische ist halt, dass auf diesen Ports ja gar keine Zertis involviert sind und es bricht bei ihm trotzdem ab.

    Das ist so nicht richtig. Auf Port 25 und 587 ist starttls verfügbar. Bei #14 sieht man am zweiten Befehl, dass das Zertifikate mit openssl s_client und -starttls smtp auf Port 587 abgefragt werden kann. Starttls kann auf Port 25 von anderen Servern verwendet um Mails verschlüsselt einzuliefern.


    Die Verbindung auf Port 25 hatte nicht geklappt und brach direkt ab. Wie wir nun wissen war dies aber kein Zertifikatsproblem. Hier war die Ausgabe von mxtoolbox leider irreführend. Man hätte schauen können, ob der Dienst überhaupt korrekt läuft:

    Bash
    svstat /service/qmail-smtpd/

    Wenn der Dienste immer nur für wenige Sekunden läuft ist etwas faul. Dann kann man mit

    Code
    svc -d /service/qmail-smtpd/
    /service/qmail-smtpd/run

    den Dienst stoppen und direkt auf der Shell starten. Dies kann man auch machen wenn der Dienst normal läuft und man Meldungen direkt auf der Shell bekommen möchte. Wahrscheinlich hätte man da Fehler gesehen. Spätestens aber mit einem erneuten Test mit telnet.


    Bei mir läuft der Dienst übrigens problemlos mit einem softlimit von 125MB. Eine pauschale Empfehlung das Limit zu erhöhen ist in sofern als kritisch zu betrachten, da man keinerlei Informationen zum System hat. Das softlimit soll verhindern, dass zu viele Ressourcen verwendet werden. Ein zu hohes Limit bei zu geringen (freien) Ressourcen kann daher genauso zu Problemen führen wie ein zu geringes Limit. Ich würde daher die 256MB nur setzen, wenn dies auch notwendig ist.

    die erste hat 125000000 und die zweite 128000000

    aber beide auf den 128000000 angepasst

    qmail-smtpSd ist Port 465. Dies wurde hier gar nicht getestet.


    Es wurden auch keine Log Einträge bzgl. Speicherlimits gepostet. Auf Verdacht Werte erhöhen würde ich daher nicht.

    Es ist gar nicht genau klar was gemacht wurde und wo genau jetzt das Problem besteht. Fehlt nur das TLS Zertifikat bei dem Dienst? Wird dies ausgegeben?

    Also erst einmal sollte geklärt werden wo es jetzt genau Probleme gibt, denn...


    - in Titel steht dovecot

    - getestet wurde auf Port 25, 587 - dies ist qmail und nicht dovecot


    Laut der lsof Ausgabe laufen die Dienste auf Port 25 und 587.


    Ich würde einmal prüfen, ob ein TLS Zertifikat ausgegeben wird:

    Bash
    $ echo "" | openssl s_client -servername <server> -starttls smtp -connect <server>:25 | openssl x509 -noout -dates
    $ echo "" | openssl s_client -servername <server> -starttls smtp -connect <server>:587 | openssl x509 -noout -dates

    Offenbar sind telnet und nmap nicht installiert. Die Ausgabe hilft somit nicht...


    Anhand der curl Ausgabe sieht man aber, dass ein Apache mit einem 403 Forbidden Fehler antwortet. Eigentlich sollte dort die Standard Apache Seite "It work's" kommen...

    Es wurde bisher viel getestet, aber scheinbar noch nicht in den Logs geschaut. Ich würde dort einmal schauen. Insbesondere zu dem curl Aufruf sollte es einen Eintrag geben.

    tbc233:

    Ich hatte

    Das hat soweit geklappt.

    so verstanden, dass die Einrichtung eines Zertifikats geklappt habe. Wenn dies nicht geklappt hat, muss man natürlich weiter vorne anfangen und prüfen.


    Die interessante Frage wäre also nun welche Ausgabe man bei Ausführung von letsencrypt erhalten hat.