Re: Sicherheit erh
On Tue, 26 Aug 2003 00:48:42 +0200 Hans-Peter \HP\ Weecks [EMAIL PROTECTED] wrote: zur Absicherung bestimmter Rechner unter Window$, verfolgte ich lange Zeit das untenstehende Konzept, welches ich jetzt in ähnlicher Form unter Debian Linux umsetzen will: (1. Absicherung über Bios-Passwort) 2. Pre-Boot Authentifikation Der Bootloader Lilo kann vor dem eigentlichen Booten ein Passwort abfragen. Das macht natürlich nur Sinn, wenn im (abgesicherten) Bios das Booten von anderen Medien ausgeschaltet ist. 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 ¹) Unter Unix/Linux kann jedes Verzeichnis aus einer eigenen Partition bestehen, die dann dorthin gemountet wird. Da der Verzeichnisbaum (meiner Meinung nach) wesentlich geordneter ist als bei Windows, lässt sich hier viel einfacher etwas bewerkstelligen. So können afaik bis auf /home,/tmp und /var alle Verzeichnisse read-only gemountet werden. Was 3c) angeht: dafür gibt es wohl CFS, das cryptographic file system bzw. StegFS. Davon bekommt der Benutzer auch nichts mit. 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. 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? MD5-Summen kannst du sicherlich von Debian anlegen lassen. Da man die entsprechenden Teile allerdings auch read-only mounten kann, wären die MD5-Summen nur im Falle eines Exploits von Nöten. Um sowas effektiv zu umgehen könnte man vielleicht Hardware einsetzen, die nur das Lesen von einem Gerät erlaubt. 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. Ich muß zugeben, dass ich so etwas noch nicht einmal ansatzweise umgesetzt habe. Ich bin mir auch nicht ganz im Klaren darüber, was das alles bringen soll. Bei der standard-Rechtevergabe kann der Nutzer eines Debian-Systems nur auf seine Dateien in /tmp und in seinem Homedir zugreifen, wobei die Platzbelegung afaik auch noch durch disk-quotas beschränkt werden kann. Der Benutzer hat also im Normalfall keine Möglichkeit, mehr als nur seinen Account zu beschädigen. 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. Wenn die gesicherten Daten gegen physikalischen Zugriff gesichert werden sollen, könnte CFS evtl. hilfreich sein. Bei ärgeren Befürchtungen könnte man auch diskless Clients bauen und alles NFS-mounten. 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. Christian -- 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)
Re: Sicherheit erh
On Die, 26 Aug 2003 at 22:21 (+0200), Christian Bodenstedt wrote: On Tue, 26 Aug 2003 00:48:42 +0200 Hans-Peter \HP\ Weecks [EMAIL PROTECTED] wrote: zur Absicherung bestimmter Rechner unter Window$, verfolgte ich lange Zeit das untenstehende Konzept, welches ich jetzt in ähnlicher Form unter Debian Linux umsetzen will: [...] 4. Umbiegen temporärer und sonstiger Dateien (Auslagerungsdatei etc) Was verstehst Du unter *Umbiegen*? 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. Es macht Sinn, temporäre Dateien sicher anzulegen, also mit nicht vorhersehbaren Dateinamen zu versehen (man mktemp), um race conditions zu vermeiden (Unterschieben anderer Inhalte). Wenn unter *Umbiegen* das Ändern der Verzeichnisnamen von /tmp resp. /var/tmp gemeint ist - das ist 1. security by obscurity und funktioniert nicht und wird 2. viele Programme zur Verzweiflung bringen und funktioniert also nicht. 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? MD5-Summen kannst du sicherlich von Debian anlegen lassen. Da man die entsprechenden Teile allerdings auch read-only mounten kann, wären die MD5-Summen nur im Falle eines Exploits von Nöten. Um sowas effektiv zu umgehen könnte man vielleicht Hardware einsetzen, die nur das Lesen von einem Gerät erlaubt. Für das Absichern der Konsistenz eines Systems gibt es z. B. tripwire. Zu den vielen schlimm klingenden Begriffen: Da wüsste ich auch gern, was sie bedeuten ;) Was die *Steganografie-Elemente* angeht: Was soll das bringen? Eine sichere Verschlüsselung reicht nicht? Steganografie setze ich doch nur dann ein, wenn keiner merken soll, dass da verschlüsselte Inhalte durch die Gegend fliegen (z. B. in Staaten, die starke Verschlüsselung verbieten oder key escrow vorschreiben - wie Frankreich). Sowas bremst nur, vergeudet Platz und bringt auch nicht mehr Sicherheit für die Daten. Man kann es auch übertreiben. 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. Ich muß zugeben, dass ich so etwas noch nicht einmal ansatzweise umgesetzt habe. Ich bin mir auch nicht ganz im Klaren darüber, was das alles bringen soll. Bei der standard-Rechtevergabe kann der Nutzer eines Debian-Systems nur auf seine Dateien in /tmp und in seinem Homedir zugreifen, wobei die Platzbelegung afaik auch noch durch disk-quotas beschränkt werden kann. Der Benutzer hat also im Normalfall keine Möglichkeit, mehr als nur seinen Account zu beschädigen. ACK. Ich frage mich auch, was Hans-Peter da aufbauen will. Ein High-Security-System für den BND? Der Aufwand für die Absicherung muss doch dem Grad der Schutzwürdigkeit der Daten entsprechen! 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. [...] Was soll das Umbenennen oder *root seiner Rechte berauben* bringen? Du brauchst einen User mit der ID 0 als Admin - wie der heisst ist völlig schnuppe. Umbenennen fällt auch wieder unter *security by obscurity* und funktioniert nicht. Die Rechte hängen an der ID 0 - nicht am Namen. *Gehärtete* Linux-Systeme kann man sich unter anderem bei der NSA downloaden. Jan -- 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)
Re: Sicherheit erh
Christian Bodenstedt schrieb: 5. AntiTempest Mode, HardwarekeyloggerScan, MD5-Checksummen auf die fertige und saubere Installation verbunden mit Ersteres sagt mir überhaupt nichts und zu HardwarekeyloggerScan hätte ich auch gerne eine Erklärung. Trollalarm - spar Dir die Mühe, der redet völliges Blech ... -- [EMAIL PROTECTED] -- 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)
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. -- 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)
Re: Sicherheit erh
On Tue, Aug 26, 2003 at 10:21:12PM +0200, Christian Bodenstedt wrote: [...] Sollen die Schädigungsmöglichkeiten im Falle eines Exploits beschränkt werden, kann man vielleicht noch root seiner Rechte berauben oder auch root umbenennen. Die Rechte von root sind nicht abhängig vom Namen sondern von der UID 0. Daher würde das bloße Umbenennen nicht sonderbar viel bringen. Gruß Florian pgp0.pgp Description: PGP signature
Re: Sicherheit erh
On Wed, 27 Aug 2003 02:43:07 +0200 Hans-Peter \HP\ Weecks [EMAIL PROTECTED] wrote: 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. Ok, davon habe ich schon gehört oder sowas ist zumindest denkbar. _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ß. Bei diesem Verwendungszweck macht der Aufwand auch Sinn. Christian -- 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)
Re: Sicherheit erh
On Wed, 27 Aug 2003 01:03:06 +0200 [EMAIL PROTECTED] (Jan Trippler) wrote: On Die, 26 Aug 2003 at 22:21 (+0200), Christian Bodenstedt wrote: On Tue, 26 Aug 2003 00:48:42 +0200 Hans-Peter \HP\ Weecks wrote: 4. Umbiegen temporärer und sonstiger Dateien 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. Es macht Sinn, temporäre Dateien sicher anzulegen, also mit nicht vorhersehbaren Dateinamen zu versehen (man mktemp), um race conditions zu vermeiden (Unterschieben anderer Inhalte). Da stimme ich dir zu, jedoch gehe ich davon aus, dass sich der Programmierer einer Anwendung darum kümmert (bzw. dass das gefixt wird, sobald es bekannt wird). Paranoide Leute müssten halt alle eingesetzten Programme checken. Wenn unter *Umbiegen* das Ändern der Verzeichnisnamen von /tmp resp. /var/tmp gemeint ist - das ist 1. security by obscurity und funktioniert nicht und wird 2. viele Programme zur Verzweiflung bringen und funktioniert also nicht. Etwa das meinte ich damit, dass das Umbiegen unter Unix keinen Sinn macht. Wenn ein Windows-Programm jedoch seine temporären Dateien in c:\programme\wasweisich\ anlegen will, kann das durchaus sinnig sein. Was soll das Umbenennen oder *root seiner Rechte berauben* bringen? Du brauchst einen User mit der ID 0 als Admin - wie der heisst ist völlig schnuppe. Umbenennen fällt auch wieder unter *security by obscurity* und funktioniert nicht. Die Rechte hängen an der ID 0 - nicht am Namen. Ich meine mich an eine Art Wettbewerb zwischen einem Windows- und einem Linux-Server zu erinnern, wobei es darum ging welcher der Rechner zuerst gehackt würde. Von dem Linux-Server wurde dabei afair sogar das Root-Passwort bekannt gegeben, was den Hackern allerdings nicht besonders hilfreich war. Wie das jedoch bewerkstelligt wurde weiß ich nicht. Eine Möglichkeit um root einzuschränken findet sich z.B. unter: http://www.linux-magazin.de/Artikel/ausgabe/2001/06/lids/lids.html Allerdings wird es ja auch wieder irgendwie möglich sein, diese Einschränkungen aufzuheben. Was das Umbenennen angeht: Das soll wohl bringen, dass sich potentielle Einbrecher selbst mit richtigem root-Passwort nicht als Admin einloggen können - security by obscurity. Bei Erlangung der Rechte des Nutzers mit ID 0 über einen Exploit bringt das natürlich nichts. Christian -- 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)
