Beiträge von antondollmaier

Zitat von tfi

Für die nächste Rundmail an die PHP v5 Kunden wollte ich mir noch die LC-Datenbank anschauen
ob man nicht mit 1-2 Queries alle E-Mail-Adressen von Kunden mit aktivem PHP 5.x Webspace erhält.

Schleife:

SELECT * FROM CUSTOMERS LEFT JOIN CONTACTS ON (CUST_OWNER_C=CON_ID AND CON_CUSTOMERID=CUST_OWNER) WHERE CUST_OWNER=1

für jeden Kunden:

SELECT * FROM SUBDOMAINS
LEFT OUTER JOIN DOMAINS ON SD_DOMAINID=D_ID
LEFT OUTER JOIN HOSTINGCONTRACTS ON D_CONTRACTID=HC_ID
LEFT JOIN WEBRUNTIMES ON ( SD_PHPVERSIONID =WR_ID OR ( SD_PHPVERSIONID IS NULL AND HC_SERVERID=WR_SERVERID AND WR_PRIO=0 AND WR_FOUND=1))
LEFT JOIN SERVERS ON ( SRV_ID=HC_SERVERID)
WHERE (SD_WEBCONFIG IN (1,5) OR SD_SSL_WEBCONFIG IN (1,5)) AND HC_LOCKED & 1 = 0 AND HC_RCIDROOT IS NULL AND HC_CUSTOMERID=%s ORDER BY HC_NAME ASC, D_NAME ASC, SD_HOST ASC

Läuft hier in einem Python-Skript, das dann die tatsächlich unsicheren PHP-Versionen noch im Code ausfiltert.

Dafür sorgen, dass Spam-Mails nicht zu Microsoft kommen.

Mögliche Quellen für solche Spam-Mails:

- CMS
- Weiterleitungen
- Kunden-Newsletter

Viel Erfolg. Wir sind seit 1,5 Jahren konsequent dran und haben seit dem keine Probleme mehr. Sind aber auch nicht bei Hetzner o.ä..

Zitat von isphttp.de

Wir haben trotzdem gleich mal alles geupdatet.

Wird wohl Zeit für einen anderen Admin.

postfix/smtps/smtpd[13115]: warning: connect to Milter service unix:/var/run/lcsam.sock: Connection refused

Das hat aber nichts mit OpenDKIM zu tun.

Was steht im Journal? (journalctl -u lcsam)

Zitat von kk

Hintergrund ist: wenn Kunden über den Aufruf von sendmail E-Mails verschicken ohne einen korrekten "Envelope-From" (Paramater "-f") anzugeben, dann gehen diese mit dem Absender <vertrag>@<hostname> raus.

Ein verflixxtes anderes Config-Panel hat dafür früher[tm] einen Alias erstellt, so dass die eingehenden Mails dann an den Kunden weitergeleitet wurden.

Nachdem LC die Mailadresse beim Kunden eh optional hat - und Sendmail auch Teufelszeug ist (also, das Sendmail-Binary! Wer Sendmail statt Postfix/Exim einsetzen will, soll das gerne weiterhin tun) - ist das eigentlich die sauberste Lösung.

Mir tun jetzt nur die Kunden leid, die so falsch konfigurierte WP-Installationen aufweisen und damit keine Mails mehr an HostEurope-Kunden senden können. Da schlägt nämlich dann die Absender-Validierung endgültig fehl.

Was spricht dagegen, einen eigenen Resolver aufzusetzen?

Zitat von kk

Und egal welcher Resolver es wird: er sollte DNSSEC unterstützen.

Das ist bei BIND und Unbound der Fall, aber ja - sollte 2021 explizit sichergestellt werden.

Zitat

(persönlich bevorzuge ich die Resolver des RZ bzw Uplinks sofern diese zuverlässig sind)

Mit dem Nachteil, dass deren Cache dann natürlich zwar größer ist, aber auch nicht beeinflusst werden kann.

