WPAD 프로토콜: 네트워크에서 프록시 자동 감지

```html

회사에 수십 또는 수백 대의 장치가 있는 경우 각 장치에 프록시를 수동으로 설정하는 것은 현실적이지 않습니다. 바로 이 때문에 WPAD(Web Proxy Auto-Discovery)가 존재합니다. 이 프로토콜은 브라우저와 애플리케이션이 사용자 개입 없이 자동으로 프록시 서버 설정을 찾을 수 있게 해줍니다. 이 프로토콜이 어떻게 작동하는지, 올바르게 설정하는 방법, 피해야 할 오류에 대해 알아보겠습니다.

WPAD란 무엇이며 왜 필요한가

WPAD는 Web Proxy Auto-Discovery Protocol의 약자로, 웹 프록시 자동 탐지 프로토콜입니다. 이 프로토콜의 주요 목적은 클라이언트 장치(노트북, 스마트폰, 워크스테이션)가 시스템 관리자나 사용자의 수동 개입 없이 스스로 프록시 서버 설정을 찾고 적용할 수 있도록 하는 것입니다.

300명의 직원이 있는 기업 네트워크를 상상해 보십시오. 새로운 직원이 채용되거나 프록시 서버 주소가 변경될 때, WPAD가 없다면 관리자는 각 장치를 수동으로 방문하거나 지침을 배포해야 합니다. 그러나 WPAD가 있으면 모든 것이 자동으로 진행됩니다. 장치가 네트워크에 연결되면 구성 요청을 하고 즉시 필요한 프록시를 통해 작동을 시작합니다.

이 프로토콜은 1990년대 후반 Netscape와 Sun Microsystems에 의해 개발되었습니다. 나이가 많음에도 불구하고 여전히 전 세계 기업 IT 인프라에서 널리 사용되고 있으며, 특히 인터넷 트래픽의 중앙 집중식 제어, 콘텐츠 필터링 또는 기업 게이트를 통한 요청 라우팅이 필요한 경우에 그렇습니다.

WPAD가 실제로 필요한 경우:

20대 이상의 장치가 하나의 프록시에 연결되어 있는 경우
프록시 서버 주소가 주기적으로 변경되는 경우
직원들이 다양한 위치(사무실, 지사, 원격)에서 연결되는 경우
다양한 유형의 트래픽에 대해 서로 다른 프록시를 적용해야 하는 경우
사용자의 개입 없이 중앙 집중식 관리가 필요한 경우

기술적으로 WPAD는 PAC(Proxy Auto-Config) 파일과 함께 작동하며, 이 파일에는 프록시 선택 로직을 포함하는 JavaScript 함수가 있습니다. WPAD는 이 파일을 클라이언트 장치에 전달하는 메커니즘이며, PAC는 실제 규칙 세트입니다. 두 구성 요소를 이해하는 것은 올바른 설정을 위해 매우 중요합니다.

WPAD 작동 방식: 단계별 탐지 메커니즘

WPAD가 활성화된 장치가 네트워크에 연결되면 자동 프록시 탐지 절차를 시작합니다. 이 과정은 엄격하게 표준화되어 있으며 특정 순서로 진행됩니다. 이 순서를 이해하면 인프라를 올바르게 설정하고 문제를 신속하게 진단하는 데 도움이 됩니다.

1단계: DHCP를 통한 요청 (옵션 252)

첫 번째로 장치는 옵션 252(wpad)를 사용하여 DHCP 요청을 보냅니다. DHCP 서버가 WPAD를 지원하도록 설정되어 있다면, PAC 파일의 URL을 응답으로 반환합니다. 예를 들어, http://wpad.company.local/wpad.dat와 같은 형식입니다. 이는 IP 주소를 받는 단계에서 발생하므로 가장 빠르고 신뢰할 수 있는 구성 전달 방법입니다.

2단계: "wpad" 호스트에 대한 DNS 요청

DHCP가 URL을 반환하지 않았다면, 장치는 현재 도메인에서 wpad라는 이름을 해석하기 위해 DNS 서버에 요청합니다. 장치가 company.local 도메인에 있다면, DNS 요청은 wpad.company.local로 이루어집니다. 성공적으로 해석되면 장치는 http://wpad.company.local/wpad.dat 주소로 접근합니다.

3단계: PAC 파일 다운로드 및 적용

URL을 받은 후, 브라우저나 애플리케이션은 HTTP를 통해 PAC 파일을 다운로드합니다. 이 파일에는 각 요청에 대해 프록시를 사용할지, 직접 연결할지, 서버 목록을 순회할지를 반환하는 JavaScript 함수 FindProxyForURL(url, host)가 포함되어 있습니다. 클라이언트는 이 파일을 캐시하고 트래픽 라우팅에 적용합니다.

중요한 점은 WPAD 탐지가 처음 연결할 때만 발생하는 것이 아니라 주기적으로 반복된다는 것입니다. 브라우저는 일반적으로 매번 시작할 때마다 PAC 파일을 다시 로드하거나 특정 간격으로 업데이트합니다. 이는 프록시 설정이 변경될 경우 PAC 파일을 서버에서 업데이트하는 것만으로 모든 장치가 자동으로 변경 사항을 반영하게 됨을 의미합니다.

탐지 단계	방법	우선 순위	요구 사항
DHCP 옵션 252	URL 직접 전달	1 (최고)	구성된 DHCP 서버
DNS wpad.*	호스트 이름 해석	2	DNS에서 wpad의 A 레코드
수동 PAC URL	명시적 설정	수동	각 장치에서 설정

PAC 파일: WPAD 구성의 핵심

PAC 파일(Proxy Auto-Configuration)은 필수 함수 FindProxyForURL(url, host)를 포함하는 JavaScript 파일입니다. 브라우저나 애플리케이션이 연결을 설정하려고 할 때마다 이 함수를 호출하여 어떤 프록시를 사용할지 또는 직접 연결할지를 지시받습니다.

이 함수는 두 개의 매개변수를 받습니다: 요청된 리소스의 전체 URL과 호스트 이름입니다. 이 데이터를 기반으로 세 가지 유형의 지시문 중 하나를 반환합니다:

DIRECT — 직접 연결, 프록시 없이
PROXY host:port — 지정된 HTTP 프록시 사용
SOCKS host:port 또는 SOCKS5 host:port — SOCKS 프록시 사용

기업 네트워크를 위한 간단한 PAC 파일의 예:

function FindProxyForURL(url, host) {

  // 로컬 주소 — 직접 연결
  if (isPlainHostName(host) ||
      shExpMatch(host, "*.company.local") ||
      isInNet(host, "192.168.0.0", "255.255.0.0")) {
    return "DIRECT";
  }

  // 내부 서비스 — 직접 연결
  if (shExpMatch(host, "*.internal.company.com")) {
    return "DIRECT";
  }

  // 나머지 모든 트래픽 — 기업 프록시를 통해
  return "PROXY proxy.company.local:8080; DIRECT";
}

PROXY proxy.company.local:8080; DIRECT 구조에 주목하세요. 이는 폴백 체인입니다. 기본 프록시가 사용할 수 없는 경우, 브라우저는 자동으로 직접 연결로 전환됩니다. 부하 분산이나 백업을 위해 세미콜론으로 여러 프록시 서버를 지정할 수 있습니다.

PAC 파일은 올바른 MIME 유형으로 웹 서버에서 제공되어야 합니다: application/x-ns-proxy-autoconfig. 일부 브라우저는 text/plain도 수용하지만, 이는 권장되지 않습니다. 파일은 일반적으로 wpad.dat 또는 proxy.pac라고 불리며, 웹 서버의 루트에 배치됩니다.

복잡한 시나리오를 위한 유용한 PAC 기능:

isInNet(host, pattern, mask) — 서브넷 마스크에 대한 IP 주소 확인
shExpMatch(str, pattern) — 패턴과 비교 (와일드카드)
dnsDomainIs(host, domain) — 도메인 소속 확인
myIpAddress() — 클라이언트의 IP 주소 가져오기 (다양한 사무실용)
weekdayRange() / timeRange() — 일정에 따른 라우팅

DHCP 및 DNS를 통한 WPAD 설정

기업 네트워크에서 WPAD를 배포하는 두 가지 주요 방법이 있습니다: DHCP를 통한 방법과 DNS를 통한 방법입니다. 실제로는 두 가지 모두 설정하는 것이 좋습니다 — DHCP를 우선 방법으로, DNS를 백업 방법으로 설정합니다. 각 접근 방식을 자세히 살펴보겠습니다.

DHCP를 통한 설정 (옵션 252)

DHCP 서버에 PAC 파일의 URL 값을 가진 옵션 252(WPAD)를 추가해야 합니다. Windows Server(역할 DHCP)의 경우:

DHCP 서버 관리 콘솔을 엽니다.
Server Options 또는 Scope Options 섹션으로 이동합니다.
Configure Options → Advanced를 클릭합니다.
Vendor class: Microsoft Windows 2000 Options를 선택합니다.
옵션 252(WPAD)를 찾아 URL을 입력합니다: http://wpad.company.local/wpad.dat
변경 사항을 저장합니다 — 새로운 DHCP 클라이언트는 자동으로 설정을 받습니다.

ISC DHCP Server가 있는 Linux 시스템의 경우 구성 파일에 다음을 추가합니다:

# /etc/dhcp/dhcpd.conf
option wpad code 252 = text;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.200;
  option routers 192.168.1.1;
  option wpad "http://wpad.company.local/wpad.dat\000";
}

DNS를 통한 설정

DNS 방법의 경우, PAC 파일을 제공하는 웹 서버의 IP 주소를 가리키는 wpad라는 이름의 A 레코드를 내부 DNS 도메인에 생성해야 합니다.

DNS 관리자 콘솔(Windows)을 열거나 존 파일(BIND)을 편집합니다.
company.local 존에 A 레코드를 생성합니다: wpad → 192.168.1.50
192.168.1.50 서버에 웹 서버(IIS, Apache, Nginx)를 배포합니다.
wpad.dat 파일을 사이트의 루트에 배치합니다.
.dat 확장자에 대한 MIME 유형을 설정합니다: application/x-ns-proxy-autoconfig
접근 가능성을 확인합니다: 브라우저에서 http://wpad.company.local/wpad.dat를 엽니다.

⚠️ Windows Server DNS에 대한 중요 사항:

기본적으로 Windows Server DNS는 보안상의 이유로 "wpad"라는 이름의 A 레코드 생성을 차단합니다(워드 공격 방지). 생성을 허용하려면 PowerShell에서 다음을 실행합니다: dnscmd /config /enableglobalqueryblocklist 0 또는 DNS의 글로벌 차단 목록에서 "wpad"를 제거합니다.

PAC 파일 제공을 위한 Nginx 웹 서버 설정

# /etc/nginx/sites-available/wpad
server {
    listen 80;
    server_name wpad.company.local;
    root /var/www/wpad;

    location /wpad.dat {
        default_type application/x-ns-proxy-autoconfig;
        add_header Cache-Control "max-age=3600";
    }

    location /proxy.pac {
        default_type application/x-ns-proxy-autoconfig;
        add_header Cache-Control "max-age=3600";
    }
}

WPAD의 취약점 및 보안 위험

WPAD는 편리한 관리와 심각한 보안 위험이 함께하는 프로토콜 중 하나입니다. 이러한 위험을 이해하는 것은 기업 네트워크에서 작업하는 모든 IT 전문가에게 매우 중요합니다. 여러 공격 클래스가 WPAD를 트래픽 가로채기의 벡터로 사용합니다.

WPAD 이름 탈취

장치가 합법적인 WPAD 서버가 없는 네트워크에 연결되면, 공격자가 가짜 DNS 서버를 배포하거나 DHCP 요청에 응답하면, 피해자에게 악성 PAC 파일을 제공할 수 있습니다. 모든 HTTP 요청은 공격자의 프록시를 통해 전달되며, 이는 전형적인 중간자 공격(MITM)입니다. 특히 공공 Wi-Fi 네트워크에서 위험합니다.

WPAD를 통한 DNS 리바인딩

이 공격은 브라우저가 PAC 파일을 신뢰하고 JavaScript를 실행한다는 사실을 이용합니다. 악성 PAC 파일은 dnsResolve() 함수를 사용하여 내부 네트워크를 탐색할 수 있습니다: IP 주소를 순회하고, 열린 포트와 서비스를 식별합니다. 이는 피해자의 브라우저를 기업 인프라 스캐닝 도구로 변환합니다.

공공 네트워크에서의 WPAD

자동 프록시 탐지가 활성화된 장치는 공공 네트워크에서도 WPAD 서버를 계속 찾습니다 — 카페, 공항, 호텔 등. 최상위 도메인에 wpad.com 레코드가 존재하는 경우(이런 사례가 연구자들에 의해 확인되었습니다), 브라우저는 외부 서버에서 PAC 파일을 다운로드할 수 있습니다. 이 때문에 ICANN은 wpad.com 도메인 등록을 차단했습니다.

위협	공격 벡터	보호 조치
가짜 WPAD를 통한 MITM	DHCP/DNS 변조	DHCP 스누핑, DNS 서명
내부 네트워크 탐색	악성 PAC 파일	PAC 무결성 확인
공공 네트워크에서의 데이터 유출	공개 Wi-Fi	사무실 외부에서 WPAD 비활성화
자격 증명 가로채기	프록시 가로채기	HTTPS + HSTS 적용

보호 방법: 실용적인 권장 사항

필요한 곳에서만 WPAD를 활성화하세요 — 기업 장치에서 그룹 정책(GPO)을 통해
PAC 파일 제공에 HTTPS를 사용하세요 — 이는 콘텐츠 변조를 방지합니다
스위치에서 DHCP 스누핑을 설정하세요 — 가짜 DHCP 서버로부터 보호
경계에서 wpad에 대한 DNS 요청을 차단하세요 — 장치가 외부 네트워크에서 WPAD를 찾지 않도록
원격 직원의 경우 WPAD를 비활성화하세요 — 사무실 외부에서 작업할 때 VPN 정책이나 GPO를 통해
wpad.dat에 대한 요청을 모니터링하세요 — 예기치 않은 요청은 공격 신호일 수 있습니다

WPAD 대 수동 설정: 접근 방식 비교

WPAD를 도입하기 전에, 실제로 어떤 상황에서 정당화되는지, 언제 수동 설정이나 그룹 정책으로 대체하는 것이 더 나은지 이해하는 것이 유용합니다. 각 접근 방식은 장점과 한계가 있습니다.

매개변수	WPAD	수동 설정	GPO (그룹 정책)
확장성	✅ 훌륭함	❌ 나쁨	✅ 훌륭함
비윈도우 장치 지원	✅ 예	✅ 예	⚠️ 윈도우만 해당
보안	⚠️ 위험이 존재	✅ 높음	✅ 높음
라우팅 규칙의 유연성	✅ 최대	❌ 없음	⚠️ 제한적
설정 변경 속도	✅ 즉시	❌ 각 PC에서 수동으로	⚠️ 다음 GPO 업데이트 시
기업 네트워크 외부에서의 작동	⚠️ 공공 네트워크에서 위험	✅ 안정적	✅ 안정적

대부분의 기업 환경에 대한 최적의 전략은 혼합 접근 방식입니다: 도메인 내 사무실 장치에 대해 WPAD를 사용하고, 원격 직원의 노트북에 대해서는 수동 설정(GPO 또는 MDM을 통해)을 강제하는 것입니다. 이는 보안에서 타협 없이 관리의 유연성을 제공합니다.

또한, 익명성과 신뢰성이 중요한 작업(예: 외부 서비스 작업 또는 경쟁사 모니터링)에는 WPAD를 통한 기업 프록시만으로는 충분하지 않을 수 있습니다. 이러한 경우, 주거용 프록시를 추가로 사용하는 것이 좋습니다. 이는 실제 가정 사용자 IP 주소를 제공하며 외부 서비스의 차단 위험을 크게 줄입니다.

기업 네트워크를 위한 WPAD 대안

WPAD는 기업 네트워크에서 프록시 설정을 중앙 집중식으로 관리하는 유일한 방법이 아닙니다. 인프라, 회사 규모 및 보안 요구 사항에 따라 다른 접근 방식이 적합할 수 있습니다. 주요 대안을 살펴보겠습니다.

1. GPO를 통한 PAC 파일 직접 배포

Active Directory 환경에서는 그룹 정책을 사용하여 Internet Explorer 및 Edge 브라우저에 PAC 파일의 URL을 강제 설치할 수 있습니다(Internet Explorer Maintenance 또는 Administrative Templates를 통해 설정). 장점은 어떤 장치가 설정을 받을지에 대한 완전한 제어가 가능하며, WPAD 공격의 위험이 없습니다. 단점은 도메인 내 Windows 장치에서만 작동한다는 것입니다.

2. 투명 프록시 (Transparent Proxy)

네트워크 장비(라우터, 방화벽)가 HTTP/HTTPS 트래픽을 가로채고 프록시 서버를 통해 리디렉션합니다. 클라이언트 장치에서 어떤 설정도 필요하지 않습니다. 사용자와 애플리케이션은 프록시의 존재를 전혀 알지 못합니다. 이는 편리하지만 HTTPS 트래픽에 대한 SSL 검사 지원이 필요하며, PKI 인프라에 대한 추가 요구 사항이 발생합니다.

3. 모바일 장치를 위한 MDM 시스템

iOS 및 Android의 스마트폰과 태블릿에 대해 Microsoft Intune, Jamf 또는 VMware Workspace ONE과 같은 모바일 장치 관리(MDM) 시스템은 프록시 설정을 중앙 집중식으로 푸시할 수 있습니다. 이는 기업 네트워크 외부에서 자주 작동하는 모바일 장치에 대해 WPAD보다 더 신뢰할 수 있습니다.

4. 강제 라우팅을 통한 기업 VPN

프록시 서버 대신 원격 직원의 모든 트래픽은 기업 VPN 게이트웨이를 통해 전달됩니다. 게이트웨이에서 필터링 및 트래픽 검사가 적용됩니다. 이 접근 방식은 높은 보안 수준을 제공하지만 VPN 인프라가 필요하며 다른 지역의 사용자에게 지연을 증가시킬 수 있습니다.

기업 인프라를 넘어서는 작업(예: 마케팅 부서가 경쟁사의 가격을 모니터링하거나 다양한 지역에서 광고 캠페인을 테스트하는 경우)에는 기업 도구만으로는 충분하지 않은 경우가 많습니다. 이러한 경우, 데이터 센터 프록시를 사용하여 빠른 파싱 작업을 수행하거나 모바일 프록시를 사용하여 소셜 미디어 및 광고 플랫폼 작업을 수행합니다.

체크리스트: 프록시 관리 접근 방식 선택 방법

✅ 도메인 내 Windows 장치만 → GPO + PAC 파일
✅ 혼합 환경 (Windows + Mac + Linux + 모바일) → WPAD + DHCP
✅ 높은 보안 요구 사항 → 투명 프록시 또는 VPN
✅ 모바일 장치 → MDM (Intune, Jamf)
✅ 원격 직원 → VPN + 강제 라우팅
✅ 외부 서비스, 광고, 파싱 작업 → 외부 프록시 제공업체

결론

WPAD는 기업 네트워크에서 프록시 설정을 중앙 집중식으로 관리하는 강력한 도구입니다. DHCP 및 DNS를 통해 올바르게 설정된 WPAD는 시스템 관리자가 각 장치를 수동으로 구성할 필요를 없애고 전체 인프라에 즉시 변경 사항을 적용할 수 있게 해줍니다. 성공적인 도입의 열쇠는 작동 메커니즘을 이해하고 PAC 파일을 올바르게 구성하며, 보안 조치(예: DHCP 스누핑, PAC 제공을 위한 HTTPS, 네트워크 경계에서 WPAD 요청 차단)를 필수적으로 이행하는 것입니다.

WPAD는 기업 네트워크 내에서 트래픽 라우팅 문제를 해결하지만, 외부 서비스와 작업하기 위한 전문 프록시 솔루션을 대체하지는 않습니다. 팀이 경쟁사 모니터링, 다양한 지역에서 광고 테스트 또는 마켓플레이스 작업을 수행하는 경우, 주거용 프록시를 추가로 고려하는 것이 좋습니다. 이는 실제 가정 사용자 IP 주소를 제공하며 외부 플랫폼의 차단 위험을 최소화합니다.