<!-- 0,1 -->
<!-- Firewalling and Proxy Server,0 -->
<!-- David,Rudder,drig@execpc.com -->
<!-- 0,0000-00-00 -->
<!-- Cortafuegos -->
<!-- Carlos,García Arques,cgarcia@isabel.dit.upm.es -->
<!-- 0.3,1998-09-01 -->
<!-- Firewall,cortafuegos,proxy -->
<!-- Software,Cortafuegos -->

<!doctype linuxdoc system>

<!-- ****************************************************************** -->
<!-- * Revisión y re-reformateo sgml v0.2      Francisco. J. Montilla * -->
<!-- *      01/09/98                               pacopepe@insflug.org * -->
<!-- ****************************************************************** -->

<article>

<title>Cortafuegos COMO

<author> David Rudder, <tt><htmlurl url="mailto:drig@execpc.com" 
name="drig@execpc.com"></tt> &nl;
Traducido por Carlos García Arques <tt><htmlurl 
url="mailto:cgarcia@isabel.dit.upm.es" name="cgarcia@isabel.dit.upm.es"></tt>

<date>Traducción v0.2, 13 de Agosto de 1996 

<abstract>
El objetivo de este documento es enseñar las bases de la instalación de un
cortafuegos mediante un PC y Linux. También trata la instalación y el uso
de Servidores Proxy, dispositivos estos con los que se consigue un mayor
nivel de acceso a la Internet desde detrás de un cortafuegos. 

Titulo original: "Firewalling and Proxy Server HOWTO"
Título alternativo propuesto por el autor: "The ride of the lonely local
area network", es decir "La balada de la red local solitaria". 
</abstract>

<toc>

<sect>Introducción
<p>

Los cortafuegos han adquirido gran popularidad de un tiempo a esta parte
como el último grito en seguridad en la Internet. Como la mayoría de las
cosas que la adquieren, con la popularidad han llegado los malentendidos. 
En este <it/Howto/ se cubrirán las bases de lo que es un
<bf>cortafuegos</bf>, cómo configurar uno, qué <bf>servidores proxy</bf>
hay, cómo configurarlos, y las aplicaciones de esta tecnología fuera del
campo de la seguridad. 


<sect1>Realimentación
<p>

Todo apoyo o crítica a este documento será bienvenido. Estoy buscando con
especial interés críticas de la gente que usa Macintoshes, ya que la
información que tengo de ellos es escasa. <bf>¡¡¡POR FAVOR, COMUNICADME
CUALQUIER INEXACTITUD EN ESTE DOCUMENTO!!!</bf> Soy humano, y puedo
cometer errores. Si encontráis alguno, me interesará mucho conocerlo.
Intentaré contestar a todo el correo, pero estoy ocupado; así que, que
nadie se ofenda si no lo hago.

Mi dirección de correo electrónico es <tt><htmlurl
url="mailto:drig@execpc.com" name="drig@execpc.com"></tt>

<sect1>Renuncia de Responsabilidad 
<p>

Este documento intenta ser una introducción al funcionamiento de los
cortafuegos y servidores proxy. No soy, ni pretendo ser, un experto en
seguridad. Soy simplemente un tipo que ha leído mucho y al que le gustan
los ordenadores más que al resto de la gente. NO SOY RESPONSABLE DE NINGÚN
DAÑO PRODUCIDO POR ACCIONES CON BASE EN ESTE DOCUMENTO. Por favor, escribo
esto para ayudar a la gente a entender el tema, no estoy preparado para
hacer depender mi vida de la exactitud de lo que hay aquí. 

<footnote><bf>Nota del Traductor:</bf> y yo menos. &nl;
(es decir, suscribo el párrafo anterior, excepto donde dice escribir,
que debe leerse traducir. Y donde dice experto en seguridad léase
traductor experto).</footnote>

<sect1>Propiedad Intelectual
<p>

A no ser que se indique de otra manera, los Howtos de LiNUX son propiedad
intelectual de sus respectivos autores. Los Howtos de LiNUX pueden ser
reproducidos y distribuidos en todo o en parte, por cualquier medio físico
o electrónico, siempre que este anuncio de copyright se mantenga en todas
las copias. La redistribución comercial está permitida y se anima a ella. 
No obstante, al autor le gustaría ser informado de cualquiera de tales
distribuciones. 

Todas las traducciones, trabajos derivados, o trabajos de recopilación que
incorporen cualquier Howto de LiNUX, deben estar cubiertos por este
copyright. Esto es, no se puede producir ningún trabajo derivado de un
Howto e imponer restricciones adicionales a su distribución.  Pueden ser
autorizadas excepciones a estas reglas bajo ciertas condiciones. Por
favor, contacte con el coordinador de los Howtos de LiNUX en la dirección
que se da más abajo. 

Resumiendo, queremos promover la diseminación de esta información a través
de todos los cauces posibles. No obstante, deseamos mantener la propiedad
intelectual de los Howtos, y nos gustaría ser advertidos de cualquier
proyecto de redistribución de los Howtos. 

Para cualquier pregunta, por favor, contacte con David Rudder <tt><htmlurl
url="mailto:drig@execpc.com" name="drig@execpc.com"></tt>

<sect1>Las Razones para Escribir Esto
<p>

Hubo muchos artículos en comp.os.linux.* a lo largo de, más o menos, el
año pasado pidiendo ayuda sobre cortafuegos. Parecía como si nadie fuera a
contestarlos. Supuse que la razón era que nadie sabía cómo.  Así que
dediqué cierto tiempo a jugar con cortafuegos y a aprender.  Este
documento existe como respuesta a aquellas peticiones. 

<sect1>Por Hacer
<p>

<itemize>
<item>Aprender cómo hacer esto en un Macintosh
<item>Aprender sobre diferentes paquetes de TCP/IP para Güindous
<item>Encontrar un buen servidor proxy de UDP que funcione con LiNUX
</itemize>

<sect1>Lecturas de Interés
<p>

<itemize>
<item>La documentación del juego de herramientas de TIS
<item>El Howto del NET-2
<item>PPP-Como
<item>El Howto de la Ethernet
<item>El MINIHowto de las Múltiples Ethernets
<item>Networking with LiNUX
<item>La guía del administrador de red TCP/IP de O'Reilly and Associates
</itemize>

<em>Las herramientas para cortafuegos de TIS</em> traen una colección de
documentos que se encuentran entre los mejores que he leído sobre
cortafuegos y asuntos relacionados. En la sección <ref id="soft"> se habla
más de las <it>herramientas de TIS</it>. 

<sect>Cortafuegos: Conceptos Básicos
<p>

<bf>Cortafuegos</bf> es el término que se emplea para referirse a una
franja de bosque que se limpia de árboles, vegetación, y cualquier materia
inflamable, con el fin de crear una barrera que el fuego de un posible
incendio no sea capaz de atravesar. 

Un <bf>cortafuegos</bf> en el mundillo de las redes de ordenadores es un
dispositivo lógico que protege una red privada del resto de la red
(pública). Funcionan así: 

<enum>
<item>Se toma un ordenador con capacidad de rutar (por ejemplo un PC
con LiNUX)
<item>Se le ponen dos interfaces (por ejemplo interfaces serie, o ethernet,
o de paso de testigo en anillo (Token Ring), etc...)
<item>Se le deshabilita el reenvío de paquetes IP (IP forwarding)
<item>Se conecta una interfaz a la Internet
<item>Se conecta la otra interfaz a la red que se quiere proteger
</enum>

Ahora hay dos redes distintas que comparten un ordenador. El ordenador
cortafuegos, al que de ahora en adelante llamaremos
<tt>"cortafuegos"</tt>, puede comunicarse tanto con la red protegida como
con la Internet. La red protegida no puede comunicarse con la Internet, y
la Internet no puede comunicarse con la red protegida, dado que hemos
deshabilitado el reenvío IP en el único ordenador que las conecta. 

Si se quiere llegar a la Internet desde la red protegida, hay que hacer
primero un telnet al cortafuegos, y acceder a la Internet desde él.  Del
mismo modo, para acceder a la red protegida desde la Internet, se debe
antes pasar por el cortafuegos. 

