Gestern wurde Firefox 51 pünktlich zum geplanten Releasetermin veröffentlicht. Die erste Version im Jahr 2017 ist genau zehn Wochen nach Firefox 50 erschienen und bringt viele kleine, aber sinnvolle Änderungen mit.
Nachfolgend wie immer ein kurzer Überblick zu den wichtigsten Neuerungen. Wer es ausführlicher haben möchte sollte bei Sören Hentzschel vorbei schauen.
Warnung vor unverschlüsselter Passwortübertragung (HTTP-Seiten die ein Passworteingabeformular nutzen werden nun als unsicher markiert)
Warnung bei Zertifikaten mit unsicherer SHA-1-Signatur
Zertifikate von den Zertifizierungsstellen (CA) Wosign und Startcom, die nach dem 21. Oktober 2016 ausgestellt wurden, werden nicht mehr akzeptiert
vor kaputten Zertifikaten mit SHA-1-Signatur sowie jenen von Wosign und Startcom
Abspielen von FLAC-Dateien ohne Plugins möglich
WebRTC unterstützt nun den VP9-Codec
Unterstützung für WebGL 2 (ermöglicht eine bessere Videowiedergabe ohne GPU)
unter Linux wird zum Rendern von 2D-Inhalten die Grafik-Bibliothek Skia eingesetzt
die mit Firefox 17 eingeführte Social-API wurde fast komplett entfernt (bis auf den Teilen-Button)
Zoom-Stufe ist in der Adressleiste sichtbar, wenn sie nicht 100 % beträgt. Ein Klick darauf setzt die Größe auf 100 % zurück.
Unterstützung von IndexedDB 2.0
Im Info-Dialog wird angezeigt, ob es sich um eine 32-Bit- oder eine 64-Bit-Version von Firefox handelt
Vor wenigen Tagen habe ich meinen Artikel “Windows 7: Update dauert ewig oder findet nichts” veröffentlicht, in dem ich das Problem der langsamen Update-Suche unter Windows 7 erkläre und eine Lösung aufzeige. Offensichtlich tritt das Problem auch unter Windows 8.1 auf, allerdings nicht so häufig. Könnte aber auch damit zusammenhängen, dass Windows 8.1 einen deutlich geringeren Marktanteil aufweist und man deshalb einfach weniger darüber liest und hört.
Das Problem ist identisch wie unter Windows 7. Die Suche nach Windows Updates dauert ewig und die Meldung “Es wird nach Updates gesucht…” erscheint und möchte nicht mehr verschwinden. Dazu ist oftmals eine hohe CPU-Last auf einem Kern feststellbar. Wer an ein paar Infos an der Ursache interessiert ist, kann in meinem Artikel zu Windows 7 nachlesen.
Nachdem mich ein Leser für Hilfe bei Windows 8.1 gefragt hat, hier die Schritte zur Problembehebung.
Lösung
Auch für Windows 8.1 bietet Microsoft ein Update an, welches das Problem durch eine neue Version für Windows Update beheben soll.
Als Voraussetzung für die Installation dieses Updates muss zuerst ein Update des Servicing Stacks (KB3021910) installiert werden.
Vor der Installation muss der “Windows Update” Dienst beendet werden. Dies macht ihr am besten direkt über “Dienste” oder alternativ über die Eingabeaufforderung und den Befehl “net stop wuauserv”.
Jetzt könnt ihr das “April 2015 servicing stack update” KB3021910 herunterladen. Alternativ wäre auch das “July 2016 servicing stack update” KB3173424 möglich.
Update installieren und PC anschließend neu starten.
Jetzt folgt das oben erwähnte „Update für Windows Update“, welches Teil des „July 2016 update rollup“ KB3172614 ist. Der Download ist direkt im Windows-Update-Katalog möglich.
Zur Installation muss der “Windows Update” Dienst ein weiteres Mal beendet werden.
Update installieren und PC anschließend neu starten.
Jetzt könnt ihr manuell nach Updates suchen und nach einigen Minuten solltet ihr alle verfügbaren Updates für euer System sehen.
Falls immer noch keine Updates gefunden werden könnt ihr noch folgende Dinge ausprobieren:
Komponentenspeichers reparieren Eine administrativen Eingabeaufforderung starten und folgende Befehle nacheinander eingeben:
Windows Update Einstellungen zurücksetzen Windows Update in der Systemsteuerung öffnen und links auf “Einstellungen ändern” klicken. Im Dropdown-Menü wählt ihr dann “Nie nach Updates suchen (nicht empfohlen)” aus und klickt auf OK. Anschließend öffnet ihr die Einstellungen erneut und stellt zurück auf “Updates automatisch installieren (empfohlen)” und klickt auf OK.
Spätestens jetzt sollten die Updates wieder schneller gefunden werden.
Seit geraumer Zeit beschweren sich Benutzer von Windows 7 und teilweise auch Windows 8.1, dass die Windows Update-Suche nicht mehr richtig funktioniert. Die Suche dauert extrem lange oder findet überhaupt keine Updates. In diesem Artikel möchte ich euch das Problem und die Ursache genauer erklären und selbstverständlich auch eine Lösung aufzeigen.
Problembeschreibung
Bei der Suche nach Windows Updates werden keine Updates gefunden oder sie dauert unheimliche lange. Windows zeigt lediglich den Hinweis an: “Es wird nach Updates gesucht…”. Teilweise vergehen viele Stunden, bis irgendetwas gefunden wird. Während der Suche sind gleichzeitig eine hohe CPU-Last (100 % auf einem Kern) und ein angestiegener RAM-Verbrauch durch “svchost.exe” feststellbar.
Das Problem existiert seit Juli 2015 und tritt vor allem unter Windows 7 SP1 auf, wobei aber auch Nutzer von Windows 8.1 betroffen sind. Im Internet finden sich zahlreiche Foren-Threads mit entsprechenden Fragestellungen. Viele Nutzer sind verzweifelt und wissen nicht mehr weiter. Insbesondere nach einer Neuinstallation von Windows 7 tritt der Fehler häufiger auf.
Ursache
Oftmals liest man, dass eine langsame Internetverbindung oder die Microsoft-Server Ursache des Problems sein sollen. Dies ist definitiv nicht der Fall! Das Kernproblem der langsamen Windows Update-Suche ist vielmehr auf den komponentenbasierten Ansatz (CBS, Component-Based Servicing) mit .MSU-Paketen zurückzuführen. Kurz gesagt ist die Suche und Installation von Updates so komplex geworden, dass die Prüfung von bereits installierten Updates, von benötigten neuen Updates und von Abhängigkeiten einfach ewig dauert. Dadurch wird auch die oben beschriebene hohe CPU-Last erzeugt.
Winfuture hat mittlerweile einen eigenen Fix veröffentlicht, welcher die benötigten Updates zur Behebung des Fehlers automatisch in der richtigen Reihenfolge installiert. Da diese Variante deutlich unkomplizierter und schneller ist, solltet ihr auf jeden Fall einen Blick darauf werfen: WinFuture UpdateFix für Windows 7
Microsoft hat das Problem erkannt und hat ein Update für Windows Update veröffentlicht, welches das Problem in fast allen Fällen behebt. Folgendermaßen müsst ihr vorgehen.
Als Voraussetzung für die Installation des oben genannten Updates muss zuerst ein anderes Update (KB3020369) installiert werden.
Vor der Installation muss der “Windows Update” Dienst beendet werden. Dies macht ihr am besten direkt über “Dienste” oder alternativ über die Eingabeaufforderung und den Befehl “net stop wuauserv”.
Update installieren und PC anschließend neu starten.
Jetzt folgt das oben erwähnte “Update für Windows Update”, welches Teil des “July 2016 update rollup” KB3172605 ist. Hier ist der Link für Windows 7 x64 und hier für Windows 7 x86.
Der “Windows Update” Dienst muss hierfür ein weiteres Mal beendet werden.
Update installieren und PC anschließend neu starten.
Jetzt könnt ihr manuell nach Updates suchen und nach spätestens einigen Minuten solltet ihr alle verfügbaren Updates für euer System sehen.
Mit dem Feature-Update auf Windows 10 Version 1511 hatten einige User das Problem, dass die Netzwerkverbindung und damit auch das Internet nicht mehr richtig funktionierte. Da das Problem offensichtlich vereinzelt immer noch existiert, nachfolgend ein kleiner Troubleshooting-Guide.
Problembeschreibung
Vor wenigen Tagen konnte ich dasselbe Problem auf einer Test-VM mit Windows 10 feststellen. Von heute auf morgen bekam ich beim Versuch eines Netzwerkzugriffs folgenden Fehler:
Fehlercode 0x80070035 Der Netzwerkpfad wurde nicht gefunden.
Also habe ich die Diagnose geöffnet, welche auch direkt ein Problem gefunden hat:
Auf diesem Computer fehlt mindestens ein Netzwerkprotokoll.
Automatische Reparatur hilft nur manchmal
Anschließend habe ich wie empfohlen die Reparatur ausgeführt. Damit ließ sich der Fehler beheben und das Netzwerk funktionierte wieder ohne Probleme. Am nächsten Tag tauchte der Fehler erneut auf und die Reparatur konnte dieses Mal keine Abhilfe schaffen. Eine kurze Internetrecherche zeigte schnell auf, dass viele User mit diesem Problem zu kämpfen hatten. Glücklicherweise existieren weitere Lösungsansätze.
Bug in Windows 10 Version 1511
Das Problem wurde durch einen Bug in Windows 10 Version 1511 verursacht, welcher laut Microsoft mit dem 2. kumulativen November-Update KB3120677 behoben worden sein sollte. Das scheint aber nicht für alle User zu gelten. In diesem Forenthread bei Microsoft wurde ein Workaround gepostet, der teilweise zu funktionieren scheint.
Netzwerk zurücksetzen
Dazu muss der Geräte-Manager geöffnet, dort im Menü auf “Ansicht” geklickt und die Option “Ausgeblendete Geräte anzeigen” aktiviert werden. Anschließend müsst ihr alle Netzwerkadapter löschen (Rechtsklick auf das Gerät und Option Deinstallieren auswählen) und dann das System neustarten.
Zusätzlich könnt ihr dann noch den TCP-IP-Stack des Netzwerkadapters zurücksetzen. Hierfür muss die Eingabeaufforderung mit Adminrechten gestartet werden. Dann den Befehl “netsh winsock reset” eingeben, mit der Eingabetaste bestätigen und den PC erneut durchstarten.
Sonstige Lösungsmöglichkeiten
Sollte das Netzwerk immer noch nicht funktionieren, solltet ihr weitere Dinge überprüfen.
Zuerst einmal sollten die Netzwerk- bzw. WLAN-Treiber auf die neueste Version aktualisiert werden. Ohne Internet ist das natürlich schwer, weshalb ihr die Treiber am besten mit einem anderen Gerät von der Herstellerseite herunterlädt und dann auf den problembehafteten PC überträgt.
Anschließend sollten die Firewall-Einstellungen von den diversen All-In-One-Security-Lösungen geprüft werden, sofern solche zum Einsatz kommen. Wer ganz sicher gehen möchte sollte diese komplett deinstallieren und anschließend auch das Lösch-Tool des Herstellers ausführen. Ebenso sollten Virenscanner entfernt werden, da diese oft eigene Filtertreiber mitbringen, welche das Problem verursachen könnten.
Wer die eingebaute Windows-10-Firewall einsetzt, sollte die Einstellungen zurücksetzen. Dazu einfach die Windows-Firewall öffnen und auf der linken Seite auf den Link “Standard wiederherstellen” klicken (siehe Screenshot). Die Änderungen werden nach einem Neustart wirksam.
Ich hoffe, dass euch der ein oder andere Tipp helfen und euer Problem damit behoben werden konnte.
Nach mehr als 13 Jahren Entwicklung wurde der beliebte Open Source Video-Transcoder am Heiligabend in Version 1.0.0 veröffentlicht. Gestern wurde dann bereits Version 1.0.1 nachgeschoben. Neben vielen Neuerungen existiert nun auch eine ausführliche Dokumentation.
Die neue Online-Dokumentation ist weniger technisch gehalten und soll einfach verständlich sein. Unter anderem beschreibt sie Schritt für Schritt den Prozess zum Transkodierung von Videodateien und ist deshalb auch für Einsteiger geeignet. Aktuell steht sie jedoch nur in englischer Sprache zur Verfügung.
Zu den weiteren Neuerungen gehören überarbeitete Presets, welche eine bessere Kompatibilität gewährleisten und mehr Geräte abdecken sollen. Des Weiteren sind auch einige komplett neue Presets für neue Geräte oder das Web hinzugekommen. Presets sind Voreinstellungen, welche das Konvertieren in verschiedene Formate bzw. für verschiedene Abspielmedien (iPhone, Apple TV, Xbox, usw.) deutlich vereinfachen. Zudem wird der neue VP9-Codec und Ultra-HD Color Passthrough mit BT.2020-Farbraum unterstützt. Ebenso ist ein Quicksync-H.265/HEVC-Encoder mit an Bord, welcher jedoch erst ab einer Intel Skylake CPU verwendet werden kann. Die Audio-Passthru-Funktion unterstützt nun E-AC-3, FLAC und TrueHD. Außerdem gab es diverse kleine Änderungen unter der Haube und kleine Anpassungen an der Programmoberfläche für Mac und Windows. Das komplette Changelog zur neuen HandBrake-Version findet ihr bei Github.
Die Open Source-Software ist für Windows, macOS und sogar Linux zu haben.
Active Directory-Based Activation (ADBA) ist die neueste Möglichkeit aus dem Hause Microsoft zur Volumenaktivierung von Produktlizenzen. ADBA wurde zusammen mit Windows 8 bzw. Windows Server 2012 eingeführt und stellt neben KMS (Key Management Service) und MAK (Multiple Activation Key) eine dritte Aktivierungsmöglichkeit dar. Nachdem ich KMS und MAK bereits in meinem Artikel “Microsoft Produktaktivierung – MAK vs. KMS” vorgestellt habe, folgt nun ein genauerer Blick auf das Active Directory-Based Activation.
Wie der Name schon vermuten lässt, kann ADBA nur Systeme aktivieren, die mit der Domäne verbunden sind. Die Aktivierung erfolgt vollautomatisch beim Domain-Join und ist wie bei der KMS-Aktivierung für 180 Tage gültig. Eine Reaktivierung erfolgt automatisch, sofern das System mit einem Domain Controller (DC) kommunizieren kann. Ein Aktivierungs-Threshold von mindestens 25 Computern wie bei KMS existiert bei ADBA nicht. Damit ist die neue Methode auch für kleinere Umgebungen mit einer geringen Anzahl an Systemen vorteilhaft.
ADBA funktioniert erst ab Windows 8 bzw. Windows Server 2012 bzw. Office 2013. Selbstverständlich werden auch neuere Betriebssysteme wie Windows 8.1, Windows 10, Windows Server 2012 R2 und Windows Server 2016 unterstützt. Auch Office 2016 funktioniert problemlos. Bei älteren Versionen wie Windows 7, Windows 2008 R2 oder Office 2010 muss die Aktivierung weiterhin via KMS oder MAK erfolgen.
Aus diesem Grund werden die meisten Unternehmen auf einen Parallelaufbau mit ADBA für die neuen und KMS für die alten Systeme setzen. Sobald keine alten Systeme mehr verwendet werden, kann der KMS-Host abgeschaltet werden.
Nachfolgend die wichtigsten Vorteile von ADBA gegenüber KMS:
Aktivierung erfolgt nahezu ohne Zeitverzögerung direkt beim Domänen-Join
Aktivierung erfolgt Forest-weit (bei KMS sind hierzu in jeder Domäne zusätzliche DNS-Einträge notwendig)
keine Mindestanzahl von 25 Computern wie bei KMS
ein Server weniger zum Administrieren und Updaten, sobald KMS-Host abgeschaltet werden kann
Einrichtung von Active Directory-Based Activation
Einzige Voraussetzung ist, dass Active Directory bereits auf das Schema-Level von Windows Server 2012 (Version 56) aktualisiert wurde. Anschließend kann die Aktivierung über Active Directory eingerichtet werden, was nur wenige Minuten dauern sollte. Bei Microsoft gibt es zwei ausführliche Anleitungen mit weiteren Informationen:
Das Active Directory Schema definiert die Datenbank des Verzeichnisdienstes. In der AD-Datenbank werden Datensätze als “Objekte” bezeichnet und deren Eigenschaften (Datenfelder) als “Attribute”. Das Schema legt also fest, welche Objektklassen und Attribute im AD existieren.
Mit jedem neuen Betriebssystem führt Microsoft neue Features ein, welche gleichzeitig oft auch neue Klassen und Attribute im Active Directory voraussetzen. Bei der Aufnahme eines Domänencontrollers (DC) mit einer neuen Betriebssystemversionen muss daher das AD-Schema aktualisiert werden. Aus diesem Grund ist die Active Directory Schema Version standardmäßig auch immer so aktuell, wie der neueste DC.
Windows Server Version
Active Directory Schema Version
Windows 2000
13
Windows Server 2003
30
Windows Server 2003 R2
31
Windows Server 2008
44
Windows Server 2008 R2
47
Windows Server 2012
56
Windows Server 2012 R2
69
Windows Server 2016
87
Unabhängig davon existieren einige Möglichkeiten, um die aktuelle Active Directory Schema Version herauszufinden.
DSQuery
Via DSQuery kann die Schema Version über die Eingabeaufforderung angezeigt werden:
dsquery * CN=Schema,CN=Configuration,DC=EXAMPLE,DC=DOMAIN -Scope Base -attr objectVersion
Mit dem Tool “repadmin” kann der Status des Attributes über alle DCs hinweg abgefragt werden. Damit kann beispielsweise die Replikation bei einer Schemaerweiterung überprüft werden.
Heute bin ich auf das Tool Remote Display Analyzer gestoßen, welches ich euch nicht vorenthalten möchte. Das Tool fungiert quasi als Real-Time-Monitoring zu bestehenden RDP-Verbindungen und zeigt nützliche Infos an.
Bisher war der Remote Display Analyzer nur für das Citrix HDX-Protokoll erhältlich. Vor einigen Wochen wurde eine spezielle Version für das RDP-Protokoll bzw. RemoteFX veröffentlicht. Das Tool besteht aus einer EXE-Datei und kann ohne Installation sowie portabel verwendet werden. Es muss auf dem Zielrechner gestartet werden, während eine RDP-Verbindung aufgebaut ist. Einzige sonstige Voraussetzung ist ein installiertes .NET Framework 4.0.
Der Remote Display Analyzer zeigt unter anderem den verwendeten Anzeigemodus (RemoteFX oder RDP), die für die Verbindung genutzten Protokolle (TCP oder UDP oder beide) und die zur Verfügung stehende Bandbreite zwischen Client und Host. Darüber hinaus werden die aktuell verwendete Bandbreite und die Latenzzeit angezeigt (siehe Screenshot). Die weiteren Features sind nur in der “Sponsored Version” verfügbar, welche mit einer einmaligen Zahlung an den Entwickler erworben werden kann. Hier stehen erweiterte Statistiken zum Paketfluss, zum Paketverlust, zu den gesendeten Frames und zum verursachten Traffic zur Verfügung.
Das nächste Feature-Upgrade für Windows 10 (Version 1703) hört auf den Namen “Creators Update” und wird höchstwahrscheinlich Ende März oder Anfang April 2017 erscheinen.
Eine interessante Neuerung ist, dass Microsofts Edge Browser zukünftig eBooks im populären EPUB-Format nativ anzeigen kann. Bei den Windows 10 Insider Builds hielt das neue Feature erstmals mit Build 14971 Einzug. Neben der reinen Anzeige kann auch die Schriftgröße, die Schriftart und das Design des “Readers” angepasst werden. Darüber hinaus kann Edge das Inhaltsverzeichnis anzeigen und zeigt unten den Lesefortschritt der EPUB an. Des Weiteren lassen sich Lesezeichen setzen und es existiert eine Suchfunktion.
Wer nur ab und zu ein EPUB-Datei betrachten möchte sollte mit den Features des Edge Browsers auskommen und kann fortan auf eine extra App oder Anwendung verzichten.
Gestern fand der letzte Microsoft Patchday für dieses Jahr (Dezember-Patchday) statt. Insgesamt veröffentlichen die Redmonder zwölf Security-Bulletins, von denen sechs als “kritisch” und sechs als “hoch” eingestuft werden. Wie fast jeden Monat werden auch dieses Mal wieder kritische Sicherheitslücken bei den beiden Browsern Internet Explorer 11 und im neuen Edge-Browser behoben.
Nachfolgend ein kurzer Überblick über die erscheinenden Bulletins und die betroffenen Produkte. Weitere Details stellt Microsoft wie immer im Security TechCenter zur Verfügung.
Bulletin ID
Bulletin Title
Maximum Severity Rating and Vulnerability Impact
Restart Requirement
Affected Software
MS16-144
Kumulatives Sicherheitsupdate für Internet Explorer (3204059)
Critical Remote Code Execution
Requires restart
Internet Explorer unter allen unterstützten Versionen von Microsoft Windows.
MS16-145
Kumulatives Sicherheitsupdate für Microsoft Edge (3204062)
Critical Remote Code Execution
Requires restart
Microsoft Edge unter allen unterstützten Versionen von Windows 10 und Windows Server 2016.
MS16-146
Sicherheitsupdate für Microsoft-Grafikkomponente (3204066)
Critical Remote Code Execution
Requires restart
Alle unterstützten Versionen von Microsoft Windows.
MS16-147
Sicherheitsupdate für Microsoft Uniscribe (3204063)
Critical Remote Code Execution
Requires restart
Alle unterstützten Versionen von Microsoft Windows.
MS16-148
Sicherheitsupdate für Microsoft Office (3204068)
Critical Remote Code Execution
May require restart
Microsoft Office 2007, Office 2010, Office 2013, Office 2013 RT, Office 2016, Office Compatibility Pack, Excel Viewer, Word Viewer, Office für Mac 2011, Office 2016 für Mac, Auto Updater für Mac, SharePoint Server 2007, SharePoint Server 2010 und Office Web Apps 2010.
MS16-149
Sicherheitsupdate für Microsoft Windows (3205655)
Important Elevation of Privilege
Requires restart
Alle unterstützten Versionen von Microsoft Windows.
MS16-150
Sicherheitsupdate für den sicheren Kernelmodus (3205642)
Important Elevation of Privilege
Requires restart
Alle unterstützten Versionen von Microsoft Windows 10 und Windows Server 2016.
MS16-151
Sicherheitsupdate für Windows-Kernelmodustreiber (3205651)
Important Elevation of Privilege
Requires restart
Alle unterstützten Versionen von Microsoft Windows.
MS16-152
Sicherheitsupdate für Windows Kernel (3199709)
Important Information Disclosure
Requires restart
Alle unterstützten Versionen von Microsoft Windows 10 und Windows Server 2016.
MS16-153
Sicherheitsupdate für den Treiber für das gemeinsame Protokolldateisystem (3207328)
Important Information Disclosure
Requires restart
Alle unterstützten Versionen von Microsoft Windows.
MS16-154
Sicherheitsupdate für Adobe Flash Player (3209498)
Critical Remote Code Execution
Requires restart
Microsoft Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10 und Windows Server 2016.
MS16-155
Sicherheitsupdate für .NET Framework (3205640)
Important Information Disclosure
Requires restart
Microsoft .NET Framework 4.6.2 unter unterstützten Versionen von Microsoft Windows 7, Windows Server 2008 R2, Windows Server 2012, Windows 8.1, Windows Server 2012 R2 und Windows 10.
Als ich heute auf zwei kürzlich installierte Server mit Windows Server 2016 geschaut habe, ist mir aufgefallen, dass bei beiden Servern die letzten Updates nicht installiert wurden. Der Download der Updates vom WSUS-Server hängt bei 0% (siehe Screenshot) und verändert sich auch nicht. Wieder mal ein Update, welches sich nicht über WSUS verteilen lässt, danke Microsoft! Ein kurzer Blick in den Eventviewer zeigte zudem auf, dass der “Update Orchestrator Service for Windows Update” und der “Windows Update Service” fast stündlich abgestürzt sind.
Nach einer kurzen Internetrecherche bin ich auf eine identische Fehlerbeschreibung bei Reddit gestoßen. Die vorgeschlagene Lösung brachte auch bei meinen beiden Servern Erfolg: Das letzte kumulatives Update für Windows Server 2016 (KB3200970) muss manuell von Hand installiert werden, danach funktioniert wieder alles. Den Download findet ihr im Windows Update-Katalog.
Darüber hinaus bin ich auf weitere Berichte gestoßen, die über enorme Probleme mit dem KB3200970-Update klagen. Es existieren viele Fälle, bei denen das Update während der Installation hängen bleibt oder mit diversen Fehlern komplett abbricht.
Fast wöchentlich wird in den Medien über neue DDoS-Angriffe (Distributed Denial of Service) berichtet. Ziel der Angreifer ist es, eine mutwillige Überlastung von Diensten oder Webseiten herbeizuführen. Dies geschieht mit einer sehr großen Anzahl von Anfragen, wobei die Infrastruktur überlastet wird und reguläre Anfragen nur noch extrem langsam oder gar nicht mehr beantwortet werden können. Heutzutage kommt für diesen Zweck in der Regel ein Botnetz zum Einsatz, welches aus einer Vielzahl von ferngesteuerten PCs und bzw. oder aus IoT-Geräten (Internet of Things) besteht.
Eine weitaus effizientere Methode für DDoS-Angriffe besteht darin, Programmfehler auszunutzen und eine Fehlfunktion des Systems auszulösen. Im Falle von BlackNurse kann schon ein einziger PC ausreichen, um Firewalls, Router oder Server lahmzulegen. Sicherheitsforscher des dänischen Netzbetreibers TDC haben den sogenannten BlackNurse-Angriff entdeckt. Am 10. November 2016 wurde der Angriff veröffentlicht und die Webseite http://blacknurse.dk mit weiteren Informationen online gestellt.
Bei BlackNurse handelt es sich um eine ICMP-Attacke. Herkömmliche Ping-Flood-Angriffe basieren auf ICMP Type 8 Code 0 Paketen. Black Nurse hingegen setzt auf ICMP Type 3 Code 3 Pakete. Einzige Voraussetzung für einen Angriff ist, dass das Zielsystem ICMP-Type3-Code3 erlaubt. Schon ein einzelner Angreifer mit einer Bandbreite von 15-18 Mbit/s kann die notwendigen 40.000 – 50.000 Pakete pro Sekunde erzeugen, um Zielsysteme stark zu beeinträchtigen. Genauer gesagt steigt die CPU-Last auf dem Zielsystem so stark an, dass normale Anfragen nicht mehr bearbeitet werden.
Von BlackNurse sind einige Systeme betroffen, darunter auch Firewalls von namenhaften Herstellern wie Palo Alto Networks, Cisco, Dell oder Fortinet. Nicht betroffen sind hingegen Systeme von Check Point, WatchGuard, Juniper oder die in Deutschland weit verbreiteten FRITZ!Box-Router von AVM.
Prinzipiell kann jeder eine solche Attacke fahren, da zur Durchführung nur wenig technische Kenntnisse notwendig sind. Benötigt wird lediglich das Tool “Hping3“, welches z.B. schnell und einfach unter Ubuntu installiert und genutzt werden kann. Die entsprechenden ICMP-Type3-Code3-Pakete können folgendermaßen erstellt und an das Zielsystem gesendet werden:
Morgen (zweiter Dienstag im Monat) findet Microsofts November-Patchday statt. Insgesamt veröffentlicht der Softwareriese 14 Security-Bulletins, von denen sechs als “kritisch” und acht als “hoch” eingestuft werden. Wie fast jeden Monat sind auch dieses Mal wieder kritische Sicherheitslücken bei den beiden Browsern Internet Explorer 11 und im neuen Edge-Browser vorhanden.
Nachfolgend ein kurzer Überblick über die erscheinenden Bulletins und die betroffenen Produkte. Weitere Details stellt Microsoft wie immer im Security TechCenter zur Verfügung. Üblicherweise funktioniert der Link erst ab Dienstagabend deutscher Zeit.
Bulletin ID
Bulletin Title
Maximum Severity Rating and Vulnerability Impact
Restart Requirement
Affected Software
MS16-129
Kumulatives Sicherheitsupdate für Microsoft Edge (3199057)
Critical Remote Code Execution
Requires restart
Microsoft Edge on all supported releases of Windows 10 and Windows Server 2016.
MS16-130
Microsoft Security Bulletin MS16-130: Sicherheitsupdate für Microsoft Windows (3199172)
Critical Remote Code Execution
Requires restart
All supported releases of Microsoft Windows.
MS16-131
Sicherheitsupdate für Microsoft-Videosteuerung (3199151)
Critical Remote Code Execution
Requires restart
Microsoft Windows Vista, Windows 7, Windows 8.1, Windows RT 8.1, Windows 10, and Windows Server 2016.
MS16-132
Sicherheitsupdate für Microsoft-Grafikkomponente (3192884)
Critical Remote Code Execution
Requires restart
All supported releases of Microsoft Windows.
MS16-133
Sicherheitsupdate für Microsoft Office (3199168)
Important Remote Code Execution
May require restart
Microsoft Office 2007, Office 2010, Office 2013, Office 2013 RT, Office 2016, Office for Mac 2011, Office 2016 for Mac, Office Compatibility Pack, Excel Viewer, PowerPoint Viewer, Word Viewer, SharePoint Server 2010, SharePoint Server 2013, Office Web Apps 2010, and Office Web Apps 2013.
MS16-134
Sicherheitsupdate für den Treiber des gemeinsamen Protokolldateisystems (3193706)
Important Elevation of Privilege
Requires restart
All supported releases of Microsoft Windows.
MS16-135
Sicherheitsupdate für Windows-Kernelmodustreiber (3199135)
Important Elevation of Privilege
Requires restart
All supported releases of Microsoft Windows.
MS16-136
Sicherheitsupdate für SQL Server (3199641)
Important Elevation of Privilege
May require restart
Microsoft SQL Server 2012, SQL Server 2014, and SQL Server 2016.
MS16-137
Sicherheitsupdate für Windows-Authentifizierungsmethoden (3199173)
Important Elevation of Privilege
Requires restart
All supported releases of Microsoft Windows.
MS16-138
Sicherheitsupdate für virtuelle Festplatte von Microsoft (3199647)
Important Elevation of Privilege
Requires restart
Microsoft Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.
MS16-139
Sicherheitsupdate für Windows Kernel (3193227)
Important Elevation of Privilege
Requires restart
Microsoft Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.
MS16-140
Sicherheitsupdate für Boot Manager (3193479)
Important Security Feature Bypass
Requires restart
Microsoft Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.
MS16-141
Sicherheitsupdate für Adobe Flash Player (3202790)
Critical Remote Code Execution
Requires restart
Adobe Flash Player on all supported editions of Microsoft Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows RT 8.1, Windows 10, and Windows Server 2016.
MS16-142
Kumulatives Sicherheitsupdate für Internet Explorer (3198467)
Critical Remote Code Execution
Requires restart
Internet Explorer on all supported releases of Microsoft Windows.
Lange und komplexe PowerShell-Skripte werden schnell unübersichtlich und man verliert den Überblick, wo das Skript gerade steht und was aktuell abgearbeitet wird. Aus diesem Grund solltet ihr in jedem Skript bereits von Anfang an eine einfache Log-Funktionalität einbauen. Dies ist in vielen Fällen schneller und einfacher zu realisieren, als das Logging später aufwändig nachzurüsten. Vor allem bei Skripten, welche kritische Daten schreiben, ist das Logging im Nachhinein oftmals ein Segen. Beispielsweise wenn euer PowerShell-Skript Daten im AD ändert und im Nachgang einige Änderungen rückgängig gemacht werden müssen.
Daher habe ich eine kleine Funktion geschrieben, welche ich nahezu am Anfang jedes PowerShell-Skripts einbinde. Die Ausgabe erfolgt sowohl in der Konsole als auch in einer Log-Datei. Neben dem aktuellen Datum und der Uhrzeit ermöglicht die Log-Funktion zudem die Definition von verschiedenen Log-Leveln.
Auch wenn der Einsatz von Windows Server 2016 noch nicht geplant ist, sollten Unternehmen ihre Infrastruktur dahingehend aktualisieren, dass eine Aktivierung von Windows Server 2016 grundlegend möglich ist. Da das neue Server-Betriebssystem nun offiziell erhältlich ist, lässt der erste Test-Server sicherlich nicht lange auf sich warten und der produktive Einsatz kommt meist auch schneller als gedacht.
Active Directory-Based Activation (ADBA) ist die einfachste Variante, lässt sich schnell einrichten und wird von Microsoft empfohlen. Wer dennoch weiterhin auf die KMS-Aktivierung setzt, hat es schwieriger und muss einige Vorarbeiten leisten.
Windows Server 2016 und Vorbereitung des KMS-Servers
Zunächst muss der KMS-Server die benötigten Voraussetzungen erfüllen. Normalerweise sollte dies automatisch der Fall sein, sofern alle aktuellen Updates installiert sind. Falls nicht hier eine kleine Übersicht:
Windows Server 2008 R2 als KMS-Host
Windows Server 2016 kann nicht aktiviert werden, keine Unterstützung seitens Microsoft
Anschließend muss der neue Windows Server 2016 KMS-Host-Key (CSVLK) eingespielt werden. Den Key erhaltet ihr im Volume Licensing Service Center (VLSC).
Wenn es bei diesem Schritt Probleme geben sollte hilft oft ein Neustart des KMS-Services.
Anschließend muss der neue KMS-Host-Key noch aktiviert werden:
Cscript.exe %windir%\system32\slmgr.vbs /ato
Zum Schluss könnt ihr die hoffentlich erfolgreiche Aktivierung mit folgendem Befehl überprüfen:
Cscript.exe %windir%\system32\slmgr.vbs /dlv
Windows Server 2016 KMS-Client-Aktivierung
Nachdem der KMS-Server soweit fertig ist, könnt ihr ab sofort eure Windows Server 2016 Clients via KMS aktivieren. Nachfolgend die benötigten KMS-Client-Keys (GVLK) (Quelle):
Betriebssystem
KMS-Client-Key
Windows Server 2016 Datacenter
CB7KF-BWN84-R7R2Y-793K2-8XDDG
Windows Server 2016 Standard
WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY
Windows Server 2016 Essentials
JCKRF-N37P4-C2D82-9YXRT-4M63B
Entweder installiert ihr die neuen Windows Server 2016 direkt mit den richtigen Keys oder ihr installiert die Keys später und aktiviert das Betriebssyystem manuell:
Neueste Kommentare