Vollständige Festplattenverschlüsselung von Windows- und Linux-installierten Systemen. Verschlüsselte Multiboot.

Aktualisierte eigene Anleitung zur Vollfestplattenverschlüsselung im Netz V0.2.

Cowboy-Strategie:

[A] Blocksystemverschlüsselung des installierten Windows 7-Systems;
[B] Blocksystemverschlüsselung GNU/Linux (Debian) des installierten Systems (einschließlich /boot);
[C] GRUB2-Konfiguration, Schutz des Bootloaders durch digitale Signaturen/AUTHENTIFIKATION/Hashing;
[D] Löschen - Vernichtung unverschlüsselter Daten;
[E] Universelles Backup verschlüsselter Betriebssysteme;
[F] Angriff Ziel - Bootloader GRUB2;
[G] nützliche Dokumentation.

╭───Schema #Zimmer 40# :
├──╼ Installiertes Windows 7 - vollständige Systemverschlüsselung, nicht verborgen;
├──╼ Installiertes GNU/Linux (Debian und abgeleitete Distributionen) — vollständige Systemverschlüsselung nicht verborgen(/, einschließlich /boot; swap);
├──╼ Unabhängige Bootloader: Bootloader VeraCrypt im MBR installiert, Bootloader GRUB2 im erweiterten Partition installiert;
├──╼ Installation/Wiederinstallation des Betriebssystems nicht erforderlich;
└──╼ Verwendete kryptografische Software: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – frei/kostenlos.

Das oben beschriebene Schema löst teilweise das Problem des "tragbaren Bootens auf einen USB-Stick", ermöglicht es, verschlüsselte Windows/Linux-Betriebssysteme zu nutzen und Daten über einen "verschlüsselten Kanal" von einem OS zum anderen auszutauschen.

Reihenfolge des PC-Starts (eine der Optionen):

• Maschine einschalten;
• Bootloader VeraCrypt laden (richtige Eingabe des Passworts setzt das Laden von Windows 7 fort);
• Drücken der Taste "Esc" läd den Bootloader GRUB2;
• Bootloader GRUB2 (Auswahl Distribution/GNU/Linux/CLI), fordert die Authentifizierung des GRUB2-Superusers ;
• Nach erfolgreicher Authentifizierung und Auswahl der Distribution ist die Eingabe der Passphrase zur Entsperrung von "/boot/initrd.img" erforderlich;
• Nach der fehlerfreien Eingabe der Passwörter wird in GRUB2 "die Eingabe des Passworts" erforderlich sein (drittes Passwort, BIOS-Passwort oder Passwort des GNU/Linux-Benutzerkontos – nicht berücksichtigen) zur Entsperrung und zum Laden des GNU/Linux-Betriebssystems, oder automatische Eingabe des geheimen Schlüssels (zwei Passwörter + Schlüssel, oder Passwort+Schlüssel);
• Externe Eingriffe in die GRUB2-Konfiguration frieren den Ladeprozess von GNU/Linux ein.

Mühsam? Ok, lass uns die Prozesse automatisieren.

Bei der Partitionierung der Festplatte (MBR-Tabelle) kann der PC nicht mehr als 4 primäre Partitionen oder 3 primäre und eine erweiterte sowie nicht partitionierten Bereich enthalten. Eine erweiterte Partition kann im Gegensatz zu einer primären Partition Unterpartitionen enthalten. (logische Laufwerke=erweiterte Partition). Mit anderen Worten, die „erweiterte Partition“ auf der HDD ersetzt LVM für die aktuelle Aufgabe: die vollständige systemweite Verschlüsselung. Wenn Ihre Festplatte in 4 primäre Partitionen unterteilt ist, müssen Sie lvm verwenden oder (mit Formatierung) die Partition von primär auf erweitert ändern oder alle vier Partitionen sinnvoll nutzen und alles so belassen, wie es ist, um das gewünschte Ergebnis zu erzielen. Selbst wenn Sie nur eine Partition auf der Festplatte haben, hilft Ihnen Gparted dabei, die HDD (in zusätzliche Partitionen) ohne Datenverlust zu partitionieren, jedoch mit einem kleinen Preis für solche Aktionen.

Das Schema der Festplattenpartitionierung, auf das sich der gesamte Artikel bezieht, ist in der folgenden Tabelle dargestellt.

Tabelle (Nr. 1) der Partitionen 1TB.

Etwas Ähnliches sollte auch bei Ihnen vorhanden sein.
sda1 – primäre Partition Nr. 1 NTFS (verschlüsselt);
sda2 – erweiterte Partition Marker;
sda6 – logisches Laufwerk (darauf ist der Bootloader GRUB2 installiert);
sda8 – Swap (verschlüsselte Auslagerungsdatei/ nicht immer);
sda9 – Testlogisches Laufwerk;
sda5 – logisches Laufwerk für Neugierige;
sda7 – OS GNU/Linux (verschobenes OS auf das verschlüsselte logische Laufwerk);
sda3 – primäre Partition Nr. 2 mit OS Windows 7 (verschlüsselt);
sda4 – primäre Partition Nr. 3 (darin befand sich unverschlüsseltes GNU/Linux, wird als Backup verwendet/nicht immer).

[A] Blockweise systemweite Verschlüsselung Windows 7

A1. VeraCrypt

Booten von der offiziellen Website, oder von einem Spiegel sourceforge Installationsversion der Verschlüsselungssoftware VeraCrypt (zum Zeitpunkt der Veröffentlichung des Artikels v1.24-Update3, die portable Version von VeraCrypt eignet sich nicht für die Systemverschlüsselung). Überprüfen Sie die Prüfziffer der heruntergeladenen Software

$ Certutil -hashfile "C:VeraCrypt Setup 1.24.exe" SHA256

und vergleichen Sie das erhaltene Ergebnis mit der veröffentlichten Prüfziffer auf der Webseite des Entwicklers von VeraCrypt.

Wenn die Software HashTab installiert ist, ist es noch einfacher: Rechtsklick (VeraCrypt Setup 1.24.exe)-Eigenschaften-Dateihashes.

Zur Überprüfung der Programmunterschrift müssen die Software und der öffentliche pgp-Schlüssel des Entwicklers auf dem System installiert sein gnuPG; gpg4win.

A2. Installation/Start von VeraCrypt mit Administratorrechten

A3. Auswahl der Optionen für die systemweite Verschlüsselung der aktiven PartitionVeraCrypt – System – Systempartition/-laufwerk Verschlüsseln – Normal – Windows Systempartition verschlüsseln – Multiboot – (Warnung: „Unerfahrenen Benutzern wird empfohlen, diese Methode nicht zu verwenden“ und das ist wahr, wir stimmen zu „Ja“) – Bootlaufwerk („ja“, selbst wenn nicht, trotzdem „ja“) – Anzahl der Systemlaufwerke „2 oder mehr“ – Mehrere Systeme auf einer Festplatte „Ja“ – Kein Windows-Bootloader „Nein“ (de facto „Ja“, aber die Bootloader VeraCrypt/GRUB2 teilen sich nicht den MBR, genauer gesagt wird im MBR/Bootsektor nur der kleinste Teil des Bootloader-Codes gespeichert, der größte Teil befindet sich im Bereich des Dateisystems) – Multiboot – Einstellungen der Verschlüsselungsparameter…

Wenn von den oben beschriebenen Schritten abgewichen wird (Schema der blockbasierten Systemverschlüsselung), wird VeraCrypt eine Warnung ausgeben und die Verschlüsselung der Partition nicht erlauben.

Im nächsten Schritt, zur gezielten Datensicherung, führen Sie einen „Test“ durch und wählen Sie den Verschlüsselungsalgorithmus aus. Wenn Sie eine nicht moderne CPU haben, wird wahrscheinlich der Verschlüsselungsalgorithmus Twofish am schnellsten sein. Wenn die CPU leistungsstark ist, merken Sie den Unterschied: AES – die Verschlüsselung laut Test wird mehrere Male schneller sein als seine Kryptokonkurrenten. AES ist ein beliebter Verschlüsselungsalgorithmus, die Hardware moderner CPUs ist speziell auf „Geheimnis“ und „Knacken“ optimiert.