Este es un mecanismo de seguridad excelente contra ataques desde la
Internet. Si alguien quiere atacar la red protegida, primero tiene que
atravesar el cortafuegos. De esta manera el ataque se divide en dos pasos,
y, por lo tanto, se dificulta. Si alguien quiere atacar la red protegida
por métodos más comunes, como el bombardeo de emails, o el nefasto
<tt>"Gusano de Internet"</tt>, simplemente no podrá alcanzarla. Con esto
se consigue una protección excelente. 

<sect1>Inconvenientes de los Cortafuegos
<p>

El mayor problema de los cortafuegos es que restringen mucho el acceso a
la Internet desde la red protegida. Básicamente, reducen el uso de la
Internet al que se podría hacer desde un terminal. Tener que entrar en el
<tt>cortafuegos</tt> y desde allí realizar todo el acceso a Internet es
una restricción muy seria. Programas como <em>Netscape</em> (pronúnciese
Nescafé), que requieren una conexión directa con la Internet, no funcionan
desde detrás de un cortafuegos. La solución a todos estos problemas es un
<bf>Servidor Proxy</bf>. 

<sect1>Servidores Proxy
<p>

Los servidores proxy son un invento que permite el acceso directo a la
Internet desde detrás de un cortafuegos. Funcionan abriendo un socket en
el servidor y permitiendo la comunicación con la Internet a través de él.
Por ejemplo: si mi ordenador, <tt>drig</tt>, estuviera dentro de la red
protegida y quisiera ver el Web con <em>Netscape</em>, pondría un servidor
proxy en el <tt>cortafuegos</tt>. El servidor proxy estaría configurado
para hacer que las peticiones de conexión de mi ordenador al puerto 80 de
otra máquina, se conectara a su puerto 1080, y él mismo establecería una
conexión con el puerto 80 de la máquina deseada. A partir de entonces
reenviaría todos los datos de esa conexión a la otra máquina. 

Quien haya usado <em>TIA</em> o <em>TERM</em> se ha encontrado este
concepto antes. Con estos dos programas se puede redirigir un puerto. Un
amigo tenía TIA configurado para hacer que quien se conectara a la
192.251.139.21 puerto 4024 lo hiciera a su servidor de Web. El servidor
proxy funciona así pero al revés. Para conectarnos al puerto 80 de
cualquiera, debemos usar el puerto 1080 (o cualquier otro que hayamos
dispuesto) del servidor proxy. 

Lo importante de los servidores proxy es que, bien configurados, son
completamente seguros. <em>No</em> dejan que nadie entre a través de
ellos. 
 
<sect>Configuración
<p>

<sect1> Requerimientos de Hardware
<p>

Para nuestro ejemplo, el ordenador es un 486-DX66 con 8 Megas de RAM, una
partición para Linux de 500 Megas, y una conexión PPP a un proveedor de
Internet a través de un módem de 14.400 bps . Ese es nuestro linux básico.
Para convertirlo en un cortafuegos le añadimos una tarjeta Ethernet
NE2000. Con ella queda conectado a tres PC'es con Güindous 3.1 y Trumpet
Winsock, y a dos Sun'es con SunOs. La razón de elegir este escenario es
que son las dos plataformas con las que estoy familiarizado. Imagino que
gran parte de lo que cuento aquí es factible con Mac'es pero, dado que no
uso Mac'es con suficiente asiduidad, lo cierto es que no lo sé. 

<sect1>Configurando el Software
<p>

Así, que ahora tenemos un LiNUX conectado a Internet por una linea PPP de
14.400 . Además tenemos una red Ethernet que conecta el LiNUX y el resto
de los ordenadores. Lo primero, debemos recompilar el núcleo con las
opciones apropiadas. En este momento yo echaría un vistazo al
<it>Kernel-Como</it>, al <it>Ethernet-HOWTO</it>, y al
<it>NET-3-HOWTO</it>.  Luego teclearía <tt>"make config"</tt>: 

Las opciones requeridas son:

<enum>
<item>Habilitar el Soporte de Red
<item>Habilitar la opción de red TCP/IP (TCP/IP Networking)
<item>Deshabilitar el reenvio de paquetes IP (CONFIG_IP_FORWARD)
<item>Habilitar la opción de Cortafuegos IP (IP Firewalling)
<item>Probablemente, habilitar las cuentas IP (IP Accounting). Parece
razonable, dado que estamos configurando un dispositivo de seguridad
<item>Habilitar el Soporte de Dispositivos de Red (Networking Device Support)
<item>Habilitar el soporte de PPP y Ethernet, aunque esto depende del
tipo de interfaces que se tenga en cada caso
</enum>

