Windows 11/Server 2019/2022: Netzwerktransfer-Leistung und CPU-Last optimieren – Teil 2

Windows[English]Windows 11 hat ein Problem mit dem Netzwerkdurchsatz, wenn Dateien empfangen werden sollen. In Teil 1 hatte ich einige Messungen, die ein Blog-Leser bei Tests zur Analyse des schwächelnden Netzwerkdurchsatzes und der hohen CPU-Belastung unter Windows 11 durchgeführt hat, präsentiert. Nach diversen Recherchen und wohl auch Kontakt mit Microsoft ist die Ursache nun klar. Verantwortlich sind die Sicherheitsfunktionen, die Microsofts Entwickler in Windows 11 (und Server 2019/2022) eingebaut haben. Glücklicherweise lässt sich das aber konfigurieren bzw. optimieren (was auch für Windows Server 2019/2022 relevant werden kann).


Anzeige

Kurzer Rückblick

Nachdem Blog-Leser Alexander bei Kundensystemen immer wieder Probleme beim Netzwerkdurchsatz und bei RDP-Verbindungen feststellte, hat er sich in einem ersten Schritt die TCP-Optimierung In Windows vorgenommen (siehe Optimierung von Microsofts TCP-Murks in Windows 10 und 11 ). In einigen Szenarien kam er trotzdem beim Netzwerkdurchsatz nicht auf vernünftige Werte.

In einem Test hat er dann eine Windows 10 22H2 Workstation und eine Windows 11 22H2 Workstation per Patchkabel verbunden, sichergestellt, dass die NICs mit gleichen Treibern ausgestattet waren und dann auch sonst nichts klemmt. Zudem waren die TCP-Einstellungen vor dem Test optimiert. Die Messungen ergaben, dass ein Datentransfer über das Netzwerk von einer Windows 11-Maschine zur Windows 10 Workstation mit passablen 1 GB/s, d.h. den erwarteten Geschwindigkeiten, ablief. Der umgekehrte Weg, dass die Windows 10 Workstation Daten zur Windows 11 Maschinen per Netzwerk transferierte, ergab aber zweierlei. Einerseits bracht die Transferleistung massiv ein, selbst mit Optimierungen ließen sich nur 600 MB/s erreichen. Zudem benötigte der Datentransfer die CPU-Leistung eines Rechenkerns, während dies in Windows 10 mit wesentlich  weniger CPU-Last ablief.

Was ist die Ursache?

An dieser Stelle stellte sich die Frage, was diesen Einbruch beim Transfer zur Windows 11 Workstation verursachte (und als Ergänzung: Das Problem lässt sich auch auf neueren Server-Versionen wie Windows Server 2022 samt Hyper-V-Rollen beobachten)? TCP-Optimierungen brachten keine wesentliche Besserung. Die in den Kommentaren von Teil 1 vermutete "Fehlmessung" mit PsPing64 aus den Sysinternals Tools konnte es auch nicht sein, da das Problem ja im Feld aufgefallen war und die Messungen mit iperf bestätigt wurden. Treiber waren auf beiden Workstations die gleichen. Die Maschinen hatte als Workstations auch genügend Rechenleistungen, und einen 10 GBit-NIC, um die entsprechenden Transferleistungen zu bewerkstelligen. Was zur Hölle verbrät bei Windows 11 die CPU-Leistung, wenn Daten per Netzwerk eintreffen?

Der Preis der Windows 11-Sicherheitsfeatures

Irgendwann begann Alexander dann "über den Zaun zu schauen" und kam dem Übel auf die Spur – kein Bug, sondern die Sicherheitsfeatures, die die Entwickler in Windows 11 (und Windows Server 2022) eingebaut haben, haben ihren (zu hohen) Preis. Alexander schrieb mir in einer Mail:

So jetzt aber zu den Details. Für einen sehr großen Teil der CPU-Mehrbelastung beim TCP-Datenverkehr des Windows 11 gegenüber einem Windows 10, sind neben den Sachen die ich schon veröffentlicht habe, mitunter auch das folgende verantwortlich.

Mit den "neben den Sachen, die ich schon veröffentlicht habe" ist das Thema TCP-Optimierungen gemeint, welches ich ja im Beitrag Optimierung von Microsofts TCP-Murks in Windows 10 und 11  behandelt habe. Weiterhin gibt es noch eine Problematik beim TCP-Stack, die Alexander in diesem Spiceworks-Community-Thread diskutiert. Ein Reset des TCP-Stacks mit netsh interface tcp reset kann Wunder bewirken – ist hier aber nicht das Thema.

Dann hat Alexander mir die Kernfunktionen aus Windows 11, die für die CPU-Belastung und den mickrigen Netzwerktransfer verantwortlich sind, in Form einer Sammlung von Screenshots aufgezeigt. Es dreht sich alles im Kern um das tolle Sicherheitsfeature Exploit-Schutz, das die Microsofts Entwickler in Windows 11 (und Windows Server 2019/2022) eingebaut haben. Ich habe es nachfolgend mal kurz aufbereitet.

Bremse: Windows Exploit-Schutz

Alexander hat mir folgendem Screenshot übermittelt. Es zeigt das Dialogfeld Windows-Sicherheit wo die Funktion Exploit-Schutz hervorgehoben ist. Ziel der Funktion ist, das Gerät vor Angriffen durch Exploits (die z.B. Speicherüberläufe provozieren) zu schützen.

Windows 11 Exploit-Schutz
Zum Vergrößern klicken


Anzeige

Auf den ersten Blick eine tolle Idee, wenn der Pferdefuß mit der CPU-Auslastung und dem Leistungseinbruch beim Netzwerk-Transfer in Empfangsrichtung nicht wäre. Dazu schrieb mir Alexander:

Diese Schutzfunktionen sind auf Server 2019/2022 übrigens genauso vorhanden und die meisten davon sind per Default auch aktiviert.

Des Weiteren laufen diese Schutzfunktionen vollkommen unabhängig von dem Defender. Sprich, wenn du auf dem Server den Defender vollständig deinstallierst, dann bleiben diese Schutzfunktionen dennoch aktiv!

Was passiert, wenn man diesen Exploit-Schutz mal versuchsweise über dessen Optionen auf den Testsystemen deaktiviert? Alexander hat den Test gemacht und schreibt dazu:

Ich habe bisher nicht alle einzeln durchgetestet, sondern sowohl als den beiden Windows 11 und Windows 10 Workstations mal alle deaktiviert und konnte danach sofort ein viel gesünderes Verhalten des TCP-Stacks beobachten.

Sprich: Die Deaktivierung einer Schutzfunktion nimmt die CPU-Last beim Datentransfer und bewirkt [einen flotteren Datentransfer].

Das ist dann die Stelle, an der jeder Administrator selbst mal ansetzen und einen Test durchführen kann. Einfach schauen, wie sich die Maschine mit deaktiviertem Exploit-Schutz in der Praxis verhält. Erspart dann auch viele Diskussionen, die am Kern vorbei gehen. Wenn es nichts bringt, ist das Thema abgehakt. Wenn es die oben skizzierten Leistungseffekte hat, muss dann die Entscheidung getroffen werden, ob man auf den Exploit-Schutz verzichtet oder nicht.

Beim ASLR gepatzt?

Und an dieser Stelle wird es leicht witzig, obwohl es im Grunde traurig ist. Alexander schrieb mir in einer Folgemail

lustig, ich sehe gerade, dass du bereits 2017 schon über das ASLR berichtet hast -> Fix: Windows 8/8.1/10 patzen bei ASLR.

Ich habe das echt bis heute nicht mitbekommen, sonst währe ich schon eher was das angeht auf die Palme geklettert.

Im oben erwähnten Beitrag bin ich seinerzeit auf das Thema ASLR in Verbindung mit Windows 8.x und Windows 10 eingegangen. Address Space Layout Randomization (ASLR) ist eine Sicherheitstechnologie für Computer, die es Angreifern durch 'Speicherverwürfelung' beim Laden des Codes schwerer machen soll, einen Pufferüberlauf auszunutzen. Diese Technik ist eigentlich in allen modernen Betriebssystemen irgendwie enthalten.

Bei Windows Vista hat Microsoft ASLR erstmals im gesamten System implementiert. Und im Microsoft Defender ist ASLR ebenfalls in Verwendung. Ruft man das Windows Defender Security Center (z.B. über die Einstellungen-App) auf, kann man unter App- & Browsersteuerung auf die Einstellungen für den Exploit-Schutz zugreifen. In meinem alten Beitrag ging es darum, dass in Windows ASLR die Speicherverwürfelung nicht zufällig vornahm, so dass Angreifer den Schutz eventuell aushebeln könnten.

Aber das ist ein Nebenkriegsschauplatz, denn hier im Blog-Beitrag geht es um den Sachverhalt, dass der Exploit-Schutz beim Empfang von Netzwerk-Paketen unter Windows 11 (oder Windows Server 2019/2022) eine sehr hohe CPU-Last mit entsprechend negativen Auswirkungen auf die Maschine verursacht. Alexander schrieb mir dazu:

zu >99,0% weiss ich aber auch jetzt schon ohne Einzeltests, wo die [gemeint ist Microsofts Entwickler] sich bei dem Exploit-Schutz, aber so richtig gewaltig ins Knie geschossen haben.

Und zwar genau an diesen Stellen …

ASLR in Windows 11

Damit verteilen die sämtliche RAM-Zugriffe einfach zufällig über den gesamten zur Verfügung stehenden RAM, mit dem Ziel, unberechtigte Speicherzugriffe dadurch zu erschweren. Das ist ein absolut billiger Taschenspieler-Trick um ein Problem zu kaschieren, welches wahrscheinlich >99% der Anwender, schlichtweg nicht betrifft.

Denn damit machen die es einem Angreifer lediglich das Leben etwas schwerer, z.B. aus einer anderen VM heraus, über sehr komplizierte Angriffswege die bisher in der freien Wildbahn übrigens noch nie gesehen wurden, den Inhalt des Hauptspeichers einer anderen VM auszulesen.

Alexander meint dazu: "Juhu, ist ja abseits von VDI, Azure und Co. ja auch so wichtig.", womit er nicht ganz unrecht hat. Auf einem virtuellen Server ist es wichtig, dass Speicherüberläufe nicht so einfach per Exploit ausnutzbar sind. Bei Clients und Bare-Metal-Servern tut man gut daran, abzuwägen, was eine bestimmte Schutzfunktion bringt. Dazu schreibt Alexander:

Und ganz neben her, pulverisiert man mal kurz nebenher auch die sehr oft effizienteren sequentiellen RAM Zugriffe.

Und ich frag mich die ganze Zeit, warum sich sequentielle Datenzugriffe über das Netzwerk nicht wirklich wie welche anfühlen.

Am liebsten würde ich jetzt in den Flieger steigen und den Microsoftians direkt vor Ort in Redmond mal so ordentlich meine Meinung geigen.

Und natürlich haben die Microsoftians dasselbe auch im Server 2022 implementiert.

Windows Server 2022 Exploit-Schutz
Zum Vergrößern klicken

Und, um der Leserschaft mal einen Eindruck zu liefern, warum Alexander sich das antut und meinem Eindruck nach, inzwischen mehrere Wochen an diesem Thema verbraten hat (er ist bei Next Generation IT-Solutions der Geschäftsführer), hier noch seine Begründung:

Was eigentlich der Hauptgrund ist, warum ich mich mit dem Thema beschäftige, denn hauptsächlich beschweren sich unsere Kunden, z.B., über zum Teil sehr massive Leistungseinbußen auf den Terminalservern, nachdem wir deren Systeme auf Server 2022 angehoben haben.

Und dann folgt ein Rant, den ich aus meiner Sicht gut nachvollziehen kann, ist es doch das Credo, welches aus vielen meiner Blog-Beiträge heraus schimmert (man braucht nicht zu suchen, das fällt einem als Beobachter doch täglich vor die Füße):

Ganz ehrlich, Microsoft hat von performanter und wirtschaftlich effizienter Hardwareansteuerung überhaupt keine Ahnung mehr.

Na ja, mit Green-IT hat das Ganze nun auch nichts zu tun, eher mit dem Gegenteil.

Statt sich auf ihre Kernkompetenz, ein anständiges Betriebssystem für die Masse, die wichtigste Schnittstelle zwischen Hardware und Anwendungssoftware zu konzentrieren, spielen die lieber an ihrem Azure, Office365 & Co, selbstverliebt herum.

Obigen Rant sollte jeder Leser an seinen eigenen Erfahrungen spiegeln – wird vielleicht nicht jeder so teilen, aber man könnte schon mal drüber nachdenken, was da vielleicht nicht so ganz "straight" läuft. Alexander hat dann noch folgendes in einer weiteren Mail geschrieben:

Ich habe vorhin übrigens den Passmark Performance Test über die Windows 11-Workstation kurz drüber laufen lassen und habe die Ergebnise mit einem Test verglichen, wo auf derselben Workstation noch ein Windows 10 installiert war. Dabei musste ich zu meinem Erstaunen feststellen, dass die RAM-Performance dieser [Windows 11-Installation] nun durchgehend  >10% besser ist, und deren 2D-Performance fast auf demselben Niveau liegt wie vorher auch bei der Windows 10-Installation, und die 3D-Leistung ist sogar etwas besser.

Der Witz ist, als ich die Tests damals mit der Windows 10-Workstation gemacht habe, war sowohl deren CPU und auch der RAM und auch die wassergekühlte RTX 2080 Ti aufs äußerste optimiert.

Jetzt ist bei der Windows 11-Workstation lediglich die CPU etwas optimiert, und selbst das habe ich im Vergleich zu dem Zustand damals nur oberflächlich gemacht, der Rest und vor allem die Grafikkarte, läuft momentan auf default.

Das sind jetzt Ergebnisse, die jeder aus der Leserschaft zur Kenntnis nehmen und an seinen eigenen Systemen bei Bedarf ausprobieren darf.

Ergebnisse im Feld

Wie bereits oben erwähnt, arbeitet Alexander als IT-Dienstleister im Kundenauftrag und ihm sind die obigen Leistungsbremsen bei der TCP-Implementierung unter Windows 11 bzw. Windows Server 2022 in Verbindung mit dem Exploit-Schutz mächtig auf die Füße gefallen. Vor allem zwei Cluster-Systeme haben da Sorgen von der Performance gemacht. Aber "Grau ist alle Theorie, was zählt ist die Praxis", und Alexander hat dann die Erkenntnisse mal bei Kunden umgesetzt. Hier seine erste Aussage:

So, die beiden Cluster die ich gestern geupdatet habe, haben es überlebt. Und das Cluster, welches ich gemäß meinem neusten Fund bereits schon optimiert habe [gemeint ist die TCP-Optimierung per Script), flitzt nun deutlich schneller wie vorher. Und dessen CPU-Gesamtauslastung ist meinem Empfinden nach, nun auch deutlich geringer geworden.

Wie sich das ganze nun auf die Kundenapplikation auswirkt kann ich heute aber nicht sagen, da ich alleine auf einem System wo normalerweise ~400 User drauf arbeiten, jetzt nicht wirklich viel Last erzeugen kann, um es auch annähernd zum Schwitzen zu bringen.

Ich merke aber alleine schon bei diversen administrativen Aufgaben, dass diese nun viel fluffiger laufen, vor allem das Backup.

In einer Nachtragsmail bestätigte er, dass die Cluster auch mit entsprechender Nutzerzahl weiterhin so performant wie erhofft laufen. Und er hat noch weitere Erkenntnisse von Systemen mit Hyper-V per Mail mitgeteilt. Dazu schrieb er:

ich kann dasselbe Problem mit der doppelt so hohen CPU-Last beim eigehenden Datenverkehr auch mit iperf3 1:1 nachstellen. Das deckt sich im Nachgang betrachtet übrigens auch mit unseren Erfahrungen, die wir nach Upgrades von einigen Systemen von Hyper-V 2019 auf 2022 jüngst gesammelt haben.

Denn so gut wie jeder Admin dieser Kunden berichtete, dass die CPU-Last der Hyper-V Nodes nach dem Upgrade deutlich nach oben gegangen ist und oder das Anwendungen langsamer wurden.

Ich bin so happy! Wir haben gerade mit dem Admin eines unserer Kunden einen einzelnen Hyper-V 2022 nach meinen neusten Erkenntnissen getunt und die VM's laufen auf diesem nun mit der Geschwindigkeit, wie ich diese auch von einem Hyper-V 2016 noch gekannt habe.

An dieser Stelle möchte ich das obige Thema erst einmal beenden – weitere Insights folgen die Tage in einem separaten Beitrag. An dieser Stelle mein Dank an Alexander, dass er mir die Ergebnisse seiner Feldforschung bereitgestellt hat, um diese mit der Leserschaft zu teilen (die Empfehlung eines Entwicklers war, sein Wissen für sich zu behalten und das dann zu Geld zu machen).

Die Erkenntnisse sind nicht an einem Tag entstanden, sondern ich habe es am Rande mitbekommen, dass Alexander über Wochen getestet und in der Spiceworks-Community sowie auf administrator.de diskutiert hat.  Von daher wäre meine Bitte, bei Diskussionen (die durchaus erwünscht sind), fokussiert zu bleiben und ggf. selbst vorher einen Test zu machen. Die Ergebnisse der Test samt Erfahrungen in der Praxis liegen jetzt vor und lesen sich beeindruckend. Wäre jetzt spannend, ob andere Administratoren mit ähnliche Erfahrungen aufwarten können – denn im Gegensatz zum TCP-Optimierungs-Script kann der Test mit dem Exploit-Schutz ja jederzeit am Windows Server 2019/2022 leicht durchgeführt werden.

Anmerkung: Da es in den Kommentaren und auf Twitter bereits angesprochen wurde – der obige Beitrag richtet sich nicht an Privatanwender, die mit einem schnellen Klick tunen wollen. Ob Administratoren im Business-Umfeld den Exploit-Schutz ausschalten, bleibt jedem als Entscheidung überlassen. Die Erkenntnisse von Alexander liegen vor, so dass jeder Administrator selbst testen und entscheiden kann.

Artikelreihe:
Optimierung von Microsofts TCP-Murks in Windows 10 und 11
Windows 10/11: Grottige Netzwerktransfer-Leistung, hohe Windows 11 CPU-Last  – Teil 1
Windows 11: Netzwerktransfer-Leistung und CPU-Last  optimieren – Teil 2

Ähnliche Artikel:
Fix: Windows 8/8.1/10 patzen bei ASLR
Windows 8/8.1/10 ASLR-Patzer ist ein Feature, sagt Microsoft
ASLR-Speicherschutz geknackt


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Netzwerk, Problemlösung, Windows, Windows 10 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

75 Antworten zu Windows 11/Server 2019/2022: Netzwerktransfer-Leistung und CPU-Last optimieren – Teil 2

  1. Stefan Kanthak sagt:

    "Damit verteilen die sämtliche RAM-Zugriffe einfach zufällig über den gesamten zur Verfügung stehenden RAM, mit dem Ziel, unberechtigte Speicherzugriffe dadurch zu erschweren."

    AUTSCH: ASLR alias "Address Space Layout Randomisation" wirkt im VIRTUELLEN Speicher, sprich den (voneinander unabhängigen) Adressräumen von Prozessen, NICHT im RAM.
    UND: in letzterem sind die Zugriffe ohnehin "verschmiert", denn die Abbildung von virtuellen auf physikalische Speicherseiten/bereiche ist IMMER "zufällig".

    "Und ganz neben her, pulverisiert man mal kurz nebenher auch die sehr oft effizienteren sequentiellen RAM Zugriffe."
    AUTSCH: das ist VÖLLIGER KWATSCH, s.o.; wer solchen Schwachsinn absondert hat von Speicherverwaltung oder (modernen) Betriebssystemen schlicht KEINE Ahnung!

    • Mira Bellenbaum sagt:

      Sind Deiner Meinung nach nur die Aussagen quatsch,
      oder zweifelst Du auch die Ergebnisse an?

      • Stefan Kanthak sagt:

        Ersteres!
        Nur: wieso fragst Du? Die Beobachtungen des Verhaltens und damit auch die Messungen habe ich nicht erwähnt und somit auch nicht bezweifelt, sondern lediglich die an den Haaren herbeigezogene Schlussfolgerung, dass ASLR bzw. deren "Verwürfelung im RAM" schuld sei.

        • Mira Bellenbaum sagt:

          Ich fragte, weil ich Deinen Kommentar so auffasste, als hätte Alex absolut keine Ahnung,
          und somit alles Quatsch.
          Da habe ich Deinen Kommentar falsch verstanden und/oder missinterpretiert.
          Sorry.
          Ich ja nun dank meiner Nachfrage geklärt.

    • Alexander Fuchs sagt:

      Moin Stefan,

      > „AUTSCH: ASLR alias "Address Space Layout Randomisation" wirkt im VIRTUELLEN Speicher, sprich den (voneinander unabhängigen) Adressräumen von Prozessen, NICHT im RAM."

      du weist aber schon was virtueller Speicher ist?

      > „UND: in letzterem sind die Zugriffe ohnehin "verschmiert", denn die Abbildung von virtuellen auf physikalische Speicherseiten/bereiche ist IMMER "zufällig"."

      Und auch das ist mir neu, kannst du das mit einem Fachartikel auch belegen.

      > „AUTSCH: das ist VÖLLIGER KWATSCH, s.o.; wer solchen Schwachsinn absondert hat von Speicherverwaltung oder (modernen) Betriebssystemen schlicht KEINE Ahnung!"

      https://learn.microsoft.com/en-us/dotnet/api/system.io.memorymappedfiles.memorymappedfile.createviewstream?view=net-7.0

      https://learn.microsoft.com/en-us/dotnet/api/system.io.memorymappedfiles.memorymappedfile.createviewaccessor?view=net-7.0

      😉

      Gruss Alex

      • Stefan Kanthak sagt:

        "du weist aber schon was virtueller Speicher ist?"
        Dummerweise erst seit 50 Jahren.
        JFTR: bereits die von Dir als Referenz angeführten M$DN-Artikel zu Schnittstellen von .NET (IGITT!) zeigen ÜBERDEUTLICH, dass Dir Grundlagen fehlen.
        Informiere Dich einfach mal über Betriebssysteme wie RCAs TSOS und ähnliche, die seit 55+ Jahren auf dem Markt sind, und deren Implementation des virtuellen Speichers per "demand paging".
        https://de.wikipedia.org/wiki/Paging

        • Alexander Fuchs sagt:

          Moin Stefan,
          > "Informiere Dich einfach mal über Betriebssysteme wie RCAs TSOS und ähnliche, die seit 55+ Jahren auf dem Markt sind, und deren Implementation des virtuellen Speichers per "demand paging"."

          danke, aber ich weis sehr genau wie der Trick mit der Referenztabele und deren Verweis auf den echten RAM und den Fake-RAM funktioniert.
          Und spätestens wenn das von dir angesprochene OS-MemoryManagement, die Zugriffe auf die Fake-RAM Adressbereiche ständig random fährt, ist es einfach nur dämlich, weil es einer HDD und auch SSD, worauf der Fake-RAM-Teil schlussendlich abgebildet ist, es ganz sicher nicht egal ist, ob man auf deren Speicherplatz sequentiell oder random zugreift. 😉

          Beste Grüsse aus BaWü
          Alex

          • 1ST1 sagt:

            Und auf das Swapfile kann man an der CPU/MMU vorbei per DMA von der Netzwerkschnittstelle aus zugreifen? Da hat doch das eine mit dem anderen nichts zu tun!

          • Stefan Kanthak sagt:

            "Zugriffe auf die Fake-RAM Adressbereiche ständig random fährt"
            Nochmal, für die gaaanz Doofen und Begriffstutzigen: die Zuordnung virtueller Adressen zu physikalischen Adressen wird von ASLR GAR NICHT beeinflusst.
            Du beweist damit nur erneut, dass Du keine Ahnung von Speicherverwaltung hast. PUNKT!
            Übrigens: IO-MMU und "scatter/gather" gibt's auch schon seit dem letzten Jahrtausend. "large pages" ebenso.

          • Paul sagt:

            Wer swappen muss hat verloren.
            Auch mit SSD lagert man nicht aus.
            Hat aber noch weniger mit der Relocierung zutun.
            Kann einer sagen, wieso Alsr denn Rechenzeit kosten soll.
            Der Loader trägt ein paar Relocierungen ein und gut ist.
            Das Zeug zur Laufzeit im Speicher hinundzuschieben ist sinnlos.

    • Alexander Fuchs sagt:

      Moin Stefan,
      > „AUTSCH: ASLR alias "Address Space Layout Randomisation" wirkt im VIRTUELLEN Speicher, sprich den (voneinander unabhängigen) Adressräumen von Prozessen, NICHT im RAM."

      Ich habe mich die Tage etwas intensiver mit dem ASLR Thema befasst und ich glaube in deiner oberen Aussage steckt ein gravierender Fehler.

      Den so wie ich das Ganze aktuell verstehe, wirkst ASLR eher zwischen dem virtuellen Speicher und dem physikalischen Speicher. Es verwürfelt vereinfacht ausgedrückt, quasi die Pages eines zugewiesenen virtuellen Speicher-Arrays, +- querbeet über das Array des physikalischen Speichers.

      Wenn man nun diese im RAM liegenden Daten über deren physikalische RAM-Adressierung auslesen/manipulieren möchte, dann ist das dank ASLR tatsächlich nicht ganz so einfach.

      Aber … ASLR verwürfelt zwar die Daten über den physikalischen Adressraum, es verwürfelt jedoch so wie es sich für mich aktuell darstellt, NICHT die Adressierung innerhalb des virtuellen Speichers, zumindest nicht bei Windows. 😔

      Lade dir einfach mal HxD runter, starte es als Administrator, drücke Umsch+Strg+m, wähle einen laufenden Prozess aus und dann siehst du was ich meine.

      Beste Grüsse aus BaWü
      Alex

  2. Paul sagt:

    Das Aslr macht nur m. E. dann Sinn, wenn der "Besuch" noch nicht auf der Kiste ist.
    Will man einen Stack overflow von Aussen auslösen, muss ich wissen welche (logische) Adresse ich für meine Routine auf den Stack legen muss, damit das Angegriffenen Programm "falsch" zu meinem Code zurückkehrt, oder wohin die pointer zeigen sollen.
    In sofern ist das (wenn die Adressen hinreichend zufällig sind) m. E. keine Augenwischerei.
    "Remote" kann ich nicht sehen wo mein böser Code geladen wurde. Viele Versuche habe ich auch nicht, denn Fehlersuche werden zum killen fer Task oder gar BSOD führen.
    Wenn man den Supervisor übernehmen kann, dann hat das Aslr keinen wirklichen Schutz. Ja.

    Eigentlich ist da noch ein Memory Mapping zwischen.
    Warum das so viel Zeit braucht sollte MS mal erklären.

    Anyway
    Sehr interessant, danke.

    • 1ST1 sagt:

      Doch, macht auch Sinn, wenn ASLR auch aktiv ist, wenn der Besuch schon auf der Kiste ist. Stichwort Spectre/Meltdown.

      • Alexander Fuchs sagt:

        Moin 1ST1,

        > "Doch, macht auch Sinn, wenn ASLR auch aktiv ist, wenn der Besuch schon auf der Kiste ist. Stichwort Spectre/Meltdown."

        wenn ich lokal privilegierten Zugriff bekomme, was bei Windows und auch den Pinguinen nicht wirklich schwierig ist, dann brauche ich weder Spectre noch Meltdown, um irgendwelchen Schabernack zu treiben. 😉

        Gruss Alex

      • Paul sagt:

        Ja, aber der Becjher bekommt das verschrieben js mit.
        Vorher muß er blind Werte schreiben. Früher waren die immer gleich. Irgendwann vor 40 Jahren fing man bei Unix an diese Lücke zu schließen.
        Das ist aber nicht fas Problem hier.

    • Alexander Fuchs sagt:

      Moin Paul,
      > "Das Aslr macht nur m. E. dann Sinn, wenn der "Besuch" noch nicht auf der Kiste ist."

      👍👍👍 und genau deswegen bezeichne ich auch einige Features, die für die Umgebungen von den meisten Normalsterblichen absolut keinen Nutzen bringen, sondern nur Performance fressen auch als Murks. Zumindest wenn diese per Default pauschal aktiviert sind.

      Beste Grüsse aus BaWü
      Alex

    • Alexander Fuchs sagt:

      Moin Paul,

      > "Eigentlich ist da noch ein Memory Mapping zwischen. Warum das so viel Zeit braucht sollte MS mal erklären."

      Das Problem ist auch nicht die Mitigation selbst.
      Auf der Windows 10 22H2 Workstation sind dieselben Mitigations aktiviert wie auf der Windows 11 22H2 Workstation. Nur verhalten sich diese auf der W11, so wie es aussieht etwas anders wie auf der W10 Workstation.

      Ich habe den Microsoftians schon den Hinweis zugesteckt, dass das Problem an einer Änderung der Mitigationverhaltens bei W11 liegen könnte, habe darauf bis jetzt jedoch keinen Feedback bekommen.

      Gruss Alex

  3. Aaron sagt:

    Meines Wissens nutzt Windows 11 per default massive Virtualisierung (z.B. Browser und Kern-Isolation) weshalb die Aussage, dass VM-Ausbrüche nur auf Servern eine Gefahr darstellen bzw. dort anzutreffen sind, wohl nicht korrekt ist.

    • Alexander Fuchs sagt:

      Moin Aaron,
      > "Meines Wissens nutzt Windows 11 per default massive Virtualisierung (z.B. Browser und Kern-Isolation) weshalb die Aussage, dass VM-Ausbrüche nur auf Servern eine Gefahr darstellen bzw. dort anzutreffen sind, wohl nicht korrekt ist."

      bei der Kernisolierung ist es ähnlich wie beim ASLR, das Ganze macht wenn überhaupt, dann so nur in einer Public-Cloud Sinn und wenn dann nur auf der Hypervisor ebene. Aber nicht auf der VM selbst und schon gar nicht auf reinen baremetale Systemen.

      Beste Grüsse aus BaWü
      Alex

  4. Paul sagt:

    "Ganz ehrlich, Microsoft hat von performanter und wirtschaftlich effizienter Hardwareansteuerung überhaupt keine Ahnung mehr."

    Naja, die müssen ja irgendwie einen Kompromiss finden und die Leistung der neuen CPU sinnvoll vernichten. Und das sie direkt mit Dir kontakteten macht klar, das denen das schon klar ist.

    Unschön ist das "reift beim Kunden".
    MS hat ein paar tausend Dollar gespart, und ein paar verärgerte Kunden mehr. Aber:
    Was kümmert das einen Monopolisten?

    • Alexander Fuchs sagt:

      Moin Paul,

      > "Naja, die müssen ja irgendwie einen Kompromiss finden und die Leistung der neuen CPU sinnvoll vernichten."

      OK … der ist schön englisch … gefält mir sehr, also ich meine deinen Humor.

      "Und das sie direkt mit Dir kontakteten macht klar, das denen das schon klar ist."

      Ähm, nein, das ist eher so, dass ich denen direkt auf den Sack gehe, weil ich durch einen glücklichen Zufall, mal den Schlüssel dazu bekommen habe. 🤪

      Gruss Alex

  5. Tom Bongers sagt:

    Wir wissen jetzt, dass Alexander die Erkenntnis gewonnen hat, dass der Exploid Schutz zu Einbußen in der Netzwerk Performance führt. Mag auch sein, dass Microsoft das schlecht oder fehlerhaft implementiert hat. Kann auch sein, dass das einfach der Preis für den zusätzliche Schutz ist. Da fehlt mir das notwendige Knowhow um das zu bewerten.

    Auch auf die Gefahr hin einen Nebenkriegsschauplatz zu eröffnen…. sorry dafür.
    Aber die Frage ist doch jetzt, welches Risiko man sich aussetzt, wenn man alle Optionen im Exploid Schutz deaktiviert. Eine Antwort auf diese Frage hätte ich mir dann doch auch zumindest als Randnotiz von Alexander oder von diesem Blog Artikel erhofft.

    Der unbedarfte Leser erfährt hier nur, dass der Exploid Schutz massig Performance im Netzwerkbereich kostet. Also wird er sich denken dann deaktivieren ich den Exploid Schutz einfach. Sind die Risiken die er sich damit einhandelt am Ende größer als der Performance Gewinn?

    • Alexander Fuchs sagt:

      Moin Tom,

      „Der unbedarfte Leser erfährt hier nur, dass der Exploid Schutz massig Performance im Netzwerkbereich kostet. Also wird er sich denken dann deaktivieren ich den Exploid Schutz einfach. Sind die Risiken die er sich damit einhandelt am Ende größer als der Performance Gewinn?"

      1. Diese Optimierungen habe ich in erste Linie nicht für Privatanwender entwickelt, sondern für Unternehmensumgebungen, die Security-Technisch zum einen anders aufgestellt sind und meistens beim Thema Sicherheit eh nicht auf die Komponenten von Microsoft vertrauen.

      2. Viele der Mitigations machen, wenn überhaupt nur in Public-Clouds Sinn, aber keineswegs in einer Private-Cloud.

      3. Einige der Mitigation sollen vor Angriffen schützen, die zwar theoretisch irgendwie möglich sind, die aber so noch NIE in der freien Wildbahn jemals beobachtet wurden, weil diese schlichtweg absolut ineffektiv sind.

      4. Was bringen diese ganzen Mitigations, vor allem lokal gesehen, wenn diese per default bei sehr vielen und meistens von Microsoft selbst stammenden Programmen eh deaktiviert sind und ansonsten diese mit ein Power-Shell Einzeiler, Systemweit auch alle deaktiviert werden können?

      5. Warum zur Höhle macht man überhaupt diese bescheuerten Mitigation und beseitigt das Problem nicht gleich an der Wurzel?
      Das sind z.B. die Fragen die ich mir bei dem Thema stelle.
      Ausserdem findet es keiner meiner Kunden wirklich lustig, >100K für neue und zum Teil X-Mal schnellere Hardware auszugeben, die dann nur -50% der Anwendungsperformance der zum Teil 10 Jahre älteren Hardware liefert.

      Gruss Alex

      • Tom Bongers sagt:

        Mir ging es in Erster Linie darum, dass es bei Günter Born hier auf dem Blog sehr viele Besucher gibt und der ein oder andere davon eben vermutlich wirklich nicht das technische KnowHow hat, das Ganze umfassend zu bewerten. Davon will ich mich selber übrigens gar nicht ausnehmen.

        Wir wissen doch, wie es läuft, da gibt es Leser, die jetzt gelernt haben das man durch die Deaktivierung des Exploid Schutz zu einer spürbar besseren Netzwerkperformance kommt. Und viele werden den Schutz dann eben deaktivieren. Ist wie mit vielen Tuning Tools, die mehr oder weniger blind durchgeklickt werden.

        Ich fände es dann eben einfach sinnvoll in dem Blog Artikel kurz auf die Gefahren einzugehen.

        Ein kurzer Satz, dass der Privatanwender den Exploid Schutz nicht deaktivieren sollte würde schon ausreichen. Oder eben wenn der Exploid Schutz für den Privatanwender ohnehin sinnfrei ist, eben ein Hinweis in diese Richtung.

      • Cornelia sagt:

        "4. Was bringen diese ganzen Mitigations, vor allem lokal gesehen, wenn diese per default bei sehr vielen und meistens von Microsoft selbst stammenden Programmen eh deaktiviert sind und ansonsten diese mit ein Power-Shell Einzeiler, Systemweit auch alle deaktiviert werden können?"

        Sehr interessanter Punkt. Microsoft 'optimiert' als die eigene Software, aktiviert aber grundsätzlich die Einstellung im Betriebssystem. Das ist schon sehr fragwürdig.
        Warum wird nicht gleich die Verantwortung für die Aktivierung dem Benutzer/Administrator überlassen mit einer entsprechenden Warnung auf mögliche Nebenwirkungen?

      • 1ST1 sagt:

        Microsoft muss eigentlich (ok, früher haben sie das nicht so gehandhabt) immer vom "Worst Case" ausgehen, sprich keine Netzwerksegmentierung, keine intelligenten Firewalls dazwischen, welche bekannte Angriffsvektoren aus Netzwerkpaketen schon herausfiltern kann, usw. Schließlich setzen nicht nur milliardenschwere Großunternehmen solche Server ein, sondern im unidealsten Fall der kleine Handwerker bei dem alles in einem Netz hinter einem simplen DSL-Router steht und auch ungehindert rausfunken kann, vielleicht noch das eine oder andere Portforwarding weils ja so schön praktisch ist, ….

        Unter der Betrachtung macht es vielleicht tatsächlich Sinn, dass man den Exploit-Schutz unter Idealbedingungen tatsächlich ausschalten kann, wenn das Ding, der Cluster, …, tatsächlich entsprechend abgeschottet ist. Aber wehe, ein Angreifer schafft es irgendwie doch in das VLAN rein und kann dort aktiv werden…

    • Mira Bellenbaum sagt:

      Zitat:
      "…. Das ist ein absolut billiger Taschenspieler-Trick um ein Problem zu kaschieren, welches wahrscheinlich >99% der Anwender, schlichtweg nicht betrifft.

      Denn damit machen die es einem Angreifer lediglich das Leben etwas schwerer, z.B. aus einer anderen VM heraus, über sehr komplizierte Angriffswege, die bisher in der freien Wildbahn übrigens noch nie gesehen wurden, den Inhalt des Hauptspeichers einer anderen VM auszulesen. "

      Interpretiere ich so, "Risiko ist zwar gegeben, aber geht gegen Null!"
      Aber was ist heute schon ohne Risiko?
      Und den Stecker ziehen, würde zwar das Risiko einer Infektion, bzw. eines Angriffs aus dem Netz
      zu 100 % verhindern, wäre aber, so glaube ich, kontraproduktiv.

      • Stefan Kanthak sagt:

        "Risiko ist zwar gegeben, aber geht gegen Null!"
        AUTSCH! Die von Dir zitierte Aussage "Taschenspielertrick" ist hanebüchener Quatsch, jeder Versuch einer Schlussfolgerung daraus somit dumm: "ex falso quodlibet".
        Die einzige Erkenntnis ist, dass der bereits mit Windows 10 1607 eingeführte "exploit guard" und/oder die ebenfalls schon in Windows 10 aktive "exploit protection" unter Windows 11 NOCH MEHR negative Auswirkungen haben.

        • Mira Bellenbaum sagt:

          Wenn Du meinst.
          Dann ist es ja gut, dass man bei Gefahr die Augen zu machen kann,
          denn dann besteht sie ja nicht mehr!

          Genau das ist nämlich der "Taschenspielertrick"!

          Und wenn das Risiko eines Hacks vorher nur ein theoretisches Risiko war,
          ist es nach diesem "Würfelspiel" immer noch, nur dass halt alles etwas länger braucht.

          Ergo, das Risiko bestand vorher in der Theorie und hinterher ebenso.
          Folgerichtige Schlussfolgerung:
          "Das Risiko ist zwar gegeben (in der Theorie),
          (da es aber ein solches Szenario noch nie gegeben hat,)
          geht (es) gegen Null!"

          • Stefan Kanthak sagt:

            "Wenn Du meinst."
            Rate mal, wieso mein Name als einziger unter den "Acknowledgements" des M$FT-Sicherheitsbulletins zu Stuxnet steht? Oder auf den ersten 3 Jahrgängen der MSRC Top 100 Security Researcher?

            "Und wenn das Risiko eines Hacks vorher nur ein theoretisches Risiko war,…"
            Dummerweise trifft das "wenn" NICHT zu: es gibt genügend erfolgreich praktizierte Angriffe, auch von aussen, über's Netzwerk, ohne Authentifizierung.

          • Alexander Fuchs sagt:

            Moin Mira,

            > "Also wenn ich es von außen auf ein System geschafft habe,
            habe ich wahrscheinlich mir nicht nur Administrator-Privilegien
            (Rechte) verschafft, sondern eventuell sogar Systemrechte."

            > "Wie sonst lassen sich so manche Wochen-, Monate- oder gar Jahrelange kompromittierte System erklären."

            👍👍👍 genau das ist der springende/traurige Punkt. Den sobald man lokalen Zugriff auf ein System hat, ist der weg zu privilegierten Rechten für einen geübten ITler nicht wirklich sehr weit. Und sobald man privilegierte Rechte erlangt hat, sind die meisten Schutzmassnahmen in Windows, meiner Ansicht nach so gut wie wertlos.

            Und genau aus diesem Grund ist ASLR als lokaler Schutz aus meiner Sicht auch weitestgehend nutzlos.

            Na ja, wenn man es genau betrachtet, dann haben auch die ganzen Pinguine, +- genau dasselbe Problem (root). 😔

            Beste Grüsse aus BaWü
            Alex

      • Alexander Fuchs sagt:

        Moin Mira,
        > „Interpretiere ich so, "Risiko ist zwar gegeben, aber geht gegen Null!""

        ja, korrekt. Diese Mitigations schützen zwar den Inhalt des RAM's halbwegs effektiv gegen Angriffe von Aussen, diese Angriffe sind jedoch sehr komplex und wurden so in der freien Wildbahn, meines Wissens nach auch noch nie beobachtet.

        Und von innen gesehen fallen mir duzende andere Möglichkeiten ein, wie ich an Informationen kommen könnte, ohne diese Aufwändig aus dem RAM zu kratzen.
        Und wenn ich doch sehen möchte was im RAM steht, dann mache ich einfach einen Memory Dump und analysiere diesen gemütlich im Nachgang.

        Ich habe in den letzten Jahren leider schon duzende Incidents betreut und mir fällt kein einziger davon ein, wo diese ganzen Mitigations auch nur ansatzweise etwas verhindert hätten. 😔

        Was jedoch die Performance der Systeme unserer Kunden angeht, so haben mir diese Migitaions, vor allem im Nachgang betrachtet, durchaus sehr viele graue Haare beschert.

        Beste Grüsse aus BaWü
        Alex

        • 1ST1 sagt:

          "Und wenn ich doch sehen möchte was im RAM steht, dann mache ich einfach einen Memory Dump und analysiere diesen gemütlich im Nachgang."

          Na dann viel Spaß beim ASLR-sortieren! Und, braucht man genau dafür Attacken wie Spectre/Meltdown? Und man muss erstmal die verhaltensbasierte AV-Erkennung umgehen, EDR/XDR, …

          • Alexander Fuchs sagt:

            Moin 1ST1,

            > "Na dann viel Spaß beim ASLR-sortieren! Und, braucht man genau dafür Attacken wie Spectre/Meltdown? Und man muss erstmal die verhaltensbasierte AV-Erkennung umgehen, EDR/XDR, …"

            na ja, wenn die Memory Dumps wegen ASLR deiner Ansicht nach keinen Sinn machen, warum werden diese dann bei einem Crash immer noch erstellt?

            Googel mal einfach, dann siehst du selbst, wie einfach sich ASLR umgehen/austricksen lässt. 😔

            Und, by the way, nein du kannst nicht per DMA/RDMA auf den Swap-Space zugreifen, auf den physikalischen RAM selbst jedoch schon. 😉

            Gruss Alex

        • Stefan Kanthak sagt:

          "Und wenn ich doch sehen möchte was im RAM steht, dann mache ich einfach einen Memory Dump und analysiere diesen gemütlich im Nachgang."
          AUTSCH: was machst Du nochmal beruflich?
          Zugriff auf den Hauptspeicher alias RAM setzt Administrator-Privilegien voraus! Zugriff auf Prozesse anderer Nutzer (und deren Adressraum) ebenfalls.
          Das einzige was Du gemütlich bescheiden Auslesen kannst sind die Adressräume Deiner eigenen Prozesse.
          Und jetzt: LERNE ENDLICH DIE GRUNDLAGEN!
          Wissen Deine Kunden eigentlich, dass Du ein Scharlatan bist?

          • Alexander Fuchs sagt:

            Moin Stefan,

            > "LERNE ENDLICH DIE GRUNDLAGEN!
            Wissen Deine Kunden eigentlich, dass Du ein Scharlatan bist?"

            https://www.mandiant.com/resources/blog/six-facts-about-address-space-layout-randomization-on-windows

            Sprich, du kannst deine Kunden von mir aus mit deiner Theorie weiterhin beweihräuchern wie du möchtest.

            Und ich setze bei meinen weiterhin auf Realität und Praxis.

            Beste Grüsse aus BaWü
            Alex

          • Jeremy sagt:

            @Alex
            Du musst deine Beiträge nicht signieren. Der Name steht oberhalb vom Beitrag. In Foren steht er meist links.

            Das Internet ist kein Brief mehr von 1800. Dank Forensoftware ist die "Visitenkarte" immer angeheftet.

          • Mira Bellenbaum sagt:

            Wow, mit harten Bandagen wird hier gekämpft!

            Also wenn ich es von außen auf ein System geschafft habe,
            habe ich wahrscheinlich mir nicht nur Administrator-Privilegien
            (Rechte) verschafft, sondern eventuell sogar Systemrechte.

            Wie sonst lassen sich so manche Wochen-, Monate- oder gar
            Jahrelange kompromittierte System erklären.

  6. oli sagt:

    Exploit-Schutz, hatte ich mir schon gedacht. Verstehe nur nicht, warum Windows 10 davon nicht betroffen ist, das hat obig erwähnte ASLR-Einstellungen nämlich genauso drin und die sind auch standardmäßig aktiv. Wurde mal das Deaktivieren von HCVI-/VBS-Kram getestet?

  7. Dolly sagt:

    "Exploit-Schutz" = ständiger Deep Packet Inspection Netzwerk Monitor = praktische Schnittstelle für totale Überwachungswerkzeuge?

  8. 1ST1 sagt:

    Äußerst interessantes Ergebnis. Die Ansicht von S.K bezüglich ASLR teile ich, logische Adressen haben schon lange nichts mehr mit physischen Adressen im RAM zu tun, nämlich spätestens seit Windows Arbeitsspeicher in ein Swap-File auslagern kann. Schon 386er CPUs haben für die Übersetzung von logischen RAM-Adressen auf pyhsische Adressen eine MMU (das gabs übrigens auch schon für 68020 als Extra-Chip und ab 68030 integriert) und schon EMM386.exe für DOS macht davon reichlich Gebrauch.

    In Richtung "Azure" zu kicken, mag zwar hipp sein, aber ob das der wahre Grund ist? Microsoft wird die lokalen Server in den Firmen und die "Fat-Clients" wohl noch auf Jahre/Jahrzehnte supporten müssen, weil ein Großteil der Kunden nicht vollständig in die Cloud gehen wird. Es ist IMHO eher so dass mit dem Exploit-Schutz nur ein Workarround um einen vielleicht komplett löchrigen TCP/IP-/SMB-/…-Stack herumgebaut wurde, um da das Gröbste (per Filter, Mustererkennung, KI, …) abzufangen? Prio wäre ja wohl eher die Ursachen zu beheben, oder? Vielleicht schafft man das aber nicht, ohne die Kompatiblität mit einer zu hohen Geschwindigkeit bei den Änderungen zu bricken? Siehe die Zeiträume bei Einführungen von Verbesserungen an Kerberos & Co. (Diese Kompatiblität geht sogar so weit, dass Linux-SMB-V4 letztes Jahr schon die gleiche Sicherheitslücke aufwies, wie das Original.)

  9. Luzifer sagt:

    Die Erkenntnis ist letztendlich: Microsoft beherscht ihren eigenen Code nicht mehr und das seit sie angefangen haben Ihr OS in Bloatware zu wandeln!

    Jetzt nicht wirklich eine Erkenntnis die neu ist ;-P

    Tja nur sind die Alternativen schlichtweg nicht vorhanden!

  10. Wetterchen sagt:

    Auf Firmen Ebene kommt für mich Win11 und Win2k22 bis 2025 nicht in Frage. Zuviel Krimskrams was MS da noch einbauen und/oder verbessern will. Es reicht ja schon, wenn man die ganzen Updates Bugs unter Win10 nach jeden Patchday aushalten musst.

    Daher danke für die Mühen und Lösungsansätze.

  11. techee sagt:

    Mal ne Frage:
    Betreffen die Performance einbußen nur 10Gbit Netzwerke?
    Habe auf die schnelle auf einigen 1Gbit angebundenen Systemen versucht zu testen,
    aber bekomme zumindest mit dieser Anbindung immer nur Bestwerte.

    • Günter Born sagt:

      Könnte schon sein, dass das bei 1 GBit nicht zum Tragen kommt – ist ja Sinn der Übung, die Sachen offen zu legen, so das jeder schnell testen kann, ob es einen Einfluss hat.

    • Joerg sagt:

      ich habe es bisher nicht geschafft, mit MS Boardmitteln einen 10G Link auf Last zu fahren, mit anderen Tools wie z.B. FTP, netio oder zwischen zwei Linux Clients kein Problem, aber von MS zu MS z.B. via SMB, CIFS, NFS oder was auch immer noch nie, weder mit aktuellen noch mit älteren OS Versionen.

      Kann mich auch noch gut an P1+P2 Zeiten erinnern, wo die ersten 3com Karten (3C905 Serie glaube ich) herauskamen die eine Schnittstelle zum Mainboard hatten, womit dann die Berechnung fürs Netzwerk von der CPU auf die Netzwerkkarte geschoben wurden, dass hat damals richtig Leistung gebracht :)

      Was hier bei uns immer wieder auffällt, seit November benötigen verhäuft die Windows 10 und 11 Client einen Reset des TCP Stacks weil DNS plötzlich nicht mehr will, ist ein Einzeiler, aber ist schon nervig (das hat jetzt nichts mit dem Script von Alexander zu tun).

      • Günter Born sagt:

        Dazu wollte ich noch was separat schreiben – auch da gibt es einen Bock, den Alexander aufgedeckt hat.

      • Paul sagt:

        "Was hier bei uns immer wieder auffällt, seit November benötigen verhäuft die Windows 10 und 11 Client einen Reset des TCP Stacks weil DNS plötzlich nicht mehr will, ist ein Einzeiler, aber ist schon nervig (das hat jetzt nichts mit dem Script von Alexander zu tun)."

        Upps, aber vielleicht mit dem ungelösten Problem das die Taskleiste sekundenlang nicht reagiert?

        Das sich der TCP stack so zerlegt ist ungewöhnlich,
        wo bei DNS auch UDP ist :)

        • Alexander Fuchs sagt:

          Moin Paul,

          > Das sich der TCP stack so zerlegt ist ungewöhnlich,
          wo bei DNS auch UDP ist :)

          ja, das ist schon sehr schräg was da mit dem TCP-Stack passiert.

          🤔 … mein Kollege schraubt gerade zwei i9-12900K PowerWorkstations für einen Kunden zusammen.
          Sobald das Windows11 auf diesen installiert ist, sehe ich einen weitere Testlauf auf diesen Zukommen.
          Einmal kurz die Perfomance mit Installationsdefault messen, danach den TCP-Stack reseten und nochmals testen. Und schon sehen wir, ob's zwischen dem Installationsstandardeinstellungen und den Reseteinstellungen, einen Unterschied gibt.

          Gruss Alex

    • Alexander Fuchs sagt:

      Moin techee,
      > "Betreffen die Performance einbußen nur 10Gbit Netzwerke?"

      nein, die Performanceeinbussen betreffen auch 1G Verbindungen und auch darunter, weil ich das Skript ehrlich gesagt nicht primär dafür ausgelegt habe, den bestmöglichen Maximaldurchsatz zu jedem Preis zu erzielen, sondern eher die bestmögliche, sprich, niedrigste Latenz (bei Transaktionen) zu erreichen.
      Und genau an dem letzten Punkt, der Latenz, hat Microsoft in letzter Zeit besonders gepatzt und oder schlichtweg nicht mehr auf diese geachtet. 😔

      Beste Grüsse aus Singen
      Alex

  12. Sigi sagt:

    Ich hoffe, dass ich den Artikel nicht allzu gedankenlos überflogen habe, aber irgendwie fehlt mir, welches Setting denn jetzt genau deaktiviert wurde?
    Unter "Exploit-Schutz" kommen noch X andere Settings.
    Wurde jetzt alles deaktiviert oder nur ALSR oder oder?

    • Günter Born sagt:

      Zitat von Alexander aus dem Artikel: Ich habe bisher nicht alle einzeln durchgetestet, sondern sowohl als den beiden Windows 11 und Windows 10 Workstations mal alle deaktiviert und konnte danach sofort ein viel gesünderes Verhalten des TCP-Stacks beobachten.

    • Alexander Fuchs sagt:

      Moin Sigi,

      > "Unter "Exploit-Schutz" kommen noch X andere Settings.
      Wurde jetzt alles deaktiviert oder nur ALSR oder oder?"

      ich hatte lediglich die 7 Migitations die über die GUI konfigurierbar sind deaktiviert und hatte gleich danach bei der W11 Workstation ein viel gesünderes TCP-Verhalten. Bei der W10 Workstation, hatte das Abschalten dieser sieben Migitations, jedoch nicht viel bewirkt.

      Wie sich das Ganze verhält, wenn ich die anderen 18 Migitations, die über die GUI nicht sichtbar sind, auch noch per Power-Shell rausklopfe, muss ich erst rausfieseln. Habe dazu momentan aber nicht wirklich viel Zeit übrig.

      Beste Grüsse aus BaWü
      Alex

  13. Tom sagt:

    ASLR ist Mist, das bringt überhaupt nichts, deswegen hat das heute jedes moderne Betriebssystem… wait…

  14. janil sagt:

    Hab ASLR komplett deaktiviert, bin allerdings kein Cloudspeicherer, das System läuft schneller und gefühlt funktioniert Internet geschmeidiger.
    Mein Eindruck.
    Danke Alexander für die viele Arbeit und die daraus resultierenden Hinweise.

  15. Anonymous sagt:

    ich konnte ähnliche probleme auch schon unter windows 2016 feststellen (auch in verbindung mit hyperv). deaktivieren von rsc coalescing im hyperv oder/und vm kann helfen (es waren aber nie alle VMs oder Clients betroffen, je nach Betriebsystemen die involviert waren, gab es die verrücktesten phänomene).

    neuerdings haben wir auch performance problemen in verbindung mit antivirenscannern und exploit schutz. vielleicht basieren diese auf den windows exploit schutz?

  16. Norddeutsch sagt:

    Ihr Lieben – selten einen Thread mit so vielen Spezialisten gesehen. Wollen wir zusammen finden?

    @Alexander – Ich schätze Deine Arbeit, Mühe, Kunden- + fundierte Praxisorientierung
    @Stefan – ich schätze Deine tiefes Wissen, welches ich selbst im Audit zur geekigen + gemeinen Überprüfung von Admins nutzte.
    @Mira – Überlegungen (zB Risk Management Perspektive) find ich grundsätzlich berechtigt und sauber
    @1ST1 – wie immer souverän, ich mag Dein Abwägen ;-)

    Nur Euer herumgehacke mag ich weniger :-) Bei Win halt ich mich seit W8 raus.
    @Tom Bongers fasste es für mich gut auf dem (imho gar nicht) Nebenschauplatz zusammen. Vielleicht mag jemand Einsteigen, um fachlichen Krieg zu verhindern – ich spende meine Literaturlinks zum Thema, leider leicht Linuxlastig – aber VM, ASLR, Speichermanagement-Basics oder Sidechannel ist vielleicht anschaulich für Einige Leser:

    – Effectiveness of Full-ASLR (Mapping, Exploit in <1s, Bilder+Bsp, Uni Valencia)
    – KASLR is Dead: Long Live KASLR (KAISER, Performance, Bench, UNI Graz)
    – Security, AMD's Cache Predictors (ASLR,KASLR, exploit, Cache attack,UNI Graz)
    – Virtual Memory VM (gute Abbildungen + Pagetablegeraffel, UNI California)

    VM, ASLR, KASLR, VM sind komplex, Selbst Randthemen wie MALLOC: riesig … Angriffe teils nur theoretisch, teils mit kleinem „p", teils eher undenkbar, teils sogar CPU und Hardwarespezifisch (Hab bis heute zu ASLR und Spectre nicht alles verstanden).

    Klein(e,ste) Eintrittswarscheinlichkeit „p" (da herrscht wohl grobes „Ja" bei Allen)
    – jedoch ist größeres Risiko/Schaden wohl möglich (wieso nicht mitigieren wenn's geht, auch wenn @Stefan@10:58 viel bequemere Attacks kennt?)
    – Größerer Performanceimpact Windows (Microsoft? Wieso nur? Bei Linux merk ich fast nix bei Performance :-p … )

    • Alexander Fuchs sagt:

      Moin Norddeutsch,

      > „Nur Euer herumgehacke mag ich weniger :-) "

      glaub mir, diese Entgleisungen sind mir auch ein Dorn im Auge, vor allem wenn diese zu sehr in die Theorie gehen.

      Folgendes Beispiel.
      Während die einen schreiben, „Alex, wie kannst du nur TCP-Delay und Delayed-ACK ausschalten, das ist kontraproduktiv und senkt die Performance", muss ich vom John Nagle, dem Entwickler des TCP-Delay (Nagle's Algorithmus) selbst, +- den folgenden Wortlaut lesen …

      „Wie kommen die überhaupt auf die Idee, meinen Algorithmus zusammen mit Delayed-ACK zu aktivieren, das ist absolut kontraproduktiv. Ich habe damals diesen Algorithmus übrigens für ein ganz bestimmtes Problem entwickelt und nicht für das wozu es heute "misbraucht" wird."

      Und dann schreibt er noch.

      "Aber das ist nun euer Problem, den ich züchte schon lange Blumen"

      Und nein, das ist kein Scherz.

      Die Originallinks, wo das jeder selbst nachlesen kann, werde ich nachreichen, sobald ich wieder in der Heimat bin. Sprich, wenn die Bahn keinen Murks macht, dann so Richtung heute Nachmittag.

      Und so ähnlich sieht es mit sehr vielen anderen Features in Windows aus, die ursprünglich für einen bestimmten Zweck entwickelt wurden, heute jedoch für alles Mögliche verwendet werden, ohne dabei wirklich einen Nutzen zu bringen. 😔

      Ich sag nur das dämliche Windows-Software-Caching, welches vielleicht bei HDD's einen Nutzen gebracht hat, aber ganz sicher nicht bei SSD's, den hier bewirkt es in den meisten Fällen genau den Gegenteil, nämlich eine Verschlechterung der Leistung und keine Verbesserung … 🤢

      Und dann noch die elenden Lazy-Wirites dazu und schon war ist, von der Anwendung bis gegen das Endstorage gesehen, jegliche anständige Latenz beim Schreiben hin. 🤮

      Die die meine Aktivitäten die letzten Jahre verfolgt haben, wissen eh, dass dieses Thema hier, ein „Nebenkriegsschauplatz" eines ganz anderen Kampfes ist und zwar dem Thema der immer schlechter werdenden Performance der Serverbetriebssysteme/Hyper-V, insbesondere ab Server 2019.

      Und an all die habe ich heute eine sehr positive Nachricht
      Ich komme von einem Kunden zurück, dessen Hyper-V 2022 Cluster, gemäss der verbauten Hardware, nun mit einer ähnlichen Effizienz und auch Performance läuft, wie ich das auch von einem Hyper-V 2012R2/2016 Cluster kenne. 😁
      Das ist übrigens schon das zweite System bei dem das so ist.

      Und so wie es aussieht lässt sich dadurch auch dieses Problem beheben …
      https://community.spiceworks.com/topic/2468243-the-windows-horror-story-season-004-the-rss-numa-core-jumble

      Das muss ich aber noch etwas genauer durchtesten, es sieht aber >90% danach aus. 😀

      Weitere Infos folgen.

      Beste Grüsse von irgendwo zwischen Singen und Murrhardt
      Alex

    • Alexander Fuchs sagt:

      Moin Norddeutsch,

      ich merke gerade, dass ich mein viertes Hirn (Obsidian Notes) in einer halbwegs aktuellen Fassung dabeihabe. 🤪

      Sprich, folgend die Links zu den angesprochenen Äußerungen von John Nagle selbst.

      https://lists.bufferbloat.net/pipermail/bloat/2016-April/007235.html

      Gruss Alex

      • Norddeutsch sagt:

        @Alex …… soll man lächeln oder weinen… witzig, DANKE!
        Erinnert mich auch an gute alte Zeiten – war mal beim Reseller von Sun Microsystems. Da gabs solche Probleme nicht. Alles sauber durchdekliniert bis zu Setting XY, Einbauanleitung für 15.000DM CPUs selbst bis zur Bomben-Verpackung: ALLES 1A.
        Hab mal ein Storagesytem für 40000DM einer Norddeutschen Zeitung nach Unfall (unverschuldet, Autobahnleitplanke, PKW auf ganzer Seite kaputt ) mit defektem PKW ausgeliefert: Lief alles, Super Stossfeste Verpackung, 2000 gabs noch Qualität :-)

        Bei Euch würd ich sicher gern arbeiten.

        Nur um Euch noch einmal lächelnd zu verdeutlichen auf welch {| abstraktem | mathematisch belegbarem | in Praxis nachweisbarem | ein-ein-deutigem | 1:n Kardinalitäts |} Niveau Ihr Euch hier über die "Verbesserungspotentiale" und technischen Feinheiten mit "keine Ahnung" oder "Quatsch" aus verschiedenen Sichweisen wie Praxis, Angreifbarkeit oder Risiko kabbelt …

        Kontrast als Ablenkung + Abschreckung Mit solch Leistungen bekommen andere einen Doktortitel und sind berühmt:
        … die Doktorarbeit von Karl W. Lauterbach
        Mir sträuben sich wissenschaftlich bei Management, fehlenden KPIs, Informatik- oder Prozess-Sicht , Wirtschaft und selbst Ethik auf jeder 2. Seite die Haare, mehr hab ich leider nicht gelernt :-(

    • Alexander Fuchs sagt:

      Moin Norddeutsch,

      > "– KASLR is Dead: Long Live KASLR (KAISER, Performance, Bench, UNI Graz)"

      zu dem Thema Performancekosten von ASLR habe ich dieses Wochenende das folgende rausgefunden.

      Laut dem RAM-Test des Passmark PerformanceTest, welcher übrigens ohne ASLR läuft, erreicht der RAM in meiner Workstation lesend beim Single-Thread eine Leistung von 13814 MB/s und bei Multi-Threads eine Gesamtleistung von 81731 MB/s mit einer durchschnittlichen Latenz von 42ns. Das entspricht dem, was mein RAM laut seiner und der CPU Spezifikation, +- auch leisten sollte. 😁

      Leider konnte ich auch mithilfe der programmgebundenen ProcessMitigation Regeln, durch die man die Nutzung von ASLR bei einzelnen Applikationen eigentlich auch erzwingen sollte, den Passmark PerformanceTest nicht dazu bringen, ASLR zu benutzen. Ich schätze mal das im Passmark Performance Test das „DYNAMICBASE" Flag auf „NO" steht, sprich dieser bewusst ASLR umgeht.

      Und so habe ich mich auf die Suche nach einem Benchmark Programm gemacht, welches den RAM-Test mit ASLR macht. Nach einer Weile bin ich über UserBenchmark gestolpert, welches ähnlich die RAM Performance testet wie der Passmark Performancetest.

      Das was mir der UserBenchmark dann aber als Ergebnis ausgespuckt hat, war leider ganz weit von dem Ergebnis von Passmark entfernt. Den laut diesem, erreicht der RAM in meiner Workstation mit ASLR lesend beim Single-Thread nur noch eine Leistung von 9556 MB/s (~30% weniger) und bei Multi-Threads nur noch eine Gesamtleistung von 42188 MB/s (~48,4% weniger) mit einer durchschnittlichen Latenz von !! 71,8!! Ns (~41,5% schlechter). 🤢🤮🤮🤮

      So viel zum Thema, ASLR frisst keine Leistung. 😔

      Beste Grüsse aus BaWü
      Alex

  17. Alexander Fuchs sagt:

    Moin Zusammen,

    die kleinen Sticheleien bezüglich dieses sagenhaften ASLR, haben mich nun doch dazu bewegt, etwas zu treiben, was ich schon sehr lange nicht mehr getrieben habe. 😁
    Ja, ich habe soeben etwas rumgefummelt … natürlich am RAM-Inhalt meiner Workstation. 🤪

    Und das Ergebnis ist, ASLR hin ASLR her, ich sehe dennoch den RAM-Inhalt eines laufenden Windows-Prozesses und zwar komplett am Stück. 😎

    😮… ferner sehe ich gerade, das viele der von den Microsoftianer selbst kommenden Anwendungen, Ihre Daten immer noch im !!! Klartext !!! im RAM ablegen … 😧

    Nein, nein, nein, warum nur, ich wollte nach diesem ganzen TCP-Murks ausgraben, eigentlich erstmal eine Murks-Grabungs-Pause machen. 😩

    Habe vorhin übrigens Günter per Mail auf eine TeamViewer Sitzung eingeladen, damit er mit seinen eigenen Augen sieht, dass ich hier jetzt keinen Mist erzähle.

    Beste Grüsse aus BaWü
    Alex

    • Norddeutsch sagt:

      Ich will mitspielen !! … na, dann wollma hoffen dass ASLR bei Microsoft neben Performanceproblem nicht nur sowas wie "RAM-Doubler" (Erfahrenere kennen die Story) ist … Wäre an Screenshots interessiert… vll an die Übersetzung+Mapping der Adressen denken …
      Grüße an Euch von der Matratze …

      • Alexander Fuchs sagt:

        Moin Norddeutsch,

        > "Ich will mitspielen !!"

        gerne, wenn du möchtest dann können wir auch jetzt noch ne Runde "zocken". Meine Hausdrachen belagern mit GNTM eh gerade die Glotze. 🤪

        –> "n-g-i-s.de" –> nach unten scrollen und die dort abgebildete Nummer anrufen. 😉

        In der Zwischenzeit, sollte ich jetzt ganz schnell bei dem vom Stefan erwähnten MSRC, wohl ein Ticket über diesen Murks eröffnen. 😔

        Beste Grüsse aus BaWü
        Alex

  18. Marius sagt:

    Hallo Alex, ich kann nicht genau sagen, ob es wirklich an dem Script liegt oder an einer anderen Ursache, wollte aber mal nachfragen, ob Du Dir vielleicht einen Reim drauf machen kannst.

    Seit etwa zwei, drei Tagen war meine lokale WLAN-Verbindung direkt nach dem Booten meines Rechners (Lenovo ThinkPad T14 Gen 1 AMD Ryzen, Windows 11 22621.1413) extrem langsam. Nach dem Booten läuft ein Backup meines Rechners auf eine Synology. Die Transferrate ist nur noch 2 bis 4 Mbit (!). Speedtest.net (also Internet-Datenverkehr) liefert die in meinem 2,4 Ghz-WLAN üblichen Download-Werte von 180 Mbit down, es liegt also nicht grds. am WLAN selbst.
    Verbaut ist eine Intel WiFi6-AX200. Ein Neustart des Laptops behebt das Problem übrigens nicht, es tritt weiterhin direkt nach einem sauberen Herunterfahren und Einschalten auf. Es hilft tatsächlich nur, im Geräte-Manager die NIC zu deaktivieren und zu aktivieren und sofort ist der Datentransfer im WLAN so schnell wie gewohnt, um die 200 Mbit/s.
    Mein Zweitgerät Lenovo ThinkPad T460s mit ebenfalls Intel WiFI6-AX200 aber mit aktuellstem Windows 10 x64 22H2 Patchlevel hat das Optimierungs-Skript nicht und hat kein Performance-Problem.

    Das Backup aufs NAS könnte ein SMB-Transfer sein, ich weiss nicht genau, wie sich der Synology Active Backup for Business Agent direkt verbindet. Ich vermute mal, er baut auf SMB für den Transfer selbst auf, weil auch ein normales Kopieren von Daten von/zum NAS so extrem langsam ist.
    Das ist nachvollziehbar nach jedem Neustart so.
    Lt. Datum der Backup-Datei Deines Scripts auf meinem Rechner habe ich am 19.03.2023 die aktuellste Version installiert.
    Wäre es möglich, dass da ein Zusammenhang besteht und Du evtl. einen Fix herausfindest?

    Ansonsten hilft das Skript bei mir wirklich gut.
    Seltsamerweise trat es jetzt mit dem aktuellsten WLAN-Treiber von Intel (22.200.2.1) nicht mehr auf. Siehst Du da einen Zusammenhang?

    Danke für deine Hilfe und Grüße, Marius

    • Marius sagt:

      Update: Mein Problem ist vollständig behoben.
      Ursache nicht unklar, bin aber zu 99% der Meinung, dass es nicht am Skript lag. Mein Windows 11 ist per SMB und im Windows Explorer wieder sehr schnell, auch das langsame WLAN direkt nach dem Booten tritt nicht mehr auf.
      Ich habe am Wochenende zur Sicherheit ein Inplace Upgrade gemacht, hat nicht geholfen.
      Weiterhin wollte ich noch die FritzBox 6591 Cable (FritzOS 7.50) nach 41 Tagen Uptime und die Synology DS 920+ nach 31 Tagen Uptime booten, daran lag es aber offensichtlich auch nicht.
      Heute kam KB5023778 (Build 22621.1485). Auch mit diesem Patch läuft (noch^^) alles.
      Allerdings waren die NTFS-Berechtigungen meiner Testdatei, die ich nach dem Booten immer wieder aufs NAS kopiert habe, kaputt. "Keine Berechtigung" auf dem NAS beim draufkopieren. Testweise SMB-Freigabe per iPhone angesteuert, auch dort konnte ich mit demselben User nicht löschen. Habe dann übers Webinterface die Datei löschen können.
      "Eventuell" hat sich der Windows Explorer an dieser Datei festgebissen (Intel Bluetooth-Treiber als EXE) und sich deswegen aufgehangen. (Trat übrigens auch mit testweise pausiertem Defender auf, daran lags also auch nicht).
      Im Changelog bei MS zu KB5023778 steht nichts zu WiFi/Explorer-Fixes, vielleicht haben sie aber trotzdem was gepatched. Das Webinterface der Fritte reagiert deutlich schneller als in den letzten Tagen, dabei wurde an dieser absolut nichts verändert.
      Also eher kurios aber für Alex sicherlich beruhigend die Rückmeldung, dass es höchstwahrscheinlich nicht am Skript liegt :-)

      • Marius sagt:

        Neues Update:
        Die Probleme waren einen Tag später auf einmal wieder da, Verhalten wie gehabt, die NIC war im LAN nur schnell, wenn sie einmal im Gerätemanager deaktiviert und wieder aktiviert wurde.
        Irgendwann habe ich bei meiner virtuellen, lokalen Hyper-V-Maschine den virtuellen Netzwerkswitch, der direkt auf die WLAN-NIC geht, deaktiviert und auf einmal ist das WLAN wieder wie gewohnt schnell.
        D.h. es lag doch am Skript, da ich es hiermit nun nachstellen kann. Wäre vllt schön, wenn das Skript bei lokal vorhandenen Hyper-V-Switches einen Warnhinweis ausgibt oder stoppt. Zugegebenermaßen ist das "nicht normal", aber nun konnte ich es herausfinden.

        • Alexander Fuchs sagt:

          Moin Marius,

          sorry für die späte Antwort, habe deinen Posts jetzt erst gesehen.

          Ja, mit Windows Clients auf denen Hyper-V installiert ist, hat das Skript noch zu kämpfen. 😬
          Ich habe in der Version 2.00 dieses jedoch schon etwas für Clients mit aktiviertem Hyper-V angepasst und überspringe z.B. schon das deaktivieren von RSS, sobald eine installierte Hyper-V Rolle erkannt wird.

          Später werde ich es noch weiter ausbauen, so das es auch das SDN (vSwitch & vNIC's) mit anpasst, aber bis dahin wird noch etwas Zeit vergehen, da ich aktuell komplett Land unter bin.

          Beste Grüsse aus BaWü
          Alex

Schreibe einen Kommentar zu 1ST1 Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.