Rootserver sauber zurückgeben

Das Problem ist wohl, dass einzelne Zellen am Ende ihres Lebens angekommen sein können und überhaupt keine Schreibzyklen mehr verkraften. Was dort reingeschrieben wurde bleibt dann eben auch erhalten.

Andererseits halte ich das für eine hypothetische Gefahr, da die Datenmenge wohl insgesamt recht gering sein dürfte und man außerdem physischen Zugriff auf die SSD bräuchte. Ich persönlich denke auch, dass ein secure erase ausreichend ist, zumindest für die allermeisten Fälle.
 
Alderon said:
Das Problem ist wohl, dass einzelne Zellen am Ende ihres Lebens angekommen sein können und überhaupt keine Schreibzyklen mehr verkraften. Was dort reingeschrieben wurde bleibt dann eben auch erhalten.
Click to expand...
Dagegen hilft allerdings auch bei Festplatten nur Thermit. ;)

Es liest sich aber immer so wie: "Ja also bei Festplatten, da geht das ja mit dd, aber bei SSD - mach dir da mal keine Illusionen." Ich halte das für Käse und nur auf das partielle Überschreiben anwendbar, da es ja darum geht, dass wenn ich eine Datei überschreibe dieser Schreibvorgang andere physische Zellen betrifft. Bei einem Komplett-Wipe treffe ich zwar auch andere Stellen, aber von diesen anderen Stellen dann doch wieder alle. Da ist mir die Reihenfolge doch eher Wurscht, Hauptsache alle waren einmal dran...
 
Last edited by a moderator:
beim überschreiben von SSDs sollte man beachten, dass manche Controller die Daten vor dem Schreiben komprimieren.
Dadurch wird ein Überschreiben mit regelmäßigen Daten recht nutzlos
 
Bei SSDs werden teilweise bis zu 50% der angegebenen Speicherkapazität zusätzlich verbaut und für wear leveling und andere Funktionen genutzt. Dieser Bereich wird durch den Controller der SSD von der Aussenwelt abgeschnitten. Weder Betriebssysteme, noch irgendwelche Tools können auf diesen Bereich zugreifen. Einzig die Firmware der SSD hat darauf Zugriff und somit muss man der Firmware per ATA-Befehl sagen "Sei so nett und lösche den mir verborgenen Speicherbereich bitte.". Ob die Firmware dies dann auch wirklich macht, who knows...


Zuverlässig ist bei SSDs einzig die vollständige physische Zerstörung jedes einzelnen verbauten Chip.
 
elias5000 said:
Dagegen hilft allerdings auch bei Festplatten nur Thermit. ;)
Click to expand...

Ich mag mich hier irren aber eine Eigenschaft der meisten SSDs war doch, dass die Zellen nicht mehr beschrieben, wohl aber gelesen werden können. Bei HDDs sind wirklich kaputte Sektoren in den meisten Fällen auch nicht mehr auszulesen.
Das wäre schon ein Unterschied.

Aber - wie gesagt - ich sehe das jetzt auch nicht als großes Problem und denke, dass 08/15 Maßnahmen wie überschreiben für die allermeisten Daten ausreichen. Wer kritischere Daten hat muss die HDDs/SSDs eben physisch vernichten.
 
Alderon said:
Das Problem ist wohl, dass einzelne Zellen am Ende ihres Lebens angekommen sein können und überhaupt keine Schreibzyklen mehr verkraften.
Click to expand...
Speicherzellen, die am Ende ihres Lebens angekommen sind, zeichnen sich AFAIK hauptsächlich dadurch aus, dass sie geschriebene Daten nicht behalten. Schreiben lassen sie sich immer noch sehr gut.

Ansonsten gilt bei SSD: Habt ihr euch mal gefragt, wieso das komplette Löschen eines iPhones so schnell geht? Weil das einzige, was da gelöscht wird der interne Krypto-Key ist, mit dem die Daten verschlüsselt wurden als das Teil eingerichtet wurde.
 
Last edited by a moderator:
Die Fragestellung des "sicheren Löschens" sollte zuvor immer den Angreifer modellieren. Wovor möchte man sich konkret schützen, d.h. welche Möglichkeiten hat mein potentieller Angreifer?

a) nur logischen Zugriff, d.h. der "Nachmieter" meines Servers, der keinen physischen Zugriff auf die Platte erhält, sondern auch nur logisch mittels eines OS aus der Ferne an die Platte ran kommt

b) gegen den Hoster bzw. andere Personen die auch physischen Zugriff auf die Platte haben.


Gegen a) kann man sich leicht durch einfaches Ausnullen schützen.
Gegen b) gibt es keinen tatsächlich 100%ig wirksamen Schutz aus der Ferne. Tatsächlich wirklich 100%ig wirksam sind nur zerstörende Methoden. Methoden bei denen die Platte weiter funktionstüchtig bleiben soll bieten immer ein gewisses Restrisiko (z.B. Ersatz-Speicherzellen bei SSDs für WearLeveling, Reservesektoren für BAD-Sectors bei Spindelplatten, ...) - welches jedoch nur mit entsprechend (krimineller) Energie und Aufwand als Angreifer tatsächlich ausgenutzt werden kann.

Am Besten ist es, erst gar keine Daten im Klartext auf die Platte zu schreiben. Von der ersten Sekunde an sollten Daten immer nur verschlüsselt auf die HDD geschrieben werden - das spart Kopfschmerzen am Ende der Lebensdauer.

Nicht vergessen sollte man in diesem Zusammenhang auch, dass alle logischen Lösch-Aktionen nur so lange möglich sind, solange die Platte noch funktioniert. Ein unvorbereiteter HDD-Defekt bedeutet, dass man den logischen Zugriff auf die Platte verliert, die Daten aber physisch im Rechenzentrum bleiben.
 
gunnarh said:
Von der ersten Sekunde an sollten Daten immer nur verschlüsselt auf die HDD geschrieben werden
Click to expand...
Security by obscurity funktioniert bekanntlich nicht.
Der Schlüssel liegt hierbei entweder für jeden extrahierbar im RAM, im Filesystem oder in einem Chip. Somit ist diese "Verschlüsselung" lediglich eine Performancebremse, aber kein realer Sicherheitsgewinn...
 
Das hat nichts mit security by obscurity zu tun.

Hier geht es ja um die Festplatten, die ausgebaut wurden. Da ist es völlig egal, ob der Schlüssel noch im RAM liegt.
Für einen Neustart muss man dann halt einen entsprechend modifizierten Kernel/Bootloader haben, bei dem man das Pw per SSH eingeben muss, aber auf den Platten liegen dann keine unverschlüsselten Daten.
 
Wo liegt der "entsprechend modifizierten Kernel/Bootloader" bei den hier angenommenen Mietservern im Regelfall noch gleich? Ach ja, auf der Festplatte...

Wer sicher sein will, der kommt um eine physische Zerstörung nicht rum.


Die fehlerhaften Implementierungen fast aller Festplattenverschlüsselungslösungen lassen wir jetzt lieber mal komplett aussen vor, sonst wird es zu Off-Topic.
 
Es gibt unterschiedliche Ansätze den Schlüssel zu verwahren bzw. beim Boot zuzuführen (TPM, Smartcard, Eingabe des Schlüssels, automatisierte Abruf des Schlüssels übers Netzwerk von einer anderen Maschine, Verwahrung des Schlüssels auf einem von der HDD getrennten Medium wie z.B. einem USB-Stick, ...)

Welche Lösung praktikabel ist und das geeignete Schutzniveau bietet muss man je nach konkretem Anwendungsfall entscheiden.

Security by Obscurity (d.h. den Schlüssel auf der HDD selbst zu hinterlegen) hatte ich selbstverständlich nicht gemeint.

