Beiträge von kk

  • Postfix Smarthost

    Direkt über die LiveConfig-Oberfläche geht das nicht (ist ja eher ein Sonderfall).


    Sie können aber die notwendigen Postfix-Einstellungen in einer .lua-Datei einrichten, so dass diese in die von LiveConfig generierte Postfix-Konfiguration mit aufgenommen werden.


    Legen Sie eine Datei namens /etc/liveconfig/lua.d/postfix.lua an, mit folgendem Inhalt:


    Code
    postfix.LOCALCONFIG = {
  ['relayhost'] = "relay.example.org"
}


    Oder - falls Sie sich per SMTP-Authentifikation (also wie ein SMTP-Client) am Relayhost anmelden müssen:


    Code
    postfix.LOCALCONFIG = {
  ['relayhost'] = "[relay.example.org]:587",
  ['smtp_sasl_auth_enable'] = "yes",
  ['smtp_sasl_password_maps'] = "static:SMTPUSER:SMTPPASSWORT",
  ['smtp_sasl_security_options'] = "noanonymous"
}


    (ungetestet, müsste aber eigentlich funktionieren)


    Anschließend LiveConfig neu starten (damit diese .lua-Datei eingelesen wird) und danach unter "Serververwaltung" -> "EMail" die Postfix-Konfiguration neu speichern lassen, damit die Einstellungen in die Konfiguration übernommen werden.


    Viele Grüße


    -Klaus Keppler

  • AddTrust Root-CA-Zertifikat / Debian 8, Ubuntu 16

    Hallo,


    weil uns derzeit immer wieder Anfragen dazu erreichen: am 30.05.2020 ist das weit verbreitete Root-CA-Zertifikat "AddTrust External CA Root" abgelaufen.


    In zwei Fällen ist das eventuell ein Problem:


    1. wenn man (fälschlicherweise) eben dieses Root-CA-Zertifikat als Intermediate-Zertifikat hinzugefügt hat. In diesem Fall wird das abgelaufene Zertifikat mit ausgeliefert, was je nach Client Probleme machen kann (moderne Browser sollten sowas aber ignorieren)
    2. wenn der Server noch OpenSSL 1.0.x verwendet; in diesem Fall liefert die Prüfung der Zertifikatskette einen Fehler, wenn da "ganz oben" ein abgelaufenes Zertifikat sitzt (auch wenn das eigentliche SSL-Zertifikat von einer inzwischen akzeptierten CA ausgestellt ist)


    Wer Debian 8 oder Ubuntu 16 einsetzt, sollte das (abgelaufene) Root-CA-Zertifikat aus dem Trust-Store entfernen, damit cURL etc. serverseitig keine Probleme machen. Hierzu die Datei /etc/ca-certificates.conf öffnen und ein Ausrufezeichen ("!") an den Beginn der Zeile von "mozilla/AddTrust_External_Root.crt" setzen:

    Code
    [...]
[B]![/B]mozilla/AddTrust_External_Root.crt
[...]


    Anschließend den Befehl update-ca-certificates ausführen.


    Zu den falsch konfigurierten Zwischenzertifikaten: wir erweitern LiveConfig aktuell, dass es beim Start alle SSL-Intermediates prüft und auf abgelaufene Zwischenzertifikate oder fälschlicherweise konfigurierte Root-CA-Zertifikate hinweist.
    Ursprünglich wollten wir diese auch automatisch löschen, das ist aber nicht ganz trivial, da eventuelle Ketten damit ungewollt unterbrochen werden könnten. Wir lassen uns da aber auch etwas einfallen.


    Viele Grüße


    -Klaus Keppler

  • Interessanter & gefährlicher Spam/Trojaner-Versand

    Guten Morgen,


    Ende letzter Woche informierten uns Hosting-Kunden über Spam-Mails, die mit deren Absendernamen versendet wurden. An sich (leider) nichts Besonderes - wäre es nicht so, dass die Spammails als Antwort auf tatsächliche E-Mails versendet wurden.
    (also so, als wenn man eine Mail im Postfach herholt, auf "Antworten" klickt und dann noch einen Trojaner-Anhang dazupackt).


    Wir haben dank umfangreicher Unterstützung zweier betroffener Postfachinhaber die Fälle analysieren können und sind zu folgenden Erkenntnissen gekommen:


    • Zugriffe auf diese Postfächer erfolgten zu 99,9% nur von den "üblichen" (deutschen) IPs aus. Aber: es gab einzelne (!) Zugriffe von ausländischen IPs (völlig unterschiedlich: USA, Hongkong, Vietnam, Russland, ...). Von so einer IP aus erfolgte aber nur ein einziger Zugriff (danach tauchte diese IP bis auf einen Fall nicht mehr im Mail-Log auf). Zudem gab es pro Tag meist nur 3-4 solcher "ausländischen" Zugriffe pro Postfach. Also immer schön unter dem Radar...
    • die Passwörter waren in vielen Fällen extrem simpel und erratbar, es war aber auch ein Kunde mit einem erfrischend komplexen Passwort betroffen. Dieser hatte dieses Passwort aber quasi überall verwendet (also auch auf anderen Websites/Shops).


    Wir gehen daher davon aus, dass es irgendeinen deutschprachigen Shop o.ä. gab/gibt, von dem die E-Mail-Adressen und Passwörter der Benutzer entweder im Klartext oder nur unzureichend geschützt abhanden gekommen sind.


    Der Versand der Spam/Trojaner-Mails erfolgt übrigens über andere SMTP-Server, sogar mit anderen (nicht passenden) Absenderadressen. Darüber lassen sich die Mails auch erkennen. Verfasst sind diese in deutscher Sprache, meist mit so etwas wie


    [INDENT]Sie müssen sich diese Berechnungen ansehen und überprüfen, ob sie korrekt sind.
    [/INDENT]
    oder
    [INDENT]Hier sind die Informationen, die Sie angefordert haben.
    [/INDENT]


    Um das eigene Mail-Log auf Auffälligkeiten zu untersuchen:

    1. Liste aller IMAP-Zugriffe erzeugen:
      grep 'imap-login: Login: user' /var/log/mail.log >/tmp/imap.log
    2. IP-Adressen sortieren & gruppieren:
      cut -d ',' -f 3 /tmp/imap.log | cut -b 6- | sort | uniq -c | less


    Vor allem Einträge mit nur 1 oder 2 Zugriffen aus "isolierten" Netzbereichen sollten überprüft werden (z.B. mit WhoIs). Stellt sich dann heraus, dass dieser Zugriff aus einem "fremden" Netz war, sollte man mit grep alle IMAP-Zugriffe auf dieses Postfach heraussuchen, die IPs extrahieren und das dann noch mal prüfen. Achtet darauf, dass es auch legitime Kunden in Hongkong, Kasachstan usw. geben kann die auf ihr Postfach zugreifen.


    Viele Grüße


    -Klaus Keppler

  • Ubuntu 20.04 mit MySQL 8.0

    Unsere Testumgebung für Ubuntu 20.04 LTS steht nun auch.
    Wie sich in den letzten Tagen herausgestellt hat ist der mit LiveConfig mitgelieferte MariaDB-Client (MariaDB Connector/C 3.1.8) leider nicht mit der auth_socket-Authentifizierung von MySQL 8 kompatibel. Wir klären das gerade mit MariaDB ab.
    Für Ubuntu 20 ist das also erstmal ein Showstopper, da der root-Account dort standardmäßig mit auth_socket eingerichtet ist (was ja prinzipiell nicht verkehrt ist). Workaround ist vorerst also die root-Authentifizierung umzustellen (wie in Beitrag #1 beschrieben).


    Mit LiveConfig v2.10.0-dev20200522.1 (aktuelle Preview, geht gleich online) funktioniert die Erkennung von MySQL 8 sowie das Anlegen/Bearbeiten/Löschen von Datenbanken. Hier waren aufgrund von Änderungen im Authentifizierungssystem ebenfalls Anpassungen erforderlich.


    Viele Grüße


    -Klaus Keppler

  • clamav unterbindet Mailversand

    Zitat

    WARNING: No clamd server appears to be available


    Ganz einfach: der ClamAV-Daemon (meist "clamd") läuft vermutlich nicht.
    Also: prüfen ob "clamd" läuft. Wenn nicht, Logs prüfen.


    Die häufigsten Ursachen sind:
    - zu wenig RAM (ClamAV ist äußerst speicherhungrig)
    - kaputte ClamAV-Datenbank

  • Ubuntu 20.04 mit MySQL 8.0

    Kurz gesagt: Ubuntu 20.04 wird aktuell von LiveConfig (v2.9.x) noch nicht unterstützt.
    Mit den Anpassungen für CentOS 8 sind wir durch, Ubuntu 20 startet diese Woche. Es dürfte also in den nächsten 1-2 Tagen ein Update der Preview-Version geben, mit dem dann zumindest die MySQL-Anbindung schon mal getestet wurde.


    Viele Grüße


    -Klaus Keppler

  • cgi-bin Erforderlich?

    Wie heißt denn Ihr CGI-Ordner?
    Weil /cgi-bin/ für alle Domains innerhalb des selben Vertrags immer auf /var/www/<Vertrag>/htdocs/cgi-bin/ gemapped wird (ScriptAlias-Anweisung). Um dieses Verhalten abzuschalten, müssten Sie im LiveConfig in den Vertrags-Einstellungen CGI deaktivieren.
    (nicht irritieren lassen; die Einstellung in ~/conf/httpd.conf erlaubt ja CGI dann wieder in den gewünschten Verzeichnissen)


    Ob die httpd.conf eingebunden wird sehen Sie z.B. durch einen Blick in /etc/apache2/sites-enabled/<Vertrag>.conf - da gibt es irgendwo dann eine include-Anweisung (einfach in der Datei mal nach "httpd.conf" suchen)


    Viele Grüße


    -Klaus Keppler

  • cgi-bin Erforderlich?

    So etwas fällt unter "exotische Sonderfälle". Man kann das einrichten, allerdings nicht über die Oberfläche.


    Legen Sie im Kunden-Home-Verzeichnis eine Datei namens "conf/httpd.conf" an (also z.B. /var/www/<Vertrag>/conf/httpd.conf). Tragen Sie da folgende Zeilen ein


    Code
    <Location "/beliebiger-cgi-ordner">
  SetHandler cgi-script
  Options +ExecCGI
</Location>


    Danach (!) speichern Sie im LiveConfig irgendeine Webspace-Einstellung dieses Vertrages neu (z.B: irgendeine Domaineinstellung mal kurz bearbeiten), damit die Apache-vHost-Konfiguration aktualisiert wird. Da wird diese httpd.conf dann mit eingebunden.

  • E-Mail-Blacklist: TLD Sperren

    Zitat von thopoh

    Soll heißen das die Blackliste die der User unter der E-Mailadresse eingibt garnicht alle Einträge die dort drinn stehen abweist?
    Das wäre ja Fatal! Wenn also SpammAssassin die Adresse als gut befindet geht sie durch und wird zugestellt?


    Nein. Die Blacklist/Whitelist-Einträge werden natürlich vom SpamAssassin mit oberster Priorität verarbeitet.
    Wenn der Absender auf der Blacklist steht bekommt die Mail praktisch 999 Spam-Punkte, bei der Whitelist -999 Punkte.


    Die Blacklist- und Whitelist-Einstellungen werden im LiveConfig unterhalb des Spamfilters konfiguriert und sind nur bearbeitbar, wenn die Checkbox beim Spamfilter gesetzt ist (=Spamfilter aktiviert ist).


    Wenn Mails dennoch durch kommen hat das definitiv einen Grund, den man am einfachsten anhand der Log-Einträge in /var/log/mail.log herausfinden kann.
    Wenn Sie sich bei der Interpretation der Meldungen unsicher sind, schicken Sie bitte mal von einer "geblacklisteten" Absenderadresse aus mal eine E-Mail und senden uns *alle* Log-Meldungen, die während der Mailzustellung in der mail.log protokolliert werden, an support@liveconfig.com

  • E-Mail-Blacklist: TLD Sperren

    Das Blacklisting/Whitelisting betrifft SpamAssassin, d.h. die Mail wird ggf. im Rahmen der Spam-Analyse abgelehnt.
    Eine Möglichkeit wenn "nichts" passiert wäre, dass SpamAssassin nicht läuft. Prüfen Sie daher bitte mal, ob die Prozesse "lcsam" und "spamd" existieren.

  • E-Mail-Blacklist: TLD Sperren

    Das Feature mit den TLD-Wildcards ist in v2.10 enthalten (aktuelle Preview-Version).


    Zum o.g. Beispiel: es kann z.B. sein dass die betroffenen Spam-Mails über irgendeine andere Adresse ins System kommen (also quasi über eine lokale Weiterleitung); es wird praktisch nur der "erste" Spamfilter ausgewertet.
    Beispiel: Weiterleitung von a@example.org an b@example.org. Wenn nun eine E-Mail an a@example.org eintrifft ist egal was bei b@example.org im Spamfilter konfiguriert ist.


    In /var/log/mail.log wird eigentlich ziemlich ausführlich protokolliert, was während einer Zustellung passiert. Ggf. müsste man anhand der Message-ID (die man in den Mailheadern auslesen kann) im Maillog suchen, was genau während der Zustellung gelaufen ist.

  • Vertrag zerschossen

    In der Datei /etc/dovecot/passwd sehen Sie die Zuordnung von E-Mail-Adresse (Postfach) zu Verzeichnisname (/var/mail/<Vertrag>/<Postfach-ID>/). Sie müssen also die Postfächer im LiveConfig neu anlegen, danach können Sie die Postfachinhalte aus dem Backup in die entsprechenden Verzeichnisse zurück verschieben.

  • Vertrag zerschossen

    Ihnen ist schon bewusst, dass das unnötige Ressourcen kostet wenn wir Ihnen die Frage erst am Telefon beantworten und Sie danach die exakt selbe Frage noch mal im Forum stellen...?


    Zitat

    Ein API Komando hat einen Vertrag in die ewigen Jagdgründe befördert.


    Was für ein API-Kommando soll das denn überhaupt gewesen sein?


    Zitat

    Wir haben bei dieser Gelegenheit festgestellt, das dass Backup der LC Datenbank nicht so läuft wie es soll, somit ist dass keine Option.


    Wie genau sichern Sie Ihre LiveConfig-Datenbank aktuell?


    Und zur eigentlichen Frage (wie auch am Telefon schon so beantwortet): wenn Sie Daten in LiveConfig löschen, dann sind diese weg. Wenn Sie kein Backup der LiveConfig-Datenbank haben, gibt es nur die Möglichkeit, den betroffenen Vertrag wieder neu anzulegen.


    Viele Grüße


    -Klaus Keppler

  • Preview: LiveConfig v2.10

    Natürlich.


    Ich halte persönlich überhaupt nichts davon, Mails automatisch in einen Spam-Ordner zu verschieben - das macht garantiert nur mehr Ärger. Die Zeit sollte man viel lieber in die Pflege & Tuning der Spamfilterung stecken, damit das Zeug überhaupt nicht erst rein kommt.

  • OPcache, Memcached und Liveconfig

    Nein, da hat sich nichts geändert - die Thematik hat schließlich mit der Architektur von PHP-FPM zu tun.
    So lange diese sich nicht grundlegend ändert, bleibt die Problematik mit Shared Memory und Opcache bestehen.


    Socket Activation haben wir auf der Ideenliste stehen, eine Umsetzung derzeit aber noch nicht geplant.


    Viele Grüße


    -Klaus Keppler

  • Zusätzliche PHP-Versionen nicht sichtbar

    Die direkt verlinkten .deb-Dateien sollten nicht verwendet werden, sondern nur das Repository.


    Dabei die selben Daten wie für Debian 9 verwenden - nur "stretch" eben durch "buster" ersetzen:

    Code
    deb http://repo.liveconfig.com/debian/ buster php