Configuración automática de proxy a través de WPAD

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org

Licencia Creative Commons
© 1999-2026 Joel Barrios Dueñas. Este manual se distribuye bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Usted es libre de compartir y adaptar el material bajo los siguientes términos: debe dar crédito al autor, no puede utilizarlo para fines comerciales y debe compartir las obras derivadas bajo la misma licencia. La licencia completa está disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.es.

Introducción

Este documento requiere haber estudiado y comprendido previamente los documentos titulados «Configuración de servidor DHCP» y «Configuración de Squid: Opciones básicas». La implementación de WPAD es un componente clave para desplegar una política de seguridad de lista blanca efectiva en la red corporativa.

¿Qué es WPAD?

WPAD (Protocolo de Descubrimiento Automático de Proxy Web) es un método que permite a los clientes de un servidor intermediario (proxy) localizar de forma automática la URI de un archivo de configuración, valiéndose de métodos de descubrimiento a través de DHCP y DNS.

Los clientes descargan y ejecutan un archivo, que debe denominarse wpad.dat, utilizando el formato de auto-configuración de proxy (PAC, Proxy Auto-Config).

El borrador del protocolo WPAD, el cual expiró en 1999, fue elaborado por un consorcio de empresas. A pesar de tratarse de un borrador que ha expirado, la mayoría de los navegadores modernos incluyen soporte para este protocolo.

El anuncio del archivo wpad.dat hacia la red de área local sólo puede hacerse a través de uno de los dos siguientes métodos:

Se puede utilizar indistintamente uno u otro método. Jamás combine ambos métodos porque los anuncios serían ignorados por los navegadores. El método más estándar es el anuncio a través de un servidor DHCP. Ambos métodos requieren añadir registros en zonas de reenvío estáticas o dinámicas del servidor de DNS utilizado por la red de área local.

¿Por qué utilizar WPAD?

Gracias a que una gran cantidad de sitios de Internet ahora funcionan a través de HTTPS, resulta poco práctico configurar servidores intermediarios (proxies) en modo transparente, pues éstos solo permiten el modo transparente para el protocolo HTTP (puerto 80/TCP), obligando a los administradores de redes de área local a configurar la salida del protocolo HTTPS (puerto 443/TCP) a través de NAT en el muro cortafuegos.

Una forma de enfrentar el problema y poder controlar y filtrar la actividad de los usuarios a través de HTTPS, es olvidarse del modo transparente de Squid y utilizar una configuración manual del servidor proxy. Sin embargo, ésto representaría una enorme cantidad de trabajo para los administradores de redes de área local, quienes tendrían que pasar anfitrión por anfitrión a realizar la configuración. Ésta, sin embargo, se puede automatizar anunciándola a través de servidores DHCP y servidores DNS, utilizando WPAD.

Eliminar la configuración de proxy en modo trasparente y utilizar en su lugar el método descrito en este documento, combinado con una configuración del proxy-cache que permita el acceso hacia Internet utilizando sólo una lista blanca y el cierre de la salida por NAT hacia el puerto 443, permite también bloquear de manera eficiente programas de elusión como Ultrasurf y Your Freedom. Si además se cierra la salida hacia el puerto 22/TCP y la salida hacia los puertos 53/UDP y 53/TCP, también se puede bloquear con éxito a programas como Tor Browser.

Nota de Seguridad (Contexto de Filosofía de Defensa): Esta configuración es fundamental para implementar una política de "lista blanca" estricta. Al deshabilitar el proxy transparente y forzar a todos los clientes a usar WPAD, se garantiza que el tráfico HTTPS (puerto 443) pase obligatoriamente por Squid para su inspección y filtrado, cerrando una ruta de evasión crítica para aplicaciones de elusión y malware.

Equipamiento lógico necesario

Puede utilizar Apache o Nginx como servidor web para alojar el archivo wpad.dat. Elija e instale uno de los dos.

