Beiträge von kk

Hallo,

vielleicht haben Sie bereits von der Sicherheitslücke in der Bourne Again Shell (kurz bash) gehört. Diese Lücke ist absolut kritisch. Wir haben in ersten Tests erfolgreich auch über PHP-Scripte, die via suPHP ausgeführt werden und die shell_exec-Funktion (bzw. Backticks) aufrufen, in eigene Testsysteme "einsteigen" können. Der eigentliche "Exploit" besteht quasi nur aus einem einzigen, spziell präparierten HTTP-Aufruf!

Im Gegensatz zu Heartbleed, welches ein mittel-/langfristiges Ausspähen verschlüsselter Daten ermöglichte, gibt es mit ShellShock einen sofortigen, unmittelbaren Serverzugriff! Potenziell verwundbare PHP-Scripte lassen sich mittels Suchmaschinen schnell finden.

Für PHP Wheezy wurde am 25.09. gegen 01:00 ein erstes Patch bereitgestellt; mit dem nun vorliegenden zweiten Patch (23:18) sollte die Lücke vollständig geschlossen sein. Für Debian Squeeze dürfte via LTS in Kürze auch ein weiteres Update erfolgen.

Für ältere Linux-Systeme gibt es nur zwei Möglichkeiten: manuell bash neu compilieren, oder mittels LD_PRELOAD-Trick einen Workaround installieren. Eine ausführliche Beschreibung haben wir in unserer Wissensdatenbank bereitgestellt: http://www.liveconfig.com/de/kb/23

Bitte nehmen Sie diese Sicherheitslücke sehr ernst! Aktualisieren Sie umgehend Ihre Server, oder installieren Sie das in KB#23 beschriebene Workaround. Nach Medienberichten existieren bereits die ersten automatisch verbreitenden Würmer.

Viele Grüße

-Klaus Keppler

Sie können die IPs des Kunden nur nicht als Admin bearbeiten. Wenn Sie eine Session als Kunde/Reseller starten, dann können Sie die IP-Einstellungen bearbeiten.

Wird trotzdem überarbeitet...

Eben wurde Version 1.7.4-r3086 mit folgenden Änderungen freigegeben:

• Fehler mit doppelten Schrägstrichen bei Apache-Weiterleitung beseitigt
• Fehler beim gleichzeitigen Hinzufügen meherere IPs zu einer Web-IP-Gruppe beseitigt
• Fehler 500 beseitigt, wenn man einen eigenen Vertrag ("Mein Hosting") aus den Top-10-Berichten angeklickt hat
• Übersetzungen aktualisiert
• konfigurierbares Präfix für SPAM-verdächtige Mails (LCDEFAULTS: mail.spam.prefix)
• Schnellsuche berücksichtigt nun auch Vertragsnamen in "Mein Hosting"

Vielen Dank für die Rückmeldungen!

Bezüglich der Auswahl der PHP-Versionen für NGINX: das ist etwas komplizierter: da NGINX ja nicht selbst die notwendigen FastCGI-Instanzen starten kann, haben wir hierfür ein Helfer-Script (/etc/init.d/nginx-php-fcgi). Dieses liest aus den NGINX-vHost-Konfigurationen jeweils aus, was für PHP-Instanzen gestartet werden sollen. Dort unterstützen wir derzeit nur eine PHP-Instanz pro Vertrag in NGINX.
Wir erweitern aktuell dieses Starter-Script sowie die notwendigen Anweisungen in den NGINX-vHosts, in Kürze* sollten also auch verschiedene PHP-Interpreter mit NGINX möglich sein.

*) voraussichtlich bis Ende kommender Woche

Eben wurde Version 1.7.4-r3086 mit folgenden Änderungen freigegeben:

• Fehler mit doppelten Schrägstrichen bei Apache-Weiterleitung beseitigt
• Fehler beim gleichzeitigen Hinzufügen meherere IPs zu einer Web-IP-Gruppe beseitigt
• Fehler 500 beseitigt, wenn man einen eigenen Vertrag ("Mein Hosting") aus den Top-10-Berichten angeklickt hat
• Übersetzungen aktualisiert
• konfigurierbares Präfix für SPAM-verdächtige Mails (LCDEFAULTS: mail.spam.prefix)
• Schnellsuche berücksichtigt nun auch Vertragsnamen in "Mein Hosting"

Vielen Dank für die Rückmeldungen!

Kurze Vorab-Info: DKIM wird ab der nächsten LC-Version (1.8.0) direkt unterstützt. Dabei bietet LC dann die Möglichkeit, Keys selbst zu erzeugen oder zu importieren, erstellt ggf. die dazugehörigen DNS-Records und konfiguriert OpenDKIM entsprechend.
Eine erste Vorab-Version dürfte in ca. 2 Wochen bereit stehen.

