Ob das auf dem eigenen Server gegeben ist, läßt sich mit “grep -cE ‘vmx|svm’ /proc/cpuinfo” schnell herausfinden: Eine 0 bedeutet “nichts gefunden”, also Nein. Alle anderen Zahlen deuten auf einen geeigneten Prozessor hin.

Nun geht’s an das Installieren, unter Debian geht’s mal wieder ganz einfach:

apt-get install kvm

Das Paket bridge-utils brauchen wir auch, wird aber netterweise gleich mit KVM angezogen.

Das komplizierteste ist nun das einrichten der Network Bridge. Dazu müssen wir die Netzwerk-Konfiguration in /etc/network/interfaces etwas anpassen. Aus jedem eth0 müssen wir ein br0 machen (nicht bro wie brother, sondern br null ) und im Interface br0 muss dann noch die Zeile “bridge_ports eth0″ mit rein.

Vorher:

auto eth0
iface eth0 inet static
address ...

Nachher:

auto br0
iface br0 inet static
bridge_ports eth0
address ...

Das war’s auch schon. Nach einem Reboot sollte der Rechner wie gewohnt im Netz erreichbar sein, jedoch nun über das Interface br0 statt eth0. Falls nicht empfehle ich den Einsatz eines guten Rescue-Systems, sofern der Server in einem Rechenzentrum steht.

Weiter geht’s mit KVM:

Zuerst brauchen wir mal ein ISO von einer Installations-CD, das wir am besten mit WGET von Debian besorgen. Hier genügt übrigens die Mini-Winzig-Install-CD, da wir eh alles über’s Netz laden.

Danach brauchen wir noch ein Image, das im virtuellen System unsere Festplatte darstellt. Natürlich würde sich hier auch eine Partition funktionieren, doch arbeite ich hier doch lieber mit einer Image-Dateien je virtuellen Maschine, wobei meine Image-Datei immer so heißt, wie die Maschine darin.

Also, hier ein 10 GB Image File:

dd if=/dev/urandom of=/home/hostname.img bs=1M count=10k

Schneller geht es übrigens mit dem Befehl kvm-img:

kvm-img create /home/hostname.img 10G

Das Kommando erlaubt das Anlegen von großen Sparse-Files. Dabei werden die Blöcke der Datei nicht wirklich auf der Platte belegt, sondern erstmal nur Verzeichnis und Inode angelegt. Das Belegen der Blöcke im Datenbereich geschieht erst, wenn Daten dort wirklich geschrieben werden.

Dadurch ist kvm-img deutlich schneller als dd, welches ja wirklich 10 GB Datei auf Platte schreiben will. Allerdings sollte man sich darüber bewußt sein, dass das Dateisystem Schaden nehmen kann, wenn man mehr Speicher vorbelegt als bei Benutzung später vorhanden ist.

Gut, den Container haben wir und unsere Installations-CD als ISO-Datei haben wir auch. Der nächste Schritt wäre nun das Starten der virtuellen Maschine:

kvm -name Hostname -smp 1 -m 512 \
-hda /home/hostname.img \
-cdrom /home/debian-cd.iso \
-boot d \
-net nic,macaddr=00:16:3E:00:00:01 -net tap \
-vnc 0.0.0.0:0

Die virtuelle Maschine startet nun mit einem Prozessor (-smp) und 512 MB Ram (-m). Die erste Platte (-hda) ist unsere Image-Datei, als CD-Rom wurde das ISO der Debian-CD gewählt. Gebootet wird von CD-ROM (d).

Mit den beiden -net Optionen erzeugen wir eine virutelle Netzwerkkarte mit angegebener MAC-Adresse, die im Hostsystem über ein TAP-Interface mit der Bridge br0 verbunden wird. Wir haben dann also kein NAT, sondern das virtuelle System verhält sich über die Bridge so, als wäre es selbst direkt mit dem Netzwerk verbunden.

Mit -vnc wird zuletzt angegeben, dass der Bildschirm der virtuellen Maschine per VNC steuerbar sein soll. Die IP 0.0.0.0 sagt, dass der VNC auf allen IPs des Hostsystems erreichbar sein sollte, mit :0 lege ich den Standardport (5900) fest.

So, nun sollte der Zugriff per VNC über die IP-Adresse des Host-Systems möglich sein:

vncviewer kvm-host:5900

Der Installation der virtuellen Systems sollte damit nichts mehr im Wege stehen. Für den produktivbetrieb sollten jedoch einige Optionen geändert werden:

-boot c

Damit booten wir von Festplatte statt CD-Rom. Die Buchstaben c und d entsprechen übrigens nicht den Windows-Laufwerksbuchstaben, sondern c ist immer Platte, d ist immer CD-Rom. Das a steht übrigens für Floppy (anzugeben mit -fda file) und das n für Network Boot.

-vnc localhost:0

Damit sorgen wir dafür, dass nicht jeder per VNC auf unsere Maschine kommt. Diese hört jetzt nur noch auf 127.0.0.1 und kann somit problemlos sicher und verschlüsselt per SSH-Port-Forwarding angesprochen werden.

-pidfile /var/run/kvm-hostname.pid -daemonize

Damit bleibt der KVM-Prozess nach dem Start der virtuellen Maschine nicht hängen, sondern startet als Daemon im Hintergrund. Durch das PID-File läßt sich der Prozess später auch wieder finden.

Das CD-Rom kann dann für den Produktivbetrieb noch entfernt werden, fertig sieht das dann so aus:

kvm -name Hostname -smp 1 -m 512 \
-hda /home/hostname.img \
-boot c \
-net nic,macaddr=00:16:3E:00:00:01 -net tap \
-vnc localhost:0 \
-pidfile /var/run/kvm-hostname.pid -daemonize

Übrigens läßt sich so nicht nur Linux installieren, auch Windows läuft prima unter KVM als Gast.

Bei mehreren Systemen ist zu beachten, dass Name, MAC-Adresse, VNC-Port sowie Name des PID-Files je System eindeutig gewählt werden müssen. Das Windows-System (also 2. virtuelles System) würde in meinem Beispiel zur Installation also so gestartet:

kvm -name Windows -smp 1 -m 512 \
-hda /home/windows.img \
-cdrom /home/windows-cd.iso \
-boot d \
-net nic,macaddr=00:16:3E:00:00:02 -net tap \
-vnc 0.0.0.0:1

So, nun noch viel Spaß beim tüfteln mit KVM

Bei der VNC-Verbindung gibt es oft Probleme mit der deutschen Tastatur. Das liegt daran, dass das lokale System die Tastencodes bereits in deutsche Zeichen umwandelt, diese per VNC überträgt, das virtuelle System dieser wieder empfängt und in der Annahme, es sind normale Keycodes einer Tastatur, diese wieder in auf Deutsch wandelt. Die Umwandlung findet also doppelt statt.

Es gibt 2 einfache Lösungen hierfür: Entweder das lokale ODER das virtuelle System auf englischer Tastatur laufen lassen. Besser wäre der Parameter ‘-k de’ beim Start von KVM:

kvm -name [...] \
-vnc 0.0.0.0:1 \
-k de

Kommentare

• Am 8. Juni 2009 schrieb proxmox: ... oder gleich Proxmox VE nehmen - KVM auf Debian Lenny - http://pve.proxmox.com
• Am 8. Juni 2009 schrieb Mike: Danke für den Tipp. Libvirt steht in einigen Tagen als Thema an. In ca. 2 Wochen kommt dann ein Artikel, der die ganzen Themen (crypt, images, kvm, libvirv, ...) zusammenfasst. Wenn Proxmox bietet, was ich dort vorstelle (und nutze), lass ich das gerne mal ein paar Wochen auf meiner Maschine zum Test laufen...
• Am 15. Juni 2009 schrieb Butschek.de » KVM mit libvirt: [...] berichtete ich über Kernel-based Virtual Machine (KVM), welches ja per Kommandozeile sehr variabel eingesetzt werden kann, jedoch von Haus aus keine [...]
• Am 10. September 2009 schrieb Oerb: Hmm ich plag mich gerade noch mit dem Tunneln von VNC:1 - x rum. Irgend wie lüpt das nicht. Ne IDEE/ Vorschlag? :-)
• Am 10. September 2009 schrieb Oerb: Huch... jetzt passts und sieht dann so aus ssh -L 5901:XXX.XXX.XXX.XXX:5901 -4 user@server danach kann man dann am Client mit localhost:5901:1 auf die VNC:1 des KVM-SERVERS zugreifen
• Am 10. September 2009 schrieb Mike: Wenn du es mit -vnc localhost:0 gestartet hast, hört VPN auf 127.0.0.1 Port 5900 (=default, der Parameter gibt +/- vom Default an, daher 0 = default). Der Tunnel wird dann wie du es oben beschrieben hast aufgebaut, in meinem Beispiel (localhost:0) mit: ssh -L PORT:127.0.0.1:5900 user@host Wobei PORT eben der lokale Port ist. Der kann auch 5900 sein, muss es aber nicht. Bei 5900 sieht es dann so aus: -L 5900:127.0.0.1:5900