VeraCrypt unterstützt die Möglichkeit, Festplatten kaskadierend mit AES zu verschlüsseln.(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (ohne Hardwareunterstützung für AES, kaskadierende Verschlüsselung A/T) Die Leistungseinbußen sind im Wesentlichen nicht spürbar. (bei CPUs von AMD derselben Ära/~Parameter – die Leistung ist etwas reduziert). Das Betriebssystem arbeitet dynamisch und der Ressourcenverbrauch für transparente Verschlüsselung ist nicht spürbar. Im Gegensatz zu erkennbaren Leistungseinbußen durch die Installation der instabilen Desktop-Umgebung Mate v1.20.1 (oder v1.20.2, ich weiß nicht mehr genau) In GNU/Linux oder aufgrund der Telemetriearbeit des Unterprogramms in Windows 7. Normalerweise führen versierte Benutzer vor der Verschlüsselung Leistungstests der Hardware durch. Zum Beispiel in Aida64/Sysbench/systemd-analyze blame und vergleichen die Ergebnisse dieser Tests nach der Verschlüsselung des Systems und widerlegen damit für sich den Mythos, dass "systemweite Verschlüsselung schädlich ist". Die Verlangsamung der Maschine und die Unannehmlichkeit sind während der Sicherung/Wiederherstellung verschlüsselter Daten spürbar, da der Vorgang der "systemweiten Datensicherung" nicht in Millisekunden gemessen wird und die Operationen <On-the-fly entschlüsseln/verschlüsseln> hinzukommen. Letztendlich balanciert jeder Benutzer, der sich mit Krypto befasst, den Verschlüsselungsalgorithmus im Hinblick auf die Erfüllung der gestellten Aufgaben, das Ausmaß seiner Paranoia und die Benutzerfreundlichkeit.

Der Parameter PIM sollte am besten auf den Standardwert belassen werden, damit bei jedem Start des Betriebssystems nicht die genauen Werte für die Iterationen eingegeben werden müssen. VeraCrypt verwendet eine enorme Anzahl an Iterationen, um einen wirklich "langsamen Hash" zu erstellen. Ein Angriff auf diese "Krypto-Schildkröte" mittels Brute-Force-Methoden oder Regenbogen-Tabellen lohnt sich nur bei einer kurzen "einfachen" Passwortphrase und der persönlichen Charset-Liste des Opfers. Die Konsequenz für die Passwortstandhaftigkeit ist eine Verzögerung bei der korrekten Eingabe des Passworts beim Start des Betriebssystems. (Das Mounten von VeraCrypt-Volumes in GNU/Linux ist erheblich schneller).
Freie Software für die Durchführung von Brute-Force-Angriffen. (Extraktion der Passwortphrase aus dem Header des VeraCrypt-/LUKS-Laufwerks) Hashcat. John the Ripper kann "Veracrypt nicht knacken", und bei der Arbeit mit LUKS versteht er die Twofish-Kryptografie nicht.

Aufgrund der kryptografischen Standhaftigkeit der Verschlüsselungsalgorithmen entwickeln unaufhörliche Krypto-Anarchisten Software mit einem anderen Angriffsvektor. Zum Beispiel die Extraktion von Metadaten/Schlüsseln aus dem RAM. (Kaltbootangriff/ direkter Zugriff auf den Speicher), es gibt spezielle freie und nicht-freie Software für diese Zwecke.

Nach Abschluss der Einrichtung/Gerierung von "einmaligen Metadaten" des verschlüsselten aktiven Abschnitts wird VeraCrypt vorschlagen, den PC neu zu starten und die Funktionsfähigkeit seines Bootloaders zu testen. Nach dem Neustart/Start von Windows wird VeraCrypt im Wartemodus geladen, es bleibt nur, den Verschlüsselungsprozess zu bestätigen – Y.

In der finalen Phase der Systemverschlüsselung wird VeraCrypt anbieten, eine Sicherungskopie des Headers des aktiven verschlüsselten Laufwerks als „veracrypt rescue disk.iso“ zu erstellen – dies ist unbedingt erforderlich – in dieser Software ist diese Operation eine Voraussetzung (bei LUKS ist dies leider weggelassen, aber in der Dokumentation hervorgehoben). Die Rettungsdiskette wird allen nützlich sein, und manche benötigen sie mehr als einmal. Der Verlust (Überschreibung des Headers/MBR) einer Sicherungskopie des Headers wird den Zugriff auf den entschlüsselten Abschnitt mit OS Windows für immer entziehen.

A4. Erstellung eines Rettungs-USB/Laufwerks von VeraCryptStandardmäßig bietet VeraCrypt an, „Metadaten ~2-3MB“ auf eine CD zu brennen, aber nicht jeder hat Discs oder DWD-ROM-Laufwerke, und die Erstellung eines bootfähigen USB-Sticks „VeraCrypt Rescue disk“ kann für einige eine technische Überraschung sein: Rufus/GUIdd-ROSA ImageWriter und andere ähnliche Software werden mit der Aufgabe nicht umgehen können, weil neben der Kopierung der verschobenen Metadaten auf den bootfähigen USB-Stick auch eine Kopie/Paste außerhalb des Dateisystems des USB-Speichers aus dem Image erstellt werden muss. Kurz gesagt, der MBR/Track muss korrekt auf den Stick kopiert werden. Unter dem OS GNU/Linux kann ein bootfähiger USB-Stick mit dem Dienstprogramm „dd“ erstellt werden, indem man sich an dieser Tabelle orientiert.

Die Erstellung einer Rettungsdiskette unter Windows ist anders. Der Entwickler von VeraCrypt hat diese Aufgabe nicht in die offizielle Dokumentation Dokumentation über „Rettungsdisketten“ aufgenommen, jedoch auf einem anderen Weg eine Lösung angeboten: er hat zusätzliche Software zur Erstellung einer „USB-Rettungsdiskette“ öffentlich zugänglich gemacht, auf seinem Forum für VeraCrypt. Das Archiv dieser Software für Windows – „Erstellung von USB VeraCrypt-Rettungsdisketten“. Nach dem Speichern von rescue disk.iso beginnt der Prozess der blockweisen systematischen Verschlüsselung der aktiven Partition. Während der Verschlüsselung stoppt das OS nicht, ein Neustart des PCs ist nicht erforderlich. Nach Abschluss des Verschlüsselungsprozesses ist die aktive Partition vollständig verschlüsselt und kann verwendet werden. Wenn beim Start des PCs der Bootloader von VeraCrypt nicht erscheint und die Wiederherstellung des Headers nicht hilft, überprüfen Sie das Flag „boot“, es sollte auf die Partition gesetzt werden, auf der Windows vorhanden ist. (unabhängig von der Verschlüsselung und anderen OS, siehe Tabelle Nr. 1).
Damit ist die Beschreibung der blockweisen systematischen Verschlüsselung mit OS Windows abgeschlossen.

[B] LUKS. Verschlüsselung von GNU/Linux (~Debian) installiertem OS. Algorithmus und Schritte

Um eine installierte Debian-/abgeleitete Distribution zu verschlüsseln, müssen Sie die vorbereitete Partition mit einem virtuellen Blockgerät verknüpfen, es auf die zugeordnete GNU/Linux-Festplatte übertragen und GRUB2 installieren/einrichten. Wenn Sie keinen nackten Server haben und Ihre Zeit schätzen, sollten Sie die GUI nutzen; die meisten der im Folgenden beschriebenen Terminalbefehle sind im «Chuck-Norris-Modus» auszuführen.

B1. PC von einem Live-USB-GNU/Linux booten

«Kryptotest zur Leistungsbewertung der Hardware durchführen»

lscpu && cryptsetup benchmark

Wenn Sie glücklicher Besitzer einer leistungsstarken Maschine mit hardwareseitiger AES-Unterstützung sind, werden die Zahlen auf der rechten Seite des Terminals ähnlich sein; wenn Sie glücklich sind, aber mit antiker Hardware — auf der linken Seite.

B2. Partitionierung der Festplatte. Mounten/Formatieren des Dateisystems der logischen HDD-Partition in Ext4 (Gparted)

B2.1. Erstellung des verschlüsselten Headers für die Partition sda7Die Bezeichnungen der Partitionen werde ich hier und im Folgenden gemäß meiner oben veröffentlichten Partitionsliste beschreiben. Je nach Ihrer Festplattenpartitionierung müssen Sie Ihre eigenen Partitionsnamen verwenden.

Zuweisung der Verschlüsselung der logischen Festplatte ( /dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Optionen:

* luksFormat -Initialisierung des LUKS-Headers;
* -y -Passphrase (kein Schlüssel/Datei);
* -v -Verbalisierung (Ausgabe von Informationen im Terminal);
* /dev/sda7 -Ihre logische Festplatte aus der erweiterten Partition (dort, wo die Übertragung/Verschlüsselung von GNU/Linux geplant ist).

Standardmäßig ist der Verschlüsselungsalgorithmus <LUKS1: aes-xts-plain64, Schlüssel: 256 Bit, LUKS-Header-Hashing: sha256, RNG: /dev/urandom> (abhängig von der Version von cryptsetup).

#Проверка default-алгоритма шифрования
cryptsetup  --help #самая последняя строка в выводе терминала.

Wenn keine hardwareseitige AES-Unterstützung auf der CPU vorhanden ist, wird empfohlen, eine erweiterte ‘LUKS-Twofish-XTS-Partition’ zu erstellen.

B2.2. Erweiterte Erstellung einer ‘LUKS-Twofish-XTS-Partition’

cryptsetup luksFormat /dev/sda7 -v -y -c twofish-xts-plain64 -s 512 -h sha512 -i 1500 --use-urandom

Optionen:
* luksFormat -Initialisierung des LUKS-Headers;
* /dev/sda7 Ihre zukünftige verschlüsselte logische Festplatte;
* -v Verbalisierung;
* -y Passphrase;
* -c Auswahl des Verschlüsselungsalgorithmus;
* -s Schlüsselgröße;
* -h Hashalgorithmus/Kryptofunktion, wird vom RNG verwendet (—use-urandom) zur Generierung eines einzigartigen Verschlüsselungs-/Entschlüsselungsschlüssels für den Header der logischen Festplatte, des sekundären Schlüssels des Headers (XTS); des einzigartigen Master-Schlüssels, der im verschlüsselten Festplattenspeicher abgelegt ist, sekundärer XTS-Schlüssel, all diese Metadaten und das Verschlüsselungs-Subprogramm, das mit Hilfe des Master-Schlüssels und des sekundären XTS-Schlüssels beliebige Daten auf der Partition verschlüsselt/entschlüsselt. (außer dem Header der Partition) werden auf ~3 MB auf der gewählten Festplattenpartition gespeichert.
* -i Iterationen in Millisekunden, anstelle von „Anzahl“ (Zeitverzögerung bei der Verarbeitung des Passworts, wirkt sich auf das Laden des Betriebssystems und die Kryptostärke der Schlüssel aus). Um das Gleichgewicht der Kryptostärke bei einem einfachen Passwort wie „russian“ zu erhalten, muss der Wert -(i) erhöht werden, bei einem komplexen Passwort wie „?8dƱob/øfh“ kann der Wert verringert werden.
* —use-urandom Zufallszahlengenerator, generiert Schlüssel und Salz.

Nach der Zuordnung der Partition sda7 > sda7_crypt (der Vorgang ist schnell, da der verschlüsselte Header mit Metadaten ~3 MB erstellt wird und das war's), muss das Dateisystem sda7_crypt formatiert und gemountet werden.

B2.3. Zuordnung

cryptsetup open /dev/sda7 sda7_crypt
#Das Ausführen dieses Befehls fordert die Eingabe des geheimen Passworts an.

Optionen:
* open - die Partition „unter dem Namen“ zuordnen;
* /dev/sda7 - logische Festplatte;
* sda7_crypt - der Name, der für das Mounten der verschlüsselten Partition oder deren Initialisierung beim Booten des Betriebssystems verwendet wird.

B2.4. Formatierung des Dateisystems sda7_crypt in ext4. Mounten der Festplatte im OS(Hinweis: Es ist bereits nicht mehr möglich, mit einem verschlüsselten Partition in Gparted zu arbeiten)

#форматирование блочного шифрованного устройства
mkfs.ext4 -v -L DebSHIFR /dev/mapper/sda7_crypt 

Optionen:
* -v - Verbalisierung;
* -L - das Label der Festplatte (das im Explorer unter anderen Festplatten angezeigt wird).

Dann sollte das virtuelle-verschlüsselte Blockgerät /dev/sda7_crypt im System gemountet werden.

mount /dev/mapper/sda7_crypt /mnt

Die Arbeit mit Dateien im Ordner /mnt führt automatisch zur Verschlüsselung/Entschlüsselung von Daten in sda7.

Es ist einfacher, die Partition im Explorer zuzuordnen und zu mounten (nautilus/caja GUI), die Partition wird bereits in der Liste der auszuwählenden Festplatten sein, es bleibt nur noch das Passwort für das Öffnen/Entschlüsseln der Festplatte einzugeben. Der zuzuordnende Name wird dabei automatisch ausgewählt und nicht „sda7_crypt“, sondern etwas wie /dev/mapper/Luks-xx-xx…

B2.5. Sicherung des Festplattenheaders (Metadaten ~3 MB)Einer der wichtigsten Punkte Operationen, die notwendig sind, ohne Verzögerung durchzuführen — Sicherung des Headers „sda7_crypt“. Wenn der Header überschrieben/ beschädigt wird, (z. B. durch die Installation von GRUB2 auf der Partition sda7 usw.), werden die verschlüsselten Daten endgültig verloren gehen, ohne jegliche Möglichkeit, sie wiederherzustellen, da es unmöglich sein wird, die gleichen Schlüssel erneut zu generieren, da die Schlüssel einzigartig erstellt werden.

#Бэкап заголовка раздела
cryptsetup luksHeaderBackup --header-backup-file ~/Бэкап_DebSHIFR /dev/sda7 

#Восстановление заголовка раздела
cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Optionen:
* luksHeaderBackup —header-backup-file -Befehlszeile für das Backup;
* luksHeaderRestore —header-backup-file -Befehlszeile für die Wiederherstellung;
* ~/Backup_DebSHIFR — Backup-Datei;
* /dev/sda7 -Partition, deren Sicherung des verschlüsselten Festplattenheaders aufbewahrt werden muss.
In diesem Schritt sind wir abgeschlossen.

B3. Migration des GNU/Linux-Systems (sda4) auf die verschlüsselte Partition (sda7)

Wir erstellen den Ordner /mnt2 (Hinweis — wir arbeiten immer noch mit Live-USB, die Partition sda7_crypt ist an /mnt montiert), und mounten unser GNU/Linux in /mnt2, das verschlüsselt werden muss.

mkdir /mnt2
mount /dev/sda4 /mnt2

Führen Sie die korrekte Migration des Systems mit Rsync-Software durch

rsync -avlxhHX --progress /mnt2/ /mnt

Die Optionen von Rsync sind in Abschnitt E1 beschrieben.

Als nächstes, den Erwerb einer Lizenz. Weitere Informationen zur Lizenzierung und zum Erwerb von Software sind auf Anfrage unter sales@basealt.ru erhältlich. Bei Anfragen zur Beschaffung der „Alt“-Distributionen für inländische Computer „Elbrus“ wenden Sie sich bitte an die AO MCS-T: sales@mcst.ru. führen Sie die Defragmentierung der logischen Diskpartition durch

e4defrag -c /mnt/ #Nach der Überprüfung wird e4defrag anzeigen, dass der Grad der Fragmentierung der Partition ~"0" ist, das ist ein Missverständnis, das Ihnen erhebliche Leistungseinbußen kosten kann!
e4defrag /mnt/ #führen Sie die Defragmentierung des verschlüsselten GNU/Linux durch

Machen Sie es sich zur Gewohnheit, e4defrag in verschlüsseltem GNU/Linux von Zeit zu Zeit durchzuführen, wenn Sie eine HDD haben.
Die Migration und Synchronisation von [GNU/Linux > GNU/Linux-verschlüsselt] ist an diesem Punkt abgeschlossen.

V4. Konfiguration von GNU/Linux auf der verschlüsselten Partition sda7

Nach der erfolgreichen Migration des Systems /dev/sda4 > /dev/sda7 müssen Sie in das GNU/Linux auf der verschlüsselten Partition einsteigen und die weitere Konfiguration durchführen (ohne den PC neu zu starten) bezüglich des verschlüsselten Systems. Das heißt, wir befinden uns im Live-USB, aber die Befehle werden „relativ zum Root des verschlüsselten Systems“ ausgeführt. Eine solche Situation wird durch „chroot“ simuliert. Um schnell Informationen darüber zu erhalten, mit welchem System Sie derzeit arbeiten (ob verschlüsselt oder nicht, da die Daten in sda4 und sda7 synchronisiert sind), desynchronisieren Sie die Betriebssysteme. Erstellen Sie in den Wurzelverzeichnissen (sda4/sda7_crypt) leere Markerdateien, zum Beispiel /mnt/verschlüsseltesBetriebssystem und /mnt2/entschlüsseltesBetriebssystem. Eine schnelle Überprüfung, in welchem Betriebssystem Sie sich befinden (auch für die Zukunft):

ls /

B4.1. „Simulation des Zugriffs auf ein verschlüsseltes Betriebssystem“

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

B4.2. Überprüfung, dass die Arbeit relativ zum verschlüsselten System erfolgt

ls /mnt 
#und wir sehen die Datei "/verschlüsseltesOS"

history
#im Terminalausgabe sollte die Historie der Befehle su des Arbeitsbetriebssystems erscheinen.

B4.3. Erstellung/Einstellung des verschlüsselten Swap, Bearbeitung von crypttab/fstabDa die Swap-Datei bei jedem Start des Betriebssystems formatiert wird, hat es keinen Sinn, jetzt Swap mit dem logischen Laufwerk zu erstellen und die Befehle wie in p.B2.2 einzugeben. Für Swap werden bei jedem Start automatisch eigene temporäre Verschlüsselungsschlüssel generiert. Lebenszyklus der Swap-Schlüssel: Abmontierung/Ausbau der Swap-Partition (+Reinigung des RAM); oder Neustart des Betriebssystems. Konfiguration des Swaps, öffnen Sie die Datei, die für die Konfiguration der blockverschlüsselten Geräte verantwortlich ist (analog zur fstab-Datei, aber verantwortlich für die Krypto).

nano /etc/crypttab 

wir bearbeiten

#«target name» «source device» «key file» «options»
swap /dev/sda8 /dev/urandom swap,cipher=twofish-xts-plain64,size=512,hash=sha512

Optionen
* swap - der zugeordnete Name bei der Verschlüsselung /dev/mapper/swap.
* /dev/sda8 - verwenden Sie Ihre logische Partition für Swap.
* /dev/urandom - Generator für zufällige Verschlüsselungsschlüssel für Swap (bei jedem neuen Boot des Betriebssystems — neu erzeugte Schlüssel). Der Generator /dev/urandom ist weniger zufällig als /dev/random, schließlich wird /dev/random unter gefährlichen paranoiden Umständen verwendet. Beim Booten des Betriebssystems verlangsamt /dev/random das Booten um einige ± Minuten (siehe systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: - das Partition weiß, dass es swap ist und wird "entsprechend" formatiert; Verschlüsselungsalgorithmus.

#Открываем и правим fstab
nano /etc/fstab

wir bearbeiten

# swap was on /dev/sda8 during installation
/dev/mapper/swap none swap sw 0 0

/dev/mapper/swap -имя , которое задали в crypttab.

Alternativer verschlüsselter Swap
Wenn Sie aus irgendeinem Grund nicht die gesamte Partition für die Swap-Datei verwenden möchten, können Sie einen alternativen und besseren Weg gehen: Erstellung einer Swap-Datei innerhalb einer Datei auf der verschlüsselten Partition mit dem Betriebssystem.

fallocate -l 3G /swap #Erstellung einer Datei mit 3GB (fast unmittelbare Operation)
chmod 600 /swap #Einstellung der Berechtigungen
mkswap /swap #aus der Datei eine Swap-Datei erstellen
swapon /swap #unseren Swap aktivieren
free -m #überprüfen, dass die Swap-Datei aktiviert ist und funktioniert
printf "/swap none swap sw 0 0" >> /etc/fstab #falls erforderlich, nach einem Neustart wird der Swap permanent sein

Die Konfiguration der Swap-Partition ist abgeschlossen.

B4.4. Konfiguration von verschlüsseltem GNU/Linux (Bearbeitung der Dateien crypttab/fstab)Die Datei /etc/crypttab, wie oben beschrieben, beschreibt die verschlüsselten blockorientierten Geräte, die während des Systemstarts konfiguriert werden.

#правим /etc/crypttab 
nano /etc/crypttab 

wenn Sie die Partition sda7>sda7_crypt wie in Abschnitt B2.1 zugeordnet haben

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 none luks

wenn Sie die Partition sda7>sda7_crypt wie in Abschnitt B2.2 zugeordnet haben

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 none cipher=twofish-xts-plain64,size=512,hash=sha512

wenn Sie die Partition sda7>sda7_crypt wie in B2.1 oder B2.2 zugeordnet haben, aber das Passwort zum Entsperren und Booten des Systems nicht erneut eingeben möchten, können Sie anstelle des Passworts einen geheimen Schlüssel/zufällige Datei verwenden

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 /etc/skey luks

Beschreibung
* none -weist darauf hin, dass beim Booten des Systems zur Entsperrung des Wurzelverzeichnisses die Eingabe einer geheimen Passphrase erforderlich ist.
* UUID -Partition-Identifier. Um Ihren Identifikator zu erfahren, geben Sie im Terminal ein (eine Erinnerung, dass Sie die ganze Zeit und darüber hinaus im Terminal in einer chroot-Umgebung arbeiten und nicht in einem anderen Live-USB-Terminal).

fdisk -l #Überprüfung aller Partitionen
blkid # sollte etwa so aussehen 

/dev/sda7: UUID=«81048598-5bb9-4a53-af92-f3f9e709e2f2» TYPE=«crypto_LUKS» PARTUUID=«0332d73c-07»
/dev/mapper/sda7_crypt: LABEL=«DebSHIFR» UUID=«382111a2-f993-403c-aa2e-292b5eac4780» TYPE=«ext4»

diese Zeile wird angezeigt, wenn Sie blkid aus dem Live-USB-Terminal bei montiertem sda7_crypt abfragen).
Den UUID nehmen Sie genau von Ihrem sdaX (nicht sdaX_crypt!, der UUID von sdaX_crypt wird automatisch bei der Generierung der Konfiguration grub.cfg entfernt).
* cipher=twofish-xts-plain64,size=512,hash=sha512 -luks-Verschlüsselung im erweiterten Modus.
* /etc/skey -geheimer Schlüsseldatei, der automatisch zur Entsperrung des Bootvorgangs verwendet wird (anstatt das dritte Passwort einzugeben). Die Datei kann beliebig bis zu 8 MB groß sein, aber die Daten werden in kleinerer Größe (<1 MB) gelesen.

#Создание "генерация" случайного файла <секретного ключа> размером 691б.
head -c 691 /dev/urandom > /etc/skey

#Добавление секретного ключа (691б) в 7-й слот заголовка luks
cryptsetup luksAddKey --key-slot 7 /dev/sda7 /etc/skey

#Проверка слотов "пароли/ключи luks-раздела"
cryptsetup luksDump /dev/sda7 

Es wird ungefähr so aussehen:

(machen Sie es selbst und sehen Sie selbst).

cryptsetup luksKillSlot /dev/sda7 7 #Löschen des Schlüssels/Passworts aus Slot 7

/etc/fstab содержит описательную информацию о различных файловых системах.

#Правим /etc/fstab
nano /etc/fstab

# «file system» «mount poin» «type» «options» «dump» «pass»
# / was on /dev/sda7 during installation
/dev/mapper/sda7_crypt / ext4 errors=remount-ro 0 1

Option
* /dev/mapper/sda7_crypt -Bezeichnung der Zuordnung sda7>sda7_crypt, die in der Datei /etc/crypttab angegeben ist.
Die Konfiguration von crypttab/fstab ist abgeschlossen.

B4.5. Bearbeitung von Konfigurationsdateien. SchlüsselpunktB4.5.1. Bearbeitung der Konfiguration /etc/initramfs-tools/conf.d/resume

#Если у вас ранее был активирован swap раздел, отключите его. 
nano /etc/initramfs-tools/conf.d/resume

und kommentieren Sie (falls vorhanden) die Zeile «# resume». Die Datei sollte vollkommen leer sein.

B4.5.2. Bearbeitung der Konfiguration /etc/initramfs-tools/conf.d/cryptsetup

nano /etc/initramfs-tools/conf.d/cryptsetup

sollte übereinstimmen

# /etc/initramfs-tools/conf.d/cryptsetup
CRYPTSETUP=yes
export CRYPTSETUP

B4.5.3. Bearbeitung der Konfiguration /etc/default/grub (genau diese Konfiguration ist dafür verantwortlich, grub.cfg bei der Arbeit mit verschlüsseltem /boot zu generieren)

nano /etc/default/grub

fügen Sie die Zeile „GRUB_ENABLE_CRYPTODISK=y“ hinzu
der Wert 'y', grub-mkconfig und grub-install werden nach verschlüsselten Laufwerken suchen und zusätzliche erforderliche Befehle für den Zugriff während des Bootvorgangs generieren (insmod- Befehle ).
es sollte etwas Ähnliches sein

GRUB_DEFAULT=0
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=„acpi_backlight=vendor“
GRUB_CMDLINE_LINUX="quiet splash noautomount"
GRUB_ENABLE_CRYPTODISK=y

B4.5.4. Bearbeiten der Konfiguration /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

Stellen Sie sicher, dass die Zeile auskommentiert ist .
In Zukunft (und selbst jetzt wird dieser Parameter keine Bedeutung haben, aber manchmal hindert er daran, das Image initrd.img zu aktualisieren).

B4.5.5. Bearbeiten der Konfiguration /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

fügen Sie ihn in den Einstellungen von Github hinzu.

KEYFILE_PATTERN="/etc/skey"
UMASK=0077

Dies wird den geheimen Schlüssel "skey" in das initrd.img packen, der Schlüssel ist notwendig, um das Root-Verzeichnis beim Booten des Betriebssystems zu entsperren. (wenn Sie nicht erneut das Passwort eingeben möchten, wird der Schlüssel "skey" automatisch verwendet).

B4.6. Aktualisieren von /boot/initrd.img [version]Um den geheimen Schlüssel in initrd.img zu packen und die Änderungen von cryptsetup anzuwenden, aktualisieren wir das Image.

update-initramfs -u -k all

beim Aktualisieren von initrd.img (wie gesagt "Möglich, aber nicht sicher") es werden Warnungen im Zusammenhang mit cryptsetup erscheinen oder beispielsweise eine Benachrichtigung über fehlende Nvidia-Module — das ist normal. Überprüfen Sie nach dem Aktualisieren der Datei, ob sie tatsächlich aktualisiert wurde, sehen Sie nach der Zeit. (bezüglich der chroot-Umgebung. /boot/initrd.img). Achtung! Vor [update-initramfs -u -k all] unbedingt überprüfen, dass cryptsetup open /dev/sda7 sda7_crypt — genau dieser Name muss in /etc/crypttab stehen, andernfalls gibt es nach dem Reboot einen Fehler busybox)
An dieser Stelle ist die Konfiguration der Konfigurationsdateien abgeschlossen.

[C] Installation und Konfiguration von GRUB2/Schutz

C1. Formatieren Sie bei Bedarf die zugewiesene Partition für den Bootloader (die Partition sollte mindestens 20 MB groß sein)

mkfs.ext4 -v -L GRUB2 /dev/sda6

C2. Mounten von /dev/sda6 auf /mntDa wir in chroot arbeiten, wird es im Root-Verzeichnis kein Verzeichnis /mnt2 geben, und der Ordner /mnt wird leer sein.
wir mounten die GRUB2-Partition

mount /dev/sda6 /mnt

Wenn Sie eine ältere Version von GRUB2 installiert haben, fehlen in /mnt/boot/grub/i-386-pc (es könnte eine andere Plattform sein, zum Beispiel nicht „i386-pc“) die Krypto-Module (kurz gesagt, im Ordner sollten Module vorhanden sein, einschließlich dieser .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), in diesem Fall muss GRUB2 neu installiert werden.

apt-get update
apt-get install grub2 

Wichtig! Beim Aktualisieren des GRUB2-Pakets aus dem Repository, müssen Sie bei der Frage „zu welchem Ort“ der Bootloader installiert werden soll, die Installation ablehnen. (Grund — Versuch, GRUB2 in den „MBR“ oder auf ein Live-USB zu installieren)Andernfalls beschädigen Sie den Bootloader von VeraCrypt. Nach der Aktualisierung der GRUB2-Pakete und der Abbruch der Installation muss der Bootloader manuell auf die logische Festplatte installiert werden, nicht in den „MBR“. Wenn Ihre Repository-Version von GRUB2 veraltet ist, versuchen Sie es zu aktualisieren von der offiziellen Website – ich habe es nicht getestet (ich habe mit aktuellen Bootloadern GRUB 2.02 ~BetaX gearbeitet).

C3. Installation von GRUB2 im erweiterten Bereich [sda6]Sie sollten die Partition [п.C.2] eingehängt haben

grub-install --force --root-directory=/mnt /dev/sda6

Optionen
* —force - installiert den Bootloader und umgeht alle Warnungen, die praktisch immer vorhanden sind und die Installation blockieren (erforderliches Flag).
* —root-directory - setzt das Verzeichnis als Wurzel von sda6.
* /dev/sda6 - Ihre sdaX Partition (überspringen Sie nicht zwischen /mnt /dev/sda6).

C4. Erstellen der Konfigurationsdatei [grub.cfg]Vergessen Sie den Befehl „update-grub2“ und verwenden Sie den vollständigen Befehl zur Generierung der Konfigurationsdatei

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Nach Abschluss der Generierung/Aktualisierung der grub.cfg-Datei sollten im Terminal Ausgaben mit gefundenen Betriebssystemen auf der Festplatte erscheinen („grub-mkconfig“ kann Betriebssysteme von einem Live-USB finden und übernehmen, wenn Sie einen Multiboot-USB mit Windows 10 und vielen Live-Distributionen haben – das ist normal). Wenn das Terminal „leer“ ist und die Datei „grub.cfg“ nicht generiert wurde, ist dies der Fall, wenn in der GRUB Umgebung Fehler auftreten (und wahrscheinlich stammt der Bootloader aus dem Testbranch des Repositories), installieren Sie GRUB2 aus vertrauenswürdigen Quellen neu.
Die Installation von „einfacher Konfiguration“ und die Einrichtung von GRUB2 sind abgeschlossen.

C5. Funktionsprüfung des verschlüsselten Betriebssystems GNU/LinuxKorrekte Beendigung der Kryptomission. Verlassen Sie vorsichtig das verschlüsselte GNU/Linux (Verlassen der chroot-Umgebung).

umount -a #alle eingehängten Partitionen des verschlüsselten GNU/Linux aushängen
Ctrl+d #Verlassen der chroot-Umgebung
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount -a #alle eingehängten Partitionen auf Live-USB aushängen
neustarten

Nach dem Neustart sollte der Bootloader von VeraCrypt angezeigt werden.


*Eingabe des Passworts für die aktive Partition — der Start von Windows beginnt.
*Drücken der „Esc“-Taste überträgt die Kontrolle an GRUB2. Bei der Auswahl von verschlüsseltem GNU/Linux wird ein Passwort (sda7_crypt) benötigt, um /boot/initrd.img zu entsperren (wenn grub2 „uuid nicht gefunden“ meldet – das ist ein Problem des Bootloaders grub2, er sollte neu installiert werden, z.B. aus dem Testbranch/stabil und p.d.).


*Je nachdem, wie Sie das System konfiguriert haben (siehe Abschnitt B4.4/4.5), wird nach der korrekten Eingabe des Passworts zum Entsperren des Abbilds /boot/initrd.img ein Passwort zum Laden des Kernels/Wurzel-OS benötigt, oder der geheime Schlüssel „skey“ wird automatisch eingetragen, wodurch eine erneute Eingabe des Passworts entfällt.

(Screenshot „automatische Einfügung des geheimen Schlüssels“).

*Anschließend folgt der bekannte Bootprozess von GNU/Linux mit der Authentifizierung des Benutzerkontos.


*Nach der Autorisierung des Benutzers und dem Zugang zum OS muss /boot/initrd.img erneut aktualisiert werden. (siehe B4.6).

update-initramfs -u -k all

Im Falle zusätzlicher Zeilen im GRUB2-Menü (vom OS über Live-USB erfasst) sollten diese entfernt werden

mount /dev/sda6 /mnt
grub-mkconfig -o /mnt/boot/grub/grub.cfg

Kurze Zusammenfassung zur Systemsicherheit von GNU/Linux:

• GNU/Linux ist vollständig verschlüsselt, einschließlich /boot/kernel und initrd;
• der geheime Schlüssel ist in initrd.img verpackt;
• das aktuelle Autorisierungsschema (Eingabe des Entsperrpassworts für initrd; Passwort/Schlüssel zum Laden des OS; Passwort zur Autorisierung des Linux-Kontos).

Die „einfache Konfiguration von GRUB2“ zur Systemsicherheit des Blockgerätes ist abgeschlossen.

C6. Erweiterte GRUB2-Konfiguration. Schutz des Bootloaders durch digitale Signatur + Schutz durch Authentifizierung.GNU/Linux ist vollständig verschlüsselt, aber der Bootloader kann nicht verschlüsselt werden – diese Bedingung wird vom BIOS diktiert. Daher ist eine verkettete verschlüsselte GRUB2-Bootloaderung nicht möglich, eine einfache verkettete Bootloaderung ist jedoch möglich/verfügbar, aus Sicht des Schutzes – es ist nicht erforderlich [siehe Abschnitt F].
Für den „anfälligen“ GRUB2 haben die Entwickler einen Algorithmus zum Schutz des Bootloaders durch „Signatur/Authentifizierung“ implementiert.

• Beim Schutz des Bootloaders mit „eigenen digitalen Signaturen“ führt eine externe Modifikation von Dateien oder der Versuch, in diesem Bootloader zusätzliche Module zu laden, zu einer Blockierung des Bootvorgangs.
• Beim Schutz des Bootloaders durch Authentifizierung ist zur Auswahl des zu ladenden Distris oder zur Eingabe zusätzlicher Befehle in der CLI die Eingabe des Superuser-Logins und -Passworts für GRUB2 erforderlich.

C6.1. Schutz des Bootloaders durch Authentifizierung.Stellen Sie sicher, dass Sie im Terminal im verschlüsselten OS arbeiten.

ls / #Entdecken Sie die Markerdatei.

Erstellen Sie ein Superuser-Passwort zur Authentifizierung in GRUB2.

grub-mkpasswd-pbkdf2 #Geben Sie das Superuser-Passwort ein/wiederholen Sie es. 

Erhalten Sie den Passwort-Hash. Etwas, das so aussieht.

grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

GRUB-Partition einhängen

mount /dev/sda6 /mnt 

Konfiguration bearbeiten

nano -$ /mnt/boot/grub/grub.cfg 

Überprüfen Sie die Datei auf, ob in der „grub.cfg“ an einer Stelle Flags („—unrestricted“, „—user“) fehlen.
Fügen Sie am Ende hinzu (vor der Zeile ### END /etc/grub.d/41_custom ###)
„set superusers=„root“
password_pbkdf2 root hash“.

Es sollte ungefähr so aussehen

# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the ‘exec tail’ line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z „${config_directory}“ -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
set superusers=„root“
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Wenn Sie häufig den Befehl „grub-mkconfig -o /mnt/boot/grub/grub.cfg“ verwenden und nicht jedes Mal Änderungen in grub.cfg vornehmen möchten, fügen Sie die oben genannten Zeilen (Benutzername/Passwort) in ein benutzerdefiniertes GRUB-Skript am Ende ein.

nano /etc/grub.d/41_custom 

cat << EOF
set superusers=„root“
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
EOF

Bei der Generierung der Konfiguration „grub-mkconfig -o /mnt/boot/grub/grub.cfg“ werden die Zeilen, die für die Authentifizierung verantwortlich sind, automatisch in grub.cfg hinzugefügt.
An dieser Stelle ist die Einrichtung der GRUB2-Authentifizierung abgeschlossen.

C6.2. Schutz des Bootloaders mit digitaler SignaturEs wird davon ausgegangen, dass Sie bereits Ihren persönlichen PGP-Verschlüsselungsschlüssel haben (oder erstellen Sie einen solchen Schlüssel). Auf dem System sollte Software für Kryptographie installiert sein: gnuPG; kleopatra/GPA; Seahorse. Kryptosoftware erleichtert Ihnen das Leben in all diesen Angelegenheiten erheblich. Seahorse — stabile Version des Pakets 3.14.0 (höhere Versionen, z. B. V3.20 – unvollständig und hat erhebliche Bugs).

PGP-Schlüssel sollten nur in einer su-Umgebung generiert/ausgeführt/hinzugefügt werden!

Generieren Sie einen persönlichen Verschlüsselungsschlüssel

gpg --gen-key

Exportieren Sie Ihren Schlüssel

gpg --export -o ~/perskey

Hängen Sie das logische Laufwerk in das Betriebssystem, falls es noch nicht eingehängt ist

mount /dev/sda6 /mnt #sda6 – GRUB2-Partition

Löschen Sie die GRUB2-Partition

rm -rf /mnt/

Installieren Sie GRUB2 in sda6 und legen Sie Ihren persönlichen Schlüssel in das Hauptabbild von GRUB „core.img“

grub-install --force --modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" -k ~/perskey --root-directory=/mnt /dev/sda6

Optionen
* —force: Installation des Bootloaders, wobei alle vorhandenen Warnungen ignoriert werden. (erforderliches Flag).
* —modules=„gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa“: Weis GRUB2 an, die erforderlichen Module beim Start des PCs vorzuladen.
* -k ~/perskey: Pfad zum „PGP-Schlüssel“ (nach dem Verpacken des Schlüssels in das Image kann er gelöscht werden).
* —root-directory -Installation des Boot-Verzeichnisses im Wurzelverzeichnis von sda6
/dev/sda6 -ваш sdaХ раздел.

Wir generieren/aktualisieren grub.cfg

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Fügen Sie am Ende der Datei «grub.cfg» die Zeile «trust /boot/grub/perskey» hinzu (PGP-Schlüssel zwangsweise verwenden.) Da wir GRUB2 mit einem Set von Modulen, einschließlich des Moduls zur Signatur «signature_test.mod», installiert haben, entfällt die Notwendigkeit, dem Konfigurationsfile Befehle wie «set check_signatures=enforce» hinzuzufügen.

Es sollte ungefähr so aussehen (Endzeilen in der Datei grub.cfg)

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z „${config_directory}“ -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
trust /boot/grub/perskey
set superusers=„root“
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Der Pfad zu «/boot/grub/perskey» muss nicht auf eine bestimmte Partition der Festplatte wie hd0,6 angegeben werden, für den Bootloader ist die «Wurzel» der Standardpfad der Partition, auf der GRUB2 installiert ist. (siehe set rot=..).

Wir signieren GRUB2 (alle Dateien in allen Verzeichnissen /GRUB) mit unserem Schlüssel «perskey».
Eine einfache Lösung, um zu signieren (für den Dateimanager nautilus/caja): Wir installieren aus dem Repository die Erweiterung «seahorse» für den Dateimanager. Der Schlüssel muss in der su-Umgebung hinzugefügt worden sein.
Öffnen Sie den Dateimanager als sudo «/mnt/boot» – Rechtsklick – signieren. Das sieht auf dem Screenshot so aus

Der Schlüssel «/mnt/boot/grub/perskey» (in das grub-Verzeichnis kopieren) muss ebenfalls mit seiner eigenen Signatur signiert werden. Überprüfen Sie, ob im Verzeichnis/Unterverzeichnissen die Signaturen der Dateien [*.sig] vorhanden sind.
Mit der oben beschriebenen Methode signieren wir «/boot» (unsere Kernel, initrd). Wenn Ihre Zeit etwas wert ist, befreit diese Methode Sie davon, ein Bash-Skript zur Signierung «mehrerer Dateien» zu schreiben.

Um alle Signaturen des Bootloaders zu entfernen (wenn etwas schiefgegangen ist)

rm -f $(find /mnt/boot/grub -type f -name '*.sig')

Um zu vermeiden, dass der Bootloader nach einem Systemupdate signiert wird, frieren Sie alle Paketupdates ein, die mit GRUB2 in Zusammenhang stehen.

apt-mark hold grub-common grub-pc grub-pc-bin grub2 grub2-common

In diesem Schritt ist die erweiterte Konfiguration von GRUB2 abgeschlossen.

C6.3. Proof-Test des GRUB2-Bootloaders, geschützt durch digitale Signatur und AuthentifizierungGRUB2. Bei der Auswahl eines beliebigen GNU/Linux-Distros oder beim Zugriff auf die CLI (Kommandozeile) wird eine Superuser-Authentifizierung erforderlich. Nach Eingabe des korrekten Benutzernamens/Passworts wird ein Passwort für initrd angefordert.

Screenshot, erfolgreiche Authentifizierung des GRUB2-Superusers.

Wenn eine der GRUB2-Dateien gefälscht oder Änderungen an grub.cfg vorgenommen werden, oder eine Datei/Signatur gelöscht oder ein bösartiges Modul .mod geladen wird, erscheint die entsprechende Warnung. Der Bootvorgang von GRUB2 wird gestoppt.

Screenshot, Versuch, in GRUB2 "von außen" einzugreifen.

Bei einem "normalen" Booten "ohne Eingriff" liegt der Systemstatuscode "0" vor. Daher ist unklar, ob der Schutz funktioniert oder nicht. (das heißt "mit Bootloader-Schutz durch Signatur oder ohne" ist der Status beim normalen Booten derselbe "0" — das ist schlecht).

Wie überprüft man den Schutz durch digitale Signatur?

Unbequeme Überprüfungsmethode: den verwendeten GRUB2-Modul fälschen/löschen, zum Beispiel die Signatur luks.mod.sig entfernen und einen Fehler erhalten.

Richtige Methode: in die CLI des Bootloaders gehen und den Befehl eingeben

trust_list

Als Antwort sollte der Fingerabdruck "perskey" angezeigt werden; wenn der Status "0" ist, funktioniert der Schutz durch Signatur nicht, überprüfen Sie p.C6.2 erneut.
An diesem Punkt ist die erweiterte Konfiguration "GRUB2-Schutz durch digitale Signatur und Authentifizierung" abgeschlossen.

C7 Alternativmethode zum Schutz des GRUB2-Bootloaders durch HashingDie oben beschriebene Methode "Schutz des Bootloaders durch CP/Authentiifizierung" ist klassisch. Aufgrund der Unzulänglichkeiten von GRUB2 ist dieser unter paranoiden Bedingungen einer echten Attacke ausgesetzt, die ich unten in p.[F] anführe. Außerdem muss der Bootloader nach einem Update des Betriebssystems/Kernels neu signiert werden.

Schutz des GRUB2-Bootloaders durch Hashing

Vorteile gegenüber der Klassik:

• Höhere Zuverlässigkeit (Hashing/Überprüfung erfolgt nur von einem verschlüsselten lokalen Medium. Der gesamte dem GRUB2 zugewiesene Speicherplatz wird auf Änderungen kontrolliert, während der Rest verschlüsselt ist; im klassischen Schema mit Bootloader-Schutz durch CP/Authentiifizierung werden nur Dateien überwacht, nicht jedoch der freie Speicherplatz, in den "etwas Bösartiges" geschrieben werden könnte).
• Verschlüsselte Protokollierung (das Schema enthält ein lesbares persönliches verschlüsseltes Protokoll).
• Geschwindigkeit (der Schutz/die Überprüfung des gesamten für GRUB2 zugewiesenen Speicherbereichs erfolgt nahezu sofort).
• Automatisierung aller kryptografischen Prozesse.

Nachteile gegenüber der Klassik.

• Signaturfälschung (theoretisch ist es möglich, eine bestimmte Kollision der Hash-Funktion zu finden).
• Erhöhter Schwierigkeitsgrad (im Vergleich zur Klassik sind etwas mehr Kenntnisse in GNU/Linux erforderlich).

Wie funktioniert die Idee mit Hashing in GRUB2/Partition?

Der "signierte" GRUB2-Abschnitt führt beim Booten des Betriebssystems eine Überprüfung der Unveränderlichkeit des Bootloader-Abschnitts durch, gefolgt von einer Protokollierung in einer sicheren (verschlüsselten) Umgebung. Im Falle einer Kompromittierung des Bootloaders oder seines Abschnitts wird zusätzlich zum Angriffsprotokoll eine solche

Sache.

Viermal täglich findet eine ähnliche Überprüfung statt, die die Systemressourcen nicht belastet.
Mit dem Befehl „-$ überprüfung_GRUB“ kann jederzeit eine sofortige Überprüfung ohne Protokollierung durchgeführt werden, jedoch mit Ausgabe der Informationen in der CLI.
Mit dem Befehl „-$ sudo signatur_GRUB“ wird eine sofortige Neusignatur des GRUB2-Bootloaders/Abschnitts und dessen aktualisierte Protokollierung durchgeführt (notwendig nach einem Update des OS/Boot), und das Leben geht weiter.

Implementierung der Hashing-Methode für den Bootloader und seinen Abschnitt

0) Wir signieren den Bootloader/Abschnitt GRUB, indem wir ihn zuvor in /media/benutzername einhängen

-$ hashdeep -c md5 -r /media/benutzername/GRUB > /podpis.txt

1) Wir erstellen ein Skript ohne Erweiterung im Root der verschlüsselten OS ~ /podpis, und wenden die erforderlichen Berechtigungen 744 Sicherheit und Schutz gegen "Dummheit" an.

Füllen Sie seinen Inhalt aus

#!/bin/bash

#Проверка всего раздела выделенного под загрузчик GRUB2 на неизменность.
#Ведется лог "о вторжении/успешной проверке каталога", короче говоря ведется полный лог с тройной вербализацией. Внимание! обратить взор на пути: хранить ЦП GRUB2 только на зашифрованном разделе OS GNU/Linux. 
echo -e "******************************************************************n" >> '/var/log/podpis.txt' && date >> '/var/log/podpis.txt' && hashdeep -vvv -a -k '/podpis.txt' -r '/media/username/GRUB' >> '/var/log/podpis.txt'

a=`tail '/var/log/podpis.txt' | grep failed` #не использовать "cat"!! 
b="hashdeep: Audit failed"

#Условие: в случае любых каких-либо изменений в разделе выделенном под GRUB2 к полному логу пишется второй отдельный краткий лог "только о вторжении" и выводится на монитор мигание gif-ки "warning".
if [[ "$a" = "$b" ]] 
then
echo -e "****n" >> '/var/log/vtorjenie.txt' && echo "vtorjenie" >> '/var/log/vtorjenie.txt' && date >> '/var/log/vtorjenie.txt' & sudo -u username DISPLAY=:0 eom '/warning.gif' 
fi

Wir führen das Skript von suaus, es erfolgt eine Überprüfung des Hashes des GRUB-Abschnitts und seines Bootloaders, speichern Sie das Protokoll.

Lassen Sie uns beispielsweise eine „schadhafte Datei“ [virus.mod] in den GRUB2-Abschnitt kopieren oder erstellen und eine sofortige Überprüfung/Test durchführen:

-$ hashdeep -vvv -a -k '/podpis.txt' -r '/media/benutzername/GRUB

In der CLI sollten wir einen Angriff auf unsere -Zitadelle- sehen#Урезанный лог в CLI

Mi Jan  2 11:41 MSK 2020
/media/benutzername/GRUB/boot/grub/virus.mod: Verschoben von /media/benutzername/GRUB/1nononoshifr
/media/benutzername/GRUB/boot/grub/i386-pc/mda_text.mod: Ok
/media/benutzername/GRUB/boot/grub/grub.cfg: Ok
hashdeep: Die Überprüfung ist fehlgeschlagen
   Untersuchte Eingabedateien: 0
  Bekannte Dateien werden erwartet: 0
          Übereinstimmende Dateien: 325
Teilweise übereinstimmende Dateien: 0
            Verschobene Dateien: 1
        Neue Dateien gefunden: 0
  Bekannte Dateien nicht gefunden: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
Wegen der Besonderheiten des getesteten Abschnitts anstelle von „Neue Dateien gefunden“ > „Verschobene Dateien“

2) Legen Sie das GIF hier ab > ~/warning.gif, setzen Sie die Berechtigungen 744.

