DNS-Tunneling: Die pure Theorie bei Hotspots

3

3X!_d0S

0
Hi Leute,

in vielen Lebenslagen ist das DNS-Tunneln ja recht brauchbar. Zum Beispiel um bei einem Hotspot die "Bezahlseite" oder Providerpage zu umgehen und trozdem surfen zu können.

Ich verstehe das Prinzip momentan noch nicht. Für mich sieht ein normaler DNS-Resolv ja so aus:

Rechner[A] will auf hackerboard.de Rechner surfen.
  • Rechner [A] schaut in der Host-Datei nach, findet keinen Verweis und fragt bei einem Nameserver[1] nach
  • Der Nameserver[1] kennt die IP nicht und gibt dies autotaritiv weiter an einen weiteren Nameserver[2]
  • Der Nameserver[2] kennt dies ebenfalls nicht und fragt bei einem Root-DNS-Nameserver inversiv nach
  • Root-Nameserver gibt Antwort an Nameserver[2] und der zu Nameserver [1]
  • Nameserver[1] gibt die Antwort an Rechner [A]
  • Rechner [A] fragt bei xxx.xxx.xxx.xxx an.

So verstehe ich erstmal das System.
Gehe ich nun an einen Hotspot, so nutzt mein Notebook, nach dem Verbinden via offenem W-LAN, deren Nameserver. Dieser Nameserver leitet mich, egal bei welcher Anfrage auch immer, auf die "Bezahlseite" weiter.

Ich habe nun die Möglichkeit via SSH zu tunneln. Dort entsteht meine ersten Fragen:
  • Wovon ist ein SSH-Tunnel abhängig?
  • Ist das oben beschriebene richtig?
  • Kann ich davon ausgehen, dass die gängisten Ports geöffnet sind,weshalb SSH funktioniert?
  • Kann ich davon ausgehen, dass der Hotspot mich bei einer IP-Anfrage direkt z.B. auf google.de zugreifen lässt, solange ich nur nicht den DNS nutze?
  • Wie kann die Tunnelung des DNS durch SSH getrackt werden?
Zum DNS-Tunneling benötige ich einen DNS-Server außerhalb des NAT im WLAN des Hotspots. Reicht dafür auch ein Service von DynDNS?

Wäre bei den Hotspots auch ein VPN-Tunnel denkbar?

ThX in advance,

3X!_d0S
 
So verstehe ich erstmal das System.
Zum Vergrößern anklicken....
Denke ich auch so. Bei DNS-Tunneling wird als Antwort allerdings Rechner B geliefert, bzw. Rechner B liefert die "IP-Adresse".

Wenn du einen SSH-Tunnel erstellen willst, brauchst du einen Server, keinen DynDNS-Dienst, zu dem du dich verbinden willst. Der Traffic wird bis zum Server verschlüsselt, danach allerdings nur bei TLS (SSL)-Nutzung.

Der Standard-SSH-Port ist 22. Du kannst davon ausgehen, dass dieser Port eventuell blockiert ist. Deshalb ist es nützlich, wenn der Server (Rechner B) den Dienst zusätzlich auf Port 80, besser 443 laufen lässt.
Meine Erfahrung zeigt, dass SSH-Traffic über Port 443 üblicherweise nicht geblockt wird. Wer möchte schon Onlinebanking verlieren ;)

Wenn der Hotspot den Nutzer nur per DNS auf seine Bezahlseite zwingt, ja. Üblicherweise wird dies allerdings nicht möglich sein. Die Hintergründe sind mir aber nicht so genau bekannt, als dass ich sie erläutern könnte.

Wenn du mit "Tracking" das Detektieren von DNS-Tunneling am Hotspot gemeint hast, meine ich, dass man höchstens feststellen kann, dass überdurchschnittlich viele DNS-Pakete von einer IP an eine andere IP gesendet werden. Ein einfacher WLAN-Router besitzt diese Funktionalität üblicherweise nicht (halte nach der SSID "t-mobile" Ausschau ;) )

