Beiträge von monderka

    Hallo,

    ich habe auf einer Maschine mit Reihe6 und aktueller SE das auch gerade mal probieren wollen.

    Habe event aktiviert und prefork ausdokumentiert.


    dann kommt bei mir folgende Meldung


    /opt/pdadmin/bin/httpd_vhosts.pl

    Writing /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected

    AH00526: Syntax error on line 16 of /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf:

    Invalid command 'MinSpareServers', perhaps misspelled or defined by a module not included in the server configuration

    Hallo Zusammen,


    letzte Woche hatte ich einen Fall bei dem ich eine Wordpress_Installation mit diversen Plugins über das PD-Admin Backup zurück sichern musste.

    Nach dem Restore hat das Backend nicht mehr funktioniert und im error_log waren tonnen Meldungen das Dateien fehlen.


    Nach einigem hin und her ist mir aufgefallen das die Unterverzeichnisse alle mit "logs" beginnen und dann ist es mir wie Schuppen von den Augen gefallen...

    Dadurch das "logs" exkludiert ist werden ALLE Unterverzeichnisse eines Kundenwebs nicht gesichert die "logs" heißen, auch wenn wie im Subdomains-Verzeichnis liegen.


    Kann man das irgendwie so machen das die Backups vollständig sind ohne das man auch die logs aus dem Root-Customer-Verzeichnis mit sichern muss?


    viele Grüße

    Manfred

    Hallo,


    ich habe mal alle neu aufgesetzten PD-Admins der letzten Monate gecheckt und tatsächlich sind bei allen die Berechtigungen auf forward_filter falsch und zwar so:


    Zitat

    51642837 12 -rwxr-xr-x 1 root root 9547 Jun 29 2016 forward_filter

    Die Installation war noch vor v4.60 und der aktuelle 0.325 SE


    Diese Rechte sollte wohl jeder mal prüfen um vor Überraschungen sicher zu sein.


    Ich habe überall auch noch das s-bit so gesetzt, damit es identisch mit den anderen Servern bei mir ist (auf Debian)

    Code
    1. chmod u+s forward_filter

    Meine Kunden bekommen manchmal schon Mails aus Russland (nicht Rumänien) mit .ru als TLD. Aber sie können die gewünschten Adressen ja in der Whitelist dann durchlassen. Generell verwenden wir auf allen Servern bei uns fast die gleiche Liste (manche Server mit mehr Kunden aus Asien haben eine etwas modifizierte Version).


    Mit dem reject meine ich das der QMAIL-SMTPD die als Spam-Mails erkannten mails bei spam_paththrough=no gar nicht annimmt und die dann auch nicht in das Quarantäne kommen sondern sofort als "SPAM" die annahme verweigert wird. Macht nicht bei jedem Kunden sinn, aber bei machen die besondern Spam geplagt sind schon.

    Hallo, allen ein gesundes und friedliches neues Jahr 2019.


    Ich mache die Blacklist-Sperrung von dubiosen Mails in der local.cf und starten danach immer den spamd Dienst neu. Das funktioniert einwandfrei.


    Hier die Liste meiner Spam-Sperrungen. Um die Spams dann ggf. gleich rejecten zu lassen trage ich im qmail die Domains mit spam_passthrue=no dediziert ein:


    Code
    1. vi /var/qmail/simcontrol/simcontrol
    2. kundendomain.com:clam=yes,spam=yes,spam_passthru=no
    3. :clam=yes,spam=yes,spam_passthru=yes
    4. Änderungen im simcontrol aktivieren:
    5. /var/qmail/bin/simscanmk
    6. /var/qmail/bin/simscanmk -g


    Mit dem Update auf v4.60 ist die die NameVirtualHost-Meldung weg.

    Die zweite Meldung bleibt im readproc.


    Das einzige Run-File in dem "test" vorkommt ist in Zeile 12:

    test "$NO_SSLv2v3" -ne 0 && export NO_SSLv2v3


    qmail-smtpd/run


    Das würde zu der Meldung passen:

    ./run: 8: [: server16.onit4u.de: unexpected operator ./run: line 12: test: : integer expression expected


    Wir haben mit Mysql 5.7 auf der Reihe6 schon mehrfach probleme mit dem strice-mode und integer-Werten gehabt, vielleicht hängt das damit zusammen? Ich kanns aber nicht 100%ig sagen. Wir haben bisher nur ein Testsystem mit Reihe6 geupdated und da erscheint die Meldung. Ich werde noch System mit Reihe 4 testweise updaten.

    Installierte pd-admin-Version: v4.59

    Installierte Version d. Serverumgebung: 6-0.325


    Nach dem Update des PD-Admin auf einer Debian9 Maschine kommen folgende komischen Meldungen:


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

    Writing /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected

    AH00548: NameVirtualHost has no effect and will be removed in the next release /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf:355



    2) readproc

    ps ax | grep readproc

    566 ? S 0:00 readproctitle service errors: ...e status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. SelfCheck: Database status OK. ./run: 8: [: server16.onit4u.de: unexpected operator ./run: line 12: test: : integer expression expected


    Ich werde das Update jetzt erstmal nicht auf alle Maschinen ausrollen bis die Meldungen geklärt sind.


    viele Grüße

    Manfred

    Folgende IP-Bereiche habe ich aktuell gesperrt, täglich kommen aber aktuell neue hinzu:


    iptables -A INPUT -s 159.65.0.0/16 -j DROP

    iptables -A INPUT -s 122.228.10.0/24 -j DROP

    iptables -A INPUT -s 185.212.131.0/24 -j DROP

    iptables -A INPUT -s 142.93.0.0/16 -j DROP

    iptables -A INPUT -s 115.235.171.0/24 -j DROP

    iptables -A INPUT -s 162.243.0.0/16 -j DROP

    iptables -A INPUT -s 138.68.0.0/16 -j DROP

    iptables -A INPUT -s 190.85/16 -j DROP


    Des weiteren probiere ich aktuell mal an einer maschine ob ich damit das Problem etwas entschärfen kann:


    Limit Connections per IP / Host, Only allow 3 connections per client host on Port 465

    iptables -A INPUT -p tcp --syn --dport 465 -m connlimit --connlimit-above 3 -j REJECT


    Nachtrag 26.10.18

    Auf mindestens einem Server bei uns hat die Limitierung geholfen. Bei einem weiteren Angriff aus dem OVH Netz wurden nur drei Verbindungen geöffnet und der Dienst blieb für die Nutzer erreichbar.

    Problematisch ist dies halt nur das die Angriffe auch verteilt kommen könnten und dann natürlich wieder der Dienst lahm gelegt werden könnte. Aber als aktuellen Workaround hilft das schonmal.

    Also ich führe das Problem ausschließlich darauf zurück das der Port 465 angegriffen wurde.

    IPs konnte ich von DigitalOcean, OVH und Linod feststellen. Ich habe dann immer großflächig die Netze der Angreifer per iptables gesperrt und zwar für alle Ports. Das mache ich jetzt eben die die nächsten Wochen um weitere Angriffe zu erkennen und zu blockieren.

    Wir haben das auch auf allen unseren Server.

    Wir gehen jetzt erstmal dazu über mit netstat -n | grep ":465" die IP-Adressen die Massenhaft den Port blockieren per iptables zu sperren. Aktuell sind das immer welche von DigitalOcean in USA

    Hallo,

    ja, das wohl überall so. Wenn mir das auffällt nehme ich den Redirect raus und mache eine Umleitung mit .htaccess dann wird das Zertifikat richtig erzeugt.


    Zu wünschen wäre aber wenn es in der Subdomain-Verwaltung im customer-Bereich die Möglichkeit gibt für einzelne Subdomains das letsencrypt abzuwählen, denn es kommt auch immer mal vor das Domains angelegt sind, gerade www ja automatisch sobald die Domain angelegt ist um nur eine Subdomain zu betreiben. Dann läuft der letsencrypt für die www. auch ins leere.


    Aber wenn man weiß warum die melden kommen kann man sich auch daran gewöhnen, man muss halt die Logfiles noch genauer durchschauen weil ein wirklicher Fehler dann nicht so schnell sichtbar ist.

    Das ist bei allen Neuinstallationen der fall das die pdadmin.conf mit dem Pfad für das reload-bin manuell angepasst werden muss. Habe gerade eben eine neu-Installation auf Reihe6 in Debian9 gemacht und da war es auch der Fall. Alle Systeme mit Apache 2.4. sollten daher manuell kontrolliert werden ob der Reload-Pfad auch korrekt eingetragen ist.

    Hallo Zusammen,


    seit einiger Zeit fallen mir solche Fehlermeldungen im Apache-Errorlog auf:


    [Tue Jul 10 02:51:40.667435 2018] [ssl:error] [pid 8601] AH02032: Hostname http://www.gitarrenkonzerte-ansbach.de provided via SNI and hostname rattelmeier.de provided via HTTP have no compatible SSL setup


    Wobei http://www.gitarrenkonzerte-ansbach.de KEIN SSL-Zertifikat hat.

    Wenn man aber auf https://www.gitarrenkonzerte-ansbach.de geht kommt man bei https://www.rattelmeier.de raus.

    Zwar Protokolliert das das errorlog dann nicht so, aber ich vermute hier irgend einen Zusammenhang.


    Hat da jemand eine Erklärung dafür und ob das problematisch ist?


    vielen lieben Dank

    Manfred

    Den Ansatz finde ich auch gut.
    Vielleicht wäre es möglich das der PD-Admin einfach eine Funktion bereit stellt die SSL-Zertifikate die in irgend einem Verzeichnis validiert liegen abarbeitet und in der Datenbank einstellt sowie die zertifikate im apache aktiviert.
    Kann sein das das mit den Zertifikaten in /opt/pdadmin/sslcerts/www.domain.org-cert / -key / -cacert schon so ist, habe ich bisher nicht ausprobiert.

    Leider habe ich dazu keine neuen Infos. Das passiert aber auch komischerweise nicht immer.
    Bei jedem SE-Update plane ich zur Sicherheit aber immer einen Reboot mit ein wenn mir innerhalb von 60 Minuten nach dem Update was komisch vor kommt.
    Vielleicht wenn vorher schon viel Spam-Verbindungen offen sind werden die nicht richtig geschlossen bevor die Dienste wieder hochfahren??? keine Ahnung, das ist reine Mutmaßung.

    Hallo Zusammen,


    ich weiß nicht wie es auch bei dem Thema SSL-Zertifikate mit letsencrypt geht.
    Auf einigen aktuellen PD-Admin-Servern mit Debian 8 und Debian 9 habe ich die von Herrn Bradler empfohlene letsencrypt-Implementierung eingerichtet. Das funktioniert gut, aber ich habe so etwas die Befürchtung das mit dem ganzen - für mich - undurchsichtigen python-kram mit Kanonen auf Spatzen geschossen wird.


    Wäre es nicht denkbar, wie bei vielen dingen im PD-Admin, eine einfache Bash-Script-Lösung für die Beantragung und Verlängerung von letsencrypt-Zertifikaten zu schaffen, die dann in der Standard-Umgebung vollständig enthalten ist?


    Sowas zum Beispiel:
    https://github.com/Neilpang/acme.sh/blob/master/README.md


    Außerdem würde ich mir in der Subdomain-Verwaltung der Kunden wünschen das ich auch Subdomains von der automatischen letsencrypt-Beantragung ausschließen kann. Denn manchmal sind Domains bei uns angelegt mit dem automatischen www. obwohl nur eine andere subdomain bei uns darauf läuft und die www. irgendwo auf einem Server ohne unseren Zugriff. Dann würde man die Fehlermeldungen im certbot reduzieren.


    Soweit meine Gedanken aktuell zu dem Thema. Da mit der EU-DSGVO die Verschlüsselung von Kontaktformularen und damit der Websites fahrt aufnimmt wäre was schlankes und praktisches wünschenswert.


    viele Grüße
    Manfred