Linux-Server: Updatemanager und Festplattenverschlüsselung parallel möglich?

Hallo Community,

da dies mein erster Thread in diesem Forum ist, moechte ich erstmal Hallo sagen: Hallo zusammen :)

Warum habe ich mich auf linuxforen.de angemeldet? Weil ich zu folgender Fragestellung bisher keine befriedigende Antwort finden konnte und hoffe im Forum eine zu erhalten.

Meine Frage ist eher theoretischer Natur und zielt darauf ab, ob es ueberhaupt moeglich ist die Daten auf einen Linux-Server gegen physischen Diebstahl zu sichern, wenn man Updates nicht manuell einspielen moechte? Ich versuche es an zwei UseCases klarer zu machen:

UseCase1: Server wird gestohlen
Um die Daten vor dem Zugriff durch den Dieb bestmoeglich zu schuetzen kann man die Festplatte verschluesseln. (Das es durch technische Weiterentwicklung bzw. eingesetzte Zeit und Rechenleistung durch den Dieb theoretisch moeglich bleibt die Verschluesselung zu entschluesseln ist klar.)

UseCase2: Server wird vom Internet aus angegriffen
Um die Daten vor dem Zugriff aus dem Netz zu schuetzen kann man beliebig viel Aufwand treiben. Ein Basisbaustein wird immer die Aktualitaet des Betriebssystems sein.

Konfiguriert man beispielsweise unattended-upgrades derart, dass bei Updates, die ein Reboot erfordern, der Reboot auch ungefragt durchgefuehrt wird, wuerde nach meinem Verstaendnis der Reboot bei der Abfrage der Passphrase einer verschluesselten Festplatte „haengen bleiben“.

Gibt es eine Loesung fuer das Problem?

Kann man z.B. dem Server beibringen die Passphrase nur bei Kaltstarts abzufragen – anders gesagt, kann Linux zwischen Kaltstart und Neustart/Reboot unterscheiden?
Oder kann man das Problem nur dadurch loesen, dass man die automatischen Updates bei einem notwendigen Reboot manuell abschliesst? Was gegen das Ziel der Frage waere, aber wenn es so ist, ist es eben so.

Vielleicht hat sich damit ja schon mal jemand beschaeftigt.

Viele Gruesse
Soeren

Autoreboot mit Verschluesselung, evtl. mit einem CryptKey, wie einem YBUI Key moeglich, gegen Verschluesslung per luks und standardsettings ist nichts einzuwenden

Hallo Huhn Hur Tu, danke für deine Antwort.

Nehmen wir eine Standardverschlüsselung via luks (cryptsetup) an.

Wie hilft ein Yubi-Key in der Situation? Bei Autoreboot müsste der Yubi-Key ja auch am USB-Port hängen (und würde damit vom Dieb gleich mit eingepackt werden) und manuell der Schlüssel angetippt werden, oder? Und ob man nun den YubiKey antippen muss oder die Passphrase eintippt ist dann ja auch schon egal.

Yubi-Key & Co werden dir in der Tat nicht helfen, da muss halt gedrückt werden - der Neustart klemmt.


Suche nach "luks automount" - automatisches mounten ist vorgesehen, es gibt viele Beispiele

Das Ding dabei ist halt, wenn man den Rechner starten kann, kann man den auch Angreifen, wenn man eine Root-Shell erlangt hat, sind die Daten nicht mehr Geheim, das wäre nicht so, wenn man was eingeben müsste.
Der Boot Loader (zB grub) sollte entsprechend abgesichert sein, wenn man zB Boot Parameter ändern darf, kann man sich sehr schnell eine Root Shell einrichten.
Beim System verschlüsseln war es ursprünglich so, dass man einen Boot Bereich brauchte der unverschlüsselt bleibt. Diesen Bereich kann man auch als Vektor nutzen. Inzwischen kann aber wohl wirklich alles verschlüsseln, also auch den Boot Bereich, dass soll aber deutlich aufwendiger sein, daher ist es wohl noch immer so, dass man sagen darf, dass das Gesamtsystem verschlüsselt ist, obwohl ein kleiner Bereich nicht verschlüsselt ist - jedenfalls ist das bei Mint vor einigen Jahren so gewesen (2016) - https://wiki.archlinux.org/index.php...ice_encryption - Arch Linux bot damals die beste Doku zum Thema, daher der Link auf die; dm-cryp ist glaube ich einfach nur ein anderer Begriff für cryptsetup