Wir haben im Netz eigene Resolver mit Unbound/dnsdist/corosync am laufen, um keine Abhängigkeiten zu haben.

Zitat von weltmeister

Welche Resolver / Einträge für resolv.conf sind zu empfehlen?

Einen DNS-Resolver, der schnell und zuverlässig arbeitet:

- die Resolver, die vom RZ/Provider bereitgestellt und gepflegt werden. Dort anfragen.
- einen der bekannten öffentlichen DNS-Resolver, wie Google/Cloudflare/Quad9, mit den dazugehörigen Nachteilen (gefilterte Einträge, Datenschutz, ...)
- sich selbst mit Bind/Unbound einen eigenen Resolver aufsetzen und diesen über 127.0.0.1/::1 ansprechen

Welche Option "die beste" ist, muss jeder für sich entscheiden.

Zitat von isphttp.de

Da lässt sich nur schwer ein Kunde ausfindig machen

Entweder die Mail kommt via php mail(), dann steht die UID mit im Log:

Feb  9 12:34:22 venus postfix/pickup[32433]: 36BEA68B3DB: uid=1153 from=<web800>

Hier kann man auch einen Sendmail-Wrapper verwenden, um die mail()-Aufrufe gezielt zu loggen.

Oder die Mail wurde per SMTP auf localhost:25 eingeliefert - dann wird es in der Tat etwas komplizierter. Passiert aber denkbar selten - und von außen gibt es die SASL-Authentifizierung, um den Absender zu identifizieren.

"journalctl -u logrotate.service"

Logs prüfen, Problem identifizieren, ggf. via "systemctl start logrotate.service" manuell ausführen.

Wenn das Quota erreicht ist, kann gzip nicht komprimieren - das kann dann schon das gesamte Logrotate mit Exit-Code 1 beenden lassen.

Zitat von stefanos

Bestimmt wird es noch etwas zu Lebzeiten! :confused:

Im alten Handbuch (Seite 95) steht ja auch "In Kürze wird es für LiveConfig eine Erweiterung der SOAPAPI geben, mit der Sie diesen Vorgang aber teilweise automatisieren können" wovon man bisher nichts sah.

Admin -> Reseller-Vertrag bearbeiten -> Tab Domains -> DNS-Vorlage auswählen.

Reseller können dann genau diese Vorlage nutzen, um eigene Domains auf den Nameservern zu erstellen.

Validierung gibt es IMHO nicht, so dass "gmx.de" durchaus auch angelegt werden könnte (Authoritive Nameserver sollten aber sowieso nicht als Recursor genutzt werden).

Zitat von clickpress

Allerdings war ich mir nicht sicher, ob es irgendwo auch einen Automatismus gibt, der das alles anstößt. Z.B. auf Kundenebene auf Basis der PHP-Einstellungen.

Bisher - leider - noch nicht.

Wir warten auch.

ja, das ist der korrekte Weg, siehe auch "man lcphp":

DESCRIPTION
       lcphp allows switching the command line version of PHP. It first checks if the file ~/conf/php exists (which should be a symbolic link to the actual PHP binary to be
       executed). If yes, then the linked binary is run.


       The search order for PHP binaries is:


       ~/conf/php
       /usr/bin/php.default
       /usr/bin/php7
       /usr/bin/php7.3
       /usr/bin/php7.2
       /usr/bin/php7.1
       /usr/bin/php7.0
       /usr/bin/php5


OPTIONS
       All options and parameters are forwarded to the final PHP interpreter without any modification. lcphp does not have any own options or parameters.


INSTALLATION
       This tool should be installed at /usr/bin/php or /usr/local/bin/php, replacing the default PHP binary.


   DEBIAN/UBUNTU LINUX
       On Debian/GNU Linux or Ubuntu Linux use the update-alternatives(8) utility.


       Installation:
         update-alternatives --install /usr/bin/php php /usr/bin/lcphp 100


       Removal:
         update-alternatives --remove php /usr/bin/lcphp

Zitat von clickpress

Btw. verstehe ich nicht, warum ihr unbedingt über die GUI euren Server backupen wollt.

Wir nicht. Die Kunden wollen darauf zugreifen.

Zitat von stefanos

Bei der IPv4 wird wohl die erste IPv4 in der Liste genommen (oder Haupt-IPv4 vom Server) seitens Liveconfig/BIND9.
Dagegen bei IPv6 die letzte IPv6 aus der Liste wenn eine Meldung an PowerDNS raus geht seitens Liveconfig/BIND9..

Das ist das reguläre Verhalten bei Source-Adress-Auswahl, wenn die Adresse nicht explizit gesetzt wird.

Für IPv6 kann eine IP mit "preferred_lft 0" auf "nicht für ausgehende Verbindungen nutzen" gesetzt werden. Ob das dann das Mail-Outbound-IP-Szenario weiterhin funktioniert, weiß ich adhoc nicht.

Zitat von kk

Ich kenne Ihre Server nicht, aber dieses Verhalten basiert vermutlich auf einer lokalen "Spezialkonfiguration". Der Aufruf von logrotate (via cron.daily) erfolgt normalerweise um 06:25 (siehe /etc/crontab). Wenn bei Ihnen alles um 00:00 statt findet, dann passiert da vielleicht zu viel gleichzeitig.

Wie ich kürzlich (aka über Weihnachten) gelernt habe: es gibt in Debian Buster neben dem cron.daily-Cronjob auch einen logrotate.timer:

~# systemctl list-timers
NEXT                         LEFT       LAST                         PASSED       UNIT                         ACTIVATES
Wed 2020-12-30 00:00:00 UTC  11h left   Tue 2020-12-29 00:00:02 UTC  12h ago      logrotate.timer              logrotate.service

Das erklärt damit die 00:00 Uhr Ausführungen.

Fehlersuche sollte jedoch komplett im Journal über "journalctl -u logrotate.service" möglich sein.

Zitat von Mogwais

Wie macht ihr das? Schreibt ihr ne Mail?

Probleme gibt es da nur, wenn das betroffene Postfach zufälligerweise der Kontakt-Mailadresse entspricht.

Und dann meldet sich der Kunde von selbst, die Info-Mail hat er ja bekommen und kann sie anschließend abrufen.

Zitat von hermann

Der Hintergrund ist, wenn sich ein Kunde einen Spammer-Virus einfängt, schafft er es u.U. den Server (bzw. die IP) über Nacht auf alle möglichen Blacklists zu schießen.
Im Protokoll kann ich relativ schnell erkennen, woher die Spams kommen und könnte die Situation dann relativ minimalinvasiv entschärfen, indem ich für dieses Postfach ganz einfach den Mailversand stoppe bis der Kunde seinen PC gefunden und wieder im Griff hat.

Wir setzen ein neues Passwort für das Postfach und informieren den Kunden.

Somit kann dieser selbst aktiv werden und es muss keine Entsperrung vorgenommen werden.

Auch bekommt der Kunde aktiv mit, dass er ein Problem hat - und nicht erst, wenn er zufälligerweise eine Mail verschicken will.

Zitat

Leider kein Erfolg Bind nutzt immernoch die Anderen IPs für anfrage und notify

Sprich, wenn BIND ein ausgehendes Paket sendet, wird dafür die .1 als Source-IP verwendet?

Es soll aber die .4 genutzt werden?

Das ist kein BIND-Problem, sondern ein Linux-Problem, insbesondere dann, wenn das Programm, das die ausgehende Datenverbindung initiiert, die Quell-IP nicht explizit angibt.

Lässt sich daher so nicht lösen.

Zitat

- Ändern der /etc/dovecot/dovecot.conf würde helfen, ist aber nicht nachhaltig:

Die Änderungen in die dovecot.conf.local übernehmen und via "doveconf -n" verifizieren sollte reichen.