El servidor proxy SOCKS se encuentra disponible en http://www.socks.nec.com/.
Una vez descomprimidos, introduzca los archivos en un directorio de su sistema, y siga las instrucciones sobre cómo hacerlo. Tuve algunos problemas cuando lo hice. Asegúrese de que sus Makefiles son correctos.
Una cuestión importante que se debe tener en cuenta es que el servidor proxy necesita ser incluido en /etc/inetd.conf. Para ello debe añadir la línea:
socks stream tcp nowait nobody /usr/local/etc/sockd sockd |
, que le comunica al servidor cuándo ha de ejecutarse.
El programa SOCKS necesita dos ficheros de configuración: uno para comunicarnos que se nos permite el acceso, y otro para enviar las peticiones al servidor proxy correspondiente. El fichero de acceso debería estar en el servidor y el fichero encaminador debería incluirse en cada sistema UNIX. Los computadores DOS y, supuestamente, Macintosh encaminarán por sí mismos.
Con socks4.2 Beta, el fichero de acceso se llama "sockd.conf". Debería contener dos tipos de líneas: las de permiso y las de prohibición. Cada línea tendrá tres entradas:
El Identificador (permit/deny)
La dirección IP
El modificador de dirección
El identificador es o "permit" (permitir) o "deny" (denegar). Debería tener una línea de cada.
La dirección IP se compone de cuatro octetos según la usual notación de puntos; por ejemplo, 192.168.1.0.
El modificador de dirección es también una dirección IP de cuatro octetos. Funciona como una máscara de red. Hay que verlo como 32 bits (unos o ceros). Si el bit es 1, el bit correspondiente de la dirección que esté comprobando debe coincidir con el bit correspondiente del campo de dirección IP; por ejemplo, si la línea es:
permit 192.168.1.23 255.255.255.255
admitirá sólo direcciones IP en las que coincida cada bit de 192.168.1.23; por ejemplo, sólo 192.168.1.3. La línea:
permit 192.168.1.0 255.255.255.0 |
admitirá todas las direcciones desde la 192.168.1.0 hasta la 192.168.1.255, la subred de clase C completa. No debería aparecer la línea:
permit 192.168.1.0 0.0.0.0 |
ya que ésta permitiría el acceso a cualquier dirección, pase lo que pase.
Así que, permita primero todas las direcciones que quiera admitir, y luego prohiba el resto. Para permitir a cualquiera de la subred 192.168.1.xxx, las líneas:
permit 192.168.1.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 |
trabajarán perfectamente. Observe los primeros "0.0.0.0" en la línea de deny. Con un modificador de 0.0.0.0, el campo de dirección IP no importa. Se suele poner 0 porque es más fácil de teclear.
Se permite más de una entrada de cada clase.
También se puede conceder o denegar el acceso a usuarios concretos. Esto se consigue gracias a la autenticación ident. No todos los sistemas admiten ident, incluyendo Trumpet Winsock, así que no entraré en ello aquí. La documentación que acompaña a socks trata este tema adecuadamente.
El fichero de encaminado tiene el desafortunado nombre de "socks.conf". Digo que es "desafortunado" porque se parece mucho al fichero de control de acceso, por lo que resulta fácil confundirlos.
El fichero de encaminado tiene la función de comunicar a los clientes de SOCKS cuándo usar socks y cuándo no. Por ejemplo, en nuestra red 192.168.1.3 no necesita usar socks para comunicarse con la 192.168.1.1, el cortafuegos. Tiene una conexión directa vía Ethernet. La dirección 127.0.0.1 define la vuelta atrás automáticamente. Por supuesto que no se necesita SOCKS para hablar consigo mismo. Existen tres tipos de entradas:
deny
direct
sockd
La entrada deny (denegar) comunica a SOCKS cuándo rechazar una petición. Esta entrada dispone de los mismos tres campos que en sockd.conf, identifier, address y modifier. Generalmente, dado que de esto también se encarga el fichero sockd.conf, el fichero de control de acceso, el campo del modificador se pone a 0.0.0.0. Si quiere abstenerse de conectar a un determinado lugar, se puede hacer aquí.
La entrada direct nos dice para qué direcciones no se usa socks. Estas son todas las direcciones a las que se puede llegar sin el servidor proxy. De nuevo hay tres campos: identifier, address y modifier. Nuestro ejemplo tendría
direct 192.168.1.0 255.255.255.0 |
Lo que nos llevaría directamente a cualquier máquina de nuestra red protegida.
La entrada sockd comunica en qué computador se encuentra el servidor demonio de socks. La sintaxis es:
sockd @=<serverlist> <IP address> <modifier>
Observe la entrada @=. Esta permite establecer las direcciones IP de una lista de servidores proxy. En nuestro ejemplo, sólo utilizamos un servidor proxy, pero puede tener muchos para admitir una carga mayor y un margen para redundancia en caso de fallo.
Los campos del modificador y de la dirección IP funcionan exactamente igual que en los otros ejemplos. Especifican a qué direcciones se van a través de los servidores 6.2.3. DNS desde detrás de un cortafuegos.
Instalar un servicio de nombres de dominio (DNS) desde detrás de un cortafuegos es una tarea relativamente sencilla. Sólo necesita instalar el DNS en el sistema cortafuegos. A continuación, configure cada sistema detrás del cortafuegos para usar este DNS.
Para que sus aplicaciones funcionen con el servidor proxy, necesitan ser "sockificadas". Será necesario disponer de dos telnets distintos: uno para la comunicación directa y otro para la comunicación por medio del servidor proxy. SOCKS se acompaña de instrucciones sobre cómo SOCKificar un programa, así como un par de programas pre-SOCKificados. Si se usa la versión SOCKificada para conectar con algún sitio con el que se tiene acceso directo, SOCKS cambiará de manera automática a la versión para acceso directo. Por ello, tendremos que dar un nuevo nombre a todos los programas de nuestra red protegida y reemplazarlos por los programas SOCKificados. Así, "Finger" pasará a ser "finger.orig", "telnet" pasará a ser "telnet.orig", etc. Todo esto se dará a conocer a SOCKS mediante el fichero include/socks.h.
Algunos programas encaminarán y sockificarán por sí mismos. Netscape es uno de ellos. Se puede usar un servidor proxy con Netscape simplemente introduciendo la dirección del servidor (en nuestro caso 192.168.1.1) en el campo SOCKs de Proxies. Todas las aplicaciones necesitarán algún retoque, independientemente de cómo procese un servidor proxy.
Trumpet Winsock viene con capacidad para el servidor proxy incorporada. En el menú "setup", se debe poner la dirección IP del servidor, y las direcciones de todos los computadores a los que llega directamente. Trumpet se encargará entonces de todos los paquetes de salida.
El paquete SOCKS trabaja sólo con paquetes TCP, no con UDP. Esto le resta utilidad. Muchos programas útiles, tales como talk y Archie, usan UDP. Existe un programa de aplicación diseñado para ser utilizado como servidor proxy para los paquetes UDP, denominados UDPrelay de Tom Fitzgerald <fitz@wang.com>. Desafortunadamente, en estos momentos, no es compatible con Linux.
El servidor proxy es, por encima de todo, un dispositivo de seguridad. Usarlo para aumentar el acceso a Internet cuando se tienen pocas direcciones IP presentan muchos inconvenientes. Un servidor proxy permite un mayor acceso desde dentro de la red protegida al exterior, pero mantiene el interior completamente inaccesible desde el exterior. Esto significa la ausencia de servidores, de conexiones talk o archive, o el envío directo de correo a los computadores interiores. Estos inconvenientes podrían parecer insignificantes, pero piense en ello de la siguiente forma:
Ha dejado un informe que está haciendo en su computador dentro de una red cortafuegos protegida. Está en casa y decide repasarla. No puede. No puede acceder a su computador, porque está detrás del cortafuegos. Intenta entrar primero al cortafuegos, pero como todo el mundo tiene acceso al exterior desde el servidor proxy, nadie se ha preocupado de abrirle una cuenta en él.
Su hija va a la universidad. Quiere enviarle un e-mail. Tiene cosas privadas que comentarle y preferiría que el correo llegara directamente a su computador. Confía plenamente en el administrador de su sistema; pero, sin embargo, es correo privado.
La incapacidad de utilizar paquetes UDP representa un gran inconveniente con los servidores proxy. Supongo que no por mucho tiempo.
FTP causa otro problema con un servidor proxy. Cuando se hace un ls, el servidor FTP establece una conexión con la máquina cliente y manda la información por ella. Un servidor proxy no lo permitirá, así que el FTP no funciona demasiado bien.
Además, un servidor proxy tarda en ejecutarse. Debido a la gran sobrecarga, casi cualquier otro medio de lograr acceso será más rápido.
En resumen, si tiene suficientes direcciones IP, y no le preocupa la seguridad, no use cortafuegos o servidores proxy. Si no dispone de suficientes direcciones IP, y tampoco le preocupa la seguridad, podría considerar la idea de utilizar un emulador IP, como Term, Slirp o TIA. Term está disponible en ftp://sunsite.unc.edu, Slirp se encuentra en ftp://blitzen.canberra.edu.au/pub/slirp, y TIA, en marketplace.com. Estos programas de aplicación van más rápido, permiten mejores conexiones y proporcionan un mayor nivel de acceso a la red interior desde Internet. Los servidores proxy están bien para las redes que tienen muchos sistemas que quieren conectar con Internet sobre la marcha, con una instalación y un mantenimiento mínimo.