Infångad portal

Ett exempel på en captive webbportal som används för att logga in på ett begränsat nätverk.

En captive portal är en webbsida som nås med en webbläsare som visas för nyligen anslutna användare av ett Wi-Fi eller trådbundet nätverk innan de ges bredare åtkomst till nätverksresurser. Captive-portaler används vanligtvis för att presentera en landnings- eller inloggningssida som kan kräva autentisering , betalning , godkännande av ett slutanvändarlicensavtal, policy för acceptabel användning , ifyllande av enkäter eller andra giltiga referenser som både värden och användaren samtycker till att följa förbi. Captive-portaler används för ett brett utbud av mobila och fotgängare bredbandstjänster – inklusive kabel och kommersiellt tillhandahållna Wi-Fi och hotspots för hemmet. En captive portal kan också användas för att ge åtkomst till företags- eller bostadsnätverk, såsom hyreshus, hotellrum och företagscenter.

Captive-portalen presenteras för klienten och lagras antingen vid gatewayen eller på en webbserver som är värd för webbsidan. Beroende på funktionsuppsättningen för gatewayen kan webbplatser eller TCP-portar vitlistas så att användaren inte behöver interagera med captive-portalen för att kunna använda dem. MAC -adressen för anslutna klienter kan också användas för att kringgå inloggningsprocessen för specificerade enheter.

WISPr hänvisar till denna webbläsarbaserade autentiseringsmetod som Universal Access Method (UAM).

Används

Captive-portaler används främst i öppna trådlösa nätverk där användarna får ett välkomstmeddelande som informerar dem om villkoren för åtkomst (tillåtna portar, ansvar, etc.). Administratörer tenderar att göra detta så att deras egna användare tar ansvar för sina handlingar och för att undvika allt juridiskt ansvar. Huruvida denna delegering av ansvar är juridiskt giltig är en fråga om diskussion.

Ofta används captive portaler för marknadsföring och kommersiell kommunikation. Tillgång till Internet via öppet Wi-Fi är förbjudet tills användaren utbyter personuppgifter genom att fylla i ett webbaserat registreringsformulär i en webbläsare. Det webbaserade formuläret öppnas antingen automatiskt i en webbläsare eller visas när användaren öppnar en webbläsare och försöker besöka valfri webbsida. Med andra ord, användaren är "fångad" - oförmögen att komma åt Internet fritt förrän användaren har beviljats ​​tillgång till Internet och har "slutfört" captive-portalen. Detta gör att leverantören av denna tjänst kan visa eller skicka annonser till användare som ansluter till Wi-Fi-åtkomstpunkten. Denna typ av tjänst kallas ibland också för "socialt Wi-Fi", eftersom de kan be om ett socialt nätverkskonto för att logga in (som Facebook ). Under de senaste åren har sådana sociala Wi-Fi captive-portaler blivit vanliga hos olika företag som erbjuder marknadsföring centrerad kring Wi-Fi-datainsamling.

Användaren kan hitta många typer av innehåll i captive-portalen, och det är ofta att tillåta åtkomst till Internet i utbyte mot att titta på innehåll eller utföra en viss åtgärd (ofta tillhandahåller personuppgifter för att möjliggöra kommersiell kontakt); Därför är marknadsföringsanvändningen av captive-portalen ett verktyg för att generera leads (affärskontakter eller potentiella kunder).

Genomförande

Det finns olika sätt att implementera en captive-portal.

HTTP-omdirigering

  En vanlig metod är att dirigera all World Wide Web- trafik till en webbserver, som returnerar en HTTP-omdirigering till en captive-portal. När en modern, internetaktiverad enhet först ansluter till ett nätverk, skickar den ut en HTTP-förfrågan till en identifierings-URL fördefinierad av dess leverantör och förväntar sig en HTTP-statuskod 200 OK eller 204 Inget innehåll. Om enheten tar emot en HTTP 200-statuskod antar den att den har obegränsad tillgång till internet. Uppmaningar om captive portal visas när du kan manipulera detta första HTTP-meddelande för att returnera en HTTP-statuskod på 302 (omdirigering) till den captive-portal du väljer. RFC 6585 anger 511 Network Authentication Required-kod.

ICMP omdirigering

Klienttrafik kan också omdirigeras med ICMP-omdirigering på nivå 3.

Omdirigera via DNS

När en klient begär en resurs på en fjärrvärd efter namn, frågas DNS för att lösa det värdnamnet. I en infångad portal kommer brandväggen att se till att endast DNS-servrarna som tillhandahålls av nätverkets DHCP kan användas av oautentiserade klienter (eller, alternativt, kommer den att vidarebefordra alla DNS-förfrågningar från oautentiserade klienter till den DNS-servern). Denna DNS-server kommer att returnera IP-adressen för den infångade portalsidan som ett resultat av alla DNS-uppslagningar.

För att utföra omdirigering via DNS använder captive-portalen DNS-kapning för att utföra en åtgärd som liknar en man-in-the-middle-attack . För att begränsa effekten av DNS-förgiftning används vanligtvis en TTL på 0.

Begränsningar

säkerhet

Captive-portaler har varit kända för att ha ofullständiga brandväggsregeluppsättningar.

DNS-tunnling

I vissa distributioner kommer regeluppsättningen att dirigera DNS-förfrågningar från klienter till Internet, eller så kommer den tillhandahållna DNS-servern att uppfylla godtyckliga DNS-förfrågningar från klienten. Detta gör att en klient kan kringgå den infångade portalen och komma åt det öppna Internet genom att tunnla godtycklig trafik inom DNS-paket.

