Quelle zu deiner Behauptung?
Gegenfrage: was erwartest Du bei Sicherheit und wie realisierst Du das?
Ich möchte eine Quelle zu Deiner Behauptung. Anscheinend wirst du diese schuldig bleiben, habe ich so im Gefühl.
2 „Gefällt mir“
Ich wollte nur testen, ob Du oder sonstwer einen Plan hat. Meine Liste worauf es ankommt findet sich öffentlich auf https://blog.lindenberg.one/DigitaleSelbstverteidigung.
Wenn ich gezielt frage, dann haben die meisten Verwender von Linux weder Festplattenverschlüsselung (geschweige denn Network-Authentication) noch eine ernsthafte (konsistente) Datensicherung des ganzen Systems.
Wird bei den meisten Distros halt nicht vorbereitet und macht daher eine Menge Arbeit und liefert Fehlerquellen ohne Ende. Ich habe es vor ein paar Jahren probiert und bin entnervt bei Windows geblieben. Ich weiß dass LUKS inzwischen TPM unterstützt werden, aber das reicht mir nicht. Und ich kenne bisher niemand der das verwendet - hier vielleicht jemand? Habe Anfragen an Proxmox und Suse gestellt - Proxmos supported verschlüsselte Systeme nicht, Suse antwortet gar nicht erst.
Bei Windows ist Bitlocker trivial aktiviert, welche Option man verwendet hängt von Bequemlichkeit vs. Risikobereitschaft ab. Der Schattenkopiedienst erlaubt konsistene Backups im laufenden Betrieb, bei mir von mehreren Rechnern teilweise mehfach am Tag inkrementell bei einem Gesamtvolumen von mehreren TB, und die Linux-VMs werden dabei einfach mitgesichert.
Bin ich zu dumm für Linux? Oder zu anspruchsvoll? Oder zu bequem? Von allem ein bisschen 
2 „Gefällt mir“
Ich hab die Beiträge vom ursprünglichen Thema abgetrennt, da sie nicht zur eigentlichen Fragestellung passen, sich aber daraus durchaus eine interessante Disskusion entwickeln könnte.
Es kommt drauf an, was man möchte. Ich persönlich hab Clients die durch btrfs und Snapshots out of the box gesichert werden. Bei anderen Clients zieh ich mir max. 1x im Jahr bzw. evtl. bei größeren Updates ein Vollbackup.
Ich verwende für LUKS ganz bewusst nicht den TPM. Klar, es ist benutzerfreundlicher, aber die Frage ist auch „Möchte ich, dass bei einem Diebstahl jemand bis zum Anmeldebildschirm kommt oder möchte ich ihn schon weit vorher aufhalten?“. Mir ist letzteres lieber, bin aber (nur zum Vergleich) auch kein Fan von z.B. Androids dateibasierter Verschlüsselung (File-Based Encryption) und vermisse dort die Vollverschlüsselung auf Geräteebene (Full Disk Encryption). Jedenfalls denke ich, dass wenn das Interesse am TPM größer wäre, auch die Distributionen sich eher dafür interessieren würden. Letztendlich hat die Community einen vergleichsweise großen Einfluss.
2 „Gefällt mir“
Ihr Mods seid in meinen Augen hyperaktiv. Gerade die Unterschiede mal darzustellen ist doch viel interessanter als jeden in seinem Topf schmoren zu lassen - aber das wollt Ihr wohl nicht.
ich benutze bei Bitlocker TPM+PIN und Netzwerkauthentifizierung - das ist mega sicher und benutzerfreundlich (keine Eingabe der PIN wenn der Keyserver erreicht wird), und auch die Konfiguration ist machbar und überprüfbar. Mitreden kann da Linux allenfalls mit Clevis & Tang.
anscheinend keinen wirksamen, sonst würden die Distros das besser unterstützen.
Über die Unterschiede kannst du gerne diskutieren und ein Thema aufmachen (oder wir ändern den Titel dieses Themas), aber man sollte halt auch die Eingangsfrage des TE im hinterkopf behalten, denn von Unterschied Windows/Linux stand da nichts. Es ist als Themenstarter enttäuschend, wenn die Diskussion von der ursprünglichen Frage abweicht und das eigentliche Anliegen dann in den Hintergrund rückt. Durch eine saubere Trennung lassen sich die Informationen nachträglich auch von anderen leichter wieder finden.
Benutzerfreundlich ja, aber sicher ist natürlich relativ - vor allem da der Recovery-Key in der Windows-Home-Variante standardmäßig in die Cloud hochgeladen wird. Der lässt sich zwar nachträglich löschen, aber da ist es ja bereits zu spät. Dass das Unternehmen vor allem zuletzt nicht gerade mit einem sorgfältigen Umgang mit Keys geglänzt hat, weckt nicht gerade viel vertrauen in Bitlocker. Dabei ist Vertrauen gerade in Sachen Verschlüsselung essentiell - was geht rein, was passiert und was kommt raus. Da fehlt für mich ein elementarer Baustein in der Kette. Die Netzwerkentsperrung lässt sich eher im Unternehmen als bei Privatanwendern umsetzen. Wobei sich auch da grundsätzlich die Frage stellt „Wie hoch ist das Risiko, dass unberechtigte Hardware entwenden oder Datenträger klonen?“.
Der TMP selbst schützt ja nur vor dem Diebstahl oder dem unbefugtem Klonen der Festplatte. Einen tieferen Sinn hab ich bisher nicht darin gesehen, weil am ehesten sowieso das gesamte Gerät entwendet wird. Das Einrichten von LUKS+TPM ist eigentlich keine große Sache, aber einen wirklichen Mehrwert hab ich für mich nicht gefunden. Richtig interessant wird allerdings erst die Kombination LUKS + FIDO2.
3 „Gefällt mir“
steht doch auf https://blog.lindenberg.one/DigitaleSelbstverteidigung#FV: ein paar €€ investieren. Ich habe nur Windows Pro und meine Recovery-Keys liegen im Active-Directory - auch das kann Linux nicht.
Und schon sind wir wieder bei Themen die übergreifend sind:
Ein normaler Finder oder Dieb wird die Hardware weiterverkaufen und nicht die TPM-Motherboard-Kommunikation abhören oder eine Cold-Boot-Attacke machen - zu aufwendig und Ertrag ungewiss. Das macht eher ein Spion oder die Staatsmacht, und da hilft es dann schon nicht nur auf das TMP zu setzen.
Ich halte nichts von FIDO2. Der Aufwand mit den redundanten Keys bei vielen Seiten oder Systemen - nein Danke. FIDO macht für mich nur im Unternehmen Sinn, wo ich für einen verlorenen zentral einen neuen bekanntmachen kann.
Wie werden mit der Pro-Variante die vorher genannten Zweifel ausgeräumt? 
Ähnlich wie vor ziemlich genau einem Jahr, gibt es übrigens wieder eine Schwachstelle in Bitlocker die erst gestern veröffentlicht wurde: CVE-2024-20666
Ein erfolgreicher Angreifer kann die BitLocker-Geräteverschlüsselungsfunktion auf dem Systemspeichergerät umgehen. Angreifende, die physischen Zugriff auf das Ziel haben, können diese Sicherheitsanfälligkeit ausnutzen, um Zugriff auf verschlüsselte Daten zu erhalten.
Quelle: msrc.microsoft.com
Microsoft veröffentlichte letztes Jahr auch ein Powershell Skript, um einen Fehler in Bitlocker/WinRE zu beheben - zwar ist es nach eigenen Aussagen nicht einfach die Schwachstelle auszunutzen, aber es sind diese wiederkehrenden Probleme mit Bitlocker, die keinen vertrauenswürdigen und soliden Eindruck machen. Gerade die WinRE hat leider schon mehrmals für eine Umgehung der Bitlocker Verschlüsselung gesorgt. Bleibt abzuwarten, wie sich das zukünftig noch entwickelt und welche Schwachstellen dort noch schlummern. Mir persönlich genügt das nicht für eine vertrauenswürdige Verschlüsselung. Wenn dir das genügt, dann passt das doch. Nicht alle haben die gleichen Anforderungen
Welcher Vorteil bleibt dann bei der Nutzung der TPM?
1 „Gefällt mir“
Bitlocker funzt ohne MS-Account, ist doch eigentlich klar, oder?
Du bist parteisch. Gib bei Google CVE + LUKS ein, da gibt es auch Treffer, sogar mit höherem CVSS als die von Bitlocker, und in ähnlicher Frequenz. Auch OSS hat Schwachstellen, denk nur an Heartblead, und ich könnte einige weitere Projekte aufzählen die bei mir im Einsatz sind und bei denen ich das auch mitbekomme.
Jede Software hat auch mal Schwachstellen und nicht immer ist es trivial die beim Kunden konsumierbar hinzubekommen. Ich weiß das aus meiner eigenen Berufserfahrung, war an der Beseitigung mehrerer Tausend Schwachstellen beteiligt. Microsoft macht im Vergleich zu anderen einen halbwegs guten Job, das mit dem Azurekey war natürlich sch… nur dass da die vergleichbare Kategorie im OSS-Bereich fehlt.
Tatsächlich sind die WinRE-Probleme in den Konfigurationen PIN oder TPM+PIN meist nicht relevant, aber wir werden die Diskussion sehen.
Dass der Dieb nicht einfach von USB/DVD booten und die Daten durchstöbern kann. Ich zeige das in meinen Kursen. Gilt übrigens auch bei Linux.
GNU Debian Linux
- hat keinen Telemetrie-Datenabfluss. Schon mal null Aufwand.
- die Grundkonfiguration ist: verboten, man muss es aktiv erlauben. Null Aufwand
- Backup-Tools gibt es gleichwertige on the box wie bei MS-Windows.
- Plattenverschlüsselung wird bei der Installation abgefragt.
- Bei der Installation werden root und user explizit eingerichtet, user hat also keine Admin-Rechte
Das mal so kurz hingeschrieben in einfachen Worten.
Für eine Bewertung bedarf es nun aber weitere Grundlagen, um dann auch vergleichen zu können.
Die erste Frage ist wie immer: welcher Schutzbedarf wird benötigt und welche Wahrscheinlichkeiten haben welchen Risiken?
Wie wir alle ja wissen, 100% Sicherheit gibt es nicht. Eine präzisere Fragestellung für einen Vergleich wäre also so das Minimum 
Ich verwende Qubes. Das ist viiiiieeeel besser als das, was die Windows-Jünger gerne behaupten über ihre kommerzielle Software. Und meine Mobile hat GrapheneOS.
Deine Liste bei lindenberg.one kann ich nicht ganz folgen, weil das ein aneinanderreihen von Aspekten ist. Der Autor selbst schreibt am Ende ja genau den Punkt, wer bitte schön welche Fähigkeiten benötigt, um Sicherheit an seiner Maschine zu gewährleisten. Ergo ist die Diskussion bis auf weiteren so nicht zielführend, weil dann müsste mal die Zielgruppe eindeutig definiert sein!
Von A bis Z: A wie Anfänger*in und Null Bock auf investieren für Privacy bis eben hin zu Führungskräften einer Widerstandsbewegung. Die ersteren hühnern den ganzen Tag auf ihren Maschinen rum, letztere sollte die Maschine eher nur nutzen, wenn es wirklich notwendig ist und am besten auch permanent bei sich tragen.
Ich wollte nur testen, ob Du oder sonstwer einen Plan hat.
Und das ist ja dann auch ne Krönung, worum es geht. Hahaha
4 „Gefällt mir“
Ja, aber was ändert das am grundlegenden Problem? Es geht ja nicht darum, Wege zu finden, um bestimmte Probleme zu umgehen, sondern bereits um das grundlegende Konzept für den durchschnittlichen Nutzer.
Es ist nun mal so, dass der Recovery-Key in die Cloud geladen wird - eine Praxis, die nichts mit Benutzerfreundlichkeit zu tun hat und ein absolutes No-Go in Bezug auf IT-Sicherheit ist. Ein Private-Key oder ein Recovery-Key gehört niemals - unter keinen Umständen - in die Cloud. Wenn bereits an dieser Stelle Dinge getan werden, die im Widerspruch zu bewährten Praktiken und Prinzipien stehen, wo dann noch? Na gut, steht ja im nächsten Absatz …
Die Geschichte mit dem verlorenen Master-Signatur-Schlüssel ist natürlich ärgerlich und man könnte das als „blöd gelaufen“ abstempeln, aber das ging ja noch weiter. Auch hier wurden wichtige grundlegende Prinzipien gebrochen. Dieser Key war nicht nur für Outlook.com gültig, sondern für große Teile der Cloud z.B. Azure und Microsoft 365. Ein Key für fast alles bzw. vermutlich alles. Damit ist der Zugriff auf Sharepoint, Teams, OneDrive und viele weitere Dienste möglich. Das betrifft nicht nur Privatanwender, die dort ihre persönlichen Dokumente und Fotos ablegen, sondern sowohl Regierungen und Unternehmen wie auch die Schulklasse aus dem Nachbardorf, die dort Daten ablegt. Chatverläufe, Besprechungsnotizen, Kalendereinträge, Dokumente, einfach alles.
Aber auch das ging noch weiter: heise schrieb dazu:
Auch in von Unternehmen selbst betriebenen Azure-AD-Instanzen und deren Cloud-Appikationen hätten die Storm-Trooper demnach einfach reinspazieren können, wenn diese auch anderen AAD-Instanzen vertrauten und etwa ein „Login with Microsoft“ ermöglichten. Das wäre der Größte Anzunehmende Unfall (GAU) für einen großen Identitäts-Provider, der Microsoft gerne sein möchte.
Nicht nur die von Microsoft selbst betriebene Cloud, sondern auch ganz andere Dienste und Anwendungen. Ich persönlich würde das eher als Super-GAU definieren, denn etwas schlimmeres hätte eigentlich gar nicht passieren können. Die widerwilligen und knappen Stellungnahmen, die nur unter hohem Druck erschienen, runden das Gesamtpaket ab.
Nein, aber ich schrieb ja bereits, dass wir anscheinend unterschiedliche Vorstellungen von IT-Sicherheit haben. Keine Software ist perfekt und überall können Schwachstellen schlummern, die vielleicht nie oder erst nach Jahren entdeckt werden. Hier geht es aber nicht um die komplexe Verkettung von Schwachstellen, um Malware auszuführen oder Daten auszuleiten. Das hat nicht mal etwas mit Microsoft-Bashing zu tun, sondern um die simpelsten der simplen Grundlagen in der IT-Sicherheit. Das betrifft Verschlüsselungstools genauso wie Messenger, Betriebssysteme oder Browser-Addons.
Wenn man darüber nachdenkt, ist es eigentlich paradox, wenn man einerseits sagt „Security by obscurity ist eine Gefahr“, während andererseits volles Vertrauen in eine geschlossene Software ohne externes Audit gesetzt wird, während der Hersteller grundlegende Prinzipien in der IT-Sicherheit missachtet.
Wie soll das bei der Verwendung von LUKS ohne TPM funktionieren?
3 „Gefällt mir“
Wer sich mit Sicherheit unter Linux und hardening beschäftigen will:
https://madaidans-insecurities.github.io/guides/linux-hardening.html
Das stimmt m.W. nur, wenn Du einen MS-Account verwendest. Wenn ich nachsehe, wird mir Azure noch nicht einmal als Option angeboten.
sehe ich genauso. Aber ich nutze Azure oder MS365 nicht. Auch Google nicht. Und AWS nur zum Erzeugen von Stimmen.
Natürlich nicht. Aber meine Maschinen sollen selbst starten können, daher verwende ich Netzwerkauthentifizierung. Bin halt nicht immer zuhause.
Es ist irrelevant, was genutzt oder nicht genutzt wird. Ich dachte, das ging aus dem Beitrag deutlich hervor
Naja, dann passt doch alles mit LUKS ohne TPM.
Hab grad mal kurz recherchiert und die Liste an Fehltritten muss erweitert werden:
- Der Master-Signatur-Schlüssel ist 2021 abgelaufen, konnte aber 2023 noch verwendet werden.
- Crashdumps (mit dem Key) stammt aus dem Jahr 2021
Scheinbar hat der Hersteller allgemein kein gutes Händchen für IT-Sicherheit und den korrekten Umgang mit Token: Datenleck: Microsoft AI-Forscher verlieren 38 TByte an internen Daten über GitHub/Azure Cloud-Speicher (www.borncity.com)
Zusammenfassung:
- Als die Sicherheitsforscher aber genauer hinschauten, fanden sie heraus, dass zu dieser URL ein falsch konfiguriertes SAS-Token gehörte, welches Dritten die Berechtigungen zum Zugriff auf das gesamte Speicherkonto gewährte.
- Das SAS-Token wurde am 20. Juli 2020 erstmals auf GitHub eingestellt, wobei ein Ablaufdatum auf 5. Oktober 2021 festgelegt worden ist. Dann wurde am 6. Oktober 2021 das Ablauf-Token erneuert und mit dem Ablaufdatum 6. Oktober 2051 versehen.
- Die über das GitHub Repository erreichbaren Verzeichnisse enthielten die persönlichen Computer-Backups von zwei Microsoft-Mitarbeitern. In diesen Backups fanden sich sensible persönliche Daten, darunter Passwörter für Microsoft-Dienste, geheime Schlüssel und über 30.000 interne Microsoft Teams-Nachrichten von 359 Microsoft-Mitarbeitern.
- Die Sicherheitsforscher von Wiz stießen am 22. Juni 2023 auf das Problem und meldeten dieses dem MSRC. Zu diesem Zeitpunkt stand die Azure-Speicherinstanz wohl bereits zwei Jahre für Unbefugte offen.
Erklärung SAS-Token
In Azure ist ein SAS-Token (Shared Access Signature) eine signierte URL, die Zugriff auf Azure Storage-Daten gewährt. Die Zugriffsebene kann vom Benutzer angepasst werden; wobei die Berechtigungen von schreibgeschützt bis zur vollständigen Kontrolle reichen. Dabei kann der Umfang der Zugriffsrechte sich entweder auf eine einzelne Datei, einen Container oder ein ganzes Speicherkonto beziehen. Auch die Ablaufzeit für Zugriffe ist vollständig anpassbar, so dass der Benutzer Token mit unbegrenzter Gültigkeitsdauer erstellen kann. Diese Granularität bietet den Benutzern eine große Flexibilität, birgt aber auch das Risiko, zu viel Zugriff zu gewähren. Im freizügigsten Fall (wie beim obigen Token von Microsoft) kann das Token für immer volle Kontrollrechte für das gesamte Konto gewähren – und damit im Wesentlichen dieselbe Zugriffsstufe wie der Kontoschlüssel selbst bieten.
Nichts für ungut, aber wer bei solch gravierenden Anfängerfehlern noch Vertrauen in die Produkte hat: Hut ab!
6 „Gefällt mir“
Das sollte man mal unserer Regierung bzw. der deutschen IT sagen aber die wollen ja nicht hören und nur mit dem Mainstream gehen
2 „Gefällt mir“
Verstehe ich trotzdem nicht. Auf den mir bekannten Seiten steht, dass der Key nur bei Geräteverschlüsselung aka Device Encryption (der Bitlocker-Variante von Windows-Home) hochgeladen wird und nur dann wenn man mit MS-Account angemeldet ist (sonst lese ich = nicht ausprobiert kann man Device Encryption nicht aktivieren, da ist MS strikt). Meine Pros und Server haben keine MS-Accounts sondern lokale Domänenaccounts (auch die nicht mit Azure verknüpft).
Wo steht dass dann trotzdem Keys hochgeladen werden? Oder ausprobiert? Hätte Ideen wie man das überprüfen kann, aber der Versuchsaufbau ist einigermaßen kompliziert…
Im Grunde ist die Zusammenfassung:
Wenn die aufdeckten Mängel im absoluten Widerspruch zu bewährten Praktiken und Prinzipien in der IT-Sicherheit stehen, wo dann noch?
Solche Fehler erwartet man von einem Berufsschüler der zum ersten mal Git verwendet, aber nicht von einem weltweit agierenden Softwarekonzern mit rund 200 Milliarden Dollar Umsatz. Die Frage ist letztendlich, ob man dem Hersteller überhaupt noch zutraut sichere Software zu bauen, wenn es bereits an solch banalen Dingen scheitert. Klar kann es mal passieren, dass man aus versehen ein Secret ins Repo pushed, aber dann auch noch ein zweites mal und zusätzlich die Gültigkeit des Tokens bis ins Jahr 2051 verlängern?!
Anders formuliert: Es geht hier nicht um einen Handwerker, der einfach nur einen schlechten Tag hatte und keine 100 % perfekte Arbeit geleistet hat. Hier geht es um einen Handwerker, der die Grundlagen in seinem Handwerk nicht verstanden hat.
4 „Gefällt mir“
aber die Frage, ob Du konkret weißt und woher, ob Bitlocker-Keys bei Windows Pro hochgeladen werden, hast Du damit nicht beantworten wollen/können.
Ich will den Azure-Master-Key-Fall nicht beschönigen, aber der hat mit dem lokalen Bitlocker wenig zu tun. Und wir wissen alle, dass Software beim Kunden reift, und die Cloud ist nicht dort
Es ging nie um die Windows Pro Variante, siehe hier:
Kommt drauf an. Wenn das best practice ist, möchte ich nicht wissen, wie es anderen Stellen aussieht…
1 „Gefällt mir“