Instalación de Apache

yum -y install httpd

o

dnf -y install httpd

Instalación de Nginx

yum -y install nginx

o

dnf -y install nginx

Inicie el servicio elegido (httpd o nginx) y configúrelo para que inicie con el sistema.

Ajustes en el muro cortafuegos

Es necesario abrir en el muro cortafuegos el puerto 80 por TCP (HTTP) y, de manera recomendada, el puerto 443 (HTTPS) para la red de área local. Se asume que ya están abiertos los puertos correspondientes al resto de los servicios involucrados.

Importante: Para que WPAD funcione con la filosofía de lista blanca, es imperativo bloquear en el cortafuegos la salida directa desde la LAN hacia los puertos 80/HTTP y 443/HTTPS en Internet. Esto fuerza a todos los navegadores a utilizar el proxy configurado via WPAD, impidiendo que el tráfico evada los filtros de contenido.

Firewalld

Utilice reglas de lenguaje enriquecido para una configuración específica. Los siguientes ejemplos asumen que la red local es 192.168.100.0/24.

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.100.0/24 destination address=0.0.0.0/0 port port=80 protocol=tcp reject'
firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.100.0/24 destination address=0.0.0.0/0 port port=443 protocol=tcp reject'
# Añada reglas similares para los puertos 20, 21, 22, 53/tcp y 53/udp si es su política.
firewall-cmd --reload

Para permitir el acceso al servidor web local (WPAD) desde la LAN, añada:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

Procedimientos

Este documento asume que se tiene configurado un servidor proxy-cache con Squid. Por favor, cambie todos los valores de ejemplo por aquellos que correspondan al escenario de su red de área local. Se utiliza el bloque de red unificado 192.168.100.0/24 para los ejemplos, con el servidor en la IP 192.168.100.2.

Resolución del nombre de anfitrión

Es imprescindible que el nombre wpad (y su FQDN, por ejemplo, wpad.red-local.net) esté correctamente resuelto en DNS para todos los clientes de la red. Esto puede configurarse en un servidor DNS local como DNSMasq o BIND.

Añada también la resolución local en /etc/hosts del servidor:

vim /etc/hosts
127.0.0.1   localhost localhost.localdomain
192.168.100.2   servidor.red-local.net servidor wpad.red-local.net wpad

Generar y personalizar el archivo wpad.dat

Cree el directorio y el archivo wpad.dat con el contenido mínimo necesario. Este archivo PAC define que los hosts en la red local (192.168.100.0/24) y los nombres de dominio .red-local.net se accedan directamente, mientras que todo el otro tráfico se dirija al proxy.

mkdir -m 0755 -p /var/www/wpad
cat > /var/www/wpad/wpad.dat << 'EOF'
function FindProxyForURL(url, host)
{
        if (
            isInNet(host, "192.168.100.0",  "255.255.255.0")
        ||  isInNet(host, "127.0.0.0", "255.0.0.0")
        ||  shExpMatch(host, "192.168.100.*")
        ||  shExpMatch(host, "127.*" )
        ||  shExpMatch(host, "localhost")
        ||  shExpMatch(host, "*.red-local.net")
        ||  isPlainHostName(host)
        ||  dnsDomainIs(host, ".red-local.net")
        ) {
            return "DIRECT";
          }
        else
          {
            return "PROXY servidor.red-local.net:8080";
          }
}
EOF
chmod a+r /var/www/wpad/wpad.dat

Si su configuración es diferente (por ejemplo, otra red, otro puerto del proxy o un nombre de servidor distinto), edite el archivo /var/www/wpad/wpad.dat y ajuste las direcciones de red, el nombre del proxy y el puerto según corresponda.

Anuncio del archivo wpad.dat (Selección del método)

Puede elegir uno de los siguientes métodos para anunciar el archivo wpad.dat en su red. Jamás combine más de uno, ya que podría causar conflictos en los clientes.

