DNS-Hijacking - Captive Portal - Bind

[N3X]

Moin,

ich habe ein kleines Problem für andere Verhältnisse.

Ich konfiguriere mir gerade für private Zwecke / Bestimmte Zwecke ein Captive Portal, Marke Eigenbau aufgrund von einigen Punkten die fertige Captive Portale nicht erfüllen.

Nun möchte ich, dass alle DNS lookups mit einer einzigen IP-Adresse beantwortet werden, und zwar der von meinem Portal.

Allerdings kenne ich mich mit bind null aus bzw. generell DNS-Servern.
Aber ich würde gerne die Zone "." soweit umschreiben, dass alle Anfragen dafür mit einer einzigen IP-Adresse beantwortet werden.

Wie kann ich das am besten realisieren?

Um die prerouting regeln für iptables (nur nicht authentifizierte User) habe ich mich bereits gekümmert, die funktionieren auch einwandfrei für DNS.

Ich setze die Linux Distribution Debian ein in der Version 7.

 

[GwenDragon]

@       IN      SOA     host.dom.tld. mail.dom.tld. (
                        2013010101      ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                4W      ; Expire
                                3H )    ; NX (TTL Negativ Cache)

@                               IN      NS      host.dom.tld.
                                IN      A       192.168.0.10                ; IP portal
host                            IN      A       192.168.0.10

host.dom.tld ist der FQDN (Fully Qualified Domain Name) deines "Gateways".

Weiteres zu bind:
https://wiki.gentoo.org/wiki/BIND/Tutorial
http://www.howtoforge.com/howtos/dns/bind
http://openbook.galileocomputing.de/ubuntu_1004/ubuntu_24_netzwerke_004.htm
http://openbook.galileocomputing.de/linux/linux_kap20_002.html

 

[N3X]

Das ist mir durchaus klar, nur möchte ich nicht eine spezifische Domain hinterlegen, sondern allerlei DNS-Requests auflösen mit der IP-Adresse meines Servers. Sprich der DNS-Server soll für alle Lookups mit der gleichen IP-Adresse antworten.

 

[PapaBaer]

Im DNS fremder Domains rumfingern ist keine gute Idee. Das hat tonnenweise unschöne Seiteneffekte für deine Nutzer. Sowas will man nicht machen.

Was du willst ist Port-Forwarding. Es wird per DNS alles korrekt aufgelöst, aber der ausgehende (HTTP-)Traffic wird auf dein Portal umgebogen.

 

[N3X]

Habe ich schon gelöst.
Ich war der Meinung geschrieben zu haben, dass ich Prerouting regeln in iptables für meine User schreibe aber okay.

Jedenfalls habe ich ein VPN-Server am laufen wo ich die user authentifizierten lasse mittels ihrer Zertifikate, dazu lasse ich nach dem login ein post authentification script laufen, welches mir die entsprechenden prerouting einträge in iptables schreibt, insbesondere für das Weiterleiten aller DNS Anfragen an einen lokalen DNS-Server, wie aber auch genereller http traffic.

Nach dem authentifizieren werden die entsprechenden prerouting einträge entfernt und ein forward eintrag für den jeweiligen nutzer geschrieben, damit dieser auch über das eth interface raus"telefonieren" darf.

ich habe mir dazu jetzt eine zone "." angelegt mit einem "fake-master" eintrag mit folgender Konfiguration:

$TTL 86400
@ IN SOA @ root(
42 ;serial
3H ;refresh
15M ;retry
1W ;expiry
1D ) ; minimum
IN NS localhost
*. IN A 10.6.0.1
*. IN MX 10 localhost

und damit funktioniert das soweit nun auch, trotzdem danke für die hilfe.

Notiz:
Captive Portal aus dem Grund, dass ich das sharing von VPN-Daten vermeiden möchte und via das Captive Portal anhand einiger Parameter validiere ob der Benutzer der ist, der auch ursprünglich die Zertifikate erhalten hat.

 

[PapaBaer]

Dass deine Clients die "falschen" DNS Antworten cachen, ggf. auch länger, ist dir klar? Dass es sowas wie DNSSEC gibt auch? Dass es mehr als A-Records gibt und das wichtig sein könnte auch? ...

Du wirst in Zukunft fiese Bugs an den Clients fixen dürfen.

