===== Fefes Blog - Windows Security ===== 

[[http://blog.fefe.de/?ts=9c40177c|Originalartikel]]


[[https://www.qgelm.de/wb2html/wbb1155.html|Backup]]

<html>
<ul><li><a href="http://blog.fefe.de/?ts=9c40177c">[l]</a> Ich ringe immer mit mir, ob ich Tipps verbreiten soll, wie man Dinge sicherer konfiguriert. Insbesondere wenn es sich um propriet&#228;re Software wie Windows handelt.<p>Auf der einen Seite will ich nicht nur schreiben, wie kaputt alles ist. Auf der anderen Seite will ich aber auch nicht daf&#252;r sorgen, dass Leute l&#228;nger bei Windows bleiben, weil sie dank irgendwelcher Konfigurationsratschl&#228;ge den Eindruck haben, sie k&#246;nnten das schon irgendwie absichern. Zu guter Letzt bin ich Code Auditor, nicht Admin. Was man da alles konfigurieren kann ist nicht mein Spezialgebiet. Am Ende verbreite ich noch Unfug?</p><p>Daher haben meine Zero-Trust-Folien am Ende eine eher allgemeine Vision.</p><p>Allerdings kam ein Leserbrief mit konkreten Ratschl&#228;gen rein, den ich jetzt mal ver&#246;ffentlichen m&#246;chte. Nehmt das aber bitte nicht als abzuarbeitendes Howto sondern als Grundlage f&#252;r eigene Recherchen. Ziel der &#220;bung sollte sein, dass ihr ein bisschen mehr verstanden habt, wie die Dinge funktionieren.</p><blockquote><div>zu deiner Zero Trust Pr&#228;si m&#246;chte ich mal etwas zur Windows Security einwerfen. Sorry, ist etwas l&#228;nglich geworden.<p>Wir sind IT Dienstleister und &#252;bernehmen in der Regel den Service einer bestehenden IT Landschaft die entweder vorher durch den Kunden oder durch einen anderen Dienstleister betreut wurde. KMU 1 bis 500 MA.Dahin zu gehen und den Kunden Windows und Outlook wegzunehmen wird in der Regel nicht gelingen. Wenn es m&#246;glich ist einen neuen Server auf Linux hoch zu ziehen k&#246;nnte man das vorschlagen und umsetzen, da h&#246;rt es aber dann auch schon auf.</p><p>Der Satz "Das geht, weil Sie Outlook und Office benutzen" stimmt leider in den meisten F&#228;llen, obwohl das nicht so sein m&#252;sste.MS liefert schon seit Windows 2000 allerhand Techniken mit die genau das alles verhindern. Wir haben aber noch nicht einen Kunden bekommen bei dem irgendwas davon aktiv war und holen das alles schleunigst nach. Das schlimmste was uns als Dienstleister passieren kann, ist ein Ransomwarebefall eines Kunden bei dem wir die Schuld tragen, weil deren Systeme nicht sicher sind, obwohl man es *ohne* Anschaffung zus&#228;tzlicher Software h&#228;tte besser machen k&#246;nnen. Der Kunde verl&#228;sst sich darauf dass wir ihm eine sichere Arbeitsumgebung geben. Es ist ein Unding, dass ein aktueller Windows Server bei einer frischen Active Directory Installation immer noch fast die gleichen Sicherheitsdefaults verwendet wie es in 2000 eingef&#252;hrt wurde und so kommt es, dass von all dem was nun kommt in freier Wildbahn oft nichts zu sehen ist.</p><p>1: Software Restriction Policies (SRP), ja ich wei&#223; ist deprecated, l&#228;uft aber selbst auf Win 11 noch. MS wollte das durch Applocker ersetzen. Ist aber auch deprecated. MS will das durch Defender Application Control ersetzen, geht aber nur per XML oder und nur in Enterprise oder so. Wir bleiben bisher bei SRP, weil das keine Enterprise Lizenzen braucht und seit Win 2000 unver&#228;ndert l&#228;uft. Muss man halt nach jedem gr&#246;&#223;erem Update testen ob es noch geht.</p></div></blockquote>Anmerkung von mir: <a href="https://www.heise.de/download/product/restrictor">Die ct hatte dazu mal ein Tool ver&#246;ffentlicht</a>, da k&#246;nnt ihr damit mal herumspielen.<blockquote><div>Was tut es? Windows f&#252;hrt nur noch EXE, CMD/BAT, PS1, sonstwas aus Pfaden aus die der Admin per GPO festgelegt hat. Outlook kopiert den Anhang aus der Mail in ein Temp Verzeichnis und will es dort starten. Das darf es dann nicht mehr. Admins installieren nach c:\program files\. Das ist erlaubt. Ein User darf da nicht schreiben.MS torpediert es aber selbst mit Programmen die sich unter AppData\Local installieren. Teams z.B. und andere Hersteller sind da auch keine Vorbilder. Muss man sehr enge Ausnahmen setzen und das Risiko in kauf nehmen.<p>2: Makros. Ja, der gelbe Balken bringt nix. Per GPO hart ganz abschalten. Brauchen ohnehin die wenigsten Anwender. Die die es brauchen, kann man geziehlt auf die Dokumente einschr&#228;nken f&#252;r die es gehen soll. Was machen die Malware Makros? VBS oder Powershell Script ausf&#252;hren und Payload nachladen und starten. Geht eigentlich durch SRP schon nicht mehr, aber es soll ja Bugs geben die vielleicht um SRP drum rum kommen.</p></div></blockquote>GPO ist ein Group Policy Object, oder in deutschen Versionen: Gruppenrichtlinien.<blockquote><div>3: Beschafft sich lokale Admin-Rechte und &#252;bernimmt den Domain Controller.Wenn 1 und 2 versagt hat kommen wir dahin. N&#228;chste Verteidigungslinie ist Lateral Movement zu verhindern.<p>Es gibt genug GPOs zum h&#228;rten der Systeme, aber man klemmt halt damit alten Legacy ab, was ich aus technischen Sicht eigentlich ganz gut finde. NTLM Auth weg, Credential Caching f&#252;r Admins und generell Server abschalten, Debugging Rechte global abschalten und nur im Einzelfall erlauben. LAPS benutzen, auch f&#252;r Server. Das macht es Mimikatz schon ganz sch&#246;n schwer an verwertbare Daten zu kommen.</p></div></blockquote>In meinen Folien hatte ich gesagt, dass Lateral Movement nicht Teil des Threat Models ist. Ich bin mir unsicher, inwieweit man das verallgemeinern kann. Ich unterhalte mich zu Ransomware mit Kumpels, die weiter oben auf der Eskalationsskala sitzen, die sehen dann praktisch ausschlie&#223;lich F&#228;lle, bei denen der AD &#252;bernommen werden konnte. Ich habe leider keine Zahlen, wie hoch der Prozentsatz der Ransomware-Angriffe ist, die man verhindern k&#246;nnte, wenn man Lateral Movement unterbindet. ALLERDINGS: Wenn man durch andere Ma&#223;nahmen daf&#252;r sorgt, dass der Sprung zum Domain Admin nicht geht, dann wird die Verhinderung von Lateral Movement pl&#246;tzlich eine wichtige Ma&#223;nahme. Genau das spricht der Leserbrief hier an.<blockquote><div>Mit ESAE hat MS schon lang ein Konzept die Admin Ebenen voneinander zu trennen. Man muss auch nicht zwingend mehrere Dom&#228;nen betreiben um den wichtigsten Teil davon umzusetzen.Bei uns darf ein Domain Admin nicht mal PCs in Dom&#228;nen aufnehmen. Niemals sollte sich ein Domain Admin an einem Client anmelden und das l&#228;sst sich auch per GPO verhindern.Der darf auch nur an Domain Controller, die CA und &#228;hnliche Systeme. Ein Server Admin darf da nicht hin und der darf auch nicht an Clients. Ja, der Domain Admin hat dann halt 4 User Accounts. User, Client Admin, Server Admin, Domain Admin. Nat&#252;rlich mit Grundverschiedenen Passw&#246;rtern. Kommt man mit klar.</div></blockquote>Ich hab das in einem Nebensatz irgendwo erw&#228;hnt, dass man die Admin-Accounts aufteilen soll, und dass der Domain Admin nicht an die Datenbanken k&#246;nnen soll. Der Leser hier hat v&#246;llig Recht, das kann und sollte man noch mehr auftrennen. Dann hat man tats&#228;chlich etwas getan, um im Threat Model ein Bedrohungsrisiko zu senken.<blockquote><div>Selbst ein Keylogger auf dem Client bekommt dann h&#246;chstens den Admin f&#252;r die Clients, aber kann immer noch nicht auf Server oder gar Domain Controller.<p>4. Benutz Smart Cards f&#252;r die Admins und lass nur Anmeldungen per Smart Card zu. In dem Fall kann ein Keylogger auf dem PC auch das Kennwort nicht einfach mal mitlesen.USB Smart Cards sind nicht teuer. Die Menge an Admins &#252;berschaubar.F&#252;r RDP gibt es dann noch den Restricted Admin Mode mit entsprechenden Komforteinbu&#223;en.In Enterprise Editionen noch Credential Guard, usw.</p></div></blockquote>Dazu sei angemerkt, dass auch mit Smart Cards im Hintergrund immer noch Kerberos l&#228;uft mit Kerberos-Tickets, die abgreifbar sind. Aber die laufen wenigstens nach einer Weile aus.<blockquote><div>5. Exchange kann Split Permissions. Nutzt das. Es entfernt die Berechtigungen dass der Exchange Server Domain Admin Rechte hat. HAFNIUM war damit nur halb so schlimm.Server m&#252;ssen auch nicht &#252;berall ins Internet d&#252;rfen. Verhindert dass Malware auf euren Servern ganz bequem per HTTPS ihren Payload laden k&#246;nnen.<p>Erweitert das noch mit VLANs und Firewalls. Kein Anwender muss auf die ESXi Infrastruktur, einen Switch oder das BMC vom Server. Die m&#252;ssen auch auf die wenigsten Ports f&#252;r die Anwendungsserver. Da reichen oft ACLs auf dem Core Switch um zumindest bei Line Speed zu bleiben.</p></div></blockquote>F&#252;r die BMC und Hypervisoren w&#252;rde ich dringend zu physisch getrennter Verkabelung raten, statt zu irgendwelchen Software-Geschichten.<blockquote><div>Backupserver aus der AD nehmen. Per Firewall/ACL einschr&#228;nken, dass der an die Server darf, aber die Server nicht zum Backupsserver.</div></blockquote>Das ist ein guter Ratschlag!<blockquote><div>All diese Dinge die ich beschrieben habe gehen mit Bordmitteln. Da ist nicht ein Anti-Virus, SIEM oder sonst eine 3rd Party L&#246;sung beteiligt.Wir setzen das meiste davon bei Firmen ein die keine 10 Mitarbeiter haben. Das kann man mit Routine an einem Tag umsetzen. (Den Windows Teil zumindest) Testet das selbst mit Mimikatz, Bloodhound und was auch immer. Hackt euch selbst und danach oder wenn ihr das generell nicht k&#246;nnt, holt euch noch einen Pen Tester um die offensichlichen L&#252;cken weg zu machen.<p>Am Rande: Domain Joined Device Public Key Authentication muss man nicht einschalten. Das ist per Default an. Man muss es aber erzwingen wenn man das Fallback nicht haben will. Ist fast das gleiche, aber doch nicht ganz und geht erst mit Server 2016.</p><p>Am weiteren Rande: Patchmanagement. Es w&#228;re sch&#246;n, wenn MS nicht Patches raus bringen w&#252;rden die gro&#223;fl&#228;chig zu Boot Loops auf Domain Controllern, Druckproblemen oder 802.1X/802.11X Problemen f&#252;hren w&#252;rden. Dann h&#228;tte man auch mit Auto-Updates weniger schmerzen. So muss man eigentlich schon zwangsweise ein paar Tage warten, wenn man nicht vor einem Totalausfall am n&#228;chsten Tag stehen m&#246;chte. Beides verfahren sind somit schlecht.</p><p>Ich gehe nicht davon aus das danach das System unhackbar sicher ist. Wir sprechen hier immer noch von Software und von Microsoft, aber zumindest hat man etwas in die richtige Richtung getan und die offenlichtlichen Scheunentore geschlossen.</p><p>Wer nun mit dem erh&#246;hten Supportaufwand argumentiert, dem sei gesagt dass er bei uns gesunken ist, weil die Anwender eben nicht mehr alles ausf&#252;hren k&#246;nnen was bei 3 nicht auf den B&#228;umen ist und die Computer dadurch so bleiben wie der Admin es sich mal vorgestellt hat.Entwicklungsabteilungen k&#246;nnen zus&#228;tzlich Nicht-Domain Computer oder VMs bekommen um ihre systemnahe Arbeit durchzuf&#252;hren.</p></div></blockquote>Nur ein Nachsatz noch von mir: Der Feind ist Komplexit&#228;t. Es ist zwar sch&#246;n, dass man bei Microsoft eine Menge konfigurieren kann, so dass es weniger schlimm ist, aber am Ende des Tages &#252;berblickt niemand mehr den ganzen Softwarehaufen, und alle sind nur an der Oberfl&#228;che am Herumkratzen. Das betrifft gl&#252;cklicherweise auch die meisten Angreifer. Wirklich sicher f&#252;hlen w&#252;rde ich mich da nicht. Und wenn man erstmal diese Art von Knowhow aufgebaut hat, dann wird man wahrscheinlich nie wieder von Windows wegmigrieren wollen.<p>Aus meiner Sicht ist der Vorteil von Linux und co, dass es da keine nat&#252;rliche Schranke gibt, wie viel Verst&#228;ndnis man von dem Gesamtsystem aufbauen kann.</p></li></ul>
</html>