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 Howto se cubrirán las bases de lo que es un cortafuegos, cómo configurar uno, qué servidores proxy hay, cómo configurarlos, y las aplicaciones de esta tecnología fuera del campo de la seguridad.
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. ˇˇˇPOR FAVOR, COMUNICADME CUALQUIER INEXACTITUD EN ESTE DOCUMENTO!!! 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 drig@execpc.com
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í.
Nota del Traductor: y yo menos.
(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).
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.
En breve, 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 drig@execpc.com
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.
Las herramientas para cortafuegos de TIS 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 Software para Cortafuegos se habla más de las herramientas de TIS.
Cortafuegos 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 cortafuegos 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í:
Ahora hay dos redes distintas que comparten un ordenador. El ordenador
cortafuegos, al que de ahora en adelante llamaremos "cortafuegos"
, 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 "Gusano de Internet"
, simplemente no podrá alcanzarla. Con
esto se consigue una protección excelente.
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 cortafuegos
y desde allí realizar todo el acceso a Internet es una
restricción muy seria. Programas como Netscape (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 Servidor Proxy.
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, drig
, estuviera dentro de la red
protegida y quisiera ver el Web con Netscape, pondría un servidor
proxy en el cortafuegos
. 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 TIA o TERM 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. No dejan que nadie entre a través de ellos.
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é.
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
Howto del Núcleo, al Howto de la Ethernet, y al Howto del NET-2.
Luego teclearía "make config"
:
Las opciones requeridas son:
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.
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 cortafuegos
que
usamos para la conexión PPP. Asignamos 192.168.2.1 a la tarjeta
Ethernet del cortafuegos
. Asignamos a las otras máquinas de la red
protegida cualquier dirección del rango anterior.
Lo primero es hacer ping a la internet desde el cortafuegos
. Yo antes
usaba nic.ddn.mil
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 Howto de Net-2 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 Howto del NET-2 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 cortafuegos
. 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 cortafuegos
desde dentro de la red protegida. No debe funcionar. Si funciona es
que no hemos deshabilitado el Reenvio del Paquetes IP 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 cortafuegos
. Llegados a este punto, no debería haber
problemas.
Ya tenemos una disposición de cortafuegos básica.
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:
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 # al comienzo de la linea
que se refiera a él. Después hay que mandar una señal SIG-HUP al
proceso inetd tecleando "kill -HUP <pid>", donde <pid> es el número de
proceso de inetd. Esto hará que inetd relea su fichero de
configuración (inetd.conf) y se reinicie. Lo comprobaremos haciendo un
telnet al puerto 15 del cortafuegos
, el puerto de netstat. Si aparece
la respuesta de netstatd, no hemos reiniciado inetd correctamente.
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 "socks", que implementa un servidor proxy
. Sin embargo, existe
otro par de programas que hay que tomar en consideración. Ahora les
daremos un rápido repaso.
TIS ha sacado una colección de programas para facilitar la realización
de cortafuegos. Básicamente, los programas hacen lo mismo que el
paquete Socks, pero tiene una estrategia de diseño diferente. Mientras
que Socks
tiene un único programa que cubre todas las operaciones de
la Internet, TIS
provee un programa para cada utilidad que quiera usar
el cortafuegos.
Para compararlos mejor, veamos el ejemplo del acceso al Web y por
Telnet.
Con Socks
, hay que hacer un fichero de configuración y poner en marcha
un demonio. Mediante ese fichero y ese demonio se activan tanto el
Telnet
como el Web
, así como cualquier otro servicio que no se haya
desactivado
explícitamente.
Con las herramientas TIS
, se arranca un demonio para el Web
y otro
para el Telnet
, 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 "para todo" 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. Socks
permite ser desidioso. Con un servidor de Socks
mal
configurado la gente de dentro tiene más acceso a la Internet del que
se quería. Con las herramientas TIS
, la gente del interior tiene
solamente el acceso que el administrador del sistema quiera que
tengan.
Socks
es más fácil de configurar, más fácil de compilar, y permite una
mayor flexibilidad. El juego de herramientas de TIS
es mas seguro si
se quiere controlar a los usuarios de dentro. Los dos proporcionan una
protección absoluta del exterior.
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:
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.
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.
Digamos, por ejemplo, que eres el líder de la Vigésimo Tercera Hermandad de la Discordia de Milwaukee. 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.
Renuncia de Responsabilidad: 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:
Las direcciones IP se disponen así:
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 192.168.2.17
para la red de iniciados, y la 192.168.2.23
para la de adeptos. Tiene que tener dos direcciones dado que tiene
dos tarjetas Ethernet. Tiene deshabilitado 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.
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:
Así, el fichero sockd.conf en el LiNUX de los iniciados tendrá esta línea:
deny 192.168.2.17 255.255.255.255
y en la máquina de los adeptos:
deny 192.168.2.23 255.255.255.255
Y, el LiNUX de los iniciados tendrá esta línea
deny 0.0.0.0 0.0.0.0 eq 80
Que dice que se deniegue a todas las máquinas el acceso al puerto igual (eq) 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:
permit 192.168.2.0 255.255.255.0
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 sockd.conf de los iniciados será más o menos:
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
y el de los adeptos será más o menos:
deny 192.168.2.23 255.255.255.255
permit 192.168.2.0 255.255.255.0
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, cuidado con los cristales de 6,5 MHz...
Francisco José Montilla,
pacopepe@nova.es
, FidoNet 2:345/402.22
es coordinador del INSFLUG: (Impatient & Novatous Spanish Fidonet LiNUX Users Group) uno de los
varios grupos de usuarios existentes en España, y más concretamente en la mejor
;-) área de FidoNet: R34.LINUX
junto con LuCas (LinUx en CAStellano).
El INSFLUG se orienta preferentemente a la traducción de documentos breves, como los Howtos y FAQs, etc.
LuCas Coordina y realiza las traducciones de las guides, es decir, documentos más extensos.
Por supuesto, la orientación de cada grupo no tiene carácter excluyente; si quieres colaborar en las dos, ˇmejor! ;-).
Actualmente están siendo traducidos varios HOWTOs y FAQs, además de las ``guides''; Esto es lo que hay traducido hasta ahora:
Otra fuente de información obligada para el recién incorporado son las FAQ
elaboradas a partir del correo circulante por R34.LINUX
por Pablo Gómez,
pgomez@p12.laereas.encomix.com
, 2:341/43.40
,
disponibles próximamente en los formatos habituales de documentación (ps, dvi,
html, sgml, etc) en los servidores de Internet especificados más adelante, así
como en el mismo área.
Actualmente están siendo traducidos varios Howtos y FAQs, así como está llevándose a cabo la traducción de la Network Administrators Guide por el grupo LuCas. ˇNecesitamos tu colaboración para futuras traducciones! si quieres unirte a nosotros ponte en contacto con:
INSFLUG:
Francisco José Montilla,
pacopepe@nova.es
, FidoNet 2:345/402.22
LuCas:
jjamor@gedeon.ls.fi.upm.es
, FidoNet 2:341/12.19
alfon@bipv02.bi.ehu.es
, FidoNet 2:344/17.2
Un buen punto de búsqueda, consulta, y obtención de la documentación traducida,
en formato HTML, con links a los demás formatos, es la página personal de Juan
José Amor:
http://lml.ls.fi.upm.es/~jjamor/
Puedes obtener los documentos en todos los formatos de los siguientes servidores:
FidoNet:
Elektra (95) 4164934/4161749 28k8/14k4
La Voix (95) 4275081/4275321 28k8/14k4
Actualmente, ambos grupos poseen las siguientes listas de correo:
lucas@bipv02.bi.ehu.es
insflug@nova.es
Por último, recordarte que un inmejorable lugar para estar informado, así como consultar y discutir todo
lo relacionado con LiNUX lo tienes en FidoNet, en R34.LINUX
.