1. A través de un servidor DHCP (ISC dhcpd)

El método clásico y ampliamente compatible. Requiere configurar la opción 252 en el servidor DHCP.

2. A través de un servidor DNS (BIND)

Configurando registros A y TXT en la zona DNS de la red local. Es funcional pero puede ser más complejo de mantener.

3. A través de DNSMasq (Método integrado recomendado)

DNSMasq es una excelente alternativa que simplifica enormemente el despliegue, al integrar un servidor DNS ligero con capacidades básicas de DHCP en una sola configuración. Es ideal para redes pequeñas y medianas donde se busca simplicidad y eficacia.

Configuración de DNSMasq para WPAD

Si aún no tiene DNSMasq instalado, hágalo con su gestor de paquetes:

yum -y install dnsmasq

o

dnf -y install dnsmasq

Edite el archivo de configuración principal (/etc/dnsmasq.conf) y añada las siguientes líneas al final, adaptando los valores a su red:

# --- Configuración para WPAD ---
# Dirección IP del servidor y dominio local
address=/wpad.red-local.net/192.168.100.2
local=/red-local.net/

# Configuración del servidor DHCP integrado
dhcp-range=192.168.100.50,192.168.100.150,255.255.255.0,12h
dhcp-option=option:router,192.168.100.1
dhcp-option=option:dns-server,192.168.100.2

# Anuncio de WPAD a través de DHCP (Opción 252). USE HTTPS.
dhcp-option=252,"https://wpad.red-local.net/wpad.dat"

# Anuncio de WPAD a través de DNS (Registro TXT)
txt-record=wpad.red-local.net,"service: wpad:!https://wpad.red-local.net/wpad.dat"

Nota sobre el servicio DHCP: Las líneas dhcp-range y dhcp-option activan el servidor DHCP de DNSMasq. Si ya tiene un servidor DHCP en su red, no debe activar esta sección para evitar conflictos. En ese caso, use solo las líneas address= y txt-record= para el anuncio vía DNS.

Guarde el archivo, habilite e inicie el servicio:

Configuración del servidor web

Elija entre Apache o Nginx para servir el archivo wpad.dat. Es crucial que el servidor web asocie la extensión .dat con el tipo MIME application/x-ns-proxy-autoconfig para que los navegadores interpreten correctamente el archivo.

Configuración de Apache

Cree el archivo de configuración /etc/httpd/conf.d/wpad.conf:

<VirtualHost *:80>
    ServerName wpad.red-local.net
    ServerAlias wpad
    DocumentRoot /var/www/wpad
    ErrorLog logs/wpad-error_log
    CustomLog logs/wpad-access_log combined
    <Directory "/var/www/wpad">
        AddType application/x-ns-proxy-autoconfig .dat
        DirectoryIndex wpad.dat
        Require ip 192.168.100.0/24
    </Directory>
</VirtualHost>

<VirtualHost *:443>
    ServerName wpad.red-local.net
    ServerAlias wpad
    DocumentRoot /var/www/wpad
    ErrorLog logs/wpad-ssl-error_log
    CustomLog logs/wpad-ssl-access_log combined

    SSLEngine on
    SSLCertificateFile /ruta/a/certificado.crt
    SSLCertificateKeyFile /ruta/a/clave.key

    <Directory "/var/www/wpad">
        AddType application/x-ns-proxy-autoconfig .dat
        DirectoryIndex wpad.dat
        Require ip 192.168.100.0/24
    </Directory>
</VirtualHost>

Recargue Apache:

systemctl reload httpd   # SystemD
# o
service httpd reload     # SysVinit

Configuración de Nginx

Nginx es un servidor web de alto rendimiento que también puede actuar eficientemente como proxy inverso. Para configuraciones más avanzadas de Nginx, puede consultar el Manual de Nginx en Alcance Libre.

