ADMINISTRACIN Socks v5

El protocolo genrico Socks para proxy versin 5 a examen

CALCETINES PARA EL PROXY

Socks es un protocolo universal de proxy para TCP y UDP que permite a los hosts de una red interna pasar de forma segura por el cortafuego y autentificar a los usuarios. Este artculo describe la ltima versin del protocolo para proxy Socks y muestra cmo se implementa. POR THOMAS KUHN Y ACHIM LEITNER

uchos administradores de cortafuegos permiten acceso directo a la Web desde la red interna pero son ms restrictivos con otros servicios como el FTP o el SMTP. Comentan que las reglas de los filtros que permiten un mnimo de servicios y puertos son ms fciles de manejar y seguir. Los Gateways del nivel de Aplicacin (ALGs) proporcionan control y se implementan como proxies (Figura 1). Sin embargo, la aplicacin del cortafuego necesita un proxy por cada servicio. El protocolo Socks [2] (RFC 1928,

Figura 1b) traza una ruta entre el filtro de paquetes de estado y el ALG. Socks est implementado, por ejemplo, en el paquete Dante [1]. La tecnologa del proxy genrico Socks deja al cortafuego el control de las aplicaciones, redes separadas en la Capa de Transporte y deja a los clientes un puerto de peticiones fijo (tpicamente 1080). Los clientes realizan peticiones al Socks, especificando el tipo de los servidores y servicios (como HTTP, SMTP o FTP). El proxy Socks (tambin conocido como servidor Socks) autentifica los clientes y autoriza el acceso a los clientes, configura la conexin al servidor y de forma transparente reenva cualquier dato enviado o recibido.

Intermediarios
Normalmente, las aplicaciones de los clientes necesitan tener integrados el soporte Socks para permitir el uso del proxy, de forma que Socks utiliza la forma de interactuar del protocolo. Sin embargo, un wrapper puede aadir soporte Socks a binarios utili-

zando la tecnologa LD_PRELOAD. Para hacer esto, el wrapper implementa una librera de socket personalizada. El nombre Socks proviene de Socket, el ttulo original del trabajo fue SOCK-etS. Hay dos versiones principales: Socks v4 y v5. Ambos protocolos se insertan en el modelo OSI entre las capas de Transporte y Aplicacin. La versin 4 est limitada al manejo de solicitudes de conexin, reglas del proxy y reenvo de datos. No proporciona ningn tipo de

62

Nmero 09

WWW.LINUX-MAGAZINE.ES

Socks v5 ADMINISTRACIN

Figura 1a: Si el cortafuegos est implementado como un gateway a nivel de aplicacin, separa la red interna y externa en el nivel de aplicacin. Sin embargo, necesita un proxy para cada protocolo.

cando qu servicio necesita (la direccin de destino DST.ADDR y el puerto DST.PORT). El proxy Socks evala la peticin, basada en la ID del cliente y la direccin de destino, tomando una lista de control de acceso en consideracin al estilo tpico del cortafuegos. Si al cliente no se le permite el acceso por el tipo de peticin, el proxy Socks rechaza la conexin del cliente. En cualquier otro caso, responde con uno o mltiples paquetes de respuestas del servidor.

Direcciones
Las peticiones y respuestas de Socks pueden contener distintos tipos de direcciones. El protocolo soporta direcciones IPv4 e IPv6, junto con nombres de dominios. El ltimo elimina la necesidad del cliente para realizar consultas al DNS y la red interna no necesita resolver nombres externos DNS. Dependiendo del tipo de respuesta del cliente, es decir, dependiendo del valor de CMD (Figura 2 y Tabla 1), los detalles de la direccin en la respuesta del servidor Socks tienen una diferencia significativa. Una respuesta a una peticin CONNECT contiene el BND.PORT y BND.ADDR, esto es la direccin con la que el proxy se ha conectado al servidor de destino. La direccin BND.ADDR normalmente no

Figura 1b: A diferencia de un ALG, Socks asume el papel de un proxy genrico, aceptando conexiones desde cualquier protocolo de aplicacin en el puerto 1080, autenticando clientes y autorizando transferencias.

autentificacin y est restringido para TCP. Socks v5 aade mecanismos de autenticacin robustos y soporte extendido a UDP.

Un Rodeo
En un escenario tpico de Socks, el cliente querr acceder al servicio HTTP proporcionado por un servidor en una red externa. El procedimiento se muestra en la Figura 2, el formato de los datos en la Figura 3 y el contenido de los campos en la Tabla 1. El cliente comienza abriendo la conexin TCP al proxy Socks (1); por defecto la conexin utiliza el puerto 1080. El cliente enva un paquete de

