DNS absichern

[StephanR 10]

Hallo,

 

Ziel ist die Absicherung der AD-DNS-Zone. Es soll nicht mehr ohne Authentifizierung möglich sein Records zu setzen und zu ändern.

 

IST-Zustand:

 

Active Directory (3x DC Windows Server 2012 R2)

DNS (3x DC Windows Server 2012 R2)

DHCP (1x Windows Server 2008 R2)

 

Aktuell übernimmt der DHCP Server die Aktualisierung der PRT und A Records für die Clients. Hier ist die Option wichtig, dass Einträge auch für Clients gesetzt werden, die keine Aktualisierung anfordern. Dies ist denke ich für unsere Druckersysteme und alte Windows embedded Geräte notwendig, da diese die Option 81 nicht liefern.

 

 

Der DHCP Server hat zudem ein AD-Userkonto zugewiesen, welches Mitglied der Gruppe DNS-Admins ist.

 

 

Die DNS-Zone erlaubt aktuell nicht sichere Updates.

 

Zielformulierung:

1 .Neue DNS Einträge können nur noch nach Authentifizierung erfolgen

2. Änderungen von bestehenden Einträgen sind nur dann erlaubt, wenn der Anforderer auch der "Besitzer" des Eintrages ist. Verhinderung von Name-Squatting.

3. Der DHCP Server aktualisiert weiterhin für AD und nicht AD-Mitglieder die DNS-Records bzw. erstellt sie.

 

Umsetzung:

Zum 1. Ziel:

Umstellung der AD-DNS-Zone auf nur sichere Updates.

Frage: D. h. nur noch Windows AD-Mitglieder können neue Einträge erstellen? Wäre dies für den DHCP Server gegeben, da er das AD-Konto DNS-Admin nutzt?

Zum 2. und 3. Ziel:

Im DHCP wird die Option DHCP-Namensschutz aktiviert

Frage: Werden weiterhin Einträge für Clients erzeugt, die keine Aktualisierung anfordern?

 

Vielleicht nochmal ausgeschrieben, wie ich das Verhalten nach Umsetzung intepretieren würde.

Änderung an der Zone sind durch die Umstellung auf "nur sichere Updates" nur noch die authentifizierte AD-Konten möglich (Beispiel DHCP AD-Konto). Dadurch wird schon mal verhindert, dass einfach Records in der Zone erstellt werden.

Jetzt gibt es aus meiner Sicht noch folgendes Problem. Kommt ein Client ins LAN und hat den gleichen Hostname wie eine AD-Maschine, so würde über den DHCP der Eintrag im DNS einfach überschrieben. Das sogenannte Name-Squatting. Um dieses zu verhindern würde ich dann gerne den DHCP Namensschutz aktivieren, der das Überschreiben von AD-Records verhindert. Ganz wichtig wäre bei den Punkten nur, dass Clients die die Option 81 nicht senden weiterhin im DNS eingetragen werden. Ich freue mich auf Feedback zu meinem Vorhaben. Vielen Dank!

[NilsK 2.934]

Moin,

 

das Thema ist im Detail nicht ganz trivial. Arbeite dich mal hier durch:

 

[DHCP, Dynamic DNS Updates , Scavenging, static entries & time stamps, the DnsUpdateProxy Group, and DHCP Name Protection - AD and Exchange Quantum Singularity]
http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx
 

"Secure Updates" bedeutet, dass ein vorhandener Eintrag nur von seinem Owner geändert werden kann. Um die Ersteintragung geht es dabei nicht.

 

Gruß, Nils

[StephanR 10]

Moin,

 

das Thema ist im Detail nicht ganz trivial. Arbeite dich mal hier durch:

 

[DHCP, Dynamic DNS Updates , Scavenging, static entries & time stamps, the DnsUpdateProxy Group, and DHCP Name Protection - AD and Exchange Quantum Singularity]

http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx

 

"Secure Updates" bedeutet, dass ein vorhandener Eintrag nur von seinem Owner geändert werden kann. Um die Ersteintragung geht es dabei nicht.

 

Gruß, Nils

 

Danke für den Link, leider kann ich diesen nicht aufrufen. Es kommt seit gestern stetig ein Timeout.

