❌

Normale Ansicht

Alles Open Source, alles unsicher

31. Oktober 2026 um 22:40

Was soll man noch nach diesem Monat sagen? Ich habe gerade gesehen, dass wir diesen Monat auch rückwirkend Black October nennen können. Zeit, mal den Monat Revue passieren zu lassen.

Das Thema der KI hat dem Bereich der IT-Sicherheit in den letzten Monaten echt den Rang abgelaufen, daher war ich außerordentlich überrascht, zu sehen, dass die PHP-Lücke so hohe Wellen schlug. Dass tatsächlich ein Teil des WWW abgeschaltet wurde, weil der Patch einer Lücke erwartet wurde, zeigt in erster Linie, dass es einige Admins gibt, die noch schnell reagieren.

Andererseits wurde IT-Sicherheit auch vereinfacht. Wozu aufwändiges Schlüsselmanagement aufbauen, wenn die Zahl 4 auch reicht?

Es zeigt aber auch, dass wir einen Großteil der bei uns im Einsatz befindlichen Software schwer überblicken können. Das wird insbesondere beim Blick auf den PHP-"Fix" schnell deutlich, da es sich dabei nicht nur einfach um einen geänderten Check oder Systemaufruf handelt, sondern an tausenden Stellen Teile verändert werden mussten. Natürlich auch durch die Hilfe durch LLMs.

Wer jetzt allerdings sagt, proprietäre Software sei ja aufgrund des fehlenden Drucks durch Transparenz so viel unsicherer, der kann beruhigt sein, denn: alle Software ist ja mittlerweile Open Source. Zumindest, wenn es nach dem Projekt "Reverse Engineer Anything" (rea) geht, das auf GitHub trendet und gerne eingesetzt wird, um Spiele zu "erweitern" oder Software zu klonen.

Bei rea bin ich auch überrascht, aber nur, weil ich damit gerechnet hatte, dass wir schneller an diesem Punkt ankämen. Software zu kompilieren ist einfach, das Kompilat zu sinnvollem Code rückzuentwickeln ist schwierig – das ist eigentlich eine der Aufgaben, wo maschinelles Lernen am besten glänzen kann. Und das tut es offenbar.

Was der letzte Monat uns aber eigentlich gezeigt hat, ist, dass KI die Hürden zwischen einer Idee und ihrer Umsetzung abbaut. Und das ist das, was vielen eigentlich das Kopfzerbrechen bereitet. Bisher galt: eine Idee ist nicht viel wert, wenn man sie nicht umgesetzt bekommt. Daher lag der Burggraben ("Moat") oft in der Fähigkeit, etwas umzusetzen. Man musste sich keine Sorgen machen, dass jemand anderes die Idee schon vorher hatte. Aber genau das kehrt sich jetzt um. Sei es, dass Software entwickelt oder originalgetreu nachgebaut werden kann, oder dass Lücken in Software gefunden werden können.

Wir leben schon in einer spannenden Welt, wo die Idee "ich möchte in das System einbrechen" jemanden schon so nah an das Ziel bringt. Und Möglichkeiten hierfür gibt es offenbar zuhauf. Das Open-Source-Argument der transparenten Entwicklung hat uns offenbar weder vor der PHP-Lücke noch vor solchen Krachern wie der CVE-2026-99999 bewahrt.

Aber das gilt eben in beide Richtungen. Die gleichen Werkzeuge, die aus der Idee eines Einbruchs einen Einbruch machen, machen aus "wir sollten unseren Code aufräumen" ein tatsächliches Refactoring. Die Hürde sinkt für Angreifer wie für Verteidiger. Nur hatten Verteidiger bisher selten die Zeit, das Budget oder schlicht die Lust dazu.

Ich bin gespannt, was der nächste Monat bringt. In wenigen Tagen soll aus all den öffentlichkeitswirksamen Wohltaten ein Börsengang werden. Ruhiger wird der kommende Monat vermutlich nicht. Sicherlich nicht.

Ubuntu-Server-Update von 24.04 auf 26.04

30. Oktober 2026 um 10:59

