El servidor proxy requiere software adicional. Éste se puede conseguir en:
ftp://sunsite.unc.edu/pub/LiNUX/system/Network/misc/socks-LiNUX-src.tgz
Solamente hay un ejemplo de fichero de configuración en ese
directorio, se llama "socks-conf"
. Debemos descomprimir y
desempaquetar los ficheros en un directorio de nuestro ordenador, y
seguir las instrucciones de cómo compilarlo. Yo tuve un par de
problemas compilándolo. Hay que asegurarse de que los Makefiles son
correctos. Algunos lo son y algunos no.
Algo importante que hay que advertir es que hay que añadir el servidor
proxy al /etc/inetd.conf
. Se debe añadir la linea:
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
para decir a inetd
que arranque el servidor cuando se le pida.
El programa socks
necesita dos ficheros de configuración distintos.
Uno en el que se le dice qué accesos están permitidos, y otro para
dirigir las peticiones al servidor proxy apropiado. El fichero de
control de acceso debe residir en el servidor. El fichero de
rutado debe residir en todas las máquinas Ún*x. Las máquinas
DOS y, presumiblemente, las Macintosh encaminarán por sí mismas.
Con socks4.2 Beta, el fichero de acceso se llama "sockd.conf"
. Debería
contener dos tipos de líneas: las de permiso, que contienen "permit" y
las de prohibición, que contienen "deny". Cada linea
tendrá tres palabras:
El identificador es o permit (permitir) o deny (denegar). Debería haber uno de cada.
La dirección IP se compone de cuatro octetos según la típica notación de puntos: p.ej. 192.168.2.0 .
El modificador de dirección es también un número de cuatro octetos. Funciona como una máscara de red. Hay que verlo como 32 bits (unos o ceros). Si el bit es uno, el bit correspondiente de la dirección que se comprueba debe coincidir con el bit correspondiente del campo de dirección IP.
Por ejemplo, si la línea es:
permit 192.168.2.23 255.255.255.255
entonces, admitirá sólo direcciones IP en las que coincidan todos los bits de 193.168.2.23, esto es, sólo ella misma. La línea:
permit 192.168.2.0 255.255.255.0
admitirá todas las direcciones desde la 192.168.2.0 hasta la 192.168.2.255, la subred de clase C completa. No se debería tener la línea:
permit 192.168.2.0 0.0.0.0
dado que permitiría cualquier dirección.
Así que, primero, permitimos todas las direcciones que queramos permitir, y después prohibimos el resto. Para permitir a cualquiera del rango 192.168.2.xxx, las líneas:
permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
funcionarán perfectamente. Observa los primeros "0.0.0.0"
en la linea
de prohibición. Con un modificador de 0.0.0.0, el campo de la dirección
IP no importa. Se suele poner todo ceros porque es fácil de teclear.
Se puede poner más de una línea de cada clase.
También se puede autorizar o denegar el acceso a determinados usuarios. Se consigue gracias a la autentificación del protocolo ident. No todos los sistemas soportan ident (incluyendo al Trumpet Winsock) de modo que no profundizaré en ello. La documentación que viene con socks trata este tema adecuadamente.
El fichero de rutado de socks tiene el desafortunado nombre de "socks.conf". Y digo que es desafortunado porque se parece tanto al del fichero de control de acceso que es fácil confundirlos.
El fichero de rutado tiene la función de decir a los clientes de socks cuándo usar socks y cuándo no. Por ejemplo, en nuestra red la máquina 192.168.2.3 no necesita usar socks para comunicarse con la 192.168.2.1 (el cortafuegos), ya que tiene una conexión directa vía Ethernet. La 127.0.0.1, dirección de "vuelta atrás" (que representa a una máquina ante ella misma), está definida automáticamente. Está claro que no se necesita usar socks para hablar con uno mismo.
Hay tres tipos de entradas:
Deny (denegar) le dice a socks que peticiones debe rechazar. Esta
entrada tiene los mismos tres campos que en sockd.conf
, identificador,
dirección, y modificador. Generalmente, dado que esto también es
manejado por el fichero de control de acceso sockd.conf
, el
modificador se pone a 0.0.0.0 . Si uno quiere impedirse a si mismo
conectar con un determinado sitio, se puede hacer poniéndolo aquí.
La entrada direct
dice para qué direcciones no se debe usar socks.
Éstas son todas las direcciones a las que se puede llegar sin usar el
servidor proxy. De nuevo hay tres campos: identificador, dirección, y
modificador. Nuestro ejemplo tendría:
direct 192.168.2.0 255.255.255.0
Con lo que iría directamente a cualquier máquina de la red protegida.
La entrada sockd
dice cuál es la máquina en la que corre el servidor
de socks. La sintaxis es:
sockd @=<lista de servidores> <dirección> IP <modificador>
Observemos la entrada @= . Ésta permite poner las direcciones IP de una lista de servidores proxy. En nuestro ejemplo sólo usamos un servidor proxy, pero se puede tener muchos para admitir una carga mayor y conseguir redundancia frente a fallos.
La dirección IP y el modificador funcionan como en los otros ejemplos. Especifican a qué direcciones se va a través de los servidores.
Instalar un Servicio de Nombres detrás de un cortafuegos es relativamente simple. No hay más que instalar el servidor de DNS en la máquina que hace de cortafuegos. Luego se hace que todas las máquinas tras el cortafuegos usen este servidor de DNS.
Para que las aplicaciones funcionen con el servidor proxy, hay que "sockificarlas". Será necesario tener dos telnets distintos, uno para la comunicación directa, y uno para la comunicación a través del servidor proxy. Socks viene con instrucciones de cómo sockificar un programa, así como con un par de programas ya sockificados. Si se usa la versíon sockificada para conectar con algún sitio al que se tiene acceso directo, socks cambiará automáticamente a la versión para acceso directo (la normal). Por esta razón deberemos cambiar el nombre a todos los programas de la red protegida y sustituirlos por los sockificados. Así "finger" pasará a ser "finger.orig", "telnet" a "telnet.orig", etc... . Se debe dar a conocer a socks todo esto en el fichero include/socks.h .
Algunos programas gestionan el rutado y el sockificado ellos mismos. Éste es el caso de Netscape. Se puede usar un servidor proxy con Netscape simplemente poniendo la dirección del servidor (192.168.2.1 en nuestro caso) en el campo SOCKs del menu Proxys. Todas las aplicaciones necesitarán algún retoque independientemente de cómo manejen la existencia de servidores proxy.
El Trumpet Winsock lleva incorporada la gestión de servidores proxy. En el menú "setup" se debe poner la dirección IP del servidor y las direcciones de todos los ordenadores a los que se llega directamente. Él se encargará a partir de entonces de todos los paquetes de salida.
El paquete socks sólo funciona con TCP, no con UDP. Esto le quita un poco de utilidad. Muchos programas interesantes, (como talk o archie) usan UDP. Existe un paquete diseñado para funcionar como un servidor proxy para paquetes de UDP que se llama UDPrelay. El autor es Tom Fitzgerald fitz@wang.com. Desgraciadamente, en el momento de escribir estas líneas, no es compatible con LiNUX.
Un servidor proxy es ante todo un dispositivo de seguridad. Usarlo para aumentar el número de máquinas con acceso a la Internet cuando se tienen pocas direcciones IP tiene 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 que no habrá conexiones archie, ni talk, ni envío directo de correo a los ordenadores de dentro. Estos inconvenientes pueden parecer pequeños, pero consideremos los siguientes casos:
cortafuegos
primero, pero como todo el mundo tiene acceso al
exterior gracias al servidor proxy, no te han abierto cuenta en él.El FTP crea otro problema con los servidores proxy. Cuando se hace un
ls
, o un get
, el servidor de 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 especialmente bien.
Además, un servidor proxy es lento. Debido a la gran sobrecarga, casi cualquier otro medio de lograr acceso será más rápido.
Resumiendo, si tienes suficientes direcciones IP y no te preocupa la
seguridad, no uses cortafuegos ni servidores proxy. Si no tienes
suficientes direcciones IP, pero tampoco te preocupa la seguridad,
seguramente deberías considerar los "emuladores de IP" como Term,
Slirp, o TIA. Term se puede conseguir en ftp://sunsite.unc.edu
, Slirp
en ftp://blitzen.canberra.edu.au/pub/slirp
, y TIA en marketplace.com
.
Van más rápido, permiten mejores conexiones, y proveen un mayor nivel
de acceso a la red interior desde la Internet. Los servidores proxy
están bien para las redes que tienen muchos ordenadores que quieren
conectar con la Internet al vuelo, y en las que se quiere poco trabajo
de mantenimiento tras la instalación.