Zum Thema "Secure Updates". Wenn weiterhin der DCHP die Einträge im DNS pflegt ist dieser ja Owner (außer er ist Mitglied der Gruppen dnsupdateproxy, dann werden soweit ich gelesen habe keine Sicherheitsinformationen gesetzt). Wenn der DHCP aber Owner ist, muss zwingend die Namensschutz Option aktiviert sein, damit der DHCP nicht einfach "seine" Einträge auf Anforderung (oder wenn es keine Anforderung gibt und der DHCP trotzdem die Einträge setzen soll) des Clients ändert? Hab ich das so richtig verstanden?

[Daniel -MSFT- 129]

Du bist nicht allein: http://www.downforeveryoneorjustme.com/msmvps.com

 

Lies Dich mal hier rein, ich habe das in der Vergangenheit schon ein paar Mal erklärt: www.google.de/search?q=daniel+melanchthon+DnsUpdateProxy

[StephanR 10]

Du bist nicht allein: http://www.downforeveryoneorjustme.com/msmvps.com

 

Lies Dich mal hier rein, ich habe das in der Vergangenheit schon ein paar Mal erklärt: www.google.de/search?q=daniel+melanchthon+DnsUpdateProxy

 

Danke, ich habe mir die Newsgroup Beiträge durchgelesen und würde meine Erkenntnisse gerne einmal zur Prüfung wiedergeben.

 

1. Die Nutzung der dnsupdateproxy Gruppen ist obsolet und unsicher.

1.1 Obsolet, weil man inzwischen ein AD-Konto im DHCP-Server definieren kann, welches sich auch mehrere DHCP-Server "teilen" können.

1.2 Unsicher, weil der DHCP Server nicht Owner des Eintrages wird, sondern der erste Client, der auf den Eintrag zugreift.

2. Best practise ist im DHCP-Server ein AD-Konto zu definieren. Dieses AD-Konto wird dann Owner der Objekte, die der DHCP Server anlegt.

1.1 Nutzt man mehrere DHCP Server haben alle Zugriff auf die Objekte, da Sie alle das gleiche AD-Konto verwenden.

3. Die DNS-Zone ist auf nur sichere dynamische Updates zu konfigurieren, damit die unter Punkt 1 & 2 geschilderten Sicherheitsmechanismen greifen.

3.1 Nur wenn die DNS-Zone auf nur sichere dynamische Updates, wird der Owner eines Objektes berücksichtigt.

3.2 Erlaubt die Zone auch unsichere Updates, so kann jeder DNS-Einträge manipulieren.

 

Mein Fazit aus diesen Erkenntnissen wären folgende:

 

1. Die Umstellung der DNS-Zone auf nur sichere dynamische Updates verhindert, dass ein unautorisierter Client bestehende Änderungen an Einträgen vornehmen kann

1.1 Es ist aber weiterhin so, dass nicht AD-Clients neue Einträge (Ersteinträge) vornehmen können? So wie NilsK im zweiten Post geschrieben hat? Wer ist dann Owner?

2. Der DHCP Server ist mit dem definierten AD-Konto Owner aller über Ihn angelegten Objekte

2.1 Besitzer der Objekte ist also letztendlich das AD-Konto, so dass diese Einträge nicht manipuliert werden können.

3. Aus meiner Sicht gibt es jetzt nur folgendes Problem. Der DHCP hat für einen AD-Client (nennen wir ihn client1.firma.local) einen Eintrag im DNS vorgenommen. Owner dieses Eintrages ist das im DHCP Server definierte AD-Konto. Jetzt kommt ein nicht AD-Client mit dem gleichen Namen client1 und konfiguriertem DNS-Suffix firma.local ins LAN. Würde der DHCP Server jetzt nicht einfach den vorhandenen Eintrag überschreiben. Schließlich ist er ja Owner.

Setzt genau an diesem Punkt die Option Namensschutz an?

 

Vielen Dank!

[NilsK 2.934]

Moin,

 

ich hoffe, dass der Server msmvps.com bald wieder geht (Link oben). Da sind diese Dinge und ein paar weitere Wichtigkeiten erläutert. Aus dem Kopf kann ich das gerade nicht wiedergeben.

 

Bei der ganzen Sache kommt nämlich ggf. noch das Scavenging dazu (Bereinigen alter DNS-Einträge), welches dann auch noch mit der DHCP-Leasedauer in Konflikt stehen kann ...

 

Gruß, Nils

[StephanR 10]

Ich vermute einfach mal, dass der Artikel seit 09/2013 nicht geändert wurde. Dann geht folgender Link über http://archive.org/web/

http://web.archive.org/web/20130907181009/http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx

Das Thema ist wirklich nicht trivial und man findet diverse widersprüchliche Aussagen.

 

Ich zitiere mal die vorgeschlagene Konfiguration der MSMVPS Seite:

 

 

Windows 2008 R2 or newer:

You have a new feature to prevent Name Squatting: DHCP Name Protection, you still need to configure Credentials and add the server to the DnsUpdateProxy group.

• Add the DHCP server to the Active Directory, Built-In DnsUpdateProxy security group.
• Configure DHCP Credentials.
• Configure Name Protection.
• If DHCP is co-located on a Windows 2008 R2 DC, you must secure the DnsUpdateProxy group by running the following:
  dnscmd /config /OpenAclOnProxyUpdates 0 
  
  Note: Configuring DHCP credentials AND using the DnsUpdateProxy group, and forcing DHCP to update all records, will also allow DHCP to register Win9x machines, as well as non-Windows machines, such as Linux, OSx (BIND based), and other Unix flavors, and update the records when they get renewed with a different IP.

Hier wird jetzt behauptet, dass sowohl die Credentials eines AD-Kontos als auch die Mitgliedschaft in der Gruppe DNSUpdateProxy notwendig ist. Immerhin gibt es dazu die klare Aussage, dass dann auch Microsoft fremde oder alte Clients ins DNS eingetragen werden.

 

Zudem wird gesagt, dass der DHCP dann bereits existierende Objekte nicht updatet bzw. löscht. Hier habe ich die Hoffnung, dass dies in unserem Fall nicht zutrifft, weil wir ja bereits Credentials nutzen und diese sich nicht ändern.

 

Note on older, pre-existing records in DNS:

After configuring the above provedure, the credentials and DnsUpdateProxy group configuratuion will not update current or delete duplicate records. You must delete them manually to allow DHCP to take care of all new records moving forward.

 

In unserer Umgebung ist mir jetzt noch folgendes aufgefallen. Wie im ersten Post erwähnt, sind im DHCP Credentials eines AD-Kontos hinterlegt. Schaue ich mir aber jetzt einen DNS-Eintrag an, so finde ich dieses Konto dort nicht unter Sicherheit:

 

 

Müsste nicht das AD-Konto der Besitzer sein und auch unter Gruppen- oder Benutzernamen aufgeführt werden? Vielen Dank!

 

[Daniel -MSFT- 129]

Ich bin gerade im Urlaub und lese hier auf dem Handy mit. Daher muss ich hier aktuell wegen der Menge an Informationen passen. Ich schreibe dazu was, wenn ich wieder zurück bin und eine vernünftige Tastatur habe.

[StephanR 10]

Hallo,

 

ich habe mittlerweile folgende Ergebnisse in einer Testumgebung erzielt:

 

 

Es wurde mit ipconfig /release & ipconfig /renew gearbeitet. Zudem ist konfiguriert, dass der DHCP Server die Einträge für die Clients vornehmen soll und zwar ausnahmslos (Siehe Screenshot Beitrag #11). Bzw. beim Linux Client Debian 7 mit Reboots, da dhclient & dhclient -r keine Änderungen im DNS durchführten.

 

1. unsichere und sichere Updates erlaubt / DHCP Namensschutz deaktiviert / DHCP nicht Mitglied Gruppe DNSUpdateProxy
   1. Ergebnis:
      1. Win7 nicht AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag im DNS
         1. es ist dabei unerheblich, ob im DHCP Credentials hinterlegt sind oder nicht
         2. Im DNS-Objekt sind keine speziellen Berechtigungen ersichtlich. Egal ob Credentials hinterlegt wurden oder nicht
      2. Win7 AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag werden im DNS
         1. Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein
            1. Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann
         2. Achtung Wird der Client umbenannt, so ist das Ergebnis wie beim Client ohne AD-Mitgliedschaft. Eventuell hat irgendein Cache dazu geführt, dass der alte Name mit dem AD-Konto als Owner angelegt wurd.
      3. Linux: Der DHCP erzeugt den A und PTR Eintrag im DNS 
         1. Im DNS-Objekt sind keine speziellen Berechtigungen ersichtlich. Egal ob Credentials hinterlegt wurden oder nicht
2. nur sichere Updates / DHCP Namensschutz deaktiviert / DHCP nicht Mitglied Gruppe DNSUpdateProxy
   1. Ergebnis:
      1. Win7 nicht AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag im DNS
         1. Wenn im DHCP keine Credentials hinterlegt sind passiert folgendes:
            1. Der DHCP trägt sich mit seinem Hostname$ als Besitzer des Objektes ein
               1. Dies dürfte zur Folge haben, dass ein anderer DHCP Server diesen Eintrag nicht ändern kann bzw. nur der Ersteller die Möglichkeit hat
         2. Sind im DHCP Credentials hinterlegt:
            1. Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein
               1. Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann
      2. Win7 AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag werden im DNS
         1. Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein
            1. Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann
      3. Linux: Der DHCP erzeugt den A und PTR Eintrag im DNS
         1. Einträge von AD-Mitglieder werden einfach überschrieben, wenn das nicht AD-Mitglied den gleichen Namen hat
         2. Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein
            1. Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann
                
3. nur sichere Updates / DHCP Namensschutz aktiviert / DHCP nicht Mitglied Gruppe DNSUpdateProxy
   1. Ergebnis:
      1. Win7 nicht AD-Mitglied: Es wird kein A Eintrag im DNS erzeugt PTR wird erzeugt.
      2. Win7 AD-Mitglied: A und PTR Eintrag werden im DNS erzeugt
         1. Der Client trägt selber seinen A-Record ein und gibt sich auf Basis der Hostnamen$ die Owner Rolle
            1. Der DHCP hat keinen Zugriff auf den Record
            2. Der Eintrag kann nicht manipuliert werden (getestet mit einem Linux Client, der den gleichen Hostnamen bekommen hat)
               1.  

                  Ereignisprotokoll DHCP-Server:

                  
      3. Linux: Der DHCP erzeugt den A, PTR und DHCID Eintrag im DNS
         1. Der DHCP trägt das AD-Konto (Credentials) als Besitzer der Objekte ein
            1. Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann
            2. Der Eintrag kann nicht manipuliert werden (getestet mit AD-Mitglied, dass den gleichen Hostnamen bekommen hat)
4. nur sichere Updates / DHCP Namensschutz aktiviert / DHCP Mitglied Gruppe DNSUpdateProxy
   1. Ergebnis:
      1. Win7 nicht AD-Mitglied: Es wird kein A Eintrag im DNS erzeugt PTR wird erzeugt.
      2. Win7 AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag im DNS
         1. Der Client trägt selber seinen A-Record ein und gibt sich auf Basis der Hostnamen$ die Owner Rolle
            1. Der DHCP hat keinen Zugriff auf den Record
      3. Linux: Der DHCP erzeugt den A, PTR und DHCID Eintrag im DNS
         1. Der DHCP trägt das AD-Konto (Credentials) als Besitzer der Objekte ein
            1. Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann

 

Mein Problem sind somit die nicht AD-Windows-Systeme, da diese in den sicheren Konfigurationen (Punkt 3 & 4) nicht in das DNS eingetragen werden. Aus meiner Sicht gibt es jetzt zwei Lösungswege:

 

1. Unter Punkt 2 wird erreicht, dass die AD-Windows Systeme nicht durch den DHCP ihren Eintrag im DNS bekommen, sondern dies eigenständig tun und somit selber Owner des Objektes werden. Dadurch hat der DHCP dann keine Möglichkeit mehr den Eintrag auf Aufforderung eines anderen Clients (Linux, Nicht-AD-Windows,...) zu ändern.

2. Nicht-AD-Windows Systeme werden irgendwie in den sicheren Konfigurationen (Punkt 3 & 4) eingetragen. Hier verstehe ich sowieso nicht, warum ein nicht AD-Windows-Client anders behandelt wird als ein Linux System. Also warum der DHCP nicht den Eintrag für nicht-AD-Windows-Clients vornimmt.

 

Wie sich externe Geräte wie Drucker oder Handgeräte im Lager verhalten, werde ich wohl live testen.

 

Ich danke fürs Lesen und hoffe auf ein paar Tipps :)

bearbeitet 30. Juli 2014 von StephanR

[NilsK 2.934]

Moin,

 

das sind ja schon mal sehr spannende Ergebnisse, vielen Dank!

 

Welche Optionen hast du im DHCP-Server für das Registrieren von Einträgen in DNS gesetzt?

 

Gruß, Nils

[StephanR 10]

Moin,

 

das sind ja schon mal sehr spannende Ergebnisse, vielen Dank!

 

Welche Optionen hast du im DHCP-Server für das Registrieren von Einträgen in DNS gesetzt?

 

Gruß, Nils

 

Moin,

 

Punkt 1 und Punkt 2 wurden mit folgenden Einstellungen getestet:

 

 

Punkt 3 und 4 wurden dann mit den durch die Aktivierung des Namensschutzes vorgegebenen Einstellung durchgeführt.

 

 

UPDATE

Ändere ich die DNS Einstellungen von "DNS Einträge immer dynamisch aktualisieren" auf "nur nach Aufforderung von Clients dynamisch aktualisieren" ergibt sich folgendes Bild.

 

1. Der AD-Mitglied DNS Eintrag bekommt als Owner den hostname$

2. Ein nicht-AD-Windows-Client wird nicht im DNS eingetragen. Hier habe ich inzwischen schon die Vermutung, dass die Umstellung der DNS-Zone auf "nur sichere Updates" auch die initiale Erstellung eines Records unterbindet, sollte keine AD-Authentifizierung vorhanden sein.

3. Der Linux Client wird über den DHCP im DNS registriert

Diesen Beitrag möchte ich gerne noch loswerden, bevor ich meine Tests erstmal einstellen möchte.

 

Folgende Option zu dynamischen Updates ist im DHCP gesetzt "nur nach Aufforderung von Clients dynamisch aktualisieren". Ansonsten sind die Einstellungen identisch zum Screenshot im Beitrag zuvor.

 

Der Nicht-AD-Windows Client wird in der DNS Zone nicht eingetragen, weil er nicht autorisiert ist DNS Einträge zu setzen. Folgende Screenshots stützen aus meiner Sicht diese These:

 

1. Der Client stellt den DHCP Request mit einem korrekten FQDN

http://picload.org/image/lwawogc/dhcp_request.jpg

2. Es kommt zu folgendem Deny der Dynamic Updates

http://picload.org/image/lwawogw/dns_deny.jpg

 

Für mich ist damit belegt, dass bei einer sicheren DNS-Zone nicht einfach so jeder Client (auch initiale) Objekte erstellen kann. Oder deute ich die Auszüge des Wiresharks falsch?

 

 

Leider scheine ich mein Upload Limit überschritten zu haben. Daher die Links zum Bildhoster...

bearbeitet 30. Juli 2014 von StephanR

[StephanR 10]

Hallo,

 

ich möchte noch kurz mitteilen, dass ich keine Lösung zum Thema Nicht-AD-Windows-Clients/sichere DNS-Zone/DHCP dynamische Updates nur nach Aufforderung finden konnte. Ich habe lediglich noch folgende Seite gefunden, die das Verhalten der Nicht-AD-Windows-Clients bestätigt. http://jorgequestforknowledge.wordpress.com/2011/01/01/dhcp-and-name-protection-in-windows-server-2008-r2/

 

Ansonsten funktioniert in den meisten Subnetzen bei uns die Einstellung, dass der DHCP nur nach Afforderung die dynamischen Updates durchführt und sich die AD-Clients somit selbständig im DNS aktualisieren. In Subnetzen mit außergewöhnlichen Komponenten (Print-Boxen, etc.) führte die Einstellung allerdings zu Problem, so dass diese Zonen so konfiguriert sein müssen, dass der DHCP für alle die dynamischen Updates durchführt.