Paketquellen sicher verwalten und prüfen

1. Warum Paketquellen ein unterschätzter Angriffsvektor sind

Jede Zeile in /etc/apt/sources.list oder /etc/yum.repos.d/ ist eine Vertrauensentscheidung mit Root-Konsequenzen. Wer eine Paketquelle hinzufügt, erlaubt dem Betreiber dieser Quelle, Software mit vollen Systemrechten zu installieren, sobald ein Update-Lauf sie erfasst. Anders als bei einem einzelnen heruntergeladenen Binary betrifft das nicht nur ein Programm, sondern potenziell jedes zukünftige Update für dieses Paket. Genau deshalb sind kompromittierte oder bösartige Paketquellen ein wiederkehrendes Ziel echter Angriffe, von unterwanderten PPA-Maintainer-Accounts bis zu gefälschten Repository-Spiegeln.

Das Angriffsmuster ist meist banal: Ein Blogpost oder eine Installationsanleitung verlangt curl -fsSL https://example.com/install.sh | sudo bash, das Skript fügt im Hintergrund ein Repository samt eigenem Signierschlüssel hinzu, und ab diesem Moment kann der Betreiber der Domain jedes Paket signieren, das dieses Repo ausliefert. Fällt die Domain in falsche Hände oder wird der Signierschlüssel kompromittiert, läuft der nächste apt upgrade potenziell manipulierten Code mit Root-Rechten aus. Die folgenden Abschnitte zeigen, wie GPG-Signaturen tatsächlich schützen, wo die häufigsten Konfigurationsfehler liegen und wie man bestehende Quellen kontrolliert prüft, statt blind zu vertrauen.

2. GPG-Signaturen bei APT und DNF verstehen

APT prüft bei jedem apt update die kryptografische Signatur der Repository-Metadaten (InRelease beziehungsweise Release plus Release.gpg) gegen die im System hinterlegten öffentlichen Schlüssel. Nur wenn die Signatur mit einem vertrauten Schlüssel übereinstimmt, werden die darin gelisteten Paket-Hashes als vertrauenswürdig akzeptiert, und erst diese Hashes schützen die eigentlichen .deb-Dateien vor Manipulation. Fehlt die Signaturprüfung oder wird ein Schlüssel blind akzeptiert, bricht die gesamte Vertrauenskette zusammen, unabhängig davon, wie sicher HTTPS die Verbindung selbst absichert.

Wichtig ist der Unterschied zwischen Transport- und Inhaltssicherheit: HTTPS schützt die Uebertragung vor Abhören und Manipulation unterwegs, sagt aber nichts darüber aus, ob der Server selbst vertrauenswürdig ist. GPG-Signaturen hingegen schützen den Inhalt unabhängig vom Transportweg, sogar wenn ein Spiegel-Server kompromittiert wird. Deshalb bleibt Acquire::AllowInsecureRepositories "false" die Standardeinstellung in modernen Debian- und Ubuntu-Versionen, und ein manuelles Deaktivieren dieser Prüfung sollte ein sofortiges Warnsignal in jedem Code-Review sein.

# Show currently trusted keyring files used for repo signature checks
ls -la /etc/apt/trusted.gpg.d/
ls -la /etc/apt/keyrings/

# Inspect fingerprint and key details of a downloaded key file
gpg --show-keys --with-fingerprint /etc/apt/keyrings/example-repo.gpg

# Verify a repository's Release file signature manually
cd /tmp
curl -fsSLO https://example-repo.io/dists/stable/InRelease
gpg --verify InRelease

# Confirm APT actually rejects unsigned or insecure repos
grep -r "AllowInsecureRepositories" /etc/apt/apt.conf.d/ 2>/dev/null

3. Vom unsicheren apt-key zu signed-by und Keyrings

Das Kommando apt-key add ist seit Debian 11 und Ubuntu 22.04 als deprecated markiert und wird in kommenden Releases entfernt, weil es strukturell unsicher war: Jeder mit apt-key add importierte Schlüssel galt global für alle konfigurierten Repositories, nicht nur für das eine, das ihn eigentlich braucht. Ein kompromittierter Drittanbieter-Schlüssel konnte damit theoretisch Pakete für offizielle Debian- oder Ubuntu-Repos signieren, was die gesamte Trennung zwischen vertrauten Quellen aufhob. Das moderne Muster bindet jeden Schlüssel explizit an genau eine Quelle.

Der korrekte Weg: Den Schlüssel als Datei nach /etc/apt/keyrings/ ablegen und in der zugehörigen .sources- oder .list-Datei per signed-by= referenzieren. Damit gilt der Schlüssel ausschließlich für dieses eine Repository, und ein Angreifer, der einen Drittanbieter-Schlüssel kompromittiert, kann damit keine Pakete für andere Quellen fälschen. Debian 12 und Ubuntu 24.04 nutzen zusätzlich das neue Deb822-Format (.sources-Dateien), das Schlüssel, URL und Komponenten in einer strukturierten, leichter auditierbaren Syntax bündelt statt in der alten Einzeiler-Notation.

# /etc/apt/sources.list.d/example-repo.sources
# Modern Deb822 format: key is scoped to this repo only, never global trust
Types: deb
URIs: https://example-repo.io/apt
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example-repo.gpg

# Old-style one-liner equivalent (still supported, less auditable)
# deb [signed-by=/etc/apt/keyrings/example-repo.gpg] https://example-repo.io/apt stable main

4. PPAs und Drittanbieter-Repos: das eigentliche Risiko

Ein Ubuntu-PPA (Personal Package Archive) unterliegt keiner redaktionellen Prüfung durch Canonical. Jeder Launchpad-Account kann ein PPA erstellen und Pakete darin veröffentlichen, was PPAs für aktuelle Software praktisch, aber sicherheitstechnisch grundlegend anders macht als das offizielle Ubuntu-Archiv. Das Risiko ist nicht theoretisch: Ein kompromittiertes Maintainer-Konto oder ein absichtlich bösartiger PPA-Betreiber kann Pakete mit beliebigem Inhalt signieren und verteilen, und der einzige Schutzmechanismus, der zwischen dem System und diesem Code steht, ist die eigene Entscheidung, dem PPA überhaupt zu vertrauen.

Besonders kritisch sind PPAs, die auf Paketnamen offizieller Software abzielen (etwa ein PPA namens chromium-stable), da Namensverwechslungen und Typosquatting gezielt Nutzer täuschen, die eigentlich das offizielle Paket wollten. add-apt-repository ppa:name/ppa lädt den zugehörigen GPG-Schlüssel automatisch von Launchpads Keyserver, was komfortabel ist, aber die eigentliche Vertrauensentscheidung fällt bereits vorher: bei der Wahl, überhaupt genau diesem PPA zu vertrauen. Vor jedem Hinzufügen lohnt ein Blick auf die Launchpad-Seite des PPA: Anzahl der Follower, Aktivität des Maintainers und ob der Quellcode öffentlich einsehbar ist.

5. Installationsskripte lesen, bevor man sie ausführt

Das Muster curl -fsSL https://example.com/install.sh | sudo bash ist bei vielen Docker-, Node- und Cloud-CLI-Installationen zur Norm geworden, umgeht aber jede Möglichkeit zur Prüfung, bevor Root-Code ausgeführt wird. Das Skript kann bedingt auf die IP-Adresse, den User-Agent oder die Tageszeit reagieren und beim Download einen anderen Inhalt liefern als bei manueller Ansicht im Browser, ein Verfahren, das bereits bei realen Supply-Chain-Vorfällen dokumentiert wurde. Der sichere Weg trennt Download und Ausführung immer in zwei separate Schritte.

Nach dem Download lohnt sich eine kurze, aber gezielte Durchsicht: Welche Repositories fügt das Skript hinzu, welche Schlüssel importiert es, ruft es weitere externe URLs auf, und schreibt es in sensible Pfade wie /etc/sudoers.d/ oder ~/.ssh/? Viele seriöse Anbieter bieten inzwischen zusätzlich eine Prüfsumme oder GPG-Signatur für das Installationsskript selbst an, die vor der Ausführung verifiziert werden sollte. Ein Skript, das sich weigert, in einer isolierten Umgebung wie einem Container zu laufen, oder das die Ausführung ohne Netzwerkzugriff verweigert, ist ein zusätzliches Warnsignal.