Negociacin sugiriendo unos cuantos mtodos de autenticacin (nmero en NMETHODS y mtodos en METHODS). Si el proxy acepta la peticin (paso 2 en la Figura 2), utiliza un paquete de Negociacin de Servidor para decirle al cliente el mtodo de autenticacin (METHODS con exactamente una entrada). A continuacin, el proxy autentifica al cliente (paso 3). El procedimiento exacto en este paso depende del mtodo seleccionado. En este punto, el cliente enva una peticin al proxy indi-

Listado 1: Servidor Socks

01 02 03 04 05 06 logoutput: syslog #logoutput: stdout 14 15 16 17 18 user.privileged: proxy user.notprivileged: nobody 27 f r o m : 0 . 0 . 0 . 0 / 0 t o : 10.0.0.11/0 28 log: connect error 29 } 30 31 pass { 32 f r o m : 1 0 . 0 . 0 . 3 / 0 t o : 10.0.0.10/0 33 protocol: tcp udp 34 } 35 block { 36 from: 0.0.0.0/0 to: 0.0.0.0/0 37 log: connect error 38 }

internal: eth0 port = 1080 external: eth1 #internal: 10.0.0.11 port = 1080 07 #external: 192.168.23.1 08 09 method: username 10 #method: none 11 #method: rfc931 12 #method: pam 13

