
111064
25.11.2013
Verständnisfrage Hotel Wlan und Ports
Hallo zusammen,
ich habe nur ein kleine Verständnisfrage. Wenn ich auf dem Rechner folgende Ports über die Windows Firewall sperre (21,22,80,443), und nur den benötigten Port für die VPN Verbindung freigeben (Hintergrund: Internetsperre ohne VPN). Können da Probleme bezüglich der Wlan Verbindung im Hotel auftreten, sodass sich der User in Prinzip nicht am Wlan Hotel anmelden kann?
Viele Grüße
ChungUI
ich habe nur ein kleine Verständnisfrage. Wenn ich auf dem Rechner folgende Ports über die Windows Firewall sperre (21,22,80,443), und nur den benötigten Port für die VPN Verbindung freigeben (Hintergrund: Internetsperre ohne VPN). Können da Probleme bezüglich der Wlan Verbindung im Hotel auftreten, sodass sich der User in Prinzip nicht am Wlan Hotel anmelden kann?
Viele Grüße
ChungUI
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 222890
Url: https://administrator.de/forum/verstaendnisfrage-hotel-wlan-und-ports-222890.html
Ausgedruckt am: 23.04.2025 um 07:04 Uhr
25 Kommentare
Neuester Kommentar
Das kommt ganz darauf an in welche Richtung (inbound oder outbound) du diese Ports sperrst. Leider teilst du uns das ja nicht mit und zwingst uns so zum Raten 
Nur soviel: Inbound bekommst du sicher keine Probleme. Outbound sicher eine Menge denn 80 und 443 bedeutet das der User keinerlei Webtraffic mehr machen kann, 22 killt alle SSH Verbindungen.
21 allein ist Blödsinn denn da fehlt noch TCP22 sorry, Fehler korrekt ist natürlich TCP 20 !! denn FTP besteht immer aus diesen beiden Ports ! Bedeutet letztlich aber das dann FTP auch nicht geht…wie gesagt nur outbound !
Nur soviel: Inbound bekommst du sicher keine Probleme. Outbound sicher eine Menge denn 80 und 443 bedeutet das der User keinerlei Webtraffic mehr machen kann, 22 killt alle SSH Verbindungen.
21 allein ist Blödsinn denn da fehlt noch TCP
Da machst du einen Denkfehler, vermutlich aus technischer Unkenntniss ?!
Mit dem WLAN kann er sich sehr wohl verbinden und er bekommt auch eine IP Adresse aus dem WLAN, da du DHCP ja nicht geblockt hast. Da ist also alles gut...
Es besteht also eine WLAN Verbindung aber dann ist die Frage WIE das Hotel WLAN funktioniert bzw. WIE die Authentisierung funktioniert.
Ist das eine unsichere Dödeleinrichtung ohne jegliche Authentisierung wie bei Piepenbrinks opn Dörphotel die sofort Internet zur Verfügung stellt geht deine Rechnung auf. Er kann dann kein Webtraffic machen, kein FTP und kein SSH, wohl aber funktionieren Email z.B. und auch dein VPN !
Hat das Hotel WLAN allerdings wie durchweg üblich ein sog. "Captive Portal" also eine Zwangswebseite mit dem man sich mit einem Einmalpasswort (Voucher) von der Rezeption authentisieren muss wie z.B. hier beschrieben, dann hat dein User Pech, denn du killst ihm ja den Webtraffic. Folglich kann er sich nicht authentisieren im Hotel WLAN.
Er hat dann keine (nromale) Möglichkeit sich im Hotel WLAN zu authentisieren, bekommt keinen Internet Zugang und aus ists…. Freaks können auch das überwinden aber dein User ist sicher nicht so einer, denn das erfordert etwas Frickelei und Rechnerkenntnis.
Kommt man aber auch von selber drauf wenn man mal ein klein wenig nachdenkt wie die Pakete sich so bewegen in einem LAN oder WLAN.
Mit dem WLAN kann er sich sehr wohl verbinden und er bekommt auch eine IP Adresse aus dem WLAN, da du DHCP ja nicht geblockt hast. Da ist also alles gut...
Es besteht also eine WLAN Verbindung aber dann ist die Frage WIE das Hotel WLAN funktioniert bzw. WIE die Authentisierung funktioniert.
Ist das eine unsichere Dödeleinrichtung ohne jegliche Authentisierung wie bei Piepenbrinks opn Dörphotel die sofort Internet zur Verfügung stellt geht deine Rechnung auf. Er kann dann kein Webtraffic machen, kein FTP und kein SSH, wohl aber funktionieren Email z.B. und auch dein VPN !
Hat das Hotel WLAN allerdings wie durchweg üblich ein sog. "Captive Portal" also eine Zwangswebseite mit dem man sich mit einem Einmalpasswort (Voucher) von der Rezeption authentisieren muss wie z.B. hier beschrieben, dann hat dein User Pech, denn du killst ihm ja den Webtraffic. Folglich kann er sich nicht authentisieren im Hotel WLAN.
Er hat dann keine (nromale) Möglichkeit sich im Hotel WLAN zu authentisieren, bekommt keinen Internet Zugang und aus ists…. Freaks können auch das überwinden aber dein User ist sicher nicht so einer, denn das erfordert etwas Frickelei und Rechnerkenntnis.
Kommt man aber auch von selber drauf wenn man mal ein klein wenig nachdenkt wie die Pakete sich so bewegen in einem LAN oder WLAN.
@Alchimedes
Nein, das ist schlicht falsch was du behauptest. Du verwechselst hier grundsätzlich was, vermutlich nämlich passive FTP und active.
Erstmal also bitte die Protokoll Grundlagen von FTP lesen, dann lernst du das FTP immer beide Ports zwingend benötigt:
http://de.wikipedia.org/wiki/File_Transfer_Protocol
TCP 20 ist der Datenport und TCP 21 der Controlport. FTP Daten werden niemals über den Controlport 21 gesendet !
Warum man scheinbar nur einen Port nötig hat, beschreibt der Mechnismus von Passive FTP was den Sessionaufbau des Datenports einfach "umdreht" um der NAT (Adress Translation) Problematik zu entgehen:
http://www.alenfelder.com/Informatik/pass-akt-ftp.html
bzw. hier mit Diagramm und Details...
http://slacksite.com/other/ftp.html
Hättest du dir nur mal die geringe Mühe gemacht und mal einen FTP Sessionaufbau (active und passive) an deinem Rechner mit dem Wireshark mitgesniffert, wäre diese Threadantwort obsolet gewesen.
Also lesen und verstehen bevor man solche Halbwahrheiten in einem Forum verbreitet !!
Zurück zum eigentlichen Thema….
Nein, das ist schlicht falsch was du behauptest. Du verwechselst hier grundsätzlich was, vermutlich nämlich passive FTP und active.
Erstmal also bitte die Protokoll Grundlagen von FTP lesen, dann lernst du das FTP immer beide Ports zwingend benötigt:
http://de.wikipedia.org/wiki/File_Transfer_Protocol
TCP 20 ist der Datenport und TCP 21 der Controlport. FTP Daten werden niemals über den Controlport 21 gesendet !
Warum man scheinbar nur einen Port nötig hat, beschreibt der Mechnismus von Passive FTP was den Sessionaufbau des Datenports einfach "umdreht" um der NAT (Adress Translation) Problematik zu entgehen:
http://www.alenfelder.com/Informatik/pass-akt-ftp.html
bzw. hier mit Diagramm und Details...
http://slacksite.com/other/ftp.html
Hättest du dir nur mal die geringe Mühe gemacht und mal einen FTP Sessionaufbau (active und passive) an deinem Rechner mit dem Wireshark mitgesniffert, wäre diese Threadantwort obsolet gewesen.
Also lesen und verstehen bevor man solche Halbwahrheiten in einem Forum verbreitet !!
Zurück zum eigentlichen Thema….
@Alchimedes
Nein, sorry die Halbwahrheit hast du verbreitet:
"Nackig FTP luebbt ueber die 21 und nicht ueber die 22 !" das ist technischer Unsinn wie du aus den oben zitierten Links ja klar lernen kannst ! Fakt ist: FTP braucht immer 2 Ports !
Nein, sorry die Halbwahrheit hast du verbreitet:
"Nackig FTP luebbt ueber die 21 und nicht ueber die 22 !" das ist technischer Unsinn wie du aus den oben zitierten Links ja klar lernen kannst ! Fakt ist: FTP braucht immer 2 Ports !
@aqui
Jo , das ist fakt, aber nicht Port 22.... kann man zwar umbiegen auf die 22 aber klug ist das nicht.
Ging mir auch nicht darum Dein wissen in Frage zustellen sondern nur ein Hinweis das es eben Port 20 und 21 ist !
Wie aus Deinen Links klar hervorgeht.
Gruss
Jo , das ist fakt, aber nicht Port 22.... kann man zwar umbiegen auf die 22 aber klug ist das nicht.
Ging mir auch nicht darum Dein wissen in Frage zustellen sondern nur ein Hinweis das es eben Port 20 und 21 ist !
Wie aus Deinen Links klar hervorgeht.
Gruss
Hotel WLANs haben meist Web-Authentisierung d.h. ausgehend http / https zu blocken ist da etwas sinnfrei falls das in dem Hotel auch so ist wo du schläfst.
VPN Protokolle verwenden auch je nach Protokoll und Hersteller unterschiedliche Ports, manche auch Kombinationen.
IPSEC-VPN
IKE (UDP500)
IPSEC (ESP Protokoll oder UDP4500 bei NAT-T)
oder TCP10.000
SSL-VPN
TCP443
Juniper SSL VPN
TCP443 (ersetzt IKE Phase 1)
UDP4500 (ESP wird in UDP gekapselt)
TCP 22 ist SSH oder SFTP (verschlüsseltes telnet oder ftp quasi)
FTP braucht 20 und 21, oft reich tauch 20.
Warum der Kollege das blockt weiss ich allerdings nicht so recht.
Ausserdem nützt eine lokale Firewall wenig wenn man in nem öffentlichen LAN hockt wo ggfs. einer ARP-Poisoning macht und deinen Traffic auf sich umleitet durch Arp-Cache Manipulationen (Cain).
Soll nur heissen- eine Clientfirewall schützt nicht vor allem. In öffenlich zugänglichen Netzten ist das die Hauptgefahr würd ich mal sagen. Die Tools sind einfach zu bedienen und effektiv. Amen.
VPN Protokolle verwenden auch je nach Protokoll und Hersteller unterschiedliche Ports, manche auch Kombinationen.
IPSEC-VPN
IKE (UDP500)
IPSEC (ESP Protokoll oder UDP4500 bei NAT-T)
oder TCP10.000
SSL-VPN
TCP443
Juniper SSL VPN
TCP443 (ersetzt IKE Phase 1)
UDP4500 (ESP wird in UDP gekapselt)
TCP 22 ist SSH oder SFTP (verschlüsseltes telnet oder ftp quasi)
FTP braucht 20 und 21, oft reich tauch 20.
Warum der Kollege das blockt weiss ich allerdings nicht so recht.
Ausserdem nützt eine lokale Firewall wenig wenn man in nem öffentlichen LAN hockt wo ggfs. einer ARP-Poisoning macht und deinen Traffic auf sich umleitet durch Arp-Cache Manipulationen (Cain).
Soll nur heissen- eine Clientfirewall schützt nicht vor allem. In öffenlich zugänglichen Netzten ist das die Hauptgefahr würd ich mal sagen. Die Tools sind einfach zu bedienen und effektiv. Amen.
@alchimdes
Sorry, willst oder kannst du es nicht verstehen ??
Bitte lies dir die oben zitierten URL genau durch dann weisst du warum FTP (und nicht sFTP oder SCP, SSH) immer 2 Ports benötigt nämlich den Control UND den Daten Port. FTP rennt niemals nur mit einem Port und auch Port Translation lässt FTP aus genau diesem Grund nicht zu !
Es sieht oft aus als ob nur ein Port reicht, das ist dann aber passive FTP was den Sessionaufbau des Datenports nur umdreht um NAT Problemen aus dem Wege zu gehen wie oben bereits angemerkt. 2 Ports werden trotzdem immer benutzt.
Zum Thema TCP 22 hat Kollege spacyfreak ja schon alles gesagt. Ganz andere Baustelle, da ganz anderes Protokoll.
Zurück zum Thema….
Sorry, willst oder kannst du es nicht verstehen ??
Bitte lies dir die oben zitierten URL genau durch dann weisst du warum FTP (und nicht sFTP oder SCP, SSH) immer 2 Ports benötigt nämlich den Control UND den Daten Port. FTP rennt niemals nur mit einem Port und auch Port Translation lässt FTP aus genau diesem Grund nicht zu !
Es sieht oft aus als ob nur ein Port reicht, das ist dann aber passive FTP was den Sessionaufbau des Datenports nur umdreht um NAT Problemen aus dem Wege zu gehen wie oben bereits angemerkt. 2 Ports werden trotzdem immer benutzt.
Zum Thema TCP 22 hat Kollege spacyfreak ja schon alles gesagt. Ganz andere Baustelle, da ganz anderes Protokoll.
Zurück zum Thema….
@aqui
ftp braucht 2 Ports naehmlich 20 und 21 NICHT 22 !! wenn Du mal RFC 959 durchgelesen haettest, wenn Du mal die Posts durchgelesen haettest,
wuerdest Du mal von Deinem Ross runtersteigen und schnallen das in Deinem Post =
der Fehler steckt !
Aber Deine Arroganz ist schon bemerkenswert.....
Gruss
ftp braucht 2 Ports naehmlich 20 und 21 NICHT 22 !! wenn Du mal RFC 959 durchgelesen haettest, wenn Du mal die Posts durchgelesen haettest,
wuerdest Du mal von Deinem Ross runtersteigen und schnallen das in Deinem Post =
21 allein ist Blödsinn denn da fehlt noch TCP 22
der Fehler steckt !
Aber Deine Arroganz ist schon bemerkenswert.....
Gruss
Auf so einem Ross sitz ich gar nicht, ist eher ein Zwergpony
...OK aber dann haben wir immer aneinander vorbeigeredet und meinen das gleiche...sorry. Klar TCP 22 ist immer SSH oder SCP und hat mit FTP nix zu tun. Das ist dann oben ein Typo im Eifer des Gefechts gewesen oben und korrigiert...sorry nochmal !
FTP ist TCP 20 und 21 wobei man dem Controlport auch einen andernePort geben kann aber nicht dem Dataport.
FTP ist TCP 20 und 21 wobei man dem Controlport auch einen andernePort geben kann aber nicht dem Dataport.
Es gibt schlicht und einfach auch keine Lösung für dein Vorhaben. Genau deshalb bekommst du hier auch kein Feedback.
Wegen der Vielschichtigkeit der Hotspot Lösungen und Access Authorisierungen lässt sich das nicht so mit Bordmitteln lösen wie du es vorhast !
Eine Kröte für offene Ports musst du zwangsweise schlucken. Port 443 allein ist natürlich völliger Unsinn, da 98% alle Hotspot Lösungen eine Portal Authentisierung über TCP 80 Traffic machen um damit die Portalseite zu triggern. Die selber rennt dann auf unterschiedlichen Ports.
Dein Unterfangen alles zu blockieren blockiert damit die Gesamtfunktion.
Wegen der Vielschichtigkeit der Hotspot Lösungen und Access Authorisierungen lässt sich das nicht so mit Bordmitteln lösen wie du es vorhast !
Eine Kröte für offene Ports musst du zwangsweise schlucken. Port 443 allein ist natürlich völliger Unsinn, da 98% alle Hotspot Lösungen eine Portal Authentisierung über TCP 80 Traffic machen um damit die Portalseite zu triggern. Die selber rennt dann auf unterschiedlichen Ports.
Dein Unterfangen alles zu blockieren blockiert damit die Gesamtfunktion.
Das wäre eine denkbare Alternative, das du 5-10 Minuten vollen Zugang erlaubst und dann alles dichtmachst bis auf den VPN Port.
Ob das aber sinnvoll mit MS Bordmitteln umzusetzen ist die der User dann auch nicht aushebeln kann ist fraglich und müsste einer der Batch und Shell oder GPO Gurus hier klären.
Ob das aber sinnvoll mit MS Bordmitteln umzusetzen ist die der User dann auch nicht aushebeln kann ist fraglich und müsste einer der Batch und Shell oder GPO Gurus hier klären.
Also ist das Vorhaben -
Firmennotebook soll nicht direkt ins Internet kommen, sondern nur VPN in die Firma machen dürfen (und ggfs. über den Firmen-Proxy ins Internet).
Wenn man auf dem Windows Rechner die http usw Ports dichtmacht und nur VPN öffnet dann geht auch via VPN kein http, dh der Anwender erreicht in der Firma auch kein Sharepoint oder Intranet Webseiten usw
Man könnte via GPO den Firmenproxy fest eintragen, und nur wenn der Anwender VPN macht in die Firma kommt er auch ins Internet via Firmenproxy.
Damit weden aber Hotel Webauths Probleme haben wenn der Client nen Proxy drin hat.
Bleibt meines Erachtens die Möglichkeit die meistens funktioniert (vorausgesetzt man hat Empfang..) - der Anwender nutzt nur UMTS/LTE und keine Hotel-WLAN Hotspots (die zumal das Endgerät grösseren Risiken aussetzen da sich da gerne mal gelangweilte Hobbyhacker tummeln und Cain&Abel anschmeissen... und dagegen hilft auch keine Clientfirewall da diese Angriffe tiefer stattfinden als die FW greifen kann - meines Wissens...
)
Firmennotebook soll nicht direkt ins Internet kommen, sondern nur VPN in die Firma machen dürfen (und ggfs. über den Firmen-Proxy ins Internet).
Wenn man auf dem Windows Rechner die http usw Ports dichtmacht und nur VPN öffnet dann geht auch via VPN kein http, dh der Anwender erreicht in der Firma auch kein Sharepoint oder Intranet Webseiten usw
Man könnte via GPO den Firmenproxy fest eintragen, und nur wenn der Anwender VPN macht in die Firma kommt er auch ins Internet via Firmenproxy.
Damit weden aber Hotel Webauths Probleme haben wenn der Client nen Proxy drin hat.
Bleibt meines Erachtens die Möglichkeit die meistens funktioniert (vorausgesetzt man hat Empfang..) - der Anwender nutzt nur UMTS/LTE und keine Hotel-WLAN Hotspots (die zumal das Endgerät grösseren Risiken aussetzen da sich da gerne mal gelangweilte Hobbyhacker tummeln und Cain&Abel anschmeissen... und dagegen hilft auch keine Clientfirewall da diese Angriffe tiefer stattfinden als die FW greifen kann - meines Wissens...
)
Weiss garnicht obs überhaupt jemand gibt der das hinkriegen würde. hehe.
Wer macht denn sowas?
Bei mobilen Notebooks kann man eben nicht alles umsetzen was man sich sicherheitstechnisch so zusammendenkt.
Man erreicht damit höchstens dass der Anwender kaum arbeiten kann und dann in der Not mehr geöffnet wird als offen sein müsste, wenn man die Verhältnismässigkeit von Anfang an im Auge behalten hätte.
Wenn die irgendwo sind mit ihren Notebooks dann müssen die meist halt je nach gegebenheiten vor Ort direkt auf port tcp80 / 443 kommunizieren können, grade in Gast-WLANs.
Diese Lösung mit zeitgesteuerter FW ist nicht der Hit. Was ist wenn der Anwender sein Notebook startet und dann erstmal aufs Klo geht, und länger als 5 Minuten braucht?
Alternative Lösung - der anwender ist mit dem Notebook relativ "frei" was Security angeht.
Mit dem Ding macht er eigentl. nix anderes als sich mit dem Firmennetz zu verbinden, wo sein DesktopPC steht auf den er sich per RDP verbindet.
Das ganze noch mit Clientzertifikaten und/oder 2-Faktor Autentisierung absichern und der Drops ist gelutscht. So mach ich das jedenfalls.
Wer macht denn sowas?
Bei mobilen Notebooks kann man eben nicht alles umsetzen was man sich sicherheitstechnisch so zusammendenkt.
Man erreicht damit höchstens dass der Anwender kaum arbeiten kann und dann in der Not mehr geöffnet wird als offen sein müsste, wenn man die Verhältnismässigkeit von Anfang an im Auge behalten hätte.
Wenn die irgendwo sind mit ihren Notebooks dann müssen die meist halt je nach gegebenheiten vor Ort direkt auf port tcp80 / 443 kommunizieren können, grade in Gast-WLANs.
Diese Lösung mit zeitgesteuerter FW ist nicht der Hit. Was ist wenn der Anwender sein Notebook startet und dann erstmal aufs Klo geht, und länger als 5 Minuten braucht?
Alternative Lösung - der anwender ist mit dem Notebook relativ "frei" was Security angeht.
Mit dem Ding macht er eigentl. nix anderes als sich mit dem Firmennetz zu verbinden, wo sein DesktopPC steht auf den er sich per RDP verbindet.
Das ganze noch mit Clientzertifikaten und/oder 2-Faktor Autentisierung absichern und der Drops ist gelutscht. So mach ich das jedenfalls.
Wenns das denn nun war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !