Beiträge von Sumeragi

    Der Symlink von MySQL ist auf jeden Fall korrekt.

    Wenn ich data.inf und data2.inf nach "/var/mysql" grepe, ist in der data.inf die gleiche Zeile wie bei Ihnen, in der data2.inf wird nichts gefunden. Für mich erschließt sich daraus aber noch nicht wo der Dateitypkonflikt sein soll.

    Dies kann ich bestätigen.


    Schritte zur Reproduktion:


    Administrator: Einstellungen => Serverkonfiguration => Hilfe

    Code: Fehlermeldung Browser Konsole
    jquery-3.5.1.min.js:2 Uncaught TypeError: e.indexOf is not a function
    at S.fn.load (jquery-3.5.1.min.js:2:84831)
    at modal_show_help_ (pdscript.js:52:16)
    at HTMLAnchorElement.onclick (administrator.cgi?todo=customers.main:72:144)
    S.fn.load @ jquery-3.5.1.min.js:2
    modal_show_help_ @ pdscript.js:52
    onclick @ administrator.cgi?todo=customers.main:72

    Endkunde: Datenbanken => Übersicht => Hilfe

    Code: Fehlermeldung Browser Konsole
    jquery-3.5.1.min.js:2 Uncaught TypeError: e.indexOf is not a function
    at S.fn.load (jquery-3.5.1.min.js:2:84831)
    at modal_show_help_ (pdscript.js:52:16)
    at HTMLAnchorElement.onclick (customer.cgi?todo=db.main:72:127)
    S.fn.load @ jquery-3.5.1.min.js:2
    modal_show_help_ @ pdscript.js:52
    onclick @ customer.cgi?todo=db.main:72

    Der Fehler ist beim Administrator und Endkunde identisch. Die Hilfe stammt übrigens aus PDA und hat somit nichts mit der Serverumgebung zu tun.

    Das Datumsformat kann nicht angepasst werden.


    Den Fehler kann ich bei mir nicht reproduzieren. Ich verwende aktuell PDA 4.101, SE 8-0.408 und Oracle Linux.


    Für eine mögliche Unterstützung wären mehr Details zu dem Fehler wichtig, wie eben


    - Betriebssystem

    - pd-admin Version

    - Version der Serverumgebung


    Angaben "Neuste" ist dabei nicht hilfreich. Ich meine im Forum gab es dafür auch irgendwo eine Vorlage... Bei Fehlermeldungen ist eine genaue Schritt-für-Schritt Anleitung zudem sehr hilfreich. Dann können andere dies gezielt nachstellen und so helfen.

    Ich hab es ganz einfach mit einem Proxy gelöst:

    Dadurch wird auch das Problem mit der Lizenz gelöst.


    Der vhost für Port 80 leitet direkt auf HTTPS weiter. Da steht also nicht viel drin.

    In der aktuellen SE fehlt die index.html unter /ist/local/pd-admin2/htdocs dadurch kommt es zu dem Forbidden Fehler, da keine index.* Datei vorhanden ist und ein list directory nicht erlaubt ist.

    Dies führt jedoch zu einem Bug in pd-admin. Wenn man nach "Einstellungen" => "Indexseite des Webserver" geht kommt ein Fehler:

    Code
    Software error:
    stat </usr/local/pd-admin2/htdocs/index.html> failed: No such file or directory at /opt/pdadmin/www/administrator/administrator.cgi line 8271
    For help, please send 

    Lösen lässt sich das ganz einfach, in dem man die index.html aus einem Backup einer älteren SE zurück kopiert :)

    Frage zu den cron jobs:

    Warum muss man die letsencrypt jobs manuell hinzufügen?
    Erledigt das nicht schon ein andes Script implizit mit?

    Bei mir ist die letzte Installation schon etwas her, aber da wurden die Cronjobs für let's encrypt automatisch gesetzt. Musste nichts manuell festlegen.


    Und braucht man wirklich ein eigenes Script wie regenerate_mail_certs.sh oder ist /opt/pdadmin/bin/update_host_certificate.sh nicht eigentlich auch "cronfähig"

    Das update_host_certificate.sh Skript kann einfach per Cron ausgeführt werden. Mache ich mittlerweile auch so.


    Der Fehler im Script /usr/local/pd-admin2/share/mkdhparams habe ich im anderen Thread zwar gefixed,
    aber die erzeugte Datei wird nach meinem Kenntnisstand nur von Courier-IMAP genutzt.
    Kann also wirklich (auch aus pd-admin) entfernt werden.

    Ja, der Cronjob kann weg, da dieser bei aktuellen pd-admin Versionen nicht mehr benötigt wird.

    Richtig, die Option TLSv1.3 kennt Dovecot 2.2 nicht. Dies wird erst mit Dovecot 2.3 eingeführt. Ebenso wird ssl_min_protocol erst mit Dovecot 2.3 eingeführt. Dies ersetzt ssl_protocols.


    TLS 1.3 kann zwar explizit nicht angegeben werden, wird aber unterstützt. Man kann

    Code
    ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384

    setzen. Dann hat man nur noch ECDHE Schlüssel in Verwendung und ist nicht mehr auf ssl_dh_parameter_length angewiesen. Dies sollte dann mehr einer "modernen" Konfiguration entsprechen. Elliptic Curve Schlüssel haben den Vorteil, dass diese weniger CPU-intensiv sind. In der Dovecot Doku wird auch empfohlen DHE Schlüssel zu deaktivieren.

    apropos modern und Dovecot 2.2 …

    # unfortunately, Dovecot 2.2 and OpenSSL 3.0 does not support the modern configuration

    Ich habe noch nicht herausgefunden wo es da eine Inkompatibilität gibt. Denn stand jetzt ist, dass die Serverumgebung mit Dovecot 2.2 und OpenSSL 3.0 ausgeliefert wird. Und es funktioniert. Es kann auch TLS 1.3 verwendet werden.


    sorry beim Kopieren ist

    Code
    ssl_dh=</etc/ssl/certs/dh_params4096.pem

    leider auf der Strecke geblieben ?(

    Wenn ich die Dovecot Doku richtig lese unterstützt Doveecot 2.2 "ssl_dh" nicht. Wirft das keinen Fehler oder Warnung aus?

    Im Grunde betrifft es ja nur die Parameter "ssl" und "ssl_dh_parameters_length". Die anderen Parameter sind ja identisch.


    Einen größeren Wert bei ssl_dh_parameters_length muss man nicht setzen, wenn man keine DHE cipher suits konfiguriert. Ein Wert von 4096bit verzögert den (Neu)Start von dovecot und macht es nicht unbedingt sicherer. Eine höhere Sicherheit erreicht man durch die Nutzung von ECDHE cipher suits.

    Auch Mozilla schlägt bei intermediate Einstellungen nur 2048bit vor. Bei moderben Einstellungen entfällt dies, da nicht mehr relevant: https://wiki.mozilla.org/Security/Server_Side_TLS

    Mozilla SSL Configuration Generator

    Auch wenn dieser Thread schon etwas länger zurück liegt, dachte ich Teile ich kurz mein Wissen :)


    Änderungen müssen unter /usr/local/pd-admin2/dovecot-2.2/etc/dovecot.tmpl/ vorgenommen werden. Dann bleiben diese auch nach einem SE Update bestehen ;)

    Zunächst sollte man sich einmal den Aufbau des Access Logs anschauen. Ich gehe davon aus, der Aufbau wirde nicht verändert und ist wie bei Auslieferung der SE. Der Teil mit den SQL Anweisungen steht im Referer Teil des Logs. Es wird somit nicht direkt ein Skript aufgerufen und versucht dort eine Injection durchzuführen. Ich nehme an, der Angriff zielt auf Anwendungen ab, welche den Referrer auswerten. Dies können Anwendungen wie Matomo oder auch (WordPress) Plugins für Statistiken sein.


    Ich habe in meinen Logs ähnliche Einträge gefunden. Teilweise war auch Code im Teil des User Agents enthalten. Hier zwei Beispiele:

    Code
    dev.xxxxx.de 216.131.114.216 - - [04/Jul/2022:12:06:36 +0200] "GET / HTTP/1.1" 200 44 "NkUXTPoA')) OR 247=(SELECT 247 FROM PG_SLEEP(15))--" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4512.0 Safari/537.36"
    
    dev.xxxxx.de 216.131.114.216 - - [04/Jul/2022:12:06:38 +0200] "GET / HTTP/1.1" 200 44 "https://www.google.com/search?hl=en&q=testing" "if(now()=sysdate(),sleep(15),0)"

    Interessant ist bei mir, dass URLs aufgerufen wurden, welche nicht konfiguriert sind und man nur die Standardseite des Apaches erreicht. In meinem Fall sieht es daher mehr nach der Suche einer Lücke aus.


    Bedenklich ist tatsächlich, dass hier die Angabe von usrdb_* gemacht wird. Wie tbc233 schon schrieb, scheint der Angreifer über das Wissen der Datenbanknamen zu verfügen. Dies muss nicht heißen, dass der Server/Endkunde eine Sicherheitslücke hat. Wenn die Daten auf einem kompromittierten PC liegen, kann dieser auch für einen Leak verantwortlich sein. Dennoch sollte man sich den Endkunden genauer anschauen.