Beiträge von tbc233

    Ich seh ja relativ viele Requests wie diese, die anscheinend auf irgendwelche Directory Traversal Lücken der Vergangenheit los gehen


    Code
    [Fri Jul 12 05:24:15.868858 2024] [core:error] [pid 16761] [client 23.xxx.xxx.xxx:51822] AH10244: invalid URI path (/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh)
    [Fri Jul 12 05:24:19.199058 2024] [core:error] [pid 16764] [client 23.xxx.xxx.xxx:52220] AH10244: invalid URI path (/cgi-bin/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/bin/sh)


    Grundsätzlich laufen sie eh ins Leere, aber die nächste Traversal Lücke kommt wohl bestimmt.


    Daher hab ich überlegt, ob man vielleicht in die httpd.conf ein


    Code
    <Directory />
        Require all denied
    </Directory>


    rein machen könnte und dann die benötigten Directories (/home/, /opt/pdadmin/www und so weiter) explizit granted.


    Wäre das sinnvoll?

    Seit ich die 4.118 habe, kann ich keinen Kunden mehr sperren. Bei Klick auf "Sperren / Entsperren" erhalte ich


    Code
    Software error:
    
    system returned 768 at /opt/pdadmin/www/administrator/administrator.cgi line 4935.
    
    For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error. 

    Absolut wertvoller Hinweis.
    Da ist definitiv was dran. Hab mir das gerade angesehen, würde man auf public_html zeigen, wären drastisch weniger Files öffentlich erreichbar, was die Angriffsfläche hinsichtlich herumspielen an etwaig verwundbaren Scripts oder Libraries enorm senken würde.


    Daniel Bradler könnte man das in Betracht ziehen?

    Also ich hab so ein Setup schon länger Up and Running (sofern ich Dein Anliegen richtig verstanden habe).


    Ziel: Eine subdomain mailservice.meinedomain.com, mit der ich alle Mailfunktionen nutzen kann und die ausgehenden Mails per DKIM signiert werden.


    Ich hab das so gemacht wie von Dir angedeutet. meinedomain.com habe ich bei den erlaubten Domainendungen angelegt. Dann mailservice.meinedomain.com als "Hauptdomain" angelegt. DKIM aktiviert, DNS Record gesetzt, Mailboxen angelegt. Funktioniert soweit alles wie erwartet.

    Da die Version auch immer aktuell ist, würde ich als workaround vorschlagen /usr/local/pd-admin2/bin mit vorne in die PATH Variable aufzunehmen. Dann funktioniert curl korrekt.

    Mir geht es gar nicht so um curl, das habe ich nur zur Demonstration des Problems eingebracht.


    Bei einem OS mit zerschossenem CA Tusted Bundle krankt es an allen Ecken und es lässt sich halt generell kaum administrieren.
    yum/dnf bricht ab wegen Zertifikatsfehler, meine Backups zu Backblaze schlagen fehl, und und und. Alles was irgendwie eine verschlüsselte Verbindung nach aussen aufbaut, funktioniert in dem Zustand nicht mehr. Natürlich kann ich bei vielen Tools die Zertifikatsüberprüfung abschalten, aber das ist ja nicht der Sinn der Übung.

    Okay, nach weiterer Analyse kehre ich zu meiner ursprünglichen Theorie zurück. Es hat mit der /etc/ssl/cert.pem zu tun.


    Nach einem dnf reinstall ca-certificates (also wenn wieder alles so ist wie es sein soll) ist diese Datei eben ein Symlink auf die besprochene ca-bundle datei:


    Code
    # ls -l /etc/ssl/cert.pem
    lrwxrwxrwx 1 root root 49 Sep 12  2023 /etc/ssl/cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Im übrigen eben die Datei, auf die eben auch /etc/pki/tls/certs/ca-bundle.crt zeigt, jenes Bundle das zum Beispiel das curl des OS verwendet.

    In /opt/pdadmin/bin/update_host_certificate.sh wird hier in Zeile 45 aber eben das CAcert des Hosts rein ge-catet


    Code: /opt/pdadmin/bin/update_host_certificate.sh
    mkdir -p /etc/ssl/
    cat /opt/pdadmin/sslcerts/$H-cacert > /etc/ssl/cert.pem


    So kommt es eben zur Überschreibung des CA Bundels des OS mit dieser Datei.
    Bei Oracle Linux scheint das kein Problem zu sein, weil dieser Symlink so wohl nicht existiert. Das update Script legt also diese /etc/ssl/cert.pem an, um die kümmert sich dort aber vermutlich niemand weiter.

    Ich hab mich leider durch das ganze Herumtesten zwischendurch mal verwirren lassen und dachte bei einem Testlauf dass ich die Zeile auskommentiert hatte, war aber wohl quatsch.

    Ich werde also fürs erste mal wieder diese Zeile auskommentieren.


    Daniel Bradler, wozu wird das gemacht?

    Mir ist das auch ein völliges Rätsel. In diesem Update Script wird die Datei meiner Meinung nach nicht angerührt, mit dem Aufruf von letsencrypt vorher ja wohl hoffentlich auch nicht.


    Vor dem Aufruf des Cronjobs ist die Datei 217K groß und enthält eine ganze Menge Certs - wie man es eben bei so einem Bundle erwarten würde.

    Code
    # md5sum /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem # vor aufru
    72f205fe6e0fbe28eed65773e289544d  /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Nach dem Aufruf hat die Datei nur mehr 1,8K und enthält nur mehr eine einzige "-----BEGIN CERTIFICATE-----" Sektion.


    Code
    # md5sum /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem #nach dem Aufruf.
    c92a7db9c0faccd6b3157af32b646f07  /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Ich kenne das Verhalten von bereits von einem völlig anderen Server, da war es exakt gleich. das war ja der Grund warum ich dieses Topic damals begonnen habe. Der Server wurde aber dann nicht mehr benötigt, daher hab ich das nicht weiterverfolgt. Nun habe ich es eben wieder bei einem völlig (mit Ausnahme von pd-admin) jungfräulich aufgesetzten Server.

    So, ich hab jetzt mal händisch den Sonntags Cronjob


    Code
    /opt/pdadmin/bin/letsencrypt --renew 2>&1 | /opt/pdadmin/bin/log.sh dehydrated-renew ; /opt/pdadmin/bin/update_host_certificate.sh

    ausgeführt. Danach das Fehlerbild:



    Allerdings scheint meine Spur, dass die Datei /etc/ssl/cert.pem etwas damit zu tun hat, möglicherweise Quatsch zu sein. Weil die betroffene Zeile habe ich testweise in der update_host_certificate.sh auskommentiert. Die Datei blieb bei diesem Testlauf unverändert.


    Somit bin ich weniger schlau als zuvor. Allerdings sehe ich schon das die Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem genau in der Minute des Scriptaufrufs verändert wurde.

    Ich kann es mir nur so erklären dass das Setup der ca-certificates bei rocky/alma halt ein anderes ist als bei Oracle. Weil bei ersteren muss es so aussehen:


    Code
    # ls -l /etc/ssl/cert.pem
    lrwxrwxrwx 1 root root 49 Sep 12  2023 /etc/ssl/cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem


    Ist das nicht der Fall, hagelt es Zertifikatsfehler bei Verbindungen zu anderen Servern.
    Derzeit wird diese /etc/ssl/cert.pem aber eben mindestens jeden Sonntag überschrieben von /opt/pdadmin/bin/update_host_certificate.sh aufgrund dieses Cronjobs


    Code
    31   4  * * 0 /opt/pdadmin/bin/letsencrypt --renew 2>&1 | /opt/pdadmin/bin/log.sh dehydrated-renew ; /opt/pdadmin/bin/update_host_certificate.sh


    Mir persönlich ist ein Rätsel, warum die pd-admin Cronjobs überhaupt die /etc/ssl/cert.pem beschreiben. Zumindest ich sehe hierfür keine Notwendigkeit.