Beiträge von monderka

    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

    Hätte man eigentlich auch mit der Ignore-List arbeiten können?
    Wird die von PD-Admin unterstützt?


    How do I ignore/whitelist a ClamAV signature?
    Creating a ignore/whitelist file >Change Directory into the location where your ClamAV databases are stored. Create a file called “whitelist.ign2”, for example, like this:
    touch whitelist.ign2


    Wenn ja, muss das in das Verzeichnis wo daily, etc drin ist?


    Denn eine Workarounds hatten empfohlen darin einen Eintrag zu machen.

    Wir sollten hier in dem Beitrag die beiden Themen trennen, sonst blickt irgendwann niemand mehr durch...


    Ursprung war die Frage wie man das Signatur-Problem lösen kann.
    Das sollten wir in dem Post vorranging behandeln.


    Gerne in einem zweiten wie man mit dem Update von ClamAV verfährt und ob man derweil das abschalten kann oder will, unabhängig davon das die signaturen wieder gehen.


    Mein Anliegen in dem Post ist ja eher zu wissen ob mit einer neuen daily von clamav auch das problem gelöst sein könnte und man dann wieder mit normalen Rechten und dem freshclam arbeiten kann... Woran würde man erkennen ob es eine korrigierte signatur ist die ausgeliefert wird?


    so wie ich das bei clamav-users lese ist ja im Signaturfile was falsch oder defekt oder sonst irgendwas.


    Don't go that way. It's much better to add the signature
    Vbs.Downloader.Generic-6431223-0 which is causing the problem to
    the ignore list (file local.ign2) so that ClamAV stops using it.



    http://lists.clamav.net/piperm…/2018-January/005747.html
    http://blog.clamav.net/2018/01…le-descriptors-issue.html


    Update on the recent "File Descriptors" issue in ClamAV
    A signature introduced in daily.cvd version 24256 triggered bug that exists in all current stable releases of ClamAV.


    The symptoms on a Linux/Unix machine running clamd under heavy load results in the system running out of file descriptors, because the file descriptors for deleted temp files were not being closed. On Windows systems, a different error occurred wherein the system reported “permission denied” errors when closing (unlinking) the temp files.


    The bug was reported as early as April 2016 here: https://bugzilla.clamav.net/show_bug.cgi?id=11549. A patch for this bug was applied towards the upcoming 0.100.0 feature release of ClamAV, but unfortunately the fix didn’t make it into the recent 0.99.3 security patch release.


    For the time-being, the offending signature was pulled as of daily.cvd version 24258, and changes to our backend processes have been implemented to prevent this from happening again.


    We apologize for the inconvenience this has caused. Future releases of ClamAV will have a fix in place to prevent this issue from reocurring.


    --
    Joel Esler | Talos: Manager | jesler at cisco.com<mailto:jesler at cisco.com>

    readproctitle service errors: ...4ce66c6ae71aac6736356ecf9aa8.tmp/clamav-eccff1b0d1d986241a11346d32f225e4.tmp: Too many open files LibClamAV Warning: fileblobScan, fullname == NULL LibClamAV Error: fileblobDestroy: textportion not saved: report to http://bugs.clamav.net /var/qmail/simscan/1516957682.890442.7056/msg.1516957682.890442.7056: Can't open file or directory ERROR tcpserver: end 7051 status 0 tcpserver: status: 2/100


    y: textportion not saved: report to http://bugs.clamav.net /var/qmail/simscan/1516957953.840941.11181/msg.1516957953.840941.11181: Can't open file or directory ERROR LibClamAV Error: cli_gentempfd: Can't create temporary file /tmp/clamav-f9899ab386b96eaf13190508f89c325d.tmp: Too many open files /var/qmail/simscan/1516957953.840941.11181/addr.1516957953.840941.11181: Can't create new file ERROR



    auf allen servern haben wir genau das problem seit heute