Beiträge von Sumeragi

    solange nicht klar ist woher es kommt sollte der SMTP Dienst deaktiviert werden. Wird dieser nicht gestoppt, landet man auf immer mehr Blacklists. Und das Delisting ist dann immer zusätzlich Aufwand.


    Es muss auch kein Kontaktformular sein. Eine Sicherheitslücke in einem Plugin reicht aus. Dazu sollte man sich das access_log anschauen. Meist hat man eine IP, welche viele POST Anfragen schickt.


    Ansonsten kann es auch eine kompromittierte Mailbox sein. Dann sollte eigentlich das Mail-Submission-Limit greifen... Aber hab schon gesehen, dass dieser Wert extrem hoch gesetzt wurde 🤷

    In dem Zusammenhang muss es dann auch nicht unbedingt nur Port 25 sein. Es kann auch über Port 465 und 587 eingeliefert werden.


    Die Ausschnitte aus den Logs sind für mich leider unbrauchbar. Ich konnte keine zusammenhängende Zustellung sehen. So hat man ein Indiz auf ein mögliches Problem. Große Logs sollten dann auch besser per txt Datei als Anhang gepostet werden. Macht das Lesen des Threads angenehmer 😉


    btw gehört dies eher in einen eigenen Thread, da es wohl nichts mit der Sicherheitslücke zu tun hat.

    Der Befehl du kann glaub ich nicht sortieren. Dies ginge höchstens mit

    Shell-Script
    1. du -h | sort -rh

    Ich nutze gerne

    Shell-Script
    1. find / -type d -exec du -Sh {} \+ | sort -rh | head -30

    Man darf sich nur nicht von den Fehlern mit /proc irritieren lassen.


    Ich würde aber Mal bei /usr/local und /var/log schauen. Das sind bei mir oft die ersten Stellen, wo schnell Mal Platz verbraucht wird.

    Ich vermute, bei Aktivierung der Weiterleitung auf HTTPS wird dies nur für die Subdomain aktiviert. Nicht aber für die Domain ohne www. Müsste man Mal in der httpd.conf schauen.


    Ich habe immer bei meinen Domains folgenden Eintrag in der htaccess stehen:

    Code
    1. RewriteEngine On
    2. RewriteCond %{SERVER_PORT} !^443$
    3. RewriteRule (.*) https://www.domain.de/$1 [L,R=301]

    Wenn dies bei Ihnen eingetragen wird, sollte auch domain.de weiterleiten.

    Wie lange läuft die Ausführung des Befehls? Der cronjob wird jede Minute ausgeführt. Vermutlich kommt es durch Mehrfachausführung zu den Fehlern.

    Es sollte der cronjob um flock erweitert und somit die Mehrfachausführung verhindert werden.

    Bitte nichts an den Symlinks unter /etc/letsencrypt/ ändern! Die werden so vom certbot erstellt/verwaltet.


    Da für den Hostnamen noch keine gesicherte Verbindung verfügbar ist vermute ich, dass die Symlinks zwischen /etc/letsencrypt/live/vpscobra.service4it.de und /opt/pdadmin/sslcerts nicht gesetzt sind (wie oben im Thread beschrieben). Können Sie bitte einmal folgende Ausgabe Posten:

    Shell-Script
    1. ls -al /opt/pdadmin/sslcerts/vpscobra.service4it.de*

    Was passiert denn, wenn Sie den Befehl mit /opt/pdadmin/bin/certbot-auto ausführen?

    Damit war der komplette Befehl gemeint und nicht bloß der certbot alleine:

    Shell-Script
    1. /opt/pdadmin/bin/certbot-auto certonly --webroot -w /usr/local/pd-admin2/htdocs -d vpscobra.service4it.com


    Zitat von Rudix

    Muss der RedirectMatch nun in der httpd.conf drinne sein oder auskommentiert sein?

    Lässt sich einfach feststellen. Einfach Mal in die httpd.conf rein schauen ;) Derzeit steht die Zeile ja schon im Template drin. Allerdings auch

    Code
    1. ## REDIRECT_TO_HTTPS ##

    Die Zeile wird bei Ausführung von httpd_vhosts.pl ersetzt. Und ich meine dies wurde gefixt und es wird der "richtige" Redirect gesetzt. Dies sieht man ebenfalls in der httpd.conf.

    Edit: Kurzum, der Redirect muss drin sein. Sonst gibt es Probleme bei der Verlängerung des Let's Encrypt für den Hostnamen.

    ... es wird doch dann mit certbot-auto-o die umbenannte originale Datei verwendet?
    ... geht bei mir mit beiden certbot-auto und certbot-auto-o nicht

    ... ein Aufruf von /opt/pdadmin/bin/certbot-auto-o certonly --webroot -w /opt/pdadmin/etc/ssl-validation/ -d vpscobra.service4it.com

    certbot-auto-o ist der eigentliche certbot. Die Datei certbot-auto ist einfach ein wrapper Skript, welches certbot-auto-o mit dem Argument -q gestartet. Daher funktioniert beides identisch.

    Habe es im anderen Threads gesehen:

    Der letzte Fehler liegt am genannten Rate Limit. Es sind 5 Fehlversuche pro Stunde erlaubt.


    Ich meine der Redirect wurde irgendwann Mal bereits gefixt. Sollte man in der httpd.conf sehen. Da es zu einem 404 Fehler kommt, kann das webroot falsch sein. Klappt es mit /usr/local/pd-admin2/htdocs als webroot ?

    Bei mir wurde bei erstmaliger Ausführung von /opt/pdadmin/bin/letsencrypt die certbot-auto Datei in certbot-auto-o umbenannt und /opt/pdadmin/bin/certbot-auto mit folgendem Inhalt angelegt:

    Code
    1. cat /opt/pdadmin/bin/certbot-auto
    2. #!/bin/bash
    3. exec /opt/pdadmin/bin/certbot-auto-o -q "$@"less /opt/pdadmin/bin/certbot-auto
    4. #!/bin/bash
    5. exec /opt/pdadmin/bin/certbot-auto-o -q "$@"

    Die Datei certbot-auto-o fehlt bei Ihnen.

    massive Probleme mit https den administrator-Zugang einzurichten, die SUB-Domains laufen nach einigen Nachinstallationen von dem ganzen Python-Paketen mit letsencrypt ! (aber erst nach langem Fehlersuchen!!!)

    Bei der erstmaligen Ausführung der certbot müssen python Pakete nachinstalliert werden. In Ihrem Beitrag schrieben Sie, dass Sie zunächst den Endkunde sudo-Berechtigungen geben mussten und dann Pakete manuell nachinstalliert haben. Dieses Verhalten ist mir neu und hatte ich bei Tests mit Debian und pd-admin noch nicht.


    Auch wenn es dadurch ein wenig Off-Topic wird... Wie sieht denn die Ausgabe von

    Code
    1. ls -al /opt/pdadmin/bin/certbot-auto*
    2. -rwxr-xr-x. 1 root root 57 27. Apr 2018 /opt/pdadmin/bin/certbot-auto
    3. -rwxr-xr-x. 1 root root 68689 9. Aug 15:59 /opt/pdadmin/bin/certbot-auto-o
    4. ls -al /opt/pdadmin/bin/letsencrypt
    5. -rwxr-xr-x. 1 root root 1518845 26. Jun 15:15 /opt/pdadmin/bin/letsencrypt

    aus?

    Ich nutze CentOS und habe Debian ein, zwei Mal zum Testen installiert. Hatte mit pd-admin keine Probleme bei den Tests. Mir ist daher etwas schleierhaft, wieso Endkunden in die sudoers Datei eingetragen werden müssen.


    Aber erst einmal zum Problem mit dem Zertifikat für den Hostnamen:

    ... so hier die Fehlermeldung von Firefox beim Aufruf über https://<SERVERNAME>/administrator


    /*schnipp*/

    vpscobra.service4it.com verwendet eine Sicherheitstechnologie namens "HTTP Strict Transport Security (HSTS)", durch welche Firefox nur über gesicherte Verbindungen mit der Website verbinden darf. Daher kann keine Ausnahme für die Website hinzugefügt werden.

    /*schnapp*/

    Prüft man vpscobra.service4it.com, sieht man dass das Zertifikat nicht zur URL passt:

    Offenbar ist http://www.service4it.com auf dem Server als Domain angelegt und hierfür ein Lets Encrypt Zertifikat eingerichtet. HSTS ist dann im Endkundenmenü über Subdomain konfigurierbar. Das Problem hier ist aber nicht HSTS, sondern ein falsches Zertifikat.


    Warum ist das so?


    Für den Hostnamen gibt es offenbar kein SSL-Zertifikat. Nun fragt man den Apache aber explizit auf Port 443 (Aufruf mittels https://...) nach einer gesicherten Verbindung. Da kein vhost mit Servernamen:443 gibt, wird der erste vhost in der Apache Konfiguration mit Port 443 verwendet. Dies ist in diesem Fall http://www.server4it.com . Kann man auch prüfen, in dem man die httpd.conf öffnet und nach ":443" sucht. Der erste Treffer ist dann http://www.service4it.com.

    Muss vielleicht ein letsencrypt-Zertifikat manuell angelegt werden?

    Ganz genau. Die Einrichtung für den Hostnamen muss manuell erfolgen. Über die Weboberfläche oder /opt/pdadmin/bin/letsencrypt geht dies nicht für den Hostnamen.


    1. Zertifikat ausstellen:

    Shell-Script
    1. /opt/pdadmin/bin/certbot-auto-o certonly --webroot -w /opt/pdadmin/etc/ssl-validation/ -d vpscobra.service4it.com

    2. Symlinks erstellen:

    Shell-Script
    1. ln -s /etc/letsencrypt/live/vpscobra.service4it.com/privkey.pem /opt/pdadmin/sslcerts/vpscobra.service4it.com-key
    2. ln -s /etc/letsencrypt/live/vpscobra.service4it.com/cert.pem /opt/pdadmin/sslcerts/vpscobra.service4it.com-cert
    3. ln -s /etc/letsencrypt/live/vpscobra.service4it.com/fullchain.pem /opt/pdadmin/sslcerts/vpscobra.service4it.com-cacert

    3. Apache Konfig neu schreiben:

    Code
    1. /opt/pdadmin/bin/httpd_vhosts.pl

    Das sollte es gewesen sein und die Weboberfläche sollte wieder erreichbar sein. Falls es zu Fehlern kommt, bräuchten wir hier die durchgeführten Schritte, sowie den vollständge Fehlermeldung, um bei Problemen helfen zu können.