Ich bemerke gerade, dein Setup ist unter Umständen sogar strafbar: du sagst deinen Clients "für die nächste Woche liefert ihr alle Mails an alle Empfänger bitte bei mir ab, weil ich zuständig bin". autschn.

 

[N3X]

Ich hab die conf nachdem ich sie gestern hier geposted habe noch angepasst für meine Zwecke womit ich sie nur eine Minute Cache. (Obiger Eintrag ist ein Beispiel aus stackoverflow)

Außerdem reichen mir a-Records vollkommen, da ich nur die aufgerufenen Webseiten in einem webbrowser auf mein Portal weiterleiten möchte. Womit der User sich erst einmal via seinen Webbrowser und seinen zugangsdaten bei mir verifizieren muss bevor er ins Netz darf. Alles andere außer http ist solange er nicht eingeloggt ist nicht möglich. Nachdem Login des jeweiligen Nutzers werden die prerouting Einträge entfernt und eine Regel für forwarding in iptables eingefugt.

Zu den prerouting Einträgen gehört auch ebenfalls mein lokaler bind Server und die Adresse des Bind servers gebe ich nicf als dhcp Option mit, sondern vollkommen andere Server (öffentliche) der bind dient nur zwecks Umleitung auf mein Portal

Würde mich auch wundern wenn es strafbar wäre, tut die Telekom genauso bei ihren hotspots und mehr als a-Records "fälsche" ich in meiner aktuellen Konfiguration nicht. Zu mal wie oben beschrieben wird der Prerouting eintrag nach dem login entfernt, womit im Endeffekt keine Daten über einen Zeitraum von 1 Woche ausgeliefert werden würden.

Aber ich sehe es sowieso nicht ein mich hier rechtfertigen zu müssen. Ich habe nur hier danach gefragt ob mir jemand bei meinem Problem helfen kann. Wie alles im Endeffekt konfigurationsmäßig im Detail aussieht ist dann wieder eine andere Sache.
Jedoch bin ich mir dessen bewusst, was Strafbar ist und was nicht, da ich selbst als Anwendungsentwickler in der IT-Branche tätig bin.

 

[PapaBaer]

Ai, da muss ich leider doch noch einige Eier gerade rücken.

Außerdem reichen mir a-Records vollkommen, da ich nur die aufgerufenen Webseiten in einem webbrowser auf mein Portal weiterleiten möchte.

Es geht ja nicht darum, was dir reicht, sondern was die Clients im Zweifel alles so treiben könnten. Ich verstehe nicht, warum du unbedingt DNS nutzen musst. Du kannst das doch einfach mit einer Firewall-Regel erledigen. HTTP-Port raus geht direkt ans Captive Portal. Das ist technisch die viel sauberere Lösung und funktioniert auch, wenn z.B. Clients deinen DHCP-DNS gar nicht umsetzen, weil sie einen eigenen fest eingestellten benutzen. Habe ich genau so gebaut, funktioniert wunderbar.

Zu den prerouting Einträgen gehört auch ebenfalls mein lokaler bind Server und die Adresse des Bind servers gebe ich nicf als dhcp

Vollkommen korrekt, da du nicht weißt, ob deine Clients die DHCP-Option überhaupt umsetzen. Daher den Bind einfach, ebenfalls per Firewall-Regel, generell als transparenten Resolver einbinden und gut ist.

Würde mich auch wundern wenn es strafbar wäre, tut die Telekom genauso bei ihren hotspots und mehr als a-Records "fälsche" ich in meiner aktuellen Konfiguration nicht. Zu mal wie oben beschrieben wird der Prerouting eintrag nach dem login entfernt, womit im Endeffekt keine Daten über einen Zeitraum von 1 Woche ausgeliefert werden würden.

Aiaia, sorry, aber du stehst mit deiner Ansicht leider vollkommen im Wald. Die Domains gehören dir nicht. Daher steht es dir nicht zu, darüber Aussagen zu treffen und in das Kommunikationsverhalten der Clients einzugreifen, indem du z.B. MX-Records dafür verteilst. Damit greifst du für nicht angemeldete Clients in deren Fernmeldegeheimnis, da diese deinen Angaben entsprechend anfangen könnten, diese auch zu nutzen und z.B. Mails über dich zuzustellen. Genauso kritisch ist es, deine Login-Seiten unter der Domain fremder Leute zu präsentieren. Und nein, die Telekom macht das ganz sicher nicht. Das habe ich bereits selbst im ICE sitzend getestet. DNS läuft da zwar über einen transparenten Resolver, wird aber auch im unangemeldeten Zustand sauber aufgelöst.