Ahora, recompilamos y reinstalamos el núcleo y rearrancamos la máquina.
Las interfaces deberían ser reconocidas en la secuencia de arranque para
que todo estuviera bien. Si no, habría que repasar los Howtos antes
mencionados y volverlo a intentar hasta que funcionase. 

<sect1>Las Direcciones de Red
<p>

Esta es la parte interesante. Dado que no queremos que la Internet tenga
acceso a nuestras máquinas, no necesitamos usar direcciones reales. Una
buena elección es el rango de direcciones de clase C 192.168.2.xxx, que
está designado como rango para pruebas. Es decir, nadie lo usa, y no
entrará en conflicto con ninguna petición al exterior. De modo que, en
esta configuración, sólo se necesita una dirección IP real. Las otras se
pueden elegir libremente y de ninguna manera afectarán a la red. 

Asignamos la dirección IP real al puerto serie del <tt>cortafuegos</tt>
que usamos para la conexión PPP. Asignamos 192.168.2.1 a la tarjeta
Ethernet del <tt>cortafuegos</tt>. Asignamos a las otras máquinas de la
red protegida cualquier dirección del rango anterior. 

<sect1>Pruebas
<p>

Lo primero es hacer ping a la internet desde el <tt>cortafuegos</tt>. Yo
antes usaba <tt>nic.ddn.mil</tt> como punto de prueba. No deja de ser una
buen sitio, pero ha demostrado ser menos fiable de lo que esperaba. Si no
funciona a la primera, probaremos a hacer pings a otro par de sitios que
no estén conectados a nuestra red local. Si no funciona es que el PPP está
mal configurado. Tendríamos que volver a leer el <it>Net-3-HOWTO</it> y a
probar. 

Ahora probaremos a hacer pings entre las máquinas de la red protegida.
Todas deben ser capaces de hacer ping a las demás. Si no fuera así, habría
que leer de nuevo el <it>Net-3-HOWTO</it> y trabajar en la red un poco
más. 

Ahora, todas las máquinas de la red protegida deben ser capaces de hacer
pings al <tt>cortafuegos</tt>. Si no, vuelta atrás. Recuerda: deberían ser
capaces de hacer ping a la 192.168.2.1, no a la dirección PPP. 

Entonces probaremos a hacer ping a la dirección PPP del
<tt>cortafuegos</tt> desde dentro de la red protegida. <em>No debe
funcionar</em>. Si funciona es que no hemos deshabilitado el <em>Reenvio
del Paquetes IP</em> y habrá que recompilar el núcleo. Al haber asignado a
la red protegida la dirección 192.168.2.0 ningún paquete será encaminado a
ella por la Internet, pero, en cualquier caso, es más seguro tener el
reenvío de paquetes IP deshabilitado. Esto deja el control en nuestras
manos, no en las manos de nuestro proveedor de PPP. 

Finalmente, haremos ping a todas las máquinas de la red protegida desde el
<tt>cortafuegos</tt>. Llegados a este punto, no debería haber problemas. 

Ya tenemos una disposición de cortafuegos básica.

<sect1>Seguridad para el Cortafuegos
<p>

El cortafuegos no sirve si lo dejamos vulnerable a los ataques.  Primero
echaremos un vistazo al /etc/inetd.conf. Este es el fichero de
configuración del así llamado "superservidor" (inetd), que arranca un buen
número de demonios servidores cuando les llega una petición. 

Entre ellos:

<itemize>
<item>Telnet
<item>Talk
<item>FTP
<item>Daytime
</itemize>

Se debe desactivar todo lo que no se necesite. No dudaremos en desactivar
netstat, systat, tftp, bootp, y finger. Seguramente querremos desactivar
telnet, y dejar sólo rlogin, o viceversa.

Para desactivar un servicio basta con poner un &num; al comienzo de la
linea que se refiera a él.  Después hay que mandar una señal SIG-HUP al
proceso inetd tecleando "<tt>kill -HUP &lt;pid&gt;</tt>", donde
<tt/&lt;pid&gt;/ es el número de proceso de inetd. Esto hará que inetd
relea su fichero de configuración (<tt/inetd.conf/) y se reinicie. Lo
comprobaremos haciendo un telnet al puerto 15 del <tt>cortafuegos</tt>, el
puerto de netstat. Si aparece la respuesta de netstatd, no hemos
reiniciado inetd correctamente.

<sect>Software para Cortafuegos <label id="soft">
<p>

<sect1>Paquetes disponibles
<p>

Un cortafuegos en sentido estricto no necesita ningún software aparte del
núcleo de LiNUX y los programas básicos de red (inetd, telnetd y telnet,
ftpd y ftp). Pero un cortafuegos así es extremadamente restrictivo y no
muy útil. 

Así que la gente ha hecho programas para aumentar la utilidad de los
cortafuegos. El que examinaremos con mayor detalle es un paquete llamado
"<em>socks</em>", que implementa un <tt>servidor proxy</tt>. Sin embargo,
existe otro par de programas que hay que tomar en consideración. Ahora les
daremos un rápido repaso. 

<sect1>El juego de herramientas para cortafuegos de TIS
<p>

<em>TIS</em> ha sacado una colección de programas para facilitar la
realización de cortafuegos. Básicamente, los programas hacen lo mismo que
el paquete <em>Socks</em>, pero tiene una estrategia de diseño diferente.
Mientras que <tt>Socks</tt> tiene un único programa que cubre todas las
operaciones de la Internet, <tt>TIS</tt> provee un programa para cada
utilidad que quiera usar el cortafuegos. 

Para compararlos mejor, veamos el ejemplo del acceso al <em>Web</em> y por
<em>Telnet</em>.  Con <tt>Socks</tt>, hay que hacer un fichero de
configuración y poner en marcha un demonio. Mediante ese fichero y ese
demonio se activan tanto el <tt>Telnet</tt> como el <tt>Web</tt>, así como
cualquier otro servicio que no se haya desactivado explícitamente. 

Con las <tt>herramientas TIS</tt>, se arranca un demonio para el
<tt>Web</tt> y otro para el <tt>Telnet</tt>, y se escribe un fichero de
configuración para cada uno. Después de haber hecho eso, el resto de
formas de acceso a Internet siguen prohibidas hasta que se configuren
explícitamente. Si no existe un demonio especial para una determinada
utilidad (por ejemplo, para talk), hay un demonio <em>"para todo"</em>
pero no es ni tan flexible, ni tan fácil de configurar como las otras
herramientas. 

Esto puede parecer una diferencia menor, pero en realidad es una gran
diferencia. <tt>Socks</tt> permite ser desidioso. Con un servidor de
<tt>Socks</tt> mal configurado la gente de dentro tiene más acceso a la
Internet del que se quería. Con las herramientas <tt>TIS</tt>, la gente
del interior tiene solamente el acceso que el administrador del sistema
quiera que tengan. 

<tt>Socks</tt> es más fácil de configurar, más fácil de compilar, y
permite una mayor flexibilidad. El <tt>juego de herramientas de TIS</tt>
es mas seguro si se quiere controlar a los usuarios <em>de dentro</em>.
<bf>Los dos proporcionan una protección absoluta del exterior</bf>. 

<sect1>El Limitador de TCP (TCP Wrapper)
<p>

El limitador de TCP no es una utilidad de cortafuegos, pero sirve para
algo parecido. Usando el limitador de TCP podemos controlar quién tiene
acceso a nuestra máquina y a qué servicios, así como registrar las
conexiones. También ofrece detección básica de impostores. 

El limitador de TCP no se cubre de manera más extensa aquí por un par de
razones: 

<itemize>
<item>No es un verdadero cortafuegos.
<item>Para utilizarlo se tiene que estar directamente conectado a la
Internet, es decir, se tiene que tener una dirección IP.
<item>Sólo controla la máquina en la que está instalado, y por lo tanto no
sirve para una red. Los cortafuegos pueden proteger todas las máquinas
cualquiera que sea su arquitectura. El limitador de TCP no funciona en
Macintoshes ni en MS Güindouses. 
</itemize>

<sect>Instalación del Servidor Proxy
<p>

El servidor proxy requiere software adicional. Éste se puede conseguir en: 

