dns_cache_project/defense.html at master · ldzgch/dns_cache_project · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8">
		<meta name="viewport" content="width=device-width, initial-scale=1">
		<link rel="stylesheet" type="text/css" href="./css/style_2.css">
		<title>CachePoisoning</title>
	</head>
	<body>
		<ul>
			<li><a href="./index.html">Home</a></li>
  		<li><a href="./basics.html">DNS Cache Poisoning</a></li>
  		<li><a href="./dnsprocess.html">Übersetzung einer Domain</a></li>
			<li><a class="active" href="./defense.html">Abwehrmethoden</a></li>
  		<li><a href="./example.html">Beispiel</a></li>
			<li><a href="./glossary.html">Lexikon</a></li>
		</ul>

		<article>
		<h1>Abwehrmethoden</h1>
			<p>Wenn der Cache-Poisoning-Angriff sauber durchgeführt wird, kann ein normaler Nutzer wenig tun, um sich zu schützen. Ein fehlerhafter Eintrag auf einem DNS-Server kann nur von seinem Besitzer korrigiert werden, sonst muss man die TTL (=time to live) des fehlerhaften Cache-Eintrags abwarten und hoffen, dass dieser dann durch den richtigen ersetzt wird.
Aber auch der Serverbesitzer hat wenig Optionen. Ein DNS-Server ist von anderen abhängig, weil dieser alleine nie alle IP-Adressen in seinem Speicher hat. Das ist problematisch, weil man auf komplett fremde Server vertrauen muss, die Informationen, die sie uns geben, sind ausserdem schwer zu kontrollieren. Grundsätzlich muss die Serversoftware immer aktuell gehalten werden und das Betriebssystem des Servers soll so abgespeckt wie möglich sein. Eine einfache Firewall ist immer empfehlenswert. [5]
Diese Ansätze reduzieren das Risiko, dass ein DNS-Server direkt «gehackt» wird, indem ein Angreifer eine Sicherheitslücke ausnutzt und danach Zugriff auf den DNS-Cache erhält.
Eine langfristige Lösung bietet DNSSEC. Dabei handelt es sich um ein Konzept, welches das gesamte DNS-System signieren will. Mithilfe von einem asymmetrischen Schlüsselsystem werden alle autoritativen Nameserver von einem höherstehenden Server verifiziert, so dass man nur noch auf die Rootserver vertrauen muss. Kann ein Server bzw. sein Public Key validiert werden, dann darf dieser benutzt werden, um einen DNS-Request zu entschlüsseln. [42]
Die Rootserver unterstützen DNSSEC bereits seit 2010, die Verbreitung des Sicherheitssystems erfolgt jedoch relativ langsam. Problematisch ist, dass plötzlich eine Vielzahl an kryptografischen Schlüsseln umhergeschickt werden müssen, was mit einer allgemein höheren Auslastung des DNS-Systems verbunden ist. [33]
			</p>
		</article>
	</body>
</html>