Wie die Namensauflösung im Detail abläuft
Es ist ja immer zwischen zwei Punkten zu unterscheiden. Der erste ist die Bereitstellung von DNS-Services für Clients auf der LAN-Seite, das übernimmt der multid und nur da gelten auch solche Namen wie "fritz.box", "kabel.box", usw..
Der zweite Punkt ist das lokale Auflösen von DNS-Namen, dafür ist aber die jeweilige Standard-C-Library (gethostname() und Konsorten, auch wenn es bei IPv4/v6-Mix dann andere Funktionen gibt) zuständig und die zieht die "normalen" Linux-Mechanismen (/etc/resolv.conf) nach sich. Bei moderneren Firmware-Versionen steht in der /etc/resolv.conf jedoch immer nur die Zeile "nameserver 127.0.0.1" drin. Da sich hinter der Datei aber ein Symlink auf /var/tmp/resolv.conf verbirgt, kann man da auch problemlos andere Nameserver direkt eintragen, damit umgeht man dann - nur für die Abfragen von Software auf der Box selbst und auch nur dann, wenn die über den Resolver-Code in der Standard-Library abfragt (der voipd macht das z.B. meines Wissen nicht) - den multid und seine "Kenntnisse" über die lokalen Clients.
Welche das konkret sind, kann man sich über
Code:
msgsend multid dnsdump;sleep 2;cat /var/tmp/dnsddebug.txt
anzeigen lassen. Welche Server der multid als DNS-Proxy/Forwarder seinerseits abfragt, steht in der Datei /var/tmp/dnsd_servers. Das hat erst einmal nichts mit den Angaben des Providers zu tun, diese stehen parallel in der Datei /var/tmp/avm-resolv.conf. Nach einer Änderung der /var/tmp/dnsd_servers muß man den multid mit einem "multid -I" zum Neulesen überreden. Das "Überreden" zum Löschen des Caches mit "msgsend multid dnsflush" funktioniert hingegen bei mir nicht, da hilft dann nur der Neustart des multid, auch das SIGHUP bringt da nichts (auch kein USR1/2 o.ä.). Beim Neustart des multid kann dann (neben delaystart-Tasks) auch noch einiges anderes zu Bruch gehen, was am "dev lan" lauscht, da die Bridge ggf. neu installiert wird (und dabei natürlich vorher gelöscht).
Ich musste selbst zumindest die Erfahrung machen, dass sich einige Fritzboxen nur mit Provider: fritz.box und Proxy: IPderProviderbox anmelden und nutzen ließen, bei anderen Kombinationen der Provider aber auch als IP funktionierte (fritz.box und Proxy ging da aber auch)
Auch schon mal, daß da tatsächlich beim Eintragen einer IP-Adresse per Reverse-Lookup wieder auf fritz.box geschlossen wurde, auch wenn die IP-Adresse eben nicht die der lokalen Box war? Das ist es ja nur, was mich so verblüfft.
Gerade, dass die Box, an der man sich anmeldet, bei vielen Firmwareversionen erwartet, mit 'fritz.box' als Provider angemeldet zu werden, spricht für eine Art Hardcodierung.
Das erstaunt mich (für aktuelle Firmware) schon ... ich habe diese Erfahrung bei den Modellen 7490/7390/7270(1+3)/6360/6490 (ich sag mal seit 06.05, um nicht zu sehr in die Vergangenheit abzuschweifen) noch nie so gemacht, nicht einmal die Anforderung, daß da unbedingt eine URI "
[email protected]" kommen muß, damit der Registrar richtig reagiert.
Der voipd arbeitet aber auch gleich noch einmal anders, der greift nur in begrenztem Umfang auf die Standard-Library zu. So kann er einerseits DNS-Anfragen immer von einem bestimmten Port aus machen (7077 ist imho Standard) und damit diese Abfragen auch anders klassifizieren lassen (sipdns heißt der Filter, wenn ich mich richtig erinnere) und gleichzeitig auch tatsächlich immer den DNS-Server befragen, der für das Interface zuständig ist, über das eine SIP-Registrierung laufen soll. Wenn z.B. ein Provider (im Kabel gerne genommen) für die SIP-Telefonie ein eigenes virtuelles Interface (voip) benutzt und für den "normalen Traffic" ein anderes (internet), dann können die ja auch unterschiedliche IP-Adressen haben (das voip-Interface eben auch gerne mal private) und auch jeweils einen eigenen DNS-Server - das kann ja alles in einer DHCP-Antwort für dieses Interface enthalten sein. Manchmal sind dann auch DNS-Namen für SIP-Registrare nur im internen Netz gültig und nur bei der Abfrage über den diesem Interface zugeordneten DNS-Server.
Vermutlich um solche Komplikationen zu vermeiden, macht der voipd (nach meinen Tests, die gar nicht so lange her sind) seine eigenen Abfragen von DNS-Servern (nur so kann er den Absenderport auch festlegen, das klappt bei den "normalen" Resolver-Funktionen natürlich nicht) und speichert auch die Ergebnisse selbst. Auch solche interessanten Sachen wie die IP-Adressen an den verschiedenen (auch virtuellen) Interfaces muß er natürlich kennen, denn nur so kann er selbst (die FRITZ!Box hat nach meinem Dafürhalten kein anderes ALG für SIP) die notwendigen Änderungen/Ergänzungen an SIP-Paketen auch vornehmen (VIA-Header zum Beispiel). In dieser ALG-Logik dürfte auch ein guter Teil der früheren Schwierigkeiten stecken, wobei die Registrierung "@fritz.box" wohl tatsächlich nur bei schon ziemlich alten Firmware-Versionen noch notwendig war (wenn das nach 06.05 noch irgendwo so ist, würde mich das tatsächlich interessieren, wo).
Bei der "Anmeldung aus dem Internet" sollte die Box eigentlich auf "nummer@dyndns_name" (parallel auch MyFRITZ!-Name) oder "nummer@ip_adresse" reagieren. Beim Zugriff über VPN dann eigentlich wieder nur über "nummer@lan_adresse" bzw. "
[email protected]" (der interne Domain-Name sollte irgendwann auch mal einstellbar werden). Wenn da irgendetwas anderes geht, dann wäre das eher ungünstig.
Ansonsten werden ankommende externe Pakete vom (k)dsld auch ganz normal mit einer passenden Forward-Regel (cat /proc/kdsld/dsliface/internet/ipmasq/forwards) an die LAN-Adresse der FRITZ!Box weitergeleitet und erst dort vom voipd in Empfang genommen.
Allerdings erhalten sie beim Durchqueren des Packet Accelerators (avm_pa) eine zusätzliche Struktur zur Seite gestellt (avm_pa_pkt_info), in der detaillierter als üblich vermerkt ist, auf welchem Interface dieses Paket ankam (internet/voip oder auch "homenet") und wohin es gesendet wurde. Da diese Information einer - universell bei der Behandlung von Netzwerkpaketen verwendeten - Struktur (sk_buff) hinzugefügt werden, stehen diese Informationen auch später noch zur Verfügung. Nur dürfte der voipd da theoretisch (wenn es nicht irgendwelche "schmutzigen Tricks" seitens AVM gibt, mit denen die Informationen aus dem Kernel-Space vom User-Space aus lesbar gemacht werden - die Möglichkeiten sind vielfältig) gar nicht drankommen, denn der sollte eigentlich nur die "normalen" Socket-Calls zur Verfügung haben als "user space program". Vielleicht gibt es ja tatsächlich irgendwelche zusätzlichen Schnittstellen, ansonsten könnte auch schon der Interface-Index beim Empfang des SIP-Pakets (über IP_PKTINFO-Option) ausreichend sein, um das Paket zuordnen zu können. Wenn bekannt ist, woher es kam, kann es auch passend modifiziert/kontrolliert werden.
Was ist falsch an direkten SIP-URI-Anrufen?Es ist ja beim SIP-Protokoll nicht nur so, daß da eine Registrierung erfolgt (die braucht es ja eigentlich nur, damit der Provider auch eingehende Gespräche ans Ziel bringen kann bzw. wenn der Kunde seinerseits ausgehende Gespräche führen will), wegen des connection-losen UDP bei INVITE kann eben auch jeder, der die korrekte Nummer kennt (die steht bei showvoidpstat dabei), ein passendes INVITE senden, worauf die FRITZ!Box dann mit TRYING reagiert und ihrerseits alle für diese Nummer eingeteilten Nebenstellen klingeln läßt, was sie dann mit RINGING quittiert. Da es dort keine Authentifizierung beim INVITE gibt (nur deshalb klappt ja ein URI-Anruf) und auch wohl keinen Test, ob die Nummer überhaupt bei einem Provider registriert werden konnte, kann man so problemlos die Telefone an einer FRITZ!Box erst einmal klingeln lassen, solange man keine echte Sprachverbindung aufbauen will. Das verursacht zwar keine Kosten in materieller Hinsicht (es ist ja ein eingehender Anruf), aber es kostet auch Nerven, wenn einen da jemand ärgern will und man z.B. eine statische Adresse und eine Telefonnummer hat, die man nicht mal so aus dem Stand ändern kann.
Da sich die Absenderadresse eines UDP-Pakets auch noch problemlos fälschen läßt (nur beim 3-Way-Handshake für TCP wird es etwas komplizierter, da etwas zu faken), wenn man das Paket erst einmal "in Verkehr gebracht" hat, gibt es auch praktisch keine Möglichkeit, solchen Praktiken (die man ja auch als DoS oder zumindest als nervig ansehen kann) einen Riegel vorzuschieben. Wenn dann als URI auch noch rufnummer@ip_adresse funktioniert (wobei da auch uri@sip_registrar nicht so viel anders ist, denn den Registrar kann man mit hoher Wahrscheinlichkeit anhand der IP-Adresse auch vorhersagen) und man irgendwie - das kann eine E-Mail mit ihren Header-Angaben sein - zu einer bekannten Rufnummer die aktuelle IP-Adresse ermitteln kann (das kann natürlich auch eine DynDNS-Abfrage sein), dann kann man den Telefonanschluß praktisch lahmlegen und da ist auch nichts mehr mit "Fangen" o.ä., wie es bei leitungsgebundener Telefonie noch funktionierte - der Absender bleibt schlicht im Dunklen bzw. der angegebene Absender muß noch lange nicht der wirkliche sein.
Das trifft mit einiger Wahrscheinlichkeit auch nicht nur auf die FRITZ!Boxen zu, die Speedport-Router werden da nicht so viel besser sein - vielleicht filtern sie etwas krasser, weil sie theoretisch nur bekannte IP-Adressen des Providers (also der Telekom) als Absender für INVITE-Pakete akzeptieren müßten. Aber auch das wäre ziemlich leicht zu umgehen - es ist eben kein Problem, ein UDP-Paket mit der gefälschten IP-Adresse eines SIP-Servers des Providers auf die Reise zu schicken, UDP-Pakete tragen außer der Absenderadresse keine Information, woher sie wirklich kommen.
Wenn man also einer FRITZ!Box ein INVITE für eine gültige URL schickt, muß das Paket noch lange keine gültige Absenderadresse haben. Man muß nur irgendwie dafür sorgen, daß die Antwort der Box (TRYING) nicht irgendwo aufschlägt, wo sie mit einer ICMP-Nachricht o.ä. abgelehnt wird, da dann die FRITZ!Box davon Kenntnis erhält, daß das TRYING nicht angekommen ist und somit irgendetwas faul sein muß. Da hilft schon ein geeignet gewählter Absenderport, denn das DROPpen von eingehenden Paketen - was Portscans verlangsamt, weil auf Timeouts gewartet wird - wird hier zum Pferdefuß, weil eben auch keine negative Antwort kommt. Es muß nach SIP-Standard nicht zwingend eine Quittung auf die TRYING-Nachricht erfolgen, so daß solange alles in Ordnung erscheint, solange gar keine Antwort eintrifft. Ob dann tatsächlich ein "unreachable/admin prohibited" o.ä. auch zum Abbruch des gesamten SIP-Dialogs (und damit des Klingelns) führt, weiß ich auch nicht genau, das ist reine Vermutung. Normalerweise würde so ein Request ja erst mit einem weiteren CANCEL-Request aufhören zu klingeln (oder nach einem entsprechende Timeout).
Ich weiß also nicht, nach welcher Logik die Validierung eines INVITE-Requests erfolgt, aber wenn es möglich ist, über SIP-URI zu telefonieren (und das nicht auf den Provider zu beschränken ist), dann kann da eigentlich nicht so viel Vorsorge vorhanden sein. Wie gesagt, das gilt ja nicht nur für die FRITZ!Box. Jeder Asterisk-Admin kennt die Notwendigkeit, daß sich der Client bei einem INVITE-Request entsprechend authentifiziert (allowguest=no), sonst kann jeder Idiot (vorwiegend von Adressen aus China, aber die könnten ja auch gefälscht sein) den Asterisk-Server mit INVITEs quälen. Leider gibt es eben auf dem umgekehrten Weg keine
zwingende Authentifizierung ... so etwas würde allerdings auch SIP-URI-Anrufe unmöglich machen und bei der Registrierung des SIP-Clients (also der FRITZ!Box) beim Provider den zusätzlichen Austausch von Credentials erforderlich machen. Wenn man dann wieder die REGISTER-Frequenz (einer FRITZ!Box 7490) mit 260 Sekunden (solange da zwischendrin kein anderer Traffic stattfindet zwischen Registrar und Client) ins Kalkül zieht, wäre wohl auch der SIP-Registrar beim Provider nur noch mit dem permanenten Updaten solcher dynamischer Credentials beschäftigt, wenn nur die Anzahl der SIP-Clients groß genug wird. Diese Credentials könnten ja auch so eine Art "Cookie" sein, aber auch das will erst einmal verwaltet werden.
Auch die Idee, im DSL-Netz eines Providers erst gar keinen "ingress traffic" zuzulassen, der angeblich aus dem eigenen Netz stammt (das würde ja dann das Fälschen von SIP-Server-Adressen des Providers von außen erschweren), ist zwar gegen das allzu leichte Fälschen von Absendern für die eigenen SIP-Server eine denkbare Lösung, funktioniert aber spätestens dann nicht mehr, wenn der DSL- und der VoIP-Provider nicht derselbe ist. Wobei das Verhindern der nomadischen Nutzung von SIP-Accounts bei einigen Providern sicherlich auf solchen Entscheidungen beruht ... aber wenn irgendwann mal alles "All-IP" ist, dann wird das bei großen Providern mit mehreren SIP-Servern in unterschiedlichen Segmenten für die Erhöhung der Verfügbarkeit, wenn mal ein komplettes AS ausfällt, auch schnell unpraktikabel.
PS:
Ich habe tatsächlich keinen der Tests gegen eine SIP-Registrierung bei einem "echten" VoIP-Provider ausgeführt ... alles nur von einer 7490 gegen einen eigenen Asterisk-Server (allowguest=no) getestet und mit dem Faken von UDP-Paketen für den Asterisk-Account in der FB vom Asterisk- und einem weiteren Server in einem anderen Netz (es ging ja auch um die Frage der Sicherheit des Clients und nicht des Registrars).
Sollten also tatsächlich noch irgendwo weitere Vorsichtsmaßnahmen bei einem Provider greifen, könnten einige der beschriebenen Angriffe nicht funktionieren.
Auch habe ich gar nichts mit IPv6 getestet ... wenn es IP-Telefonie auch an DS-Lite-Anschlüssen gibt, müßte das ja auch alles mit IPv6 funktionieren - da wird ja sicherlich nicht das CGN-Gateway benutzt, wenn der Access-Provider auch der VoIP-Provider ist.
Die Angaben/Annahmen zum Verhalten von dsld, PA und voipd basieren auf Beobachtungen, den Angaben der /proc-Interfaces und den Quellen des Packet Accelerators, soweit diese im Source-Paket von AVM mit enthalten sind.
