내용 요약: 비즈니스 운영 중 WebRTC 검사에서 유출이 감지되면, 먼저 중요한 계정 로그인이나 조작을 중단하고 현재 환경을 닫은 후 프록시 연결, WebRTC 모드, IPv6 및 프록시 우회 규칙을 확인해야 합니다. MostLogin 사용자의 일반적인 처리 방법은 다음과 같습니다: 프록시 감지가 성공적인지 확인하고, 환경의 WebRTC를 Private(개인정보)로 설정합니다. 비즈니스에서 웹 오디오/비디오 또는 P2P 통신이 전혀 필요하지 않은 경우 Disabled(비활성화)를 선택할 수도 있습니다. 동시에 프록시 장애 시 환경 열기를 금지하는 보호 규칙을 활성화합니다.
테스트 페이지에 여러 주소가 표시되었다고 해서 반드시 유출인 것은 아닙니다. 페이지에서 실제 공용 IPv4, 실제 공용 IPv6이 노출되었거나, 해당 환경과 연관되어서는 안 되는 네트워크 출구가 나타난 경우에만 즉각적인 조치가 필요한 고위험 문제로 간주됩니다.
WebRTC란 무엇인가? 왜 일반 프록시 설정을 우회할 수 있는가?
WebRTC는 Web Real-Time Communication의 약자로, "웹 실시간 통신"을 의미합니다. 브라우저 간 음성 통화, 화상 회의, 화면 공유 및 P2P 데이터 전송을 직접 허용하며, 많은 온라인 회의, 고객 상담 통화 및 협업 도구에서 사용됩니다.
두 장치 간 사용 가능한 연결 경로를 찾기 위해 WebRTC는 ICE를 통해 여러 "후보 주소"를 수집합니다. 이러한 후보 주소에는 장치 네트워크 인터페이스 주소, STUN 서버를 통해 발견된 공용 매핑 주소, 그리고 TURN 서버를 통해 중계되는 주소가 포함될 수 있습니다. MDN의 ICE 후보 유형 설명에 따르면, host 후보는 장치의 직접 주소를 나타내고, srflx 후보는 STUN/TURN 상호작용에 의해 생성되며, relay 후보는 TURN 중계를 통해 사용됩니다. MDN의 WebRTC 연결 설명
이것이 WebRTC 유출이 발생하는 근본적인 이유입니다: 웹페이지는 JavaScript를 통해 WebRTC 연결을 생성하고 ICE 후보를 읽습니다. 브라우저가 이러한 주소를 올바르게 제한하지 않으면, 웹페이지가 보는 네트워크 정보가 프록시 출구와 일치하지 않을 수 있습니다. MDN은 또한 ICE 후보 주소가 사용자의 예상보다 장치 위치 및 네트워크 토폴로지 정보를 유출할 수 있으며, 브라우저 핑거프린팅에 사용될 수 있다고 명시하고 있습니다. MDN의 RTCIceCandidate 보안 설명
간단히 이해하면: 일반 웹페이지 요청은 프록시를 통해 전송될 수 있지만, WebRTC는 실시간 통신 경로를 별도로 찾습니다. 두 경로가 통합되어 제약되지 않으면, 웹사이트는 "프록시 IP"와 "다른 네트워크 주소 그룹"을 동시에 볼 수 있습니다.
어떤 상황이 WebRTC 유출인가?
유출 판단은 테스트 페이지에 IP가 나타났는지 여부만으로 판단할 수 없으며, "페이지에 무엇이 표시되었는지"와 "환경이 원래 무엇을 표시해야 하는지"를 비교해야 합니다.
| 테스트 결과 | 유출 여부 | 위험 판단 |
|---|---|---|
| WebRTC 공용 IP가 MostLogin에서 감지된 프록시 IP와 일치 | 일반적으로 아님 | 정상, DNS, 타임존 및 위치 정보의 일관성 계속 확인 |
| 가정용 광랜, 회사 네트워크 또는 모바일 핫스팟의 실제 공용 IP 표시 | 예 | 고위험, 현재 환경에서의 계정 조작을 즉시 중단해야 함 |
| 프록시는 IPv4이지만 테스트 페이지에서 실제 공용 IPv6 표시 | 예 | 고위험, IPv6이 프록시로 커버되지 않았을 수 있음 |
192.168.x.x, 10.x.x.x 등 사설 주소 표시 | 불확실 | LAN 정보 노출, 일반적으로 공용 네트워크 출구 유출은 아니지만 네트워크 핑거프린트 정보를 증가시킴 |
무작위 .local 이름 표시 | 일반적으로 아님 | 대부분의 경우 브라우저가 mDNS를 사용하여 로컬 주소를 숨긴 결과 |
| 여러 주소가 표시되지만 모두 동일한 프록시 또는 중계 출구에 속함 | 일반적으로 아님 | IPv4, IPv6 또는 서로 다른 ICE 후보 유형일 수 있음 |
최신 브라우저는 mDNS 호스트명을 사용하여 LAN IP를 대체할 수 있으므로, 테스트 페이지에 무작위 문자열에 .local이 붙은 결과가 나타난다고 해서 실제 공용 IP가 노출된 것은 아닙니다. 정말로 주의해야 할 점은: 브라우저 환경 외부에서 조회한 실제 ISP 공용 주소가 나타났는지 여부입니다.
WebRTC 유출의 결과는?
1. 프록시 신원과 실제 네트워크 신원의 충돌
예를 들어, 어떤 MostLogin 환경에서 미국 뉴욕 프록시를 구성하고 웹페이지 요청도 뉴욕 IP를 표시하지만, WebRTC가 사용자의 로컬 네트워크 공용 IP를 노출하는 경우입니다. 플랫폼이 보는 것은 자연스럽고 안정적인 브라우징 환경이 아니라, 지리적으로나 네트워크 사업자가 상충하는 두 개의 연결 신호입니다.
이것이 자동으로 사용자의 신원을 증명하는 것은 아니지만, 프록시 격리 효과를 약화시키고 비정상적인 리스크 관리, 추가 인증 또는 세션 검토의 신호 중 하나가 될 수 있습니다.
2. 서로 다른 브라우저 환경이 동일한 실제 IP로 연관될 수 있음
팀에서 다양한 테스트 프로젝트를 위해 여러 독립 환경을 만들고, 각 환경마다 다른 프록시를 사용합니다. 만약 이러한 환경 모두 WebRTC를 통해 동일한 사무실 공용 IP를 노출한다면, 웹사이트는 환경 간 반복되는 연관 신호를 얻을 수 있습니다. Cookie, Canvas 및 WebGL이 각각 격리되어 있더라도, 반복적으로 나타나는 실제 네트워크 출구는 환경 간의 독립성을 저하시킵니다.
3. 대략적인 위치, 네트워크 사업자 및 네트워크 구조 노출
공용 IP는 일반적으로 국가, 도시 수준의 지역 및 네트워크 사업자를 판단하는 데 사용될 수 있습니다. LAN 주소, IPv6 또는 다양한 네트워크 인터페이스는 더 많은 네트워크 토폴로지 특성을 노출할 수 있습니다. IP만으로는 정확한 주소나 실제 이름을 확인할 수 없지만, 로그인 계정, Cookie, 장치 핑거프린트 및 행동 데이터와 결합하여 사용할 수 있습니다.
4. 화상 회의 및 웹 통화에서 "개인정보와 사용성"의 트레이드오프 발생
WebRTC를 직접 비활성화하면 관련 노출면을 줄일 수 있지만, WebRTC에 의존하는 화상 회의, 음성 상담, 화면 공유 또는 파일 직접 전송이 제대로 작동하지 않을 수 있습니다. 따라서 올바른 방법은 모든 상황에서 일괄적으로 종료하는 것이 아니라, 비즈니스 필요에 따라 Private과 Disabled 중에서 선택하는 것입니다.
안티 디텍트 브라우저에서 WebRTC 유출 감지 후 먼저 할 6가지
1단계: 현재 환경에서 민감한 조작 일시 중단
검사 페이지에서 이미 실제 공용 IP가 표시되었다면, 로그인, 결제, 콘텐츠 게시 또는 중요한 계정 전환을 계속하지 마십시오. 먼저 다음을 포함한 테스트 결과를 기록합니다:
- 일반 IP 검사에서 표시된 주소;
- WebRTC 검사에서 표시된 IPv4 및 IPv6;
- MostLogin에서 구성된 프록시 주소 및 국가/지역;
- 테스트 시간, 환경 이름 및 VPN 사용 여부.
정보를 기록하는 것은 문제의 원인을 파악하기 위함이며, 스크린샷에 프록시 비밀번호, 계정 Cookie 또는 기타 자격 증명을 보관하지 않는 것이 좋습니다.
2단계: "실제 IP - 프록시 IP - WebRTC IP" 대조표 작성
비즈니스 계정을 열지 않은 상태에서 세 그룹의 검사를 수행합니다:
- 프록시를 사용하지 않는 일반 브라우저에서 현재 공용 IPv4 및 IPv6를 조회하여 실제 네트워크 기준선을 설정합니다.
- MostLogin의
Proxy탭에서 프록시 IP 검사를 클릭하고 예상 출구를 기록합니다. - 해당 환경을 열고 WebRTC 테스트 페이지에서 후보 주소를 확인합니다.
WebRTC 결과가 첫 번째 기준선과 같고 두 번째 프록시 출구와 다르다면, 기본적으로 유출이 확인됩니다. 결과가 프록시 IP와 일치한다면, 정상적인 WebRTC 후보 표시일 가능성이 높습니다.
3단계: 프록시를 먼저 수정한 후 WebRTC 조정
WebRTC 설정은 이미 오프라인 상태이거나 인증에 실패했거나 잘못 구성된 프록시를 복구할 수 없습니다. 대상 환경의 편집 페이지로 이동하여 Proxy 탭을 열고 프로토콜, 호스트, 포트, 계정 및 비밀번호를 확인한 후 프록시 IP 검사를 실행합니다. MostLogin 공식 환경 생성 가이드에 따르면, 현재 direct, http, https 및 socks5를 구성할 수 있으며 "Check proxy IP"를 통해 연결 결과를 확인할 수 있습니다. MostLogin: 새 환경 만들기
프록시 검사가 성공하고 표시된 국가와 도시가 예상과 일치한 후에만 다음 단계로 진행합니다.
4단계: MostLogin에서 적절한 WebRTC 모드 선택
작업 경로는 일반적으로 다음과 같습니다:
Profiles(환경 목록) → 대상 환경 선택 → Edit(편집) → Fingerprint(핑거프린트) → WebRTC
MostLogin의 현재 공식 문서에는 WebRTC 드롭다운 설정이 표시되어 있으며, Private은 WebRTC 기능을 유지하면서 실제 IP를 숨기는 데 사용됩니다. 또한 Public 및 Disabled도 제공될 수 있습니다. MostLogin: WebRTC 핑거프린트 설정 설명
| 모드 | 권장 시나리오 | 주의 사항 |
|---|---|---|
| Private | 일반적인 웹 브라우징, 브라우저 오디오/비디오, 고객 상담 또는 협업 도구가 필요한 경우 | 우선 선택; 저장 후 반드시 재테스트하여 결과가 프록시와 일치하는지 확인 |
| Disabled | 화상 회의, 음성 또는 P2P 기능이 전혀 필요 없는 환경 | 개인정보 경계가 더 명확하지만, 관련 웹사이트 기능이 실패할 수 있음 |
| Public | 실제 네트워크 후보를 공개해야 하는 개발 또는 호환성 테스트로 명확히 제한된 경우 | 실제 네트워크 출구를 숨겨야 하는 프록시 환경에는 적합하지 않음 |
일반적인 프록시 환경에서는 먼저 Private을 사용하는 것이 좋습니다. 비즈니스가 WebRTC에 의존하지 않거나 Private 모드가 격리 요구를 충족하지 못하는 경우에만 Disabled를 테스트합니다. 테스트 페이지에 "WebRTC enabled"가 나타난다고 해서 유출이라고 판단하지 마십시오. 핵심은 어떤 주소가 반환되었는지입니다.
5단계: 프록시 장애 보호 활성화 및 프록시 우회 목록 확인
MostLogin의 전역 설정 또는 환경 환경 설정으로 이동하여 다음 보호를 활성화합니다:
- 프록시 네트워크 오류 시 환경 열지 않기;
- 프록시 IP 변경 시 환경 열지 않기;
- 프록시 IP 국가 또는 지역 변경 시 환경 열지 않기;
- 환경 동기화 실패 시 환경 열지 않기.
MostLogin 공식 문서에서는 이러한 설정을 시작 전 보호 조치로 설명하며, 프록시 네트워크 오류 보호는 프록시 장애 시 실제 ISP IP가 예기치 않게 노출되는 것을 방지합니다. MostLogin: Profile preferences
Settings → Proxy bypass도 확인해야 합니다. 우회 목록에 추가된 도메인은 현재 환경의 프록시가 아닌 로컬 네트워크를 직접 사용합니다. MostLogin 공식 설명에서도 우회 도메인은 실제 로컬 연결을 통해 접근한다고 명시하고 있습니다. MostLogin: Proxy bypass 테스트 사이트, 인증 도메인 또는 해당 API/CDN 도메인이 여기에 있는 경우, 불필요한 예외를 제거하고 저장해야 합니다.
6단계: 환경을 완전히 닫고 다시 열어 교차 재테스트
설정을 저장한 후, 전체 브라우저 환경을 닫고 다시 시작합니다. 검사 페이지를 새로고침하는 것만으로는 충분하지 않습니다. 최소한 두 개의 독립적인 검사 페이지를 사용하여 다음을 각각 확인합니다:
- 브라우저가 외부에 표시하는 일반 공용 IP;
- WebRTC 후보의 IPv4;
- WebRTC 후보의 IPv6;
- DNS, 타임존, 언어 및 위치 정보가 프록시 영역과 일치하는지.
재테스트 통과 기준은: 검사 페이지에서 실제 ISP 공용 IPv4/IPv6가 더 이상 표시되지 않아야 합니다; WebRTC에 표시되는 공용 주소는 프록시, 중계 출구 또는 제품 예상 행동과 일치해야 합니다; 환경 재시작 후에도 결과가 안정적으로 유지되어야 합니다.
MostLogin 사용 예시: 뉴욕 프록시 환경에서 실제 IPv6 감지
시나리오
크로스 리전 웹사이트 QA 팀이 US-NewYork-QA-01이라는 MostLogin 환경을 생성했고, HTTP 프록시 검사는 미국 뉴욕 IPv4를 표시했습니다. 테스트 페이지를 열었을 때, 일반 IP는 여전히 뉴욕이었지만 WebRTC 영역에 로컬 ISP의 공용 IPv6가 나타났습니다.
진단
이는 "여러 IP가 나타나는" 일반적인 상황이 아니라 실제 유출입니다. 원인은 HTTP 프록시가 IPv4 웹페이지 요청을 커버했지만, 호스트의 IPv6 네트워크 경로가 동일하게 처리되지 않아 WebRTC 후보가 여전히 해당 주소를 노출할 수 있었던 것입니다.
처리
- 환경을 닫고 로그인 테스트를 계속하지 않습니다.
- 프록시 서비스가 IPv6을 명시적으로 지원하는지 확인합니다. 지원하지 않는 경우 IPv4/IPv6을 완전히 커버할 수 있는 프록시 솔루션을 사용하거나, 시스템 네트워크 계층에서 보호되지 않은 IPv6 경로를 비활성화합니다.
- 환경을 편집하고
Fingerprint → WebRTC에서 Private을 선택합니다. - "프록시 네트워크 오류 시 환경 열지 않기"를 활성화합니다.
- 프록시 우회 목록을 확인하고 테스트 사이트와 관련된 예외 도메인을 삭제합니다.
- 환경을 다시 열고 재테스트하여 실제 IPv6이 더 이상 나타나지 않는지 확인합니다.
이 시나리오에서는 WebRTC 모드만 변경하면 테스트 결과를 일시적으로 제거할 수 있지만, 프록시의 IPv6 커버리지가 여전히 근본적인 문제이므로 두 가지를 모두 확인해야 합니다.
MostLogin 사용 예시: 테스트 페이지에 .local이 나타나지만 공용 IP가 프록시와 일치
시나리오
사용자가 영국 프록시를 사용하고 있고, 일반 IP와 WebRTC 공용 주소 모두 영국을 표시합니다. 테스트 페이지에 무작위 문자열 끝에 .local이 추가로 나열되어 유출로 오인했습니다.
판단
.local은 일반적으로 브라우저가 mDNS 이름을 사용하여 로컬 네트워크 주소를 숨기는 현상입니다. 실제 ISP 공용 IPv4/IPv6이 나타나지 않고 공용 후보가 영국 프록시와 일치한다면, .local만으로 실제 IP 유출을 판단할 수 없습니다.
처리
현재 Private 설정을 유지하고, 결과를 기록한 후 다른 테스트 페이지로 교차 검증하면 됩니다. 이 시점에서 프록시를 자주 변경하거나, 핑거프린트를 무작위화하거나, 환경을 재구축하면 오히려 안정적이어야 할 테스트 환경에 더 많은 변화를 일으킬 수 있습니다.
MostLogin 사용 예시: WebRTC 비활성화 후 화상 회의 연결 불가
시나리오
원격 지원 팀이 WebRTC를 Disabled로 설정한 후, 웹 고객 상담 통화 및 화면 공유에서 연결이 수립되지 않았습니다.
처리
환경을 Private으로 변경하고 프록시가 정상적으로 연결된 상태를 유지한 다음 WebRTC 주소를 재테스트합니다. 실제 IP가 더 이상 나타나지 않고 오디오/비디오가 복구된다면, 기능과 네트워크 격리를 동시에 확보할 수 있습니다. Private 모드에서도 유출이 계속된다면, 통화를 복구하기 위해 직접 Public을 선택하기 전에 프록시 프로토콜, IPv6, VPN 분할 및 우회 도메인을 확인해야 합니다.
수정 후에도 유출이 계속되는 경우, 원인은 어디에?
MostLogin이 Private로 설정되었는데도 테스트에서 실제 공용 IP가 표시된다면, 다음 순서로 계속 확인할 수 있습니다:
- 프록시가 실제로 연결되지 않음. 자격 증명 오류, 노드 만료 또는 프록시 서버 오프라인 시 브라우저가 예상 출구를 받지 못할 수 있습니다.
- IPv6이 커버되지 않음. 프록시가 IPv4만 처리하고, 호스트는 여전히 실제 IPv6을 통해 네트워크에 접근할 수 있습니다.
- 프록시 우회 규칙. 테스트 사이트 또는 관련 하위 도메인이 직접 연결로 설정되어 있습니다.
- VPN 분할 또는 시스템 라우팅 충돌. VPN, 시스템 프록시 및 환경 프록시를 동시에 사용하면 서로 다른 네트워크 경로가 발생할 수 있습니다.
- 이전 환경 프로세스가 여전히 실행 중. 설정 저장 후 환경을 완전히 닫지 않아 이전 프로세스가 원래 구성을 계속 사용합니다.
- 브라우저 확장 프로그램이 네트워크 행동을 변경. VPN, 프록시, 개인정보 또는 WebRTC 확장 프로그램이 환경 설정과 충돌할 수 있습니다.
- 검사 페이지 오판 또는 캐시. 두 번째 테스트 페이지를 사용하고 환경을 재시작하여 확인하며, 단일 결과를 기준으로 결론을 내리지 마십시오.
두 개의 독립적인 테스트 페이지 모두 동일한 실제 공용 주소를 안정적으로 표시한다면, 민감한 자격 증명을 포함하지 않은 스크린샷, MostLogin 버전, 운영 체제, 프록시 프로토콜 및 재현 단계를 저장한 후 MostLogin 지원팀 또는 프록시 서비스 제공업체에 문의하십시오.
WebRTC 유출 방지 체크리스트
각 새 환경의 첫 사용, 프록시 교체, 클라이언트 업데이트 또는 네트워크 전환 후에 다음 검사를 한 번 실행합니다:
자주 묻는 질문
WebRTC 테스트에서 여러 IP가 표시되면 반드시 유출인가?
반드시 그렇지는 않습니다. 여러 결과는 IPv4, IPv6, LAN 인터페이스, STUN 매핑, TURN 중계 또는 mDNS에서 각각 올 수 있습니다. 실제 ISP 공용 IP, 관련 없는 네트워크 출구 또는 프록시 위치와 명백히 충돌하는 공용 주소가 나타날 때만 고위험 유출로 간주해야 합니다.
프록시 사용 후 WebRTC는 어떤 IP를 표시해야 하는가?
이상적으로는 웹페이지가 실제 ISP 공용 IP를 볼 수 없어야 합니다. 브라우저 및 제품 정책에 따라 테스트 페이지는 프록시 주소, 중계 주소, 숨겨진 로컬 후보를 표시하거나 사용 가능한 주소를 표시하지 않을 수 있습니다. 판단 기준은 "단 하나의 IP만 나타나야 한다"가 아니라 "격리되어야 할 실제 공용 출구가 나타나서는 안 된다"입니다.
MostLogin에서 Private과 Disabled 중 무엇을 선택해야 하는가?
웹 오디오/비디오, 고객 상담 통화 또는 화면 공유가 필요한 경우 Private을 우선 선택하고 재테스트합니다. WebRTC 기능을 전혀 사용하지 않는 경우 Disabled를 선택할 수 있습니다. Disabled는 웹사이트 기능에 영향을 줄 수 있으므로 모든 환경의 기본 최적해는 아닙니다.
WebRTC 유출로 실제 이름과 정확한 주소가 노출될 수 있는가?
일반적으로 IP만으로 실제 이름이나 정확한 주소를 직접 얻을 수는 없지만, 공용 IP는 대략적인 지역과 사업자를 알 수 있으며, 계정, Cookie, 브라우저 핑거프린트 및 행동 기록과 결합하여 더 강력한 연관 단서를 형성할 수 있습니다.
한 번 유출이 발생한 후 설정 수정만으로 충분한가?
수정은 이후 노출을 막을 수 있지만, 웹사이트가 이미 받은 데이터를 철회할 수는 없습니다. 중요한 비즈니스의 경우 유출 발생 시점, 영향을 받은 환경 및 로그인 기록을 확인해야 합니다. 필요한 경우 이전 세션을 종료하고 자격 증명을 업데이트하며, 플랫폼에서 비정상적인 인증이 나타나는지 관찰해야 합니다.
요약
WebRTC 유출의 핵심은 "WebRTC가 활성화되어 있는지"가 아니라, 현재 프록시 환경과 일치하지 않는 실제 공용 주소를 노출하는지 여부입니다. 이상 징후를 발견한 후 먼저 민감한 조작을 일시 중단한 다음, 실제 IP, 프록시 IP 및 WebRTC IP 세 그룹의 데이터로 대조 검사를 완료해야 합니다. MostLogin 사용자는 일반적으로 프록시 연결 확인, WebRTC Private 선택, 프록시 장애 보호 활성화, 불필요한 프록시 우회 규칙 정리 및 IPv6 경로 검증을 통해 문제를 해결할 수 있습니다.
WebRTC 검사를 새 환경 출시 전 고정 프로세스에 포함시키는 것이 계정 이상 발생 후 대처하는 것보다 더 신뢰할 수 있습니다. 프록시, 네트워크 또는 클라이언트 버전을 변경할 때마다 재테스트해야 네트워크 출구와 브라우저 핑거프린트가 장기적으로 일관되게 유지됩니다.
