3. Aufteilung der Harddisk in drei Partionen: a) Betriebssystem und standard Software minimale Gr��e (NTFS) b) FAT32 Partionen mit Recovery-Tools und gesicherten Cryptschl�sseln c) Cryptpartion Echtzeitverschl�selung R/W f�r Daten �)
Was 3c) angeht: daf�r gibt es wohl CFS, das cryptographic file system bzw. StegFS. Davon bekommt der Benutzer auch nichts mit.
Das CFS setze ich bereits ein. Es gefiel mir ganz gut, da es nicht extra in den Kernel kompilliert werden brauchte und Blowfish als Verschl�sselungsalgorithmus unterst�tzt.
StegFS werde ich mir mal n�her anschauen.
4. Umbiegen tempor�rer und sonstiger Dateien (Auslagerungsdatei etc)
Die von Windows bekannte Auslagerungsdatei kommt bei Unix sowieso meist auf eine eigene, vom Benutzer nicht lesbare Partition. Im Umbiegen von tempor�ren Dateien sehe ich unter Unix keinen Sinn.
Full ACK.
5. AntiTempest Mode, HardwarekeyloggerScan, MD5-Checksummen auf die fertige und saubere Installation verbunden mit Steganographie-Elementen
Ersteres sagt mir �berhaupt nichts und zu "HardwarekeyloggerScan" h�tte ich auch gerne eine Erkl�rung. Ist das eine Hardware, die nach Keylogger-Software sucht oder umgekehrt? Und wie soll sowas funktionieren?
Tempest stellt eine Kompromittierungsmethode da, welche die Abstrahlung auf einem Kat.Strahl Monitors auch noch in ~100m als Bild darstellen kann.
Der *r�usper* Hardwarekeyloggerscan geht hin und vergleicht nur die Signallaufzeiten sowie die Stromaufnahme, welche er mit einer zuvor auf einem sauberen System angelegten Tabelle vergleicht. Somit /kann/ ein zus�tzlich installiertes "HW Add-on" entdeckt werden.
...Hat jemand soetwas oder etwas �hnliches, abgesehen von Punkt 1, bereits einem f�r ein Debian-System umgesetzt? Falls ja, w�rde es mich sehr interessieren wie.
Sollen die Sch�digungsm�glichkeiten im Falle eines Exploits beschr�nkt werden, kann man vielleicht noch root seiner Rechte berauben oder auch root umbenennen. Das grenzt aber wohl ehr an Perversion als an Paranoia - da ist ehr das rechtzeitige Einspielen von Patches/Updates angesagt. Die Security-Updates f�r Debian Stable haben wohl den Ruf sehr gut, p�nktlich und einfach durchf�hrbar zu sein.
Es geht weniger um die sch�digenden Auswirkungen eines Exploits als einfach darum, die Platte nach einem Diebstahl gesichert zu wissen. Zus�tzlich soll damit nat�rlich auch der sichere Betrieb gew�hrleistet sein, was wiederum die Rootkit Exploits einschlie�t. Damit will ich ganz bewu�t die perverse Methode, die durchaus in Banken praktiziert wird, umgehen.
Ich sehe f�r mich keine Notwendigkeit solche Ma�namen umzusetzen - was nicht heist, dass es mich nicht interessiert. Ich hoffe jedoch, ich habe dir einige gute Stichpunkte zum googlen gegeben. Interessieren w�rde mich auch noch, in was f�r einer Umgebung die so gesicherten Rechner stehen sollen.
Die Stichpunkte von Dir waren ok und an eine Umsetzung bei anderen als an meinem PC hatte ich nicht gedacht. Da hatte ich mich wohl flasch ausgedr�ckt. _Der_ Rechner steht noch in meinem Arbeitszimmer, voraussichtlich wird er genutzt werden, um von unseren dezentral laufenden Hotspot-Appliances Verbrauchsdaten/Logs zu holen sowie diese via SECSH-Protokoll als root zu administrieren. Da unsere Kunden Krankenh�user und �ffentliche Einrichtungen sind und die Appliances direkt im Netz dieser Einrichtungen integriert sind, bin ich an einem hohen Sicherheitsstandard interresiert. Ausserdem macht es mir Spa�.
Christian
Hans-Peter
-- A mainframe: The biggest PC peripheral available.
--
Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