Cree el archivo de configuración /etc/nginx/conf.d/wpad.conf:

# Servidor HTTP para WPAD
server {
    listen 192.168.100.2:80;
    server_name wpad.red-local.net wpad;
    root /var/www/wpad;
    access_log /var/log/nginx/wpad-access.log;
    error_log /var/log/nginx/wpad-error.log notice;
    charset UTF-8;
    location / {
        default_type application/x-ns-proxy-autoconfig;
        index wpad.dat;
    }
}

# Servidor HTTPS para WPAD (Recomendado)
server {
    listen 192.168.100.2:443 ssl http2;
    server_name wpad.red-local.net wpad;
    root /var/www/wpad;
    access_log /var/log/nginx/wpad-ssl-access.log;
    error_log /var/log/nginx/wpad-ssl-error.log notice;
    charset UTF-8;

    ssl_certificate /ruta/a/certificado.crt;
    ssl_certificate_key /ruta/a/clave.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        default_type application/x-ns-proxy-autoconfig;
        index wpad.dat;
    }
}

Verifique la sintaxis y recargue Nginx:

nginx -t
systemctl reload nginx   # SystemD
# o
service nginx reload     # SysVinit

📜 Generación y Uso de Certificados SSL/TLS

Para que HTTPS funcione, necesita un certificado válido para el nombre wpad.red-local.net.

1. Certificado Wildcard de Let's Encrypt (Recomendado para producción)

Un certificado comodín (*.red-local.net) es ideal porque es válido para wpad.red-local.net y cualquier otro servicio en su dominio, es gratuito y es reconocido como de confianza por la mayoría de los sistemas.

Requisito previo: Debe poder probar la propiedad de su dominio mediante un registro TXT en su DNS público. Para una configuración interna segura, la validación por DNS es la más adecuada.

El proceso general con Certbot es:

# 1. Instalar certbot y el complemento para validación DNS
dnf -y install certbot python3-certbot-dns-cloudflare

# 2. Generar el certificado (Ejemplo para validación DNS)
certbot certonly --manual --preferred-challenges=dns \
  -d '*.red-local.net' -d 'red-local.net' \
  --server https://acme-v02.api.letsencrypt.org/directory

Certbot le pedirá que añada un registro TXT específico en su DNS público. Una vez hecho, emitirá los certificados. Para la renovación automática, puede usar certbot renew.

Consulte el Manual de Nginx en Alcance Libre para ver ejemplos detallados de configuración de Certbot con validación DNS para obtener un certificado wildcard.

2. Certificado Autofirmado (Rápido para pruebas/entornos aislados)

Para laboratorios o redes completamente aisladas, puede generar su propio certificado. La gran desventaja es que todos los clientes mostrarán una advertencia de seguridad a menos que importen y confíen en su Autoridad Certificadora (CA) raíz autofirmada.

Generación del certificado:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/wpad.red-local.net.key \
  -out /etc/ssl/certs/wpad.red-local.net.crt \
  -subj "/C=MX/ST=Estado/L=Ciudad/O=Empresa/CN=wpad.red-local.net"

Luego, apunte las directivas ssl_certificate (Nginx) o SSLCertificateFile (Apache) a los archivos .crt y .key generados.

3. Consideraciones Especiales para Clientes macOS

Los sistemas macOS, siguiendo las decisiones de diseño de Apple para aumentar la seguridad por defecto, presentan dificultades adicionales con certificados autofirmados o de una CA privada. El proceso para confiar en dichos certificados es más estricto y manual que en otros sistemas operativos. En entornos empresariales, la forma práctica es a través de Perfiles de Configuración distribuidos con una solución de MDM, lo que añade complejidad.

