Beiträge von Sumeragi

    Sicherlich interessant für den Einen oder Anderen:


    Das Problem scheint mit Apache 2.4.39 einher zu gehen. Darin wurde mod_reqtimeout eingeführt, womit man Timeouts bei Handshakes konfigurieren kann. Bei einem Timeout kommt es zu den Log Einträgen von tbc233 . Beim Client kommt es zu einem 408 Fehler. Dies ist so auch in der Doku beschrieben:


    https://httpd.apache.org/docs/…t.html#requestreadtimeout


    Offenbar werden beim Apache 2.4.39 die Default-Werte nicht korrekt gesetzt. Dies wird mit Version 2.4.40 gefixt (bisher noch nicht veröffentlicht):


    https://svn.apache.org/repos/a…pd/branches/2.4.x/CHANGES


    Abhilfe schafft hier das Setzen des von TomLoader beschrieben Werts im Apache 2.4 Konfig Template:


    RequestReadTimeout body=3600


    Die Position ist egal. Ich habe den Wert über den TimeOut Werten gepackt.


    Reproduzierbar ist dies übrigens auch per WebFTP. Nach setzen von RequestReadTimeout klappte der Upload.


    Edit:


    Interessant wäre jetzt noch, ob tatsächlich ein Wert von 3600 benötigt wird oder ein geringerer Wert nicht auch ausreichend ist. Der Default-Wert ist wohl 20 Sekunden. Möglicherweise wird mit dem Fix in 2.4.40 der Wert korrekt gesetzt und der Eintrag im Template wird überflüssig.

    Versand von Mails werden unter /usr/local/pd-admin2/htdocs/roundcubemail/logs/ssendmail geloggt. Dies ist eine Standardeinstellung. Es muss also nichts an der Konfig von Roundcubemail gemacht werden. Die Logzeilen sehen dann wie folgt aus:

    Code
    1. [15-May-2019 06:48:59 +0200]: User mail@absender.tld [178.xxx.xxx.xxx]; Message for mail@empfänger.tld; 250: ok 1557895739 qp 19142


    Man könnte also tatsächlich ein fail2ban Filter dafür erstellen.


    Aber greift das Mail Submission Limit aus pd-admin wirklich nicht? Die Mails werden ja schließlich von Roundcubemail an qmail übergeben und dieser stellt die Mails dann zu. Das Mail Submission Limit greift tatsächlich nicht bei Mails, die von Roundcubemail versandt werden.


    Ich hatte dies auch. Hängt aber nicht mit dem SE Update zusammen. Bei mir waren die Dailies beschädigt und dadurch erzeugte clamd eine extrem hohe Last. Die clam Updates werden täglich per cron ausgeführt. Ich würde das Update einmal händisch ausführen und schauen, ob es korrekt durch läuft. Wenn nicht, würde bei der nächsten cron Ausführung die Last wieder extrem ansteigen. Abhilfe schaffte bei mir das löschen der Dateien unter /usr/local/pd-admin2/share/clamav/

    Das war jetzt nur die Konfiguration für den Webserver. Die pd-admin Oberfläche ist ja auch nur "eine Webseite". Daher sollte dies auch funktionieren.

    Die Frage ist eher, ob sämtliche Hintergrundfunktionen/-skripte in pd-admin IPv6 kompatibel sind. Wenn das alles (noch) nicht umgesetzt/getestet wurde, kann ebeb keine 100%ig Unterstützung gewährleistet werden.


    Mir ist z.B. aufgefallen, dass bei einem Login über eine IPv6 Adresse der Lizenztyp als "free" angezeigt wird. Wobei das wohl vornehmlich daran liegen wird, dass im Lizenz File die Zeile der IPv6 Adresse leer ist. Aber auch hier ist dann die Frage: wird IPv6 bei der Validierung des Lizenz Files bereits unterstützt oder ist es enthalten für eine zukünftige IPv6 Unterstützung?

    Okay, ich hab grad gesehen dass ich meine httpd.conf-template entsprechend erweitert habe, damit auch ipv6 zieht. Das war mir auswendig nicht mehr geläufig dass ich das händisch gemacht habe.


    Damit sollte es dann gehen, weil das pd-admin document root dann auch auf die ipv6-Adresse "hört".

    Habe ich nun ebenfalls erweitert und per cURL ist pd-admin nun erreichbar :thumbup: Konnte es im Browser nur noch nicht wirklich testen da, egal bei welchem Anschluss, die Anfragen bei mir bisher immer per IPv4 raus gingen.


    Edit:


    Zugriff per IPv6 auf die Verwaltungsoberfläche klappt problemlos.

    Muss tbc233 zustimmen. Eine Analyse ist so nicht möglich... Zumal ich hier den Eindruck habe, dass Mail-Dienste und Webserver in einen Topf geworfen werden. Da getrennte Dienste, muss dies auch getrennt betrachtet werden.


    Ich habe mich entschlossen IPv6 auf meinem Server zu aktivieren und bei den ersten Tests klappt alles problemlos:


    Mail-Dienste:


    Mails werden per IPv6 versandt und empfangen.


    Webserver:


    Gehostete Webseiten sind per IPv6 erreichbar.


    Die pd-admin Verwaltungsoberfläche nicht. Schaut man sich die httpd.conf wird auch klar wieso. Es gibt kein IPv6 vhost dazu. afaik unterstützt pd-admin, also die Verwaltungsoberfläche, noch kein IPv6. Sprich egal ob eine IPv6 Adresse konfiguriert ist oder nicht, die Verwaltungsoberfläche ist nicht per IPv6 erreichbar.

    Ich sperre immer gleich das ganze Netz, denn oft kommen Attacken danach von einer anderen IP aus dem gleichen Netz und so ist meist Ruhe.

    Mache ich auch. Nur wollte ich das Detail mit dem Subnetz erwähnt haben, da dies für den Einen oder Anderen nicht direkt ersichtlich sein könnte. Wäre dies z.b. eine Telekom IP könnte die Sperrung des Subnetzes andere Probleme nach sich ziehen.

    iptables -A INPUT -s 212.96.162.0/24 -p TCP -j DROP


    und weg issser ;)

    Durch das /24 hieße es wohl eher "und weg isset". Denn man sperrt dadurch ein komplettes Subnetz und nicht bloß eine IP.


    Die IP selber scheint derzeit noch nicht auf einer Blacklist. Im whois zur IP kann man jedenfalls eine abuse Mail-Adresse entnehmen. Der Spamversand sollte auch gemeldet werden. So tut man auch etwas Gutes für andere Nutzer und verhindert (hoffentlich) weiteren Spam.

    Ich vermute es liegt an den Berechtigungen. Wie setze ich die richtig?

    Ich denke eher es liegt an der Erstellung des symlinks.


    Bei der Erstellung des symlinks wurde

    Code
    1. ln -s /etc/letsencrypt/live/s1.stefanb341.de/privatekey.pem /opt/pdadmin/s slcerts/s1.stefanb341.de-key

    eingebenen. Bei mir heißen die private key Dateien von Let's Encrypt "privkey.pem" und nicht wie angegeben "privatekey.pem". Wäre jedenfalls ein Grund weshalb die Datei nicht gefunden würde.

    Den Befehl

    Shell-Script
    1. certbot certonly --webroot -w /usr/local/pd-admin2/htdocs -d hostname

    verwendet man, wenn man certbot per apt-get oder yum aus einem repository installiert hat. Es kann aber stattdessen certbot-auto von pd-admin verwendet werden... Kommt aufs gleiche raus.


    Unter /etc/letsencrypt/live/s1.DOMAIN.de/ befinden sich

    privatekey.pem, cert.pem und fullchain.pem. Die fullchain.pem wird als cacert Datei verwendet. Sieht dann so aus:

    Shell-Script
    1. ls -al /opt/pdadmin/sslcerts
    2. lrwxrwxrwx. 1 pdadmin root 50 26. Okt 2017 hostname-cacert -> /etc/letsencrypt/live/hostname/chain.pem
    3. lrwxrwxrwx. 1 pdadmin root 49 26. Okt 2017 hostname-cert -> /etc/letsencrypt/live/hostname/cert.pem
    4. lrwxrwxrwx. 1 pdadmin root 52 26. Okt 2017 hostname-key -> /etc/letsencrypt/live/hostname/privkey.pem