強制門戶
 | 此條目需要補充更多來源。 (2019年5月4日) |
強制門戶（英文：Captive portal，又名強制網絡門戶、強制主頁）是在授予新連接至Wi-Fi的用戶更廣的網絡（互聯網）訪問權限之前在其網頁瀏覽器呈現中的網頁，其常用於呈現可能需要認證或接受最終用戶許可協議/可接受使用策略的着陸頁或登錄頁。強制門戶應用於各方面的移動寬帶服務中（如有線連接、計費Wi-Fi及家庭熱點），同時也可提供對企業或家庭有線網絡（公寓、酒店和商業中心的網絡）的訪問權限。
呈現至客戶端的強制門戶有可能存放在網關或網頁伺服器上。網關也可白名單特定網站或TCP端口以使用戶在不使用網絡門戶的情況下訪問網絡。已連接客戶端的MAC地址可用於繞過特定設備的登錄流程。
用途
[編輯]強制門戶主要用於開放的無線網絡中，用戶將收到歡迎信息及服務條款（許可端口、使用責任等等）。管理員以此來使其用戶對自己的行為負責，並避免自身可能的法律責任。但這種責任授權是否具有法律效力仍有爭議。[1][2]
強制門戶通常用於營銷和商業交流用途。用戶往往需要先在網頁瀏覽器中打開登記表單，填寫自己的個人數據後才能訪問互聯網。這種表單可能會自動在用戶的瀏覽器中打開，也有可能會在用戶使用瀏覽器打開任意網頁時出現。換言之，用戶被「捕獲」（即英文「Captive」的字面意思）——直至完成表單前用戶都無法自由訪問互聯網，使得服務提供商可向連接至Wi-Fi接入點的用戶顯示或發送廣告。由於其可能需要社交網絡賬號（如微信、Facebook）登錄，這種類型的服務有時被稱為「社交Wi-Fi」。近年來，隨着多個公司開始提供基於Wi-Fi數據的市場營銷，社交Wi-Fi強制門戶也漸漸成為家常便飯。
實現
[編輯]市面上存在多種實現強制門戶的方式。
HTTP重定向
[編輯]常見方法之一是將所有萬維網流量定向至網頁伺服器，同時向強制門戶返回HTTP重定向。 [3]當現代互聯網設備首次連接至網絡時，其將發出HTTP請求並期望返回HTTP 204狀態碼。若設備接收到HTTP 204狀態碼，則設備將認為自己擁有無限的互聯網訪問權限；若設備接收到HTTP 302狀態碼，則設備顯示強制門戶提示。[4][5]
ICMP重定向
[編輯]重定向DNS
[編輯]當客戶端請求互聯網資源時，瀏覽器會查詢DNS。在強制門戶中，防火牆將確保僅有網絡DHCP伺服器提供的DNS可被未認證的客戶端使用（或將所有未認證客戶端的請求轉發至此DNS伺服器）。隨後，網絡提供的DNS伺服器將對所有的DNS查詢結果返回強制門戶頁面的IP位址。
強制門戶使用DNS劫持攻擊（與中間人攻擊類似）進行DNS重定向。為了減輕DNS投毒的影響，伺服器通常將存活時間設置為0。
繞過強制門戶
[編輯]據了解，強制門戶的防火牆規則不夠完善。[6]在部分部署情形下，防火牆將轉發客戶端DNS請求至互聯網，或者所提供的DNS伺服器將履行客戶端的任意DNS請求。這使得客戶端可繞過強制門戶並通過DNS包內的任意隧道流量訪問開放互聯網。
部分強制門戶可能被配置為允許被特定用戶代理（User Agent）檢測並自動認證。用戶代理及如蘋果《Captive Portal Assistant》一類的軟件有時能在擁有正確憑證的情況下違背服務提供商的意願，繞過強制門戶的內容顯示；或者它們可能會嘗試使用不正確或過期的憑證認證，導致賬戶鎖定一類的意外後果。
根據MAC地址追蹤已連接設備的強制門戶有時可通過連接到允許設置MAC地址的路由器上的方法規避。路由器固件通常將此行為稱之為MAC地址克隆。一旦計算機或平板電腦已使用有效的用戶名及密碼在強制門戶上認證，路由器可複製其MAC地址連接到強制門戶，同時路由器的MAC地址也將顯示為被克隆設備的地址。
局限性
[編輯]上述的部分實現僅需用戶的IP及MAC地址允許通過網關後訪問經SSL加密的登錄頁面。此方法可使用數據包分析器破解。一旦發現其他已認證設備的IP及MAC地址，任何主機均可使用此信息欺騙網關。正因如此，部分強制門戶解決方式創建了擴充認證機制以減小欺騙風險。
強制門戶通常需要使用網頁瀏覽器；這也通常是用戶連接至互聯網後使用的首個應用程式，但使用需要互聯網連接的電子郵件或其他應用程式的用戶可能會發現應用無法正常工作，並需要開啟網頁瀏覽器驗證。但是有時用戶也可使用不依賴DNS的電子郵件或其他軟件（若應用程式指定了連接IP而非主機名的情況下）。此問題在客戶端使用AJAX或已載入網頁至網絡瀏覽器之後連接網絡的情況下同樣存在，網頁在嘗試向其源伺服器上發送HTTP請求時可能會造成未定義行為。
相似地，由於HTTPS連接無法被重定向（至少在不觸發安全警告的情況下），僅有在被強制門戶授權前訪問加密站點的網頁瀏覽器才會顯示訪問嘗試失敗（通常此情況僅在目標網站離線或無法訪問時出現）。
擁有Wi-Fi和TCP/IP棧但沒有支持HTTPS的瀏覽器的平台（如使用任天堂Wi-Fi連接的任天堂DS）無法使用大部分強制門戶。市面上也存在使用基於XML的WISPr認證協議或基於其他協議/MAC地址的非瀏覽器認證方案。
平台供應商也可經由大量強制門戶熱點的運營商並通過其封閉平臺通過對平台供應商伺服器的免費或優惠訪問。其中一個例子是2005年任天堂與Wayport直接達成了交易，以在特定的麥當勞餐廳為任天堂DS用戶提供免費Wi-Fi。[7]另外，網關需允許VoIPSIP端口繞過其本身才能讓VoIP電話正常工作。
另請參閱
[編輯]參考文獻
[編輯]- ^ Wi-Fi Hotspots and Liability Concerns. Maiello Brungo & Maiello. April 9, 2007 [2019-03-06]. （原始內容存檔於2019-05-04）.
- ^ Myths and Facts: Running Open Wireless and liability for what others do. Open Wireless Movement. August 7, 2012 [2019-03-06]. （原始內容存檔於2019-02-14）.
- ^ Wippler, Andrew J. Captive Portal Overview. Andrew Wippler's Sketchpad. April 7, 2017 [2019-03-06]. （原始內容存檔於2019-05-04）.
- ^ Wippler, Andrew J. WiFi Captive Portal. Andrew Wippler's Sketchpad. March 11, 2016 [2019-03-06]. （原始內容存檔於2019-05-04）.
- ^ Network Portal Detection. Chromium. [2019-03-06]. （原始內容存檔於2019-03-03）.
- ^ Laliberte, Marc. Lessons from DEFCON 2016 – Bypassing Captive Portals. August 26, 2016 [2019-03-06]. （原始內容存檔於2019-02-04）.
- ^ Nintendo And Wayport Join Forces To Bring Free U.S. Wi-Fi Access To Nintendo DS Users. 2005-10-18 [2019-03-06]. （原始內容存檔於2019-05-04）.
外部連結
[編輯]- Android強制門戶設置 （頁面存檔備份，存於互聯網檔案館）
- RFC 7710 使用DHCP或路由器廣播（RA）的強制門戶識別