Conclusión práctica: En una red heterogénea con clientes macOS, el esfuerzo para desplegar y mantener la confianza en una CA privada puede ser significativo. Esto convierte a la opción de un certificado válido públicamente (como Let's Encrypt) en la más atractiva, incluso para servicios internos.

🔐 Consideraciones de Seguridad: La vulnerabilidad WPAD y HTTPS

La implementación original de WPAD presenta una vulnerabilidad crítica que no es un defecto de un sistema operativo en particular, sino una debilidad inherente al diseño del protocolo/estándar WPAD y a su interacción con mecanismos de resolución de nombres.

Naturaleza de la vulnerabilidad (Ataque WPAD/LNR)

El núcleo del problema reside en el algoritmo de descubrimiento. Cuando un cliente busca el archivo de configuración, intenta resolver el nombre de host wpad. Si este nombre no está definido en el dominio local, algunos sistemas podían escalar la búsqueda eliminando sucesivamente subdominios, pudiendo confiar en respuestas de servidores DNS maliciosos dentro de la red.

Este ataque, a veces referido como WPAD Name Resolution (LNR) Poisoning, permite al atacante suplantar el servidor WPAD y redirigir todo el tráfico web a través de un servidor intermediario bajo su control, realizando un ataque "Man-in-the-Middle" (MitM) completo.

Mitigación: Estrategia de Defensa en Profundidad

  1. HTTPS Obligatorio: Servir el archivo wpad.dat exclusivamente a través de HTTPS es la barrera principal. El certificado SSL/TLS autentica el servidor legítimo.
  2. Registros DNS Explícitos y Restrictivos: Definir registros A y TXT explícitos para wpad.red-local.net en el DNS local autoritativo cierra la puerta a la búsqueda escalonada.
  3. Segmentación y Monitoreo de Red: Aplicar listas de control de acceso (ACL) en switches para limitar quién puede ofrecer servicios DHCP/DNS.

Conclusión operativa: En entornos corporativos, la configuración de WPAD sobre HTTP debe considerarse obsoleta e insegura. La implementación con HTTPS y registros DNS explícitos es un requisito fundamental para convertir a WPAD en una herramienta de gestión segura dentro de su arquitectura de defensa en profundidad.

Comprobaciones

Para verificar que WPAD funciona correctamente, puede realizar pruebas desde un cliente dentro de la red.

1. Verificación con curl (Herramienta de diagnóstico esencial)

a) Verificación de DNS y conectividad básica (HTTP):

curl -I http://wpad.red-local.net/wpad.dat

Salida exitosa esperada (Ejemplo con Nginx):

HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Mon, 23 Oct 2023 14:30:00 GMT
Content-Type: application/x-ns-proxy-autoconfig
Content-Length: 1245
Last-Modified: Sun, 22 Oct 2023 10:15:00 GMT
Connection: keep-alive
ETag: "6347-56781234abcd"
Accept-Ranges: bytes

b) Diagnóstico de HTTPS:

Síntoma en curl Diagnóstico Área a Verificar
curl: (6) Could not resolve host Fallo de DNS. Configuración de DNSMasq/BIND.
curl: (7) Failed to connect... Connection refused Servicio no escuchando. Estado de Nginx/Apache. Cortafuegos.
curl: (60) SSL certificate problem Certificado no confiable. Validez del certificado (Let's Encrypt recomendado).
HTTP/2 200 con Content-Type: application/x-ns-proxy-autoconfig ✅ CONFIGURACIÓN CORRECTA. -

2. Prueba desde un navegador web

Acceda a https://wpad.red-local.net/wpad.dat. El navegador debe descargar automáticamente el archivo.

3. Verificación de la configuración en el cliente

Consideraciones finales de seguridad

La implementación de WPAD sobre HTTPS, utilizando un certificado gestionable (idealmente de Let's Encrypt), es la única manera de implementar este protocolo de forma segura en la era moderna. Mitiga el ataque histórico de envenenamiento LNR, se integra sin problemas con la filosofía de lista blanca y simplifica la administración en entornos con sistemas operativos diversos.

Bibliografía