3) Konfigurieren Sie fstab für das automatische Einhängen des GRUB-Abschnitts beim Booten

-$ sudo nano /etc/fstab

LABEL=GRUB /media/benutzername/GRUB ext4 defaults 0 0

4) Führen Sie die Protokollrotation durch

-$ sudo nano /etc/logrotate.d/podpis 

/var/log/podpis.txt {
täglich
rotate 50
size 5M
dateext
compress
delaycompress
olddir /var/log/old
}

/var/log/vtorjenie.txt {
monatlich
rotate 5
size 5M
dateext
olddir /var/log/old
}

5) Fügen Sie einen Job zu cron hinzu

-$ sudo crontab -e

neu starten '/podpis'
0 */6 * * * '/podpis

6) Erstellen Sie permanente Aliase

-$ sudo su
-$ echo "alias signatur_GRUB='hashdeep -c md5 -r /media/benutzername/GRUB > /podpis.txt'" >> /root/.bashrc && bash
-$ echo "alias überprüfung_GRUB='hashdeep -vvv -a -k '/podpis.txt' -r /media/benutzername/GRUB'" >> .bashrc && bash

Nach dem OS-Update -$ apt-get upgrade signieren wir unseren GRUB-Abschnitt neu
-$ signatur_GRUB
Dieser Schritt zum Schutz der GRUB-Partition durch Hashing ist abgeschlossen.