Empfohlene Themen:

• KVM mit libvirt

Wir gehen von einer normalen Debian Lenny installation aus. Ich habe sda in 3 Partitionen unterteilt: Swap (2 GB), Root-FS (10 GB) und /home (Rest). Die dritte Partition werde ich verschlüsseln.

Zuerst installieren wir die Software und laden das nötige Kernel-Modul. Dies ist beim Einrichten einmalig manuell nötig, beim späteren Öffnen des Containers wird das Modul automatisch geladen:

apt-get install cryptsetup
modprobe dm_crypt

Nun starten wir die Einrichtung:

cryptsetup luksFormat /dev/sda3

Mit luksOpen öffnen wir den verschlüsselten Bereich. Dadurch entsteht ein neues Gerät namens /dev/mapper/{name} welches das “geöffnete” /dev/sda3 repräsentiert, jedoch in nichtverschlüsselter Form. Wir benutzen also künftig /dev/mapper/{name}, wobei alles, was wir dorthin speichern transparant verschlüsselt und nach /dev/sda3 geschrieben wird.

cryptsetup luksOpen /dev/sda3 private

Wir haben der Partition also nun den Gerätenamen ‘privat’ gegeben, daher finden wir unsere lesbare “Partition” nun unter /dev/mapper/private. Nun formatieren wir die Partition:

mkfs.xfs -L sda3-priv /dev/mapper/private

Fertig, schon kann die Partition gemountet und genutzt werden:

mount /dev/mapper/private /home

Was ich an dieser Stelle gerne empfehle ist das vollständige Überschreiben der Festplatte. Beim luksFormat wird der Bereich nämlich nicht überschrieben, es wird nur der leere Index angelegt. Die zuvor unverschlüsselt gespeicherten Daten sind also noch rekonstruierbar.

Das “Ausnullen” (Überschreiben mit lauter 0×00 Bytes) vermeide ich hier, da ein Angreifer sonst verschlüsselte und unverschlüsselte Daten großer Teile der Platte kennen könnte und somit gezielt nach dem Schlüssel suchen könnte. Daher benutze ich hier /dev/urandom:

dd if=/dev/urandom of=/home/fillup.dat bs=1M
rm /home/fillup.dat

Eine interessante Sache übrigens: Das Füllen mit Zufallsdaten könnte theoretisch auch vor dem luksFormat direkt auf /dev/sda3 erfolgen, man könnte sogar annehmen, dass dies schneller geht, weil die Zufalldaten dann nicht verschlüsselt geschrieben werden müßten. Da die Verschlüsselung jedoch die Entropie der Zufallszahlen ganz vewaltig in die Höhe treibt, geht das Erzeugen von Zufallszahlen beim Überschreiben des gecrypteten Bereiches in der Tat schneller als beim Überschreiben der Platte sda3.

Meine Messwerte:

So, um die Partition nach dem Entmounten wieder zu “schließen”, also das Mapper Device wieder zu entfernen, damit nicht mehr auf die Daten zugegriffen werden kann, wird das Kommando luksClose genutzt:

umount /dev/mapper/private
cryptsetup luksClose private

Durch einen Reboot ist das Laufwerk übrigens auch geschlossen, wenn also jemand mit lokalen Zugang zum PC kein Passwort hat, wird er künftig keine Daten aus /home mehr auf dem Rechner finden, denn selbst ein Reboot mit init=/bin/bash ist nun wirkungslos.

Fertig ist das streng geheime Home-Verzeichnis – was übrigend auch mit jedem anderen Verzeichnis klappt – zumindest solange es kein System-Verzeichnis ist, welches zum Booten schon benötigt wird.

TIPP: Ein Blick ins Manual von cryptsetup ist übrigens sehr zu empfehlen. Hier wied auch verraten, wie man mit den luks*Key Kommandos mehrere Passwörter anlegen (z.B. für mehrere Leute, jeder hat SEIN Passwort) oder wie man mit Key-Files (z.B. auf dem USB-Stick) arbeiten kann. Auch Scripting ist dank isLuks und luksUUID problemlos möglich…

