Verschlüsselung, Hoster ausgrenzen.

[Anonymous]

Hallo,

ich habe letztens mit einem Freund eine Diskussion geführt.
Er ist der Meinung, dass man ein dedicated-server komplett Verschlüsseln kann, so dass selbst der Hoster kein Zugriff hat.

Ist es nicht aber so, dass sobald das System läuft und die Verschlüsselten Partitionen gemounted sind, jeder mit Zugriff auf den PC, die Daten lesen kann? Die Partitionen werden doch beim mounten sozusagen "geöffnet", oder hab ich hier was falsch verstanden?

Weiterhin ist er der Meinung, dass es möglich ist, Zugriff auf die Verschlüsselten Daten nur über FTP/http (mit entsprechendem passwort), erlauben kann.

Damit der ftpd/httpd die Daten lesen kann, muss der/die Container/Partion doch gemounted sein, oder?
AFAIK, kann der ftpd/httpd die Daten nicht "On-Demand" entschlüsseln.

Ich lass mich natürlich gerne eines besseren belehren.
Sollte ich unrecht haben, wär ich über jede/n Hinweis/Doc froh.

thanks in advance

[lord_pinhead]

Ich denke da ist dein Freund etwas falsch gewickelt :).

1) Wenn ich die Partitionen sperre, muss ich wenigstens noch /boot (für den Kernel) und /etc (für die Initscripte + fstab) offen halten. Da die restlichen Partitionen aber verschlüsselt sind, müsste als allererstes der Rest eingemountet werden, dazu brauch ich jemanden der vor der Kiste sitzt und beim Booten das Passwort reinhackt. Leider kann ich mount nicht sagen das er das Passwort einfach so übergeben soll, das geht nur mit dem Optionalen Seed den ich bei Loop-AES verwenden kann. Also es scheitert einfach nur an einen der das Passwort beim Booten eintippt :twisted: Theoretisch könnte ich einen Bashscript sagen das er automatisch das Passwort bei der Abfrage übergeben soll, das ist aber wieder klar lesbar, Vorteil der Verschlüsselung 0 :roll:

2) Ok, rein Praktisch sind verschlüsselte Homedirs möglich. Ich könnte das ganze über pam_mount realisieren wenn ich auf den FTP zugreife. Nur wenn ich mich dann auslogge, wird der Container wieder ausgehängt und über HTTP nicht mehr erreichbar. Wieder scheitert es an einen Passwort welches mit HTTP ja nicht mitgegeben werden kann, ebensowenig wie die komplette Useranmeldung die pam_mount benötigt. Möglicherweise könnte pam_mount ja mit WebDAV zusammenarbeiten, dann könnte es rein theoretisch laufen. Also wenn er FTP Accounts verschlüsseln möchte, soll er mal nach "Encrypted Home directories" suchen. Ã?ber FTP ist es vielleicht möglich das pam_mount das loginpasswort auch für den Container zu verwenden, ich hab das nie getestet. Nachteil: Ich kann das Passwort nie ändern da es gleich ist mit dem Containerpasswort. Ok, ich kenne einen Provider (Rapid FTP oder wie der hieß), der bietet an Firmenbackups dort in einen Loop-AES zu speichern, dürfte auch mit pam_mount laufen und beim Ausloggen sind die Firmendaten gesichert. Wie das genau abläuft kann ich jetzt nur raten.

Also realistisch gesehen ist so eine Lösung nur bedingt möglich, aber allenfalls totaler Schwachsinn. Wenn er sein Provider aussperren will, soll er die TTY´s die beim Booten starten abschalten. Es geht sowisso keiner an die Kiste, also warum soll er sich da in die Hosen machen. Wenn er illegale Sachen auf der Kiste hat, braucht er eher Freunde bei sein Hoster als nen Verschlüsseltes Homedir.

Und noch kurz zur Frage wegen der Lesbarkeit: Klar ist es lesbar, wie willst du sonst wieder an deine Daten kommen? Praktisch sind diese Sachen für Laptops und Firmenrechner interessant, wenn da wichtige Daten drauf sind die keiner lesen darf (Laptop geklaut/Verloren, Festplatte im Betrieb geklaut, bleibt trotzdem alles sicher). Ist der verschlüsselte Container gemountet, kann jeder darin lesen der Zugriffsrechte für den Ordner hat. Fährt der Hoster die Kiste allerdings runter, kann er nicht mehr, bis du es wieder einmountest, darin rumsuchen. Ausser er kennt dein Passwort und den Optionale Seed. Muss der Hoster die Kiste runterfahren weil die Polizei Ihn beschlagnahmen möchte und die merken dann danach das er die Beweise verschlüsselt hat, kann es Beugehaft nach sich ziehen. Er belastet sich zwar damit selbst, aber man kann Ihn ja auch nicht so davonkommen lassen. Also wozu das ganze?