<tt><htmlurl
url="ftp://sunsite.unc.edu/pub/LiNUX/system/Network/misc/socks-Linux-src.tgz" 
name="ftp://sunsite.unc.edu/pub/LiNUX/system/Network/misc/socks-Linux-src.tgz"</tt>

Solamente hay un ejemplo de fichero de configuración en ese directorio, se
llama <tt>"socks-conf"</tt>. 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 <tt>/etc/inetd.conf</tt>. Se debe añadir la linea: 

<tscreen><verb>
socks   stream  tcp     nowait  nobody  /usr/local/etc/sockd    sockd
</verb></tscreen>

para decir a <tt/inetd/ que arranque el servidor cuando se le pida.

<sect1>Configuración del Servidor Proxy
<p>

El programa <tt/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. 

<sect1>El Fichero de Control de Acceso
<p>

Con socks4.2 Beta, el fichero de acceso se llama <tt>"sockd.conf"</tt>.
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: 

<itemize>
<item>El identificador (permit/deny)
<item>La dirección IP
<item>El modificador de dirección
</itemize>

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:

<tscreen><verb>
permit 192.168.2.23 255.255.255.255
</verb></tscreen>

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: 

<tscreen><verb>
permit 192.168.2.0 255.255.255.0
</verb></tscreen>

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: 

<tscreen><verb>
permit 192.168.2.0 0.0.0.0
</verb></tscreen>

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: 

<tscreen><verb>
permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
</verb></tscreen>

funcionarán perfectamente. Observa los primeros <tt>"0.0.0.0"</tt> 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 <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. 

<sect1>El Fichero de rutado
<p>

El fichero de rutado de socks tiene el desafortunado nombre de
<bf>"socks.conf"</bf>. 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:

<itemize>
<item>deny
<item>direct
<item>sockd
</itemize>

Deny (denegar) le dice a socks que peticiones debe rechazar. Esta entrada
tiene los mismos tres campos que en <tt>sockd.conf</tt>, identificador,
dirección, y modificador. Generalmente, dado que esto también es manejado
por el fichero de control de acceso <tt>sockd.conf</tt>, 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 <tt/direct/ 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: 

<tt>direct 192.168.2.0 255.255.255.0</tt>

Con lo que iría directamente a cualquier máquina de la red protegida.

La entrada <tt/sockd/ dice cuál es la máquina en la que corre el servidor
de socks. La sintaxis es: 

<tscreen><verb>
sockd @=<lista de servidores> <direccion IP> <modificador>
</verb></tscreen>

Observemos la entrada <tt/&commat;=/. É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. 

<sect1>El Servicio de Nombres tras el Cortafuegos
<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. 

<sect1>Trabajar con un Servidor Proxy
<p>

<sect2>Unix

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 <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 <bf>SOCKs</bf> del <bf>menu
Proxys</bf>.  Todas las aplicaciones necesitarán algún retoque
independientemente de cómo manejen la existencia de servidores proxy. 

<sect2>MS Güindous con el Trumpet Winsock
<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. 

<sect1>Cómo conseguir que el Servidor Proxy funcione con UDP
<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 <htmlurl url="mailto:fitz@wang.com" name="fitz@wang.com">.
Desgraciadamente, en el momento de escribir estas líneas, no es compatible
con LiNUX. 

<sect1>Inconvenientes de los Servidores Proxy
<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:  

<itemize>

<item>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 <tt>cortafuegos</tt> primero,
pero como todo el mundo tiene acceso al exterior gracias al servidor
proxy, no te han abierto cuenta en él. 

<item>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. 

<item>La incapacidad de manejar paquetes UDP es un gran inconveniente de
los servidores proxy. Imagino que no por mucho tiempo. 
</itemize>

El FTP crea otro problema con los servidores proxy. Cuando se hace un
<tt>ls</tt>, o un <tt>get</tt>, 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 <tt><htmlurl url="ftp://sunsite.unc.edu" 
name="ftp://sunsite.unc.edu"></tt>, Slirp en <tt><htmlurl
url="ftp://blitzen.canberra.edu.au/pub/slirp" 
name="ftp://blitzen.canberra.edu.au/pub/slirp"></tt>, y TIA en
<tt><htmlurl url="ftp://marketplace.com" 
name="ftp://marketplace.com"></tt>. 

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.