Empfohlene Themen:

• Loop Device Setup
• kpartx: Partition im Loop Device
• Dateien sicher löschen mit shred
• Virtuelle Maschinen mit KVM

Um dies zu verbindern gibt es Tools wie shred. Es überschreibt den Inhalt einer Datei mit Zufallsdaten und sorgt so dafür, dass eine Datei unwiederbringlich gelöscht ist. Dazu ruft man shred genauso wie rm auf, wobei es einige interessante Parameter gibt:

• Mit -v wird die ausführliche Ausgabe aktiviert. Eigentlich unnötig, aber interessant, um die Funktion zu sehen. Auch bei sehr großen Dateien ist es eventuell hilfreich, um grob zu wissen, wo das Programm gerade steckt.
• Mit -n legt man die Anzahl der Durchläufe fest, also wie oft die Daten überschrieben werden sollen. Nachdem Forensikexperte Craig Wright 2008 feststellte, dass einmaliges Überschreiben der Daten absolut genügt, sollte wir also -n1 nutzen. Alles andere verwendet nur Zeit und Strom.
• Mit -z gibt man an, dass die Datei nach dem letzten Durchlauf nochmal ausgenullt werden soll. Dies ist zwar nicht nötig, doch monkische Menschen wie ich mögen die Ordnung.
• Mit -u wird die Datei nicht nur überschrieben, sondern am Ende auch gleich gelöscht. Das spart ein nachträgliches aufrufen von rm.

In der Shell sieht das dann wie folgt aus:

# shred -v -n1 -z -u secret
shred: secret: pass 1/2 (random)...
shred: secret: pass 2/2 (000000)...
shred: secret: removed

Freien Speicher löschen

Falls eine Datei aus Versehen schon gelöscht wurde, kann man sie nicht mehr mit shred behandeln. Es hilft dann jedoch, einfach den gesamten freien Platz der Festplatte zu überschreiben. Da man den freien Platz nicht mit einem Namen ansprechen kann, legen wir einfach mit dd eine Datei an, die die ganze Platte füllt:

dd if=/dev/urandom of=/fillup.dat bs=1k

Die Angabe ohne den count-Parameter sorgt dafür, dass dd die Platte so lange mit zufälligen Daten von /dev/urandom beschreibt, bis sie voll ist. Danach kann die Daten mit rm wieder gelöscht werden: rm /fillup.dat

Partition oder ganz Festplatte löschen

Möchte man eine Partition (z.B. /dev/sda3) oder eine ganze Festplatte (z.B. /dev/sda) löschen, kann man einfach deren Gerätenamen in Kombination mit shred einsetzen:

shred -v -n1 -z /dev/...

Hier ist aber unbedingt auf korrekte Angaben zu achten, ist die falsche Partition erstmal überschrieben, gibt es kein Zurück mehr!

Einschränkungen

Moderne Dateisysteme (XFS, ReiserFS, JFS, …) speichern im Journal Daten zwischen, die auf die Festplatte geschrieben werden sollen. Dieses Journal wird von shred nicht gelöscht und kann damit unter umständen noch bereits gelöschte geglaubte Informationen erhalten.

Auch bei EXT3/4 tritt dieses Problem auf, wenn das Dateisystem mit der Option data=journal gemountet wurde. Dies läßt sich einfach durch Eingabe von ‘mount’ prüfen.

Gut, im Journal wird sich in der Praxis nach kurzer Zeit (einigen Schreibvorgängen) nicht mehr viel finden lassen. Wer dennoch auf Nummer Sicher gehen will, dem bleibt nur noch das Auslöschen der ganzen Partition, wie oben beschrieben. Damit werden nämlich nicht nur Dateien, sondern das ganze Filesystem (inkl. Verzeichnis und Journal) gelöscht.

Eine weitere Einschränkung sind die genutzten Festplatten selbst. Diese können nämlich defekte Sektoren für den Computer ausblenden und stattdessen andere, für diesen Zweck reservierte Sektoren, dorthin mappen. Somit ist es möglich, dass sich auch nach komplettem Löschen der Platte noch Informationen darauf befinden, die ein Datenretter wieder herstellen könnte.

Für alte Festplatten gilt daher: Vernichten statt verkaufen. Ein guter Vorschlaghammer genügt dafür übrigens

Kommentare

