Beiträge von tbc233

  • merkwürdige symptome beim den ankommenden mails

    Mir fallen hier zwei Dinge ein aus der Vergangenheit: Namensauflösung und korrupte Bayes Datenbank.

    Flutscht die Namensauflösung auf dem Host? Ansonsten kann es zu Timeouts bei Blacklist Abfragen etc. kommen.

    Auch eine beschädigte Bayes Datenbank kann Timeouts verursachen. Wäre interessant, die bestehenden Bayes DB Dateien mal weg zu moven (vorher Serverumgebung stoppen und dann wieder starten). Dann wird eine neue angelegt. Ich erinnere mich aber grad um die Burg nicht, wo diese Dateien liegen.

  • Alma Linux 10 - i686 Pakete

    Ich hab mir grad einen Alma Linux 10 Server gebaut und wollte pd-admin installieren. Hab mir ja schon ganz gut notiert, welche Pakete ich so brauche vorher und dabei ist mir aufgefallen dass die .i686 Pakete fehlschlagen (zum Beispiel glibc.i686, ncurses-libs.i686 etc). Und tatsächlich, Alma Linux Website sagt

    Zitat

    Starting with AlmaLinux OS 10.0 there are no longer 32-bit (i686 architecture) packages.

    Nun hab ich mal testweise probiert glibc-2.28-251.el8_10.25.i686.rpm händisch runterzuladen und zu installieren, aber hier wird gleich gemeckert dass andere Pakete fehlen, sieht für mich so aus als würde ich hier in eine Abhängkeitshölle kommen wenn ich diesen Weg gehe.

    Muss ich den Server platt machen und auf Alma 9 gehen, oder hat jemand eine Idee?

  • Custom Mod_Security Rules

    Zitat von tobiw

    Wie seht ihr das?

    Ich komm gar nicht so weit zu solchen Überlegungen, weil wie gesagt, mein Hauptproblem ist dass mod_security eine Serverweite Einstellung ist. Kommt auch nur ein Projekt auf dem Server, warum auch immer, nicht mit mod_security zurecht, ist es für den ganzen Server gestorben, weil ich es dann abdrehen muss. Das ist mir bisher relativ oft passiert. Daher würde ich mir eine Schaltung je Account wünschen.

  • Custom Mod_Security Rules

    Entschuldige, ich hatte in Deinem Eingangspost leider überlesen dass Dir das schon bekannt war mit der Template Datei. Leider hab ich hier dann auch keine weitere Idee derzeit. Vielleicht als Wunsch einmelden. Bei der Gelegenheit fände ich es auch fein, wenn man mod_security je Account aktivieren könnte und nicht nur je gesamten Server.

  • Custom Mod_Security Rules

    Ich weiß jetzt nicht ob es hilft, weil ich von mod_security noch nicht so viel Ahnung habe. Aber ganz allgemein gesprochen, wird zur Generierung der httpd.conf die /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template herangezogen. Dort kannst Du durchaus eigene Konfigurationen einfügen.

    Schwierig wird es halt immer nur dann, wenn Du eigene Konfigurationen hinzufügen willst zu den automatischen generierten Einträgen.

  • Too many domains.Type: free

    Ich bin jetzt nicht exakt über den pd-admin Code informiert, aber ich kenne die Beobachtung bei Servern im Dual Betrieb. Zugriff über ipv4 in Ordnung, über ipv6 keine Lizenz. Daher gehe ich davon aus dass die Server-IP die angesprochen wird, ausgewertet wird. Mir ist das selbst in einem Fall jahrelang nicht aufgefallen, weil mein eigener Internetzugang nicht ip6 fähig war. Daher hab ich immer über ip4 zugegriffen und hab nie was von dem Problem gemerkt. Bis dann mal ein Kollege hinter einem ip6 Internetzugang sich gemeldet hat dass er den Lizenzfehler bekommt.

    Zitat von mkpd15

    Ich verstehe es dennoch nicht, weil der Server in dieser Konfiguration schon ewig läuft und nie Probleme gemacht hat.

    Wie gesagt, vermutlich weil Du über ip4 zugegriffen hast.

  • Too many domains.Type: free

    Ein Aufruf der pd-admin Oberfläche über ipv6 führt zum Licence Type free Problem, das war schon immer so. Das liegt daran, dass Lizenzen nur auf IPv4 Adressen ausgestellt werden und wenn ein Client die ipv6 Adresse des Servers anspricht, passt das quasi nicht zusammen. Wenn Du sagst dass es schonmal funktioniert hat, dann hast Du da wahrscheinlich mit einem IPv4 Client zugegriffen und nun wenn es nicht funktioniert mit IPv6.

  • Code Einschleusung durch Mail Attachment Dateinamen

    Ich hab grad von diesem Mist hier gelesen

    Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection
    Phishing emails with RAR archives exploit Linux filename injection to deliver VShell backdoor, bypassing antivirus defenses
    thehackernews.com

    Hier wird quasi durch einen speziellen Dateinamen eines Mailanhangs bösartiger Code zur Ausführung gebracht, in dem darauf gehofft wird, dass der Dateiname von irgendeinem Shell Kommando verarbeitet wird.

    Ich frage mich, ob unser Simscan/Clamav Setup hier anfällig sein könnte.

  • pd-admin in VM umgezogen --> neue IP

    Die IPs in der domains Tabelle (oder vhosts, bin mir grad nicht sicher) der vadmin datenbank müssen noch auf die neue ip geändert werden. Ich mach das immer direkt in der Datenbank, falls Du auf das Administrator Interface kommst, sollte es auch genügen es unter Reseller -> IPs anzupassen. Dann /opt/pdadmin/bin/httpd_vhosts.pl ausführen.

  • Mailfunktion funktioniert nicht

    Wordpress kann bei der pd-admin Serverumgebung problemlos Mails versenden, im Normalfall ohne irgendwelche Zusatz Plugins oder ähnliches.

    Ich würde daher im ersten Schritt mal den Mail Log des Servers beobachten, während Wordpress ein Mail schickt. Dann sieht man mal, ob hier überhaupt was ankommt.

  • 553 5.7.3 A secured connection (either via StartTLS or SMTPS) is required for this sender.

    Zitat von Twilo

    Was ich mich frage: Warum erstellt qmail die Datei und versucht es nicht einfach jedes Mal aufs Neue?

    Meine Interpretation: qmail hat sonst keinen Mechanismus um sich die TLS Probleme auf der Gegenseite zu "merken". Also diese Datei wird ja nicht nur für künftige weitere Mails angelegt, sondern auch für das selbe Mail das nach dem verpatzten Zustellversuch in der queue verbleibt. Gäbe es diese Strategie nicht, würde das Mail solange in der queue verbleiben bis das Problem auf der Gegenseite behoben ist. Erst diese Datei führt überhaupt erst dazu dass es unverschlüsselt probiert wird.

  • 553 5.7.3 A secured connection (either via StartTLS or SMTPS) is required for this sender.

    Aus meiner Sicht ist das ein Folgefehler. Das nachfolgende ist ein bisschen aus meinen Erfahrungen zusammengereimt, sollte ich Quatsch reden, bitte mich gerne korrigieren.

    qmail versucht grundsätzlich immer, eine verschlüsselte Verbindung aufzubauen. Sollte das mit einem bestimmten gegnerischen Server nicht klappen (unvereinbare TLS Versionen zum Beispiel, aber auch andere Gründe), wird eine Datei unter /usr/local/pd-admin2/var/qmail-tls-error/ mit dem Namen der Empfängerdomain angelegt und dadurch weiß qmail dann, dass diese Domain das nächste mal unverschlüsselt kontaktiert werden soll. Dieses Verzeichnis wird meiner Beobachtung nach dann auch regelmäßig bereinigt, damit es immer wieder mal erneut verschlüsselt probiert wird.

    Nun scheint die Situation bei Dir so zu sein, dass eben hier schon mal ein verschlüsselter Dialog mit der Gegenseit schief gegangen ist. Daher existiert eine entsprechende Datei unter /usr/local/pd-admin2/var/qmail-tls-error/ und qmail probiert es erst gar nicht verschlüsselt. Da nun die Gegenseite aber so konfiguriert ist, dass sie nur verschlüsselte Verbindungen annimmt, entsteht hier quasi eine Patt-Situation.

    Ich würde an Deiner Stelle mal diese Datei löschen, dann sollte es qmail mal wieder verschlüsselt probieren. Dann kannst Du mit einem Testmail im Log beobachten, was das grundliegende Problem ist (vielleicht war es ja auch nur temporär). Also warum die gegenüberliegende Domain überhaupt in diesem error Verzeichnis gelandet ist.