mboost-dp1
Login til internet, offentligt
Sidder i skrivende stund på ringsted sygehus og venter på en kammerat, som er ved at blive rodet i knæet. Jeg har fået oprettet et gæstelogin til deres internet, via ubeskyttet wifi. Jeg skule blive promptet med et login, "når jeg kom på", sagde den flinke dame der oprettede min gæstekonto.
Det sker bare ikke.
Har før prøvet, på et andet åbent netværk på en anden offentlig instans, ikke at blive promptet med login efter jeg hopede på det åbne netværk. Det kunne løses ved at jeg indtastede default gatewayen i adresselinjen i browseren og trykkede enter, så blev jeg bedt om login. Det virker ikke her.
Nogen der har et forslag, til hvordan jeg skal komme på internettet?
Lige nu kører jeg hotspot på telefonen, men dækning er der ikke meget af.
Det sker bare ikke.
Har før prøvet, på et andet åbent netværk på en anden offentlig instans, ikke at blive promptet med login efter jeg hopede på det åbne netværk. Det kunne løses ved at jeg indtastede default gatewayen i adresselinjen i browseren og trykkede enter, så blev jeg bedt om login. Det virker ikke her.
Nogen der har et forslag, til hvordan jeg skal komme på internettet?
Lige nu kører jeg hotspot på telefonen, men dækning er der ikke meget af.
Problemet med den slags logins er at der ikke er nogen rigtig måde at gøre det på. Det har ført til at forskellige udbydere har valgt massevis af forskellige forkerte måder at sætte dem op på.
Et typisk forløb er følgende:
1. Du forbinder til et åbent WIFI access point.
2. Du prøver at åbne en webside.
3. DNS forespørgsel sendes til serveren annonceret over DHCP.
4. Et korrekt DNS svar sendes tilbage til browseren.
5. Browseren forsøger at åbne en HTTP forbindelse.
6. HTTP forbindelsen hijackes og et forfalsket svar med en HTTP redirect sendes tilbage.
7. Browseren fortsætter til den nye URL.
8. Den nye URL peger på en loginside som der er åben adgang til.
9. Efter login redirectes browseren enten til den oprindelige URL eller til udbyderens egen hjemmeside.
Der er en hel del variationer over ovenstående tema, og afhængigt af hvilken variation og hvordan computeren er sat op, kan det gå galt.
For det første er der variationer i hvordan DNS opslag håndteres. Nogle netværk tillader kun at du bruger deres egen DNS server. Andre netværk tillader at du bruger en vilkårlig DNS server. De har simpelthen åben for port 53 uanset hvortil.
En totalt åben DNS port giver mulighed for at man kan udnytte det til trafik uden at være autoriseret til adgang på netværket. Men det kan sagtens være en god idé alligevel. For det første forhindrer det problemet som #2 og #3 nævner. Og dem som absolut vil udnytte netværket kan gøre det alligevel. En åben DNS port betyder bare at dem som vil udnytte det kan gøre det uden at belaste default DNS serveren.
En anden fremgangsmåde der til tider anvendes er at hijacke DNS trafik og sende alle DNS opslag til egen DNS server uanset modtageradresse. Det løser også problemet nævnt i #2 og #3, men det betyder mere hijacking, og hijacking kan være medvirkende årsag til mange tekniske problemer. Nogle netværk glemmer at slå DNS hijacking fra når man er logget på.
Selv hvis man bruger DNS serveren fra DHCP og der ikke foregår hijacking af DNS, så er man ikke garanteret at det virker. DNS er ikke helt simpel, og der findes mange fejlbehæftede DNS servere. F.eks. har jeg set nogle nyere Windows versioner som ikke var i stand til at fungere sammen med nogle routere fra TDC. (Det var sandsynligvis routerens fejl). Den slags fejl kunne man også godt komme ud for på offentlige netværk som det nævnte.
Andre muligheder for hvad der kan gå galt involverer brug af andre protokoller end HTTP. Hele hijacking forløbet er designet efter HTTP. Hvad gør netværket, hvis man forsøger at snakke en anden protokol.
Det kan være trafikken bliver afvist, det kan være man oplever timeout, det kan være den bliver hijacket og besvaret med HTTP selvom klienten slet ikke snakker HTTP. Det kan også være der simpelthen er lukket op for andre protokoller (hvilket dog hører til sjældenhederne). Hvis man forsøger HTTPS kan det være man bliver udsat for et ugyldigt certifikat.
Og når man så har været gennem hele forløbet og skal redirectes tilbage, så kan det gå galt pga. caching. F.eks. kan svaret på den hijackede HTTP session have fortalt browseren noget forkert om caching, sådan at browseren cacher noget, der ikke burde være cachet. Og der kan være bugs i browseren.
At man overhovedet tillader DNS og ikke giver forfalsket svar på DNS forespørgsler i første omgang skyldes at nogle browsere har det med at cache DNS svar i længere tid end de burde. Bruger netværket falske DNS svar i stedet for hijacking på HTTP niveau er selve hijackingen mere pålidelig, men der kan gå noget galt senere hen.
Jeg har også set netværk der godt nok kan hijacke og redirecte, men den server de redirecter til svarer ikke (eller er blokeret).
Det er værd at afprøve både fast konfigureret DNS (f.eks. 8.8.8.8) og DNS fra DHCP. Hvis ingen af de to virker får man nok brug for packet sniffing for at identificere fejlen.
Et typisk forløb er følgende:
1. Du forbinder til et åbent WIFI access point.
2. Du prøver at åbne en webside.
3. DNS forespørgsel sendes til serveren annonceret over DHCP.
4. Et korrekt DNS svar sendes tilbage til browseren.
5. Browseren forsøger at åbne en HTTP forbindelse.
6. HTTP forbindelsen hijackes og et forfalsket svar med en HTTP redirect sendes tilbage.
7. Browseren fortsætter til den nye URL.
8. Den nye URL peger på en loginside som der er åben adgang til.
9. Efter login redirectes browseren enten til den oprindelige URL eller til udbyderens egen hjemmeside.
Der er en hel del variationer over ovenstående tema, og afhængigt af hvilken variation og hvordan computeren er sat op, kan det gå galt.
For det første er der variationer i hvordan DNS opslag håndteres. Nogle netværk tillader kun at du bruger deres egen DNS server. Andre netværk tillader at du bruger en vilkårlig DNS server. De har simpelthen åben for port 53 uanset hvortil.
En totalt åben DNS port giver mulighed for at man kan udnytte det til trafik uden at være autoriseret til adgang på netværket. Men det kan sagtens være en god idé alligevel. For det første forhindrer det problemet som #2 og #3 nævner. Og dem som absolut vil udnytte netværket kan gøre det alligevel. En åben DNS port betyder bare at dem som vil udnytte det kan gøre det uden at belaste default DNS serveren.
En anden fremgangsmåde der til tider anvendes er at hijacke DNS trafik og sende alle DNS opslag til egen DNS server uanset modtageradresse. Det løser også problemet nævnt i #2 og #3, men det betyder mere hijacking, og hijacking kan være medvirkende årsag til mange tekniske problemer. Nogle netværk glemmer at slå DNS hijacking fra når man er logget på.
Selv hvis man bruger DNS serveren fra DHCP og der ikke foregår hijacking af DNS, så er man ikke garanteret at det virker. DNS er ikke helt simpel, og der findes mange fejlbehæftede DNS servere. F.eks. har jeg set nogle nyere Windows versioner som ikke var i stand til at fungere sammen med nogle routere fra TDC. (Det var sandsynligvis routerens fejl). Den slags fejl kunne man også godt komme ud for på offentlige netværk som det nævnte.
Andre muligheder for hvad der kan gå galt involverer brug af andre protokoller end HTTP. Hele hijacking forløbet er designet efter HTTP. Hvad gør netværket, hvis man forsøger at snakke en anden protokol.
Det kan være trafikken bliver afvist, det kan være man oplever timeout, det kan være den bliver hijacket og besvaret med HTTP selvom klienten slet ikke snakker HTTP. Det kan også være der simpelthen er lukket op for andre protokoller (hvilket dog hører til sjældenhederne). Hvis man forsøger HTTPS kan det være man bliver udsat for et ugyldigt certifikat.
Og når man så har været gennem hele forløbet og skal redirectes tilbage, så kan det gå galt pga. caching. F.eks. kan svaret på den hijackede HTTP session have fortalt browseren noget forkert om caching, sådan at browseren cacher noget, der ikke burde være cachet. Og der kan være bugs i browseren.
At man overhovedet tillader DNS og ikke giver forfalsket svar på DNS forespørgsler i første omgang skyldes at nogle browsere har det med at cache DNS svar i længere tid end de burde. Bruger netværket falske DNS svar i stedet for hijacking på HTTP niveau er selve hijackingen mere pålidelig, men der kan gå noget galt senere hen.
Jeg har også set netværk der godt nok kan hijacke og redirecte, men den server de redirecter til svarer ikke (eller er blokeret).
Det er værd at afprøve både fast konfigureret DNS (f.eks. 8.8.8.8) og DNS fra DHCP. Hvis ingen af de to virker får man nok brug for packet sniffing for at identificere fejlen.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Support
Gå til bund