Inhaltsverzeichnis
  1. Zwei kritische Schwachstellen in Azure-nahen Diensten 2
  2. Sysprep erzeugt keine eindeutigen vm IDs 3 - 4
  3. Temperatur in Server- und Technikräumen 5 - 6
  4. WSUS Einstellung am 18.04.2025 7 - 8
  5. Windows Server 2025 wird Nachfolger 9 - 11
  6. Exchange gefällig? - gefährlich? 12 - 13
  7. Windows Server LSASS-Memory-Leak geschlossen 14 - 15
  8. Exchange Server unbedingt patchen 16
  9. Windows Server 2012 R2 Supportende 17
  10. veeam - Sicherheitslücke - V12 erforderlich 18
  11. Microsoft macht alten Exchange die Tür zu 19
  12. veeam neue kritische Sicherheitslücken 20

Zwei kritische Schwachstellen in Azure-nahen Diensten

Im Rahmen des #Microsoft Patchday im September 2025 wurden zwei besonders kritische #Sicherheitslücken veröffentlicht, die Azure-nahe Komponenten betreffen. Organisationen, die Azure Automation oder Azure AD Connect (Entra ID Synchronisation) einsetzen, sollten dringend handeln.

CVE-2025-29827 – Azure Automation Runbook Execution Engine

Betroffene Komponente:
Azure Automation Runbook Execution Engine, insbesondere bei Einsatz von Hybrid Worker Nodes oder lokal ausgeführten Runbooks.

Risiko:
Ein lokal authentifizierter Angreifer kann manipulierte Runbooks nutzen, um Systemrechte zu erlangen.

Erforderlicher Patch:

  • Sicherheitsupdate KB50329827 für Windows Server 2019/2022 auf Hybrid Worker Nodes.
  • Aktualisierung der Runbook Engine über das Azure Portal oder PowerShell (Update-AzAutomationAccount).

Empfohlene Maßnahmen:

  • Runbooks auf verdächtigen Code prüfen.
  • Audit-Logs aktivieren.
  • Least-Privilege-Prinzip für Runbooks durchsetzen.

CVE-2025-29972 – Azure AD Connect (Entra ID Synchronisation)

Betroffene Komponente:
Azure AD Connect, das für die Synchronisation zwischen lokalem Active Directory und Azure AD (Entra ID) verwendet wird.

Risiko:
Ein Angreifer kann durch manipulierte Synchronisationsprozesse administrative Rechte erlangen.

Erforderlicher Patch:

  • Sicherheitsupdate KB50329972 für Azure AD Connect (mindestens Version 2.1.20.0).
  • Aktualisierung des Azure AD Connect Health Agent über Microsoft Update oder manuell.

Empfohlene Maßnahmen:

  • Sync-Konten auf unnötige Rechte prüfen.
  • Multi-Faktor-Authentifizierung (MFA) aktivieren.
  • Audit-Logs für Synchronisationsaktivitäten aktivieren.

Fazit

Die beiden Schwachstellen zeigen, wie wichtig es ist, auch Cloud-nahe Dienste wie Azure Automation und Azure AD Connect regelmäßig zu patchen und abzusichern. Unternehmen sollten die genannten Updates zeitnah installieren, idealerweise innerhalb von 7 Tagen nach Veröffentlichung, wie es auch in internen Sicherheitsrichtlinien empfohlen wird.


Sysprep erzeugt keine eindeutigen vm IDs

Wenn man Sysprep beim Klonen von Windows-VMs verwendet, kann es passieren, dass alle geklonten Systeme die gleiche IdentifyingNumber aus Win32_ComputerSystemProduct erhalten – insbesondere bei virtuellen Maschinen (VMs).

🧩 Warum ist das so?

IdentifyingNumber stammt aus SMBIOS

  • Die Eigenschaft Win32_ComputerSystemProduct.IdentifyingNumber wird vom SMBIOS geliefert.
  • Bei physischen PCs enthält sie z. B. die Seriennummer des Mainboards.
  • Bei VMs (z. B. Hyper-V, VMware, VirtualBox) wird dieser Wert vom Hypervisor simuliert oder fix vorgegeben.

Sysprep verändert SMBIOS-Werte nicht

  • Sysprep entfernt Benutzerinformationen, SIDs, Netzwerkkonfigurationen etc.
  • Aber es verändert keine Hardwareinformationen wie:
    • IdentifyingNumber
    • UUID (aus Win32_ComputerSystemProduct.UUID)
    • SerialNumber (aus Win32_BIOS)
  • Diese Werte bleiben nach dem Sysprep-Klonen identisch, wenn der Hypervisor sie nicht automatisch generiert oder du sie manuell ersetzt.

⚠️ Warum ist das ein Problem?

Asset-Management

Tools wie SCCM, GLPI, OCS Inventory oder Lizenzsysteme nutzen IdentifyingNumber zur Erkennung von Geräten.
➡️ Wenn alle VMs die gleiche ID haben → Geräteüberschreibung.

Lizenzierung

Software, die per Hardware-ID lizenziert wird (z. B. manche PHP-Verschlüsselungen, SQL-Server-Bindungen), wird beim Klonen ungültig oder doppelt registriert.

🛠 Lösung: Eindeutige SMBIOS-IDs zuweisen

Für Hyper-V:

powershellKopierenBearbeitenSet-VMFirmware -VMName "VM-Name" -SystemSerialNumber "DEINE-EINDEUTIGE-ID"

Für VMware Workstation/ESXi:

  • In .vmx-Datei: iniKopierenBearbeitenuuid.bios = "56 4d 12 34 56 78 90 ab-cd ef 12 34 56 78 90 ab" serialNumber = "VM-1234567890"

Für VirtualBox:

cmdKopierenBearbeitenVBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/SerialNumber" "UNIQUE-ID"

⚠️ Diese Werte müssen vor dem ersten Boot nach dem Klonen gesetzt werden.

✅ Empfohlener Klon-Prozess für VMs mit Sysprep

  1. Sysprep ausführen (generalize + shutdown)
  2. VM nicht sofort starten, sondern:
    • eine neue UUID, Seriennummer, MAC-Adresse etc. konfigurieren
  3. Erst danach VM starten und initialisieren lassen

🔒 Alternative: Bessere Hardware-IDs nutzen

Wenn du eine eindeutige Systemkennung brauchst, verwende eine dieser Optionen:

WMI PropertyVorteil
Win32_ComputerSystemProduct.UUIDEtwas robuster, aber oft auch identisch
Win32_BIOS.SerialNumberManchmal vom Host überschrieben (z. B. "VMware-56...")
Get-CimInstance Win32_BaseBoard + SerialNumberBIOS-Board-spezifisch, aber bei VMs oft leer
MAC-Adresse der NICUnterscheidbar, falls per DHCP/Hypervisor generiert

Oder:
Erzeuge bei Erststart eine eindeutige Kennung (z. B. GUID in Datei/Registry) → das ist verlässlich, selbst bei gleichen Hardware-IDs.

🧾 Fazit

PunktAussage
IdentifyingNumber wird nicht von Sysprep zurückgesetzt✅ korrekt
Klone ohne Anpassung erzeugen Duplikate⚠️ problematisch für Inventar, Lizenzierung, Monitoring
LösungSeriennummer/UUID per Hypervisor setzen vor dem Start der geklonten VM
AlternativEigene GUID beim First Boot generieren und persistieren

Temperatur in Server- und Technikräumen

Die #Temperatur im Serverschrank nicht außerhalb des Temperaturbereichs von 18°C bis 24°C liegen.
Auch wenn moderne Server ein verbessertes Abwärmekonzept (wie FUJITSU Cool-Safe) haben, sind nicht alle anderen technischen Geräte immer auf dem neusten Stand, sondern bis zu 6 Jahre alt (oder sogar älter).

Daher sind Server-Hersteller-Empfehlungen, die Server bei 25-27 °C zu betreiben, mit Vorsicht zu betrachten.

Das #BSI empfiehlt keine konkreten Werte, schreibt aber, dass ausreichend Kühlleistung gemessen an der Wärmeleistung der Server vorhanden sein muss, um sicheren Dauerbetrieb der Geräte zu erreichen.
Die Luftfeuchtigkeit sollte bei etwa 45-55% liegen.

Aus Energie-Effizienz-Gründen haben sich de Werte 22°C bei 50% relativer Luftfeuchte etabliert.

Bei dieser Temperatur (messbar und dokumentiert als "Ambient" im FUJIUSU IRMC oder HP ILO) arbeiten Netzwerkgeräte optimal und haben eine lange Lebensdauer.
(Hintergrund: Muss mehr warme Abluft von den elektronischen Komponenten abgeführt werden, drehen die Lüfter mit bis zu Maximaldrehzahl. Vergleichbar mit einem Turbolader im Auto, der ständig unter Vollast läuft und daher schneller defekt ist.

Elektronische Geräte erzeugen Wärme. Sofern die Wärmeableitung nicht ausreicht und die Luft nicht entweichen kann, sondern sich im Schrank staut, kann es zur Überhitzung kommen. Die Temperatur hat einen direkten Einfluss auf die Leistung und Zuverlässigkeit Ihres Servers und anderer Netzwerkgeräte wie Telefonanlagen, Switches, Router, USV).

Zu hohe Temperaturen können zu Störungen und Ausfällen führen. Eine Temperatur ab 30°C verdoppelt die Ausfallrate. Und ab 40°C ist die Gefahr 4-mal so groß. Zudem können hohe Temperaturen dauerhafte Schäden an den Geräten verursachen.


WSUS Einstellung am 18.04.2025

[time_until date="18.04.2025"]

Am 18. April 2025 wurde von Microsoft im Kontext von WSUS (Windows Server Update Services) keine komplette Einstellung des Dienstes vorgenommen, sondern es gab wichtige Änderungen im Support und in der Weiterentwicklung.

Hier ist eine differenzierte Übersicht über das, was zum Stichtag eingestellt wurde, und was weiterhin funktioniert:

❌ Eingestellt / betroffen ab 18. April 2025

Einstellung der Weiterentwicklung

  • Microsoft hat offiziell angekündigt, dass WSUS nicht mehr aktiv weiterentwickelt wird.
  • Das bedeutet:
    • Keine neuen Features.
    • Keine Verbesserungen in der Verwaltung oder Funktionalität.
    • Keine Unterstützung für neue Windows-Versionen nach Windows 11 24H2 oder Server 2025, sofern keine Kompatibilitäts-Updates mehr folgen.

Verwaltung neuer Update-Kanäle

  • WSUS unterstützt nicht mehr alle neuen Update-Typen und Pakete, z. B.:
    • Neue Feature-Updates im „Unified Update Platform (UUP)“-Format werden nicht mehr automatisch unterstützt.
    • Updates für bestimmte Azure- oder Intune-gebundene Geräte können nicht mehr sauber synchronisiert werden.

✅ Was funktioniert weiterhin (Stand Juli 2025)

Bereitstellung klassischer Windows-Updates

  • WSUS kann weiterhin verwendet werden, um klassische Sicherheits- und Qualitätsupdates für unterstützte Systeme bereitzustellen:
    • Windows 10 (bis inkl. 22H2)
    • Windows Server 2016, 2019, 2022 (solange sie Support erhalten)
    • Windows 11 23H2 und teilweise 24H2 (sofern Unterstützung nicht aufgehoben wurde)

Bestehende WSUS-Installationen

  • Vorhandene WSUS-Instanzen funktionieren unverändert:
    • Updates werden weiterhin synchronisiert (sofern nicht vom Microsoft Update-Katalog entfernt).
    • Clients können sich weiter mit WSUS verbinden und Updates beziehen.
    • GPO-basierte Steuerung (z. B. Update-Zeitpläne, Genehmigungen) funktioniert weiterhin.

Support bis Oktober 2032

  • WSUS kann laut Microsoft-Planungen bis einschließlich Oktober 2032 genutzt werden, sofern es mit unterstützten Windows-Versionen betrieben wird.

📝 Empfehlung für WSUS-Nutzer

Für Unternehmen, die WSUS On-Premises einsetzen, gilt:

  • Der aktuelle Wartungsansatz (WSUS) funktioniert weiterhin.
  • Aufgaben der Systemkoordinierenden (z. B. Update der Server) bleiben bestehen.
  • Es ist ratsam, auf moderne Update-Management-Systeme (z. B. Intune, Endpoint Manager) umzusteigen – insbesondere im Rahmen einer Cloud-Migration (IaaS/SaaS).

Viele Unternehmen haben bereits heute #WSUS ausgeschaltet/entfernt und lassen Updates direkt herunterladen. Die Installation auf den Endgeräten mit Windows 10 / 11 Pro/Enterprise erfolgt dann automatisch und die Benutzer werden zum Neustart aufgefordert.

Auf Servern erfolgt die Installation meist durch den Unternehmens-Administrator, gefolgt von einem manuellen Neustart der Server. Hiermit wird sichergestellt, dass die Neustarts im definierten Wartungsfenster (max. 10 Tage nach Patchday) liegen. Nach dem Neustart erfolgt eine kurze Funktionsprüfung der wichtigsten Funktionen. Im Bedarfsfall können so fehlerhafte Sicherheitsupdates zurückgezogen werden.

Wir empfehlen das Installieren der Updates am ersten Wochenende nach dem Patchday. Damit hat Microsoft 4 Tage Zeit, Patches, die fehlerhaft sind, wieder zurückzuziehen oder zu reparieren. Zusätzlich liegt man im von Versicherungen bewerteten Zeitfenster (nach mehr als 10 Tagen ohne Updates behalten sich Versicherungen vor, die Leistungen im Schadenfall rigoros zu kürzen).

Wer die Geräte verwalten möchte, dem empfehlen wir passende Intune Pläne. Bereits im Microsoft 365 Business Premium Plan sind wertvolle und nützliche Funktionen aus Intune nutzbar. Für die vollständige Verwaltung aller Geräte kann dann ein auf die vollständigen Intune-Pläne zurückgegriffen werden.


Windows Server 2025 wird Nachfolger

Nach Server 2022 kommt Server 2025. Microsoft hat nun auch für Visual Studio Abonnenten die RTM-Version (als Release Preview) bereitgestellt. Server 2025 wird dabei die gleichen Updates wie Windows 11 24H2 bekommen. Der Server Build ist damit identisch wie bei der Windows 11 Version – nämlich 26100.xxx (xxx steht für das monatliche Sicherheitsupdate und das optional 2 Wochen später erscheinende Funktionsupdate.

Installiert man also aus der ISO 26100.1, erfolgt kurz darauf ein Update auf Version .560. Da ich in der virtuellen Maschine kein TPM aktiviert habe, funktioniert die Installation im Gegensatz von Windows 11 ohne Tricks. Die Voraussetzung, dass der Prozessor SSE 4.2 unterstützen muss und somit alte Core2Duo und Core2Quad Prozessoren nicht lauffähig sind, vermuten wir, können es aber weder dementieren, noch beweisen. Es wird aber wohl kaum jemand so alte Client-Hardware zum Betrieb von Servern einsetzen. Wie alt ein XEON-Prozessor in einem Server 2025 sein darf, ist noch herauszufinden. Da die meisten bei On-Prem-Einsatz ihre Windows Server (Std oder Datacenter) Lizenzen mit einem Server als OEM Version lizenzieren, dürfte auch das nicht relevant sein.

Wer ein VS Prem oder VS Professional Abonnement hat, kann die Server-Version schon in einer isolierten Umgebung testen (z. B. in einer Client Hyper-V Umgebung).

Zur automatisierten Installation (Unattended, deployment) dürfen folgende Schlüssel verwendet werden (für die Lizenzierung muss nachher ein gültiger Lizenz-Schlüssel eingegeben werden).

Windows Server 2025 Standard. TVRH6-WHNXV-R9WG3-9XRFY-MY832
Windows Server 2025 Datacenter. D764K-2NDRG-47T6Q-P8T8W-YP6DF

Windows-Updates für die Server 2025 Version wird es voraussichtlich bis September 2034 geben - Bisher waren Server immer LTSC mit 10 Jahren Laufzeit. Sofern Microsoft nicht auf den "Modern Life Cycle mit 5 Jahren" wie beim Office umstellt. bleibt das dabei.

Testbericht Server 2025 / 26100

Mit den o.g. Installationsschlüsseln lässt sich eine Unattend Vorlage bauen, so dass eine VM auf Knopfdruck innerhalb von 5 Minuten mit GUI installiert ist (und das nur im Client-Hyper-V unter Windows 10). Das ist gegenüber Server 2022 eine deutliche Beschleunigung.

Der Installationsprozess ist noch nicht modernisiert - man findet in der SETUP-GUI immer noch das Aussehen von Windows 7 :D .

Das Aussehen von Windows Server 2025 ist - Überraschung! - identisch mit Windows 11 (24H2). Kein Wunder, denn es ist ja dieselbe Code-Basis und derselbe Kernel. Wer also die RDS-Services aktiviert, bekommt auf den Terminalservern die GUI von Windows 11 präsentiert. Gruppenrichtlinien, die man von Windows 11 kennt, lassen sich auch anwenden.

Der Server-Manager und auch Active Directory Benutzer&Computer, sowie die anderen Verwaltungs-Tools sind unverändert verfügbar, es wird aber wieder Werbung für ADAC gemacht (Active Directory Admin Center). Außerdem ist wieder AzureArc - wie nach einem Windows Update von Server 2022 an Bord und fährt im Autostart mit hoch. Wer keine Server in Azure hat (Hybrid), sondern eine reine On-Prem-Umgebung, der kann im Task-Manager unter Autostart (ja, der Menüpunkt ist nun auch auf dem Server vorhanden) das Tray-Icon deaktivieren.

Wie die Hardware-Anforderungen sind, wird leider nicht klar ausgedrückt (siehe oben). Eins ist sicher: Auf meiner Test-VM habe ich in den Einstellungen NICHT den TPM des Hosts aktiviert. Die Installation der Gen2 VM läuft problemlos durch und Server 2025 startet auch danach fehlerfrei. Meine Vermutung ist aber, dass es neben der Windows 11 Prozessorliste (alles ab Core i der 8. Generation) auch eine Positivliste für XEON-Prozessoren gibt. Lediglich die IoT-LTSC Version von Server 2025 hat geringere Hardware-Anforderungen (sie hat aber auch keine grafische Benutzeroberfläche, wenn sie auf einer Smart-Fliese im Bad betrieben wird).


Exchange gefällig? - gefährlich?

Eine aktuelle Analyse im Internet zeigt: Von etwa 45.000 Microsoft-Exchange-Servern in Deutschland, die über das Internet via Outlook Web Access (OWA) erreichbar sind, gibt es leider immer noch viele veraltete und unsichere Versionen.

Das Bundesamt für Sicherheit in der Informationstechnik hat festgestellt, dass rund 12 % dieser Server noch mit Exchange 2010 bzw. 2013 laufen, für die seit Oktober 2020 bzw. April 2023 keine Sicherheitsupdates mehr erhältlich sind. Außerdem sind ungefähr 28 % der Server mit den neueren Versionen Exchange 2016 oder 2019 nicht auf dem neuesten Stand und haben daher eine oder mehrere kritische Sicherheitslücken, die es einem Angreifer von außen ermöglichen, beliebige Programme auf dem angegriffenen System auszuführen (Remote Code Execution, RCE). #Wichtig - das entspricht rund 25 % aller Exchange-Server in Deutschland.

Wer #Exchange Server 2010 oder 2013 einsetzt ODER Exchange Server 2016 oder 2019 nicht mit allen verfügbaren Patches einsetzt, ist entweder schon unter Kontrolle der kriminellen Banden, hat Datenabfluss und Kompromittierung nur noch nicht bemerkt oder hat ein kritisches Risiko, gehackt zu werden.

Auch wenn alle Patches auf einem Exchange Server 2019 installiert sind, bleibt das Betriebs-Risiko wegen Zero-day-Lücken immer bis zum nächsten Patchday kritisch (also bis zu einem Monat!)

Cyber-Versicherungen lassen sich entweder gar nicht erst abschließen oder verweigern die Leistung im Schadenfall. Insbesondere weil mit Rechtswirksamkeit von NIS2 auch viele KMU-Unternehmen in die KRITIS Klasse 2 fallen, ist zusätzlich mit hohen Geldbußen und Strafen zu rechnen.

BSI Veröffentlichungen

Was ist zu tun?

[faq openfirst=1]Sie haben Exchange Server 2010/2013 im Einsatz?|=|Migrieren Sie umgehend auf Exchange online.
||Sie haben Exchange Server 2016/2019 im Einsatz?|=|Installieren Sie alle verfügbaren Updates, Sicherheitspatches und CUs und migrieren Sie ebenfalls umgehend auf Exchange online.
||Sie haben schon Exchange online?|=|Microsoft kümmert sich um die Updates und hat das primäre Betriebsrisiko und die Sicherstellung der Verfügbarkeit im Rahmen ihrer SLA vertraglich mit Ihnen geregelt.[/faq]


Windows Server LSASS-Memory-Leak geschlossen

#Erfreulich - mit dem #Patchday März 2024 schließt Microsoft eine kritische Sicherheitslücke in der Kerberos Authentifizierung von Domänen-Controllern. Leider hat man dabei einen Speicherfresser (Memory Leak) kodiert, der dazu führt, dass mancher (nicht alle) Domänencontroller 2016/2019 und 2022 nach einiger Zeit (zwischen 12 und 24 Stunden) so viel Speicher auf den Prozess LSASS.EXE alloziert, dass der DC entweder keine Aufgaben mehr wahrnimmt oder sogar eigenständig neu startet.

Update 23.3.2024: Microsoft hat ein Out-of-band Update für Windows Server 2022 (KB5037422), Windows Server 2016 (KB5037423) und Windows Server 2012 R2 (KB5037426) herausgegeben. Windows Server 2019 folgt noch in den nächsten Tagen. #Warnung - diesen Patch bitte zeitnah installieren auf betroffenen Servern.

Update 26.03.2024: Nun ist auch das Update für Windows Server 2019 erschienen. Die unterstützten Server sollten dann nach Installation und Neustart wieder frei vom Speicherloch sein und nicht mehr abstürzen.

Microsoft Knowledge Base

Einige Admins berichten, dass das Problem bei ihnen gar nicht auftritt, andere starten die DC zeitversetzt 1x pro Tag neu als Workaround. Da DCs in Azure aus Kostengründen meist noch andere Aufgaben (1 File, 1 Print/Apps) übernehmen, lässt sich ein Neustart nur außerhalb der normalen Arbeitszeiten realisieren.

Generell ist es aber keine gute Idee, das Update wegzulassen, da eine kritische Lücke mit einem Score von 9 von 10 geschlossen wurde.

Microsoft hat das Problem bestätigt und arbeitet an einem Hotfix, der kurzfristig ausgerollt werden soll. Aus Sicherheitsgründen kann man hier nur abwarten.

Übrigens: Ältere Server wie Server 2012 R2, die On-Premises keine Sicherheitsupdates bekommen, haben zwar nicht das Speicherproblem, aber dennoch die Sicherheitslücke. Werden sie in Azure betrieben, gibt es einen Patch, der auch für diese Server die Sicherheitslücke schließt und auch das Speicherproblem mit sich bringt. Wer noch Windows Server 2008 R2 einsetzt, hat ganz andere Sicherheitsprobleme, da es auch im ESU gegen Bezahlung keine Sicherheitsupdates mehr gibt.


Exchange Server unbedingt patchen

#Wichtig - die zuletzt für #Exchange 2016 und 2019 geschlossenen, kritischen #Sicherheitslücken aus CVE-2024-21410, mit denen Angreifer leichtes Spiel haben, Exchange Server unter ihre Kontrolle zu bringen und Schadsoftware einzuschleusen, werden derzeit aktiv ausgenutzt.

Sollten Sie noch Exchange Server 2016 oder 2019 im Einsatz haben, ist das Installieren der Patches überlebenswichtig, da es sonst nur eine Frage der Zeit ist, wann Ihr Server übernommen wird.

Mehr Details und welcher Patch für welche Exchange Version installiert sein muss, finden Sie im unten verknüpften Artikel.

Kunden mit Microsoft 365 / Exchange online sind wieder einmal nicht betroffen, da Microsoft dort die Sicherheitslücken selbst und vor Veröffentlichung geschlossen hat.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21410

Windows Server 2012 R2 Supportende

Nur zur Erinnerung - #endoflife - Mit dem Patchday am 10. Oktober 2023 liefert Microsoft die letzten #Sicherheitsupdates für Windows Server 2012 R2 aus, die nicht in der Azure Cloud betrieben werden (also für alle Kauf-Versionen ungeachtet, ob Sie eine Software-Assurance mitgebucht haben oder nicht).

[time_until date="10.10.2023" calendar=1]

Der Betrieb von 2012 R2 Servern ist damit ein potenziell deutlich höheres Risiko, die Gefahr einer Infektion und Ausbreitung von Schadsoftware damit gegeben. Spätestens, wenn zum Patchday November 2023 für neuere Betriebssysteme Lücken geschlossen werden.

Modernisieren Sie vorhandene Server 2012 R2 auf neuere Server-Betriebssysteme (2016, 2019 oder 2022) oder bringen die Server in die Microsoft Azure IaaS Cloud, falls Sie Software weiterbetreiben müssen, die nur auf dieser 10 Jahre alten Plattform lauffähig ist.


veeam - Sicherheitslücke - V12 erforderlich

Eine Datensicherungssoftware muss immer den aktuellen Stand haben, denn bei einem Befall aufgrund einer Sicherheitslücke in der Software wären im schlimmsten Fall ein Datenverlust oder Datendiebstahl verbunden.

Bei veeam hat die Sicherheitslücke, vor der die CISA derzeit warnt, ein Ranking von 7.5 von 10 auf der Schadensskala. Problem ist der Prozess Veeam.Backup.Service.exe, der auf TCP-Port 9401 reagiert. Angreifer können verschlüsselte Anmeldeinformationen herausbekommen und Zugriffe auf Backup-Infrastruktur-Hosts stattfinden, schreiben die Entwickler von veeam.

Neu dabei ist, dass man nun auch Version 11 mit aktuellem Patchlevel auf Version 12 anheben muss. Erst mit Version Build 12.0.0.1420 P20230223 oder neuer ist diese Lücke sicher geschlossen.

#Wichtig - Bitte aktualisieren Sie Ihre veeam-Installationen auf die aktuelle 12er Version oder lassen sie aktualisieren.

https://www.veeam.com/kb4424

Microsoft macht alten Exchange die Tür zu

Wie aktuelle Statistiken beweisen, sind noch zigtausende alte #Exchange Server im Internet erreichbar und versenden (da solche Server meist schon - auch ohne das der Betreiber es merkt - unter der Kontrolle Krimineller sind) E-Mails und Spams.

Da nur noch Exchange Server mit Version 2016 und 2019 #Sicherheitsupdates bekommen, stellen die alten Versionen 2007, 2010 und 2013 ein hohes Risiko dar. Microsoft hat daher beschlossen, auf seinen Onlinediensten (Exchange Online/Microsoft 365) den Empfang von Mailservern der unsicheren Art zu verhindern, indem dort der absendende Server aus den E-Mail-Kopfzeilen ausgelesen wird und bei feststellen von einem Exchange 2007/10/13 die E-Mail abgewiesen (gebounct) wird.

Die Block-Regel für Exchange Server 2007 wird kurzfristig aktiviert, 2010 und 2013 sollen dann sukzessive folgen.

#Wichtig - Wer noch einen Exchange Server 2007, 2010 oder 2013 betreibt, sollte umgehend handeln (Version 2019 lizensieren (Ende der Sicherheitsupdates ist bereits am 14.Okt 2025 und einen Nachfolger kann man nur noch mieten!) oder besser: auf Exchange online umstellen) oder damit rechnen, dass er viele seiner Kunden und Lieferanten (alle Empfänger, die bereits Microsoft Online-Diente nutzen) nicht mehr erreichen können wird.

Quelle: Microsoft Artikel - https://aka.ms/BlockUnsafeExchange

veeam neue kritische Sicherheitslücken

Werden diese #Sicherheitslücken (CVE-2023-27532 „hoch“) ausgenutzt, können Angreifende Kontrolle über den Backup-Server erlangen. Veeam Software hat Anfang März 2023 Sicherheitsupdates zur Verfügung gestellt, mit denen die Lücken geschlossen werden können.

#Wichtig - Wie aus dem Security-Bulletin des Herstellers hervorgeht, müssen alle veeam-Versionen (9,10 und auch Version 11) auf Version 12.0 aktualisieren.

Hierzu ist ein aktiver Wartungsvertrag erforderlich. Seite Rest-Laufzeit wird im Startbild von veeam oder im "Info über" Dialog im Hamburger-Menü angezeigt. Zum Herunterladen der aktuellen Patches melden Sie sich mit Ihrem veeam Konto auf veeam.com an, laden das Update herunter und installieren es. Nach einem Neustart des Backup-Servers ist die Sicherheitslücke geschlossen.

auch veeam Version 11.01 Versionen müssen aktualisiert werden

veeam Knowledgebase