Fernwartung mal anders: Remote PowerShell

Die PowerShell durchdringt inzwischen alle Arbeitsbereiche eines Administrators. Server-Eye stellt seit dem Partnertag 2017 bereits eine umfassende Anbindung der PowerShell an unsere Cloud bereit. Alle Kernfunktionen von Server-Eye können bereits durch Skripte gesteuert werden. Wir haben auch bereits eine große Anzahl von Skripten auf https://github.com/Server-Eye/helpers bereitgestellt.

Fernwartung mit PowerShell

Auf dem Partnertag 2018 haben wir jetzt den nächsten Schritt der PowerShell Integration vorgestellt, die Remote PowerShell.

Diese neue Funktion ermöglicht es sich aus dem Browser heraus mit einer PowerShell Instance auf einem Rechner mit installiertem Sensorhub zu verbinden. Sie haben jetzt den Zugriff auf alle lokalen Cmdlets auf diesem Rechner. Diese Alternative zur klassischen Fernwartung ermöglicht oft eine schnellere Lösung der anstehenden Aufgaben.

Bespiel Remote Powershell

Als kleiner Denkanstoß was so alles möglich ist:

  • Dienste neustarten
  • Rechner neustarten
  • Temporäre Dateien löschen
  • Logdateien ansehen
  • Konfigurationsdateien bearbeiten
  • Downloads durchführen
  • AD / Exchange Benutzer anlegen
  • Ereignisanzeige einsehen
  • Software installieren und deinstallieren.

Natürlich sicher

Natürlich ist uns auch bei dem Zugriff durch die Remote PowerShell das Thema Sicherheit besonders wichtig. Um die Remote PowerShell Erweiterung nutzen zu können muss dem Techniker die entsprechende Rolle in der Rechteverwaltung zugeteilt sein.

Powershell Erweiterung

Erst wenn der Techniker im OCC eine Remote PowerShell anfordert werden auf dem Client die entsprechenden Dienste gestartet. Anders als zum Beispiel bei der Host Installation von typischer Fernwartungssoftware ist eine Verbindung nur für ca. 10 Sekunden ab diesem Zeitpunkt möglich.

Die eigentliche Verbindung erfolgt jetzt in zwei Stufen. Im sogenannten Pre-Connect Schritt werden jetzt erst Zugangsdaten für ein Administrationskonto auf dem Remote Rechner abgefragt. Erst mit diesen Zugangsdaten wird eine eigentliche PowerShell Instanz auf dem Zielrechner gestartet.

Remote Powershell Anmeldung

Die Verbindung zwischen dem Browser und der PowerShell Instanz auf dem Zielrechner erfolgt über einen speziellen Reflektordienst in der Server-Eye Cloud. Beide Verbindungen sind dabei natürlich per TLS abgesichert. Zu keinem Zeitpunkt werden die Daten, die zwischen der PowerShell Instanz und dem Browser übertragen werden, von uns gespeichert oder eingesehen.

Folgende Dinge werden allerdings gespeichert. In der Änderungshistorie des Sensorhubs wird protokolliert welcher Server-Eye User eine Verbindung aufgebaut hat. Im Windows Anwendungsprotokoll wird der Benutzername gespeichert, mit dem die PowerShell Instanz gestartet wurde.

Jetzt verfügbar

Die Remote PowerShell ist ab sofort für alle Partner freigeschaltet und kann kostenlos genutzt werden. Aktivieren Sie die Remote PowerShell einfach in den Erweiterungen und schon können Sie loslegen.

Wir bieten zur Nutzung der Remote PowerShell auch neue Webcasts an. Mehr Informationen zum Webcast gibt es hier: https://www.server-eye.de/aktuelles/webcast/

 