Hmm, Fehler gefunden: wenn in den LCDEFAULTS bei den ".enabled"-Feldern eine "1" gesetzt ist, dann wird diese Option auch aktiviert wenn die Checkbox nicht angehakt ist (ist ein unerwünschtes Verhalten unserer Formularklasse: wird eine Checkbox nicht gesetzt, wird diese natürlich auch nicht im HTTP-Request an den Server gesendet - uns hier fügt die neue LCDefaults-Funktion eben dann den Wert aus der Datenbank ein Merkwürdig, dass uns das nicht auch schon aufgefallen ist.

Ich empfehle daher, vorerst die .enabled-Werte in der LCDEFAULTS auf "0" stehen zu lassen. Die Fehlerbehebung ist recht einfach und dürfte morgen früh schnell erledigt sind.

Viele Grüße

-Klaus Keppler

Ach ja, zur nachträglichen Aktivierung (=Massen-Update aller Postfächer) ist auch schon eine Lösung in Arbeit - Details dazu dann auch bis Ende der Woche. Ein einfacher Eingriff in die DB genügt jedenfalls nicht, da die gewünschten Änderungen aktiv angetriggert werden müssen, damit der LC-Client-Prozess diese übernimmt.

Die Werte aus LCDEFAULTS werden nur beim Programmstart eingelesen - d.h. starten Sie LC bitte neu, dann sollten auch die neuen Werte gelten.

(Die Doku für LCDEFAULTS kommt noch bis Ende dieser Woche ins Handbuch ;))

Der Fehler wurde mit v1.7.4-r3082 beseitigt (wird in Kürze bereitgestellt).

Zitat von Ringelnatz

Mir sind noch zwei Dinge aufgefallen: Wenn ich eine Weiterleitung erstelle und als Ziel http://www.domain.de/* eingebe, erfolgt die Weiterleitung auf z.B. http://www.domain.de//index.php (man beachte die zwei Schrägstriche).

Ist mit v1.7.4-r3080 erledigt.

Zitat

Und bei mir sind die Tooltips für die Weiterleitung und die PHP-Version beim Bearbeiten einer Domain auf Englisch.

Ist mit v1.7.4-r3081 erledigt.

Eben wurde eine weitere Aktualisierung bereitgestellt (v1.7.4-r3079): nach Aktivierung vom SpamAssassin musste LiveConfig bislang neu gestartet werden, da es sonst die Spam-Einstellungen nicht in /etc/postfix/spamassassin angelegt hatte. Dieser Fehler (eine Zeile in Lua...) ist damit beseitigt.

Sie meinen vermutlich PHP 5.3.x für Debian 7?
Wurde eben aktualisiert, nun ist da auch das SOAP-Modul mit drin (php-5.3-opt_5.3.29-1+wheezy11_amd64.deb)

Einfach nur das Paket "spamassassin" installieren und LiveConfig neu starten - das war's.

Hallo,

es sieht so aus als ob die Spam-Einstellungen erst nach einem LiveConfig-Neustart in /etc/postfix/spamassassin geschrieben werden. Wer also das selbe Problem hat, einfach LiveConfig mal neu starten. Wir suchen bereits nach der Ursache...

Eben wurde noch eine aktualisierte Version bereitgestellt (v1.7.4-r3077), bei der die korrekten Spamfilter-Standardwerte für bestehende Postfächer voreingestellt sind. (3.0/5.0 statt 0/0).

Zitat von ManDal

Was aber immer noch ist das die /etc/postfix/spamassasin Datei bis auf den LiveConfig Header leer bleibt...

Haben Sie für irgendein Postfach (Hosting -> E-Mail -> Postfach bearbeiten) den Spamfilter aktiviert?

Ab sofort steht eine aktualisierte Version bereit (v1.7.4-r3077), bei der korrekte Spamfilter-Standardwerte für den Spamfilter voreingestellt sind.

Die Meldung "lcsam_lookup(Empfänger not found" heißt nur, dass lcsam bei einer eingehenden E-Mail an Empfänger keine Spamfilter-Einstellungen in /etc/postfix/spamassassin(.db) finden konnte - die E-Mail wird somit ungefiltert zugestellt.
Sobald Sie im LiveConfig bei einem konkreten Postfach die Spamprüfung aktivieren, sollte die betroffene Mailadresse (und alle Aliase) in die /etc/postfix/spamassassin mit aufgenommen werden. Passiert das nicht, dann prüfen Sie bitte mal die /var/log/liveconfig/liveconfig.log, ob dort irgendwelche Meldungen auftauchen.

Prüfen Sie bitte, ob in der Datei /etc/postfix/spamassassin ein Eintrag für die Empfängeradresse (hier: user@empfaenger.ch) existiert - danach sucht lcsam nämlich. Außerdem sollte die Datei /etc/postfix/spamassassin.db existieren jünger oder gleich alt wie die /etc/postfix/spamassassin sein.

Zitat von kk

Bei verdächtigen Mails wird (wie im Handbuch beschrieben) der Betreff modifiziert (***Spam-Verdacht***). Zudem sind im Mail-Header die Ergebnisse der SA-Analyse enthalten. Wenn Sie für Ihre Kunden einen ausführlichen Report wünschen, dann können Sie das gerne in der SpamAssassin-Konfiguration aktivieren.

Update: report_safe wird wohl doch nicht klappen, da lcsam nur die Ergebnisse der Spamprüfung vom SpamAssassin-Prozess ausliest. Es ist SA also nicht möglich, eine Mail zu modifizieren (in diesem Fall also z.B. einen Bericht vorzuschalten). Bei Bedarf können wir das längerfristig in lcsam mit aufnehmen.