Abhilfe ist im Prinzip nicht schwer. Anstelle den NAT-Router als DNS-Server zu verwenden, wie es meist der Fall ist, wenn man seine Rechner vom Router per DHCP konfigurieren lässt, trägt man die DNS-Server des Providers, freie DNS-Server oder die DNS-Server von Google ein, siehe Bild 4.
Endanwender, die von der neuen Sicherheit bei DNS profitieren möchten, müssen zunächst enttäuscht werden. Um den eigenen Rechner sicher zu machen, muss man einen Resolver-Mechanismus auf seinem Rechner installieren, der DNSSEC unterstützt. Das ist nicht grundsätzlich unmöglich, jedoch mit Schwierigkeiten verbunden.
Windows hat einen DNS-Client, der die Namensauflösung vornimmt und in der Lage ist, DNS-Antworten zu cachen. Er unterstützt kein DNSSEC. Unix-Betriebssysteme wie Linux und Mac OS können von Haus aus noch weniger. Sie befragen grundsätzlich bei jeder Namensauflösung einfach die konfigurierten DNS-Server in der Datei /etc/resolv.conf. Wer lokales Caching haben möchte, muss ein Programm wie nscd installieren, das bei vielen Linux-Distributionen mitgeliefert wird.
Um DNSSEC auf dem eigenen Rechner zu installieren, kommt man bei allen Betriebssystem nicht umhin, einen DNSSEC-fähigen DNS-Server aufzusetzen, der zunächst als Caching-Only-Server konfiguriert wird. Eine Anleitung gibt der ZDNet-Artikel Sperre von freien DNS-Servern: So umgeht man die Blockade.
Bevor man sich diese Mühe macht, sollte man jedoch wissen, dass eine lokale Installation von DNSSEC erst sinnvoll ist, wenn DNSSEC durchgängig in allen Domainhierarchien verfügbar ist. Generell wird für jede DNS-Zone ein öffentlicher Schlüssel benötigt. Diesen darf man sich jedoch nicht per DNS holen, weil eine gefälschte DNS-Antwort auch einen gefälschten Schlüssel beinhalten kann. Der Schlüssel muss daher auf einem anderen Übertragungsweg kommen, etwa über eine HTTPS-Verbindung.
Das bedeutet, dass man sich für jede Domain einen Schlüssel beschaffen und in seine DNS-Serverkonfiguration eintragen muss. Das ist praktisch nicht durchführbar. Daher lassen sich die sogenannten Zone Signing Keys (ZSKs) mittels Key Signing Keys (KSK) verketten. Im Idealfall reicht es aus, als „Trust Anchor“ nur den KSK der Root-Zone zu konfigurieren.
Derzeit gibt es jedoch nur „DNSSEC-Inseln“. Das bedeutet, dass man die KSKs jeder Inselhierarchie in seiner DNS-Konfiguration pflegen muss. Dazu ist es auch erforderlich, gelegentliche Schlüsselwechsel zu berücksichtigen und seine Konfiguration upzudaten.
Endanwender können von DNSSEC derzeit nur profitieren, wenn die DNS-Server des Providers DNSSEC unterstützen. Wer nicht die Server seines Providers einsetzt, ist DNS-Cache-Angriffen genauso ausgesetzt wie DNS-Server-Betreiber. Die Provider können in ihrem eigenen Netz sicherstellen, dass IP-Adressen aus dem eigenen Adressraum nicht von außen akzeptiert werden. Kommt ein gespooftes Paket, jedoch von einem fremden DNS-Server, etwa 8.8.8.8, hat der Provider keine Möglichkeit festzustellen, ob das Paket wirklich vom Google-DNS-Server kommt.
Immer häufiger müssen sich Betriebe gegen Online-Gefahren wehren. Vor allem in KMUs werden oft noch…
Darunter ist ein weiterer Sandbox-Escape. Angreifer können unter Umständen aus der Ferne Schadcode einschleusen und…
Sie steigt auf 8 Prozent Wachstum in diesem Jahr. Der Bereich IT-Services wächst in diesem…
Die Hintermänner stammen mutmaßlich aus Russland und haben staatliche Unterstützung. Die Backdoor Kapeka wird seit…
Cyberkriminelle haben auf Zahlungs- und Zugangsdaten abgesehen. LinkedIn landet auf dem ersten Platz. Zudem verhelfen…
Die Paysafecard hat sich in den letzten Jahren als eine der beliebtesten und sichersten Zahlungsmethoden…