You are here: Home » Dokumentation » Netzwerk » DNS und reverse mapping
Sorry, this page is not translated yet.

DNS und reverse mapping

Das Domain Name System bietet nicht nur die Auflösungen von Domainnamen wie cert.uni-stuttgart.de zu IP-Adressen (z.B. 129.69.16.9) an, sondern auch die umgekehrte Richtung, mittels sogenannter reverse lookups.

Funktionsweise eines reverse lookups

Für einen reverse lookup wird zunächst die IP-Adresse (beispielsweise 129.69.16.9) in ihre Komponenten aufgeteilt und die Reihenfolge umgedreht. Dann wird noch die Zeichenkette “.in-addr.arpa” abgegängt (wodurch sich in unserem Beispiel 9.16.69.129.in-addr.arpa ergibt).

Mit dem so gewonnenen Bezeichner wird über die üblichen Mechanismen eine DNS-Abfrage durchgeführt, allerdings nicht für einen A record (der eine IP-Adresse enthält), sondern für einen PTR record, der einen Verweis (pointer) auf einen anderen DNS-Eintrag enthält (also den zur Adresse gehörigen Domainnamen).

Mit dem Werkzeug dig kann man sich detailliert anzeigen lassen, welches Ergebnis eine solche PTR-DNS-Anfrage liefert:

;; QUESTION SECTION:
;9.16.69.129.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
9.16.69.129.in-addr.arpa. 172800 IN	PTR	cert.uni-stuttgart.de.

;; AUTHORITY SECTION:
69.129.in-addr.arpa.	172800	IN	NS	artemis.rus.uni-stuttgart.de.
69.129.in-addr.arpa.	172800	IN	NS	themis.rus.uni-stuttgart.de.
69.129.in-addr.arpa.	172800	IN	NS	skylla.rus.uni-stuttgart.de.
69.129.in-addr.arpa.	172800	IN	NS	dns1.belwue.de.
69.129.in-addr.arpa.	172800	IN	NS	minnehaha.rhrk.uni-kl.de.
69.129.in-addr.arpa.	172800	IN	NS	ifi.informatik.uni-stuttgart.de.

;; ADDITIONAL SECTION:
artemis.rus.uni-stuttgart.de. 172800 IN	A	129.69.1.28
themis.rus.uni-stuttgart.de. 172800 IN	A	129.69.1.2
skylla.rus.uni-stuttgart.de. 172800 IN	A	141.58.231.9
dns1.belwue.de.		172800	IN	A	129.143.2.1
minnehaha.rhrk.uni-kl.de. 50381	IN	A	131.246.9.116
ifi.informatik.uni-stuttgart.de. 86400 IN A	129.69.211.1

Angriffsmöglichkeiten

Der Betreiber des DNS-Servers, der die Antwort für die PTR-Anfrage für 9.16.69.129.in-addr.arpa liefert, muss diesen DNS-Server nicht unbedingt so konfigurieren, dass dieser cert.uni-stuttgart.de zurückliefert. Er könnte sich z. B. auch für rus-cert.de entscheiden, selbst wenn ihm diese Domäne gar nicht gehören sollte.

Falls ein Programm einen reverse lookup durchführt und nur den gewonnenen DNS-Eintrag in das Logfile schreibt, ist dieses Logfile im Zweifelsfall wertlos, da diese Einträge auch in der Praxis manipulierbar sind. Noch problematischer wird die Angelegenheit, wenn der DNS-Eintrag zur Autentifizierung bzw. Autorisierung verwendet wird, da sich dann ein Angreifer mit geringem Aufwand Zugriff auf geschützte Ressourcen verschaffen kann.

In Logfiles machen sich Angriffe (oder Fehlkonfigurationen, was viel wahrscheinlicher ist) beispielsweise wie folgt bemerkbar:

Nov 23 05:13:33 cert sshd[9674]: log:
   reverse mapping checking gethostbyname for RUS-CERT.DE failed 
   - POSSIBLE BREAKIN ATTEMPT!

Um im Beispiel zu bleiben: Die Adresse RUS-CERT.DE stammt aus dem PTR record und wurde gefälscht, womit diese Information ziemlich wertlos ist. Man muss in diesem Fall hoffen, dass die IP-Adresse an anderer Stelle aufgezeichnet wurde.

Der Hinweis POSSIBLE BREAKIN ATTEMPT! ist hier ein wenig überzogen. Solche Fehler im DNS können auch durch versehentliche Fehlkonfiguration entstehen. (Allerdings kommen viele Scans nach verwundbaren SSH-Servern aus Netzen mit fehlerhaft konfiguriertem reverse lookup.)

Gegenmaßnahmen

Zur Verifikation der PTR-Antwort ist es ratsam, eine gewöhnliche DNS-Anfrage nach einem A record zu stellen, und zwar für die Domain, die in der PTR-Antwort vorgefunden wurde. Die PTR-Antwort kann nur dann korrekt sein, wenn die ursprüngliche IP-Adresse in einem A record auftaucht. Die Annahme, die hier zugrundeliegt, besagt, dass es für einen Angreifer deutlich schwieriger ist, die Anfrage nach dem A record zu fälschen, da dies DNS spoofing (siehe unten) erfordert, oder einen erfolgreichen Angriff auf einen der DNS-Server, der diesen A record dem Client anbietet.

Diese Gegenmaßnahme beseitigt allerdings nicht die grundlegenden Unwägbarkeiten des DNS-Protokolls. Beispielsweise ist bei allen DNS-Clients DNS spoofing möglich, über das ein Angreifer einem System eine falsche Sicht des DNS-Baumes vermitteln kann. Die DNS-Implementierungen unterscheiden sich hier nur beim nötigen Aufwand (von “trivial” bis “unpraktikabel”).

Außerdem sollte immer auch eine IP-Adresse geloggt werden (und nicht ein bloßer Eintrag aus dem DNS), da das reverse lookup unter Umständen nur wenige Minuten möglich ist und nicht mehr zu dem Zeitpunkt, zu dem die Logfiles ausgewertet werden (müssen).