<sect>Configuración Avanzada
<p>

Hay una configuración que me gustaría mostrar antes de dar por terminado
este documento. La que acabo de comentar bastará seguramente para la
mayoría de la gente. Sin embargo, pienso que el próximo ejemplo mostrará
una más avanzada que puede resolver algunas dudas.  Si tienes preguntas
que trascienden lo cubierto hasta aquí, o simplemente estás interesado/a
en la versatilidad de los servidores proxy y los cortafuegos, sigue
leyendo. 

<sect1>Una gran red con énfasis en la seguridad
<p>

Digamos, por ejemplo, que eres el líder de la <em>Vigésimo Tercera
Hermandad de la Discordia de Milwaukee</em>. Te gustaría poner una red. 
Tienes 50 ordenadores y una subred de 32 (5 bites) direcciones IP
(reales). Hay varios niveles de acceso. Se dicen cosas distintas a los
discípulos según el nivel en que están. Obviamente, querrás proteger
ciertas partes de la red de los discípulos que no están en ese nivel. 

<em>Renuncia de Responsabilidad:</em> No soy miembro de la Hermandad de la
Discordia. No conozco su terminología, ni me importa. Solo los estoy
usando como ejemplo.  Por favor, mandad todos los frutos de vuestros
arrebatos de ira a

Los niveles son:

<enum>

<item><bf>El nivel externo</bf>. Éste es el nivel que se enseña a
cualquiera.  Básicamente es un rollo patatero sobre Eris, Diosa de la
Discordia, y un montón de chorradas más. 

<item><bf>Iniciado</bf>. Este es el nivel para la gente que ha pasado del
nivel externo. Aquí es donde se les dice que la discordia y la estructura
son realmente una, y que Eris es también Jehová. 

<item><bf>Adepto</bf>. Aquí es donde se encuentra el <em>verdadero</em>
plan. En este nivel se guarda toda la información de cómo la Sociedad de
la Discordia va a dominar el mundo gracias a un diabólico, aunque jocoso,
plan que implica a Newt Gingrich, los Cereales Wheaties, O.J. Simpson, y
quinientos cristales de cuarzo erróneamente etiquetados como de 6,5 MHz. 
</enum>

<sect2>Configuración de la Red
<p>

Las direcciones IP se disponen así:

<itemize>
<item>Una dirección es 192.168.2.255, que es la de difusión y por lo tanto
no utilizable. 
<item>23 de las 32 direcciones IP se asignan a las 23 máquinas accesibles
desde la Internet. 
<item>Una dirección IP extra es para una máquina LiNUX en esa red.
<item>Una dirección IP extra es para otra máquina LiNUX en esa red.
<item>Dos direcciones IP son para el router que los conecta con la Internet.
<item>Cuatro se dejan sin usar, pero se les asignan los nombres paul,
ringo, john, y george, sólo para confundir las cosas un poco. 
<item>Las dos redes protegidas tienen direcciones del tipo 192.168.2.xxx .
</itemize>

Entonces se instalan dos redes, cada una en una habitación separada.  Se
utilizan Ethernets de infrarrojos, de tal manera que son completamente
invisibles desde la habitación exterior. Por suerte, la Ethernet de
infrarrojos funciona como la normal (o eso creo), de modo que podemos
pensar en ellas como si fueran Ethernets normales. 

Cada una de esas redes se conecta a una de las máquinas LiNUX a las que se
asignaron las direcciones IP extras. 

Hay un servidor de ficheros que conecta las dos redes protegidas. Esto se
debe a que los planes para dominar el mundo implican a algunos de los
iniciados de mayor nivel. El servidor de ficheros tiene la dirección
<tt>192.168.2.17</tt> para la red de iniciados, y la <tt>192.168.2.23</tt>
para la de adeptos. Tiene que tener dos direcciones dado que tiene dos
tarjetas Ethernet. Tiene <bf>deshabilitado</bf> el reenvio de paquetes IP. 

El reenvio de paquetes IP también está deshabilitado en los dos LiNUXes.
El router no encaminará paquetes con destino 192.168.2.xxx a menos que se
le diga explícitamente, así que la Internet en ningún caso podría acceder
al interior. La razón para deshabilitar el reenvio de paquetes IP aquí es
para que los paquetes de la red de adeptos no lleguen a la de iniciados y
viceversa. 