Was ich halt ausdrücken möchte, um die Angriffsvektoren zu minimieren, brauchst du ein wirklich vollständige verschlüsseltes System, also auch einen verschlüsselten Boot Bereich. Bessere im Sinne der Sicherheit wäre es aber, wenn es Bereiche gibt die ein Passwort brauchen, das System kann ja trotzdem booten.

Weiterhin, diese Auto-Upgrade Thematik ist und bleibt schwierig (Frag mal Windows 10 User, oder Leute mit einem Tesla, IoT ist wohl auch schon so einiges defekt geupdatet worden). Es ist vermutlich unrealistisch, aber bessere wäre es, wenn man weiß, warum man da was ändert/updated - bei einem Server gilt das umso mehr.

Ahoi Sören und ahoi alle anderen,

dies ist auch mein erster Post.
Ich hatte mir auch mal eine ähnliche Frage gestellt und bin auf diesen Artikel gestoßen:
https://www.thomas-krenn.com/de/wiki...H_freischalten

Es gibt noch die Möglichkeit über ein Schlüsselserver, [s](irgendwas mit Klank oder crank, ich werde diesen Post editieren wenn ich was gefunden habe)[/s] https://www.admin-magazine.com/Archi...levis-and-Tang

Bis dahin.

E: Ich bin zu Blöd den Text durchzustreichen...

Danke schon mal für euere Antworten.

- Mein Stand ist auch der von nopes beschriebene, also dass ein Teil des Systems unverschlüsselt bleibt. Die Hinweise zur Absicherung von Grub und einer "echten" Vollverschlüsselung finde ich hilfreich.
- Bzgl. Updates. Klar muss man sich zwischen "never touch a running system" und dem manuellen/automatischem schließen von Sicherheitslücken entscheiden. Als Hobby-Linux-Server-Baumeister habe ich nicht den Anspruch alle Updates auf Bugs zu prüfen, sondern würde annehmen, dass es eher positiv ist, wenn verwendete Pakete aktualisiert werden. Das Risiko, dass etwas "defekt-gepatcht" wird, besteht zwar, aber auf einem Server sind doch hauptsächlich Standardanwendungen mit einem hohen Verbreitungsgrad, so dass ich klar zu den Updates neige.

Viele Grüße
Sören

Inzwischen habe ich noch ein wenig mehr gelesen und komme zu dem Schluss, dass sich das Problem grundsätzlich nicht auflösen lässt. (Ich lasse mich gerne eines besseren belehren.)
Anders gesagt: Egal welchen Umfang des Systems man verschlüsselt muss zum Reboot der Schlüssel vorhanden sein. Wenn der Schlüssel kein Passwort sein darf, sondern eine Schlüsseldatei sein muss, muss diese lesbar also unverschlüsselt abliegen. Auch eine Absicherung von Grub bringt wiederum keinen Erfolg, da mindestens der Defaultstartpfad ohne Passworteingabe funktionieren müsste, um ein Reboot ohne Benutzer/Admin-Eingriff zu ermöglichen. Somit besteht bei Diebstahl der Hardware und Automount quasi automatisch Zugriff, der nur noch durchs Passwort geschützt ist

Das alternatives Setup wäre demnach ein System, bei dem Grub vollständig Passwortgeschützt ist, so dass keine einfache Manipulation am Kernel oder den Parameter erfolgen kann und zusätzlich die gesamte Platte verschlüsselt, ob mit Passphrase oder Keyfile ist dann auch schon egal, ist. Muss man dem System nur noch beibringen, dass es einem bei Updates, die ein Reboot benötigen, informiert, bevor der Reboot manuell ausgeführt wird (Begrenzen der Admintätigkeit auf ein Minimum). Dazu scheint es das Paket update-notifier-common zu geben.

Evtl. kann man ein einmalig die Passwortabfrage für einen reboot aussetzen.
Das hatten wir bei einem Kunden für eine andere (Windows mit 3rd Party Software) gemacht. Hier wurden die Systeme beim Patchen damit rebootet und man kam wieder remote an das System.
Bei einem außerplanmäßig Ausfall braucht man natürlich wieder Zugriff.