Da die Fritz!Boxen NAT-Loopback unterstützen, gibt es keinen ernsthaften Grund, für einen "öffentlichen" Hostname eine private IPv4-Adresse zurückzumelden.
Ich musste erstmal rausfinden, was NAT-Loopback sein soll. Das ist in meinen Augen jetzt nicht so ein Sonderfeature, dass es einen eigenen Namen bräuchte, aber hey, wenn's dem Marketing hilft...
Es ist ja super, dass die Fritzbox auch aus dem internen Netz heraus mit ihrer öffentlichen IP erreichbar ist und Portweiterleitungen funktionieren. Meine Suche nach dem Begriff hat aber auch den Eindruck erweckt, dass das nicht überall so ist. Das das nicht geht ist in meinen Augen genau so unsinnig wie die DNS Manipulation, zeigt aber, dass Dein Ansatz, überall nur öffentliche IPs zu verwenden, scheinbar nicht unumstritten ist.
Und was mache ich eigentlich, wenn meine server1.meinedomain.de und server2.meinedomain.de beide grade unter der selben public IP erreichbar sind, und ich jetzt mit einem davon HTTP sprechen will?
Ich kann eigentlich beide durch ihre internen IPs unterscheiden, aber weil es das Sicherheitsempfinden meines Routers stört soll ich mir jetzt für HTTP verschiedene Ports merken? Am besten nur auf der public IP, intern bleibt es Port 80?
Wenn ich das nicht will, bin ich ratz fatz wieder bei Split DNS oder wie die Kids das heute nennen, was aber auch keine Lösung für die unterschiedlichen Ports hat. Oder ich nehme intern komplett andere Zonen und muss dann alles für verschiedene Hostnamen konfigurieren.
Nee, danke, das überzeugt mich hinten und vorne nicht. Wenn das mehr als einen Workaround braucht, dann kann das nicht die beste Lösung sein die man sich ausdenken kann.
Im Allgemeinen würde ich den Angriff eher über korrekte Konfiguration abblocken. Das erzeugt deutlich weniger Fehler und Probleme, und greift nicht ins DNS ein, was man vielleicht aus anderen Gründen immer korrekt haben will.
... bei korrekter Konfiguration wird weder für www.google.com noch für mein.dyn.org oder blubber.no-ip.com jemals eine private IPv4-Adresse zurückgemeldet werden.
Man greift also nicht in in dem Sinne in die DNS-Namensauflösung ein, sondern verhindert vielmehr Eingriffe durch Dritte.
Mit korrekter Konfiguration meinte ich natürlich, dass man dem internen Dienst, der so bereitwillig jedem dahergelaufenen HTTP Request alle Deine wichtigen Daten mitgibt, beibringt genau das nicht zu tun. Dazu später mehr.
Im DNS gibt es ja durchaus verschiedene Ansätze, wie man mit RFC1918 umgeht; es gibt sogar das Argument, dass man seine internen IPs aus Sicherheitsgründen sowieso nicht public machen sollte.
Da wird dann mit verschiedenen Views auf Zonen gearbeitet, oder man verwendet direkt interne Zonen ("host.firma.lan"). Die große Nachteile ist, dass man immer den richtigen DNS Server erreichen können muss, damit das funktioniert, und jedem Host auch beibringt, welchen Server er verwenden soll.
In der Regel kannst Du zwar die Server prinzipiell erreichen, z.B. weil man sich ja eh vorher ins VPN eingewählt hat, aber was machst Du z.B. bei mehreren aktiven (VPN-) Verbindungen - das System kann die Verknüpfung zwischen IP-Netz, DNS-Zone und Server für die DNS Auflösung garnicht abbilden*.
DNS ist kein Fallback-System, in dem ich solange alle Server durchprobiere bis einer meinen Request beantwortet. DNS kennt nur ja oder nein, und die erste Antwort gewinnt.
In meiner Welt sind alle Systeme heutzutage sowieso kontinuierlich in mehreren logischen Netzen unterwegs, und da bleibt mir nichts anderes übrig, als die Eindeutigkeit des DNS zu akzeptieren und dann eben auch so zu nutzen. Wenn ich meinen host "notebook" von überall im DNS finden können will, dann muss er halt notebook.meinedomain.de heissen. Und da der eben nativ eine RFC1918 Adresse hat, steht die dann auch im DNS. Damit ich den Host aus verschiedenen Netzen erreichen kann (das hängt vom Netz ab in dem er grade ist und ob z.B. Weiterleitungen eingerichtet sind oder UPnP erlaubt ist), landen die entsprechenden Infos als SRV im DNS, wo ich die Priorität angeben kann.
Ich würde dazu aber verschiedene Ansätze akzeptieren, das ist in meinen Augen auch eine philosophische Frage und da gibt's ja bekanntlich kein richtig und falsch. Und mit v6 erledigt sich das ja dann hoffentlich sowieso, der ganze RFC1918 Kram ist bei mir auch nur noch legacy.
* mit DNSmasq kann man das bauen, wenn man Linux und root-Rechte hat - womit die Relevanz dieses Workarounds auch direkt klar ist.
Und Schutzmaßnahmen gegen DNS-Rebinding werden üblicherweise auch bei Nutzung von BIND, Unbound, DNSMasq, usw. konfiguriert.
Von DNSmasq abgesehen, der kein DNSSEC kann, sehe ich öfters Konfigurationen mit DNSSEC als mit einem Rebindschutz. Die anderen Resolver (um authoritative Server geht es ja grad nicht) würde ich im Homerouter-Kontext nicht erwarten, daher wundere mich nicht, dass entsprechende Konfigs mir noch nicht untergekommen sind.
DNSSEC und Rebindschutz lässt sich übrigens auch nur deshalb vereinbaren, weil man einem Client nicht zubilligt, die Signaturen selbst zu checken. Zum Glück wird DNSSEC wohl genau so selten verwendet wie RFC1918 im public DNS, dass die Überdeckung wohl vernachlässigbar gering ist und bisher auch noch nichts dadurch kaputt gegangen ist.
Wie soll Dein Schutz aussehen?
- Der Hostname, den der Browser verwendet, steht im HTTP Header (und wird bei TLS zusätzlich noch via SNI übermittelt).
- Der Browser sendet einen Referer, der zumindest ein enger Indikator für "fremde" Requests ist.
Geräte, die Du nicht entsprechend konfigurieren kannst, nehmen wir als Beispiel eine properitäre IP Kamera mit un-/schlecht gesichertem Backend, gehören sowieso hinter einen Proxy oder in ein Managementnetz und sind daher gar nicht direkt erreichbar.
Bevor Du übersiehst, was ich eigentlich kritisiere:
Ich erkenne an, dass es für die meisten Anwender nicht Realität ist, ihre internen IPs ins öffentliche DNS zu legen. Es macht mir daher nichts aus, dass es manche Router entsprechend unterbinden. Ob man das möchte muss jeder selbst wissen, und ich selbst kann dank Endgerätefreiheit entsprechenden Schrott von meinen Netzen fern halten.
Ich widerspreche Deiner Aussage, dass es
grundsätzlich richtig sei, RFC1918 aus dem öffentlichen DNS zu filtern.