Über Ubuntu 26.04 habe ich hier schon berichtet. Heute habe ich meinen ersten Ubuntu-Server von Version 24.04 auf 26.04 aktualisiert. Es ist eigentlich recht gut gegangen. Dieser Beitrag fasst die wichtigsten Erkenntnisse zusammen.

  • MySQL-Passwörter
  • Dovecot-Konfiguration (Update 2.3 -> 2.4)
  • SSH-Server-Konfiguration
  • Externe und obsolete Pakete aufräumen

Grundsätzliche Vorgehensweise

Logischerweise sollten Sie zuerst ein Backup machen. Mein System ist eine virtuelle Maschine (KVM), ich habe also ein Backup des Images gemacht (LVM-Snapshot im laufenden Betrieb). Wäre irgendetwas total schief gegangen, hätte ich den ganzen Server blitzschnell in den alten Zustand zurückversetzen können.

Wichtig: Falls Sie Nextcloud verwenden, aktualisieren Sie die Nextcloud-Version zuerst und führen Sie das Ubuntu-Update erst danach durch. Andernfalls kann es Ihnen passieren, dass Nextcloud danach nicht mehr startet (Fehlermeldung: This version of Nextcloud is not compatible with PHP>=8.5. You are currently running 8.5.4). Es ist ziemlich mühsam, aus dieser Falle wieder herauszukommen, weil die üblichen Update-Mechanismen PHP voraussetzen!

Am Zielsystem habe ich dann ein letztes Update durchgeführt und dann do-release-upgrade gestartet. Der erste Lauf scheiterte an alten MySQL-Passwörtern. Nachdem ich diese umgestellt hatte (Details folgen gleich), lief do-release-upgrade ziemlich problemlos durch.

Bei sämtlichen Rückfragen, ob ich meine geänderten Konfigurationsdateien behalten oder lieber die neuen Konfigurationsdateien verwenden möchte, habe ich mich für meine alten Konfigurationsdateien entschieden. (Die Entscheidung ist nicht ganz einfach: Die neuen Konfigurationsdateien enthalten in der Regel bessere/neuere Einstellungen, die vorzuziehen wären. Umgekehrt will ich aber auch nicht die in der Vergangenheit vorgenommenen Änderungen verlieren.)

Danach ein Reboot, nach 30 Sekunden war ein neuer SSH-Login möglich. Sehr gut!

Jetzt begannen die Aufräumarbeiten. Es gab zwei Hauptprobleme:

  • Dovecot funktionierte nicht mehr (das war zu erwarten).
  • PHP auch nicht (das kam überraschend).

Vor dem Ubuntu-Update: MySQL-Passwörter

Mit Ubuntu 26.04 kommt MySQL 8.4. Diese Version des Datenbank-Servers unterstützt standardmäßig keine mysql_native_password-Passwörter mehr. Das ist an sich vernünftig, die Passwörter werden nach einem unsicheren Verfahren verschlüsselt. Es gibt zwei Lösungen: Eine besteht darin, das nicht mehr empfohlene Plugin mysql_native_password doch wieder zu aktivieren. (In Version 9 wird das aber nicht mehr gehen.) Die andere besteht darin, für alle betroffenen Benutzer ein neues Passwort mit dem Verfahren caching_sha2_password einzurichten, im Wesentlichen so:

ALTER USER name@localhost IDENTIFIED WITH caching_sha2_password BY 'topsecret';

Ich habe mich für diese Variante entschieden, zumal es ohnedies nur wenige betroffene Accounts gab. Zwei bereiteten mir allerdings Kopfzerbrechen. Welche Passwörter sollte ich für die (in der Vergangenheit) automatisch eingerichteten Accounts 'debian-sys-maint'@localhost und mysql.session@localhost verwenden? Eine kurze Recherche ergab, dass sich das Passwort für ersteren Account (eine Debian/Ubuntu-Spezialität) in /etc/mysql/debian.cnf befindet. Der zweite Account ist MySQL-intern. Es muss existieren, ist aber nicht für einen Login gedacht. Jedes zufällige Passwort ist OK.

Das eigentliche Update habe ich NACH den MySQL-Änderungen gestartet.

