Alternative zu Tails für digitale Sicherheit Qubes OS mit Whonix: Starkes Duo für mehr Anonymität

Qubes OS in Kombination mit Whonix setzt auf kompromisslose Isolation und anonymes Routing über Tor. Der Beitrag erklärt die Sicher­heits­ar­chi­tek­tur mit Qubes, zeigt Einsatzmöglichkeiten im Alltag zum Schutz sensibler Daten und erklärt, warum das Duo als ernsthafte Alternative zu Tails gilt.

Viele stoßen über Tails OS auf das Thema digitale Anonymität. Das System verschlüsselt standardmäßig den Datenzugriff, routet allen Verkehr konsequent über das Tor-Netzwerk und speichert nichts, was nicht explizit in einem Persistent-Volume abgelegt wurde. Doch sobald Root-Zugriff möglich ist, lässt sich der Schutz aushebeln. Tor ist dann nutzlos, die reale IP-Adresse liegt offen.

Qubes OS agiert im Gegensatz mit einem Konzept, das auf kompromisslose Isolation setzt. Jeder Internetzugriff erfolgt in einem abgeschotteten Qube. Ein Angriff, der bei Tails das gesamte System kompromittiert hätte, betrifft unter Qubes nur die einzelne AppVM. Die reale IP-Adresse bleibt geschützt, solange kein VM-Escape gelingt, was in der Praxis äußerst selten ist. Die Installation des Sicherheits-Linux Qubes OS haben wir in einem eigenen Artikel beschrieben.

Bildergalerie

Bildergalerie mit 5 Bildern

Video-Tipp #73: Qubes OS

Qubes OS installieren und sicher im Alltag nutzen

Whonix ist in Quebes OS integriert

Whonix ist in Qubes OS integriert, aber härter segmentiert als in KVM-Installationen. Die Workstation verbindet sich nie direkt ins Tor-Netz, sondern leitet den gesamten Datenstrom an ein eigenes Gateway-Qube weiter. Dieses Gateway bleibt für den Benutzer unsichtbar, führt keine Anwendungen aus und kennt nur eine Aufgabe: Routing. Ein erfolgreicher Angriff müsste erst die Workstation kompromittieren, dann aus der VM ausbrechen, das Gateway angreifen und dort eine weitere Sicherheitslücke ausnutzen.

Dom0, Xen und Virtualisierungsvorteile

Qubes ist kein Einzwecksystem wie Tails. Neben Whonix liefert es farbcodierte AppVMs für den Alltag, etwa „personal“ (gelb) oder „work“ (blau). Jedes Fenster zeigt durch die Farbmarkierung an, in welchem Sicherheitskontext man sich gerade befindet, ein banales, aber wirksames Mittel gegen versehentliche Eingaben. Zwischen Whonix und personal umschalten stellt kein Problem dar. Parallelstart genügt. Der Wechsel erfolgt ohne Neustart.

Service- und Hardwaretrennung durch spezialisierte Qubes

Netzwerkzugriff erfolgt nicht direkt aus AppQubes. Stattdessen übernehmen sys-net, sys-firewall und optionale VPN- oder DNS-Qubes die Kaskade. USB-Zugriff geht ausschließlich über sys-usb, der wiederum vom eigentlichen Arbeits-Qube isoliert bleibt. So lassen sich etwa Angriffe durch präparierte USB-Sticks abfangen. Die vault-VM dient der Speicherung sensibler Daten und hat keine Netzwerkverbindung, kein USB-Zugriff, keine versehentlichen Datenlecks.

Bildergalerie

Bildergalerie mit 5 Bildern

Qubes im Alltag und individuelle Anwendungsfälle