PS: Wir werden die Remote PowerShell natürlich weiter mit Updates und Verbesserungen versorgen. Zur Zeit gibt es allerdings folgende Einschränkungen: Der Zielrechner benötigt eine direkte Anbindung ans Internet, Proxies werden aktuell nicht unterstützt. Es werden keine Nested PowerShells unterstützt, der Befehl Connect-PSSession ist nicht verfügbar. Es werden nur zeilenbasierte Ausgaben unterstützt.


Auswirkung des DE-CIX Ausfalls

Was ist passiert?

Im Rechenzentrum FRA5 der Firma Interxion gab es in der Nacht vom 9. auf den 10. April einen massiven Stromausfall. In diesem Frankfurter Rechenzentrum befindet sich auch ein Teil der DE-CIX Systeme. DE-CIX ist der wichtigste Internetknotenpunkt in Europa. Mit über 6 Tb/s ist er der grösste Knoten der Welt.

Auch Server-Eye ist an diesen Knoten angebunden. Diese Anbindung, mit ihren vielen Peeringpartnern, sorgt dafür, dass unsere Kunden stets einen schnellen Zugriff auf die Server-Eye Cloud haben.

Natürlich ist die Verbindung nach Frankfurt nicht unser einziger Kontakt zu Aussenwelt. Fällt eine Anbindung aus, werden die Daten die eigentlich dort ankommen sollen zu einer anderen Leitung umgeroutet.

Im aktuellen Fall hat das aber leider nicht wie geplant funktioniert.

Graph vom de-cix Ausfall

In dieser Grafik sieht man, dass ca. 80% des Traffics einfach verschwinden. 20% kommen noch bei uns an. Der fehlende Traffic betrifft alle Verbindungen, die durch das Netz der Deutschen Telekom zu uns geleitet wurden. Kunden von Kabel Deutschland waren z.B. nicht betroffen.

Wir sind noch dabei mit unserem Netzwerkprovider zu klären warum das umrouten nicht funktioniert hat.

Gegen 2:30h, nach ca. 5 Stunden, war die Anbindung wieder verfügbar. Die Daten von 5 Stunden kommen jetzt alle auf einmal bei uns an.

Diese Datenmenge war zu gross. Wir verarbeiten alle eingehenden Daten streng sequentiell, schliesslich soll die OK Meldung nicht vor der Alarmmeldung kommen. Damit dies funktioniert werden alle Daten in einen FIFO Buffer (First In, First Out) gespeichert und dann daraus verarbeitet. Dieser Buffer ist in seiner Grösse begrenzt. Wir können hier ca. 2 Stunden Daten auffangen. Mit 5 Stunden war die Datenmenge allerdings mehr als doppelt so gross. Wir konnten deshalb nicht alle Werte verarbeiten und mussten einen Teil der Daten verwerfen.

Was können wir als Server-Eye tun um diesen Fehler in Zukunft besser abzufangen?

  • Wir stocken unsere Hardware nochmal um 70% der vorhandenen Leistung auf. Dadurch können wir einen deutlich längeren Buffer zur Verfügung stellen.
  • Wir optimieren unseren internen Verarbeitungsprozess um Daten noch schneller und effizienter zu verarbeiten. Hier befinden wir uns bereits in der Planung.
  • Zusammen mit unserem Netzwerkbetreiber werden wir die Anbindung an die Server-Eye Cloud optimieren.
  • Wir werden uns in Zukunft nicht mehr nur auf das Routing unsers Netzwerkbetreibers verlassen. Wir haben ein Konzept entwickelt mit dem wir den Traffic unabhängig vom Netzwerkbetreiber umleiten können.

 


WiFi oder nicht WiFi

Das Security Monster meldet sich zurück. Dieses Mal mit einem Problem für alle. In unseren modernen Welt nutzen wir eine Vielzahl von verbundenen Geräten. Wir wollen Zuhause auch im Garten online sein und in der Firma tragen wir unser Notebook von einem Raum in den anderen, möglichst ohne Kabel mitzunehmen.

