[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sicherheit erh



Christian Bodenstedt wrote:

 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.



Reply to: