Wichtiges Windows Update für Windows Updates

Alle Ihre Server und Arbeitsplätze mit #Windows 7 Service Pack 1 und Windows #Server 2008 R2 SP1 müssen bis zum 13. August die "Servicing Stack Updates" KB4474419 und KB4490628 installiert bekommen, ansonsten erhalten diese beiden Betriebs-Systeme bereits im September 2019 keine #Sicherheitsupdates mehr.

Bekanntlich ist für diese beiden Betriebs-Systeme das Ende des erweiterten Supports und damit der Sicherheits-Patches ohnehin für Januar 2020 festgelegt. Ohne das oben genannte Update verkürzt sich die Zeit, in der Sie auf Windows 10 Pro/Enterprise bzw. Windows Server 2016 oder 2019 umstellen können, um weitere vier Monate.

Zusätzlich sind auch Windows Software Update Services (WSUS 3.0) betroffen. Die Software stellt keine Updates mehr bereit, wenn sie nicht auch auf den aktuellen Stand gebracht wird. Für WSUS 3.0 ist das Update KB4484071 am 12.03.2019 erschienen. Dieses Update muss manuell aus dem Windows Update-Katalog heruntergeladen und installiert und genehmigt werden.

Handlungsbedarf

Prüfen Sie bitte, ob oben genannte Updates installiert sind. Wenn nicht, oder Sie uns mit der Prüfung und Installation beauftragen möchten, nehmen Sie bitte Kontakt über einen Vorgang mit Bezug auf diesen Artikel mit uns auf.

Setzen Sie bereits unsere Managed Services (https://erpsystem.de/managed-services/) ein? Dann brauchen Sie nichts unternehmen – wir kümmern uns um alles Notwendige.

Hintergrundinformation

Microsoft stellt ihren Update-Mechanismus auf SHA-2 verschlüsselte Pakete um. Dies ist bereits im Vorfeld bei neueren Betriebs-Systemen wie Windows 10 und Windows Server 2016/19 geschehen. Da darüber hinaus lediglich Windows 7 und Server 2008 R2 noch kein Support-Ende haben, müssen diese Plattformen aktualisiert werden.
Für Windows Server 2008 und Windows Vista ist das Update zwar auch erhältlich, beide bekommen aber bereits seit 2018 keine Sicherheits-Updates mehr. Wer also noch "Vista-Server" Windows Server 2008 im Einsatz hat, kann das Update zwar installieren, sollte aber lieber auf die oben genannten neuen Betriebs-Systeme wechseln.

Mittlerweile sind viele Softwareprodukte ohnehin nur unter den aktuell supporteten Windows Umgebungen lauffähig (Windows 10 und Server 2016 oder 2019).

Details und Stichtage

WSUS 3.0 SP2:                  Sicherheitsupdate für SHA2-Unterstützung 12.03.19 erschienen                              SHA2 erforderlich am 16.06.19

WinServer2008SP2:        Sicherheitsupdate für SHA2-Unterstützung 09.04.19 u. 14.05.19 erschienen       SHA2 erforderlich am 16.07.19

Windows 7 SP1:               Sicherheitsupdate für SHA2-Unterstützung 12.03.19 erschienen                              SHA2 erforderlich am 13.08.19

WinServer2008R2SP1:   Sicherheitsupdate für SHA2-Unterstützung 12.03.19 erschienen                              SHA2 erforderlich am 13.08.19

Mehr Informationen: https://support.microsoft.com/de-de/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus

RDP-Lücke BlueKeep in Windows wird aktiv genutzt

Warum zeitnahes Patchen spätestens kurz nach dem #Patchday so wichtig ist, zeigt sich mal wieder anhand der derzeit aktiv ausgenutzten #BlueKeep Lücke im RDP-Protokoll aller #Windows Versionen <8.1:
In #Server 2008 R2 und Server 2012 (ohne R2), sowie in Windows 7 wurde jüngst eine Sicherheitslücke geschlossen, die es ermöglichte, einem Angreifer volle Kontrolle über das Zielsystem zu erlangen und Schadcode auszuführen. Microsoft stuft diese Lücke als kritisch ein.

Nur wer zeitnah (mit WSUS Unterstützung oder direkt) alle Server und Arbeitsplätze der oben genannten Versionen patcht, ist sicher. (CVE-2019-0708)

Hyper-V Replika - genial aber mit versteckten Fallen

Seit Server 2012 R2 ist die Funktion, virtuelle Maschinen auf einen anderen Hyper-V-Host auch über WAN-Leitungen (oder eben über das lokale Netzwerk) zu replizieren, funktionsfähig und verfügbar.

Für alle, die das Vorhaben planen, bei Hardware-Ersatz-Investition den alten Server als Replika-Ziel zu verwenden, hat Microsoft ganz am Ende der Einrichtung nun eine nette Falle eingebaut: Das Ziel-Betriebssystem (also der Host, auf den repliziert wird) muss das gleiche Betriebssystem haben oder neuer sein als das Quellhost-Windows.

Möchte man also einen alten Server für diesen Zweck nutzen, ist es notwendig, eine Betriebssystem-Lizenz des neuen Servers auch für den alten zu erwerben. Da die Host-Betriebssysteme meist aus kaufmännischen Gründen als OEM-Version erworben werden, bedeutet das den Neukauf der Windows Server Lizenz (und je nach Anzahl der replizierten Maschinen auch der additional Core Licenses). 
Seit Server 2016 sind im Basis-Paket 16 Cores (virtuelle Prozessoren) lizensiert. Das entspricht einer 2-Prozessor-Maschine mit jeweils einem 8-Core XEON Prozessor. 

Hat man die Lizenz für den Replika-Server erworben, müssen beide Hosts (Quell-Host und Ziel-Host noch in der selben Domäne Mitglied sein). Solange man nur im lokalen Netzwerk repliziert, kann man sich die Verschlüsselung mit Zertifikaten sparen und verwendet stattdessen die Kerberos-Authentifizierung des Active Directory, damit sich die Hosts verstehen. 
Wer den Replika-Host hiter einer WAN-Leitung betreibt, sollte ein VPN als äußere Schutzschicht verwenden. Auch in diesem Fall müssen nicht zwingend Zertifikate eingesetzt werden. 
Spätestens bei Übertragung der Replika-Daten über das Internet, sind HTTPS-Verschlüsselung und Zertifikate erforderlich, um gesetzlichen Vorschriften zu genügen. 

Die Einrichtung selbst ist dann ein Klacks. Replikaserver empfangsbereit machen, Quell-Server die virtuellen Maschinen, die man benötigt über die rechte Maustaste per Assistent für die Replizierung aktivieren. Der gängige Praxiswert ist die Replikation der Deltas alle 15 Minuten. 

Server-Uhr geht vor (NTP-Quelle)

In der Windows Domäne gelten strenge Regeln für die#Uhrzeit. Dadurch kann sich ein Client nicht mehr an der Domäne anmelden, wenn seine Uhrzeit stark von der Server-Uhrzeit abweicht.
Optimal ist daher, den führenden Domänen-Controller mit externer, amtlicher Uhrzeit zu versorgen. Die weiteren Domänen-Controller müssen so eingestellt sein (werden), dass sie die Uhrzeit vom Domänen-Controller beziehen.
Damit das Ganze funktioniert, muss auf der Firewall der Zugriff auf die amtlichen Zeitserver erlaubt werden. Basis bildet hier das sogenannte NTP Protokoll.
Wenn man am ersten Domänen-Controller die folgenden Befehle einstellt - in einer Eingabeaufforderung (Administrator), wird die Serverzeit amtlich:

w32tm /config /update /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8 3.pool.ntp.org,0x8" /syncfromflags:MANUAL w32tm /config /reliable:yes w32tm /config /update

net stop w32time

net start w32time w32tm /resync /rediscover

Danach müssen alle Clients (am Besten über eine Richtlinie) gezwungen werden, die Zeit vom Server beziehen.

Exchange Server 2019

#Microsoft gibt die System-Voraussetzungen für einen #Exchange #Server 2019 (on premise) bekannt. Wichtig dabei ist die neue Mindest-Arbeitssspeicher-Anforderung:

• 2 Prozessoren
• Mind. 128 GB Arbeitsspeicher*
• Ab 100 GB Festplattenplatz, abhängig von der Postfachdatenbank-Größe

128 GB werden mindestens vorausgesetzt, damit ein mittelgroßer Exchange Server performant betrieben werden kann. Alte Versionen konnten mit 32 GB Arbeitsspeicher arbeiten.

Exchange Server angreifbar

Aktuell existiert eine #Sicherheitslücke in allen #Exchange Versionen, die es ermöglicht, sich administrative Berechtigungen zu erschleichen und z. B. Mails umzuleiten. Da die Lücke im Active Directory (EWS) verankert ist und über den Internet-Zugang auf den Exchange (OWA) erreichbar ist, sollten Sie umgehend handeln und die Lücke schließen (lassen).
Bis ein Update von Microsoft verfügbar ist, lässt sich die Lücke durch Löschen eines Registrierungs-Schlüssels auf dem Exchange Server schließen:

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f

Wenn Sie die Lücke nicht selbst schließen möchten oder können, beauftragen Sie uns bitte mit einem (kostenpflichtigen) Vorgang beauftragenund wir sichern Ihren Exchange Server ab.

Quelle: CVE-2018-8581 | Microsoft Exchange Server Elevation of Privilege Vulnerability

Mindestversion Ferrari Officemaster Fax: 6.2.3

Microsoft Exchange Online synchronisiert nur noch über TLS 1.2: Ab Novenber 2018 wird die Microsoft Office365 Cloud die Eingangs-Connectoren zwingend auf TLS Version 1.2 umstellen. Der Exchange BCS-Connector, der für die UMS-Dienste im Messaging Server für die Office365 Cloud zuständig ist, beliefert Rückmeldungen und eingehende Nachrichten (Voicemails, Fax- und SMS-Nachrichten) per SMTP i.d.R. direkt über das Internet zur Office365 Cloud. Standardmäßig wird dabei keine Übertragungsverschlüsselung verwendet. 

Da ab November für eingehende Mails in die Office365 Cloud eine TLS-Verschlüsselung der Version 1.2 vorgeschrieben ist, muss die TLS-Verschlüsselung für den BCS-Connector eingeschaltet werden. TLS 1.2 wird erst ab OfficeMaster 6.2.3 abwärtskompatibel unterstützt. Bisher unterstützte der Connector nur TLS Version 1.0.