Beiträge von kk

  • Apache2 mod_python

    Welche main.conf meinen Sie?
    Und um welche Distribution geht es?


    Unter Debian/Ubuntu wäre z.B. für globale Einstellungen das Verzeichnis /etc/apache2/conf.d/ bzw. conf-enabled der richtige Ort; für Module ggf. /etc/apache2/mods-enabled/<Modul>.conf

  • .html mit PHP ausführen

    Über den Sinn des ganzen reden wir an dieser Stelle besser mal nicht... ;)


    Code
    <FilesMatch "\.html$">
    Options +ExecCGI
    SetHandler fcgid-script
</FilesMatch>
FcgidWrapper /var/www/web1/conf/php5/php-fcgi-starter .html


    Im Grunde also das konfigurieren, was bislang für .php in der vHost-Konfiguration steht.

  • Logjam SSL-Angriff & LiveConfig

    Zitat von antondollmaier

    In der Liste fehlt Debian Wheezy :)


    Ups... Stimmt natürlich. Danke für den Hinweis, werde ich gleich aktualisieren.


    Zitat

    Gibt es dann für jeden Dienst eigene DH-Parameter oder werden die für jeden Host berechnet und dann bei allen Services deployed?


    Letzteres fände ich interessanter.


    Wir werden pro Dienst einzelne DH-Parameter erzeugen. Sooo gigantisch ist der Aufwand ja auch wieder nicht. ;)


    Zitat

    Kriegen wir in dem Zusammenhang dann auch automatische Updates der von LC verwalteten Config-Dateien hin? In der Vergangenheit gab es ja einige Verwirrungen, beispielsweise bei aktualisierten Ciphern, geänderten SSL-Zertifikaten oder Änderungen, die in einer neuen LC-Version mitgebracht wurden.


    Ja, das ist etwas kniffliger. Ob das in diesem Update schon mitkommt kann ich noch nicht versprechen, ist aber so geplant. Konkret hängt da die Sache mit dem Versand von Infomails durch LiveConfig mit dran (wir möchten nämlich nach einer Config-Aktualisierung zumindest mal eine Mail an den Admin zur Info senden).
    Noch eleganter wäre es, wenn der Admin entscheiden kann, ob er anstehende Änderungen an der Konfiguration automatisch übernehmen oder nur darauf hingewiesen werden möchte. ;)


    Viele Grüße


    -Klaus Keppler

  • Logjam SSL-Angriff & LiveConfig

    Vor wenigen Tagen wurden verschiedene Sicherheitsprobleme im Zusammenhang mit dem Diffie-Hellman-Verfahren bei verschlüsselten Verbindungen bekannt (siehe z.B. Heise Newsticker: "Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet").


    Wir haben uns inzwischen ausführlicher mit der Sache beschäftigt, und hier im Forum gab's an verschiedenen Stellen ja auch schon die ersten Diskussionen. Im Folgenden möchte ich etwas mehr Licht in die Sache bringen, einige Mißverständnisse beseitigen und unsere Strategie zu dieser Sache vorstellen.


    1. Weder LiveConfig noch mit LiveConfig verwaltete Dienste sind von "Logjam" betroffen.
    Mit "Logjam" wird der Angriffsvektor beschrieben, mit dem durch einen Man-in-the-middle-Angriff eine eigentlich sichere Verbindung auf unsichere Krypto-Parameter heruntergestuft wird. Das ist nur dann möglich, wenn der Server entsprechend unsichere Krypto-Parameter unterstützt - konkret ist hier von den "Export-Ciphers" die Rede.
    LiveConfig selbst und auch die damit konfigurierten Dienste (Apache, NGINX, Postfix, Dovecot, ProFTPD/vsftpd) verwenden keine Export-Ciphers. Wir konfigurieren die von dem Mozilla OpSec Team empfohlenen Ciphers.


    An dieser Stelle möchte ich übrigens dringend davon abraten, irgendwelche Cipher-Listen aus dem Internet zusammenzuklauben (konkret z.B. von der weakdh.org-Website), so lange man nicht genau weiß, was man da tut.


    2. LiveConfig nutzt eigene DH1024-Parameter
    Der zweite Angriffsvektor beruht auf der Vermutung von Forschern, dass Angreifer mit entsprechend großen Rechenkapazitäten (konkret: Geheimdienste, evtl. Industriespionage) die mit den am häufigsten genutzten Diffie-Hellman-Parametern erzeugten Schlüsseldaten knacken könnten.
    LiveConfig verwendet aktuell (v1.8.3) 1024-Bit Diffie-Hellman-Parameter, die von uns vor einer Weile individuell erzeugt wurden (sind also keine Standard-Daten). Dennoch sind diese "statisch" (also auf allen Servern gleich) und derzeit - wie das bislang eben üblich war - direkt im Code enthalten.
    Ein akutes Sicherheitsproblem besteht unsere Ansicht nach also nicht, weil es nach wie vor einen erheblichen Rechenaufwand benötigt, um die mit "unseren" DH-Parametern erzeugten Schlüsseldaten zu knacken.
    Nichts desto trotz - wir werden das ändern (s.u.).


    3. Apache 2.2 bleibt (vorerst) anfällig (Debian 6 LTS, Debian 7, Ubuntu 12.04 LTS, CentOS 5)
    Die Distributionen Debian 6 (Squeeze), Debian 7 (Wheezy), Ubuntu 12 und CentOS 5 liefern Apache httpd in der Version 2.2.x aus - in der sind die DH-Parameter ebenfalls "hardcodiert" und können somit nicht ersetzt werden. Die verwendeten DH-Parameter sind überall die selben; potenzielle Angreifer werden sich also zuerst die Arbeit machen, Dienste mit diesen extrem weit verbreiteten Parametern zu knacken.
    Unsere Empfehlung ist daher, diese "alten" Distributionen zu aktualisieren. Eventuell wird aber auch hier von den Distributionen ein Patch zurückportiert, der die DH-Parameter verwaltbar macht (bei CentOS 6 ist das nämlich der Fall - hier läuft auch ein httpd 2.2.x, der aber Änderungen aus der 2.4er-Reihe enthält).


    Unsere nächste Schritte
    Die Erzeugung von 2048bit DH-Parametern erfordert eine ganze Menge Rechenaufwand. Unsere Tests haben gezeigt, dass das auf einem handelsüblichen 3,0 GHz-System zwischen 20 Sekunden und fast 10 Minuten dauern kann - je nachdem, was der Pseudozufalls-Generator für Daten liefert. Wir haben daher beschlossen, künftig durch LiveConfig in einem Hintergrundprozess etwa alle zwei Wochen neue DH-Parameter für alle Services zu generieren; wenn diese "fertig" (berechnet) sind, ersetzt LiveConfig die dann selbständig im jeweiligen Dienst und startet den neu (Dovecot 2 macht das übrigens auch so).
    Unser Ziel ist es also, dass LiveConfig sich völlig selbständig darum kümmert, dass für alle Dienste regelmäßig neuer Krypto-Input generiert (und aktiviert) wird - ohne dass der Admin da nun alle paar Wochen irgendwelche Dateien austauschen muss.
    Das geht natürlich nicht von heute auf morgen, zudem muss das Ganze noch auf Kompatibilität mit anderen Systemen getestet werden. Die DH-Erzeugung wird also im nächsten Update (v1.9) enthalten sein, das Preview-Update mit dieser Funktion sollte Mitte/Ende nächster Woche soweit sein.


    Anfang kommender Woche werden wir auf unserer Website eine eigene Testseite bereitstellen, bei der man die DH-Parameter aller Services auf einmal durchtesten kann (und nicht nur Port 443 wie etwa bei SSLLabs oder WeakDH).


    Fazit
    Die Sache ist ernst zu nehmen, aber bei weitem sind die Server deshalb nun nicht "offen". Die Export-Ciphers sind durch LiveConfig abgeschalten, einziger Angriff ist also mit erheblichem Aufwand über stark verbreitete DH-Parameter denkbar. Soweit ich weiß stuft SSLLabs derzeit auch noch keine Bewertung herab, sondern weist lediglich auf die schwachen Parameter hin.
    In etwa einer Woche gibt's unsere Lösung zu diesem Thema.


    Bis dahin: schöne Pfingsten schonmal! :cool:


    Viele Grüße


    -Klaus Keppler

  • PHP 5.4.41, 5.5.25 und 5.6.9 freigegeben

    Die optionalen PHP-Pakete für Debian wurden eben auf die Version 5.4.41, 5.5.25 und 5.6.9 aktualisiert (siehe KB#22). Die Pakete stehen in den Repositories bereit.


    Für Debian 8 (Jessie) stehen ab nächster Woche auch PHP-Pakete zur Verfügung (geplant sind 5.3, 5.4 und 5.5).

    Viele Grüße


    -Klaus Keppler

  • Kritische Lücke in ProFTPD!

    Der ProFTPD-Fehler 4169 (CVE-2015-3306) erlaubt es unangemeldeten FTP-Benutzern, auf Dateien des Webservers zuzugreifen. Laut einem Bericht bei heise.de werde dieser Fehler derzeit aktiv ausgenutzt.


    Hier sind die Ergebnisse unserer Analysen, was mit LiveConfig verwaltete Systeme betrifft:


    • Der Fehler ist offenbar seit mindestens Mitte April 2015 bekannt (Quelle).
    • Debian 6 (Squeeze) ist nicht betroffen (dort ist mod_copy nicht enthalten)
    • Debian 7 (Wheezy) und Debian 8 (Jessie) sind betroffen (Debian Security CVE-2015-3306).


    Wir können aber in einem gewissen Umfang Entwarnung geben: in unseren Tests ließ sich auf Debian-Systemen kein Schadcode einschleusen/ausführen. Auch der von Heise verlinkte Exploit ist wirklungslos. Grund:

    • So lange kein Endkunde beim ProFTPD authentifiziert ist, läuft der betroffene ProFTPD-Prozess mit dem Benutzer "proftpd" und der Gruppe "nogroup".
    • Das beschriebene Angriffs-Szenario funktioniert indem eine ungültige Zieldatei mit einem PHP-Script als Dateinamen geöffnet werden soll; das schlägt natürlich fehl und dieser "Dateiname" wird in der ProFTPD-Logdatei protokolliert. Der Exploit schreibt bzw. verlinkt eben diese Logdatei dann in den Webspace des anzugreifenden Kunden.
    • Und genau das klappt bei mit LiveConfig verwalteten Servern nicht: der Benutzer "proftpd" hat keinerlei Zugriffsrechte auf Kunden-Verzeichnisse - nicht einmal lesend. Das heißt, es kann weder eine Datei mit Schadcode in irgendeinen Webspace geschrieben werden, noch können private Daten aus fremden Webspaces ausgelesen werden.


    Es steht aber nicht zur Diskussion, dass es sich hier um eine Sicherheitslücke handelt. Da nicht authentifizierte Benutzer zumindest in global schreibbaren Verzeichnissen (/tmp/ etc) Dateien (bzw. Symlinks) erzeugen können, bestehen andere Risiken (u.a. DoS).
    Wir empfehlen als Workaround, auf betroffenen Systemen einfach das Modul "mod_copy" zu deaktivieren:

    Code
    sed -i -e 's/^LoadModule mod_copy.c/# LoadModule mod_copy.c/g' /etc/proftpd/modules.conf
service proftpd restart


    Die Wahrscheinlichkeit, dass auf Debian-Systemen über diese Lücke Schadcode eingeschleust wurde, halten wir mit LiveConfig für ausgeschlossen.


    Tests mit CentOS und Ubuntu laufen derzeit noch, ein weiteres Update folgt in Kürze.

  • Kritische Lücke in ProFTPD!

    Ich schreibe gerade eine ausführliche Analyse (ist in ca. 10 min online). Vorab: es gibt noch kein Debian-Update, aber der Fehler ist unter Debian auch nicht wirklich kritisch. Details in Kürze...

  • Probleme mit lclogsplit unter Debian Jessie

    Die Syntax mit "|exec ..." funktioniert mit Apache 2.4 nicht mehr, dort muss das "||" heißen. LiveConfig schreibt schon seit längerer Zeit die "neue" Syntax in die liveconfig.conf - bei alten Installationen muss das aber eventuell angepasst werden. Wir werden das künftig in der Upgrade-Routine berücksichtigen.


    Die Lösung ist also, das "|exec " durch "||" zu ersetzen:

    Code
    CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" Liveconfig

  • Traffic-Graph fehlt bei einem Kunden

    Wie schaut denn die access.log-Datei vom betroffenen Kunden aus - tauchen da überhaupt aktuelle Einträge drin auf?
    (/var/www/<Vertrag>/logs/access.log)


    Wenn nein: laufen die Domains dieses Kunden eventuell mit NGINX?

  • Autoresponder funktioniert nicht...

    Zitat von Robbi

    könnten Sie uns mitteilen, wie genau der Zeitraum ist, bevor wieder eine automatische Antwort an die gleiche Adresse gesendet wird? Und ob ggf. wo man das verändert kann?


    Dovecot-Sieve nutzt die standardisierte "vacation"-Routine. Der Parameter "days" entscheidet, nach wie vielen Tagen erneut eine Antwort gesendet werden soll: https://tools.ietf.org/html/rfc5230#section-4.1
    Standard-Einstellung ist 1 Tag - kürzere Intervalle gehen also nicht (ohne weiteres).
    Dieser Wert wird auch durch LiveConfig in die sieve-Datei der jeweiligen Postfächer geschrieben (dovecot.lua, Zeile 837).

  • Manuelle Änderungen an .htaccess

    LiveConfig fasst .htaccess-Dateien in Webspace-Verzeichnissen nicht an.
    Der Passwortschutz durch LC wird direkt in der vHost-Konfiguration (/etc/apache2/sites-available/...) eingetragen.


    Viele Grüße


    -Klaus Keppler

  • SSH-Zugänge für Endkunden

    Zitat von weltmeister

    Kann es sein, dass seit dem letzten Update die SSH-Zugänge für die Endkunden nicht mehr funktionieren?


    Das kann ich zumidnest schon mal ausschließen - LiveConfig ändert definitiv nichts an SSH-Zugängen.


    Die einzige richtige Antwort liefern auch in diesem Fall nur die Logfiles - unter Debian insbes. /var/log/auth.log

  • Roundcube 500er Servererror!

    Zitat von aziegler

    Herr Keppler, könnten Sie bitte für den App-Installer nicht einfach das "roundcube....-complete" Paket benutzen?
    da wäre Pear&co. schon enthalten!


    Ist nun umgestellt - ab sofort installiert der AppInstaller das "roundcube-xxx-complete"-Paket.