Für die hier diskutierten Fälle: Mietserver bei einem Hoster, Rückgabe des gemieteten Servers sowie dem Fall einer defekten HDD sind die meisten Ansätze jedoch sehr gut geeignet. Man fährt einfach die Maschine nieder, flüchtige Schlüssel im RAM werden hierbei ohnehin entladen, und die auf getrenntem Medium (TPM, Smartcard, Stick, Abruf übers LAN) verwahrten Schlüssel entfernt man. Egal wer nun als Nachmieter bzw. Käufer der Maschine auf die HDD dann logisch oder physisch zugreifen kann, derjenige hat jedenfalls keinen Zugriff auf den Schlüssel (mehr). Verbliebene Chiffrate auf der Disk sind wertlos.
 
Joe User said:
Wo liegt der "entsprechend modifizierten Kernel/Bootloader" bei den hier angenommenen Mietservern im Regelfall noch gleich? Ach ja, auf der Festplatte...
Click to expand...


Der Loader ist ja nicht das Geheimnis, das Geheimnis selbst darf natürlich nicht auf der zu schütztenden Disk liegen.

Eventuell hast Du den hier diskutierten Anwendungsfall etwas aus den Augen verloren. Wir diskutieren hier keinen Schutz des Gerätes im gebooteten Zustand (da ist Diskverschlüsselung natürlich wertlos, bei physischem Zugriff auf die Maschine kann der Schlüssel aus dem RAM extrahiert werden) - sondern wir diskutieren wie man die Maschine im Fall eines vorzeitigen Defektes oder bei regulärer Rückgabe sicher löschen kann. Und für diesen hier diskutierten Fall ist Festplattenverschlüsselung definitiv eine bequeme und ausreichend sichere Lösung.
 
Man muß bei dem ganzen auch immer beachten: SInd die Daten auf dem Server einen besonderen Aufwand wert? Und ich denke, bei den meisten, die einen Root-Server mieten, dürfte das komplette Füllen der Platte mit Nullen genau den passenden Zweck erfüllen: Die Daten auf der Platte sind nicht wiederherstellbar. Ich denke auch, das die Gefahr, daß die Daten auf der Platte in falsche Hände geraten, im laufenden Betrieb des Servers erheblich höher liegen. Und da kann man letztendlich nur hoffen, daß man eine Lücke im System (sei es ein Programmlücke, ein Konfig-Fehler oder auch nur ein schwaches Passwort) entdeckt und beseitigt, bevor sie vom Angreifer entdeckt und ausgenutzt wird.
 
elias5000 said:
Speicherzellen, die am Ende ihres Lebens angekommen sind, zeichnen sich AFAIK hauptsächlich dadurch aus, dass sie geschriebene Daten nicht behalten. Schreiben lassen sie sich immer noch sehr gut.
Click to expand...

Ich habe jetzt nochmal nachgelesen, es ist wohl so, dass die Daten tatsächlich nicht mehr zuverlässig vorgehalten werden, lesen ist allerdings immer möglich. Von daher wäre die Frage, wie viel in einer konkreten Situation überlebt hat, da der Controller der SSD von sich aus die Zelle für weitere Schreibvorgänge sperren sollte. Je nachdem in welchem konkreten Zustand sie also ist, kann sie ihre Daten also noch durchaus halten und der Controller schreibt dort einfach nicht mehr hin.

Vorhersagen kann man das aber scheinbar nicht und bei einem Langzeit SSD Test fielen einige SSDs komplett aus, andere liesen sich aber noch zuverlässig auslesen, nicht aber mehr beschreiben.

elias5000 said:
Ansonsten gilt bei SSD: Habt ihr euch mal gefragt, wieso das komplette Löschen eines iPhones so schnell geht? Weil das einzige, was da gelöscht wird der interne Krypto-Key ist, mit dem die Daten verschlüsselt wurden als das Teil eingerichtet wurde.
Click to expand...

Das hat doch aber per se erst einmal nichts mit SSDs zu tun, sondern liegt einfach daran, dass der Controller die Daten verschlüsselt schreibt. Das darunter liegende Medium ist dann ja eigentlich egal, das kann man also auch bei einer HDD so umsetzen. Diverse Lenovo Laptops bieten das ja auch an, das man im Bios einen neuen Key generiert und damit effektiv den Zugriff auf die Daten auf der HDD verhindert, unter der Annahme natürlich, dass die Implementation korrekt arbeitet, wie Joe User ja schon sagte.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top