Noch ein Link: dns tunneling made simple
und noch einer: daemon.be
Schau dir den letzten Link an.

Hmm, was meinst du damit genau? Ich vermute, du meinst ob allein ein DynDNS-Name zum Tunneln ausreicht: Nein.

Prinzipiell ja, wobei ich persönlich SSH einfacher zum Einrichten finde.
 
Ähm euch ist schon bewusst das euch das ganze nichts bringt solange ihr nicht direkt auf die IP Adresse zugreift?

Wenn das System wirklich solange jeden Zugriff auf das Internet sperrt bzw. auf die
Anmeldeseite umleitet und das nur über die DNS Anfrage gemacht wird. Bringt euch auch
ein Server hinter einer DynDNS Adresse nichts. Da für die DynDNS ja wieder der DNS in
Anspruch genommen wird der euch wieder auf die Anmeldeseite umleitet. Also wenn
dann müsstest du die IP schon direkt wissen vom Ziel System.

Technisch wird das ganze aber wohl anders geregelt werden, z.B. über die MAC
Adresse. Logt man sich also z.B. auf einen T-Online Hotspot ein kommt man zur
Anmeldeseite nach dem man dort nun sich eingeloggt oder dergleichen gemacht hat wird
die MAC Adresse gespeichert und hat dann z.b. die Erlaubnis für 1Std das Internet zu
nutzen vorher ist es gesperrt und nach der Stunde auch wieder.
Zumindest würde ich es so in der Art machen :D
 
aber wie kommt man mit dem ssh client überhaupt an den server von sich ran?
der letzte hotspot wo ich mal hier und da was probiert hab, hatte mich selbst bei eingaben wie http://1.1.1.1:80 auf die bezahlseite geschickt.
das würde ja bedeuten, dass ich dann auch mit dem ssh verbindungsversuch wieder zurückgeschoben werde auf die bezahlseite und dort nur quatsch herbekomme?
oder vesteh ich was falsch.

das einzige was scheinbar von meinen verbindungsversuchen nach ausen gegangen ist sind pinganfragen - und da wurden auch die ips richtig aufgelöst.
nur beim eigentlich verbindungsversuch bin ich nichtmehr weitergekommen.

ssh hatte ich nur auf den standardport probiert, und der war scheinbar geblockt.
 
Ein SSH-Tunnel ist natürlich erst dann einsetzbar, wenn man im Hotspot eingeloggt ist. Wenn Port 22 auch dann geblockt ist, sollte man SSH auf dem Server einfach auf einen Port legen, der nicht geblockt wird.
 
und wie sieht das mit den dns anfragen aus?
wenn die ordentlich aufgelöst werden, ohne dass ich eingeloggt bin, dann könnte man ja ggf. den ssh server auf den dns port legen und versuchen dadrüber rauszukommen?
oder liegt das einfach daran, dass ein lokaler server mir die antwort auf den dns lookup gegeben hat?

oder alternativ bin ich ja mit imcp (ping) paketen nach draußen gekommen.
besteht da ne chance sowas zu umgehen?
 
Habe mal eine Frage zum Thema:

Gibt es auch einen DNS Server, der direkt auf der FritzBox läuft? (z.B. mir Freetz)
 
Hallo ,

zu der puren Theorie (d.h. auch hier nur mein Verständnis Deiner Frage, meine Thesen können gerne entkräftet werden)

Ein Protokolltunnel ist ein Schema, bei dem in den protokollspezifischen Datenpaketen, andere Datenpakete im Datenteil untergebracht werden.
Dies funktioniert immer dann, wenn der Datenteil eines bestimmten Protokolls, z.B. dns, Felder zulässt, in denen man beliebige Daten (hier Pakete) speichern kann, ohne dass das eigentliche Paket dadurch gegen die Validität der Protokolldefinition verstößt und somit auf seinem Weg durch das Netz irgendwo gedroppt wird.
Die DNS Funktionsweise hast du ja bereits korrekt dargestellt. Es ist erstmal so:

1. Es gibt einen DNSServer und einen DNSClient
2. Der Client schickt einen DNSRequest an den DNSServer.
3. Der DNSServer schickt einen DNSResponse an den Client

Wie nun ein Tunnel ?

Man benötigt Zugriff auf den auflösenden DNSServer, denn für den Tunnel sind zwei Dinge nötig.
Auf clientseite müssen Datenpakete(z.B. tcp für ssh) in den Datenteil der dns request eingepackt werden. Der Server muss sie allerdings wieder auspacken können. Du benötigst also ein System was Deine dns request empfängt, eine andere Möglichkeit kann ich mir beim besten Willen für einen 'Protokolltunnel' nicht vorstellen.

Für das einpacken/Auspacken solcher Daten kann ein tun/tap Adapter denke ich nützlich sein, oder auch auf serverseite möglicherweise gut über eine gewöhnliche Paketsniffer Bibliothek gemacht werden.

Desweiteren sollte eine über upd(dns) getunnelte verbindung sehr inperformant sein, da udp Protokollimmanent nicht für gesicherte Datenübertragungen geeignet ist. Im Übrigen ist ein solcher Tunnel prizipiell genauso über icmp möglich, diese Art von Tunnel könnte man, denke ich, mit einer einfachen dyndns Adresse relativ einfach selbst nachstellen.


[EDIT: sorry hatte nicht gemerkt wie verstaubt das hier schon ist]
 
Zuletzt bearbeitet:
Wie nun ein Tunnel ?

Man benötigt Zugriff auf den auflösenden DNSServer, denn für den Tunnel sind zwei Dinge nötig.
Auf clientseite müssen Datenpakete(z.B. tcp für ssh) in den Datenteil der dns request eingepackt werden. Der Server muss sie allerdings wieder auspacken können. Du benötigst also ein System was Deine dns request empfängt, eine andere Möglichkeit kann ich mir beim besten Willen für einen 'Protokolltunnel' nicht vorstellen.

Für das einpacken/Auspacken solcher Daten kann ein tun/tap Adapter denke ich nützlich sein, oder auch auf serverseite möglicherweise gut über eine gewöhnliche Paketsniffer Bibliothek gemacht werden.

Desweiteren sollte eine über upd(dns) getunnelte verbindung sehr inperformant sein, da udp Protokollimmanent nicht für gesicherte Datenübertragungen geeignet ist. Im Übrigen ist ein solcher Tunnel prizipiell genauso über icmp möglich, diese Art von Tunnel könnte man, denke ich, mit einer einfachen dyndns Adresse relativ einfach selbst nachstellen.
Zum Vergrößern anklicken....


Eben, ein Tunnel! Wenn man davon ausgeht, dasz der Zugang in diesem WLAN spot dadurch kontrolliert wird, dasz man einen DNS server aufgezwungen bekommt, wenn man nicht in irgendeiner FW Table steht:

Lappi -> lokale filterregeln biegen ausgehende DNS requests auf den tunnel um -> am ende des tunnels wird entsprechend verfahren. Entweder laeuft dort lokal ein DNS Server, oder man leitet eben auch das weiter.

Wenn man den Tunnel ueber die IP aufbaut gibt es kein Problem, sofern das o.g. stimmt.
 
@chromatin: wie würdest Du einen hotspot for pay einrichten wenn Du ihn nach belieben programmieren könntest ?

Ich meine nur: solange wir nicht wissen, wie kommerzielle hotspots auf die Payseite verweisen, kann man nur im Trüben fischen, wogegen Sie sich schützen müssen.
 
Kommerzielle Hotspot Systeme, wie zb in Hotels sind ganz Handelsuebliche
Geraete/Software. Dort wirds oft ueber einen Key geregelt, fuer den man eine bestimmte Zeit zahlt.

Wenn ich ihn selber bauen muesste, wuerde ich ebenso mit ablaufenden Keys arbeiten.
 
@Chromatin:

