Diese "Drop-Ins" sind sozusagen die Overrides (ich denke wir reden hier von der selben Sache). systemd sucht sowohl in /etc/systemd/system/<unit>.d/ als auch in /lib/systemd/system/<unit>.d/ nach entsprechenden Overrides/Drop-Ins.
Wenn Sie "nur" ExecStart ändern, dann sehe ich auch keinerlei Konflikt mit den vom "10-sandbox.conf" vorgenommenen Einstellungen.
Hello,
from now on there is the possibility to harden PHP-FPM additionally. The packages php-(VERSION)-opt-hardened can be installed in addition to the PHP versions provided by us, e.g:
apt install php-8.3-opt-hardenedThese include a so-called drop-in for the respective systemd unit files in order to run the FPM pool manager with additional restrictions:
All settings can be found (including comments and reference to the respective systemd documentation) at /lib/systemd/system/php(VERSION)-fpm.service.d/10-sandbox.conf. If individual settings cause problems in a specific case, they can be overwritten by an additional drop-in.
Please let us know if you encounter any problems or unexpected restrictions during operation. In the longer term, we plan to equip PHP-FPM with these restrictions by default. Further measures to increase server security are also being prepared.
The hardened packages are available for PHP 5.6 - 8.3 on Debian 10-12 and Ubuntu 18-22.
Best regards
-Klaus Keppler
Hallo,
ab sofort gibt es die Möglichkeit, PHP-FPM zusätzlich abzuhärten.
Die Pakete php-(VERSION)-opt-hardened können als Ergänzung zu den von uns bereitgestellten PHP-Versionen installiert werden z.B.:
apt install php-8.3-opt-hardenedDiese beinhalten ein sogenanntes Drop-In für die jeweiligen Systemd-Unit-Files, um den FPM-Pool-Manager mit zusätzlichen Einschränkungen laufen zu lassen. Das sind unter anderem:
Alle Einstellungen sind (inklusive Kommentaren und Verweis auf die jeweilige systemd-Dokumentation) unter /lib/systemd/system/php(VERSION)-fpm.service.d/10-sandbox.conf zu finden. Sollten einzelne Einstellungen im konkreten Fall Probleme machen, kann man diese durch ein zusätzliches Dop-In wieder überschreiben.
Bitte geben Sie uns Bescheid, falls Probleme oder unerwartete Einschränkungen im Betrieb auftauchen. Längerfristig planen wir, PHP-FPM standardmäßig mit diesen Beschränkungen auszustatten. Weitere Maßnahmen zur Erhöhung der Serversicherheit sind auch noch in Arbeit.
Die hardened-Pakete sind für PHP 5.6 - 8.3 unter Debian 10-12 und Ubuntu 18-22 verfügbar.
Viele Grüße
-Klaus Keppler
Dieses Feature wird definitiv über die Oberfläche kommen - in v3 ist das bereits vorbereitet.
In LiveConfig v2 werden wir das voraussichtlich nicht mehr backporten - bei Bedarf bitte kurz Kontakt mit support@liveconfig.com aufnehmen, dann gehen wir den "manuellen" Weg über Änderungen an der Datenbank durch.
Die Warnmeldung sollte inzwischen nicht mehr auftauchen, wir haben das "main"-Repository inzwischen mit dem neuen Key neu signiert.
Viele Grüße
-Klaus Keppler
Hallo,
für das "main"-Repository gab es schlichtweg noch keine Aktualisierungen, daher war das noch mit dem "alten" Key signiert.
Wir haben das eben aktualisiert, die Warnung sollte somit nicht mehr auftauchen.
Wir haben heute (15.03.2024) die Repositories auf den neuen Key umgestellt, da der alte Signaturschlüssel am 23.03.2024 abläuft.
Wir empfehen, das Paket liveconfig-keyring (wie oben verlinkt) zu installieren, dann werden die Signaturschlüssel künftig automatisch aktualisiert.
Viele Grüße
-Klaus Keppler
Zur Migration: prinzipiell möglich, die Anforderung hatten wir bislang noch nie. Das Vorgehen wäre:
- die SQLite-Datenbank (/var/lib/liveconfig/liveconfig.db) komplett entleeren (truncaten), nur das Datenbankschema (alle Tabellen, Referenzen etc.) muss erhalten bleiben
- aus MySQL nur die Daten exportieren (keine "CREATE TABLE"-Statements etc.)
- diese Daten dann in die SQLite-Datenbank einfügen.
Zum Archiv: nein, öffentlich steht so ein Archiv nicht bereit, aber wir haben hier alle jemals veröffentlichten Versionen archiviert. Bei Bedarf kurze Mail an support@liveconfig.com mit der benötigten Versionsnummer (und Plattform/Distribution).
Besteht das Problem immer noch?
Ein einfacher Neustart von LiveConfig dürfte genügen.
Das Problem tritt während Upgrades auf, wenn Apache gleichzeitig mit LiveConfig aktualisiert wurde, und das Apache-Paket noch nicht vollständig konfiguriert ist. Dann kann LiveConfig dieses Paket nicht erkennen, somit nicht herausfinden ob FastCGI und/oder FPM verfügbar sind - und peng.
Wir werden uns etwas einfallen lassen, wie wir diesen Zustand vermeiden können...
Hmm, das ist sehr merkwürdig - die mit diesem Schema hinzugefügten Datenbankeinträge dürfen eigentlich noch nicht existieren.
Bitte führen Sie mal folgende SQL-Abfragen aus und posten das Ergebnis, oder schicken es uns (support@liveconfig.com):
SELECT * FROM GROUPPERMISSIONS WHERE GP_MODULEID=2 AND GP_PERMISSIONID=1;
SELECT COUNT(*) FROM CUSTOMERPERMISSIONS WHERE CP_MODULEID=2 AND CP_PERMISSIONID=1;
SELECT COUNT(*) FROM USERPERMISSIONS WHERE UP_MODULEID=2 AND UP_PERMISSIONID=1;Kommt auf die PHP-Version drauf an.
Wenn es PHP-Pakete von LiveConfig sind (php-x.x-opt): https://www.liveconfig.com/de/…ncube-loader-installieren
Wenn es system-eigene PHP-Pakete sind (php-cgi/php-fpm): der Herstelleranleitung folgen.
Während der Entwicklung pflegen wir nur die deutschen Übersetzungen. Derzeit gibt es noch häufig Änderungen an den Phrasen - es macht erst Sinn die Übersetzungen zu erstellen, wenn die meisten Sätze/Begriffe "fix" sind. Mit Arabisch haben wir die RTL-Darstellung getestet (right to left).
Ich schätze, dass die Übersetzungen etwa Mitte März dran sind.
Wir haben die Informationsseite zu LiveConfig 3 eben aktualisiert.
Für alle Interessenten wohl am wichtigsten: die Seite enthält nun eine Liste aller noch offenen Punkte. Wie zu sehen ist, betrifft das zum größten Teil noch die GUI (d.h. die meiste Funktionalität ist bereits implementiert und über die API verfügbar).
In den nächsten zwei Wochen werden wir ein Installations-Repository und einen Bugtracker einrichten, um erste Beta-Tests zu ermöglichen. Details dazu und Infos wie man daran teilnehmen kann werden wir ebenfalls im Forum veröffentlichen, sobald alles vorbereitet ist.
Wir haben hier jeden Dienstag eine Besprechungsrunde, in deren Rahmen auch die "ToDo-Liste" jeweils aktualisiert wird. Wir möchten damit den Entwicklungsfortschritt transparenter machen.
Zudem wurde auch die Online-Demo (admin/admin) aktualisiert, hier kann sich jeder einen aktuellen Eindruck verschaffen.
Viele Grüße
-Klaus Keppler
Hallo,
wir wurden darauf aufmerksam gemacht, dass LiveConfig bis einschließlich Version 2.5.1 eine kritische Sicherheitslücke enthielt. Der Fehler wurde mit Version 2.5.2 (28.11.2017) behoben.
Details zu dem Fehler werden in Kürze veröffentlicht. In Anbetracht der Tatsache, dass dieser Fehler seit über sechs Jahren behoben ist, sollte das also die meisten LiveConfig-Kunden nicht betreffen.
Allerdings wurden wir auch darüber informiert, dass tatsächlich noch einzelne Server im Internet per Scan gefunden wurden, die entsprechend (stark) veraltet sind.
Wer also (warum auch immer) noch so alte Systeme am Laufen hat, möge bitte kurz mal die Version prüfen und ein Update ausführen. Wenn ein Update auf die aktuellste Version (2.16.2) nicht möglich sein sollte (z.B. wenn die Distribution nicht mehr unterstützt wird), wenden Sie sich bitte an support@liveconfig.com.
Viele Grüße
-Klaus Keppler
LiveConfig3 enthält eine vollständig neue GUI, daher können die bisherigen CSS-Templates nicht weiter verwendet werden. Das Logo ist aber weiterhin über die GUI änderbar (wie bisher).
Die Idee mit den CSS-Overrides möchten wir aber prizipiell beibehalten, mit dem neuen Framework sollte das dank CSS-Variablen sogar einfacher werden. Mittelfristig können wir uns auch vorstellen, das Farbschema ebenfalls über die GUI anpassbar zu machen.
Das CSS-Customizing steht ehrlich gesagt aber nicht ganz oben in der Prioritätenliste (mehr dazu am Montag). Wenn Sie spezielle Wünsche zur Anpassbarkeit haben, lassen SIe es uns bitte wissen.
In LiveConfig 2.x ist die DNSSEC-Implementierung leider sehr stark auf RSA fokussiert, für LC3 haben wir quasi den kompletten Code dazu neu entwickelt.
Ob ein Backporting anderer Algorithmen von LC3 auf LC2 möglich ist, müssen wir prüfen - einfach wird das aber sicher nicht.
Zu LC3 wird es am kommenden Montag (15.01.) weitere Informationen geben (wir stecken aktuell mitten in der Release-Planung).
Bei PHP-FPM gibt es technisch bedingt keine Lösung um den Ioncube-Loader nur selektiv zu aktivieren. In diesem Fall lädt nämlich der PHP-FPM-Pool-Prozess die Ioncube-Erweiterung, beim eigentlichen PHP-Zugriff wird dieser Prozess dann nur geforked und anschließend mit Benutzer-Berechtogungen und -Einstellungen ausgeführt. Zu diesem Zeitpunkt ist Ioncube aber bereits geladen (und ein Nachladen erst nach dem fork() ist nicht möglich).
Eine Idee wäre, mit der php.ini-Option ioncube.loader.encoded_paths zu experimentieren. Laut Anleitung legt diese fest, in welchen Verzeichnissen Ioncube aktiv werden soll. Sie könnten diese Einstellung global auf einen quasi ungültigen Wert (z.B. disabled) setzen, und nur bei den Kunden die Ioncube benötigen auf %HOME%/
Die andere Möglichkeit wäre, auf PHP-FPM zu verzichten und FastCGI zu nutzen. Da wird ja pro Benutzer (Vertrag) eine eigene PHP-Instanz gestartet, somit können Extensions individuell aktiviert/deaktiviert werden. Konkret könnte das so aussehen, dass Webhosting-Verträge ohne Ioncube-Loader weiterhin mit PHP-FPM genutzt werden können, während Accounts die Ioncube benötigen dann mit FastCGI laufen müssen.
So oder so müssten Sie in z.B. /opt/php-8.2/etc/conf.d/ioncube.ini die zend_extension=...-Anweisung auskommentieren, und in der php.ini-Verwaltung in LiveConfig (für jede verfügbare PHP-Version) einen entsprechenden php.ini-Eintrag hinzufügen:
(oder die Option "Änderbar" nur auf "pro Vertrag" setzen, dann kann das nicht der Kunde selbst ändern sondern nur noch der jeweilige Admin)
Ich hoffe, dass Ihnen das hilft.
Viele Grüße
-Klaus Keppler
Hallo,
ab sofort steht LiveConfig 2.16.2 zum Download bereit.
Ja, zwei Tage vor Weihnachten sollte man keine Updates ausrollen - aber der Grund ist leider ernst: mit genauso wenig Begeisterung hat der Entwickler von Postfix - Wietse Venema - auf ein äußerst kurzfristig öffentlich gemachtes Sicherheitsproblem in Postfix hingewiesen: SMTP Smuggling.
Dieses LiveConfig-Update macht nichts anderes, als den in dem verlinkten Beitrag empfohlenen Workaround anzuwenden (die Anweisung "smtpd_data_restrictions = reject_unauth_pipelining" wird in die main.cf mit aufgenommen)
Während des Upgrades erfolgt das automatisch durch LiveConfig, es ist also kein manuelles Aktualisieren der Konfiguration erforderlich.
Weitere Informationen:
Viele Grüße
-Klaus Keppler
Was liefert der Befehl "dpkg -l | grep -i mariadb" ?
Hallo!
Ab sofort steht LiveConfig v2.16.1 zum Download bereit. Die wichtigsten Änderungen sind:
Außerdem wurden neben einigen kleineren Fehlern auch mögliche Problem beim Upgrade des Datenbank-Schemas von (sehr) alten LiveConfig-Installationen behoben.
Die vollständige Liste aller Änderungen findet sich wie immer im Changelog.
Die Änderungen am Schema der LiveConfig-Datenbank sind weitgehend abgeschlossen, so dass eine reibungslose Umstellung auf LiveConfig 3 (und auch zurück) möglich sein wird.
Das Update sollte - wie immer - reibungslos über den jeweiligen Paketmanager möglich sein.
Falls der Repository-Key abgelaufen ist, am besten das Paket liveconfig-keyring installieren (siehe Hinweise).
(ab März 2024 werden alle Pakete und Repositories mit dem neuen Key signiert, der in liveconfig-keyring bereits enthalten ist)
Viele Grüße
-Klaus Keppler