# WRONG: pipe directly to a root shell, no chance to inspect first
curl -fsSL https://example.com/install.sh | sudo bash

# RIGHT: download, inspect, then decide
curl -fsSL https://example.com/install.sh -o /tmp/install.sh
sha256sum /tmp/install.sh   # compare against published checksum if available
less /tmp/install.sh        # actually read what it does before running it

# Search the script for suspicious actions before executing
grep -nE "curl|wget|sudo|chmod 777|sources.list|/etc/sudoers|ssh" /tmp/install.sh

# Only run after review, and prefer a sandboxed dry run first
docker run --rm -v /tmp/install.sh:/install.sh ubuntu:24.04 bash /install.sh

6. Bestehende Paketquellen systematisch auditieren

Server, die über Jahre gewachsen sind, sammeln oft vergessene Paketquellen an: ein PPA für ein Tool, das längst deinstalliert wurde, ein Testrepository, das nie wieder entfernt wurde, oder ein Docker-Repo aus einer alten Anleitung. Jede dieser Zeilen bleibt ein aktiver Vertrauensanker, selbst wenn niemand mehr an sie denkt. Ein regelmäßiges Audit listet alle konfigurierten Quellen auf, prüft, ob sie noch benötigt werden, und entfernt alles, was nicht mehr eindeutig zugeordnet werden kann.

Unter Debian und Ubuntu liegen alle aktiven Quellen in /etc/apt/sources.list und den Dateien unter /etc/apt/sources.list.d/, während die zugehörigen Schlüssel in /etc/apt/trusted.gpg.d/ und /etc/apt/keyrings/ liegen. Ein Audit sollte beide Ebenen gemeinsam betrachten: Schlüssel ohne zugehörige aktive Quelle sind verwaiste Vertrauensanker, und Quellen, die auf HTTP statt HTTPS zeigen, sollten grundsätzlich hinterfragt werden. apt-cache policy zeigt zusätzlich, welche Priorität jede Quelle bei Versionskonflikten hat, ein oft übersehener Faktor, wenn ein Drittanbieter-Repo versehentlich eine höhere Priorität als das offizielle Archiv erhält.

# List every active source with its origin
grep -rhE "^deb|^Types:" /etc/apt/sources.list /etc/apt/sources.list.d/*.list \
  /etc/apt/sources.list.d/*.sources 2>/dev/null | sort -u

# Find keyring files without a clear owning source (manual review needed)
for key in /etc/apt/trusted.gpg.d/*.gpg /etc/apt/keyrings/*.gpg; do
  echo "== $key =="
  gpg --show-keys --with-fingerprint "$key" 2>/dev/null | grep -E "pub|uid"
done

# Flag any source still using plain HTTP instead of HTTPS
grep -rhE "^deb http://" /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

# Check pin priority to catch a third-party repo silently outranking the official archive
apt-cache policy | grep -B1 "example-repo"

7. GPG-Prüfung unter DNF und YUM

Auf RHEL-basierten Systemen wie Fedora, Rocky Linux und AlmaLinux definiert jede .repo-Datei unter /etc/yum.repos.d/ die Optionen gpgcheck und gpgkey selbstständig. gpgcheck=1 aktiviert die Signaturprüfung für die Pakete selbst, während repo_gpgcheck=1 zusätzlich die Metadaten des Repositorys absichert, ein Unterschied, der in vielen Community-Anleitungen übersehen wird. Ein Repository mit gpgcheck=0 installiert Pakete ohne jede kryptografische Prüfung, was bei einem kompromittierten Mirror ein direktes Einfallstor für manipulierte Binaries ist.

Anders als bei APT, wo Schlüssel meist automatisch beim Hinzufügen einer Quelle importiert werden, verlangt DNF häufig einen expliziten Import via rpm --import, bevor die erste Installation aus dem Repo gelingt. Das ist tatsächlich ein Sicherheitsvorteil, weil der Admin den Fingerprint des Schlüssels sehen und bewusst bestätigen muss, statt dass der Import stillschweigend im Hintergrund läuft. dnf repolist und dnf config-manager --dump zeigen zuverlässig, welche Repos aktiv sind und wie ihre GPG-Konfiguration aussieht.

8. Audits automatisieren und in CI/CD absichern

Manuelle Audits sind gut für eine einmalige Bestandsaufnahme, veralten aber sofort, sobald jemand ohne Rücksprache eine neue Quelle hinzufügt. Der wirksamere Ansatz ist, den Soll-Zustand der Paketquellen als Konfiguration zu verwalten, etwa via Ansible oder einem einfachen Shell-Skript, das im CI-Lauf gegen den Ist-Zustand des Servers prüft. So fällt eine unautorisierte Aenderung sofort beim nächsten Deployment-Check auf, statt Monate später bei einem Incident-Response entdeckt zu werden.

Für Container-Images empfiehlt sich zusätzlich, das Hinzufügen von Paketquellen im Dockerfile nachvollziehbar und mit fixierten Schlüssel-Fingerprints zu dokumentieren, statt Schlüssel bei jedem Build frisch vom Keyserver zu laden. Ein Build, der einen fremden Schlüssel ungeprüft zur Build-Zeit nachlädt, ist ein Reproduzierbarkeits- und Sicherheitsrisiko zugleich: Aendert sich der Schlüssel auf dem Keyserver zwischen zwei Builds, entsteht ein Image mit anderer Vertrauensbasis, ohne dass sich am Code etwas geändert hat.

# Ansible task: enforce a known-good set of APT sources, fail on drift
- name: Verify only approved package sources are configured
  ansible.builtin.command:
    cmd: >
      bash -c "comm -23
      <(grep -rhE '^deb ' /etc/apt/sources.list.d/*.list 2>/dev/null | sort -u)
      <(sort /etc/ansible/files/approved-sources.txt)"
  register: unapproved_sources
  changed_when: false
  failed_when: unapproved_sources.stdout != ""

- name: Fail the play if drift was detected
  ansible.builtin.fail:
    msg: "Unapproved package source detected: {{ unapproved_sources.stdout }}"
  when: unapproved_sources.stdout != ""

9. Paketquellen-Absicherung im direkten Vergleich

Die folgende Uebersicht fasst zusammen, welche gängige Praxis im Umgang mit Paketquellen unsicher ist und welches Muster stattdessen empfohlen wird.

Der gemeinsame Nenner aller Zeilen in der Tabelle: Vertrauen sollte immer explizit, eng begrenzt und nachvollziehbar sein, statt implizit und global. Ein einzelner kompromittierter Schlüssel oder ein einzelnes übersehenes gpgcheck=0 reicht aus, um die gesamte Signaturprüfung für ein System auszuhebeln, egal wie sorgfältig alle anderen Quellen konfiguriert sind.

10. Zusammenfassung

Die sichere Verwaltung von Paketquellen ist keine einmalige Einrichtungsaufgabe, sondern eine dauerhafte Verpflichtung. GPG-Signaturen bilden das kryptografische Fundament, das Manipulation an Repository-Metadaten und Paketen aufdeckt, unabhängig davon, ob der Transportweg per HTTPS zusätzlich abgesichert ist. Die Migration von apt-key zu scoped Keyrings mit signed-by= verhindert, dass ein kompromittierter Drittanbieter-Schlüssel systemweite Wirkung entfaltet. PPAs und Drittanbieter-Repos bringen aktuelle Software, aber ohne die redaktionelle Prüfung offizieller Archive, weshalb ein kurzer Blick auf Maintainer und Aktivität vor jedem Hinzufügen Pflicht sein sollte.

Installationsskripte per curl | sudo bash auszuführen, ohne sie vorher gelesen zu haben, bleibt eines der unterschätztesten Risiken im täglichen Admin-Alltag. Wer Download und Ausführung konsequent trennt und ein regelmäßiges, idealerweise automatisiertes Audit aller aktiven Quellen etabliert, reduziert die Angriffsfläche eines Servers spürbar, ohne die Praktikabilität der Paketverwaltung einzuschränken.

11. FAQ: Paketquellen sicher verwalten und prüfen