client pass { from: 10.0.0.3/0 port 1-65535 to: 0.0.0.0/0 19 } 20 21 client block { 22 from: 0.0.0.0/0 to: 0.0.0.0/0 23 log: connect error 24 } 25 26 block {

WWW.LINUX-MAGAZINE.ES

Nmero 09

63

ADMINISTRACIN Socks v5

Figura 2: Cuando establecemos una conexin Socks v5, el cliente comienza enviando un paquete de negociacin al proxy Socks (1). El cliente se autentifica (3); el proxy establece la conexin con el servidor (6) y reenva los datos (8).

como el cliente necesita para la autenticacin de una conexin TCP.

Autenticando
es la misma que la direccin del servidor Socks, en la cual el cliente enva la respuesta original. Este sistema es conocido como servidor sock multihome, es tpico de un cortafuegos Socks que conecta dos redes. Tras un exitoso comando Connect, el cliente y el servidor pueden comunicarse de forma transparente mediante el proxy; el Socks simplemente reenva cualquier dato. El cliente enva una peticin REQUEST para indicar que espera una conexin entrante desde el servidor. Este escenario podra parecer que es al revs, pero esto es normal en el caso del protocolo FTP en modo activo. Con FTP y siguiendo los tradicionales cliente-servidor, el cliente primero establecer una conexin al servidor FTP; esto se conoce como control de conexin. Si un fichero necesita ser transferido, el servidor establece una conexin de datos tras el cliente. Antes de esto, el cliente necesita decirle al servidor qu direccin y qu puerto del servidor puede utilizar. Esta informacin se enva a travs del canal de control. de la mquina utilizada para abrir la El mtodo de autenticacin tambin conexin. Finalmente, el proxy reenva puede proporcionar confianza e integrilos datos desde el servidor externo al dad entre el cliente y el proxy. La autencliente interno. Si quiere que el Socks Tabla 1: Etiquetas de los Paquetes acte como un proxy UDP, el cliente necesita Etiqueta Contenido/ Descripcin utilizar primero TCP ATYP Tipo de Direccin: para contactar con el 0x01: Direccin IPv4 0x02: Nombre de dominio proxy y autenticarse 0x03: Direccin IPv6 (Figura 4). El CMD lo BND.ADDR Socks Proxy source address para transminegocia, en este caso es sin de datos al servidor el tercer valor de la BND.PORT Socks Proxy source port para transmisin de Tabla 1: UDP Associate. datos al servidor Como el cliente actualCMD Tipos de transmisin: mente utilizar UDP 0x01 CONNECT para transmitir los 0x02 BIND datos, necesitar decirle 0x03 UDP Associativo al proxy que llegarn DST.ADDR Direccin destino solicitada (en el servidor) estos paquetes. Para DST.PORT Puerto destino solicitado (en el servidor) hacerlo, el cliente aade FRAG Nmero de fragmento actual (para paquetes a su propia direccin y UDP) METHODS Campo de seleccin para el mtodo de puerto a los campos autenticacin: DST.ADDR y DST.PORT. 0x00: Sin autentificacin El proxy abre un 0x01: GSSAPI puerto interno UDP, 0x02: Nombre de usuario y contrasea permitiendo al cliente 0x03 a 0x7E: Definido por IANA enviar paquetes hacia 0x80 a 0xFE: Reservado para mtodos priva fuera. El cliente lee la dos (slo utilizado localmente) direccin y el puerto del 0xFF: El proxy ha rechazado el mtodo ofre proxy desde la respuescido por el cliente ta del servidor a la resNMETHODS Nmero de entradas en el campo METHODS puesta UDP asociada: REP Campo de respuesta: BND.PORT y 0x00: Perfecto 0x01: Generic Socks proxy error BND.ADDR. Y aqu es 0x02: Conexin deshabilitado por ruleset donde el cliente tiene 0x03: Red no accesible que enviar cualquier 0x04: Host no accesible paquete UDP destinado 0x05: Peticin de conexin rechazada a la red externa. El 0x07: No soporta comandos Socks cliente coge su propio 0x08: No soporta el tipo de direccin paquete UDP en una 0x09 a 0xFF: No definido solicitud UDP (Figura RSV Reservado 3). La UDP se queda VER Versin del protocolo (0x05) abierta tanto tiempo

Un Mundo al Revs
Selectivamente el Socks puede permitir este tipo de conexin en la red interna. El cliente abre el canal de control al servidor enviando una respuesta normal Connect. El cliente luego utiliza una respuesta Bind sin una segunda conexin para preguntar al proxy Socks para abrir un puerto a la conexin de datos entrante. El proxy enva dos contestaciones en respuesta. El primero contiene el puerto y la direccin que el servidor Socks escuchar por las conexiones entrantes. El proxy no enva la segunda respuesta hasta que el servidor abre la conexin. Cuando esto ocurre, la respuesta del proxy contiene la direccin y el puerto

64

Nmero 09

WWW.LINUX-MAGAZINE.ES

Socks v5 ADMINISTRACIN

Figura 3: La versin 5 de Socks utiliza cinco tipos de paquetes: Client Negotiation, Server Negotiation, Client Request, Server Reply y UDP Request. El campo especifica el nombre y el tamao. La Tabla 1 describe el contenido.

que tambin ha comercializado mdulos de control de banda ancha y monitoreo de puertos y reenvos. Se comenta que la versin gratuita es suficiente para la mayora de las tareas. Adems de proporcionar los servicios Socks y MSproxy, tambin puede actuar como proxy HTTP, autenticar usuarios basndose en sus nombres de usuarios y contraseas o a travs de PAM (Pluggable Authentication Module). El soporte para nombre de interfaces en los ficheros de configuracin permite el uso de DHCP.

Configuracin del Proxy

ticacin podra implicar el encapsulado de los datos, por ejemplo, utilizando un protocolo seguro como SSL o TLS. Tras completar el proceso de negociacin del cliente/servidor, el cliente se autentica usando SSL/TSL. Cualquier otro dato enviado durante la conexin tambin puede ser protegido por SSL/TSL y esta forma de comunicacin segura asegura la confiabilidad e integridad. Los usuarios pueden utilizar dispositivos mviles, wireless seguros mediante el proxy Socks. La instalacin normal, utilizando configure && make && make install, coloca el fichero de configuracin del servidor en /etc/sockd.conf (Listado 1). En la lnea 1, una instruccin logoutput le indica a Dante dnde colocar los ficheros de log (Syslog o Stdout). En las lneas 4 y 5 se especifican el nombre de las interfaces de red. Esto es muy til para equipos configurados con DHCP. Las lneas 6 y 7 muestran que las direcciones IP son aceptadas.

Dante
La implementacin del cliente y el servidor de Socks con licencia BSD Dante para Unix[1] soporta Socks v4 y v5 y los ltimos MSproxy. La versin 1.1.15 se ha lanzado a finales de Enero de 2005. Dante lo desarroll una consultora noruega llamada Inferno Nettverk A/S,

ADMINISTRACIN Socks v5

que chequear los ficheros de registros del proxy, que estarn en /var/log/messages si utiliza Syslog.

Socks por todas partes

Al igual que el servidor Socks, el paquete Dante tiene un script wrapper denominado socksify. El script socksify proporciona al usuario la opcin de aadir capacidades de Socks a la mayora de los programas cliente de la red. Con socksify, puede aadir la capacidad Socks a protocolos como SMTP, FTP, NTP, DNS o IRQ. Por ejemplo:
./socksify -c ftp 10.0.0.10

Figura 4: En un escenario UDP, el cliente primero utiliza TCP para conectarse con el proxy Socks. El Client Request (4) contiene un comando UDP Associate, en el cual el cliente le dice al proxy desde donde ser enviado el paquete UDP.

Hay que tener en cuenta que la interfaz interna necesita un nmero de puerto. El mtodo de autenticacin soportado por Dante incluye el nombre del usuario / contrasea (lnea 9), el mtodo Ident especificado en RFC 931 (lnea 11) y PAM. El servidor Socks necesita distintos usuarios privilegiados para reflejar el mtodo de autenticacin. Si necesita acceder al fichero de contraseas, optar por una cuenta de usuario con los privilegios necesarios (definido como proxy en la lnea 14), aunque en cualquier otra circunstancia es mejor ser nobody (lnea 15). Sugerimos utilizar una cuenta de usuario dedicada para el servidor Socks v5. Los administradores pueden ejecutar el servidor en un entorno aislado para alejarlo de los sistemas de ficheros y tambin dar al servidor su propio fichero de claves.

otro acceso. Estas reglas son aplicadas a nivel TCP/IP y no tienen nada que ver con el protocolo Socks. La segunda clase de reglas de filtros comprueba el contenido de las peticiones de los clientes. Estas reglas especifican las clases de peticiones que el proxy atender. La regla block en las lneas de la 26 a la 29 del Listado 1 rechaza cualquier peticin de los ordenadores que quieran conectarse a 10.0.0.11. El trfico TCP y UDP de la mquina 10.0.0.3 con peticin para 10.0.0.10 es admitida (lneas 1 a 34). El proxy ignorar cualquier otra solicitud.

Junto con un fichero de configuracin adecuado /etc/socks.conf, el comando anterior le dice a socksify que llame al programa ftp mediante el proxy Socks sin necesidad de recompilar el cliente.
route { from: 0.0.0.0/0 to: U 0.0.0.0/0 U via: 10.0.0.11 port = 1080 proxyprotocol: socks_v5 }

Primeros Tests
Llamando a /sbin/sockd-d se lanza al proxy en modo de depuracin. Este modo le dice al proxy que registre cualquier cosa importante en logoutput. Ethereal es perfecto para chequear los detalles de la comunicacin. Utilizamos el navegador Mozilla como nuestro cliente de prueba. Establecemos el servidor Socks a 10.0.0.11 y el puerto 1080 en el Manual de configuracin del proxy en nuestro caso. Si el proxy Socks rechaza una conexin de una cuenta con privilegios de acceso inapropiados, el usuario podra darse cuenta de los sntomas sin llegar a saber por qu ha fallado la conexin. Por ejemplo, si el navegador Mozilla muestra un fallo de conexin, simplemente mostrar que The document contains no data en el caso de un error en la parte 2 de las reglas de filtrado, pero no hay que mencionar que la causa sea el proxy. Para investigar las posibles causas de un problema de conexin de este tipo, hay

La configuracin anterior le indica a socksify que utilice Socks v5 como un protocolo proxy y que establezca una conexin de red segura mediante el puerto 1080 en el ordenador 10.0.0.11.

Uno para Todos

La tecnologa Socks le proporciona a los administradores de la red la capacidad de desplegar un mtodo simple y transparente para la gestin de seguridad. Socks tambin aade autenticacin y encriptacin a aplicaciones de la red. A diferencia de muchos otros protocolos, el protocolo Socks no distingue entre conexin y autenticacin de usuario y por tanto, Socks proporciona un cortafuegos con control completo sobre todo el trfico de datos. s

Buen Filtrado
Las reglas de filtrado en los ficheros de configuracin le permiten especificar qu clientes pueden acceder al proxy Socks y a qu direcciones se puede conectar el proxy. Dante analiza las reglas de los filtros secuencialmente. Primero evala cualquier regla con el prefijo client para establecer qu ordenadores tienen permisos para acceder al servidor Socks (desde las lneas 17 al 24). Las reglas pass permiten el acceso, y las reglas block lo deniegan. Desde las lneas 17 a la 19 permiten al ordenador con la direccin 10.0.0.3 tener acceso sin restricciones, y las lneas 21 a 24 deniegan cualquier

RECURSOS
[1] Dante: http://www.inet.no/dante/ [2] RFC 1928, SOCKS Protocol Version 5: http://www.ietf.org/rfc/rfc1928.txt [3] RFC 1929, Username/ Password Authentication for SOCKS V5: http:// www.ietf.org/rfc/rfc1929.txt [4] RFC 1961, GSS-API Authentication Method for SOCKS Version 5: http:// www.ietf.org/rfc/rfc1961.txt

66

Nmero 09

WWW.LINUX-MAGAZINE.ES