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).