Migration eines physikalischen Windows XP Rechnern auf einen VMware ESX-Server

VMware-Converter

Zunächst dem VMware-Converters von der VMware Homepage herunterladen (Registrierung notwendig). Dann den VMware-Converter auf der zu migrierenden physikalischen Maschine installieren. Bei der Installation nur die lokale Version auswählen (kein Client Server Modus).

Bei Gelegenheit vom physischen Host noch mit einem Keyfinder den Windows XP Product Key exportieren.

Nach Installation dann die Software starten und auf Convert klicken.

Dort „diese physische Maschine“ auswählen.

In den weiteren Fenstern bitte IP-Adresse und Zugangsdaten des ESXi-Servers eintragen.

ACHTUNG: Bitte in den Einstellungen für die VM, die erstellt wird die Netzwerkkarte so einstellen, dass diese beim Einschalten nicht verbunden wird (zur Sicherheit, um IP-Adresskonflikte zu vermeiden)!

Dann den Konvertiervorgang starten.

Hinweis zu Dauer

Die Konkrete Dauer für eine Hardware Intel Core i3 CPU mit ca. 500 GB Festplatte, von der ca. 10% belegt waren betrug ca. 2 Stunden.

Probleme mit der Windows-Aktivierung

Im Nachhinein ganz klar, dass das Windows XP durch die andersartige „Hardware“ der VMware-Virtualisierung neu aktiviert werden musste. Nach Fertigstellung ein Einschalten der Maschine wurde das Windows XP gebootet. Leider erschien direkt die Meldung, dass Windows erneut aktiviert werden muss.

Um das Problem zu lösen, habe ich die Maschine rebootet und eine Windows XP-CD als ISO File in die VMware Konsole eingebunden. Dann das migrierte VM-System ins Bios booten und schauen, dass das CD-Laufwerk als Boot-Device aktiv ist. Den Start ins Bios Setup kann man in den Einstellungen der virtuellen Maschine im Reiter „Optionen“ einstellen und dann von der CD-Booten.

Wer schnell genug ist und den Fokus in die VMware Konsole bekommt, der kann auch per Tastendruck ins Bios Setup gelangen.

„Migration eines physikalischen Windows XP Rechnern auf einen VMware ESX-Server“ weiterlesen

Sichere Passwörter und /bin/false als Shell!

Durch einen ungeschickten useradd-Befehl gepaart mit Passwort == Username, wurde mal ein Server schnell kompromittiert. Dem useradd-Befehl wurde dann auch nicht per „-s /bin/false“ keine Shell zugewiesen, sondern es wurde „/bin/sh“ per Default gesetzt. So fand jemand sehr schnell die Einstiegsluke.

In Unterverzeichnissen von /tmp wurden einige Exploit-Skripts und eine IRC-Bot-Software installiert. Unter anderem beinhaltete die Softwaresammlung auch den Bot Eggdrop.

Nachdem ich den Angreifer ausgesperrt hatte, konnte ich in der Shell-History das Vorgehen einsehen.

Sowas darf nicht passieren!

Hier die Shell-History (die IP-Adressen und Hostnamen sind geändert):

„Sichere Passwörter und /bin/false als Shell!“ weiterlesen

IP Adresse mit iptables blockieren

Mir fiel auf, dass von einer IP-Adresse sehr viele Passwortanfragen kamen, da die /var/log/auth.log Datei sehr groß wurde.

Als schnelle Lösung habe ich die IP-Adresse mit iptables blockiert.

Mit folgendem iptables-Befehl kann der Traffic einer IP-Adresse (Bsp. 1.2.3.4) komplett geblockt werden.

iptables -A INPUT -s 1.2.3.4 -j DROP

Netstat sortieren nach Foreign Portnummer

Dieser Befehl war sehr praktisch, als ein Serial-To-Ethernet Umsetzer von Perle (IOLAN STS-16) ausgetauscht werden musste. Diese Geräte werden z.B. dafür genutzt, um Laboranalygeräte an die EDV anzuschließen. Die einzelnen seriellen Leitungen werden von dem Umsetzer auf tcp-Socket 10001-100016 gemappt.

Nach dem Austausch konnte ich durch den Befehl schön beobachten, wie die einzelnen Treiber des Laborservers sich mit den Sockets verbunden hatten.

Befehl
linux$ netstat -apn | grep 110.27 | sort -t \: +2

Ausgabe
(Es konnten nicht alle Prozesse identifiziert werden; Informationen über
nicht-eigene Processe werden nicht angezeigt; Root kann sie anzeigen.)
tcp 0 0 192.168.110.35:57494 192.168.110.27:10002 VERBUNDEN 539/process-name
tcp 0 0 192.168.110.35:37240 192.168.110.27:10003 VERBUNDEN 787/process-name
tcp 0 0 192.168.110.35:36276 192.168.110.27:10004 VERBUNDEN 1031/process-name
tcp 0 0 192.168.110.35:47603 192.168.110.27:10007 VERBUNDEN 801/process-name
tcp 0 0 192.168.110.35:49051 192.168.110.27:10008 VERBUNDEN 1033/process-name
tcp 0 0 192.168.110.35:51300 192.168.110.27:10009 VERBUNDEN 1202/process-name
tcp 0 0 192.168.110.35:53143 192.168.110.27:10010 VERBUNDEN 1029/process-name
tcp 0 0 192.168.110.35:54758 192.168.110.27:10012 VERBUNDEN 927/process-name
tcp 0 0 192.168.110.35:37393 192.168.110.27:10015 VERBUNDEN 526/process-name
tcp 0 0 192.168.110.35:55052 192.168.110.27:10016 VERBUNDEN 1027/process-name

Default Login Perle IOLAN STS-16
User: iolan oder system oder su
Passwort: iolan oder system oder iolan123

Impressum

Kontakt

Steffen Berg
Fachinformatiker
Cäcilienstr. 12
42655 Solingen

Telefon: +49 172 2178497

E-Mail: steffen.berg@it-kaufmann.net

 

Haftungsausschluss (Disclaimer)

Haftung für Inhalte

Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

Haftung für Links

Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

Urheberrecht

Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.

Quelle: http://www.e-recht24.de

IPv6 in Windows deaktivieren

Der intern genutzte IPv6-Stack von modernen Windows-Versionen machte mal mit lokaler DNS-Auflösung auf Clients Probleme. Eine Software steuerte auf den Clients direkt einen LPD-Dienst an. Im Netzwerk wurde ausschließlich IPv4 genutzt, aber auf dem Client wurde intern DNS-Auflösung per IPv6 durchgeführt. So lieferte der lokale Lookup nicht den IPv4 FQDN wieder, sondern eine IPv6-Adresse.

Nur Entfernen der Bindung im Netzwerkadapter brachte nicht komplett Abhilfe.

Über die Netzwerkkarten-Eigenschaften kann man das Binding von IPv6 von einer Karte entfernen (Haken entfernen).

Man kann aber auch hart das ganze Subsystem IPv6 deaktivieren, durch setzen eines Registry-Keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents auf den Wert 0x000000ff (dezimal 255).

Aktuell gibt es von Microsoft noch die Empfehlung für komplettes Deaktiviern von IPv6 den Wert auf 0xffffffef zu setzen.

Mehr Informationen zu den genauen Mappings:
https://support.microsoft.com/de-de/kb/929852

Sysprep Windows 7 Treiber behalten

Für eine einfache Imaging-Lösung ohne WDS o.ä. wurden Master-PCs installiert. Beim ersten Sysprep-Versuch und Erstellen des Image konnten Rechner nicht nutzbar damit versorgt werden. Die Hardware-Treiber wurden entfernt. Das hat Zeit gekostet.

Durch Setzen einen Registry-Keys kann das Verhalten des Sysprep geändert werden.

Konkret wurde der Sysprep-Befehl c:\windows\system32\sysprep\sysprep.exe /oobe /generalize /shutdown verwendet.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Sysprep\Settings\sppnp

DWORD-Wert PersistAllDeviceInstalls auf 1 setzen.

Danach bleiben die Device-Treiber bei einem Sysprep erhalten