[D] Reinigung – Vernichtung unverschlüsselter Daten

Löschen Sie Ihre persönlichen Dateien so vollständig, dass "sogar Gott sie nicht lesen kann", so ein Vertreter aus South Carolina, Trey Gowdy.

Wie gewohnt gibt es verschiedene "Mythen und Legenden", über die Wiederherstellung von Daten nach deren Löschung von der Festplatte. Wenn Sie an Cyber-Magie glauben oder ein Anhänger der Dr. Web-Community sind und nie versucht haben, Daten nach deren Löschung/Überschreibung wiederherzustellen, (zum Beispiel Wiederherstellung mit R-studio), könnte die vorgeschlagene Methode daher nicht für Sie geeignet sein; nutzen Sie das, womit Sie sich wohler fühlen.

Nach der erfolgreichen Übertragung von GNU/Linux auf die verschlüsselte Partition muss die alte Kopie ohne Wiederherstellungsmöglichkeit gelöscht werden. Ein universeller Reinigungsansatz: Software für Windows/Linux, kostenlose GUI-Software BleachBit.
Schnell formatieren Sie die Partition, auf der die Daten vernichtet werden sollen (mit Gparted), starten Sie BleachBit, wählen Sie 'Freie Speicherplatz löschen' – wählen Sie die Partition (Ihr sdaX mit der alten Kopie von GNU/Linux), der Prozess der Bereinigung wird gestartet. BleachBit – reinigt die Festplatte in einem Durchgang – das ist es, was "wir brauchen", aber! es funktioniert nur theoretisch, wenn Sie die Festplatte formatiert und in der Software BB v2.0 gereinigt haben.

Achtung! BB reinigt die Festplatte, hinterlässt jedoch Metadaten; die Dateinamen bleiben bei der Löschung der Daten erhalten (Ccleaner – hinterlässt keine Metadaten).

Und der Mythos über die Möglichkeit der Wiederherstellung von Daten ist nicht ganz ein Mythos.Bleachbit V2.0-2 war ein instabiler OS Debian-Paket (und jede andere ähnliche Software: sfill; wipe-Nautilus – wurden ebenfalls in diesem schmutzigen Geschäft bemerkt) hatte tatsächlich einen kritischen Fehler: die Funktion 'Freie Speicherplatz löschen' arbeitet nicht korrekt auf HDD/USB-Sticks (ntfs/ext4). Derartige Software schreibt bei der Bereinigung des freien Speicherplatzes nicht die gesamte Festplatte neu, wie viele Benutzer glauben. Und einige (viele) gelöschte Daten werden vom OS/der Software als nicht gelöscht/nutzerdefiniert betrachtet und bei der Bereinigung von 'Freiem Speicher' werden diese Dateien übersprungen. Das Problem ist, dass nach einer solch langwierigen Reinigung der Festplatte "gelöschte Dateien" wiederhergestellt werden können sogar nach 3+ Durchgängen des Abwischens der Festplatte.
Auf GNU/Linux in Bleachbit 2.0-2 Die Funktionen zur unwiderruflichen Löschung von Dateien und Verzeichnissen arbeiten zuverlässig, aber die Bereinigung des freien Speicherplatzes nicht. Zum Vergleich: Unter Windows funktioniert die Funktion „Wipe for NTFS“ in der Software CCleaner einwandfrei, und Gott kann tatsächlich gelöschte Daten nicht lesen.

Um gründlich zu löschen, „kompromittierende“ alte unverschlüsselte Daten, ist ein direkter Zugang von Bleachbit zu diesen Daten erforderlich, danach sollten Sie die Funktion „Dateien/Verzeichnisse unwiderruflich löschen“ nutzen.
Um „gelöschte Dateien mit den Bordmitteln des Betriebssystems“ in Windows zu entfernen, verwenden Sie CCleaner/BB mit der Funktion „Wipe“. In GNU/Linux müssen Sie sich um dieses Problem kümmern, (Löschen gelöschter Dateien) müssen Sie praktische Erfahrungen sammeln (Daten löschen + eigenständiger Versuch, sie wiederherzustellen, und Sie sollten sich nicht auf die Softwareversion verlassen (wenn es kein Backdoor ist, ist es ein Bug)), nur in diesem Fall verstehen Sie den Mechanismus dieses Problems und können die gelöschten Daten endgültig loswerden.

Bleachbit v3.0 wurde nicht geprüft, möglicherweise wurde das Problem bereits behoben.
Bleachbit v2.0 arbeitet zuverlässig.

In diesem Schritt ist die „Festplattenschonung“ abgeschlossen.

[E] Universelle Datensicherung für verschlüsselte Betriebssysteme

Jeder Benutzer hat seine eigene Methode, Daten zu sichern, aber verschlüsselte Daten von „System-Betriebssystemen“ erfordern einen etwas anderen Ansatz. Einheitliche Software, wie zum Beispiel „Clonezilla“ und ähnliche Software, kann nicht direkt mit verschlüsselten Daten arbeiten.