El servidor de NFS puede ser configurado para ofrecer diferentes ficheros
a las diferentes redes. Esto puede venir al pelo, y unos pocos trucos con
enlaces simbólicos pueden hacer que se compartan los ficheros comunes
entre todos. Con esta configuración y otra tarjeta Ethernet, el mismo
servidor de ficheros puede dar servicio a las tres redes. 

<sect2>El Servidor Proxy
<p> 

Dado que los tres niveles quieren rastrear la Internet para sus propios y
diabólicos propósitos, los tres necesitan tener acceso a ella. La red
externa está conectada directamente a la Internet, luego no tenemos que
hacer nada. Las redes de adeptos e iniciados están detrás de sendos
cortafuegos, luego es necesario instalar servidores proxy para ellas. 

Las dos redes se configurarán de forma muy parecida. Ambas tienen las
mismas direcciones IP asignadas. Añadiré un par de requisitos para hacerlo
más interesante: 
 
<enum>

<item>No se debe poder usar el servidor de ficheros para acceder a la
Internet Esto le expone a virus y otras cosas desagradables, y es bastante
importante. 

<item>No permitiremos a los Iniciados acceso al World Wide Web. Están
formándose, y la adquisición de ese tipo de información podría resultar
dañina. 

</enum>

Así, el fichero <tt/sockd.conf/ en el LiNUX de los iniciados tendrá esta
línea:

<tscreen><verb>
deny 192.168.2.17 255.255.255.255
</verb></tscreen>

y en la máquina de los adeptos:

<tscreen><verb>
deny 192.168.2.23 255.255.255.255
</verb></tscreen>

Y, el LiNUX de los iniciados tendrá esta línea

<tscreen><verb>
deny 0.0.0.0 0.0.0.0 eq 80
</verb></tscreen>

Que dice que se deniegue a todas las máquinas el acceso al puerto igual
(<em>eq</em>) a 80, el puerto del http. Esto aún permitirá el acceso a
otros servicios, sólo impedirá el acceso al Web. 

Además, ambos ficheros contendrán:

<tscreen><verb>
permit 192.168.2.0 255.255.255.0
</verb></tscreen>

para permitir a todos los ordenadores de la red 192.168.2.xxx usar este
servidor proxy, excepto aquello que ya ha sido prohibido (esto es:
cualquier acceso desde el servidor de ficheros y el acceso al Web desde la
red de iniciados) 

El fichero <tt/sockd.conf/ de los iniciados será más o menos:

<tscreen><verb>
deny 192.168.2.17 255.255.255.255
deny 0.0.0.0 0.0.0.0 eq 80
permit 192.168.2.0 255.255.255.0
</verb></tscreen>

y el de los adeptos será más o menos:

<tscreen><verb>
deny 192.168.2.23 255.255.255.255
permit 192.168.2.0 255.255.255.0
</verb></tscreen>

Con esto todo debería estar configurado correctamente. Cada red está
aislada como corresponde, con el grado apropiado de interacción. Todo el
mundo debería estar contento. Ahora, <em>cuidado con los cristales de 6,5
MHz...</em>

<sect>Anexo: El INSFLUG <label id="Grupos">
<p>

El <em/INSFLUG/ forma parte del grupo internacional 
<it/Linux Documentation Project/, 
encargándose de las traducciones al castellano de los Howtos (Comos),
así como la producción de documentos originales en aquellos casos
en los que no existe análogo en inglés.

En el <bf/INSFLUG/ se orienta preferentemente a la traducción de documentos
breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de
<bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc.

Diríjase a la sede del INSFLUG para más información al respecto.

En la sede del INSFLUG encontrará siempre las <bf/últimas/ versiones 
de las traducciones:  <tt><htmlurl url="http://www.insflug.org" 
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última versión 
disponible en el Insflug antes de bajar un documento de un servidor réplica.

Se proporciona también una lista de los servidores
réplica (<it/mirror/) del Insflug más cercanos a Vd.,  
e información relativa a otros recursos en castellano.

Francisco José Montilla, <tt><htmlurl url="mailto:pacopepe@insflug.org"
name="pacopepe@insflug.org"></tt>.
</article>
