Beiträge von kk

  • host mail.xxxx.tld[173.xxx.xxx.xxx] said: 521 5.7.1

    Zitat von Citytow
    Code
    <info@xxxxx.de>: Recipient address rejected: Domain disabled (in reply to
    RCPT TO command)


    Wie die Meldung schon sagt: die Domain ist deaktiviert. Soweit ich weiß müsste diese Meldung nur dann erscheinen, wenn im LiveConfig beim betroffenen Vertrag E-Mail deaktiviert wurde.
    (also mal auf "Vertrag bearbeiten" klicken und schauen, was bei "Status" eingestellt ist (aktiv/gesperrt/deaktiviert).


    Viele Grüße


    -Klaus Keppler

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Also, Drupal trickst da ganz schön mittels .htaccess herum.
    Vereinfacht gesagt: in der .htaccess-Datei im Hauptverzeichnis wird eine RewriteRule gesetzt, welche Zugriffe auf nicht vorhandene Dateien pauschal durch index.php routet. Die Rewrite-Anweisungen in sites/default/files/.htaccess setzen alle anderen RewriteRules zurück - daher kommt es zu einem "403".


    Die Lösung ist also, das Routing nicht vorhandener Dateien auf die /index.php auch in die untergeordnete .htaccess aufzunehmen:

    Apache Configuration
    RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ /index.php [L]


    Damit werden die Thumbnails wieder korrekt beim ersten Aufruf erzeugt. Wir werden das in unsere Doku mit aufnehmen.
    Bei CloudFest werden wir uns zudem mal direkt mit den Drupal-Leuten über die Problematik unterhalten. ;)

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Hallo,


    anhand einer NGINX-Konfiguration für Drupal vermute ich, dass das am URL-Rewriting liegt: gedacht ist das so, dass wenn ein Zugriff auf den Image-Cache erfolgt und die Zieldatei aber (noch) nicht existiert, dass der Aufruf dann über die index.php geroutet werden soll (damit Drupal das gewünschte Bild dynamisch erzeugt).
    Die aktuelle RewriteRule sollte das aber eigentlich auch gar nicht verbieten...
    Wir werden mal versuchen, das mit einer Drupal-Testinstallation zu reproduzieren. Details folgen dann in Kürze...


    Viele Grüße


    -Klaus Keppler

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Zitat von WolfgangS

    Leider hat der eine sehr negative Auswirkung:
    Durch den Flag [F] werden alle Scripten abgebrochen, die auf den Files-Folder zugreifen. Viele Bild-Uploads, die in Drupal durchgeführt werden, legen automatisch von den hochgeladenen Bildern Styles an:
    So werden z.B. automatisch Bilder als Thumbnails in 150 x 150 Pixel erstellt [...]


    Die o.g. RewriteRule sollte nur dann Zugriffe verbieten, wenn die abzurufende Datei direkt eine der aufgeführten Endungen (.php/.pl/.sh/usw) hat.
    Eine .jpg-Datei, die sich in dem Verzeichnis befindet, müsste problemlos abrufbar sein.


    Legen Sie testweise mal in sites/default/files/ eine Datei namens "test.txt" mit irgendeinem Inhalt an, und versuchen Sie anschließend, diese über den Browser aufzurufen.
    Welche Fehlermeldung exakt bekommen Sie? (403 forbidden oder 500 internal server error?)


    Zitat

    Habt Ihr andere Vorschläge, wie man die Sicherheitslücke stopfen kann?
    Danke und Viele Grüße :)
    Wolfgang


    Das Hauptproblem ist Drupal selbst, da es aktiv in die Serverkonfiguration eingreifen möchte. Dieser Ansatz ist gut gemeint, aber leider nicht zu Ende gedacht (z.B. sind NGINX .htaccess-Dateien völlig schnuppe).
    Wenn Sie einen komplett eigenen Server betreiben (also quasi nur einen einzigen Webspace-Vertrag auf dem Server angelegt haben), dann könnte man SetHandler dort erlauben (die Lücke wäre dann quasi wieder offen, könnte aber nicht aktiv durch "fremde" Kunden ausgenutzt werden).


    Ich vermute auf den ersten Blick, das irgendwas mit der RewriteRule oder der restlichen .htaccess-Datei nicht stimmt und deshalb der Zugriff auf die temporären Dateien nicht funktioniert - da gibt es also wahrscheinlich eine recht einfache Lösung.


    Viele Grüße


    -Klaus Keppler

  • Umstellung fastcgi auf FPM, Debian 9

    Guten Morgen,


    Zitat von weltmeister

    Hat jemand eine kurze und knappe Anleitung parat?


    Code
    apt install php-fpm


    Also im Prinzip nur die PHP-FPM-Pakete nach installieren. Die PHP-Pakete von LiveConfig enthalten jeweils bereits die FPM-Variante. Mit "liveconfig --diag" können Sie sich alle PHP-Versionen ausgeben lassen, da wird dann auch jeweils angezeigt ob diese FPM unterstützt.


    Zitat

    Mit der Umstellung auf "FPM" in den Angeboten allein ist es ja nicht getan. Es kursieren im Internet teilweise verschiedene Anleitungen, die untereinader variieren.


    Was LiveConfig betrifft, genügt es normalerweise tatsächlich, die Angebote bzw. Verträge auf FPM umzustellen. Erweiterungen spielen keine Rolle (ob Extensions für CGI oder FPM installiert wurde ist egal, die liegen alle in den selben Verzeichnissen).


    Wichtig ist vor allem, dass Sie FPM nur mit LiveConfig ab v2.7.4 nutzen (nur dann ist die Konfiguration sicher).

  • Applikationen sehr veraltet

    Zitat von seb1983

    Da ich PHP7.2 laufen habe gibt es ja zum Glück kein mysql_connect mehr sondern mysqli, warum ist denn die Applikation so brutal alt?


    Das ist leider die Gratwanderung...
    LiveConfig unterstützt ja alle großen Distributionen auch in der LTS-Version - konkrekt z.B. CentOS 6 (PHP 5.3!) oder Ubuntu 14 (PHP 5.5). Da ist eben standardmäßig kein aktuelles PHP verfügbar.
    Wir haben aber bereits auf der Roadmap, den Installer grundlegend zu überarbeiten, so dass je nach verfügbarer PHP-Version entsprechend aktuellere App-Versionen installiert werden können (damit legen wir voraussichtlich ab April/Mai los).


    Zitat

    Kann ich die irgendwo selber einspielen oder werden die extern bezogen?


    Contao wird heutzutage meistens über den "Contao Manager" per Shell installiert (mit "composer"). Achten Sie ggf. darauf, das opcache-Modul zu deaktivieren oder die php.ini-Option "opcache.file_cache_only=On" zu setzen - siehe Contao-Manager Issue #347.

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Für alle CMS-Entwickler die hier eines Tages mal mitlesen: es ist BAD PRACTICE, mittels .htaccess in die Serverkonfiguration einzugreifen. Der Schutz via SetHandler ist nett gemeint, verpufft aber sobald man z.B. NGINX einsetzt. Letztendlich wird zudem nur am Symptom herumgepfuscht (Ausführung von Dateien, die irgendwie im Webspace gelandet sind) als die eigentliche Ursache zu vermeiden (durch eine anständige Architektur, z.B. Speicherung reiner Nutzdaten außerhalb des Webspace-Roots).

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Hmm, der Befehl FcgidWrapper ist ärgerlicherweise bei Apache nicht in den FileInfo-Overrides dokumentiert, sonst hätten wir den mit aufgenommen.


    Am einfachsten dürfte es sein, wenn Sie die Datei /usr/lib/liveconfig/lua/apache.lua bearbeiten und in Zeile 135 den Befehl "SubstituteMaxLineLength" durch "FcgidWrapper" ersetzen (*). Danach müssten Sie LiveConfig neu starten und den betroffenen Vertrag neu speichern (damit die vHost-Konfiguration aktualisiert wird).
    Wir werden FcgidWrapper beim nächsten Update auch mit in diese Liste aufnehmen (die Änderung ist daher quasi "updatesicher").
    Sicherheitstechnisch spricht aktuell nichts gegen FcgidWrapper, da hier die "normalen" suexec-Schutzmechanismen greifen.


    Viele Grüße


    -Klaus Keppler


    *) es hilft NICHT, die Anweisung "FcgidWrapper" einfach an die Liste anzufügen - nein, dafür muss leider ein anderer Eintrag dran glauben. Es gibt vermutlich einen Bug in Apache, welcher die maximale Länge der Zeile "AllowOverrideList" implizit begrenzt (laut Doku kann eine einzelne Config-Zeile max. 16MB groß sein, in der Praxis wird sie aber irgendwo klammheimlich (ohne Log-Meldung) abgeschnitten. Mehr als das, was LiveConfig aktuell rausschreibt, ist offenbar nicht drin.

  • 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).