Nach dem Ubuntu-Update: PHP

Nach dem Update liefen Apache und der MySQL-Server auf Anhieb, nur PHP wollte nicht. Die Fehlermeldung im Apache-Log lautete:

(2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.3-fpm.sock (localhost:8000) failed

Der Fehler war leicht zu finden: Ich verwende PHP mit dem FastCGI Process Manager (FPM). Die PHP-Version wurde auf 8.5 aktualisiert, aber die Konfiguration verwies weiter auf die FPM-8.3-Version. Abhilfe:

apt install php-fpm
systemctl enable --now php8.5-fpm
a2disconf php8.3-fpm
a2enconf php8.5-fpm
systemctl restart apache2

Warum der Upgrade-Prozess sich um diese Details nicht gekümmert hat, kann ich nicht sagen. Möglicherweise hatte ich unter Ubuntu 24.04 irgendeine Abweichung von der Default-Konfiguration durchgeführt und die Konfigurationsdateien wurden deswegen nicht aktualisiert.

Ein letzter Hinweis zu PHP: Mit PHP 8.5 werden neue Konfigurationsdateien nach /etc/php/8.5 installiert. In meinem Fall (FPM) ist die Datei /etc/php/8.5/fpm/php.ini relevant. Änderungen, die in der Vergangenheit in der 8.3er-Version von php.ini vorgenommen wurden, müssen jetzt in der 8.5er-Version wiederholt werden. (In meinem Fall war vor allem memory_limit = 512M wichtig, damit Nextcloud ordentlich läuft. Der Defaultwert 128M ist zu klein.)

Dovecot

Dovecot (ein IMAP-Server) macht mit Ubuntu 26.04 einen Versionssprung von 2.3 auf 2.4. Das klingt unspektakulär, aber tatsächlich hat Dovecot mit der neuen Version die Syntax der Konfigurationsdateien grundlegend geändert. Solange die Dateien nicht angepasst werden und insbesondere die Anweisungen dovecot_config_version = 2.4.0 sowie dovecot_storage_version = 2.4.0 an den Beginn von /etc/dovecot.conf eingebaut werden, startet der Dienst nicht.

Upgrading Dovecot CE from 2.3 to 2.4 enthält eine umfassende Migrationsanleitung. Die simple Übernahme der neuen Konfigurationsdateien ist (in meinem Fall) unmöglich, weil ich diverse eigene Anpassungen vorgenommen habe. Schon vor dem Ubuntu-Update habe ich deswegen sicherheitshalber ein Backup des alten Konfigurationsverzeichnisses /etc/dovecot durchgeführt.

Die manuelle Migration erschien mir recht mühsam. Also habe ich Claude Code SSH-Zugriff auf meinen Server gegeben (für einen normalen Account, nicht für root) und habe den folgenden Prompt formuliert:

you can ssh to example.com (no root); go to /etc/dovecot and look at the config files; these are partially from 2.3 and must be updated to 2.4 (see also https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html); explain me what to change, don’t try to do it yourself; summarize your findings locally (not on example.com) into dovecot-migration-plan.md

Diesen Plan habe ich anschließend manuell umgesetzt. Anbei eine Kurzfassung:

Dovecot 2.3 -> 2.4: config changes

dovecot.conf

  Add these as the very first settings:

    dovecot_config_version = 2.4.0
    dovecot_storage_version = 2.4.0

  Remove the empty "dict { }" block.

conf.d/10-auth.conf

  Old: auth_username_format = %Ln
  New: auth_username_format = %{user | username | lower}

conf.d/auth-system.conf.ext

  passdb and userdb blocks need a name:

    passdb pam {
    }
    userdb passwd {
    }

conf.d/10-mail.conf

  mail_location is gone:

    mail_driver = maildir
    mail_path = ~/Maildir

conf.d/10-master.conf

  Old: user = $default_internal_user
  New: user = $SET:default_internal_user

conf.d/10-ssl.conf

  New setting names, no more "<" before file names:

    ssl = yes
    ssl_server_cert_file = /etc/letsencrypt/live/
                           example.com/fullchain.pem
    ssl_server_key_file  = /etc/letsencrypt/live/
                           example.com/privkey.pem
    ssl_server_dh_file   = /etc/dovecot/dh.pem
    ssl_server_prefer_ciphers = server

  (Each path belongs on one line; it is split here only
  for readability.)

  ssl_server_prefer_ciphers accepts "client" or "server";
  "yes" is a fatal error. The DH file is only needed for
  non-ECC key exchange and can be omitted.

conf.d/20-lmtp.conf

  "mail_plugins = $mail_plugins sieve" no longer works:

    protocol lmtp {
      postmaster_address = postmaster@example.com
      mail_plugins {
        sieve = yes
      }
    }

conf.d/90-sieve.conf

  The plugin { } block is gone. Use named script blocks:

    sieve_script personal {
      driver = file
      path = ~/sieve
      active_path = ~/.dovecot.sieve
    }
    sieve_script after {
      type = after
      driver = file
      path = /etc/dovecot/sieve-after
    }

  Recompile global sieve scripts (as root):

    sievec /etc/dovecot/sieve-after/spam-to-folder.sieve

  Users' own scripts are recompiled automatically.

Protocols

  2.4 enables no protocols by default. On Debian they come
  from /usr/share/dovecot/protocols.d, i.e. one file per
  installed package (imapd, lmtpd, managesieved, ...).

Testing

  doveconf -n          # must run without errors
  systemctl restart dovecot
  journalctl -u dovecot -n 50

  Then check IMAP login, LMTP delivery from Postfix, SMTP
  auth via the Postfix SASL socket and sieve filtering.

Eine halbe Stunde später konnte ich in Thunderbird meine Mails wieder abrufen.

Update Configuration File (UCF)

Eine Debian/Ubuntu-Pakete verwenden das Verfahren Update Configuration File (UCF). Bei diesen Paketen wird parallel zur unverändert belassenen Konfigurationsdateien die neue Version der Konfigurationsdatei mit der Kennung *.ucf-dist angelegt. Das ist praktisch, weil Sie unkompliziert danach suchen können:

find /etc -name '*.ucf-dist'

Leider wird UCF nur von ausgewählten Paketen verwendet (auf jeden Fall: apt, dovecot und ssh).

SSH-Server

Der SSH-Server (openssh-server 10.2) läuft zwar auf Anhieb (alles andere wäre ja eine Katastrophe), aber journalctl -u ssh liefert diverse Warnungen:

sshd: rexec line 16: Deprecated option UsePrivilegeSeparation
sshd: rexec line 19: Deprecated option KeyRegenerationInterval
sshd: rexec line 20: Deprecated option ServerKeyBits
sshd: rexec line 31: Deprecated option RSAAuthentication
sshd: rexec line 38: Deprecated option RhostsRSAAuthentication

Also habe ich auch diese Datei etwas aufgeräumt, wobei Claude Code einige weitere Verbesserungsvorschläge gemacht hat (ChallengeResponseAuthentication -> KbdInteractiveAuthentication, PermitRootLogin without-password -> PermitRootLogin prohibit-password, HostKey /etc/ssh/ssh_host_dsa_key entfernen).

Docker

In Ubuntu 24.04 hatte ich Docker-Pakete direkt aus dem Docker-Repo installiert. Die alten Pakete wurden unverändert belassen, Docker funktionierte weiter. Allerdings wurde im Rahmen des Updates die Docker-Paketquelle deaktiviert (siehe /etc/apt/sources.list.d/*.disabled), d.h. ich würde keine Updates mehr erhalten. Ich habe daher die folgende Datei docker.sources neu eingerichtet:

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: resolute
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

apt update und apt list --upgradable zeigt jetzt zu Ubuntu 26.04 passende Docker-Pakete an, die ich mit apt dist-upgrade installierte. Ein kurzer Test mit docker ps zeigt, dass alle Docker-Container wie geplant laufen.

Obsolete Pakete entfernen

Das Kommando

apt list '?obsolete'

liefert eine Liste von Paketen, die aus früheren Ubuntu-Versionen stammen (zu meiner Schande bis zurück nach 14.04) und zu denen es keine aktive Paketquellen mehr gibt (z.T. uralte Kernel-Versionen). Höchste Zeit, auch hier aufzuräumen. Ich habe Claude Code um eine Analyse gebeten.

find obsolete packages and access which can be safely removed

In der Folge habe ich die meisten betreffenden Pakete mit apt purge entfernt.

Quellen/Links

PHP-Notfallupdates schließen kritische Sicherheitslücken

Von: MK
22. Oktober 2026 um 03:38

Das PHP-Entwicklerteam hat dringende Sicherheitsupdates veröffentlicht, die zwei kritische Schwachstellen in der serverseitigen Skriptsprache beheben. Angreifer könnten diese unter bestimmten Bedingungen aus der Ferne ausnutzen, um eigenen Code auf betroffenen Servern auszuführen, ohne sich zuvor authentifizieren zu müssen. Die Lücken CVE-2026-109618 und CVE-2026-109619 werden nach CVSS 4.0 jeweils mit 9,2 von 10 Punkten bewertet. Administratoren […]

Der Beitrag PHP-Notfallupdates schließen kritische Sicherheitslücken erschien zuerst auf fosstopia.

HPLIP 3.26.6 bringt neue HP-Drucker unter Linux

Von: MK
18. September 2026 um 05:30

HP hat eine neue Version seiner Linux-Treiber veröffentlicht. HPLIP 3.26.6 erweitert die Hardware-Unterstützung um zahlreiche aktuelle Drucker und Scanner. Unterstützung für neue Linux-Distributionen fehlt allerdings weiterhin. Neu hinzugekommen sind mehrere Geräte der ScanJet-Reihen. Dazu gehören der ScanJet Enterprise Flow N9000 sn1 und der ScanJet Enterprise Flow 9000 s1. Auch der ScanJet Pro 4200 s1 wird […]

Der Beitrag HPLIP 3.26.6 bringt neue HP-Drucker unter Linux erschien zuerst auf fosstopia.

HP stärkt das LVFS Projekt und setzt ein wichtiges Zeichen für Linux

Von: MK
21. Mai 2026 um 05:45

Die Linux Firmware Landschaft erhält neuen Rückenwind. HP unterstützt nun als weiterer Premier Sponsor den Linux Vendor Firmware Service (LVFS) und reiht sich damit neben Dell und Lenovo ein. Das Projekt gewinnt damit einen weiteren großen Hersteller, der die Zukunft sicherer Firmware Updates auf Linux Systemen aktiv mitgestaltet. Hinter dem Dienst steht die bekannte fwupd […]

Der Beitrag HP stärkt das LVFS Projekt und setzt ein wichtiges Zeichen für Linux erschien zuerst auf fosstopia.

Ubuntu-Server-Upgrade von 22.04 auf 24.04

05. September 2024 um 09:27

Generell lautet ja meine Empfehlung, bei produktiven Servern niemals ein Distributions-Upgrade durchzuführen, als z.B. ohne Neuinstallation von Ubuntu 22.04 auf 24.04 umzustellen. Manchmal halte ich mich aber selbst nicht an diese Regel. Testobjekt war ein Server mit Apache, MySQL, PHP, Mail (Postfix, Dovecot, OpenDKIM) und Docker.

Natürlich gab es Schwierigkeiten …

Fairerweise muss ich zugeben, dass do-release-upgrade noch gar kein Server-Update auf Version 24.04 vorsieht. Das ist ein wenig überraschend, als Ubuntu 24.04.1 ja bereits freigegeben wurde. Normalerweise ist das der Zeitpunkt, ab dem do-release-upgrade funktionieren sollte. Ich habe das Upgrade mit do-release-upgrade -d erzwungen. Selbst schuld also.

Update: Canonical rät aktuell wegen APT-Problemen explizit davon ab, Upgrades von 22.04 auf 24.04 durchzuführen (siehe https://lists.ubuntu.com/archives/ubuntu-release/2024-September/006225.html).

Distributions-Upgrade

Zuerst habe ich ein letztes Mal alle 22.04-Updates installiert (also apt update und apt full-upgrade) und den Server dann neu gestartet.

Danach habe ich ein Backup des in einer virtuellen Maschine laufenden Servers durchgeführt. Zur Not hätte ich aus der gesicherten Image-Datei problemlos den bisherigen Zustand des Servers wiederherstellen können. Das war aber zum Glück nicht notwendig.

Das Distributions-Upgrade habe ich dann mit do-release-upgrade -d eingeleitet, wobei -d für --devel-release steht und das Update erzwingt. Es dauerte ca. 1/4 Stunde und lief an sich überraschend flüssig durch. Ein paar Mal musste ich bestätigen, dass meine eigenen Konfigurationsdateien erhalten bleiben und nicht durch neue Konfigurationsdateien überschrieben werden sollten.

Der nachfolgende Reboot verursachte keine Probleme, ich konnte mich nach kurzer Zeit wieder mit SSH einloggen. So weit so gut!

Kein DNS

Die statische Netzwerkkonfiguration meines Servers erfolgt durch /etc/netplan/01.yaml. Dort sind sechs Nameserver eingetragen, je drei für IPv4 und IPv6. Überraschenderweise funktioniert im aktualisierten 24.04-Server keine Namensauflösung mehr — ein wirklich grundlegendes Problem! ping google.com führt also zum Fehler, dass die IP-Adresse von google.com unbekannt sei.

Ein kurzer Blick auf resolv.conf zeigt, dass es sich dabei um einen Link auf eine gar nicht existierende Datei handelt.

ls -l /etc/resolv.conf

  /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf (existiert nicht)

dpkg -l | grep resolve verrät, dass systemd-resolved nicht installiert ist. Sehr merkwürdig!

Abhilfe schafft die Installation dieses Pakets. Die Installation ist aber ohne DNS gar nicht so einfach! Ich musste zuerst /etc/resolv.conf löschen und dann einen Eintrag auf den Google-DNS dort speichern:

rm /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf
apt install systemd-resolved 
reboot

Nach einem Reboot läuft DNS. resolvectl listet jetzt meine in /etc/netplan/01.yaml aufgeführten Nameserver auf.

PHP-Probleme

Nächstes Problem: Apache startet nicht. systemctl status apache2 verweist auf einen Fehler in einer Konfigurationsdatei von PHP 8.1. Aber Ubuntu 24.04 verwendet doch PHP 8.3. Was ist da passiert?

Ein Blick in /etc/apache2/mods-enabled zeigt, dass dort noch PHP 8.1 aktiviert ist. Abhilfe:

a2dismod php8.1
a2enmod php8.3
systemctl restart apache2

Apache und PHP laufen jetzt, aber ein Blick auf die Nextcloud-Statusseite zeigt, dass /etc/php/8.3/apache2/php.ini sehr konservative Einstellungen enthält. Nach memory_limit=1024M und ein paar weiteren Änderungen ist auch Nextcloud zufrieden.

OpenDKIM

Auf meinem 22.04-Server hatte ich DKIM aktiv (siehe auch https://kofler.info/dkim-konfiguration-fuer-postfix/). Nach dem Upgrade funktioniert die Signierung der Mails aber nicht mehr. Der Grund war einmal mehr trivial: Beim Upgrade sind die entsprechenden Pakete verloren gegangen. Abhilfe:

apt install opendkim opendkim-tools

Fazit

Keines der Probleme war unüberwindbar. Überraschend war aber die triviale Natur der Fehler. Beim Upgrade verloren gegangene oder nicht installierte Pakete, keine Synchronisierung zwischen den installierten Paketen und den aktivien Apache-Modulen etc. Ich bleibe bei meinem Ratschlag: Wenn Ihnen Stabilität wichtig ist, vermeiden Sie Distributions-Upgrades. Ja, die Neuinstallation eines Servers verursacht mehr Arbeit, aber dafür können Sie den neuen Server in Ruhe ausprobieren und den Wechsel erst dann durchführen, wenn wirklich alles funktioniert. Bei einem Upgrade riskieren Sie Offline-Zeiten, deren Ausmaß im vorhinein schwer abzuschätzen ist.

Links/Quellen

❌