Nach Upgrade auf vSphere 6 erscheint beim Verbinden mit einer virtuellen Maschine die Meldung „Failed to initialize SSL session to remote host„.
Neustarten der Maschine oder der Versuch eine alternative Verbindung herzustellen bringen keinen Erfolg.
Das Problem lässt sich aber relativ leicht lösen – einfach den entsprechenden Host neu starten und die Verbindung sollte ohne Probleme wieder funktionieren.
Ginge es nach den Mitteilungen in unseren SPAM-Ordnern, bekäme man nicht nur täglich unglaubliche Erbschaften sondern auch noch gleich die grosse Liebe frei Haus. Dass diese nicht immer ganz so einfach aufgibt und manchmal auch zur Brechstange greift zeigt folgender Artikel.
Alles Beginnt mit einem Mail das vielen bekannt vorkommen dürfte. Solche Mails erhalten wir täglich – sehen sie als offensichtlichen SPAM zum Glück aber praktisch nie.
Diese SPAM-Nachricht ist aber etwas anders; Zum einen erfolgt die Personalisierung der Nachricht nicht nur im Mail selbst (Hello…) sondern bereits in der Absenderadresse (…@bezeqint.net).
Welchen Vorteil sich der Spammer (= Evgeniya ;)) wohl davon erhofft?
Wirft man dann einen Blick in den E-Mailheader wird schnell klar, dass diese SPAM anscheinen tatsächlich über den Mailserver von Bezeqint.net (israelische Telekommunikationsgesellschaft) gesendet wurde. Der SPF-Fehler / Softfail hingegen zeigt, dass der Empfängerserver (in diesem Fall Google Apps) festgestellt hat, dass die Mailadresse beim Empfänger gar nicht existiert.
Return-Path: <[email protected]> Received: from bzq-79-176-7-**.red.bezeqint.net (bzq-79-176-7-83.red.bezeqint.net. [79.176.7.**]) by mx.google.com with ESMTP id r2si8280383lar.102.2015.04.24.06.42.37 Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 79.176.7.** as permitted sender) client-ip=79.176.7.**; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning [email protected] does not designate 79.176.7.** as permitted sender) [email protected] From: "Evgeniya" <[email protected]>
Dies hat folgende Punkte zur Folge:
Das System funktioniert in diesem Fall fast perfekt;
Nachdem man Evgeniya in Teil 1 nicht weiter beachtet hat, geht man davon aus, dass sie sich anderweitig umgesehen hat.
Leider scheint sie aber von hartnäckiger Natur zu sein und versucht es nun anstelle von Blumen mit der Brechstange. Diverse Mitteilungen „Delivery Status Notification Failure“ (=Mail gleich unzustellbar) im Posteingang zeugen von ihrem hartnäckigen Werben…
Der Inhalt derselben ist identisch mit der ursprünglichen Nachricht – mit zwei Unterschieden:
Was hat Evgeniya versucht? Nun – nichts anderes als im Namen der ersten Mail weitere „Kunden“ anzulocken. Die Mailadresse, die dabei als Absender genutzt wird ([email protected]) exisitiert nicht und wird gefälscht (sog. Spoofing).
Es ist davon auszugehen, dass auch beim nächsten Empfänger als Absender wieder eine gefälschte Phantasieadresse des Vorgänger verwendet wird.
Das entsprechende Schema dazu dürfte bekannt vorkommen; ein typisches Schneeballsystem.
Spoofing alias Evgeniyas Way of Love…
Durch die Kombination von Spoofing und Spamming wird zwar die „Erfolgsquote“ von Evgeniya drastisch sinken, andererseits gibt es dafür keinen konkreten SPAM-Mailserver bzw. SPAM-Domain die man sperren könnte. Bei jedem Versand sind andere Domains und Mailserver betroffen…raffiniert, nicht?
Problematisch an dieser Art von Spam + Spoof ist dabei nicht nur die verschmähte Liebe sondern v.a. dass durch das Spoofing leicht an sich unschuldige Dritte als Spammer gekennzeichnet werden können.
Wenn bei einer Domain keine korrekten SPF – Einträge gesetzt sind (d.h. der Empfänger kann nicht überprüfen ob die ensprechenden Mails auch vom authorisierten Absendern kommen) oder dies anderweitig überprüft wird (z.B. standardmässig mit Google Apps) wird der Absender bei ausreichender Anzahl an Beschwerden als Spammer markiert…
Um solche Fälle zu vermeiden empfiehlt sich dringend korrekte SPF-Records zu setzen. Einen entsprechenden Generator dazu gibt es etwa hier oder hier. Der so erstellte Eintrag muss anschliessend als TXT in den DNS-Einträgen der Domain hinterlegt werden.
Zwar braucht das etwas Zeit, langfristig macht man Evgeniya damit aber einen Strich durch die Rechnung…
Wer von einem Bekannten eine E-Mail mit dem Anhang fax-message876-792-093.zip erhält, tut gut daran diese nicht zu öffnen. Weder handelt es sich um einen Fax noch wurde die Nachricht in dessen Absicht versendet…
Im Gegensatz zum Artikel SPAM – Back to the Roots ist der Nachrichtentext diesmal etwas sinnvoller – wenn auch immer noch auf Englisch:
You have received fax from EPSON16843115 at ****
Besonders boshaft an dieser Version ist aber die Art der Verbreitung. Der Absender ist dem Empfänger bekannt und auch der Mailversand erfolgt über den korrekten Mailserver des Absenders. SPAM-Filter werden dadurch weitestgehend ausgehebelt. Rein technisch kommt das Mail ja vom korrekten Empfänger.
Da zum Versand der Nachricht das persönliche Adressbuch des Absenders genutzt wird, besteht von Anfang an ein Bezug zu diesem Mail – die menschliche Neugier garantiert, das ein Grossteil aller Empfänger diese Nachricht auch öffnet.
Spätestens beim Öffnen des mitgesendeten Fax müsste man misstrauisch werden. Ein Epson – Drucker der ein Fax nicht nur komprimiert und automatisch versendet, sondern daraus auch noch einen Anwendung erstellt? Erstaunlich…
Entsprechend wenig mit einem Fax hat der Inhalt dann tatsächlich zu tun. Öffnet man nämlich die komprimierte bot.exe passiert erst einmal – nichts. Also noch einmal öffnen…
Doch erst nach einigem Klicken und Drücken erscheint dann das „Fax“:
Leider handelt es sich nicht um einen Fax sondern um die Ransomware CryptoWall.
Im Gegensatz zur üblichen Ransomware, die den Computer „nur sperrt“ beginnt CryptoWall sämtliche Daten zu verschlüsseln. Eine Entschlüsselung ist nur möglich, wenn der entsprechende Entschlüsselungcode gekauft wird. Dies empfiehlt sich aber nicht!
Es gibt keine Gewissheit, dass
Die Sinnvollste Lösung ist das professionelle Entfernen des Ransomware und das Einspielen eines aktuellen Backups.
Was passiert aber eigentlich im Hintergrund?
Nachdem box.exe ausgeführt wurde, wird erst einmal der „Persönliche Verschlüsselungscode“ generiert. Die Formulierung dazu ist recht höflich gehalten („Especially for you, on our server was generated the secret key pair…“).
Schaut man sich die Netzwerkprotokolle an, wird schnell ersichtlich, dass zu Generierung der Verschlüsselung eine vorgängig gehackte WordPressite genutzt wird:
In diesem Fall handelte es sich um 9 verschiedene WordPresssites – ein Grossteil wurde wahrscheinlich bereits im Dezember 2014 über eine Sicherheitslücke im WordPressplugin RevSlider gehackt.
An diesem Punkt stellt sich dann die Frage; Kann die Verschlüsselung auch über eine solche infizierte Webseite rückgängig gemacht werden?
Leider nein – den entsprechenden Entschlüsselungscode erhält man nur über das TOR-Netzwerk – eine Rückverfolgung ist damit praktisch unmöglich.
Den bereits im letzen Artikel SPAM – Back to the Roots angesprochenen „Toten Winkel“ gibt es leider auch hier. 4 Stunden nach Erhalt der E-Mail haben 9 von 57 Antivirusscannern immer noch kein Problem mit dem File fax-message876-792-093.zip.
Wer mit diesen Schutzprogrammen unterwegs ist muss sich auf seinen gesunden Menschenverstand verlassen – oder aber verfügt über ein gutes Backup!
PS: Im Wikieintrag Cryptowall 3.0 entfernen gibts einige Tipps wie man versuchen kann Daten von einem mit Cryptowall betroffenen Computer zu retten.
Datenimporte in eine Datenbank auf Basis von Excelsheets ist immer eine lustige Sache. Inbesondere dann, wenn bspw. zusammengeführte Zellen vorhanden sind, die zwar übersichtlich, für den Import aber problematisch sind.
Das Zusammenführen in Excel ist vor allem eine grafische Angelegenheit; die oberste Zelle wird lediglich grafisch verlängert, die entsprechenden Werte (in diesem Beispiel die Wochentage) werden nicht übernommen und liegen auch nach dem Zurücksetzen der zusammengeführten Zelle immer noch nur im obersten Feld.
Für einen Import, in dem jede Zeile sämtliche Werte aufweisen muss ist dies denkbar ungünstig. Zum Glück lässt sich das aber mit ein paar Tricks lösen.
Zuerst sollten einmal sämtliche Formatierungen und zusammengeführten Zellen zurückgesetzt werden (Start > Verbinden und Zentrieren). Das Beispiel sieht dann so aus:
Anschliessend können die fehlenden Werte berichtigt werden. Dazu die entsprechende Spalte markieren.
Anschliessend auf Start > Suchen und Auswählen > Inhalte auswählen klicken und im sich öffnenden Fenster die Checkbox Leerzeilen auswählen.
Nun sollten nur noch die leeren Einträge in der Spalte A markiert sein.
Die so markierten Zellen können nun automatisch mit dem übergeordneten Wert versehen werden. Dazu einfach auf der Tastatur „=“ eingeben und die Taste aufwärts drücken. Anschliessend mit Enter + Ctrl bestätigen (Wichtig!)
Das Endergebnis, das leicht weiterverarbeitet werden kann, sollte dann in etwa so aussehen:
Nach einem Update tritt beim Öffnen einer Konsolensitzung im Webclient von vmware folgende Fehlermeldung auf:
Unable to connect to the MKS: Could not connect to pipe \\.\pipe\vmware-authdpipe wihtin retry period
Die Lösung des Problems ist zum Glück relativ einfach;
Wie man „NFC storage connection“ – Probleme in Veeam Backup and Replication 8 löst – in diesem Artikel.
Folgende Fehlermeldungen in Veeam Backup and Replication 8 treten wiederholt auf:
Getting VM info from vSphere Error: NFC storage connection is unavailable. Storage: [stg:datastore-***,nfchost:host-*,conn:******]. Storage display name: [Datastore *****]. Failed to create NFC download stream. NFC path: [nfc://conn:*****,nfchost:host-***,stg:datastore-***@****/****.vmx].
Oder:
Processing **** Error: NFC storage connection is unavailable. Storage: [stg:datastore-***,nfchost:host-***,conn:*****]. Storage display name: [Datastore ***]. Failed to create NFC download stream. NFC path: [nfc://conn:****,nfchost:host-***,stg:datastore-***@P****/****.vmx].
Das Problem tritt auf, wenn vCenter Server oder einer der ESXi – Hosts nur über eine IP-Adresse verfügt bzw. der Hostname (FQDN) nicht sauber aufgelöst werden kann. (also z.B. 192.168.1.100 anstelle von vcenter.domain.local).
Für sämtliche ESXi – Hosts sowie den vCenter Server müssen (meistens manuell) ein statischer DNS A-Name Record sowie ein entsprechender Pointer erstellt werden!
Anschliessend sollte das Problem behoben sein.
Um in Windows Server 2012 R2 Core die Eingabesprache von English auf Deutsch (Schweiz) zu ändern, wie folgt vorgehen:
In Powershell folgendes eingeben:
Set-WinDefaultInputMethodOverride "0807:00000807"
Anschliessend in der Registry (in Powershell einfach „Regedit“ eingeben…) zu
HKCU\Keyboard Layout\Preload
navigieren und „Value 1“ auf 00000807 setzen.
Sämtliche anderen Values können gelöscht werden.
TAPI Treiber korrekt zu installieren bzw. zu konfigurieren kann mühsam sein – insbesondere wenn mehrere Benutzer eingerichtet werden müssen. Das folgende Beispiel mit einer AGFEO Telefonanlage soll zeigen, dass mittels Gruppenrichtlinien auch dann die einzelnen Parameter individuell eingestellt werden können, wenn der Hersteller eine „einfache Netzwerkinstallation“ eigentlich gar nicht vorgesehen hat…
Im folgenden Beispiel war die Ausgangslage recht unkompliziert. Lediglich der AGFEO – Server (Bindeglied zwischen Telefonanlage und TAPI – Bereitstellung) wurde migriert. Manuell müsste nun aber auf jeder einzelnen Arbeitsstation die Konfiguration angepasst werden – etwas mühsam…
Ein etwas speditiverer Lösungweg führt über die Gruppenrichtlinienverwaltung der Domäne. Da dabei auch Registry – Einträge der einzelnen Arbeitsstationen angepasst / erstellt werden können, kann praktisch jede Software beliebig „massenangepasst“ werden.
Einzige Bedingung dafür ist, dass der Aufbau bzw. Lageort der entsprechenden Einträge im Voraus bekannt ist. In folgendem Fall konnte nach einer manuellen Anpassung der Software und anschliessender Auslesung der Registry (Tipp: den zu ändernden Begriff mit einem Platzhalter z.B. PLATZHALTER833 ersetzen, anschliessend die Registry mit F3 nach diesem Wort durchsuchen) die nötigen Infos gefunden werden:
Beispiel AGFEO TAPI Driver:
Der Pfad in der Registry lautet:
HKEY_LOCAL_MACHINE\SOFTWARE\AGFEO\TSP7\7.0\Net
Dabei sind folgende Einträge von Bedeutung:
"Pwd"="PASSWORD" "Host"="HOST" "Usr"="USERNAME "Port"=dword:000013d9
Hinweis: Der Eintrag Port wird als DWORD gespeichert, was nichts anderes als der hexadezimale Wert des Ports ist (5081). Eine schnelle Umrechnung Hex <–> Dec ermöglicht z.B. der Hex to Decimal Converter
Die so ermittelten Parameter können anschliessend über die Gruppenrichtlinienverwaltung individuell, schnell und zielgerichtet im Netzwerk verteilt werden. Dabei kann auch hier wieder mit Parametern gearbeitet werden (z.B. für Benutzernamen des TAPI – Treibers automatisch den Windowslogin verwenden –> %username%).
Wenn die Richtlinie einmal erstellt wurde, sind zukünftige Anpassungen oder aber auch automatische Neuzuweisungen (bei Benutzer/Arbeitsplatzwechsel) mit relativ wenig Aufwand verbunden.
Probleme beim Konsolidieren von Snapshots? Meldung „msg.fileio.lock“? So behebt man das Problem…
Die Mitteilung in VMware vCenter „Die Festplatten der virtuellen Maschine müssen konsolidiert werden“ können normalerweise per Rechtsklick auf die jeweilige Maschine >> Snapshots >> Konsolidieren beseitigt werden.
Leider kommt es aber ab und zu vor, dass dann die Meldung „Fehler beim Konsolidieren der Festplatten: msg.fileio.lock.“ erscheint.
Meist liegt die Ursache an einem der mittlerweile so zahlreich vorhandenen Backuplösungen, die noch in irgendeiner Form auf die VMs zugreift oder z.B. durch einen Systemausfall „hängengeblieben“ ist. Ein Reboot des Backuplösung löst das Problem daher meistens.
Um einen Client einer Domäne hinzuzufügen muss man eine Reihe von Anforderungen erfüllten. Selbes Netzwerk, die richtigen DNS-Einstellungen,etc. Wie man dasselbe offline erledigen kann – hier die korrekten Schritte.
Das Vorgehen ist schnell erklärt. Auf dem Domänencontroller führt man ein kleines Skript aus und generiert ein Textdokument. Dieses kann dann (z.B. per Mail) an den Client gesendet werden der sich damit dann offline an die Domäne anbinden kann.
Eingabeaufforderung (CMD) öffnen und folgende Befehle eingeben:
djoin /provision /domain “DOMÄNE” /machine “NAME” /savefile c:/djoin.txt
Anschliessend „taucht“ der Client auch bereits im ActiveDirectory auf.
Hinweis: DOMÄNE = Name der Domäne, NAME = Computername
Das generierte Textfile djoin.txt befindet sich unter C:\.
Das File kopieren und auf den Client verschieben (z.B. per E-Mail, USB-Stick…)
Das oben generierte Textfile djoin.txt in C: kopieren.
Anschliessend Eingabeaufforderung ausführen (als lokaler Admin!) und folgende Befehle eingeben:
cd c:\ djoin /requestODJ /loadfile djoin.txt /windowspath %systemroot% /localos
Fertig – Der Client wurde der Domäne hinzugefügt!