Übersicht: Wichtige S.M.A.R.T Werte und Ihre Bedeutung

Im IT-Administrator 07/2014 gibt es einen guten Artikel zum Thema S.M.A.R.T Werte bei Festplatten. Da das Thema bei uns in der Firma immer mal wieder aktuell ist und vor allem die Frage im Raum steht wie man Festplatten durch Monitoring besser überwachen kann ist eine Tabelle sehr gut, die aufzeigt welche SMART Werte in der Praxis überhaupt von Relevanz sind und was sie beziehungsweise eine Änderung bedeuten. Für meine eigene Dokumentation möchte ich diese hier einmal festhalten:

 

WertBedeutung
Spin_Up_Time (ID:3)Die Zeit in Millisekunden, die der Plattenstapel beim Hochfahren benoetigt, um auf Nenndrehzahl zu kommen. Steigt dieser Wert ploetzlich an, deutet das auf ein defektes Plattenlagter oder Motorproblem hin.
Spin_Retry_Count (ID:10)Anzahl der Fehlstarts beim hochdrehen des Plattenstapels. Dreht der Plattenstapel nach kurzer Zeit nicht mit Nenndrehzahl, wird ein erneuter Startversuch unternommen. Beginnt dieser Wert ueber 0 zu steigen, deutet das auf ein defektes Plattenlager oder Motorproblem hin.
Calibration_Retry_Count (ID:11)Anzahl der Rekalibrierungsversuche. Schaffen es die Koepfe nicht, sich in der vorgegebenen (kurzen) Zeit genau ueber einer Spir zu platzieren, muss eine Rekalibrierung initiiert werden. Steigt dieser Wert, deutet das vor allem bei aelteren Laufwerken auf beginnende Probleme der Festplattenmechanik hin.
Power_On_Hours (ID:9)Anzahl der Betriebsstunden. Der Wert waechst im Laufe der Zeit und zeigt lediglich das Alter der Festplatte in Stunden (manchmal Minuten oder Sekunden) an.
Temperature_Celsium (ID:194)Aktuelle Temperatur im Laufwerk. Der Wert sollte ganz grob moeglichst im Bereich von 30°C-40°C liegen - zu warme Festplatten (>45°C) aber auch kalte Platten (<20°C) haben ein deutlich erhoehtes Ausfallrisiko.
UDMA_CRC_Error_Count (ID:199)Anzahl der fehlerhaftern Uebertragungen zwischen Festplatte und Controller. Werte ueber 0 deuten auf schlecht eingesteckte Verbindungskabel, mangelde Abschirmung oder Wackelkontakte hin. Sehr hohe Werte (mehrere tausend) koennen Ihre Ursache in einem defekten Controller-Chip haben.
Reallocated_Sector_Ct (ID:5)Anzahl der reallozierten Sektoren. Sobald ein Sektor mehrfach nicht mehr korrekt gelesen/geschrieben/geprueft werden kann, wird er in einen reservierten Bereich der Platte ausgelagert (sparse area). Dies ist ein deutliches Warnzeichen, weil es auf beginnende Oberflaechenprobleme hinweist. Beginnt dieser Wert ueber 0 zu wachsen, steht oft ein Festplattenausfall (head-crash) bevor.
Seek_Error_Rate (ID:7)Eine nicht naeher spezifizierte Rate fuer Positionierungsfehler der Schreib-/Lesekoepfe. Steigt dieser Wert, deutet das auf Probleme mit der Positionierung der Koepfe hin - Ursache koennen Servofehler, thermische Ausdehnung oder mechanische Ausfallerscheinungen sein.
(Raw_)Read_Error_Rate (ID:1)Eine nicht naeher spezifizierte Rate fuer Lesefehler. Ein steigender Wert bedeutet, dass die Oberflaeche der Platten beschaedigt ist oder die Schreib-/Lesekoepfe fehlerhaft arbeiten.
Uncorrectable_Sector_ct (ID:198)Anzahl der Versuche, fehlerhafte Sektoren ohne Erfolg zu lesen oder zu schreiben. Ein steigender Wert zeigt defekte Plattenoberflaechen oder Fehler in den Schreib-/Lesekoepfen an.
Free_Fall_Protection (ID:254) und nG-Sense_Rerror_Rate (ID:221)Wird bei Notebook-Festplatten die 'Free Fall Protection' ausgeloest (Platte befindet sich bei 0 G im freien Fall) und/oder gibt es Fehler durch zu hohe G-Raten (Vibration/Stoesse), steigen diese Werte. Das wiederum deutet auf einen sehr rauhen Umgang mit den Notebook hin.
Load_Cycle_Coung (ID:193)Anzahl der Unload/Load-Zyklen der Schreib-/Lesekoepfe. Viele (Notebook-)Festplatten parken ihre Koepfe (unload) nach wenigen Sekunden Leerlauf, um Energie zu sparen. Schreibt ein Betriebssystem wie Linux alle paar Sekunden beispielsweise eine Log-Datei, muessen die Koepfe dazu wieder 'ent-parkt' werden (load). Die maximale Anzahl von Unload-/Load-Zyklen sollte je nach Hersteller 100.000 bis 600.000 nicht ueberschreiten, waechst im obigen Szenario jedoch um ueber 100 pro Stunde. Das Unload/-Load Maximum ist so innerhalb eines Jahres erreicht. Abhilfe schafft ein Abschalten der Energiespar-Option.
Current_Pending_Sector_Ct (197)Dieser besondere Wert zeigt die aktuell nicht korrekt les- oder schreibbaren Sektoren an, die noch nicht remappt wurden. Ist ein Sektor auch nicht mit Hilfe der Fehlerkorrektur (ECC)lesbar, erhaelt er zunaechst den Status 'current pending sector'. Der Sektor wird nun aber noch nicht remapped, weil sein Inhalt (bei Lesefehlern) ja nicht bekannt ist und ein spaeterer Versuche vielleicht erfolgreich ist. Erst nach mehreren erfolglosen Lese-Versuchen wird der Sektor als fehlerhaft markiert und Reallocated_Sector_Ct (ID: 5) um den Wert 1 erhoeht. Wird andererseits schreibend auf den Sektor zugegriffen, muessen die Daten zuvor logischerweise nicht gelesen werden. Die Festplatte markiert den Sektor dann endgueltig als fehlerhaft und mapped ihn in den reservierten Bereich um.

HowTo: Backup von LUKS Headerdaten erzeugen / zurueckspielen

Heute morgen kam ich zur Arbeit und mein Rechner wollte das Passwort zum entschluesseln der mit LUKS verschluesselten Festplatten nicht mehr annehmen. Nach einer Stunde probieren aller erdenklichen Moeglichkeiten habe ich mich dann dazu entschieden den PC komplett neu aufzusetzen. Zum Glueck ist nur sehr wenig verloren.

Warum ich in der letzten Woche jeden Morgen das Passwort eingeben konnte und es heute morgen nicht mehr ging ist ein Raetsel. Vielleicht haette mir ein Backup der LUKS Headerdaten geholfen. Ich hatte aber keines, bis gerade eben.

Erzeugen:

cryptsetup luksHeaderBackup /dev/disk/by-uuid/XXXX --header-backup-file /tmp/backupname.luksheader

Wieder einspielen:

cryptsetup luksHeaderRestore /dev/disk/by-uuid/XXXX --header-backup-file /tmp/backupname.luksheader

Mehr Sicherheit fuer die eigenen Daten – vollverschluesselte Festplatten auf Servern

Dieses ist der neunte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten acht Artikeln befinden sich am Ende des Blogposts. Im neunten Teil moechte ich meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vorstellen.