Aber ich sehe es sowieso nicht ein mich hier rechtfertigen zu müssen. Ich habe nur hier danach gefragt ob mir jemand bei meinem Problem helfen kann. Wie alles im Endeffekt konfigurationsmäßig im Detail aussieht ist dann wieder eine andere Sache.

Du musst dich nicht rechtfertigen, aber wenn du clever bist, nimmst du technische und juristische Ratschläge ernst, die dir gegeben werden. Es könnte nämlich was dran sein...

Jedoch bin ich mir dessen bewusst, was Strafbar ist und was nicht, da ich selbst als Anwendungsentwickler in der IT-Branche tätig bin.

Öh, und kein Anwalt, oder? Im Zweifel fragst du besser einen?

 

[PapaBaer]

Ach so, das war auch noch:

Zu mal wie oben beschrieben wird der Prerouting eintrag nach dem login entfernt, womit im Endeffekt keine Daten über einen Zeitraum von 1 Woche ausgeliefert werden würden.

Es ist irrelevant, wie lange die Daten ausgeliefert werden. Wenn der Client die Daten in irgend einen Cache wirft, reicht eine einmalige Auslieferung. Ich kenne lokale DNS-Resolver, die nach eigenem Gutdünken DNS-Abfragen cachen und sich überhaupt nicht für irgend eine TTL interessieren. Browser neigen auch dazu, DNS und Content im Cache zu halten. Und schwups, schon rennt der Client tagelang durch die Gegend und wundert sich, warum er spiegel.de nicht aufrufen kann.

Nochmal ganz klar: DNS ist aus den verschiedensten Gründen der vollkommen falsche Ansatz. Nimm NAT an der Firewall, da ist die richtige Stelle zum ansetzen.

 

[N3X]

Ich nutze unter anderem nat regeln, die prerouting regeln die ich konfiguriert habe beziehen sich auch auf NAT.

Ich leite unter anderem jeglichen http Traffic via die prerouting regeln (-t NAT prerouting) an mein Portal weiter. Allerdings habe ich bemerkt, dass beispielsweise der Internet explorer, wenn die im Client konfigurierten dns Server nicht erreichbar sind, das Portal gar nicht erreichen kann.
Daher kam ich auf die Idee mir einen dns aufzusetzen den ich temporär dazu nutze für die Umleitung auf mein Portal.
Bevor sie jeweiligen Clients nicht authentifiziert sind lasse ich auch dns nicht ins Internet durch. Einfach aus dem Grund der Möglichkeit von "Tcp Over dns".
Die prerouting Regel für http zieht bei mir gut nur eben nicht mit Domain Namen die im Browser aufgerufen werden.

Zu Beginn wollte ich nämlich keinen dns Server dafür nutzen, allein weil ich nicht zwangsläufig noch eine weitere Anwendung die ihre Ressourcen benötigt auf der Kiste brauche.

Sobald ich Zuhause von der Arbeit bin, poste ich euch mal die Details, iptables regeln und etc.

root@openvpn:/etc# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  10.5.0.2             anywhere             tcp dpt:http to:10.6.0.1:80

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.10.0.0/24         anywhere
MASQUERADE  all  --  10.5.0.0/24          anywhere

 

[PapaBaer]

Was du schreibst ist korrekt. Ich persönlich lasse dns Tunnel immer durch, einfach weil die Idee dahinter ip in dns zu kapseln so drollig ist und das Bonuspunkte verdient. Obendrein sind Leute, die einen dns Tunnel an den Start bekommen auch fähig mac Adressen zu spoofen und dann halt damit am Portal vorbei zu gehen.

Zur Lösung. Wenn du dns Tunnel unterbinden willst, dann setz einfach rate limits auf dns requests pro zeit. dns Tunnel brauchen so unglaublich auffällig viel dns requests auf eine einzige Domain. Es ist überhaupt kein Problem das mit rate limits abzudrehen.

 

[N3X]

Auf die idee die DNS-Requests zu limitieren bin ich bislang noch nicht gekommen.
Dann kann ich mir also doch den DNS-Server sparen.

Danke für den Lösungsvorschlag.
Werde ich dann wie von dir @PapaBaer beschrieben umsetzen.