Sie sind nicht angemeldet.

  • »cerberus« ist der Autor dieses Themas

Beiträge: 2

Registrierungsdatum: 18.02.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Andere Betriebssysteme: Ubuntu Server

  • Nachricht senden

1

18.02.2014, 23:32

Verschlüsselter Root-Server kann nicht via SSH freigeschaltet werden

Hallo zusammen,

- Situation: Der Root-Server soll bis auf /boot (md1) und /swap (md0) verschlüsselt sein. Folgendes wurde mit Ubuntu12.04.3 (minimal), 12.10(minimal), 13.04(minimal) und 13.10(minimal) ausprobiert, mit aktivem RAID1.

- Ziel: Beim starten/rebooten des Root-Servers, startet Dropbear und mittels Busybox entschlüsselt man die RAID-Partition auf der das Betriebssystem liegt, das Root-System startet durch und man kann sich per SSH normal mit seinem User anmelden und fröhlich seine Dienste starten.

- Problem: Die unten aufgeführten Schritte wurden ausgeführt, jedoch wird die verschlüsselte Root-Partition (md2) anscheinend nicht entschlüsselt und der Server startet neu - ich lande also wieder im Dropbear (s.u.). Nach diesen und auch anderen Versuchen habe ich keinen Fortschritt erzielen können, um meinen verschlüsselten Root-Server zu booten. Anscheinend wird die verschlüsselte Root-Partition nicht korrekt entschlüsselt oder der Boot-Vorgang liefert Fehler (die ich nicht sehe, da der Server sonst wo steht), weswegen der Root-Server anscheinend neustartet.



Folgende Schritte wurden durchgeführt und zur Übersicht in zwei Phasen eingeteilt.

--- Phase 1. – Vorbereitung und Konfiguration ---

1. Server auf z.B. 12.04.03 (minimal) eine Basis-Konfiguration durchgeführt. Darüber hinaus folgende Schritte:

Quellcode

1
nano /etc/.ssh/sshd_conf 

-> ändere: PermitRootLogin von YES auf NO setzen
-> ändere: PasswordAuthentication von YES auf NO setzen


2. Installiere notwendige Programme:

Quellcode

1
aptitude install cryptsetup dropbear busybox 


3. Ergänze Initramfs Konfiguration an der Stelle “DEVICE= ”:

Quellcode

1
nano /etc/initramfs-tools/initramfs.conf 

-> DEVICE=eth0
-> IP=<serverIP>::<gateway>:<subnetz>:<rechnerName>:eth0:off
-> DROPBEAT=y


4. Pass Crypttab an:

Quellcode

1
nano /etc/crypttab 

-> cryptroot /dev/md2 none luks


5. Passe Fstab an:

Quellcode

1
nano /etc/fstab 

-> ersetze “/dev/md2” durch “/dev/mapper/cryptroot”


6. Skripte, die die Bugs zwischen Plymouth und dem Entschlüsseln beheben sollen einspielen und ausführbar machen:
Entweder Link1 (bis auf "dropbear.fixup3" ist das aktuell auf meinem Root-Server) oder Link2 (habe ich auch ausprobiert, gib auch nicht). (Alternativ auch einen Manuellen Fix: Link3
Generelles Vorgehen:

Quellcode

1
cat >/mein/pfad/dropbear.fix <<'__EOF__' 

-> Skript von Link1 oder Link2 einfügen...

Quellcode

1
chmod a+x /mein/pfad/dropbear.fix 



7. Erstelle einen SSH-Schlüssel und schreibe den Public-Key in die authorized_keys von Dropbear:

Quellcode

1
2
3
4
mkdir  /home/<user>/.ssh/dropbear
cd /home/<user>/.ssh/dropbear
ssh-keygen –t rsa
sudo cat /home/<user>/.ssh/dropbear/id_rsa_dropbear.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys



8. Den erstellten SSH-Key mit WinSCP kopieren:
-> … windows gedaddel …


9. Führe ein Update der Initramfs durch:

Quellcode

1
 update-initramfs -u -k all 




--- Phase 2. – Verschlüsseln ---

10. Rettungssystem booten.

11. Mounte unverschlüsseltes System, erstelle ein Backup und verschiebe es auf eine Backup-Platte:

Quellcode

1
2
3
4
5
6
cd /
mkdir /realroot
mdadm –assemble /dev/md2 --uuid 123:123:123 md2
mount /dev/md2 /realroot
tar cvzf backup.tar.gz /realroot/
scp -P 23 /backup.tar.gz yourUsername@yourHost.de:/backup.tar.gz 



12. Entferne bisherigen Mount, damit man /dev/md2 formatieren können:

Quellcode

1
umount -f /dev/md2 



13. Formatiere /dev/md2 mit crytpsetup, bestätige mit YES und gebe ein PW ein:

Quellcode

1
cryptsetup luksFormat /dev/md2 



14. Entschlüssle die Partition und formatiere diese:

Quellcode

1
2
cryptsetup luksOpen /dev/md2 cryptroot
mkfs.ext3 /dev/mapper/cryptroot 



15. Nach kurzem warten kann man das Cryptroot mounten und das Backup zurückspielen:

Quellcode

1
2
3
4
5
mount /dev/mapper/cryptroot /realroot/
cd /
scp -P 23 yourUsername@yourHost.de:/backup.tar.gz /backup.tar.gz
tar xzvf /backup.tar.gz –C /
rm backup.tar.gz 



16. Unmounten der verschlüsselten Root-Partition und Neustart des Systems, damit man sich auf Dropbear einloggen kann:

Quellcode

1
2
3
umount /dev/mapper/cryptroot
cryptsetup close cryptroot
shutdown –r now 



17. Sobald das System per Ping erreichbar ist als root mit dem Dropbear-SSH-PW einloggen -> Wir sind auf Busybox!

18. Nun Festplatte entschlüsseln! Mit den Skripten recht einfach:

Quellcode

1
unlock 



=> PROBLEM: Nun sieht man immer wieder dasselbe Resultat, das in dem Screenshot oben zu sehen ist. Festplatten werden angeblich entsperrt, Dropbear-Session wird abgeschossen, das System ist kurzzeitig nicht erreichbar (mein System bootet? Ja/Nein/Vielleicht?), dann ist der „Zielhost nicht erreichbar“. Der Server bootet dabei anscheinend neu und man landet wieder auf dem Dropbear, sobald ein Ping erfolgreich ist.



Ich hoffe, dass einer mir helfen kann, indem er mich evtl darauf hinweist was ich falsch mache.

PS: Sollte das Problem gelöst werden stelle ich das Ganze als Guide („Verschlüsselter Ubuntu-Server from Scratch via SSH freischalten“) in einen neuen Thread setzen!


Viele Grüße,
C.

  • »cerberus« ist der Autor dieses Themas

Beiträge: 2

Registrierungsdatum: 18.02.2014

Derivat: Ubuntu

Architektur: 64-Bit PC

Andere Betriebssysteme: Ubuntu Server

  • Nachricht senden

2

24.02.2014, 14:25

Wow! Das war mein erster Post. Es gab 44 Views und keine Antwort! Anscheinend darf ich keine vollständigen Artikel schreiben bzw Fragen in der Ausführlichkeit stellen, wenn ich eine Lösung/Lösungsansatz auf mein Problem suche. Ich werde Ende der Woche den Artikel schließen, da mir anscheinend niemand bei meinem Problem helfen kann. Schade!
Gruß, C.

  • »maettu« ist männlich

Beiträge: 3 299

Registrierungsdatum: 14.09.2005

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

3

25.02.2014, 09:21

ähm ist auch ein äusserst kompliziertes Thema!

Und in einem Forum sind übrigens meistens gewöhnliche Leute, die meisten davon haben keine Ausbildung in Linux-Server-Administration.
Wobei ich eine Verschlüsselung bei Servern eh etwas kritisch finde, die meisten Angriffe werden wohl im "entschlüsselten" Zustand erfolgen, da ja ein Server im Normalfall 24/7 laufen sollte.
Aber bin bezüglich Verschlüsselung kein Experte, ich hab immer Angst irgendwas geht kaputt und dann sind alle Daten weg ;)

DocHifi

unregistriert

4

25.02.2014, 09:58

Das selbe gilt für mich, ich habe weder einen Server, noch kenne ich mit Verschlüsselung aus.
Daher kann auch ich nicht helfen.