• Am 7. Mai 2009 schrieb markuman: sehr aufschlussreich :-) danke!
• Am 14. Mai 2009 schrieb linuxnetzer: Wer sich für das Thema interessiert, der sollte sich auch wipe ansehen (wipe - securely erase files from magnetic media). Die Manpage von wipe ist darüberhinaus richtig lesenswert. Hier steht einiges über die Hintergründe des Löschens und wiederherstellen von Daten. Gruß, linuxnetzer (http://www.linuxnetz.wordpress.com)
• Am 14. Mai 2009 schrieb Mike: Danke für den Tipp. Ich habe in deinem Kommentar die Verlinkung zur Manpage gleich noch aufgenommen.
• Am 15. Mai 2009 schrieb linuxnetzer: Oh, du scheinst da eine andere Version der manpage von wipe zu haben. Die Version 0.21, die ich meine enthält folgende Beschreibung: (...) DESCRIPTION Recovery of supposedly erased data from magnetic media is easier than what many people would like to believe. A technique called Magnetic Force Microscopy (MFM) allows any moderately funded opponent to recover the last two or three layers of data written to disk; wipe repeatedly overwrites special patterns to the files to be destroyed, using the fsync() call and/or the O_SYNC bit to force disk access. In normal mode, 34 patterns are used (of which 8 are random). These patterns were recommended in an article from Peter Gutmann (pgut001@cs.auck‐ land.ac.nz) entitled "Secure Deletion of Data from Magnetic and Solid- State Memory". A quick mode allows you to use only 4 passes with random patterns, which is of course much less secure. NOTE ABOUT JOURNALING FILESYSTEMS AND SOME RECOMMENDATIONS (JUNE 2004) Journaling filesystems (such as Ext3 or ReiserFS) are now being used by default by most Linux distributions. No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system. Encrypting a whole partition with cryptoloop, for example, does not help very much either, since there is a single key for all the parti‐ tion. Therefore wipe is best used to sanitize a harddisk before giving it to untrusted parties (i.e. sending your laptop for repair, or selling your disk). Wiping size issues have been hopefully fixed (I apologize for the long delay). Be aware that harddisks are quite intelligent beasts those days. They transparently remap defective blocks. This means that the disk can keep an albeit corrupted (maybe slightly) but inaccessible and unerasable copy of some of your data. Modern disks are said to have about 100% transparent remapping capacity. You can have a look at recent discussions on Slashdot. I hereby speculate that harddisks can use the spare remapping area to secretly make copies of your data. Rising totalitarianism makes this almost a certitude. It is quite straightforward to implement some sim‐ ple filtering schemes that would copy potentially interesting data. Better, a harddisk can probably detect that a given file is being wiped, and silently make a copy of it, while wiping the original as instructed. Recovering such data is probably easily done with secret IDE/SCSI com‐ mands. My guess is that there are agreements between harddisk manufac‐ turers and government agencies. Well-funded mafia hackers should then be able to find those secret commands too. Don’t trust your harddisk. Encrypt all your data. Of course this shifts the trust to the computing system, the CPU, and so on. I guess there are also "traps" in the CPU and, in fact, in every sufficiently advanced mass-marketed chip. Wealthy nations can find those. Therefore these are mainly used for criminal investigation and "control of public dissent". People should better think of their computing devices as facilities lended by the DHS. IMPORTANT WARNING -- READ CAREFULLY The author, the maintainers or the contributors of this package can NOT be held responsible in any way if wipe destroys something you didn’t want it to destroy. Let’s make this very clear. I want you to assume that this is a nasty program that will wipe out parts of your files that you didn’t want it to wipe. So whatever happens after you launch wipe is your entire responsiblity. In particular, no one guarantees that wipe will conform to the specifications given in this manual page. Similarly, we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means. So if nasties get your secrets because you sold a wiped harddisk to someone you don’t know, well, too bad for you. The best way to sanitize a storage medium is to subject it to tempera‐ tures exceeding 1500K. As a cheap alternative, you might use wipe at your own risk. Be aware that it is very difficult to assess whether running wipe on a given file will actually wipe it -- it depends on an awful lot of factors, such as : the type of file system the file resides on (in particular, whether the file system is a journaling one or not), the type of storage medium used, and the least significant bit of the phase of the moon. Wiping over NFS or over a journalling filesystem (ReiserFS etc.) will most probably not work. Therefore I strongly recommend to call wipe directly on the correspond‐ ing block device with the appropriate options. However THIS IS AN EXTREMELY DANGEROUS THING TO DO. Be sure to be sober. Give the right options. In particular : don’t wipe a whole harddisk (eg. wipe -kD /dev/hda is bad) since this will destroy your master boot record. Bad idea. Prefer wiping partitions (eg. wipe -kD /dev/hda2) is good, pro‐ vided, of course, that you have backed up all necessary data. (...)

Zuerst hole ich mir mit dd zufällige Daten, sagen wir mal 10 kByte. Diese schicke ich durch eine RegEx und entferne alle Zeichen, die nicht den gewünschten Zeichen entsprechen. Ich nehme hier im Beispiel nur Buchstaben und Zahlen. Nun muss ich nur noch dafür sorgen, dass nur so viele Zeichen wie benötigt ankommen, was ebenfalls wieder durch eine RegEx passiert.

Das Ergebnis sieht dann so aus:

dd if=/dev/urandom bs=1024 count=10 2>/dev/null \
  | perl -pe "s/[^a-zA-Z0-9]//g" \
  | perl -pe "s/^(.{12}).*$/1/g"

Nun gibt es aber einen Sonderfall, bei dem ich weitere Ausnahmen mache: Das Root-Kennwort.

Ein externer Login (via SSH) mit Passwort ist bei meinen Systemen nicht möglich (nur via Public Key). Das Passwort wird bei mir also nur benötigt, wenn ein Techniker es im Rechenzentrum lokal eingeben muss. Daher sollten alle Zeichen einfach tippbar sein, âáà sind das bei nodeadkeys meist nicht. Außerdem sollte man an die Verwechslungsgefahr denken: Der Techie mit dem Ausdruck des Passwortes in seiner Hand kann bei typischer RZ-Beleuchtung sicher keinen Unterschied zwischen | und l erkennen.

Folgende Zeichen der oben generierten Passworter erachte ich als Störend:

• Kleines Ludwig (l), großes Ida (I), die Zahl Eins (1), das Pipe-Symbol: lI1|
• Großes Otto (O), die Zahl Null (0): O0
• Das Ypselon und das Zet (weil auf US-Keyboards vertauscht)

So würde das nun aussehen, wenn wir diese Zeichen nun entfernen:

dd if=/dev/urandom bs=1024 count=10 2>/dev/null \
  | perl -pe "s/[^a-zA-Z0-9]//g" \
  | perl -pe "s/[lI1O0yYzZ]//g" \
  | perl -pe "s/^(.{12}).*$/\1/g"

Die beiden RegEx könnte man zusammenfassen, indem man schon beim ersten nur gewünschte Zeichenbereiche freigibt. Aber ich finde es so leichter lesbar und besser zu bearbeiten.

Kommentare

• Am 11. Mai 2009 schrieb Yoda: Hi Michael, ich habe es in der Vergangenheit für mich immer so gelöst: mktemp XXXXXXXX ArA17594 rm ArA17594 Wie ich finde, einfacher. Der Befehl "mktemp" ist überall vorhanden und man kann mit der Anzahl der großen "X" die Länge des Zufallswertes angeben. Da mktemp aber eine leere Datei anlegt muss man diese dann auch wieder löschen. Dieser Zufällswert genügt dem gewöhnlichen Alltagsbedarf. Wenn es dann mehrere sein sollen, dann geht das auch in einer Schleife: for (( i=1 ; i<=31 ; i++ )) ; do AAA="`mktemp XXXXXXXX`";rm $AAA;echo $AAA ; done Gruß Yoda
• Am 11. Mai 2009 schrieb Mike: Der Trick mit mktemp ist nett, hat jedoch einen großen Nachteil: Durch das mktemp landet das Passwort einmal als Verzeichniseintrag auf der Platte, durch das nachfolgende rm landet das Passwort auch noch in der Bash History. Auch wenn die History später gelöscht wird, so wurde das Passwort dennoch 2x auf Platte gespeichert. Und da gelöschte Daten in einem Dateisystem nicht immer wirklich auf Platte gelöscht / überschrieben werden, ergeben sich so 2 Angriffspunkte. Eine einfache (sicher nicht perfekte) Lösung für das Erzeugen ohne entsprechende Tools, nur mit Linux Boardmitteln wäre das hier: head /dev/urandom | md5sum

Empfohlene Themen:

• GnuPG Mini Referenz
• htaccess: Nur mit meiner IP oder Passwort…
• Partition verschlüsseln mit LUKS
• Sichere Passwörter
• Datum und Uhrzeit mit date