In den meisten Firmen und in fast jedem Haushalt gibt es ein WLAN, damit unser Kontakt zum Internet niemals abbricht. Im Gegensatz zu einem Kabel, welches eine Punkt zu Punkt Verbindung darstellt, ist ein WLAN eher mit einem Megafon zu vergleichen. Im Prinzip kann jeder in Empfangsreichweite mithören.

KRACK

Damit niemand etwas mit diesen Daten anfangen kann nutzen alle WiFi Geräte einen Standard mit dem Namen WPA2 (Wi-Fi Protected Access => Mehr dazu bei Wikipedia).

Dieser Standard hat bis heute einen sicheren Schutz vor Mithöreren geboten. Krypto Experte Mathy Vanhoef der belgischen Universität KU Leuven hat jetzt aber einen Fehler in diesem Standard gefunden. Die Schwachstelle mit dem Namen "Key Reinstallation Attacks" (KRACK) ist auf der Seite www.krackattacks.com im Detail beschrieben.

Die Schwachstelle nutzt einen Fehler in der Spezifikation von WPA2 selbst aus. Das bedeutet, jedes WLAN Gerät, dass diesen Standard anbietet, ist betroffen. Es handelt sich nicht um einen Fehler eines bestimmten Herstellers. Alle Geräte sind betroffen.

Was kann ich jetzt tun? Soll ich WLAN komplett abschalten?

Das ist eine schwierige Frage. Ja, wenn ich 100% sicher sein will muss ich WLAN deaktivieren. Ich kann aber die Gefahr aber auch anders umgehen. Ein WLAN bei Starbucks oder im ICE ist genau so unsicher wie ein per KRACK gehacktes WLAN. Wenn ich also auf Webseiten bin die TLS einsetzten, wenn ich meine E-Mails mit sicheren Verfahren wie SMTPS oder IMAPS verschicke und abhole, oder im besten Fall sogar ein VPN nutze, dann bin ich mit einer vertretbaren Wahrscheinlichkeit sicher.

Auch Server-Eye nutzt für die intern und externe Kommunikation zusätzliche Verschlüsselungsverfahren wie TLS um auch über unsichere Medien eine sichere Verbindung aufzubauen.

Aber wie geht es jetzt weiter?

Jetzt sind alle Hersteller von Geräten gefragt die WLAN nutzen. Besonders alle Hersteller von Access Points (inklusive Router mit WLAN Funktion). Es scheint wohl möglich die Schwachstelle durch einen Fix auf der Seite des Access Points zu beheben. Behalten Sie also die Information der Hersteller der bei Ihnen eingesetzten Produkte im Auge und führen Sie das Update durch sobald es verfügbar ist.


Das Fundament macht's

Am Anfang war Server-Eye nur eine Sammlung von VBS Skripten. Heute ist Server-Eye ein komplexes System das in vielen verschiedenen Programmiersprachen umgesetzt ist.

Ein großer Teil ist in C# geschrieben, einer Programmiersprache aus dem Microsoft .NET Framework. Aktuell basieren die auf dem Client installierten Dienste auf dieser Sprache. Das .NET Framework ist wie jede andere moderne Technologie immer im Wandel. Server-Eye nutzt aktuell die Version 3.5 des Frameworks. Diese Version wurde im November 2007 veröffentlicht und wird als ".NET 3.5 SP1" in allen aktuellen Versionen von Windows noch unterstützt. (Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows 8.1 Update, Windows Server 2012, Windows Server 2012 R2, Windows 10 und Windows Server 2016)

Parallel zu der Version 3.5 existiert auch eine neue Variante des .NET Frameworks ab der Version 4.0. Diese ist allerdings nicht direkt kompatibel zur Version 3.5.

Aufbau

Das .NET Framework besteht im groben aus zwei Teilen, einer Sammlung von APIs, der .NET Framework Class Library, und einem Interpreter der den eigentlichen Programmcode ausführt. Die APIs sind eine Sammlung von Funktionen die es einem erlauben z.B. eine Datei zu lesen oder in eine Datenbank zu schreiben. Die APIs sind in Bibliotheken zusammengefasst und liegen als .DLL Dateien vor. Der Interpreter kann jetzt diese Bibliotheken und die eigentlichen Programme (.EXE Dateien) ausführen.

Der Interpreter nennt sich "Common Language Runtime" oder kurz CLR. Diese CLR stellt die Basis eines jeden .NET Frameworks da. Im .NET Framework 3.5 hat die CLR die Version 2.0 und damit die gleiche Version wie auch schon im .NET Framework 2.0 und 3.0. Diese Framework Versionen unterscheiden sich also nur durch neuen Funktionen in Form von DLLs. Im Prinzip kann ein Programm aus dem .NET Framework 3.5 auch auf einem Rechner laufen der nur das Framework 2.0 installiert hat, vorausgesetzt es werden keine Bibliotheken benutzt die es im .NET Framework 2.0 noch nicht gab.

Das .NET Framework an Version 4 setzt auf eine neue CLR, diese hat jetzt die Version 4 (eine Version 3 der CLR gab es nie).

Dieser Wechsel der CLR zwingt uns jetzt auch mit Server-Eye auf eine neuere Version des .NET Frameworks zu setzen. Neben den unzähligen Verbesserungen die durch die APIs des Frameworks dazugekommen sind, gibt es einige Änderungen der CLR die notwendig waren um für die Zukunft gewappnet zu sein. Die CLR ist unter Anderem verantwortlich für die Sicherheit, das Speichermanagement und die Threadverwaltung.

Eine bessere Threadverwaltung erlaubt es uns z.B. ein System mit mehreren CPU Kernen (also eigentlich jedes System) besser auszulasten und Aufgaben schneller und dadurch mit weniger Impact auf andere Prozesse auszuführen.

Wir haben uns entschieden als Ziel das .NET Framework 4.6 zu unterstützen. Da bedeutet eine CLR in der Version 4 und eine Class Library mindestens in der Version 4.6. Diese Version ist auch noch für ältere System wie Windows Server 2008 verfügbar.

Da heißt aber auch, dass ich ein Framework 4.7 auf meinem System installieren kann, auch dieses enthält die CLR in Version 4. Die Class Library 4.7 ist abwärtskompatibel zur Version 4.6.

Es sollte also immer die neuste 4.x Version des .NET Frameworks installiert werden.

Haben Sie noch den Überblick über alle Versionsnummern die ich bis jetzt erwähnt habe? Keine Angst auch Microsoft findet das inzwischen zu kompliziert und hat deshalb neue Versionsnummern erfunden. Ja, das haben Sie richtig gelesen um alles einfacher zu machen gibt es jetzt noch einen neuen Satz Versionsnummern.

Die Zukunft

Mit der Powershell hat Microsoft es vorgemacht. Die Powershell ist auch auf macOS und Linux-Systemen verfügbar. Das war möglich, weil die CLR und ein Teil der Class Library auf diese Systeme portiert wurden. Microsoft nennt das .NET Core. Und die aktuelle Versionsnummer davon ist 2.0.

Um jetzt ein Verhältnis zwischen .NET Core und dem .NET Framework herzustellen gibt den .NET Standard. Die höchste Version von des .NET Standards ist 1.6.

Ein Produkt, z.B. Server-Eye, dass sich an diesen .NET Standard 1.6 hält kann also auch unter .NET Core auf einem Linux Server ausgeführt werden.

Aktuell ist Server-Eye noch nicht mit .NET Standard kompatibel. Mit diesem Update legen wir aber den Grundstein dafür.

Und jetzt?

Erstmal müssen Sie gar nichts tun. Wir werden vor dem eigentlichen Update alle Kunden informieren deren System nicht die benötigte Version vom .NET Framework installiert haben. Während des Updates werden wir über die vorhandenen Windowsfunktionen eine Installation oder ein Update des .NET Frameworks anzustoßen. Erst wenn die Korrekte .NET Version installiert ist wird Server-Eye umgestellt.

Wir werden allen betroffenen Kunden vorher die Möglichkeit geben sich für die automatische Framework Installation abzumelden. Auf diesen Systemen müssen Sie dann manuell ein Update durchführen. Sobald das .NET Framework eingespielt wurde, werden diese Systeme wieder für das Server-Eye Update freigegeben.

Alle Systeme auf denen wir das automatische Update nicht einspielen konnten, werden wir Ihnen melden. Auch hier ist dann eine manuelle Installation notwendig.

Auf den allermeisten Systemen ist allerdings bereits eine passende .NET Version installiert. Auf diesen Systemen wird ein ganz normales Server-Eye Update durchgeführt.


Mehr Power(shell)

Auf unserem Partnertag haben wir vorgestellt wie man die Powershell nutzen kann um mit Server-Eye zu arbeiten. Wir waren selbst etwas überrascht wie positiv das Thema aufgenommen wurden. Danke an dieser Stelle für das konstruktive Feedback.

Neuer Aufbau

Wir werden die bereitgestellten Powershell Module auch weiterhin erweitern und stetig neue Funktionen hinzufügen. Aufgrund des Umfangs haben wir das Projekt in zwei Module aufgeteilt. Alle cmdlets die direkt eine API Funktion abbilden sind in das Module ServerEye.Powershell.API ausgelagert worden. Alle höheren Hilfsfunktionen sind im Module ServerEye.Powershell.Helper.

Mit dieser Aufteilung haben wir auch Namespaces (Prefixes) eingeführt. Vorhandene Skripte die bereits die alte Version des Modules genutzt haben müssen deshalb angepasst werden. Die API ist im Namespace SeApi und die höheren Funktionen im Namespace SE. Aus Get-Customer die direkt auf die API zugreift wurde Get-SeApiCustomer. Dadurch wurde aber auch Platz geschaffen für die Hilfsfunktion Get-SECustomer. Die API Funktion erfordert eine genau Kentniss der API, die neue Hilfsfunktion ist hier benutzerfreundlicher gestalltet.

Mit

kann ich z.B. gezielt den Kunden Systemmanager IT abrufen ohne die Kundennummer zu kennen. Und die Daten dann direkt per Pipeline direkt an das cmdlet

weitergeben und mir so aller Sensorhubs anzeigen deren Name mit "Exch" beginnt.

Die Ausgabe erfolgt in einem auf das wesentlich reduzierte Format. Natürlich geben wir trotzdem die ID der angezeigten Objekte aus, man kann also direkt weitere Daten aus der API abrufen.

Aktuell existieren folgende Hilfsfunktionen:

  • Get-SECustomer
  • Get-SESensorhub
  • Get-SESensor
  • Get-SENotification
  • Add-SENotification
  • Get-SESensorSetting

Automatische Session

Wer aufgepasst hat, hat bemerkt, dass in meinem Beispiel gar keine Session oder API Key übergeben wurde. Wir haben auch die Funktion Connect-SESession angepasst. Diese kann wie bisher genutzt werden oder mit dem Schalter -Persist. Mit Angabe dieses Schalters wird die Server-Eye Cloud Session in der lokalen Powershell Session gespeichert. Bei allen nachfolgenden Aufrufen einer Funktion aus dem Modul Helper ist keine weitere Angabe zur Authentifizierung mehr notwendig.

PS >Connect-SESession -Persist
 Windows PowerShell credential request
 Server-Eye Login
 User: andy@server-eye.de
 Password: ******
The session has been stored in this Powershell. It will remain active until you close it!
PS >Get-SECustomer
Name                CustomerId                           CustomerNumber
----                ----------                           --------------
Systemmanager IT    da7c266b-a44c-4da4-b008-6180b9c14954 1234
Exchange Company    a3ec03e9-c5aa-4735-8929-ce2a5c18744a 5678
Schulung Eppelborn  a017220d-5206-4af2-8a00-09fee755c0d0 4321

 

