<HTML> <HEAD> <TITLE>Cortafuegos COMO: Instalación del Servidor Proxy</TITLE> </HEAD> <BODY> <A HREF="Cortafuegos-Como-4.html">Anterior</A> <A HREF="Cortafuegos-Como-6.html">Siguiente</A> <A HREF="Cortafuegos-Como.html#toc5">Indice</A> <HR> <H2><A NAME="s5">5. Instalación del Servidor Proxy</A></H2> <P>El servidor proxy requiere software adicional. Éste se puede conseguir en: </P> <P><CODE> <A HREF="ftp://sunsite.unc.edu/pub/LiNUX/system/Network/misc/socks-Linux-src.tgz">ftp://sunsite.unc.edu/pub/LiNUX/system/Network/misc/socks-Linux-src.tgz</A></CODE></P> <P>Solamente hay un ejemplo de fichero de configuración en ese directorio, se llama <CODE>"socks-conf"</CODE>. 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. </P> <P>Algo importante que hay que advertir es que hay que añadir el servidor proxy al <CODE>/etc/inetd.conf</CODE>. Se debe añadir la linea: </P> <P> <BLOCKQUOTE><CODE> <PRE> socks stream tcp nowait nobody /usr/local/etc/sockd sockd </PRE> </CODE></BLOCKQUOTE> </P> <P>para decir a <CODE>inetd</CODE> que arranque el servidor cuando se le pida.</P> <H2><A NAME="ss5.1">5.1 Configuración del Servidor Proxy</A></H2> <P>El programa <CODE>socks</CODE> 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. </P> <H2><A NAME="ss5.2">5.2 El Fichero de Control de Acceso</A></H2> <P>Con socks4.2 Beta, el fichero de acceso se llama <CODE>"sockd.conf"</CODE>. 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: </P> <P> <UL> <LI>El identificador (permit/deny)</LI> <LI>La dirección IP</LI> <LI>El modificador de dirección</LI> </UL> </P> <P>El identificador es o permit (permitir) o deny (denegar). Debería haber uno de cada. </P> <P>La dirección IP se compone de cuatro octetos según la típica notación de puntos: p.ej. 192.168.2.0 . </P> <P>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. </P> <P>Por ejemplo, si la línea es:</P> <P> <BLOCKQUOTE><CODE> <PRE> permit 192.168.2.23 255.255.255.255 </PRE> </CODE></BLOCKQUOTE> </P> <P>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: </P> <P> <BLOCKQUOTE><CODE> <PRE> permit 192.168.2.0 255.255.255.0 </PRE> </CODE></BLOCKQUOTE> </P> <P>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: </P> <P> <BLOCKQUOTE><CODE> <PRE> permit 192.168.2.0 0.0.0.0 </PRE> </CODE></BLOCKQUOTE> </P> <P>dado que permitiría cualquier dirección.</P> <P>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: </P> <P> <BLOCKQUOTE><CODE> <PRE> permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 </PRE> </CODE></BLOCKQUOTE> </P> <P>funcionarán perfectamente. Observa los primeros <CODE>"0.0.0.0"</CODE> 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. </P> <P>Se puede poner más de una línea de cada clase.</P> <P>También se puede autorizar o denegar el acceso a determinados usuarios. Se consigue gracias a la autentificación del protocolo <EM>ident</EM>. No todos los sistemas soportan <EM>ident</EM> (incluyendo al Trumpet Winsock) de modo que no profundizaré en ello. La documentación que viene con socks trata este tema adecuadamente. </P> <H2><A NAME="ss5.3">5.3 El Fichero de rutado</A></H2> <P>El fichero de rutado de socks tiene el desafortunado nombre de <B>"socks.conf"</B>. Y digo que es desafortunado porque se parece tanto al del fichero de control de acceso que es fácil confundirlos. </P> <P>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. </P> <P>Hay tres tipos de entradas:</P> <P> <UL> <LI>deny</LI> <LI>direct</LI> <LI>sockd</LI> </UL> </P> <P>Deny (denegar) le dice a socks que peticiones debe rechazar. Esta entrada tiene los mismos tres campos que en <CODE>sockd.conf</CODE>, identificador, dirección, y modificador. Generalmente, dado que esto también es manejado por el fichero de control de acceso <CODE>sockd.conf</CODE>, 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í. </P> <P>La entrada <CODE>direct</CODE> dice para qué direcciones <EM>no</EM> 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: </P> <P><CODE>direct 192.168.2.0 255.255.255.0</CODE></P> <P>Con lo que iría directamente a cualquier máquina de la red protegida.</P> <P>La entrada <CODE>sockd</CODE> dice cuál es la máquina en la que corre el servidor de socks. La sintaxis es: </P> <P> <BLOCKQUOTE><CODE> <PRE> sockd @=<lista de servidores> <direccion IP> <modificador> </PRE> </CODE></BLOCKQUOTE> </P> <P>Observemos la entrada <CODE>@=</CODE>. É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.</P> <P>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. </P> <H2><A NAME="ss5.4">5.4 El Servicio de Nombres tras el Cortafuegos</A></H2> <P>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. </P> <H2><A NAME="ss5.5">5.5 Trabajar con un Servidor Proxy</A></H2> <H3>UnixPara que las aplicaciones funcionen con el servidor proxy, hay que"sockificarlas". Será necesario tener dos telnets distintos, uno para lacomunicación directa, y uno para la comunicación a través del servidorproxy. Socks viene con instrucciones de cómo sockificar un programa, asícomo con un par de programas ya sockificados. Si se usa la versíonsockificada para conectar con algún sitio al que se tiene acceso directo,socks cambiará automáticamente a la versión para acceso directo (lanormal). Por esta razón deberemos cambiar el nombre a todos los programasde la red protegida y sustituirlos por los sockificados. Así "finger"pasará a ser "finger.orig", "telnet" a "telnet.orig", etc... . Se debe dara conocer a socks todo esto en el fichero include/socks.h . Algunos programas gestionan el rutado y el sockificado ellos mismos. Éstees el caso de <EM>Netscape</EM>. Se puede usar un servidor proxy con<EM>Netscape</EM> simplemente poniendo la dirección del servidor(192.168.2.1 en nuestro caso) en el campo <B>SOCKs</B> del <B>menuProxys</B>. Todas las aplicaciones necesitarán algún retoqueindependientemente de cómo manejen la existencia de servidores proxy. </H3> <H3>MS Güindous con el Trumpet Winsock</H3> <P>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. </P> <H2><A NAME="ss5.6">5.6 Cómo conseguir que el Servidor Proxy funcione con UDP</A></H2> <P>El paquete socks sólo funciona con <EM>TCP</EM>, no con <EM>UDP</EM>. 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 <A HREF="mailto:fitz@wang.com">fitz@wang.com</A>. Desgraciadamente, en el momento de escribir estas líneas, no es compatible con LiNUX. </P> <H2><A NAME="ss5.7">5.7 Inconvenientes de los Servidores Proxy</A></H2> <P>Un servidor proxy es ante todo un <EM>dispositivo de seguridad</EM>. 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: </P> <P> <UL> <LI>Te has dejado un informe que estás haciendo en tu ordenador que está dentro de la red protegida por el cortafuegos. Estás en casa y decides cambiar algo. No puedes. No puedes llegar a tu ordenador dado que está tras el cortafuegos. Intentas entrar en el <CODE>cortafuegos</CODE> primero, pero como todo el mundo tiene acceso al exterior gracias al servidor proxy, no te han abierto cuenta en él. </LI> <LI>Tu hija va a la universidad. Quieres enviarle correo. Tienes algunas cosas privadas que comentar con ella, por lo que preferirías que el correo llegara directamente a tu máquina. Confías plenamente en el administrador de tu sistema, pero, aún así, es correo privado. </LI> <LI>La incapacidad de manejar paquetes UDP es un gran inconveniente de los servidores proxy. Imagino que no por mucho tiempo. </LI> </UL> </P> <P>El FTP crea otro problema con los servidores proxy. Cuando se hace un <CODE>ls</CODE>, o un <CODE>get</CODE>, 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. </P> <P>Además, un servidor proxy es lento. Debido a la gran sobrecarga, casi cualquier otro medio de lograr acceso será más rápido. </P> <P>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. </P> <P>Term se puede conseguir en <CODE> <A HREF="ftp://sunsite.unc.edu">ftp://sunsite.unc.edu</A></CODE>, Slirp en <CODE> <A HREF="ftp://blitzen.canberra.edu.au/pub/slirp">ftp://blitzen.canberra.edu.au/pub/slirp</A></CODE>, y TIA en <CODE> <A HREF="ftp://marketplace.com">ftp://marketplace.com</A></CODE>. </P> <P>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.</P> <HR> <A HREF="Cortafuegos-Como-4.html">Anterior</A> <A HREF="Cortafuegos-Como-6.html">Siguiente</A> <A HREF="Cortafuegos-Como.html#toc5">Indice</A> </BODY> </HTML>
