Anzeige:
Ergebnis 1 bis 8 von 8

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

  1. #1
    Registrierter Benutzer
    Registriert seit
    Apr 2020
    Beiträge
    4

    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
    Geändert von Sören (17.04.20 um 17:03 Uhr)

  2. #2
    Registrierter Benutzer Avatar von Huhn Hur Tu
    Registriert seit
    Nov 2003
    Ort
    Karlsruhe
    Beiträge
    2.243
    Autoreboot mit Verschluesselung, evtl. mit einem CryptKey, wie einem YBUI Key moeglich, gegen Verschluesslung per luks und standardsettings ist nichts einzuwenden
    Zwischen anonym sein wollen und seine Daten nicht verkaufen wollen, liegen zwei Welten. Wenn man sich einen kostenpflichtigen Dienst sucht, dann meist, weil man für diese Dienstleistung zahlt und nicht selbst das Produkt sein will.


  3. #3
    Registrierter Benutzer
    Registriert seit
    Apr 2020
    Beiträge
    4
    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.

  4. #4
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    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.
    Geändert von nopes (18.04.20 um 17:05 Uhr)
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  5. #5
    Registrierter Benutzer
    Registriert seit
    Apr 2020
    Beiträge
    1
    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...
    Geändert von DrToast (20.04.20 um 22:38 Uhr)

  6. #6
    Registrierter Benutzer
    Registriert seit
    Apr 2020
    Beiträge
    4
    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

  7. #7
    Registrierter Benutzer
    Registriert seit
    Apr 2020
    Beiträge
    4
    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.
    Geändert von Sören (01.05.20 um 18:23 Uhr)

  8. #8
    Registrierter Benutzer
    Registriert seit
    Jun 2006
    Beiträge
    194
    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.

Ähnliche Themen

  1. Neueinrichten/Booten von Live-CD nicht möglich
    Von greyhawk im Forum System installieren und konfigurieren
    Antworten: 1
    Letzter Beitrag: 05.01.19, 17:52
  2. Ubuntu 8.04 Updatemanager
    Von tkay im Forum Anwendungen Allgemein, Software
    Antworten: 9
    Letzter Beitrag: 19.10.08, 19:49
  3. mehrere X-Server parallel
    Von Irrlicht im Forum X-Konfiguration
    Antworten: 5
    Letzter Beitrag: 06.07.04, 17:30
  4. mehrere x-server parallel?
    Von mat74 im Forum X-Konfiguration
    Antworten: 4
    Letzter Beitrag: 22.10.03, 20:51
  5. back to the root!(nur konsole?m*glich)
    Von namous im Forum Linux Allgemein
    Antworten: 6
    Letzter Beitrag: 03.06.03, 03:38

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •