\nEin Angreifer kann sich z.B. bei einer DNS Abfrage\u00a0 eines Clients zwischenschalten und ihm eine gef\u00e4lschte Antwort auf den DNS-Query liefern (z.B. eine IP-Adresse die ihn an einen anderen Rechner lenkt), noch bevor ihm sein eingetragener DNS Server antwortet.<\/p>\n
Schwachstelle DNS Server zu DNS Server<\/span> Gegenma\u00dfnahmen<\/span> Windows\u00a0Implementierung<\/span> Stand heute hat sich DNSSEC – vor allem auf Grund der nur langsam fortschreitenden Implementierung im \u00f6ffentlichen DNS Namespace – noch nicht weitgehend durchgesetzt.\u00a0 Ein weiterer Nachteil von DNSSEC ist, dass in Windows Umgebungen \u00c4nderungen an der signierten DNS-Zone nur noch manuell vom\u00a0 DNS-Administrator vorgenommen werden k\u00f6nnen.<\/p>\n Ein durchaus\u00a0 sinnvoller PKI-gest\u00fctzter Einsatzrahmen in einem Unternehmen kann dagegen in Hochsicherheitsbereichen sein, bei denen nur eine eingeschr\u00e4nkte Menge an Clients eine Namensaufl\u00f6sung durchf\u00fchren muss.<\/p>\n Vgl. Seshadri, Shyman; Lindsay, Greg: \u201eWindows Server 2008 R2 \u2013 DNSSEC Deployment Guide\u201c<\/a>.\u00a0 S.53-60.<\/p>\n","protected":false},"excerpt":{"rendered":" Das origin\u00e4re DNS-Protokoll zur Aufl\u00f6sung von Namen in IP-Adressen bietet keinerlei Sicherheitsmechanismen und ist deshalb anf\u00e4llig gegen\u00fcber Man-In-The-Middle, Spoofing und DNS-Cache Poisoning Angriffen. Schwachstelle Client – DNS Server Ein Angreifer kann sich z.B. bei einer DNS Abfrage\u00a0 eines Clients zwischenschalten … Weiterlesen
\nDer Angriff kann auch dadurch erfolgen, dass der Verkehr zwischen zwei DNS-Servern manipuliert wird, indem ein weiterer gef\u00e4lschter Record in eine Antwort eingeschleust wird, f\u00fcr die der sendende DNS Server eigentlich nicht autoritativ ist.
\nDer empfangende DNS Server nimmt\u00a0 den gef\u00e4lschten Record dann evtl. in seinen Cache auf und leitet die ihn selbst anfragenden Clients dann an die gef\u00e4lschte Zieladresse weiter.<\/p>\n![\"Attacking](\"http:\/\/lkl-it.de\/blog\/wp-content\/uploads\/AttackingDNS.jpg\" "\\"AttackingDNS\\"")
<\/a><\/p>\n
\nDNSSEC<\/strong> ist eine aktuelle Protokollerweiterung, welche die DNS Sicherheit durch Datenintegrit\u00e4t und Ursprungsbeweis \u00fcber Signaturmechanismen deutlich ausweiten kann.
\nDabei signiert der DNS-Server, der f\u00fcr eine Zone autoritativ ist, seine Zoneneintr\u00e4ge mit einem privaten Schl\u00fcssel.
\nAnfragende DNS-Server k\u00f6nnen dann, wenn sie mit dem korrespondierenden \u00d6ffentlichen Schl\u00fcssel (Trust Anchor bei DNSSEC genannt) ausgestattet wurden, die Zoneneintr\u00e4ge auf ihre Integrit\u00e4t und Unverf\u00e4lschtheit pr\u00fcfen.
\nIm Gegensatz zu den DNS-Servern k\u00f6nnen anfragende Endclients selbst keine DNSSEC Signierung pr\u00fcfen, sie m\u00fcssen sich dabei vollst\u00e4ndig auf ihren lokalen DNS-Server verlassen.<\/p>\n
\nZur Absicherung des Verkehrs zwischen Client und lokalem DNS-Server kommt in Windows Implementierungen eine spezielle IPSec-Richtlinie (siehe IPSec <\/a>) zum Einsatz, die auf X.509 Zertifikaten basiert (Client mit Clientauthentifizierungszertifikat, DNS-Server hat spezielles Serverauthentifizierungszertifikat mit DNS EKU).
\nZus\u00e4tzlich kann ab Windows 7 ein Client explizit \u00fcber eine NRPT<\/strong>-Regel (Name Resolution Policy Table) so konfiguriert werden, dass er von seinem eingetragenen DNS Server auch nur solche Antworten annimmt, bei denen dieser eine DNSSEC Signaturpr\u00fcfung vorgenommen hat.<\/p>\n![\"DNSSec](\"http:\/\/lkl-it.de\/blog\/wp-content\/uploads\/DNSecOnWindowsClientsJPG.jpg\" "\\"DNSecOnWindowsClientsJPG\\"")
<\/a><\/p>\n