Beiträge von kk

    Ab sofort steht LiveConfig v1.7.5 (r3122) als Preview zum Download bereit.
    Wir haben uns dazu entschlossen, noch mal eine Zwischenversion vor der v1.8 herauszugeben, welche die aktuell bekannt gewordene SSLv3-Sicherheitslücke betrifft.


    Die Änderungen sind:

    • Aktualisierung der OpenSSL-Bibliothek auf die heute freigegebene Version 1.0.1j
    • Deaktivierung von SSLv3 in LiveConfig (HTTPS/LCCP)
    • Deaktivierung von SSLv3 in allen von LiveConfig verwalteten Diensten (s.u.!)


    Zudem wird nun für HTTPS auf gemeinsamen IPs (also mit SNI) automatisch ein Standard-SSL-Zertifikat erzeugt.


    Um die Konfigurationen der von LiveConfig verwalteten Dienste zu aktualisieren, gehen Sie bitte wie folgt vor:

    • Apache/nginx: irgendeine IP-Gruppe bearbeiten (z.B. an den Namen irgendein Zeichen anfügen) & speichern
    • FTP: Button "neu konfigurieren" klicken
    • Postfix: Button "bearbeiten..." klicken und dort direkt auf "speichern"
    • Dovecot: Button "bearbeiten..." klicken und dort direkt auf "speichern"


    Wir testen die neue LiveConfig-Version morgen Vormittag noch ausführlich durch; wenn keine Fehler auftauchen (bzw. gemeldet werden ;)) dann wird die neue Version morgen Nachmittag produktiv freigegeben.


    Viele Grüße


    -Klaus Keppler

    So, die Änderungen sind alle eingecheckt und werden nun von unserem Jenkins compiliert & getestet (das dauert noch eine Weile...). Sobald die Pakete fertig sind gebe ich noch mal Bescheid.


    Die geänderten Einstellungen sind:

    • Apache:
      [highlight]SSLProtocol ALL -SSLv2 -SSLv3[/highlight]
    • nginx:
      [highlight]ssl_protocols TLSv1;[/highlight] (bzw. [highlight]ssl_protocols TLSv1 TLSv1.1 TLSv1.2;[/highlight] mit nginx 1.1.13+ und 1.0.12+)
    • Postfix:
      [highlight]smtpd_tls_protocols = !SSLv2, !SSLv3[/highlight] (Postfix v2.6+)
      [highlight]smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3[/highlight] (Postfix v2.5)
      [highlight]smtpd_tls_mandatory_protocols = TLSv1[/highlight] (Postfix <v2.5)
    • Dovecot:
      Dovecot 1.x: SSLv3 kann nicht abgeschaltet werden (s.u.)
      Dovecot ab 2.1: [highlight]ssl_protocols = !SSLv2 !SSLv3[/highlight]
    • ProFTPd:
      [highlight]TLSProtocol TLSv1[/highlight]
    • vsftpd:
      keine Änderung notwendig, SSLv3 war bereits deaktiviert (ssl_sslv3=NO)


    Bei Dovecot 1.x/2.0 lässt sich SSLv3 nicht abschalten (zumindest nicht ohne den Code zu patchen). Das ist aber auch nicht dramatisch, da die POODLE-Attacke voraussetzt, dass der Angreifer die Daten beeinflussen kann, die zum Server gesendet werden - wie auch bei den BEAST- und CRIME-Angriffen. Das klappt in der Praxis nur dann mit realistischem Aufwand, wenn man in eine Webseite JavaScript-Code einschleust und den Datenverkehr komplett abhören kann (z.B. mit WLAN-Proxies). Da bei POP3/IMAP-Zugriffen praktisch kein Einfluss auf die vom Client zum Server gesendeten Daten genommen werden kann, ist ein Angriff dort (nach derzeitigem Wissensstand) praktisch nicht möglich.


    Insgesamt ist der POODLE-Angriff ernst zu nehmen, aber nicht annähernd so schlimm wie Heartbleed oder Shellshock. Es handelt sich um einen Angriff auf den Client (konkret: auf den Webbrowser), der auch nur dann möglich ist, wenn man die komplette Kommunikation zwischen Client und Server "abhören" kann (insbes. also bei WLANs).

    NEIN!!!!
    MACHT DAS NICHT!!!


    Das ergibt eine inkonsistente Datenbank!
    Die LiveConfig-Datenbank verwendet sog. "Nested Sets" zur relationalen Organisation der Hierarchien - da sind deutlich mehr UPDATE-Befehle notwendig. Von Hand ist das kaum machbar!


    Verträge verschieben geht ausschließlich über die LC-Oberfläche (Vertrag bearbeiten -> Button "neu zuordnen..." klicken)

    Ich verweise kurz und knapp auf einen Artikel bei Heise Online: Poodle: Experten warnen vor Angriff auf Internet-Verschlüsselung.


    Kurz gesagt: das SSLv3-Protokoll ist verwundbar, Experten empfehlen dieses auf Servern zu deaktivieren.


    Wir arbeiten bereits an einem LiveConfig-Update, um alle von LiveConfig verwalteten Dienste entsprechend zu konfigurieren. Ich gebe Bescheid sobald wir das Update fertiggestellt & getestet haben (vorraussichtlich noch heute Abend).


    Viele Grüße


    -Klaus Keppler

    Wurde eben aktualisiert (siehe KB#22).
    Außerdem bauen wir künftig in die PHP-Pakete die Suhosin-Erweiterung mit ein. Diese ist standardmäßig deaktiviert, macht gerade im Shared Hosting aber viel Sinn (u.a. können so alle durch PHP-Scripte hochgeladenen Dateien automatisch durch einen Virenscanner (ClamAV) untersucht werden!)


    Viele Grüße


    -Klaus Keppler

    Die Option, alle Endkunden eines Resellers mit zu löschen wird in Kürze auch verfügbar sein, einen genauen Termin dafür kann ich aber noch nicht nennen.
    (das hat technische Gründe - es reicht nicht eben einfach nur alle Datensätze in der Datenbank zu markieren, sondern LC muss im Grunde abwarten bis alle Kundenaccounts von eventuell verschiedenen Servern komplett gelöscht sind, bevor der Reseller dann schlußendlich auch gelöscht werden kann).

    Nachtrag: ich hatte das nur mit dem IE unter Windows XP getestet. Wenn ein Browser mit SNI-Unterstützung auf den Server zugreift, kommt tatsächlich die Seite vom zuerst konfigurierten SSL-vHost - trotz der SSLStrictSNIVHostCheck-Einstellung. :|
    Wir werden LiveConfig so anpassen, dass bei SSL auf Shared IPs (=SNI) automatisch ein selbst-signiertes Zertifikat erzeugt wird, welches dann auf die Standard-Fehlerseite ("Diese Domain ist nicht verfügbar...") verweist. Müsste im Laufe dieses Tages fertig sein.


    Viele Grüße


    -Klaus Keppler

    auch bei mir bringt der o.g. Code keine Veränderung :(


    Was für eine Veränderung erwarten Sie denn?
    Mit dieser Einstellung (SSLStrictSNIVHostCheck=on) werden keine Inhalte von "fremden" Seiten mehr angezeigt, falls der Browser kein SNI unterstützt bzw. falls er über einen "falschen" Hostnamen auf den Server zugreift (in diesem Fall antwortet Apache mit einem 403 - Forbidden).
    Dass dem Besucher aber auch in diesem Fall irgendein SSL-Zertifikat präsentiert wird lässt sich nicht ändern (siehe oben). Wenn ein Browser eine SSL-Verbindung anfordert, dann muss der Server ja mit irgendwas antworten. Die einzige saubere Lösung besteht eben darin, SSL-Websites auf eine separate IP-Adresse zu legen. Das hat nichts mit LiveConfig zu tun, sondern mit den technischen Grundlagen von SSL.

    Das Problem ist, dass bei "klassischem" SSL erst der SSL-Handshake stattfindet, und dann der HTTP-Request erfolgt. Mit anderen Worten: pro SSL-Zertifikat braucht(e) man eine eigene IP-Adresse; man kann keinen "anderen" Content zuverlässig auf der selben IP hosten.
    SNI verschafft da theoretisch Abhilfe - funktioniert allerdings nicht mit dem IE unter Windows XP u.ä. (was immerhin noch rund 10% der Internetnutzer betrifft).


    Legen Sie die Datei /etc/apache2/conf.d/sni mit folgendem Inhalt an:

    Code
    <IfModule mod_ssl.c>
    SSLStrictSNIVHostCheck on
    </IfModule>


    Starten Sie Apache danach neu. Mit dieser Einstellung (SSLStrictSNIVHostCheck on) sollten dann nur noch "richtige" SNI-Zugriffe durchgestellt werden. Beachten Sie aber bitte, dass eben noch nicht alle Browser SNI beherrschen.


    Viele Grüße


    -Klaus Keppler

    Code
    aptitude search php | grep opt


    Oder noch einfacher: einen Blick in KB#22 werfen. Dann werden Sie feststellen, dass wir für Debian Squeeze gar kein optionales PHP 5.3 Paket bereitstellen (schließlich gibt es das da direkt von Debian).

    Ab sofort steht ein kleines Update bereit (v1.7.4-r3112), welcher einen Fehler bzw. ein Problem mit den neuen Tabellen beseitigt.
    (Wenn man z.B. einen Kunden mit 30 Domains geöffnet hat, in der Domainliste auf die Seite 2 blätterte und danach einen Kunden mit z.B. nur 5 Domains öffnete, dann wurden dort gar keine Domains mehr angezeigt (weil die Tabelle noch auf "Seite 2" stand).)


    Viele Grüße


    -Klaus Keppler

    der Style und die Formatierung für die Cron-Jobs muss sicher noch anlag zu den anderen Tabellen angepasst werden. Das sieht so nicht ganz normal aus. Herr Keppler machen Sie es bitte noch ? :)


    Danke für den Hinweis, wurde eben aktualisiert (r3110). Die Cron-Jobs sowie übrigens auch die Datenbanken waren auch noch nicht sortierbar.


    Zitat

    Also bei Weiterleitungen kann eine Sortierung schon Sinn machen wenn es nur ein Ziel gibt und man so alle Weiterleitungen zu dem Ziel finden will.


    Wenn man alle Weiterleitungen zu einem Ziel finden will, dann braucht man das nur ins Suchfeld der Tabelle eingeben - so bekommt man alle Treffer, auch wenn ein Postfach zusätzlich noch an andere Ziele weitergeleitet wird.


    Zitat

    Nun, wenn das neue, fehlerfreie Release veröffentlicht wurde, wollte ich nachfragen, wann kommt das nächste Release?


    Wenn's fertig ist. ;)
    Aktuell werden die Änderungen für's neue Templatesystem (HTML5/CSS) umgesetzt, eine erste Preview dürfte nächste Woche verfügbar sein. Insgesamt stehen derzeit aber keine "großen" Teilprojekte an, so dass wir voraussichtlich alle 4-6 Wochen jeweils neue Funktionen releasen werden.


    Zitat

    ist es gewünscht das die Suchen bzw. den Begriffe auch nach dem aus und wieder einloggen gespeichert sind?


    Ja, das ist so beabsichtigt; falls das zu verwirrend ist können wir das ggf auch wieder rausnehmen.


    Viele Grüße


    -Klaus Keppler

    Der "ar" von BSD und GNU unterscheidet sich leider etwas - der von GNU fügt (warum auch immer) intern noch einen Schrägstrich an den Dateinamen an. Dieser führt dann auch zu Problemen mit dpkg-sig.


    Ab Version 1.8 werden wir die Debian-Pakete anders bauen (also nicht mehr mit ar), um künftig u.a. die Repo-Files automatisiert auf korrekte Signaturen prüfen zu können. In Kürze sollte sich dieses Problem also erledigt haben.


    Viele Grüße


    -Klaus Keppler

    Eine Sortierung ist nur in den Spalten möglich, wo das auch einen Sinn macht. Da für Aliase/Weiterleitungen mehrere Einträge pro Postfach existieren können, ist eine alphabetische Tabellensortierung danach eher sinnlos. Diese Felder werden aber in der Filterung berücksichtigt.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ab sofort steht LiveConfig v1.7.4-r3109 zum Download (als "Stable-Version") bereit. Die zwei wichtigsten Änderungen sind:

    • überarbeitete Tabellen (sortierbar, Einstellungen werden gespeichert)
    • Fehler im LCCP-Parser beseitigt, der in seltenen Fällen zum "Stillstand" des Client-Prozesses führen konnte*


    Das Update steht auch in den Repositories bereit und kann wie immer reibungslos installiert werden.


    Viele Grüße


    -Klaus Keppler


    *) zu diesem Fehler muss ich etwas ausholen :)
    Einige Kunden berichteten davon, dass ab und zu LiveConfig keine Aktionen mehr ausführte (z.B. Anlegen von Datenbanken oder Löschen von Postfächern). Wir konnten dieses Verhalten hier bislang aber nicht reproduzieren.
    Dank der Unterstützung einiger LiveConfig-Kunden (namentlich besonderen Dank an aziegler und mgoeben!) konnte der Fehler nun lokalisiert werden: er trat ausschließlich dann auf, wenn mehrere "große" LCCP-Nachrichten vom Server- an den Clientprozess gleichzeitig gesendet wurden und deren Header an einer ganz bestimmten Position im Lesepuffer auftauchte (es handelte sich um 15 Byte in einem 4096 Byte großen Lesepuffer).
    Der Fehler ist nun endlich beseitigt und war auf diese eine recht spezielle Parser-Funktion beschränkt.

    Hallo,


    für Gentoo steht nun r3108 als Preview bereit. Ich hatte am Samstag offenbar nur einen Teil der Backtrace-Ausgabe überarbeitet (nur den Teil für den Server-Prozess, nicht aber den für den Client-Prozess :(). Ich bin optimistisch, dass uns ein Backtrace zur Wurzel des Übels führen dürfte; falls das nicht hilft würde ich gerne das SSH-Angebot in Anspruch nehmen (dazu würde ich mich aber noch mal separat melden).
    Auf unserer Test-VM mit Gentoo haben wir bislang übrigens keinen SEGFAULT im Log feststellen können. :/


    Viele Grüße


    -Klaus Keppler