Automatisk inlämning

Vissa captive-portaler kan konfigureras för att tillåta lämpligt utrustade användaragenter att upptäcka captive-portalen och automatiskt autentisera. Användaragenter och tilläggsprogram som Apples Captive Portal Assistant kan ibland på ett transparent sätt kringgå visningen av captive portalinnehåll mot tjänsteoperatörens önskemål så länge de har tillgång till korrekta referenser, eller så kan de försöka autentisera med felaktiga eller föråldrade referenser, vilket resulterar i oavsiktliga konsekvenser som oavsiktlig kontolåsning.

MAC-spoofing

En captive-portal som använder MAC-adresser för att spåra anslutna enheter kan ibland kringgås genom att återanvända MAC-adressen för en tidigare autentiserad enhet. När en enhet har autentiserats till captive-portalen med giltiga referenser, lägger gatewayen till enhetens MAC-adress till sin godkännandelista; eftersom MAC-adresser lätt kan förfalskas, kan vilken annan enhet som helst låtsas vara den autentiserade enheten och kringgå captive-portalen. När IP- och MAC-adresserna för andra anslutande datorer har befunnits vara autentiserade, kan vilken maskin som helst förfalska MAC-adressen och Internet Protocol (IP)-adressen för det autentiserade målet och tillåtas en rutt genom gatewayen. Av denna anledning skapade vissa captive portallösningar utökade autentiseringsmekanismer för att begränsa risken för usurpation.

Kräv webbläsare

Captive-portaler kräver ofta användning av en webbläsare; användare som först använder en e-postklient eller annan applikation som är beroende av Internet kan upptäcka att anslutningen inte fungerar utan förklaring och måste sedan öppna en webbläsare för att validera. Detta kan vara problematiskt för användare som inte har någon webbläsare installerad på sitt operativsystem . Det är dock ibland möjligt att använda e-post och andra faciliteter som inte är beroende av DNS (t.ex. om programmet anger anslutningens IP-adress snarare än värdnamnet). Ett liknande problem kan uppstå om klienten använder AJAX eller går med i nätverket med sidor som redan är inlästa i sin webbläsare, vilket orsakar odefinierat beteende (till exempel korrupta meddelanden visas) när en sådan sida försöker HTTP-förfrågningar till sin ursprungsserver.

På liknande sätt, eftersom HTTPS-anslutningar inte kan omdirigeras (åtminstone inte utan att utlösa säkerhetsvarningar), kommer en webbläsare som endast försöker komma åt säkra webbplatser innan den har auktoriserats av captive-portalen att se dessa försök misslyckas utan förklaring (det vanliga symptomet är att den avsedda webbplatsen verkar vara nere eller otillgänglig).

Plattformar som har Wi-Fi och en TCP/IP-stack men som inte har en webbläsare som stöder HTTPS kan inte använda många captive-portaler. Sådana plattformar inkluderar Nintendo DS som kör ett spel som använder Nintendo Wi-Fi Connection . Icke-webbläsarautentisering är möjlig med WISPr , ett XML -baserat autentiseringsprotokoll för detta ändamål, eller MAC-baserad autentisering eller autentiseringar baserade på andra protokoll.

Det är också möjligt för en plattformsleverantör att ingå ett serviceavtal med operatören av ett stort antal captive portal-hotspots för att tillåta fri eller rabatterad tillgång till plattformsleverantörens servrar via hotspotens muromgärdade trädgård . Till exempel, 2005 gick Nintendo och Wayport ihop för att tillhandahålla gratis Wi-Fi-åtkomst till Nintendo DS-användare på vissa McDonald's- restauranger. Dessutom VoIP SIP- portar tillåtas att kringgå gatewayen för att låta telefoner fungera. [ förtydligande behövs ]

Se även

  1. ^ Wiederkehr, Patrick (2009). "Tillvägagångssätt för förenklade hotspot-inloggningar med Wi-Fi-enheter" . doi : 10.3929/ethz-a-005899210 . {{ citera journal }} : Citera journal kräver |journal= ( hjälp )
  2. ^ "Wi-Fi-hotspots och ansvarsbekymmer" . Maiello Brungo & Maiello . 9 april 2007 . Hämtad 2019-03-06 .
  3. ^ "Myter och fakta: Att köra Open Wireless och ansvar för vad andra gör" . Öppna Wireless Movement . 7 augusti 2012 . Hämtad 2019-03-06 .
  4. ^ YEC. "Rådets inlägg: Varför utnyttja infångade portaler för att avslöja dolda kunder" . Forbes . Hämtad 2022-03-18 .
  5. ^ Wippler, Andrew J. (7 april 2017). "Fångad portalöversikt" . Andrew Wipplers skissblock . Hämtad 2019-03-06 .
  6. ^ Wippler, Andrew J. (11 mars 2016). "WiFi Captive Portal" . Andrew Wipplers skissblock . Hämtad 2019-03-06 .
  7. ^ "Nätverksportalavkänning" . Krom . Hämtad 2019-03-06 .
  8. ^ Laliberte, Marc (26 augusti 2016). "Lektioner från DEFCON 2016 – Förbigående av fångna portaler" . Hämtad 2019-03-06 .
  9. ^ "Nintendo och Wayport går samman för att ge gratis tillgång till US Wi-Fi till Nintendo DS-användare" . 2005-10-18 . Hämtad 2019-03-06 .

externa länkar