Beiträge von kk

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Zitat von RB-Media-Group

    Es werden nun nicht nur SET HANDLER bemängelt, sondern auch:


    AddDefaultCharSet
    FileETag


    Dann haben Sie eine frühere LiveConfig-Version aus dem Test-Repo installiert (vermutlich v2.7.4 <r5214).


    Das Test-Repository kann immer wieder mal instabile Versionen enthalten, wir raten daher DRINGEND davon ab, dieses Repository für die "regulären" Server zu nutzen.


    In diesem Fall müssen Sie folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:

    SQL
    UPDATE LIVECONFIG SET LC_VALUE='0005102' WHERE LC_KEY='dbschema' AND LC_VALUE = '0005103';


    Installieren Sie anschließend die aktuelle Version (2.7.4-r5214).


    Viele Grüße


    -Klaus Keppler

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    [UPDATE 20.08.2019]
    Mit LiveConfig v2.8.0 haben wir eine andere Lösung zur Vermeidung der zugrundeliegenden Sicherheitsprobleme implementiert.
    SetHandler und "AllowOverride FileInfo" sind mit LiveConfig v2.8 also wieder problemlos (und risikolos) möglich.
    [ENDE]


    Hallo,


    kürzlich hat uns ein Kunde auf ein mögliches Sicherheitsrisiko in der Apache-Konfiguration aufmerksam gemacht. Nach kurzer Prüfung konnten wir das Problem bestätigen und haben seitdem einen entsprechenden Patch erarbeitet.
    Das Problem ist, dass es sich hier um keinen klassischen "Bug" handelt, sondern Apache in einem bestimmten Zusammenhang schlicht keine Sicherheitsprüfung vornimmt. Bevor wir die Details näher beschreiben möchten wir aber allen Kunden noch genügend Zeit geben, um das Update zu installieren.


    Besonders auf Servern, auf denen PHP-FPM läuft, sollte dieses Update möglichst zeitnah eingespielt werden.
    Es besteht kein Risiko "von außen". Ein möglicher Angriff müsste lokal erfolgen und setzt einige Kenntnisse über die jeweilige Serverkonfiguration voraus - wir schätzen die Sache also nicht als hochkritisch, aber dennoch ernst ein.
    Weniger kritisch ist das Thema bei Servern, bei denen PHP-FPM nicht aktiviert ist oder nicht genutzt wird - aber auch hier empfehlen wir das Update bei Gelegenheit durchzuführen. Reine NGINX-Webserver sind nicht betroffen.


    Das Update (v2.7.4) aktualisiert automatisch alle Apache-vHost-Konfigurationen wie folgt:

    • die AllowOverride-Option "FileInfo" wird entfernt
    • statt dessen werden die erlaubten Anweisungen in AllowOverrideList aufgeführt


    Die Anweisung "SetHandler" ist damit ab sofort nicht mehr in .htaccess-Dateien erlaubt!


    Jede "normale" Web-Anwendung benötigt keine SetHandler-Anweisung in .htaccess. Traurige Ausnahme ist Drupal: dort enthält u.a. /sites/default/.htaccess entsprechende SetHandler-Anweisungen, um die Ausführung von hochgeladenen Dateien zu verhindern (was ohnehin ein merkwürdiges Sicherheitskonzept ist, aber da hat Drupal noch ganz andere Probleme...).
    Informationen zur .htaccess-Thematik bei Drupal haben wir (white-labeled) vorab hier bereitgestellt: https://hostinghandbuch.de/apps.drupal.htaccess
    Am Ende dieser Seite ist auch ein Aufruf aus find und sed angegeben, mit dem man alle Drupal-.htaccess-Dateien auf einem Server rekursiv patchen kann (Ausführung auf eigene Gefahr!).


    Bei Multi-Server-Umgebungen ist es egal, ob das Update zuerst auf dem Server oder auf den Clients installiert wird.


    Wir empfehlen Ihnen folgendes Vorgehen:

    • Installation des Updates auf allen Servern mit Apache
    • Identifikation aller Kunden, die .htaccess-Dateien mit SetHandler-Anweisungen verwenden:

      Code
      find /var/www -type f -name .htaccess -exec grep -Hi "^\s*sethandler" {} \;


    • Information der betroffenen Kunden, dass SetHandler nicht mehr genutzt werden darf
    • ggf. automatisches Patchen der betroffenen .htaccess-Dateien

      • zuerst speziell für Drupal:

        Apache Configuration
        find /var/www -type f -name .htaccess -exec \
sed -e 's/^\(\s*Options\s\+\)+FollowSymLinks/\1+SymLinksIfOwnerMatch/i' \
    -e 's/^\(\s*\)\(SetHandler Drupal_Security_Do_Not_Remove.*\)/\1# \!\!\! SetHandler disabled - see https:\/\/hostinghandbuch.de\/apps.drupal.htaccess\n\1#\2\n\1RewriteEngine On\n\1RewriteRule .+\\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$ - [F,L]/i' \
    -i {} \;





    [LIST=|INDENT=2]
    [*]dann für alle restlichen .htaccess-Dateien:

    Code
    find /var/www -type f -name .htaccess -exec \
 sed -e 's/^\(\s*SetHandler\)/# \!\!\! SetHandler disabled - see https:\/\/hostinghandbuch.de\/apps.drupal.htaccess\n#\1/i' -i {} \;


    [/LIST]

    Bei Fragen stehen wir gerne zur Verfügung.


    Viele Grüße


    -Klaus Keppler

  • "Top-10-Verträge ---> E-Mails" bleibt leer

    Starten Sie bitte mal LiveConfig (bzw. falls Multi-Server: nur den lcclient) auf dem betroffenen Server neu, und prüfen dann nach ca. 15-20 Minuten, ob dann Daten erscheinen.


    Machen Sie zudem eine Kopie von /var/lib/liveconfig/smtp.stats und prüfen ebenfalls nach ca. 15 Minuten mal per "diff", ob sich in der Datei etwas geändert hat.


    (diese beiden Ansätze helfen dabei, die mögliche Ursache weiter einzugrenzen)

  • "Top-10-Verträge ---> E-Mails" bleibt leer

    Prüfen Sie sicherheitshalber per "ps aux | grep lclogparse" ob der Prozess auch wirklich läuft (systemd alleine ist nicht vertrauenswürdig ;)
    Wenn ja, prüfen Sie ob /var/lib/liveconfig/smtp.stats aktuell ist (sollte max. alle 5 Minuten aktualisiert werden). Da sollten dann auch die aktuellen Statistikdaten (roh) drin stehen.
    Zuletzt ggf. noch die lclogparse-Konfiguration prüfen: /etc/liveconfig/lclogparse.conf (am besten mal per "diff" mit einer Datei von den anderen Servern vergleichen, wo's funktioniert).

  • Weiterleitungen deaktivieren

    Kommt mit der nächsten Version (2.8).
    (um genau zu sein: wurde in r5157 implementiert, es gibt dann einen LCDefault-Schlüssel "mail.forwards.blacklist", mit dem man bestimmte Domains als Weiterleitungsziel verbieten kann)


    Nachtrag: ein Dropdown zur Auswahl lokaler Domains als Ziel haben wir als Feature Request mit aufgenommen. Da kam noch die Idee hinzu, dass Admins zusätzliche Weiterleitungen frei anlegen können (damit man z.B. "hostmaster@example.org" auf eine zentrale Adresse beim Webhoster umleiten kann).

  • Auswahl Pfad wählen unter Domains bleibt leer

    Zitat von trg2889

    Nginx läuft unter folgenden Rechten:nginx/nginx


    Das wird vermutlich genau das Problem sein.
    /var/www/<Vertrag>/htdocs/ gehört <Vertrag>:www-data (mode=0750), der User "nginx" kommt da also nicht rein.
    Unter Debian ist es üblich, dass NGINX auch als www-data:www-data läuft. Das müsste also angepasst werden, dann sollte alles funktionieren.

  • PHP7 ./configure Optionen

    PHP 7 unter Ubuntu 14 wird dann ohnehin eine Herausforderung, weil die meisten von PHP7 benötigten Bibliotheken gar nicht unter Ubuntu 14 verfügbar sind (einfachstes Beispiel: OpenSSL 1.1).
    Ich empfehle dringend ein Dist-Upgrade auf Ubunru 16, damit hält man sich viele Probleme vom Hals. Und es tut auch gar nicht weh. ;)

  • PHP7 ./configure Optionen

    Naja, im einfachsten Fall nur "./configure" ausführen. Alles weitere kommt eben darauf an, was man braucht und wo PHP installiert werden soll.
    Es würde daher auch nichts nutzen, wenn ich die configure-Aufrufe für die von uns bereitgestellten Pakete heraussuche - die Parameter variieren zwischen allen Distributionen und den zu bauenden Extensions.
    Vom Bau eigener PHP-Pakete rate ich daher dringend ab, so lange man nicht genau weiß was man tut.
    Lieber unsere Pakete oder die von deb.sury.org verwenden.

  • PHP 5.6.40, 7.1.26, 7.2.14 und 7.3.1

    Immer wenn ein "500 Internal Server Error" generiert wird, erzeugt Apache auch einen Eintrag in der /var/log/apache2/error.log (bzw. wenn im LiveConfig unter "Webspace" der Punkt "Fehlerprotokoll aktivieren" eingeschaltet ist, im dortigen error.log).
    Diese Fehlermeldung hilft sicher weiter.

  • PHP 5.6.40, 7.1.26, 7.2.14 und 7.3.1

    Zitat von dicker

    Ich habe es jetzt bei zwei Kunden Accounts getestet. Da hat es funktioniert.


    Stelle ich eine Domain, die unter *Mein Hosting* registriert ist auf 5.6.4 um, dann kommt immer error.


    Dann vergleichen Sie mal, wie die PHP-Ausführung konfiguriert ist (Vertragseinstellung) - FastCGI, suPHP oder FPM. Das wird beim "eigenen" Vertrag und bei den Kunden vermutlich unterschiedlich sein.
    Die Ausgabe von liveconfig --diag ist leider zu sehr gekürzt - die ganze Liste der PHP-Versionen fehlt da. Da würde nämlich stehen, welche PHP-Version wie verfügbar ist (FPM/FastCGI).

  • GitHub

    Zitat von weltmeister

    Momentan geht die Entwicklung für viele gewünschte Erweiterungen sehr schleppend voran... oder täuscht das?


    Die Release-Häufigkeit hat nichts mit der Entwicklungsgeschwindigkeit zu tun.
    Es tut sich im Moment *sehr* viel, nur können wir das noch nicht alles gleich freigeben. Bitte noch ein klein wenig Geduld. In v2.8 gibt es große Änderungen.

  • date.timezone nicht gesetzt in .../php56/php.ini

    Zitat von sTeaLth

    Ist die Option "date.timezone" in php56 noch kein Standard oder warum wird diese nicht gesetzt


    Soweit ich weiß ist diese Option standardmäßig in der php.ini auskommentiert. (PHP kann ja nicht wissen, in welchem Land es gerade eingesetzt wird)


    Die sauberste Lösung ist:

    • im LiveConfig als "admin" anmelden
    • zur php.ini-Verwaltung gehen
    • dort einen neuen Eintrag vom Typ "Zeichenkette" anlegen. Name="date.timezone", Wert="Europe/Berlin". Änderungen durch den Kunden ggf. erlauben.


    Damit landet diese Einstellung dann in allen mit LiveConfig genutzten PHP-Versionen.


    Viele Grüße


    -Klaus Keppler

  • DEBUG Problem

    Ihr CMS hat sich irgendeine Malware eingefangen.
    Von dieser URL wird Code nachgeladen, der dann auf dem Webserver ausgeführt wird (häufig irgendwas um Malware/Trojaner weiter zu verteilen).


    Lassen Sie am besten mal einen lokalen Malware-Scan laufen (z.B. Linux Malware Detect).


    Die Website an sich sollte schleunigst abgeschaltet werden, bevor diese bei Google etc. auf einer Blacklist landet.