Was fuer ein Key bitte und wo wird der hinterlegt und auf was wird der gamapped ? Wo speichert der client den key und wie / wann uebermittelt er den an den pay server.

Ich wuerde das ganze wohl mit ACLs am gatewat loesen bzw DHCP regeln und nur IPs die vom DHCP vergeben wurden ins Netz lassen.
 
Hi,

ich hab den Thread hier jetzt auch mal gelesen. Ist das bereits in DNS Tunnel??

Code: 
# ssh -p 443 -L 53:127.0.0.1:53 ip_of_my_gateway_at_home
# echo "nameserver 127.0.0.1" > /etc/resolv.conf

Ich gehe also davon aus, dass 443 rausgeht und DNS nicht funktioniert. localhost:53 auf dem client landet also in meinem DNS Dienst zuhause.
Jetzt befrage ich einfach localhost und es geht.

Stimmt so oder?

cu
serow
 
Ich verstehe grade nicht was dir das bringt wenn du mit ssh raus kommst kannst gleich ssh tunneln da brauchts kein DNS tunnel mehr
 
Hmm, stimmt, das ist ja dann ein SSH Tunnel durch den ich DNS mache ... Jetzt bin ich ganz verwirrt ^^

EDIT: http://www.dnstunnel.de/ Hier wirds super erklärt! Sry für den Blödsinn den ich gepostet habe :D

cu
serow
 
Zuletzt bearbeitet:
Ancient hat gesagt.:
@Chromatin:

Was fuer ein Key bitte und wo wird der hinterlegt und auf was wird der gamapped ? Wo speichert der client den key und wie / wann uebermittelt er den an den pay server.
Zum Vergrößern anklicken....
Gute Frage, interessant wäre noch, ob dieser key für die wlan Verschlüsselung genutzt wird ^^. Ansonsten wüsste ich nicht, wie dieser key den client authentisiert.

Ancient hat gesagt.:
Ich wuerde das ganze wohl mit ACLs am gatewat loesen bzw DHCP regeln und nur IPs die vom DHCP vergeben wurden ins Netz lassen.
Zum Vergrößern anklicken....
Ja aber dhcp kann ja prinzipiell jeder haben der fragt und dhcp hat imho kein feature für key exchange. Wie weiter ?

Ich habe so eine payseite in einem cafe mal gesehen, da ist ein webfrontend, wo man einen Schlüssel eingibt, allerdings wüsste ich nicht wie dieser verarbeitet bzw. genutzt bzw. woran er gebunden wird. Dies wäre mit einem handelsüblichen schwer oder ?
allerdings wäre ein solches webdings in Indiz dafür, dass man alle dns requests an eine payseite auflöst, bis irgendein key vorhanden ist, wo auch immer

Serow hat gesagt.:
ich hab den Thread hier jetzt auch mal gelesen. Ist das bereits in DNS Tunnel??
Zum Vergrößern anklicken....

Es kommt natürlich darauf an, was man als Tunnel definiert. Meiner Ansicht nach ist es erst ein Tunnel, wenn man ein Protokoll in einem anderen überträgt. In Deinem ssh Beispiel werden die dns resolvs schon in ssh getunnelt, allerdings, wenn das bei so einem hotspot ginge, könnte man auch direkt seinen heimischen dns server angeben. Es sei natürlich, man blockt port 53 udp auf dem spot und meint, so könne niemand einen anderen dns server nutzen. Letztenendes wieß ich auch garnicht, wie der op auf dns tunneling bei pay hotspots kommt :rolleyes:. Jedenfalls ist imo ein dns tunnel, ein dns request response zyklus, der im additionalrecords Bereich ein anderes protokoll transportiert...aber wie auch immer
 
Zuletzt bearbeitet:
Funktionier eigentlich der Trick auch bei UMTS Prepaid Sticks (N24, ProSieben)? Da gibt es ja auch eine "Startseite" auf die man immer geleitet wird und dort sein Surfpaket auswählen kann.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben