캡티브 포털
캡티브 포털(Captive portal)은 와이파이 또는 유선 네트워크에 새로 연결된 사용자에게 네트워크 리소스에 대한 더 넓은 접근 권한이 부여되기 전에 표시되는, 웹 브라우저로 접근하는 웹 페이지이다. 캡티브 포털은 일반적으로 인증, 전자지급결제대행서비스, 소프트웨어 사용권 동의/이용 목적 제한 방침 수락 또는 설문 조사 완료를 요구할 수 있는 랜딩 또는 로그인 페이지를 제공하는 데 사용된다.[1] 캡티브 포털은 케이블 및 상업적으로 제공되는 와이파이와 홈 핫스팟을 포함한 광범위한 모바일 및 보행자 광대역 서비스에 사용된다. 캡티브 포털은 또한 아파트, 호텔 객실 및 비즈니스 센터와 같은 기업 또는 주거용 유선 네트워크에 대한 접근을 제공하는 데 사용될 수 있다.
캡티브 포털은 클라이언트에게 제공되며 게이트웨이 또는 웹 페이지를 호스팅하는 웹 서버에 저장된다. 게이트웨이의 기능 집합에 따라 웹사이트 또는 TCP 포트를 허용 목록에 추가하여 사용자가 캡티브 포털과 상호 작용할 필요 없이 사용할 수 있다. 연결된 클라이언트의 MAC 주소는 지정된 장치에 대한 로그인 프로세스를 우회하는 데 사용될 수도 있다.
WISPr은 이 웹 브라우저 기반 인증 방법을 Universal Access Method(UAM)라고 부른다.[2]
용도
[편집]캡티브 포털은 주로 사용자가 접근 조건(허용된 포트, 책임 등)을 알리는 환영 메시지를 보는 개방형 무선 네트워크에서 사용된다. 관리자는 자체 사용자가 자신의 행동에 책임을 지고 법적 책임을 피하도록 이를 수행하는 경향이 있다.[3] 이 책임 위임이 법적으로 유효한지는 논란의 여지가 있다.[4][5] 일부 네트워크는 네트워크에서 불법 활동이 발생할 경우 관리자가 당국에 정보를 제공할 수 있도록 사용자의 휴대폰 번호 또는 신원 정보를 입력하도록 요구할 수도 있다.
종종 캡티브 포털은 마케팅 및 상업적 통신 목적으로 사용된다. 사용자가 웹 브라우저에서 웹 기반 등록 양식을 작성하여 개인 데이터를 교환할 때까지 개방형 와이파이를 통한 인터넷 접근은 금지된다. 웹 기반 양식은 웹 브라우저에서 자동으로 열리거나, 사용자가 웹 브라우저를 열고 어떤 웹 페이지를 방문하려고 할 때 나타난다. 즉, 사용자는 인터넷 접근 권한이 부여되고 캡티브 포털을 "완료"할 때까지 인터넷에 자유롭게 접근할 수 없는 "포로" 상태이다. 이를 통해 이 서비스 제공자는 와이파이 접근 지점에 연결하는 사용자에게 광고를 표시하거나 보낼 수 있다. 이러한 유형의 서비스는 페이스북과 같은 사회 연결망 계정으로 로그인하도록 요청할 수 있으므로 때때로 "소셜 와이파이"라고도 알려져 있다. 지난 몇 년 동안 이러한 소셜 와이파이 캡티브 포털은 와이파이 데이터 수집을 중심으로 마케팅을 제공하는 다양한 회사와 함께 흔해졌다.[6]
사용자는 캡티브 포털에서 많은 유형의 콘텐츠를 찾을 수 있으며, 콘텐츠를 보거나 특정 행동을 수행하는 대가(종종 상업적 연락을 가능하게 하기 위해 개인 데이터를 제공)로 인터넷 접근을 허용하는 경우가 많다. 따라서 캡티브 포털의 마케팅 사용은 리드 생성(비즈니스 연락처 또는 잠재 고객)을 위한 도구이다.[7]
구현
[편집]캡티브 포털을 구현하는 다양한 방법이 있다.
HTTP 리디렉션
[편집]일반적인 방법은 모든 월드 와이드 웹 트래픽을 웹 서버로 보내는 것으로, 웹 서버는 캡티브 포털로 HTTP 302 리디렉션을 반환한다.[8] 최신 인터넷 지원 장치가 네트워크에 처음 연결되면, 공급업체에서 미리 정의한 감지 URL로 HTTP 요청을 보내고 HTTP 상태 코드 200 OK 또는 204 No Content를 기대한다. 장치가 HTTP 2xx 상태 코드를 받으면 무제한 인터넷 접근 권한이 있다고 가정한다. 장치가 대신 캡티브 포털로 302 리디렉션 상태 코드를 받으면 캡티브 포털 프롬프트가 표시된다.[9][10] RFC 6585는 511 Network Authentication Required 상태 코드를 지정한다.
ICMP 리디렉션
[편집]클라이언트 트래픽은 레이어 3 수준에서 ICMP 리디렉션을 사용하여 리디렉션될 수도 있다.
DNS를 통한 리디렉션
[편집]클라이언트가 이름으로 원격 호스트의 리소스를 요청할 때, 해당 호스트 이름을 확인하기 위해 DNS가 쿼리된다. 캡티브 포털에서 방화벽은 네트워크의 DHCP가 제공하는 DNS 서버만 인증되지 않은 클라이언트가 사용할 수 있도록 보장한다(또는, 대안적으로 인증되지 않은 클라이언트의 모든 DNS 요청을 해당 DNS 서버로 전달한다). 이 DNS 서버는 모든 DNS 조회 결과로 캡티브 포털 페이지의 IP 주소를 반환한다.
DNS를 통한 리디렉션을 수행하기 위해 캡티브 포털은 DNS 하이재킹을 사용하여 중간자 공격과 유사한 작업을 수행한다. DNS 오염의 영향을 제한하기 위해 일반적으로 TTL 0이 사용된다.
캡티브 포털 API
[편집]RFC 8910은 네트워크가 DHCP(IPv4 및 DHCPv6 모두) 옵션 및 IPv6 NDP 라우터 광고를 사용하여 RFC 8908 캡티브 포털 API 엔드포인트의 존재를 클라이언트에게 알리는 표준화된 방법을 소개한다. RFC 8910은 2023년 7월에 Systemd-networkd v254에 구현되었다.[11][12] 네트워크매니저 토론에서도 캡티브 포털 상호 작용에 사용될 가능성을 탐구했다.[13]
탐지
[편집]캡티브 포털 탐지 URL은 일반적으로 캡티브 포털 뒤에 있지 않을 때 최소한의 표준화된 응답을 반환한다. 장치가 예상 응답을 받으면 직접 인터넷 접근 권한이 있다고 결론 내린다. 응답이 다르면 장치는 캡티브 포털 뒤에 있다고 가정하고 캡티브 포털 로그인 프로세스를 트리거한다.
| 플랫폼 | 테스트 URL | 예상 응답 |
|---|---|---|
| 애플
(MacOS/iOS 계열) |
현재: | 제목과 본문 텍스트 모두에 "Success"가 포함된 HTML |
| 레거시: | ||
| 구글[14]
(안드로이드/크롬OS) |
http://connectivitycheck.gstatic.com/generate_204 | HTTP 상태 코드 204 및 빈 본문 |
| http://clients3.google.com/generate_204 | ||
| 윈도우[15] | 현재 (윈도우 10 1607 이상): | "Microsoft Connect Test" (평문) |
| 레거시 (윈도우 10 1607 이전): | "Microsoft NCSI" (평문) | |
| 네트워크매니저 (그놈) | http://nmcheck.gnome.org/check_network_status.txt | "NetworkManager is online" (평문) |
| 네트워크매니저 (KDE 플라스마) | http://networkcheck.kde.org/ | "OK" (평문) |
| 모질라 파이어폭스[16] | http://detectportal.firefox.com/canonical.html | "<meta http-equiv="refresh" content="0;url=https://support.mozilla.org/kb/captive-portal"/>" (HTML) |
한계
[편집]보안
[편집]캡티브 포털은 불완전한 방화벽 규칙 집합을 가지고 있는 것으로 알려져 있는데 – 예를 들어 아웃바운드 포트가 열려 있어서 – 클라이언트가 포털을 우회할 수 있다.[17]
DNS 터널링
[편집]일부 배포에서는 규칙 집합이 클라이언트의 DNS 요청을 인터넷으로 라우팅하거나, 제공된 DNS 서버가 클라이언트의 임의 DNS 요청을 처리한다. 이를 통해 클라이언트는 DNS 패킷 내에서 임의의 트래픽을 터널링하여 캡티브 포털을 우회하고 개방된 인터넷에 접근할 수 있다.
자동 제출
[편집]일부 캡티브 포털은 적절하게 장착된 사용자 에이전트가 캡티브 포털을 감지하고 자동으로 인증할 수 있도록 구성될 수 있다. 애플의 Captive Portal Assistant와 같은 사용자 에이전트 및 보조 응용 프로그램은 올바른 자격 증명에 접근할 수 있는 한 서비스 운영자의 의지와 상관없이 캡티브 포털 콘텐츠 표시를 투명하게 우회할 수 있으며, 또는 잘못되거나 오래된 자격 증명으로 인증을 시도하여 의도하지 않은 결과(예: 우발적인 계정 잠금)를 초래할 수 있다.
MAC 스푸핑
[편집]MAC 주소를 사용하여 연결된 장치를 추적하는 캡티브 포털은 이전에 인증된 장치의 MAC 주소를 재사용하여 우회될 수 있다. 유효한 자격 증명을 사용하여 캡티브 포털에 장치가 인증되면 게이트웨이는 해당 장치의 MAC 주소를 허용 목록에 추가한다. MAC 주소는 쉽게 스푸핑될 수 있으므로 다른 장치가 인증된 장치인 척하여 캡티브 포털을 우회할 수 있다. 다른 연결 컴퓨터의 IP 주소와 MAC 주소가 인증된 것으로 확인되면 모든 머신이 인증된 대상의 MAC 주소와 인터넷 프로토콜(IP) 주소를 스푸핑하고 게이트웨이를 통해 경로를 허용받을 수 있다. 이러한 이유로 일부 캡티브 포털 솔루션은 강탈 위험을 제한하기 위해 확장된 인증 메커니즘을 만들었다.
웹 브라우저 필요
[편집]캡티브 포털은 종종 웹 브라우저 사용을 요구한다. 이메일 클라이언트나 인터넷에 의존하는 다른 응용 프로그램을 먼저 사용하는 사용자는 연결이 설명 없이 작동하지 않는 것을 발견할 수 있으며, 유효성을 검사하려면 웹 브라우저를 열어야 한다. 이는 운영체제에 웹 브라우저가 설치되어 있지 않은 사용자에게는 문제가 될 수 있다. 그러나 DNS에 의존하지 않는 이메일 및 기타 기능을 사용하는 것이 때로는 가능하다(예: 응용 프로그램이 호스트 이름 대신 연결 IP 주소를 지정하는 경우). 유사한 문제는 클라이언트가 AJAX를 사용하거나 웹 브라우저에 이미 페이지가 로드된 상태로 네트워크에 가입할 때 발생할 수 있으며, 이러한 페이지가 원본 서버에 HTTP 요청을 시도할 때 미정의 동작 (예: 손상된 메시지 나타남)을 유발한다.
마찬가지로, HTTPS 연결은 리디렉션될 수 없으므로(적어도 보안 경고를 트리거하지 않고는), 캡티브 포털에 의해 승인되기 전에 보안 웹사이트에만 접근하려는 웹 브라우저는 그러한 시도가 설명 없이 실패하는 것을 볼 것이다(일반적인 증상은 의도한 웹사이트가 다운되거나 접근할 수 없는 것처럼 보이는 것이다).
와이파이와 TCP/IP 스택은 있지만 HTTPS를 지원하는 웹 브라우저가 없는 플랫폼은 많은 캡티브 포털을 사용할 수 없다. 이러한 플랫폼에는 닌텐도 Wi-Fi 커넥션을 사용하는 게임을 실행하는 닌텐도 DS가 포함된다. 브라우저가 아닌 인증은 이 목적을 위한 XML 기반 인증 프로토콜인 WISPr을 사용하거나 MAC 기반 인증 또는 다른 프로토콜 기반 인증을 사용하여 가능하다.
또한 플랫폼 공급업체는 캡티브 포털 핫스팟 운영자와 서비스 계약을 맺어 핫스팟의 동화 속 정원을 통해 플랫폼 공급업체의 서버에 무료 또는 할인된 접근을 허용할 수 있다. 예를 들어, 2005년 닌텐도와 웨이포트는 특정 맥도날드 레스토랑에서 닌텐도 DS 사용자에게 무료 와이파이 접근을 제공하기 위해 협력했다.[18] 또한, VoIP 및 SIP 포트는 게이트웨이를 우회하여 전화기가 전화를 걸고 받을 수 있도록 허용될 수 있다.
같이 보기
[편집]각주
[편집]- ↑ “What is a captive portal? – TechTarget Definition” (영어). 《Mobile Computing》. 2023년 12월 19일에 확인함.
- ↑ Wiederkehr, Patrick (2009). 《Approaches for simplified hotspot logins with Wi-Fi devices》 (영어) (Master Thesis). ETH, Swiss Federal Institute of Technology, Computer Science Department. doi:10.3929/ethz-a-005899210. 2022년 11월 20일에 원본 문서에서 보존된 문서. 2022년 11월 20일에 확인함.
- ↑ “What Is a Captive Portal? | Linksys: US” (영어). 《www.linksys.com》. 2023년 12월 19일에 확인함.
- ↑ “Wi-Fi Hotspots and Liability Concerns”. 《Maiello Brungo & Maiello》. 2007년 4월 9일. 2019년 5월 4일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
- ↑ “Myths and Facts: Running Open Wireless and liability for what others do”. 《Open Wireless Movement》. 2012년 8월 7일. 2019년 2월 14일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
- ↑ “Understand the Evolution of Captive Portal to Cloud Authentication Solutions”. 2023년 5월 23일. 2023년 7월 2일에 원본 문서에서 보존된 문서. 2023년 7월 8일에 확인함.
- ↑ YEC. “Council Post: Why Leverage Captive Portals To Uncover Hidden Customers” (영어). 《Forbes》. 2022년 3월 18일에 원본 문서에서 보존된 문서. 2022년 3월 18일에 확인함.
- ↑ Wippler, Andrew J. (2017년 4월 7일). “Captive Portal Overview”. 《Andrew Wippler's Sketchpad》. 2019년 5월 4일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
- ↑ Wippler, Andrew J. (2016년 3월 11일). “WiFi Captive Portal”. 《Andrew Wippler's Sketchpad》. 2019년 5월 4일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
- ↑ “Network Portal Detection”. 크로미엄. 2019년 3월 3일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
- ↑ “systemd v254”. 《GitHub》. 2023년 7월 28일. 2024년 11월 3일에 확인함.
- ↑ Ronan Pigott (2023년 6월 22일). “Implement RFC8910: captive portal dhcp options”. 《GitHub》. 2024년 11월 3일에 확인함.
- ↑ Petr Menšík (2023년 5월 30일). “[RFE] Support of captive portal API”. 《Freedesktop GitLab》. 2024년 11월 3일에 확인함.
- ↑ “Network Portal Detection”. Google. 2024년 3월 6일에 확인함.
- ↑ “Answers To Common Questions About NCSI”. Microsoft. 2023년 6월 23일. 2024년 3월 6일에 확인함.
- ↑ “Captive portal detection”. Mozilla.
- ↑ Laliberte, Marc (2016년 8월 26일). “Lessons from DEFCON 2016 – Bypassing Captive Portals”. 2019년 2월 4일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
- ↑ “Nintendo And Wayport Join Forces To Bring Free U.S. Wi-Fi Access To Nintendo DS Users”. 2005년 10월 18일. 2019년 5월 4일에 원본 문서에서 보존된 문서. 2019년 3월 6일에 확인함.
외부 링크
[편집]- 안드로이드 캡티브 포털 설정
- RFC 8910 DHCP 및 라우터 광고(RAs)의 캡티브 포털 식별
- 캡티브 포털 솔루션 캡티브 와이파이