Ok, mal zu einer Praktischen Anwendung von Loop-AES. Wenn ich jetzt von meinen Serversystem ein Hashabdruck mache mit sha1sum, und möchte die Datei verstecken sowie wichtige andere Scripte, dann lohnt es sich einen Container zu verstecken, der nur eingemountet wird wenn du alleine an der Kiste sitzt und Administrative Aufgaben machst, wie z.b. Abgleich des Systems mit der Hashfile, Backup von Logs/Userdaten etc. Dazu nutze ich auch ein Loop-AES das irgendwo versteckt liegt und nur ich weiß wo es ist. Ein Hacker kann es dann höchstens löschen, aber nie reinsehen was darin ist. Schieb ich die Datei wieder hoch mit dem Inhalt, kann ich genauso wieder Arbeiten wie zuvor und das System checken (vorrausgesetzt ich sicher es in regelmässigen Abständen).

Sollte ich jetzt was ausgelassen haben sagt bescheid, mehr fällt mir jetzt im moment nicht ein zu dem Thema :)

[outofbound]

Platte crypten, bis auf die "boot"- Partition. Passphrase über die SSH- Gesicherten Remote Consoles eingeben, dann ist man ziemlich "sicher" wenn die Kiste "offline" geht. Angriffe im laufenden Betrieb sind eine ganz andere Sache. Prinzipiell könnte man da noch vorarbeit leisten, indem man den Swap z.B. Random crypted, speicherprofile niedrig hält und diverse Totmannschaltungen bei Angriffsversuchen einbaut. Da leidet dann aber natürlich die Erreichbarkeit drunter. ;)
Je nach Encryption- Method sind ja auch nur einzelne Blöcke der Platte "lesbar" (Im RAM, Swap)... das wird aber dann etwas komplex. ;)

Warum man natürlich so sensible Daten überhaupt auf einem Server im Netz ablegt, ist eine ganz andere Sache. ;) Vor allem wenn man die Daten dann doch public available macht. ;)

Und gegen einen gepatchten SSH auf der Remote Console hat man auch verloren. ;)

Als Ã?bung hab ich das mal mit Gentoo auf einer Testkiste aufgesetzt.
Ist ganz witzig, die Anwendungsfälle allerdings sehr begrenzt. ;)

Insofern hat dein Kollege Recht, man könnte solche Sachen mit gepatchtem ftpd/httpd tatsächlich erreichen... ob das jemand gemacht hat... seehr unwahrscheinlich. ;)

Gruss,

Out

[Anonymous]

Erstmal danke für die Antworten, sind sehr hilfreich.
Das Thema kam auf, als wir über Sinn und Einsatzgebiete von Verschlüsselten Systemen gesprochen hatten. Da kam es dann irgendwie auch zum dedicated. Das ganze ist nur ne Diskussion, es geht nicht um Sensible Daten die gesichert werden sollen oder so.


Zum pam_mount:
Sobald man mit der FTP/pam_mount Variante auf den Rechner zugreift und der Container eingehängt wird, ist er doch sozusagen "geöffnet" und der Hoster könnte an die Daten ran, (zumindest solange der User eingeloggt ist) oder?

Zum herunterfahren:
Soweit war auch meine Argumentation. Wird der Rechner heruntergefahren, hat keiner mehr Zugriff beim nächsten boot, ohne dem passphrase.
Solange der Server aber läuft, keine Chance.

Zur Remote-Console:
Das scheint mir auch ne gute Möglichkeit zu sein, das System zu verschlüsseln, aber auch hier ist es doch so, dass es im laufendem Betrieb den Hoster nicht ausperren würde, oder?

Theorie 1: Gehen wir aber mal davon aus, alles ist verschlüsselt mit der "Remote-Console Methode". Nach erfolgtem Systemstart, werden die tty's (remote-console ist auch ein tty, oder?) deaktiviert.
So scheint es mir, als könnte man das System so wirklich komplett vor Fremden Zugriffen schützen.

Theorie 2: Gehen wir davon aus, nicht das System, sondern nur eine Partition ist Verschlüsselt bzw. ein Container. Nach erfolgtem Systemstart werden die tty's deaktiviert. Anschliessend der Container bzw. die Partion eingehängt. So wär der Hoster ausgesperrt, aber über SSH/FTP/HTTP je nachdem welcher Dienst läuft, wären die Daten verfügbar. Das würde den Aufwand im Gegensatz zum komplett verschlüsseltem System etwas verringern, da man so nur die zu schützenden Daten verschlüsselt.


Sollten die letzten beiden Theorien in der Praxis so möglich sein, hab ich mich blamiert, aber was neues dazu gelernt :)

[lord_pinhead]

Ich überlege seit ich oob´s Post gelesen habe wie ich nur mit dem Kernel (sagen wir mal nen monolitischen Kernel) eine Serielle Konsole über das Internet bekomme und dann noch mit SSH Verschlüsselt wenn ich gar nicht auf die Programme zugreifen kann, sind ja alle auf den Verschlüsselten Partitionen. Praktisch, habe ich das mit einer Testkiste gemacht und habe nur /etc und /boot offen gelassen, aber ohne die Startscripte und fstab dürfte das recht unmöglich sein das man die Partition einhängen kann, und das selbst wenn ich davorsitze. oob, hast du da irgendwo was rumliegen wo das beschreibt was du sagst? Wäre interssant wenn das doch gehen würde.

Theorie 1: Die TTY´s werden nie gestartet, die kann man in /etc/inittab auskommentieren und gut ists

Theorie 2: Ja das ist möglich, sollange die Container nicht eingehängt wurden gibts da keine Chance für den Provider da so einfach reinzusehen. Loop-AES will z.b. min. ein 20 Stelliges Passwort, da kann er mal versuchen das zu knacken :D

Insofern hast du dich nicht ganz blamiert, es ist möglich seinen Provider Steine in den Weg zu legen. Aber ob das wirklich sooooo gut ist wenn ich das mache ist mal dahingestellt.

[outofbound]

Prinzipiell:

http://forums.gentoo.org/viewtopic-t-10 ... art-0.html

Gruss,

Out

[Anonymous]

juti, danke euch beiden.
Muss das ganze jetzt nochmal mit nem Testrechner probieren, nur Theorie ist auch langweilig :)

[Anonymous]

Ich habe bei mir eine FreeBSD Partition per dd auf den root Server geschossen und dort dann ein paar verschluesselte Partitionen für chroot-Jails/Swap erzeugt. Sollte der Server vom Netz gehen wird alles neu aufgesetzt und vom (verschlüsselten) Backup zurueckgespielt. Wenn der Server nicht im laufenden Betrieb oder beim ersten und einzigen booten kompromitiert wurde, sollte das recht dicht sein. Besser geht das vermutlich nur, wenn die Hardware unter eigener kontrolle ist. Ausserdem wird die Maschine natürlich laufend überwacht und wartet mit ein paar leckeren Fallen auf eventuelle Eindringlinge, welche im Notfall den Server innerhalb kürzester Zeit komplett abtöten.

Man muss als Admin etwas vorsichtiger auf Maschine sein. Seit den letzten zwölf Monaten läuft die Maschine aber perfekt. Eigentlich besser als erwartet, da ich ursprünglich nur mal testen wollte, wie stark massive Paranoia die Benutzbarkeit des Systems einschränkt. Ich hatte erwartet, selbst in eine meiner Fallen zu laufen, war aber bisher nicht der Fall.

[captaincrunch]

Klingt nach einem sehr interessanten Projekt. Wie wär's mit näheren Angaben, wenn nicht sogar einem kurz umrissenen Turotial?

[Anonymous]

Für FreeBSD auf einem (Alturo)Rootserver gibt es ein recht gutes
Wiki. Das sollte bei anderen Providern ähnlich funktionieren:
http://www.hcesperer.org/wiki/index.php ... auf_Alturo

Man sollte schauen, dass beim booten kein getty mehr gestartet wird (z.Bsp. FreeBSD '/etc/ttys': Alle tty Zeilen auf 'off' stellen, Linux '/etc/inittab': Alle getty Zeilen auskommentieren - oder aus dem Kernel rauskompilieren).

Ein Problem beim Remoteserver ist, dass man den Bootprozess sehr genau beobachten sollte, da dieser und das Rescue-System mögliche Angriffspunkte sind, welche man nicht unter Kontrolle hat.

Ist das System mal oben, kann man den Cryptoswap (bde_swap="YES" in /etc/rc.conf) und die Cryptolabels (man gbde) einrichten.

Vorzugsweise werden alle Services (auch ssh) per NAT auf die (verschiedene) Jails (man jail) umgebogen, sodass ein Angreifer erst mal in einer Jail landet. In der ssh-Jail kann man den root komplett abschalten und die entsprechenden SUID Tools löschen. Den/Die ssh Benutzer (SSH2 / Kein Passwort nur Zertifikat?!) kann man mit ein paar Fallen ausstatten (alias, ls, env, cd), welche erst mal per 'entferne_die_fallen_mit_einem_sehr_unueblichen_befehl' entschärft werden müssen. Passiert das nicht, wird ein Flag (im Filesystem) gesetzt, welches auf der Hauptinstallation von einem Daemon ausgewertet wird. Dieser killt als erstes das Netzwerkinterface (ifconfig rl0 down), um danach den Server Schritt für Schritt zu töten: gbde detach <gbde_labels>, shred|wipe <gbde_key_files>, dd if=/dev/urandom of=/dev/ad0, KERNELPANIC 8)

Das ganze kann man natürlich auch mit Linux und chroot oder besser UML (User Mode Linux) und cryptsetup/iptable machen.

Es empfiehlt sich in alle Jails/UML Fallen einzubauen. Das ganze ist natürlich umsonst, wenn der lokale Adminrechner gehackt wird oder mit einem Keylogger verseucht ist. Dort empfiehlt sich eine Cryptoroot und booten von Kernel/initrd vom USB-Stick/MiniCD. Oder gleich das komplette System von USB-Stick/CD booten. Gegen Hardware-Keylogger hilft xvkbd und kombinierte Eingabe mit Maus/Tastatur - wenn keine Videoüberwachung vorhanden ist.

Hat jemand noch mehr paranoide Ideen?

[captaincrunch]

Ideen (erstmal) nicht mehr, aber ein dickes Dankeschön. :) Hättest du Interesse, das in http://rootiewiki.de einzubringen (bzw. einbringen zu lassen)?