Sicherheit: Best Practice, zum Updaten von Windows Domain Controllern

Windows[English]In Unternehmensumgebungen werden oft Windows Server eingesetzt, die als Domain Controller (DC) fungieren. Domänencontroller sind für viele Unternehmen nach wie vor (trotz Trend zur Azure-Coud, so Microsoft) ein zentraler Bestandteil der Infrastruktur. Und die in der Active Directory gespeicherten Identitäten sind häufig das Ziel von Angreifern. Wie kann man die Domain Controller in Bezug auf Updates bestmöglich absichern? Microsoft hat da ein paar Gedanken zu veröffentlicht.


Anzeige

Ich bin über nachfolgenden Tweet auf das Thema gestoßen. Michael Niehaus weist auf den Techcommunity-Beitrag Updating best practices for Domain Controllers Microsofts hin, der sich mit dem Thema "Absicherung von DCs" befasst.

Updating best practices for Domain Controllers

Microsoft schreibt, dass der Schutz von Domain Controllern (DCs) vor Angriffen habe für Administratoren seit jeher Priorität. Dann zeigt man einige Beispiele auf, wie Unternehmen ihre DCs schützen können:

  • Beschränkung der Verwendung von Domänen-Admin-Rechten
  • Verwenden Sie Jumpboxen für den RDP- oder MMC-Zugang
  • Installieren Sie keine Anwendungen von Drittanbietern auf DCs
  • Beschränken Sie den Internetzugang zu DCs

Für die für die Sicherheit Verantwortlichen besteht die Herausforderung, die "Best Practices" zyklisch zu überdenken, und zu prüfen, wo Verbesserungen möglich sind. In diesem Kontext hat Microsoft seine Best Practices-Empfehlungen zum Schutz von Domänencontrollern vor Angriffen aktualisiert.

  • Microsoft empfiehlt beispielsweise nicht mehr, dass DCs unter allen Umständen keinen Internetzugang haben sollten.
  • Stattdessen werden Empfehlungen ausgesprochen, die mit der sich verändernden Sicherheitslandschaft übereinstimmen.

Microsoft befürwortet zwar nach wie vor, keinen ungefilterten Internetzugang der DCs, und die Nutzung des Internets über einen Browser von diesen Servern aus sollte nach wie vor verboten sein. Anstatt die DCs komplett vom Internetzugang zu isolieren und davon auszugehen, dass sie nie angegriffen werden, empfiehlt Microsoft einen Defense-in-Depth-Ansatz mit modernem Bedrohungsschutz, bei dem immer auf Angriffe zu achten ist. So meint Microsoft im Technet-Beitrag, dass der Defender for Identity identitätsbasierte Bedrohungen und kompromittierte Benutzer in lokalen Umgebungen erkennt und Kunden hilft, die Angriffsfläche zu reduzieren, um Kompromittierungen und Seitwärtsbewegungen von Angreifern im Netzwerk zu verhindern.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Update, Windows Server abgelegt und mit Domain Controller, Update, Windows Server verschlagwortet. Setze ein Lesezeichen auf den Permalink.

16 Antworten zu Sicherheit: Best Practice, zum Updaten von Windows Domain Controllern

  1. 1ST1 sagt:

    Idealerweise sind DCs Core-Server ohne grafische Oberfläche, dann kann man da auch keine Anwendungen drauf installieren. DCs gehören in ein eigens Subnetz mit Firewall davor, es müssen fürs interne Netz alle SMB/RDCP/DNS/DHCP-Ports auf gemacht werden, und alles für RDP/MMC notwendige nur für spezielle Admin-Jumphosts aufgemacht werden, die ausschließlich zur Verwaltung der DCs benutzt werden. Zusätzlich ist die Umsetzung des Admin-Tier-Modells und Installation von LAPS erforderlich. Wer dann noch das Hopping von einem Server zum Nächsten verhindern wiill, bestückt noch die Windows-Firewall mit sinnvollen Regeln, vor allem für SMB, RPC und RDP hillt es, diese so einzuschränken, dass nur ausgewählte andere Systeme sich damit verbinden können.

    • Stefan sagt:

      Gute Idee, ich glaube aber du kannst die Firmen im KMU-Umfeld an einer Hand abzählen die so etwas umsetzen würden.

      Ist schon heftig, vor 10 Jahren gab es die SBS wo alles auf eine Kiste gepackt wurde (AD/Exchange/File/SQL) und heute sowas. Versteht mich nicht falsch, alles gute Ideen, dürfte aber wohl bei den kleineren Firmen wohl reslistisch nie zum Zuge kommen.

    • Cestmoi sagt:

      Betr. "… und alles für RDP/MMC notwendige nur für spezielle Admin-Jumphosts aufgemacht werden, …":

      mstsc.exe und mmc.exe sind Binsen. Viel wichtiger ist powershell.exe mit diversen remote capabilities wie in (1) beschrieben bzw. referenziert.

      (1)
      https://docs.microsoft.com/en-my/powershell/scripting/learn/ps101/08-powershell-remoting?view=powershell-7.2

      • MOM20xx sagt:

        klingt irgendwie nach rhost, rshell und rexec von unix der 70er jahre.
        gibts eigentlich irgendwas, dass per default sicher is aus dem hause redmond ohne, dass der admin gefühlte wochen lang hardening etc. betreiben müsste damit es halbwegs sicher wird?

    • MOM20xx sagt:

      micrsoft bekommt seinen – ich muss 1000 jahre abwärtskompatibel bleiben, emmentaler nimmer gebacken. und muss dann quasi ein ganzes gefängnis drüber bauen. nur das interessiert vielleicht in grossen unternehmen wo es wirklich rollen aufteilungen gibt. im kleinen kmu wo 1-2 admins alles schaukeln wird auf admin-tier man gepflegt verzichtet. Die Leute wollen arbeiten und nicht in administrativem Müll von Microsoft ersticken.
      Ich hab noch nie bei Linux irgendwo gelesen, dass man jetzt eigene Admin Tiers und was nicht alles braucht, nur weil ma angst vor cached credentials, pass the hash und so müll haben muss.

    • Sascha Sonnenwald sagt:

      Das ist nicht ganz korrekt, denn auch auf Coreservern kann man Drittanbieter- oder Zusatzsoftware installieren.

  2. Norman sagt:

    "Beschränken Sie den Internetzugang zu DCs" :D :D

    Wer DCs ans Internet lässt hat sie nicht mehr alle

    • Blackii sagt:

      Moin,
      einige Dienstleister oder gemütliche Personen setzen Magagement Zugänge gerne ins Internet, um besser dranzukommen 🙃🤷
      Edit: besonders bei kleinen Infrastrukturen.

      MfG,
      Blackii

    • MOM20xx sagt:

      na dann. root dns zonen, ntp, …

      ja klar die 5 mann bude installiert sich gleich neben ad den ein oder anderen linux server für dns forwarder, proxy, ntp und was nicht alles. nur weil der mist aus redmond offen is wie sonst nur was. die frage is halt wer sie da nicht alle beisammen hat

    • Jackie sagt:

      Die 80er haben abgerufen und wollen ihre Best Practises zurück. Sorry aber im Jahr 2022 dar ein DC natürlich ins Netz! Meine DCs dürfen das auch seit knapp 20 Jahren denn sie sind authoritative DNS Server! Davor gehört eine ordentliche Firewall und ein Unbound Resover. Es gibt kaum was schöneres im Windows Netzwerk! Eine AD basiert nunmal primär auf DNS also lasst eure DCs gefälligst ihren Job machen. Meine DCs sind im Windows Netzwerk die Stelle auf die ich vertraue dewegen sind sie DNS Server für das gesammte Netzwerk und zudem die primäre Zeitquelle. Vor 20 Jahren konnten DCs ihren Job ihren Job auch ohne Unbound direkt mit den Root Server machen. Ich hab damals sogar den K-Root aus Frankfurt direkt lokal gespiegelt man war das geil!

      Sorry ich steh einfach auf DNS, IPs eingeben ist einfach was für Looser ;)

  3. JohnRipper sagt:

    Was heißt schon Internet? Meine DCs dürfen zumindest zu den Root Servern zwecks DNS und zu NTP Servern zwecks Zeit verbinden.

    EMule und Naspter habe ich gestern deinstalliert.

  4. Max sagt:

    Wenn ich mir die tägliche Praxis zu Gemüte führe, dann sehe ich weniger den Internetzugang als das Hauptproblem in puncto Sicherheit, sondern unsichere Zugänge (dasselbe einfache PW über die halbe IT-Infrastruktur), veraltete Domänenstrukturen, fehlende Informationen zu den Konfigurationen (z. B. mit einer legendären IT-Dokumentation) und vor allem die vielen Einzelkämpfer innerhalb und außerhalb der Unternehmen (z. B. selbstständige Administratoren), die nicht mehr wissen, wo hinten und wo vorne ist.

    • Sascha Sonnenwald sagt:

      Das sehe ich ähnlich. Es sollte über die Absicherung von Adminworkstation (Stichwort: PAW) nachgedacht werden in Verbindung mit dem Tier-Modell. Sowie dedizierte Accounts für die verschiedenen Serverrollen in Verbindung mit Authentication Policies/ Silos.
      Weil selten wird direkt am Domänencontroller "eingebrochen" meistens geschieht es doch über die unsichere (Admin)Workstation auf der auch noch die Hashes des Domänenadministrator liegen.

Schreibe einen Kommentar zu Stefan Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

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.