Beiträge von Sumeragi

    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.

    Die IPs aus den Beispielen stammen aus einem reservierten Netzbereich für Dokumentation. Das würde das Listing bei Spamhaus erklären. Ich würde daher sagen das ist Spam.


    Bei dem "passed thru" würde ich sagen, dass die Mail durchgelassen wird. Wenn es jedoch keine weitere Zustellung gibt und auch nichts in der Queue hängt, wird die Zustellung vermutlich doch abgelehnt worden sein. Bei mir konnte ich in den Logs keine derartigen Einträge finden. Kann dies somit nicht selber prüfen.

    Die Beschreibung ist ja, dass das Dashboard langsam sei und Untermenüs schnell gehen. Die Statistiken wären ja ein Untermenü.


    Auf dem Dashboard werden zwar Speicherplatzverbrauche angezeigt, dies geschieht aber nicht "live".

    Der Speicherplatzverbrauch für das Home Verzeichnis wird afaik aus /opt/pdadmin/tmp/du.txt ausgelesen. Die Datei wird per Cronjob aktualisiert. Die Mail Quota wird aus den dovecot Dateien ausgelesen. Also keine rechenintensiven Vorgänge.


    Ich konnte ein solches Verhalten bisher auch nicht beobachten. Da dies bisher kein anderer beobachten konnte, würde ich ein allgemeines Problem durch das Update ausschließen.

    Schön wäre es wenn man die genauen Schritte zur Reproduktion des Fehlers bekäme. Möglicherweise ist nicht jedem Nutzer bekannt was bei

    Wird das RCM-Update manuell via dem Shell-Skript im SE-Ordner gemacht

    zu tun ist. Dies erhöht somit die Schwierigkeit für helfende Nutzer und mindert gleichzeitig die Chance auf Hilfe 8)


    ERROR: SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client

    Der Fehler hängt mit MySQL 8 und der verwendeten PHP Version zusammen (kann man auch googlen). Daher taucht der Fehler auch nur bei Reihe 8 auf. Ich kann das Verhalten ebenfalls bei einem Update der Reihe 8 reproduzieren:



    Die Warning Meldung kann behoben werden, in dem man

    PHP: /usr/local/pd-admin2/htdocs/roundcubemail/config/config.inc.php
    'mime_types' => '/usr/local/pd-admin2/httpd-2.4/conf/mime.types'

    in das Array einfügt. Dies ist aber nicht ursächlich für die Fehlermeldung.


    Relevant sind bei dem Update die Zeilen 1447-1448 aus se-update.sh:

    Code
    $T1523594                                                                                                                                                                                        $T1524289

    Dabei werden lediglich die Skripte ticket-1523594.sh und ticket-1524289.sh aus dem SE Update Ordner ausgeführt. Relevant hierbei ist das erste Skript. Führt man dies manuell aus, erhält man die Fehlermeldung aus dem SE Update. In dem Skript wird in Zeile 39 (Update Funktion)

    Code
    ln -snf $INST/bin/php-7.3-cli ${RCM}/bin/php

    gesetzt. PHP 7.3 hat jedoch Probleme mit der Authentifizierungsmethode bei MySQL 8. Es muss hier PHP 7.4 verwendet werden. Also einfach die Zeile in

    Code
    ln -snf $INST/bin/php-7.4-cli ${RCM}/bin/php

    ändern und siehe da

    Bash
    $ ./ticket-1523594.sh
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    What version are you upgrading from? Type '?' if you don't know.
    Executing database schema update.
    NOTICE: Update dependencies by running `php composer.phar update --no-dev`
    This instance of Roundcube is up-to-date.
    Have fun!
    mysql: [Warning] Using a password on the command line interface can be insecure.
    Ticket_2019102267002761 returned true

    Das Skript läuft durch.