Praktisch bewährt sich Qubes vor allem dann, wenn klare Trennung nötig ist: Ein E-Mail-Anhang soll geöffnet werden, doch das Risiko erscheint zu hoch? Disposable VMs schaffen Abhilfe. Sie starten temporär, führen isoliert den Inhalt aus und löschen sich nach dem Schließen selbst. Wer produktiv mit mehreren Identitäten arbeitet, etwa beruflich getrennt von privaten oder politischen Aktivitäten, kann jedem Bereich eigene Qubes zuweisen. Allein durch die farbige Fensterleiste lässt sich sofort erkennen, welche Umgebung aktiv ist. Kommunikationswege lassen sich je nach Sicherheitsstufe segmentieren, etwa separate Qubes für Aktivismus, Softwareentwicklung, private Kontakte und verschlüsselten Nachrichtenaustausch.

Qubes Manager im Überblick

Im Zentrum der Systemverwaltung steht der Qubes Manager. Hier lassen sich einzelne Qubes starten, stoppen, konfigurieren oder löschen. Farbmarkierungen machen auf einen Blick sichtbar, welcher Qube welchem Sicherheitskontext zugeordnet ist. Änderungen an Firewall-Regeln, Dienstverbindungen oder Template-Zuweisungen erfolgen direkt über das Kontextmenü oder die jeweiligen Einstellungen.

Die globale Konfiguration erlaubt die Wahl zwischen stabilen, sicherheitsfokussierten oder experimentellen Update-Kanälen. Auch Speichereinstellungen, Standard-Templates, Zwischenablagenutzung und Geräteweiterleitungen lassen sich dort definieren. Eine Besonderheit ist die zentrale Steuerung des Update-Verhaltens: Templates, Gateways und AppQubes können getrennt aktualisiert und durch Restart synchronisiert werden. Wer eigene Template-Anpassungen durchführt, muss darauf achten, dass Anwendungen zwar systemweit installiert, Konfigurationsänderungen aber nicht automatisch in abhängige AppQubes übernommen werden.

Die Verwaltung von Anwendungen innerhalb eines Qubes erfolgt über die zugewiesenen Menüeinträge. Nur was dort explizit aktiviert ist, erscheint im Startmenü. Das reduziert die Angriffsfläche und vereinfacht die Navigation. Services und Hardware-Zuweisungen, etwa für Audio, Kamera oder USB-Geräte, lassen sich ebenfalls granular konfigurieren. Jede VM besitzt eigene Ressourcenlimits, wählbare Kernel-Versionen und CPU-Zuteilungen.

Updates erfolgen typischerweise über sys-firewall oder sys-whonix. Temporäre Netzwerkverbindungen für Templates müssen manuell gesetzt und nach erfolgreicher Aktualisierung wieder entfernt werden. Installationen außerhalb der Template-VMs sind flüchtig, nur wer Software in Templates einbindet, kann sie dauerhaft und systemweit nutzen. Für produktive Nutzung empfiehlt es sich, individuelle Templates pro Sicherheitsbereich zu erstellen, etwa getrennte Umgebungen für Kommunikation, Recherche, Softwareentwicklung oder öffentliches Browsing.

Bildergalerie

Bildergalerie mit 5 Bildern

Anonym und sicher im Internet surfen

Tor und Tails fusionieren

Geräteverwaltung mit dem Device Manager

Externe Geräte wie Kameras, Mikrofone oder USB-Sticks lassen sich in Qubes OS gezielt einzelnen VMs zuweisen. Dafür steht der Device Manager zur Verfügung, der erkannte Hardware automatisch auflistet und deren Weiterleitung erlaubt. Die Sicherheitslogik bleibt erhalten. Ohne explizite Zuordnung bleibt ein Gerät funktionslos.

Ein Beispiel: Wird das integrierte Mikrofon oder die Webcam eines Laptops nicht manuell einem Qube zugewiesen, bleiben sie ungenutzt, selbst wenn Anwendungen wie Cheese oder SimpleScreenRecorder installiert wurden. Erst nach der Auswahl im Device Manager, etwa durch Zuweisung an den Personal-Qube, lassen sich Kamera und Mikrofon verwenden.

Auch physische USB-Keys oder externe Datenträger erscheinen direkt nach dem Einstecken und können on-the-fly an beliebige Qubes weitergeleitet werden. Die Zuweisung lässt sich jederzeit widerrufen. Qubes OS verhindert damit, dass Peripherie unkontrolliert Systembereiche erreicht.

Ein wichtiger Schritt bleibt das vorherige Installieren und Aktivieren der gewünschten Software im entsprechenden Template, da sich Applikationen nur dann im Qube-Menü aufrufen lassen. Nach dem Software-Setup müssen Template-VMs einmal neu gestartet werden, bevor Änderungen in abhängigen Qubes sichtbar werden. Erst dann lassen sich Geräte sinnvoll zuweisen und testen, in vielen Fällen direkt per grafischer Oberfläche oder Kommandozeile.

Unentdeckte Schadsoftware „Plague“ kapert PAM-Subsystem

Hochentwickelte Backdoor bedroht Linux-Server

BusKill als Alternative zum Tails-Not-Aus

Ein oft genannter Vorteil von Tails ist der physische Not-Aus. Läuft das System von einem USB-Stick und dieser wird entfernt, bricht das System ab. Daten bleiben verschlüsselt. Qubes bietet so etwas nicht nativ, doch BusKill schließt diese Lücke. Wird ein bestimmter USB-Stick abgezogen, reagiert das System mit konfigurierbaren Maßnahmen: Herunterfahren, Sperren, Datenlöschung. Anders als ein manuell auszuführender Shortcut funktioniert BusKill auch dann, wenn keine Zeit bleibt, und integriert sich problemlos in bestehende Qubes-Setups. Wer will, kann damit ein physisches Dead-Man-Switch-Verhalten in Qubes realisieren, das dem Tails-Modell überlegen ist.

Eigene Workstations und Spezial-VMs

Ein Vorteil von Qubes gegenüber Tails liegt in der Flexibilität. Es gibt keine Beschränkung auf Tor. Wer möchte, kann ein eigenes Qube auf Basis von Arch, Fedora oder Debian konfigurieren, VPN-Tunnel via Mullvad definieren und eigene Routingpfade bauen. Solche spezialisierten Qubes lassen sich als Templates abspeichern und jederzeit neu starten. Auch mehrere Netzwerkpfade nebeneinander sind möglich, etwa parallele Nutzung von Tor, VPN und anderen Internetverbindungen, sauber getrennt über NetVMs, FirewallVMs und ProxyVMs.

Bildergalerie

Bildergalerie mit 5 Bildern

Erweiterte Einsatz-Szenarien des Linux Unified Key Setup

Profi-Tipps zur Verschlüsselung mit LUKS

Clipboard, Passwortmanager und Datenflusskontrolle

Das Clipboard funktioniert nur über Interaktion mit dem Qubes-Widget: Erst selektieren, dann explizit für den Ziel-Qube freigeben. Das schützt gegen verdeckte Mitleser. Der Passwortmanager in vault lässt sich nutzen, um Anmeldedaten gezielt per Zwischenablage an Whonix oder personal weiterzugeben. Eine versehentliche Übertragung ist ausgeschlossen. Der Nutzer kontrolliert jede Übertragung aktiv.

Wer unbedingt Dateien nach dom0 transferieren will, obwohl dies dem Sicherheitsmodell zuwiderläuft, kann dies mit einem gezielten qvm-run --pass-io realisieren. Der Quell-Qube liefert seine Datei über einen cat-Aufruf, dom0 speichert sie über Umleitung. Der Befehl lautet:

Die umgekehrte Richtung, von dom0 in eine AppVM, ohne das integrierte qvm-copy-to-vm, funktioniert ebenso:

Solche Vorgehensweisen machen nur dann Sinn, wenn komplexe Pfadstrukturen oder Pipelining nötig sind. Sie setzen vollständiges Vertrauen in das Ziel-Qube voraus, andernfalls bleibt qvm-copy-to-vm mit Kontrolle durch den Qube Manager die sicherere Option.

Berechtigungen und Zugriffssicherheit steuern

Sicherheit von Linux-Dateisystem Ext4 verbessern

Firewallverhalten außerhalb der GUI

DNS-basierte Regeln im Firewalleditor sind problematisch. Wer eine Regel für updates.mycorp.local erstellt, muss wissen: Die Namensauflösung geschieht einmal beim Aktivieren des Qubes, nicht bei jeder Verbindung. Damit können IP-Wechsel aufgrund von Geo-Routing oder Lastverteilung zu ungewolltem Traffic-Block führen. Für flexible Ziele helfen nur statische IP-Adressen oder dynamisches Regel-Rewriting über rc.local.

ICMP-Pakete und DNS-Anfragen sind in der Firewall-GUI nicht regelbar. Wer sie gezielt unterbinden oder zulassen will, muss qvm-firewall im Terminal von dom0 nutzen. Für einen restriktiven Banking-Qube könnte das so aussehen:

qvm-firewall --add --rule allow --proto icmp --dst 192.0.2.42 banking

DNS lässt sich auf Port 53 fixieren, doch systemeigene Updates umgehen diese Regeln ohnehin, der Updates Proxy (updates.proxy.qubes) ist von der Firewall entkoppelt und wird nur durch entsprechende Richtlinien im Policy-Framework kontrolliert. Wer sicherstellen will, dass keine Templates oder dom0 unbeabsichtigt mit Paketquellen kommunizieren, muss /etc/qubes/policy.d/50-updates.policy entsprechend anpassen.

Netzwerkunterbrechungen nach NetVM-Absturz

Nach einem unerwarteten Neustart von sys-net, etwa durch WiFi-Treiberfehler oder Suspend-Wake-Probleme, bleibt häufig die Verbindung zu abhängigen Qubes unterbrochen. Der übliche Fehler ist dann „No NetVM configured“. Ein einfacher Befehl genügt zur Wiederherstellung:

Danach sind alle abhängigen AppVMs wieder verbunden. Firewall-Dienste wie VPN-Clients oder lokale DNS-Resolver haben in sys-firewall nichts verloren. Der Grund ist simpel, nftables-Regeln, die dort gesetzt werden, können mit denen des Qubes-eigenen Firewall-Frameworks kollidieren oder von Wartungsupdates überschrieben werden. Die empfohlene Trennung besteht aus einer Struktur wie:

Damit bleibt jede logische Ebene klar voneinander getrennt. Änderungen in sys-vpn können so nicht versehentlich die Absicherung der AppVMs kompromittieren. Um diese Kaskadierung umzusetzen, muss jedem Qube per qvm-prefs die passende NetVM zugewiesen werden.

Bildergalerie

Bildergalerie mit 5 Bildern

Sudo

Beliebtes Linux-Tool mit kritischer Schwachstelle

Wer Ports aus der Außenwelt nach innen in ein Qube weiterleiten will, muss die Weiterleitung an drei Stellen korrekt konfigurieren: In sys-net wird der eingehende Traffic empfangen, per DNAT an sys-firewall geleitet, dort erneut übersetzt und schließlich über die interne Qubes-IP ins Ziel-Qube übermittelt. Ein Beispiel: Ein Webserver in Qube webpub soll unter Port 443 erreichbar sein. In sys-net lautet der erste Schritt:

Dann:

und:

In sys-firewall wiederholt sich das Muster mit Zieladresse des AppVMs. Wer testet, kontrolliert die Zählerstände mit nft list table ip qubes und beobachtet, ob packets und bytes zunehmen. Eine stabile Methode für interne Portweiterleitungen zwischen Qubes ist die Nutzung von qvm-connect-tcp in Kombination mit einer systemd-Socket- und Service-Unit. Das erlaubt automatische Aktivierung beim Booten. Wer wissen will, ob seine Weiterleitungsregeln tatsächlich greifen, prüft mit tcpdump direkt auf den Interfaces:

Das zeigt in Echtzeit eingehende Verbindungen. Parallel sichert man die eigene nftables-Konfiguration mit:

Änderungen erfolgen im Testfile, am besten mit flush ruleset an erster Stelle, so bleibt das Backup als Rückfallmöglichkeit erhalten.

(ID:50540560)