Die aktuellsten Informationen zum Server-Eye Powershell Helper findet man hier: http://bit.ly/SE_Helper


Server-Eye einfach mit Skripten steuern

In der Microsoft Welt führt kein Weg mehr an der PowerShell vorbei. Sei es beim Konfigurieren des Exchange Servers oder beim schnellen Skripten von Routineaufgaben. PowerShell ist überall.

Die inzwischen in der Version 5 verfügbare Shell ersetzt nicht nur die betagte cmd.exe sondern ist integraler Bestandteil vieler Serverdienst. Als mein Kollege in unserer Skype for Business Telefonanlage die Wartemusik austauschen wollte, war das sogar nur über die PowerShell möglich. Auch die grafische Verwaltungsoberfläche von Exchange erstellt eigentlich nur Skripte die dann ausgeführt werden.

Für uns als IT Profis gilt es hier am Ball zu bleiben und sich die vielen Möglichkeiten zu Nutzen zu machen. Viele Routineaufgaben werden durch den Einsatz der PowerShell schneller, einfacher und sicherer. Wer es noch nicht gesehen hat kann sich ja mal die Software von unserem Partner ScriptRunner (https://www.scriptrunner.com/ ansehen. Hier gibt es schon viele vorgefertigte Skripte für alle möglichen Routineaufgaben.

Auch Server-Eye selbst ist bereits von PowerShell durchdrungen, auch wenn Sie das vielleicht noch gar nicht gemerkt haben. Sei es unser Exchange Sensoren, die vmware Sensoren oder natürlich unser ActiveDirectory Sensoren, alle nutzen die PowerShell um ihr Aufgaben zu erfüllen.

Mehr Power für Server-Eye

Mit dem Release des ServerEye.Powershell.Helper Modules gehen wir jetzt noch einen Schritt weiter. Wir geben die Ihnen die Möglichkeit via PowerShell auf die volle Power von Server-Eye zuzugreifen. Wir stellen unsere gesamte API als cmdlets zur Verfügung.

Sie wollen alle Kunden sehen?
Get-CustomerList -Session $session " Format-Table

Sie wollen eine neue Server-Eye Gruppe anlegen?
New-Group -Session $session -Name "Server Techniker" -CustomerId 123-456-789

Oder einfach zählen in wie vielen Alarmierung Sie eingetragen sind?
Get-MyNotificationList -Session $session measure " %

Natürlich sind auch komplexere Abfragen möglich. Wie wäre es mit einer Liste aller Sensoren für die keine Alarmierung eingetragen ist?
https://github.com/Server-Eye/helpers/tree/master/SensorsOfCustomersWithoutNotifications

Mit unserem neuen Helper Modul sind Ihren Möglichkeiten keine Grenzen gesetzt. Ein paar weitere Beispiele finden Sie unter: https://github.com/Server-Eye/helpers/.

Wie das ganze Funktioniert und wie ich das ganze in meinen eigenen Skripten nutze steht hier: https://github.com/Server-Eye/helpers/tree/master/ServerEye.Powershell.Helper.

Wir haben auch unsere API Dokumentation (https://api.server-eye.de angepasst. Zu jedem Eintrag finden Sie jetzt auch den passenden cmdlet Aufruf.

Und jetzt Sie

Sie haben bestimmt noch viele Ideen was man alles machen kann. Vielleicht schreiben Sie ja ein Skript, dass jeden Tag auf Facebook postet wieviele Backups Sie geprüft haben. Gerne veröffentlichen wir Ihre Skripte auf unserer Seite.


Es ist zum Heulen – Der WannaCry Ransom-Wurm

Dieses Mal meldet sich das Security Monster zum Thema Ransomware. In den letzten Tagen hat eine neue Ransomware eine Welle der Zerstörung hinter sich hergezogen. Der Name „WannaCry“ bedeutet frei übersetzt „Es ist zum Heulen“.

Die WannaCry-Ransomware verbreitet sich über eine Schwachstelle im SMB-Protokoll von Windows, dem auf eigentlich allen Rechnern eingeschaltetem Dienst zur Dateifreigabe. Sobald ein Rechner in einem Netz infiziert wurde, verbreitet sich WannaCry als Wurm auf allen anderen erreichbaren und verwundbaren Windowssystemen. Dies macht diese Mischung aus Wurm und Ransomware so gefährlich, denn ist ein Rechner infiziert, dann sind es in kürzester Zeit alle.

Wie bei einer Ransomware üblich werden alle Daten auf den Systemen verschlüsselt und man erhält eine Meldung, dass man die Daten gegen Zahlung eines Lösegeldes entschlüsseln kann. Im Allgemeinen sollte man jedoch von dieser Zahlung absehen und die Daten selbst aus einem Backup wiederherstellen. (Ob man ein aktuelles Backup hat, kann man übrigens mit Server-Eye leicht überwachen.)

Betroffen waren unter anderem die Systeme des NHS (National Health Service) aus Großbritannien, die Systeme der Telefónica (O2), das russische Innenministerium und die Deutschen Bahn. Unser Partner Avira hat Meldungen über die Infektion aus über 90 Ländern erhalten.

Gerade der fast totale Ausfall der NHS System hat das Leben von Menschen in Gefahr gebracht, da wichtige medizinische Daten nicht mehr einsehbar war.

Da sich WannaCry als Wurm verbreitet, sah sich sogar Microsoft gezwungen einen Patch für das seit Jahren nicht mehr unterstützte Windows XP zu veröffentlichen. (Link ist am Ende des Artikels)

Dies ist allerdings als absolute Ausnahme zu verstehen, auch ist nicht ausgeschlossen, dass dieser Notfall-Patch Nebenwirkungen unter Windows XP auslöst. Es gilt daher wie schon in den letzten Jahren, alle Windows XP Systeme die einen Netzwerkzugriff haben sollten durch ein neueres System ersetzt werden. Die Gefahr, die durch ungepatchte System ausgeht, ist zu groß.

Updates, Updates, Updates

Damit sind wir auch schon beim größten Problem, ungepatchte Systeme. Die Verbreitung über SMB basiert auf einer Lücke, die im Microsoft Patch MS17-010 vom 14. März 2017 geschlossen wurde.  Das sind fast zwei Monate, in denen der Sicherheitspatch hätte eingespielt werden können.

Wir von Server-Eye können an dieser Stelle nur nochmals auf die absolute Wichtigkeit von Sicherheitsupdates hinweisen. Das Einspielen alle Sicherheitspatches ist ebenso wichtig wie der Einsatz einer Anti-Virus Lösung. (Einige Sicherheitsexperten halten Updates sogar für wichtiger als Anti-Virus.)

Schalten Sie deshalb die automatischen Updates ein oder nutzen Sie ein Patch Management. (z.B. das von Server-Eye https://www.server-eye.de/patch-management/)

Aktuell können wir zwar alle etwas aufatmen, da die Verbreitung durch den zufälligen Fund eines eingebauten Killswitches gestoppt wurde. Allerdings ist es nur eine Frage der Zeit bis die Autoren von WannaCry diesen Killswitch ausbauen oder ein anderer Wurm die gleiche Lücke ausnutzt.  Spielen Sie deshalb noch heute alle Sicherheitsupdates ein!

Was ist mit unserer Anti-Ransom Lösung, hätte die einen Angriff nicht verhindert?

Ja und nein. Der Angriffsvektor war wie so oft eine E-Mail mit einem angehängtem PDF. Anti-Ransom kann diesen Fall abfangen. Sobald allerdings eine Maschine im lokalen Netz befallen ist, kann sich der Wurm auf allen anderen Systemen ausbreiten und wird nicht von Anti-Ransom gestoppt. Die im Wurm genutzte Lücke in der Windows SMB Implementierung bedeutet, dass hier ein Sperren mit Anti-Ransom nicht möglich war.

Die Kombination macht’s, eine erste solide Abwehr durch Anti-Ransom und das Blockieren der internen Verbreitung durch das Einspielen der Sicherheitspatches. Wie so oft ist Sicherheit ein komplexes Thema und erfordert Wachsamkeit in alle Richtungen.

 

Mit freundlichen Grüßen,

Ihr Security Monster.

 

PS: Wenn Sie unser Patchmanagement nutzen, sehen Sie den Einzelpatch MS17-010 nicht, dieser ist im kumulativen Update vom März enthalten (CU2017-03).

PPS: Wer das Sicherheitsupdate immer noch nicht eingespielt hat sollte das umgehend tun.

Für Windows Vista, 7, 8.1 und 10 sowie Windows Server 2008, 2012 und 2016
https://support.microsoft.com/de-de/help/4013389/title

Für Windows XP, 2003 und Windows 8
https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/


Cloudbleed, SHA-1 Kollision und andere Monster

Unser Team hat immer ein Auge auf die aktuelle Sicherheitslage im Internet. Wer wie wir die Nachrichten verfolgt hat, hat von zwei Vorfällen rund um Sicherheit gehört. Auf diese beiden Monster will ich etwas näher eingehen.

 

 

TL;DR: Die Server-Eye Cloud Systeme sind von der Sicherheitslücke bei Cloudflare und der Kollision bei SHA-1 nicht betroffen.

Read more


Windows Server 2003 - Ein Abschied

Auch wir verabschieden uns heute offiziell von Windows 2003. Lange hast du uns gute Dienste erbracht, aber es Zeit für den Ruhestand. Mehr als 12 Jahre warst du im Einsatz. Wir hatten eine gute Zeit miteinander (Und manchmal auch keine so gute Zeit). Du hast unsere Emails transportiert, unsere Daten gespeichert, unsere Datenbanken gehostet und unsere Webseiten verwaltet. Dafür sagen wir Danke. Ich gebe zu wir waren auch nicht immer einfach und haben ab und an ganz schön über dich geflucht, aber das gehört einfach dazu.

Ich weiss du fühlst dich noch fit und könntest noch Jahre weitermachen, aber sind wir mal ehrlich, die Sicherheitsgebrechen fangen so langsam an. Lass doch die Jungen mal ran. Und Papa Satya hat auch gemeint er kann dich nicht weiter unterstützen. Lass es dir in den kommenden Jahren einfach mal gutgehen, so ganz ohne Stress, ohne die ganze Bit-Schieberei und ohne Blue Screens. Ich habe gehört XP hat inzwischen auch viel Freizeit.

Das Team von Server-Eye wünscht dir jedenfalls einen wohlverdienten Ruhestand. 

 

PS Ok, weil du es bist, bis Ende des Jahres drücken wir noch ein halbes Auge zu. Für bereits auf Windows Server 2003 installierte Sensorhubs gibt es von uns noch bis zum 31.12. Support. OCC-Connectoren auf Windows Server 2003 können von uns aber nicht mehr mit gutem Gewissen unterstützt werden. Wenn Sie Hilfe brauchen wie man den OCC-Connector auf einen anderen Server umzieht, dann schreiben Sie einfach an support@server-eye.de. --Server-Eye Team


Danke für das Beta Feedback

Gerade einmal eine Woche läuft jetzt unser öffentlicher Beta Test und 20% aller Benutzer sind bereits auf das neue OCC gewechselt. Danke.

Wir haben jede Menge positives Feedback erhalten, was uns natürlich glücklich macht. Darüber hinaus gab es auch wirklich sehr konstruktive Verbesserungsvorschläge, die wir jetzt in den nächsten Wochen noch versuchen zu integrieren.Read more