Hallo zusammen,
ich habe letzte Woche 2 Programme zur Remote-Verbindung kennengelernt (ntrsupport und logmein) als Ersatz für Microsoft Remote Connection, vnc etc. Für die Verbindung braucht man keine Ports freizugeben und im Firewall muss nichts eingestellt werden. Ich finde dies sehr gut und praktisch (abgesehen von der Sicherheit).
Nun interessiert mich die Frage, wie die Remote-Verbindung ohne Portfreigabe zustande kommt. Die Pakete müssen doch durch den Firewall und durch die Ports erfolgt ja normalerweise die Zuweisung der Pakete zur entsprechenden Anwendung. Wie kommst es also dazu, dass ich ohne Portfreigabe und Firewallkonfiguration den Bildschirm des entfernten Rechners einfach im Browser sehen kann?
viele Grüße
Hitaf
Hallo Hitaf,
das geht normalerweise aehnlich wie bei Skype: die Firewall wird ausgetrickst.
Einfach dargestellt: Dazu braucht man irgendwo einen Server, bei der die Clienten anfragen, ob eine neue Verbindung aufgebaut werden soll. Wenn ja, dann vermittelt der Server zwischen den beiden Clienten und diese kommunizieren dann untereinander.
Siehe dazu z.B. auch http://www.heise.de/security/Wie-Skype-Co-Firewalls-…
Gruesse
Stefan
Hallo zusammen,
Man nutzt halt einfach http-tunnel http://de.wikipedia.org/wiki/Tunnel_(Netzwerktechnik)
das heist es wird auf normaler browser communication gearbeitet.
Ob das sicher ist … gute frage … 
http://de.wikipedia.org/wiki/Tunnel\_(Netzwerktechnik)
Hallo Stefan,
vielen Dank. Die Sache ist mir jetzt klar geworden. Der entscheidende Punkt ist, dass die Clients mit dem Server permanent in Verbindung stehen, die sie --selber-- aufbauen. Auf der Webseite, die du empfohlen hast, ist das Skype-Beispiel mit UDP beschrieben. Mit diesem Protokoll kann man ja einfach ein Loch in Firewall bohren. Mit TCP sollte es dann doch bisschen anders laufen oder? Nach dem das Syn-Segment zum Verbindungsaufbau geschickt wird, ist die Verbindung ja noch nicht aufgebaut und somit kein Loch in Firewall gebohrt (Erwartet wird ja nach syn auf syn/ack vom Ziel, was ja nie ankommen wird, da dies vom Firewall des entfernten Rechners verworfen wird.) Wie läuft das dann mit TCP ab?
entfernten Rechners verworfen wird.) Wie läuft das dann mit
TCP ab?
immer noch über http-tunnel …
Hallo,
die Frage wurde dir ja schon beantwortet.
Mir bleibt noch loszuwerden, dass das eine der Ekligkeiten der von NAT. Wenn man Kontrolle des Datenstroms machen will, sollte man das mit der Firewall machen, nicht mit NAT. Das aktuelle System begünstigt viele eklige Workarounds, die IPv6 hoffentlich wieder überflüssig machen wird.
Grüße,
Moritz
Hallo RakonDark,
entfernten Rechners verworfen wird.) Wie läuft das dann mit
TCP ab?
immer noch über http-tunnel …
Danke für die Antwort. Über einen Tunnel lässt sich theoretisch alles transportieren, solange der Standard des Tunneling-Protokolls nicht verletzt wird, das ist mir auch klar geworden. Was mir jedoch noch nicht klar ist, ist die Kommunikation zwischen zwei Parteien, die beide hinter Firewall sitzen, ohne Tunneling. Skype-Kommunikation ist ja ein Beipiel dafür. Hier trickst man den Firewall einfach aus, das ja in udp kein Verbindungsaufbau gibt. Damit kann man bei eigenem Firewall einfach ein Loch bohren, in dem man zum Zielrechner ein Paket schickt. Bei TCP hat man jedoch 3-Way-Handschake, deshalb lässt sich da am eigenen Firewall nicht einfach ein Loch bohren, da nachdem SYN-Segment das passende SYN/ACK vom Zielrechner nicht ankommen wird (vom Firewall des Zielrechners wird es ja verworfen). Oder ist die Kommunikation zwischen zwei Partnern mit TCP ohne Tunneling nicht möglich?
Zurück zu deiner Antwort: D.h. In ntrsupport oder logmein wird http-tunnel oder so ähnliches benutzt. Dann ist das Protokoll zur eigentlichen Remotesteurung in http eingebettet, verstehe ich das richtig?
viele Grüße
Hitaf
Zu Skype…
Warum blockieren manche Firewalls Skype?
Einige Firewalls erkennen Skype u. U. noch nicht und blockieren fälschlicherweise den Zugriff von Skype auf Ihr System – die Skype-Fehlermeldung Nr. 1102 wird eingeblendet. Skype sollte mit jeder Firewall funktionieren. Wenn Sie beim Herstellen der Verbindung mit Skype Probleme haben, beziehen Sie sich auf die Firewall-Anleitungen auf dieser Seite.
http://www.skype.com/intl/de/help/guides/firewalls/
Es gibt also Firewalls die den Trick schon kennen
Firewall des Zielrechners wird es ja verworfen). Oder ist die
Kommunikation zwischen zwei Partnern mit TCP ohne Tunneling
nicht möglich?
Wenn die Firewall nicht gut konfiguriert ist
TCP ist ja nur das Transportwesen. Wer eine lücke im TCP findet kann auch dort versuchen verbindungen aufzubauen.
Diverses dazu gibts bei iptables und die module für DOS attacken etc.
Wenn du dir das TCP protokoll mit header mal anschauen willst
http://iptables-tutorial.frozentux.net/iptables-tuto…
Zurück zu deiner Antwort: D.h. In ntrsupport oder logmein wird
http-tunnel oder so ähnliches benutzt. Dann ist das Protokoll
zur eigentlichen Remotesteurung in http eingebettet, verstehe
ich das richtig?
Ja . Das Eigentliche Protokoll wird einfach übersetzt (z.b. als dateistream getarnt) in eine http verpackung.
Sprich auf beiden seiten ist ein codierer und dechiffrierer.
der eben über HttP kommuniziert.
Dabei kann die Firewall bei gut gemachten http packeten keinen unterschied feststellen.
Ich brauch also garkeine FireWall Fehler ausnutzen.
viele Grüße
Hitaf
Ja . Das Eigentliche Protokoll wird einfach übersetzt (z.b.
als dateistream getarnt) in eine http verpackung.
Sprich auf beiden seiten ist ein codierer und dechiffrierer.
der eben über HttP kommuniziert.
Nun die http-Daten, die das eigentliche Remoteverbindung-Protokoll beinhalten, haben ja ein Ziel-port. Dieser Ziel-port muss dann entsprechend am Ziel freigeschaltet sein. Das ist ja die Idee von Tunneling. Da ich die Port des Remoteverbindung-Protokolls nicht freischalten will oder dies umgehen möchte, bette ich es in http ein und tunnele es. Woher wissen dann Anwendungen wie z.b. ntrsupport bzw. logmein, ob das http ziel-port am Ziel freigeschaltet ist oder nicht? Ist dieses Ziel-Port standardmäßig auf jedem Client offen?
Huhu,
Da wir davon ausgehen können das Internet verbindungen über HTTP immer zugelassen werden , können wir auch diesen benutzen.
Nun ist es egal welchen Port man nutzt.
Standart Verbindung ist z.b.
Höhe Ports stellen anfragen an tiefere ports.
Z.B. Client-Server http webservice
verabredet wurde port 80 als eingang und höhere ports (grösser 1024) als ausgang.
So fragt der Client von z.b. Port 24000 nach Port 80
Beim Server ist also Port 80 frei für annahme von Kommunikation
Das muss aber nicht so sein.
Die Ports sind nur eine Verabredung.
Ich könnte auch nen Server auf Port 12000 laufen lassen
Dann muss ich aber bei HTTP immer domain.de:12000 schreiben, weil der standartport 80 nicht genommen wurde. Dein Browser packt also automatisch die 80 hin.
Da ich also weiss die Kommunikation per Browser ist für Anfragen auf 80 zuständig , schreib ich mir nen Programm was ein PROTKOLL in HTTP wandelt und schick das wie ein server per HTTP die kommunikation ist also offen. Und wenn ich einmal die Verbindung aufgebaut habe, dann kann ich tun was ich will solange es HTTP bleibt
Nun ist die Frage , wenn ich aber nur reinkommende kommunikation auf port 80 erlaube, wie schafft es client und server sich zu verbinden.
Der Client sendet halt zuerst weil die Anfrage ist ja erlaubt.
Nun, das war nur ein Beispiel (was mir gerade einfiel)
Es kann durchaus auch sein das die gesamte Kommunikation ueber deren Server als Mittelsmann geschieht.
Ich glaube bei ICQ benutzt man dies z.B. als Fallback, wenn beide Nutzer hinter einer Firewall ‚stehen‘. Das erzeugt zwar ‚etwas‘ Traffic, ist aber ziemlich Stressfrei. (gerade fuer DAU’s die keine Firewall konfigurieren koennen)
Sprich es laeuft so ab: Nutzer A moechte eine Datei an Nutzer B senden.
Der Client schaut, ob A eine direkte Verbindung zu B aufbauen kann. Wenn nicht, wird ueber den Server dem Clienten von B gesagt, das er versuchen soll eine Verbindugn zu A auf zu bauen. Wenn das nicht funktioniert bauen beide eine Verbindung zum Server auf und transferieren die Daten ueber diesen.
Man nutzt halt einfach http-tunnel
http://de.wikipedia.org/wiki/Tunnel_(Netzwerktechnik)
Nun, tunneling nutzt nichts, wenn 2 Clients direkt miteinander kommunizieren wollen, aber beide Clients sich hinter einer Firewall befinden, welche die eingehenden Verbindungen blockt. Es muesste also mind. einer von beiden seine Firewall konfigurieren.
Stimmt, womit wir zu einem „Man in the middle“ kommen.
Meist ein Server Dienst.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]