KNOPPIX 4.0.2 als Gast unter VMware

Gerne nehme ich den Wunsch von Burkard auf und beschreibe die Installation der aktuellen Knoppix Version als Gast unter VMware:
Mein Host-System läuft unter Debian Testing. VMware ist die Version, die in der letzten c’t mitgeliefert wurde:4.5.2 Build 8848.
Beim Anlegen des neuen Gastes wähle ich "Custom" aus, um alle Details einstellen zu können. Als Gast Betriebssystem wähle ich dann Linux (in der Version "Other 2.6.x kernel"). Da mein Host über nicht allzu viel Resourcen verfügt, kann ich meinem Gast nur 96MB zugestehen. Knoppix wird sich darüber beschweren. Doch dazu später mehr.
Die Art der Netzwerkanbindung ist Geschmackssache. Ich wähle hier mal Bridged-Networking aus.
Der SCSI-Treiber kann ruhig so als BusLogic bestehen bleiben. Ich lege eine neue Virtual Disk an. Allerdings wähle ich statt der voreingestellten SCSI Platte eine IDE Platte. Das mag zwar von der Performance in manchen Fällen schlechter sein. Falls ich aber ein System, das unter VMware lief per Image auf ein reales System übertragen will und meine Rechner eher IDE-Platten haben als SCSI-Platten, habe ich mir so ein Problem erspart.
Die Plattengröße sei nach Gutdünken gewählt. Ich nehme mal 4 GB, die aber zunächst nicht angelegt werden sollen. Das ist zwar wieder langsamer, so passt aber mehr auf meine eh immer zu kleinen Platten.
Somit ist fast alles konfiguriert. Als nächstes lade ich das ISO-File der aktuellen Knoppix Version herunter. Damit ich heute noch
fertig werde, wähle ich die CD-Fassung und nicht die DVD-Variante. Vom Plus.line-Server ist das Ding dann doch recht schnell gezogen.
Das ISO-File nehme ich dann direkt als Quelle für mein virtuelles CD-ROM-Laufwerk meines neuen Gastes. So spare ich mir einen Rohling 😉
Nun kann man den Gast starten. Da ich wie anfangs beschrieben nur recht wenig RAM habe, beschwert sich Knoppix darüber.
Also lege ich gleichmal auf /dev/hda eine Swap-Partition mit fdisk und mkswap an. Beim Neustart erkennt Knoppix diese Swap-Partition und nutzt sie auch gleich.
Nun kann ich in einem Terminal-Fenster per "sudo knoppix-installer" die Festinstallation auf der Festplatte starten.
Diese läuft im Moment. Da ich aber heute noch den Artikel posten will, tue ich das mal vorab 😉
War das jetzt alles? Nein, ich habe diverse Probleme natürlich verschwiegen 😉
Hier eine kurze Übersicht:
Mein Rechner, auf dem VMware läuft, ist nicht direkt mit Monitor und Tastatur zugänglich. Daher greife ich per über ssh getunneltes VNC darauf zu. Leider mögen sich VMware und VNC (zumindest unter Linux) nicht sonderlich. Beim Starten eines Gastes gibt es diverse Meldungen, die Ärger versprechen.
So funktioniert die Tastaturumsetzung nicht richtig. Man sucht also des öfteren nach der richtigen Taste. Als hatte ich als Ausweich NX versucht.
Dies ist eine Erweiterung des X-Protokolls, mit dem es möglich sein soll, Verbindungen zu kappen und wieder aufzunehmen, wie dies bei VNC möglich ist. Als Client gibt es auch eine freie Fassung für Windows. Leider ist die Wiederaufnahme einer Verbindung (zumindest bei mir 🙁 ) nicht immer
möglich. Aber vielleicht schreibe ich dazu später mal etwas.
Für weitere Fragen und Hinweise bin ich natürlich offen. Man freut sich doch immer über Resonanz.

Der Versuch eines Honeypots

Angeregt durch diverse Beschreibungen habe ich nun selbst einmal versucht, mit Hilfe von VMware einen Honeyot aufzusetzen.
In dieser Umgebung habe ich ein ungepatchtes Debian 3.0 aufgesetzt.
An den Honeypot werden nur die Ports 80, 443, 25, 22 und 21
weitergereicht.
Auf dem Host  läuft ein ethereal, das den ganzen Netzwerkverkehr mit schneidet.
Mal schauen, was sich dort so ergibt.

Windows XP: Arbeitsplatz „keine Rückmeldung“

Heute stehe ich vor einem Windows-Problem. Es tritt in letzter Zeit immer häufiger auf, dass sich beim Öffnen einer Dateiauswahlbox diese verabschiedet. Das öffnende Programm steht dann im Taskmanager mit dem Status "keine Rückmeldung". Auch wenn ich den Exporer öffne und auf den Arbeitsplatz zugreifen will, friert dieser ein.
Ich habe schon versucht, über ein
net use * /delete
alle Netzlaufwerke zu deaktivieren. Aber auch dies führte leider zu keinem Erfolg. Auch ein Mitschneidern des Netzwerkverkehrs auf allen Netzwerkinterfaces (das physikalische und die virtuellen von VMware) haben nichts ergeben.
Damit bin ich mit meinem "(Windows-) Latein" am Ende ….

initrd bei meinem Debian/testing Sytsem

Nachdem ich festgestellt habe, dass die meisten Zugriffe auf mein blogg über Suchmaschinen kommen, bei denen nach dem Kernel panic Problem mit der Meldung "/sbin/init: 432: cannot open dev/console: No such file" gesucht wird, habe ich mich entschlossen, mir das Problem doch nochmal genauer anzusehen.
Im Netz liest man häufig, dass das Problem beim Update auf Kernel 2.6 in Zusammenhang mit SATA-Platten auftritt, da der 2.6er Kernel die SATA-Platten als /dev/sdx Devices anspricht, der 2.4er aber noch als /dev/hdx. Daher muss man beim Update die Bezeichnungen u.a. in der /etc/fstab anpassen. Aber all dies konnte bei mir nicht dir Ursache des Problems sein, da ich zum einen nur den 2.4er Kernel verwendete und zum anderen überhaupt keine SATA-Platten einsetze. (Solche High-Tech Geräte besitze ich gar nicht … 😉
Nun gut. Ich hatte das Glück, dass ich noch einen monolothischen Kernel ohne initial Ramdisk vorliegen hatte, mit dem ich das System noch booten konnte, ohne jedesmal die Knoppix-CD bemühen zu müssen.
Also habe ich mir mal die Ramdisk angeschaut.
Mit dem Kommando
mount -t cramfs /initrd.img /mnt -o loop
kann man die Ramdisk nach /mnt mounten und sich den Inhalt anschauen.
Mir ist aufgefallen, dass in der Datei linuxrc.conf  die Zeile IDE_CORE=none
zu finden war, was mich stutzig machte.
Daraufhin habe ich mir das Erzeugen der Ramdisk mit dem Skript
/usr/sbin/mkinitrd angesehen. Dieses Skript sucht unter anderem nach den nötigen Modulen, die zum Booten des Kernel bzw. zum Zugriff auf das root-Filesystem notwendig sind. Es ist schon an den 2.6er Kernel angepasst. Daher sucht es im passenden modules-Verzeichnis nach Dateien, die auf .ko enden und auf den 2.6er Kernel hindeuten. Hat es solche Dateien gefunden, berücksichtigt es nur noch .ko-Module und keine alten .o-Module.
Bei mir haben sich nun — wie auch immer — zwei Dateien mit der Endung .ko eingeschlichen, obwohl ich doch nur einen 2.4er Kernel habe. Ich habe diese beiden Dateien gelöscht und mit
dpkg-reconfigure kernel-image-2.4.27-2-686
eine neue Ramdisk erzeugt. Und siehe da, in der Datei linuxrc.conf fand sich die Zeile:
IDE_CORE=ide-core
Und nach einem Reboot kam das System hoch, wie man es erwartet.
Dies zeigt mal wieder den Vorteil, den ein quelloffenes System hat: Ich kann, wenn ich mir nur die Zeit nehme, tief genug eindringen, um den Fehler zu analysieren und dann auch zu beheben. Auch wenn nicht bei allen, die den obigen Fehler erhalten, der Fehler auf diese falschen Dateien zurückzuführen ist, so zeige ich doch einen Weg auf, mit dem dem Fehler auf die schliche kommen kann.

Droht VMware das gleiche Schicksal wie Netscape seinerzeit?

Microsoft will angeblich in seiner "Windows Vista Enterprise Edition"
Virtual PC integrieren, so liest man zur Zeit auf heise.de.
Das erinnert doch an das (vorläufige) Ende des Netscape Browsers, als  Microsoft  seinen Internet Explorer mit dem Betriebssystem auslieferte.
Okay, die Windows Vista Enterprise Edition richtet sich an Business Kunden, so dass die Verbreitung des Virtual PC nur auf diesen Bereich erreicht wird. Aber auch VMware selbst ist sicherlich nur im Businessumfeld verbreitet. Sollte Microsoft den Support für die Gastsysteme auf Linux, Netware und BSD ausdehnen, so wird VMware sich was überlegen müssen.

Was gut ist, kommt wieder

Kriminelle lernen aus den CSI Serien in Amerika, schreibt Bruce Schneier auf seiner Seite. Das ist doch nichts Neues. Das erinnert mich nur an einen Bilderwitz, den ich vor über 25 Jahren in einer Fernsehzeitung gesehen habe. Da rief ein Vater seinen Sohn, er solle zum Fernseher kommen, schließlich laufe Schulfernsehen. Auf der Mattscheibe war Ede Zimmermann zu sehen, der sein "Vorsicht, Falle" oder Aktenzeichen ..xy präsentierte.

Willkommen in der realen Welt

Für den Firefox 1.0.6 wurde nun eine Sicherheitslücke entdeckt, die zu einem DoS oder gar zur Kompromittierung des Systems führen kann. In ihrem Security Advisory heißt es bei Secunia bei Lösungsvorschlag lapidar: Don’t browse untrusted web sites.
Bingo! Genauso gut kann man einem Patienten, der seine Praxisgebühr nicht zahlen will, auch sagen: "Dann werden Sie doch nicht krank".