Wenn ich eine verschluesselte Verbindung zu einem anderen Rechner / Dienst im Internet aufbaue kann ich das ungewollte Mitlesen der Kommunikation erschweren bis verhindern. Speichere ich nun die Daten auf eigenen Servern und vertraue sie nicht Firmen wie Google (Mail, Drive), Microsoft (Outlook.com, Skydrive) oder Amazon Cloud (Dropbox) an, dann erschwere ich auch erst einmal das ungewollte Lesen meiner Daten. Ich bin ja schliesslich kein Administrator auf dem anderen Server und weiss nicht wann sich wo auf deren Seite jemand potentiell dazwischen schaltet.

Meine Daten liegen also auf einem selbstgehosteten Server und ich baue eine verschluesselte Verbindung dahin auf. Die Daten auf dem Server selbst sind aber immer noch unverschluesselt gespeichert. Es kann also potentiell jemand ins Rechenzentrum gehen, sich den Server schnappen, analysieren und die Daten dort herunter ziehen. Was liegt da naeher als die Festplatten zu verschluesseln.

Mit LUKS (klick) steht dafuer unter Linux auch eine gute Loesung zur Verfuegung. Auf meinem Laptop oder meinem Arbeitsplatzrechner setze ich sie bereits ein. Ist ja auch kein Problem beim Booten das Passwort einzugeben. Das bei einem Server zu tun ist es schon sehr viel umstaendlicher, denn man sitzt ja eigentlich nie direkt davor…

Ich werde hier nun keine Anleitung schreiben wie man die Schritte 1:1 geht um seine Festplatte mit LUKS zu verschluesseln. Davon gibt es bereits genuegend im Netz. Einige Distributionen wie Debian bieten es sogar im Installer gleich an die Festplatte mit LVM zu erzeugen und dann mit LUKS zu verschluesseln. Die Stichworte beim Suchen nach entsprechenden Dokumentationen sind Distributionsname + „LUKS“ oder „cryptsetup“ oder „encrypted filesystem“. Nicht zu vergessen auch unter /usr/share/doc/cryptsetup/ nach zuschauen!

Der Clou an der Geschichte ist nun, das man einen dropbear SSH Server in die initramfs seines Servers hinzufuegen kann. So ist es moeglich waerend des Bootvorgangs eine SSH Verbindung in die initramfs aufzubauen und dort das Passwort zum entschluesseln der Festplatte einzugeben. Damit das ganze komfortabel wird, nutze ich dafuer SSH-Keys ohne Passwort in Verbindung mit einem Miniskript pro Maschine.

Boese boese mag sich nun mancher denken, aber alles halb so wild. Ich habe eine Maschine die ist unverschluesselt. Einfach, weil Sie es nicht benoetigt und dort nichts wichtiges abgespeichert ist. Auf dieser Maschine habe ich einen Ordner mit ecryptfs verschluesselt (klick fuer Anleitung). In diesem Ordner bewahre ich folgendes auf:

  1. private Keys fuer die Verbindung zu dem Dropbear Servern im initramfs der virtuellen Maschinen
  2. eigene known_hosts Datei dafuer
  3. Ein Skript pro VM das mir die Eingabe des Passworts erleichtert.

Das Skript sieht schematisch wie folgt aus:

#!/bin/bash
 
ssh -o "UserKnownHostsFile=known_hosts/known_hosts.initramfs" -i "keys/servername" root@1.2.3.4 "echo -ne "**TOPSECRET**" &gt;/lib/cryptsetup/passfifo"

Wenn ich nun einen Server neu starte bei dem die Festplatte verschluesselt ist, dann melde ich mich auf der unverschluesselten Maschine an, mounte den ecryptfs verschluesselten Ordner und muss dann nur noch das entsprechende Skript starten, z.B. ./unlock_servername und schon bootet die Maschine durch.

In diesem Kontext sicherlich noch einmal spannend ist auf einen drei Jahre alten Blogeintrag „Howto: virsh console“ zu verweisen um sich das ganze auch vom physikalischen Server aus anzuschauen ;-)

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.