Die Aufgabenstellung für die Datensicherung von verschlüsselten Blockgeräten:

1. Universalität – ein einheitlicher Algorithmus/software zur Datensicherung für Windows/Linux;
2. die Möglichkeit, in der Konsole mit jedem Live-USB-GNU/Linux ohne zusätzliche Software herunterzuladen, zu arbeiten (aber ich empfehle dennoch eine GUI);
3. Sicherheit der Backups – die gespeicherten „Images“ sollten verschlüsselt/passwortgeschützt sein;
4. die Größe der verschlüsselten Daten muss der Größe der tatsächlich zu sichernden Daten entsprechen;
5. komfortablen Zugriff auf die benötigten Dateien aus dem Backup (keine Notwendigkeit, zuerst die gesamte Partition zu entschlüsseln).

Zum Beispiel, Backup/Wiederherstellung über das Tool „dd“

dd if=/dev/sda7 of=/path/sda7.img bs=7M conv=sync,noerror
dd if=/path/sda7.img of=/dev/sda7 bs=7M conv=sync,noerror

Entspricht fast allen Punkten der gestellten Aufgabe, jedoch ist Punkt 4 nicht kritikfähig, da er den gesamten Bereich der Festplatte einschließlich des freien Speicherplatzes kopiert — das ist nicht interessant.

Zum Beispiel ist ein Backup von GNU/Linux über das Archivierungsprogramm [tar» | gpg] praktisch, aber für ein Windows-Backup muss eine andere Lösung gefunden werden — das ist nicht interessant.

E1. Universelles Backup für Windows/Linux. Kombination aus rsync (Grsync)+VeraCrypt-VolumeAlgorithmus zur Erstellung eines Backups:

1. Erstellung eines verschlüsselten Containers (Volume/Datei) VeraCrypt für das Betriebssystem;
2. Übertragung/Synchronisation des Betriebssystems mithilfe der Software Rsync in den Kryptokontainer VeraCrypt;
3. bei Bedarf das VeraCrypt-Volume über das Internet laden.

Die Erstellung eines verschlüsselten VeraCrypt-Containers hat ihre Besonderheiten:
Erstellung eines dynamischen Volumes (Dynamische Volumes können nur unter Windows erstellt werden, sind aber auch unter GNU/Linux verwendbar);
Erstellung eines gewöhnlichen Volumes, jedoch gibt es eine „paranoide“ Anforderung (laut Aussage des Entwicklers) – Formatierung des Containers.

Ein dynamisches Volume wird unter Windows nahezu sofort erstellt, doch beim Übertragen von Daten von GNU/Linux > VeraCrypt-DT sinkt die Gesamtleistung des Backup-Vorgangs erheblich.

Ein normales Twofish-Volume mit 70 GB wird erstellt (sagen wir, mit einer durchschnittlichen PC-Leistung) auf der HDD in etwa einer halben Stunde (Überschreibung der vorherigen Daten des Containers in einem Durchgang, dies ist durch Sicherheitsanforderungen bedingt). In VeraCrypt Windows/Linux wurde die Funktion zur schnellen Formatierung des Volumes bei der Erstellung entfernt, sodass die Erstellung eines Containers nur durch „Überschreibung in einem Durchgang“ oder die Erstellung eines weniger leistungsfähigen dynamischen Volumes möglich ist.

Erstellen wir ein normales VeraCrypt-Volume (nicht dynamisch/ntfs), es sollten keine Probleme auftreten.

Konfigurieren/erstellen/öffnen Sie den Container in der VeraCrypt GUI > GNU/Linux Live-USB (das Volume wird automatisch unter /media/veracrypt2 eingehängt, das Windows-Volume wird unter /media/veracrypt1 eingehängt). Erstellen Sie ein verschlüsseltes Backup des Windows-Betriebssystems mit der GUI rsync (grsync), indem Sie die Häkchen setzen.

Warten Sie auf das Ende des Prozesses. Nach Abschluss des Backups haben wir eine verschlüsselte Datei.

Auf die gleiche Weise erstellen Sie ein Backup des GNU/Linux-Betriebssystems, indem Sie das Häkchen in der GUI rsync für „Windows-Kompatibilität“ entfernen.

Achtung! Den VeraCrypt-Container für „GNU/Linux-Backup“ erstellen in einem Dateisystem ext4. Wenn Sie ein Backup im ntfs-Container erstellen, verlieren Sie beim Wiederherstellen dieser Kopie alle Rechte/Gruppen auf Ihre Daten.

Alle Operationen können auch im Terminal durchgeführt werden. Die Hauptoptionen für rsync:
* -g - Gruppen beibehalten;
* -P —progress — Status der Arbeitszeit an der Datei;
* -H - Hardlinks unverändert kopieren;
* -a - Archivmodus (einige Flags rlptgoD);
* -v - Verbalisation.

Wenn Sie das „Windows VeraCrypt-Laufwerk“ über die Konsole in der Software cryptsetup einbinden möchten, können Sie ein Alias (su) erstellen.

echo "alias veramount='cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sdaX Windows_crypt && mount /dev/mapper/ Windows_crypt /media/veracrypt1'" >> .bashrc && bash

Jetzt wird bei der Eingabe des Befehls „veramount pictures“ eine Aufforderung zur Eingabe des Passworts angezeigt, und das verschlüsselte Windows-Systemlaufwerk wird im Betriebssystem eingehängt.

Die Befehlszeile für das Einbinden des VeraCrypt-Systemlaufwerks in cryptsetup lautet

cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sdaX Windows_crypt
mount /dev/mapper/Windows_crypt /mnt

Die Befehlszeile für das Einbinden des VeraCrypt-Teils oder Containers in cryptsetup lautet

cryptsetup open --veracrypt --type tcrypt /dev/sdaY test_crypt
mount /dev/mapper/test_crypt /mnt

Statt eines Alias fügen wir (Skript zum Autostart) das Systemlaufwerk mit Windows und die logische verschlüsselte NTFS-Disk in den Autostart von GNU/Linux hinzu.

Wir erstellen ein Skript und speichern es in ~/VeraOpen.sh

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 #dekodiert das Passwort aus base64 (bob) und sendet es zur Passwortabfrage beim Einbinden des Windows-Systemlaufwerks.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/КонтейнерНтфс #analog, jedoch binden wir die logische NTFS-Disk ein.

Setzen Sie die „richtigen“ Berechtigungen:

sudo chmod 100 /VeraOpen.sh

Erstellen Sie zwei identische Dateien (mit demselben Namen!) in /etc/rc.local und ~/etc/init.d/rc.local
Füllen Sie die Dateien

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will «exit 0» on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sh -c "sleep 1 && '/VeraOpen.sh'" #после загрузки ОС, ждём ~ 1с и только потом монтируем диски.
exit 0

Setzen Sie die „richtigen“ Berechtigungen:

sudo chmod 100 /etc/rc.local && sudo chmod 100 /etc/init.d/rc.local 

Fertig, jetzt müssen wir beim Start von GNU/Linux keine Passwörter zum Einbinden der verschlüsselten NTFS-Disk eingeben, die Laufwerke werden automatisch eingehängt.

Eine kurze Notiz über das oben Beschriebene in Abschnitt E1 Schritt für Schritt (jetzt jedoch für das OS GNU/Linux)
1) Erstellen Sie ein Volume im fs ext4 > 4GB (für eine Datei) Linux in Veracrypt [KryptoBox].
2) Starten Sie von einem Live-USB.
3) ~$ cryptsetup open /dev/sda7 Lunux # Einbinden des verschlüsselten Teils.
4) ~$ mount /dev/mapper/Linux /mnt # Verschlüsselten Teil in /mnt einbinden.
5) ~$ mkdir mnt2 # Verzeichnis für zukünftige Backups erstellen.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/KryptoBox KryptoBox && mount /dev/mapper/KryptoBox /mnt2 # Einbinden des VeraCrypt-Volumes mit dem Namen „KryptoBox“ und Einbinden der KryptoBox in /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ # Operation zur Sicherung des verschlüsselten Teils in das verschlüsselte VeraCrypt-Volume.

(p/s/ Achtung! Wenn Sie ein verschlüsseltes GNU/Linux von einer Architektur/Maschine auf eine andere übertragen, z. B. von Intel > AMD (d. h. Sie spielen ein Backup von einer verschlüsselten Partition auf eine andere verschlüsselte Partition von Intel > AMD), vergessen Sie nicht nach der Übertragung des verschlüsselten OS den geheimen Einfüge-Schlüssel anstelle des Passworts zu ändern, da der vorherige Schlüssel ~ /etc/skey – bereits nicht mehr zu einer anderen verschlüsselten Partition passt, und ein neuer Schlüssel mit „cryptsetup luksAddKey“ nicht idealerweise aus chroot erstellt werden sollte – ein Fehler ist möglich, geben Sie einfach in ~ /etc/crypttab vorübergehend „none“ anstelle von „/etc/skey“ an, nach dem reboot und dem Zugang zum OS erstellen Sie Ihren geheimen Einfüge-Schlüssel neu.

Als IT-Veteranen vergessen wir nicht, separate Backups der Header verschlüsselter Partitionen für Windows/Linux zu erstellen, da die Verschlüsselung sonst gegen Sie selbst eingesetzt werden kann.
An diesem Punkt ist die Sicherung der verschlüsselten OS abgeschlossen.

[F] Angriff auf den GRUB2-Bootloader

DetailsWenn Sie Ihren Bootloader mit einer digitalen Signatur und/oder Authentifizierung geschützt haben (siehe p.C6.), dann schützt dies nicht vor physischem Zugriff. Die verschlüsselten Daten bleiben unzugänglich, aber der Umgehungsschutz (Zurücksetzen des Schutzes durch digitale Signatur) GRUB2 ermöglicht es einem Cyberkriminellen, seinen Code in den Bootloader einzufügen, ohne Verdacht zu erregen (es sei denn, der Benutzer überwacht manuell den Zustand des Bootloaders oder denkt sich einen stabilen benutzerdefinierten Skript-Code für grub.cfg aus).

Angriffsalgorithmus. Der Angreifer

* startet den PC von einem Live-USB. Jede Änderung (durch den Angreifer) der Dateien würde den tatsächlichen Besitzer des PCs über das Eindringen in den Bootloader informieren. Aber eine einfache Neuinstallation von GRUB2 mit Beibehaltung der grub.cfg (und der späteren Möglichkeit, sie zu bearbeiten) wird es dem Angreifer ermöglichen, beliebige Dateien zu bearbeiten (in diesem Szenario würde es bei der Bootmeldung von GRUB2 keine Benachrichtigung an den tatsächlichen Benutzer geben. Der Status bleibt der gleiche )
* montiert die unverschlüsselte Partition und speichert „/mnt/boot/grub/grub.cfg“ bei sich.
* installiert den Bootloader neu (indem „perskey“ aus dem core.img-Bild entfernt wird)

grub-install --force --root-directory=/mnt /dev/sda6

* gibt „grub.cfg“ > „/mnt/boot/grub/grub.cfg“ zurück, bearbeitet es bei Bedarf, zum Beispiel indem er sein Modul „keylogger.mod“ im Modulverzeichnis des Bootloaders hinzufügt, in „grub.cfg“ > Zeile „insmod keylogger“. Oder beispielsweise, wenn der Feind hinterhältig ist, dann nach der Neuinstallation von GRUB2 (bleiben alle Signaturen an Ort und Stelle) Er erstellt das Hauptbild von GRUB2 mit "grub-mkimage mit der Option (-c)." Die Option "-c" ermöglicht es, seine Konfiguration vor dem Laden des Haupt-"grub.cfg" zu laden. Die Konfiguration kann aus nur einer Zeile bestehen: eine Umleitung zu einer beliebigen "modern.cfg", gemischt mit etwa 400 Dateien (Module+Signaturen) im Verzeichnis "/boot/grub/i386-pc". Dabei kann der Angreifer beliebigen Code einfügen und Module laden, ohne "grub/grub.cfg" zu beeinträchtigen, selbst wenn der Benutzer "hashsum" auf die Datei angewendet hat und sie vorübergehend auf dem Bildschirm angezeigt wurde.
Der Angreifer benötigt für den Login/Passwort des Superusers von GRUB2 keinen Brute-Force-Angriff, es reicht einfach, die Zeilen zu kopieren (die für die Authentifizierung verantwortlich sind) "/boot/grub/grub.cfg" in seine "modern.cfg"

set superusers=„root“
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

Und für den PC-Besitzer bleibt die Authentifizierung des Superusers von GRUB2 weiterhin wirksam.

Chain-Loading (der Bootloader lädt einen anderen Bootloader), wie oben erwähnt, macht keinen Sinn (es ist für einen anderen Zweck gedacht). Aufgrund des BIOS kann kein verschlüsselter Bootloader geladen werden (bei Chain-Loading wird GRUB2 neu gestartet > verschlüsselter GRUB2, Fehler!). Wenn man jedoch die Idee des Chain-Loadings anwendet, kann man sicher sein, dass tatsächlich der verschlüsselte (nicht modernisierte) "grub.cfg" aus dem verschlüsselten Abschnitt geladen wird. Und auch das ist ein falsches Sicherheitsgefühl, denn alles, was in der verschlüsselten "grub.cfg" (modulbasiert) wird mit den Modulen, die aus dem unverschlüsselten GRUB2 geladen werden, kombiniert.

Wenn Sie dies überprüfen möchten, erstellen Sie einen weiteren verschlüsselten Abschnitt sdaY, kopieren Sie GRUB2 darauf (der Vorgang grub-install auf einem verschlüsselten Abschnitt ist nicht möglich) und in "grub.cfg" (unverschlüsselte Konfiguration) ändern Sie Zeilen wie diese

menuentry 'GRUBx2' --class parrot --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-382111a2-f993-403c-aa2e-292b5eac4780' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_twofish
insmod gcry_twofish
insmod gcry_sha512
insmod ext2
cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838
set root='cryptouuid/15c47d1c4bd34e5289df77bcf60ee838'
normal /boot/grub/grub.cfg
}

Zeilen
* insmod -Laden der benötigten Module für die Arbeit mit der verschlüsselten Festplatte;
* GRUBx2 -die angezeigte Zeile im GRUB2-Bootmenü;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 -siehe fdisk -l (sda9);
* set root -Festlegung des Roots;
* normal /boot/grub/grub.cfg -ausführbare Konfigurationsdatei im verschlüsselten Abschnitt.

Das Vertrauen darin, dass tatsächlich die verschlüsselte «grub.cfg» geladen wird, ist eine positive Rückmeldung bei der Eingabe des Passworts / der Entsperrung von «sdaY» bei der Auswahl der Zeile «GRUBx2» im GRUB-Menü.

Um im CLI nicht durcheinanderzukommen, (und zu überprüfen, ob die Umgebungsvariable «set root» funktioniert hat), erstellen Sie leere Marker-Dateien, zum Beispiel im verschlüsselten Bereich «/shifr_grub», im unverschlüsselten Bereich «/noshifr_grub». Überprüfung im CLI

cat /Tab-Tab

Wie bereits erwähnt, wird dies nicht helfen, das Laden bösartiger Module zu verhindern, wenn solche Module auf Ihrem PC vorhanden sind. Zum Beispiel ein Keylogger, der Tasteneingaben in einer Datei speichert und sich mit anderen Dateien in «~/i386» vermischt, bis er vom Angreifer mit physischem Zugriff auf den PC heruntergeladen wird.

Der einfachste Weg zu überprüfen, ob der Schutz der digitalen Signatur aktiv funktioniert (nicht zurückgesetzt), und niemand in den Bootloader eingedrungen ist, geben Sie im CLI den Befehl

list_trusted

ein und erhalten als Antwort einen Schnappschuss unseres «perskey», oder wir erhalten nichts, wenn wir angegriffen wurden. (es muss auch überprüft werden, ob «set check_signatures=enforce» gesetzt ist).
Ein wesentlicher Nachteil dieses Schrittes ist, dass die Befehle manuell eingegeben werden müssen. Wenn Sie diesen Befehl in «grub.cfg» einfügen und die Konfiguration mit einer digitalen Signatur schützen, ist die vorläufige Ausgabe des Schlüssels zu kurz und man hat keine Zeit, die Ausgabe zu erkennen, bevor GRUB2 geladen wird.
Es gibt kaum jemanden, an den man Ansprüche stellen könnte: Der Entwickler erklärt in seinem Dokumentation p.18.2 offiziell,

„Beachten Sie, dass GRUB selbst, selbst mit Passwortschutz, nicht verhindern kann, dass jemand mit physischem Zugriff auf die Maschine die Firmware (z. B. Coreboot oder BIOS) so ändert, dass die Maschine von einem anderen (angreiferkontrollierten) Gerät bootet. GRUB ist bestenfalls nur ein Glied in einer sicheren Bootkette.“

GRUB2 ist mit Funktionen überladen, die ein Gefühl von falscher Sicherheit vermitteln könnten, und seine Weiterentwicklung hat die Funktionalität von MS-DOS bereits übertroffen, obwohl es nur ein Bootloader ist. Lustig ist, dass GRUB2 – das „Morgen“ – ein Betriebssystem werden könnte, während die mit GNU/Linux virtuellen Maschinen für ihn geladen werden.

Ein kurzes Video darüber, wie ich den Schutz der digitalen Signatur von GRUB2 zurückgesetzt habe und mich als Eindringling bei einem echten Benutzer zu erkennen gegeben habe. (ich habe ihn erschreckt, und anstelle dessen, was im Video gezeigt wird, kann man auch nicht harmlosen beliebigen Code / .mod schreiben).

Fazit:

1) Blockweises Systemverschlüsselung für Windows ist einfacher zu implementieren, und der Schutz mit einem Passwort ist bequemer als der Schutz mit mehreren Passwörtern bei der blockweisen Systemverschlüsselung von GNU/Linux; der Fairness halber: Letzteres ist automatisiert.

2) Der Artikel wurde als relevant und detailliert verfasst einfach eine Anleitung zur vollständigen Festplattenverschlüsselung von VeraCrypt/LUKS auf einer Heimmaschine, die derzeit die beste im russischen Internet ist (IMHO). In der Anleitung sind > 50k Zeichen enthalten, daher wurden einige interessante Kapitel nicht behandelt: über Kryptographen, die verschwinden/sich im Schatten halten; darüber, dass in verschiedenen Büchern über GNU/Linux wenig/nichts über Kryptographie steht; über Artikel 51 der Verfassung der RF; über Lizenzierung/запрете der Verschlüsselung in der RF, darüber, warum es notwendig ist, den „Root/Boot“ zu verschlüsseln. Die Anleitung ist auch ohne diese Kapitel umfassend geworden, aber (beschreibt sogar die einfachen Schritte), was Ihnen wiederum eine Menge Zeit sparen wird, wenn Sie sich mit der „echt vollständigen Verschlüsselung“ beschäftigen.

3) Die vollständige Festplattenverschlüsselung wurde auf Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5 durchgeführt.

4) Ich habe einen erfolgreichen Angriff auf meinen GRUB2-Bootloader durchgeführt.

5) Das Tutorial wurde erstellt, um allen Paranoikern in der GUS zu helfen, wo die Arbeit mit Verschlüsselung auf gesetzlicher Basis erlaubt ist. Und in erster Linie für diejenigen, die vollständige Festplattenverschlüsselung einrichten möchten, ohne ihre konfigurierten Systeme zu löschen.

6) Ich habe mein Leitfaden überarbeitet und aktualisiert, der 2020 relevant ist.

[G] Nützliche Dokumentation

1. Benutzerhandbuch zu TrueCrypt (Februar 2012 RU)
2. Dokumentation zu VeraCrypt
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (offizielle detaillierte Dokumentation zur Einrichtung der Verschlüsselung von GNU/Linux mit cryptsetup)
4. Offizielle FAQ zu cryptsetup (kurze Dokumentation zur Einrichtung der Verschlüsselung von GNU/Linux mit cryptsetup)
5. Verschlüsselung des LUKS-Geräts (archlinux-Dokumentation)
6. Detaillierte Beschreibung der Syntax von cryptsetup (Handbuchseite arch)
7. Detaillierte Beschreibung von crypttab (Handbuchseite arch)
8. Offizielle Dokumentation zu GRUB2.

Tags: vollständige Festplattenverschlüsselung, Partitionsverschlüsselung, vollständige Festplattenverschlüsselung Linux, vollständige Systemverschlüsselung LUKS1.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.

Verschlüsseln Sie?

• 17,1%Ich verschlüssele alles, was möglich ist. Ich habe Paranoia.

• 34,2%Ich verschlüssele nur wichtige Daten.

• 14,6%Manchmal verschlüssele ich, manchmal vergesse ich es.

• 34,2%Nein, ich verschlüssele nicht, es ist unpraktisch und kostspielig.

82 Nutzer haben abgestimmt. 22 Nutzer haben sich enthalten.

Quelle: habr.com