Вы находитесь на странице: 1из 49

Shorewall

Instalacin y Actualizacin de Shorewall Importante Antes de actualizar, asegrese de revisar Problemas al Actualizar. Nota Los RPM de Shorewall estn firmados. Para evitar alertas tales como la siguiente warning: shorewall-3.0.1-1.noarch.rpm: V3 DSA signature: NOKEY, key ID 6c562ac4 descargue la llave GPG de Shorewall y ejecute el siguiente comando: rpm --import shorewall.gpg.key Instalar usando RPM Para instalar Shorewall usando RPM:

1. Asegrese que tiene el paquete RPM correcto


El paquete RPM estandar descargado desde shorewall.net y sus espejos se sabe funciona con SuSE, Power PPC, Trustix y TurboLinux. Tambin hay paquetes RPM provisto por Simon Matter que estn ajustados para RedHat/Fedora y otro paquete de Jack Coates que est personalizado para Mandrake. Todos estos estn disponibles en la pgina de descarga. Si intenta instalar el paquete equivocado, probablemente no funcione. 2. Instale el RPM rpm -ivh <shorewall rpm> Precaucin Algunos usuarios tienen el hbito de usar el comando rpm -U para instalar como para actualziar paquetes. Si usa este comando cuando instale el RPM Shorewall entonces tendr que manualmente habilitar Shorewall para se inicie al arranque del sistema usando chkconfig, insserv o cualquiera sea el utilitario para manipular los enlaces simblicos. Nota Algunos usuarios SuSE han encontrando un problema en donde rpm reporta un conflicto con kernel <= 2.2 incluso si un kernel 2.4 est instalado. Si esto sucede, simplemente use la opcin --nodeps de rpm. rpm -ivh --nodeps <shorewall rpm> Nota Shorewall depende del paquete iproute. Desafortunadamente algunas distribuciones llaman a este paquete iproute2 lo que provoca que la instalacin de Shorewall falle con el mensaje diagnstico:

error: failed dependencies:iproute is needed by shorewall-2.2.x-1 Este problema no debiera ocurrir si est usando el paquete RPM correcto (vea 1., arriba) pero puede resolverse dndole la vuelta usando la opcin --nodeps de rpm. rpm -ivh --nodeps <shorewall rpm>

3. Edite los archivos de configuracin para ajustarse a sus necesidades de configuracin.


Alerta USTED NO PUEDE SIMPLEMENTE INSTALAR EL RPMY MANDAR EL COMANDO shorewall start . SE REQUIERE DE CONFIGURACION ANTES DE QUE EL FIREWALL PUEDA ARRANCAR. SI ENVIA EL COMANDO start Y EL FIREWALL FALLA EN ARRANCAR, SU SISTEMA NO ACEPTARA NINGUN TRAFICO DE RED. SI ESTO SUCEDE, USE EL COMANDO shorewall clear PARA RESTAURAR LA CONECTIVIDAD DE RED.

4. Habilite el inicio eliminando el archivo /etc/shorewall/startup_disabled (Si est usando Shorewall 2.1.3 o
5. posterior, edite /etc/shorewall/shorewall.conf y ponga STARTUP_ENABLED en Yes). Arranque el firewall tipeando shorewall start Instalar usando tarball Para instalar Shorewall usando el tarball y el guin de instalacin: 1. desempaque el tarball (tar -zxf shorewall-x.y.z.tgz). 3.0.0). Tipee: ./install.sh

2. cd al directorio shorewall (la versin est condificada en el nombre del directorio como en shorewall3.

4. Edite los archivos de configuracin para ajustarse a sus necesidades de configuracin. 5. Habilite el inicio editando /etc/shorewall/shorewall.conf y poniendo STARTUP_ENABLED en Yes).
6. Arranque el firewall tipeando shorewall start

7. Si el guin install no fue capaz de configurar Shorewall para arrancarse automticamente al arrancar el
sistema (boot), vea estas instrucciones. Instalar usando .lrp Para instalar mi versin de Shorewall en un disco fresco de Bering, simplemente remplace el archivo shorwall.lrp en la imagen con el arhivo que descarg. Por ejemplo, si descarga shorewall-lrp-2.2.0.tgz entonces deber renombrar el archivo a shorwall.lrp y remplazar el archivo de ese nombre en el disco Bering con el nuevo. Entonces proceda a configurar Shorewall como se describe en la documentacin Bering (o Bering uClibc). Instalar usando .deb

Importante Una vez que ha instalado el paquete .dev y antes de intentar configurar Shorewall, por favor lea el concejo de Lorenzo Martignoni, el Mantenedor de Shorewall Debian: Para ms informacin acerca del uso de Shorewall en sistemas Debian, mire en /usr/share/doc/shorewall/README.Debian provisto por el paquete Debian de shorewall. La forma ms fcil de instalar Shorewall en Debian es usar use apt-get: apt-get install shorewall Para asegurar que est instalando la ltima versin de Shorewall, por favor modifique su archivo /etc/apt/sources.list como se describe aqu. Una vez que haya completado la configuracin Shorewall, puede habilitar el arranque de Shorewall al arranque del sistema (boot) poniendo startup=1 en /etc/default/shorewall. Notas Generales Acerca de la Actualizacin Shorewall La mayora de los problemas asociados con las actualizaciones tienen su origen en dos causas: El usuario no ley y sigui las consideraciones de migracin en las notas de liberacin (estos se reproducen en Problemas al Actualizar Shorewall). El usuario no manej bien el archivo /etc/shorewall/shorewall.conf durante la actualizacin. Shorewall est diseado para tener un comportamiento por omisin persistente a lo largo de la evolucin del producto. Para que esto sea posible, el diseo asume que usted no remplazar su archivo shorewall.conf actual durante las actualizaciones. Se recomienda que despus de instalar por primera vez Shorewall modifique /etc/shorewall/shorewall.conf tal que prevenga que el manejador de paquetes lo sobrescriba durante subsiguientes actualizaciones (ya que hay que agregar STARTUP_ENABLED, tal modificacin asegura que usted debe manualmente cambiar los ajustes de esta opcin). Si se siente realmente impulsado a tener los ltimos comentarios y opciones en su shorewall.conf entonces proceda con cuidado. Debera determinar cules nuevas opciones han sido agregadas y debe reajustar sus valores (e.g. OPTION=""); de otra forma, obtendr un comportamiento diferente al que espera.

Actualizando con RPM Si ya tiene el RPM Shorewall instalado y est actualizando a una nueva versin:

1. Asegrese de tener el paquete RPM correcto


El paquete estandar RPM de shorewall.net y sus espejos se saben funcionan con SuSe, Power PPC, Trustix y TurboLinux. Hay tambin un paquete RPM provisto por Simon Matter que ha sido ajustado para RedHat/Fedora y otro paquete provisto por Jack Coates que est personalizado para Mandrake. Si intenta usar el paquete equivocado, probablemente no funcione. 2. Actualice el RPM rpm -Uvh <shorewall rpm file> Nota Algunos usuarios SuSE han encontrado un problema donde rpm reporta un conflicto con kernel <= 2.2 an cuando est instalado un kernel 2.4. Si esto sucede, simplemente use la opcin --nodeps de rpm.

rpm -Uvh --nodeps <shorewall rpm> Nota A partir de Shorewall 1.4.0, Shorewall depende del paquete iproute. Desafortunadamente algunas distribuciones llaman a este paquete por otro nombre iproute2 lo que causa que Shorewall falle con el mensaje diagnstico: error: failed dependencies:iproute is needed by shorewall-1.4.0-1 A esto se le puede dar la vuelta usando la opcin --nodeps de rpm. rpm -Uvh --nodeps <shorewall rpm> 3. Vea si hay alguna incompatibilidad entre su configuracin y la nueva versin de Shorewall y corrija si es necesario. shorewall check 4. Reinicie el firewall. shorewall restart Actualizando con tarball Si ya tiene instalado Shorewall y est actualizando a una nueva versin usando tarball: 1. desempaque el tarball. tar -zxf shorewall-x.y.z.tgz

2. cd al directorio shorewall (la versin est codificada en el nombre del directorio como en shorewall3. 3.0.1). Tipee: ./install.sh 4. Vea si hay alguna incompatibilidad entre su configuracin y la nueva versin de Shorewall y corrija si es necesario. shorewall check 5. Arranque el firewall tipeando shorewall start

6. Si el guin isntall no fue capaz de configurar Shorewall para su arranque automtico al arrancar el sistema
(boot), vea estas instrucciones. Actualizando con .lrp Lo siguiente fue contribucin de Charles Steinkuehler en la lista de correos Leaf:

Es *MUY* simple...slo ponlo en un nuevo CD y reinicia! :-) De hecho, slo bromeo ligeramente...as es exactamente como actualizo mis firewalls de produccin. La facilidad de respaldo parcial que agregue a Dachstein permite que los datos de configuracin sean almacenados separadamente del resto del paquete. Una vez que los datos de configuracin estn separados del resto del paquete, es fcil actualizar el paquete mientras mantiene su configuracin actual (en mi caso, insertando un CD y reiniciando). Los usuarios que no estn corriendo con mltiples rutas de paquetes y usan respaldos parciales tambin pueden actualizar un paquete, slo toma un poco ms de trabajo. La idea general es usar el respaldo parcial para salvar su configuracin, remplazar el paquete y restaurar sus viejos archivos de configuracin. Instrucciones paso-a-paso para una forma de hacer esto (asumiendo un sistema convencional de un-floppy LEAF) sera: Haga una copia de respaldo de su disco de firewall ('NUEVO') . Este es el disco al que agregar el paquete actualizado. Dele formato a un floppy para usarlo como ubicacin temporal para sus archivos de configuracin ('XFER'). Este disco debera tener el mismo formato que el disco del firewall (y simplemente pudiera ser simplemente otra copia de respaldo de firewall actual). Asegrese de tener una copia qeu funcione de su fierwall ('VIEJO') en algn lugar seguro, que *NO* usar durante este proceso. De esta forma si algo sale mal, usted simplemente reinicia con el disco VIEJO para volver a una configuracin que funciona. Remueva su disco actual de configuracin de firewall y remplcelo con el disco XFER. Use el men de respaldo lrcfg para ahcer un respaldo parcial del paquete que desea actualizar, estando seguros acerca de los archivos en el disco XFER. A partir del men de respaldo: t e <enter> p <enter> b <package1> <enter> b <package2> <enter> ... Descargue y copie el paquete que desea actualizar en el disco NUEVO. Reinicie su firewall usando el disco NUEVO...en este punto su actualizacin tendr su configuracin por omisin. Monte el disco XFER (mount -t msdos /dev/fd0u1680 /mnt) CD al directorio raz (cd /) Extraiga manualmente los datos de configuracin para cada paquete que actualiz: tar -xzvf /mnt/package1.lrp tar -xzvf /mnt/package2.lrp ... Desmonte (umount /mnt) y retire el disco XFER Usando lrcfg, haga respaldos *FULL* de sus paquetes actualizados. Reinicie verificando que el firewall funciona como se espera. Algunos archivos de configuracin puede que necesiten ser 'entonados' para que funcionen apropiadamente con los binarios actualizados del paquete.

Importante El nuevo archivo paquete <paquete>.local puede usar para entonar cules archivos estn incluidos (y excluidos) del respaldo parcial (vea el Dachstein-CD README para ms detalles). Si este archivo no existe, los guiones de respaldo asumirn que cualquier cosa del archivo <package>.list que reside en /etc o /var/lib/lrpkg es parte de los datos de configuracin y se usa para crear el respaldo parcial. Si Shorewall pone algo en /etc que no sea un archivo de configuracin modificado por el usuario, debera crearse un archivo apropiado shorwall.local antes de hacer el respaldo parcial [Nota del Editor: Shorewall coloca slo archivos modificables por el usuario en /etc].

Nota Es obviamente posible hacer lo anterior 'en-sitio', sin usar mltiples discos, e incluso sin hacer respaldos parciales (ie: copiar archivos de configuracin actuales a /tmp, manualmente extraer el nuevo paquete sobre el firewall que est corriendo, luego copiar o fusionar los datos desde /tmp y/o respaldo...o similar), pero para cualquiera que sea capaz de toda esa gimnasia en la lnea de comandos es probable que lo pueda hacer sin ningn tipo de instrucciones detalladas :-) Para ms informacin de otras herramientas de actualizacin LEAF/Bering mire en este artculo de Alex Rhomberg. Configurando Shorewall Usted necesitar editar algunos o todos los archivos de configuracin para lograr la configuracin deseada. En la mayora de los casos las Guas Rpidas de Shorewall contienen toda la informacin que usted necesita para comenzar. Desinstalar/VolverAtrs Vea VolverAtrs y Desinstalar.

Firewall Bsico Dos-Interfaces

Introduccin El configurar un sistema Linux como firewall para una red pequea es relativamente una tarea simple si entiende los principios bsicos y sigue la documentacin. Esta gua no intenta profundizar en todas las facilidades de Shorewall. A cambio se enfoca en lo que se requiere para configurar Shorewall en su configuracin ms comn: Sistema Linux usado como firewall/router para una red local pequea. Un nica direccin IP pblica. Si tiene ms de una direccin IP pblica, esta no es la gua que desea -- vea la Gua de Configuracin de Shorewall . Conexin Internet por cable modem, DSL, ISDN, Frame Relay, discada...

Aqu se muestra un esquemtico de una instalacin tpica: Figura 1. Configuracin comn de firewall con dos interfaces

Precaucin Si edita sus archivos de configuracin en un sistema Windows , usted salvarlos como archivos Unix si su editor soporta esta opcin o debe pasarlo por el programa dos2unix antes de intentar de usarlos. De forma similar, si copia un archivo de configuracin del disco duro en Windows a un disco flexible, debe pasarlos por dos2unix antes de usarlos con Shorewall. Versin Windows de dos2unix Versin Linux de dos2unix

Requerimientos de Sistema Shorewall requiere que tenga instalado el paquete iproute/iproute2 (en RedHat, el paquete se llama iproute). Usted puede saber si este paquete est instalado por la presencia del programa ip en su sistema firewall. Como root, puede usar el comando which para verificar este programa: [root@gateway root]# which ip /sbin/ip [root@gateway root]# Se le recomienda primero leer a lo largo de la gua para familiarizarse con los tpicos involucrados para luego volver sobre ella y hacer los cambios de configuracin. Convenciones Los puntos en los cuales se recomiendan cambios de configuracin estn sealadas.

Las notas de configuracin que son nicas de LEAF/Bering est marcadas con

PPTP/ADSL Si tiene un Modem ADSL y usa PPTP para comunicarse con un servidor en ese modem, usted debe hacer los cambios que se recomiendan aqu en adicin a los que se explican abajo. ADSL con PPTP se encuentra frecuentemente en Europa y notable Austria. Conceptos Shorewall Los archivos de configuracin de Shorewall estn en el directorio /etc/shorewall -- para configuraciones simples encontrar que slo necesitar lidiar con algunos de ellos como se describe en esta gua. Alerta Nota para los Usuarios Debian Si instala usando .deb encontrar que su directorio /etc/shorewall est vaco. Esto es intencional. El esqueleto de archivos de configuracin se pueden encontrar en su sistema en el directorio /usr/share/doc/shorewall/default-config. Simplemente copie los archivos que necesite desde ese directorio a /etc/shorewall y modifique las copias. Note que debe copiar /usr/share/doc/shorewall/default-config/shorewall.conf y /usr/share/doc/shorewall/defaultconfig/modules a /etc/shorewall incluso si no planea modificarlos. Importante Despus que tiene instalado Shorewall, localice las muestras two-interfaces: 1. Si instal usando RPM, las muestras estarn en el subdirectorio Samples/two-interfaces/ del directorio de documentacin de Shorewall. Si no sabe donde est el directorio de documentacin Shorewall, puede encontrarlo usando el siguiente comando: ~# rpm -ql shorewall | fgrep two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/masq /usr/share/doc/packages/shorewall/Samples/two-interfaces/policy /usr/share/doc/packages/shorewall/Samples/two-interfaces/routestopped /usr/share/doc/packages/shorewall/Samples/two-interfaces/rules /usr/share/doc/packages/shorewall/Samples/two-interfaces/zones ~# 2. 3. Si instal usando el tarball, las muestras estn en el directorio Samples/two-interfaces en el tarball. Si instal usando .deb, las muestras estn en /usr/share/doc/shorewall/examples/two-interfaces.

En la medida que se explica cada archivo le sugerimos que vea el archivo en cuestin en su sistema -- cada archivo contiene instrucciones detallads de configuracin y entradas por omisin. Shorewall ve la red sobre la cual trabaja como si estuviera compuesta de un conjunto de zonas. En la configuracin de muestra two-interface, se usan los siguientes nombres de zonas: #ZONE TYPE # fw firewall net ipv4 loc ipv4 OPTIONS OPTIONS IN OUT OPTIONS

Las zonas se definen en el archivo /etc/shorewall/zones . Note que Shorewall reconoce el sistema firewall como su propia zona - cuando se procesa el archivo /etc/shorewall/zones , el nombre de la zona firewall se almacena en la variable shell $FW que puede usarse para referirse a la zona del firewall a lo largo de la configuracin de Shorewall. Las reglas acerca del trfico a permitir o rechazar se expresan en trminos de zonas. Usted expresa su poltica por omisin para las conexiones desde una zona a otra en el archivo /etc/shorewall/policy . Usted define excepciones para dichas polticas por omisin en el archivo /etc/shorewall/rules .

Para cada solicitud de conexin que ingresa al firewall, la solicitud se verifica primero contra el archivo /etc/shorewll/rules . Si no aplica ninguna regla para la solicitud de conexin entonces la primera poltica en /etc/shorewall/policy que coincida se aplica. Si hay una accin comn definida para la poltica en /etc/shorewall/actions o /usr/share/shorewall/actions.std entonces esa accin se ejecuta antes de la poltica. El archivo /etc/shorewall/policy que se incluye con la muestra two-interface tiene las siguientes polticas: #SOURCE loc net net all all all DEST POLICY ACCEPT DROP info REJECT info LOG LEVEL LIMIT:BURST

En la muestra two-interface, la lnea abajo est incluida pero est comentada. Si desea que su sistema firewall tenga acceso completo a los servidores en internet, quite el comentario a esa lnea. #SOURCE DEST POLICY $FW net ACCEPT Las polticas anteriores: Permitirn todas las solicitudes de conexiones desde la red local hacia internet Desacartn (ignorarn) todas las solicitudes de conexin desde internet hacia su firewall o red local Opcionalmente aceptar todas las solicitudes de conexiones desde el firewall hacia internet (si levant el comentario de la poltica adicional) Rechazarn todas las otras solicitudes de conexin. LOG LEVEL LIMIT:BURST

Es importante notar que las polticas Shorewal (y las reglas) refieren a conexiones y no flujo de paquetes. Con las polticas definidas en el archivo /etc/shorewall/policy como se muestra arriba, las conexiones se permiten desde la zona loc a la zona net incluso aunque no esten permitidas las conexiones desde la zona loc al propio firewall. En este punto, edite su /etc/shorewall/policy y haga los cambios que considere. Interfaces de Red

El firewall tiene dos interfaces de red. Donde si bien la conectividad es a travs de cable modem o "Modem" DSL", la Interface Externa ser el adaptador ethernet que se encuentre conectado a dicho "Modem" (e.g., eth0) a menos que conecte va Point-to-Point Protocol over Ethernet (PPPoE) o Point-to-Point Tunneling Protocol (PPTP) en cuyo caso la Interface Externa ser una interface ppp (e.g., ppp0). Si conecta por un modem regular, su Interface Externa tambin ser ppp0. Si conecta usando ISDN su interface externa ser ippp0.

Si su interface externa es ppp0 o ippp0 entonces querr poner CLAMPMSS=yes en /etc/shorewall/shorewall.conf. Su Interface Interna ser un adaptador ethernet (eth1 o eth0) y conectar a un hub o switch. Sus computadores se conectarn al mismo hub/switch (nota: Si tiene un nico sistema interno, puede conectarlo directamente al firewall usando un cable cruzado).

Alerta No conecte la interface interna y externa al mismo hub o switch exceptuado para pruebas. Usted puede probar usando este tipo de configuracin si especifica la opcin arp_filter o la opcin arp_ignore en /etc/shorewall/interfaces para todas las interfaces comunes al mismo hub/switch. Usando tal configuracin con un firewall en produccin no es para nada recomendable.

La muestra two-interface de Shorewall asume que la interface externa es eth0 y que la interface interna es eth1. Si su configuracin difiere tendr que modificar la muesta acordemente en el archivo /etc/shorewall/interfaces . Mientra est ah puede revisar la lista de opciones que le son especficas para las interfaces. Algunas pistas: Tip Si su interface externa es ppp0 o ippp0, puede remplazar en la segunda columna detect con - (sin las comillas). Tip Si su interface externa es ppp0 o ippp0 o si tiene una direccin IP esttica, puede eliminar dhcp de la lista de opciones. Tip Si su interface interna es un puente (bridge) cree If your internal interface is a bridge create using the brctl utility then you must add the routeback option to the option list. Direcciones IP Antes de seguir avanzando debemos decir unas cuantas palabras acerca de las direcciones Internet Protocol (IP). Normalmente su ISP le asignar una nica direccin IP Pblica. Esta direccin puede ser asignada va Dynamic Host Configuration Protocol (DHCP) o como parte del establecimiento de su conexin cuando disca (modem estandar) o establece su conexin PPP. En raras ocasiones su ISP le asignar una direccin IP esttica, esto significa que usted configurar la interface exerna de su firewall para usar permanentemente esa direccin. Sin embargo, su direccin IP asignada ser compartida por todos sus sistemas cuando accedan a Internet. Usted tendr que asignar sus propias direcciones en su red interna (la Interface Interna en su firewall ms las otras computadores). El RFC 1918 reserva varios rangos de direcciones Privadas IP para ese propsito: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255

Antes de arrancar Shoreall, usted debe ver la direccin IP de su interface externa y si es una dentro de los rangos descritos arriba, debera quitar la opcin 'norfc1918' de la entrada que corresponde a su interface externa en /etc/shorewall/interfaces. Usted querr asignar sus direcciones desde la misma subred. Para nuestros propsitos, podemos considerar una subred que consista de un rango de direcciones x.y.z.0 - x.y.z.255. Tal subred tendr una mscara de red de 255.255.255.0. La direccin x.y.z.0 se reserva como la Direccin de Subred y x.y.z.255 se reserva como la Direccin de Difusin de la Subred (Boradcast). En Shorewall, una subred se describe usando la notacin Classless InterDomain Routing (CIDR) que consiste de direcciones de subred seguida de /24. El 24 se refiere a la cantidad de "1" consecutivos a la cabeza de la mscara de red. Rango: 10.10.10.0 - 10.10.10.255

Direccin de Subred: Notacin CIDR:

10.10.10.0 10.10.10.0/24

Direccin de Difusin: 10.10.10.255 Es convencin asignarle la primera direccin utilizable en la subred a la interface interna (10.10.10.1 en el ejemplo anterior) o la ltima (10.10.10.254). Uno de los propsitos de hacer subredes es permitir a todas las computadoras en la subred entender qu otras computadoras pueden comunicarse con ellas directamente. Para comunicarse con sistemas fuera de la subre los sistemas deben enviar los paquetes a su detino final a travs de un gateway (enrutador).

Sus computadoras locales (computer 1 y computer 2 en el diagrama arriba) deben ser configuradas con el default gateway a la direccin IP de la interface interna del firewall. La discusin a continuacin repasa por encima los temas de subredes y enrutamiento. Si est interesado en aprender ms acerca del direccionamiento y el enrutamiento IP, si le recomienda altamente el libro IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13975483-0 (enlace). El resto de esta gua asume que tiene su red dispuesta de esta forma:

El default gateway para las computdores 1 y 2 sera 10.10.10.254. Alerta Su ISP puede que le asigne una direccin RFC 1918 para su interface externa. Si dicha direccin est en la subred 10.10.10.0/24 entonces tendr que seleccionar una subred DIFERENTE RFC 1918 para su red local. Enmascaramiento IP (SNAT) Las direcciones reservadas por el RFC 1918 son a veces referidas como no-ruteable debido a que los enrutadores en el corazn de Internet no se renvan los paquetes IP cuando tienen como destino una direccin RFC 1918. Cuando uno de su sistemas locales (digamos computer 1) enva una solicitud de conexin a una mquina en Internet, el firewall debe hacer Network Address Translation (NAT, Traduccin de Direccin de Red). El firewall rescribe la direccin de origen en el paquete para que sea la direccin de la interface externa del firewall; en otras palabras, el

firewall hace parecer que la solicitud de conexin fu originada en el propio firewall. Esto es necesario hacerlo para la maquina destino sea capaz de enrutar la respuesta de vuelta hasta el firewall (recuerde que los paquetes cuyos destinos es una direccin RFC 1918 no son enrutados a travs de internet para que la respuesta vuelva su origen en computer 1). Cuando el firewall recibe un paquete de respuesta, rescribe la direccin de destino de vuelta a 10.10.10.1 y enva el paquete a computer 1. En los sistemas Linux el proceso anterior es conocido como Enmascaramiento IP pero tambin ver el uso del trmino Source Network Address Translation (SNAT) . Shorewall sigue la convencin que usa Netfilter: Enmascaramiento (Masquerade) describe el caso donde se permite al sistema firewall detectar automticamente la direccin de la interface externa. SNAT se refiere al caso donde explcitamente especifica la direccin origen que desea usar en los paquetes salientes.

En Shorewall, tanto Enmascaramiento y SNAT se configuran con entradas en el archivo /etc/shorewall/masq . Normalmente usar Enmascaramiento si su direccin IP en la interface externa es dinmica y SNAT en el caso de direccin IP esttica.

Si la interface externa de su firewall es eth0, no se necesita modificar el archivo provisto con la muestra. De otra forma, edite /etc/shorewall/masq y cambie la primera columna para que refleje el nombre de su interface externa y la segunda columna el nombre de su interface interna.

Si su direccin IP externa es esttica, puede enterarla en la tercrea columna en /etc/shorewall/masq si desea si bien su firewall funcionar bien si no lo hace. Enterar su direccin IP esttica en la tercera columna hace que procesar los paquetes salientes sea un poco ms eficiente.

Si est usando el paquete Debian, por favor revise su archivo shorewall.conf para asegurarse que lo siguiente est escrito correctamente; si no es as, cmbielo apropiadamente: IP_FORWARDING=On

Desvo de Puerto (DNAT) Una de sus metas puede ser correr uno o mas servidores en sus sistemas locales. Ya que dichas computadoras tienen direcciones RFC-1918 , no es posible a los clientes en internet conectar directamente con ellas. En cambio es necesario para dichos clientes dirigir sus solicitudes de conexin hacia el firewall quien rescribe la direccin destino a la direccin de su servidor y enva el paquete al servidor. Cuando su servidor responde el firewall automticamente realiza SNAT para rescribir la direccin origen en la respuesta. El proceso anterior es llamado Desvo de Puerto o Port Forwarding o Destination Network Address Translation (DNAT). Usted puede configurar el desvo de puerto usando las reglas DNAT en el archivo /etc/shorewall/rules . La forma general de una regla de desvo de puerto simple en /etc/shorewall/rules es: #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:<server local ip address>[:<server port>] <protocol> <port>

Shorewall incorpora macros para muchas de las aplicaciones populares. Revise en /usr/share/shorewall/macro.* para identificar los macros disponibles en su versin. Los macros simplemente crean reglas DNAT suministrando el protocolo y puerto(s) como se muestra en los siguientes ejemplos. Ejemplo 1. Servidor Web Usted est corriendo un Servidor Web en computer 2 y desea desviar el puerto entrante TCP 80 a este sistema: #ACTION SOURCE DEST Web/DNAT net loc:10.10.10.2 Ejemplo 2. Servidor FTP Usted est corriendo un Servidor FTP en computer 1 tal que desea entonces desviar el puerto entrante TCP 21 a ese sistema: #ACTION SOURCE DEST FTP/DNAT net loc:10.10.10.1 PROTO DEST PORT(S) PROTO DEST PORT(S)

Para FTP necesitar adicionalmente el motor de seguimiento de conexiones y el soporte NAT en su kernel. Para los kernel provistos por el vendedor esto significa que los mdulos ip_conntrack_ftp y ip_nat_ftp deben ser cargados. Shorewall cargar automticamente dichos mdulos si estn disponibles y localizados en el lugar estandar bajo /lib/modules/<kernel version>/kernel/net/ipv4/netfilter. Un par de puntos importantes a mantener en mente son: Usted debe probar la regla anterior desde un cliente externe a su red local (i.e., no pruebe desde un explorador en los computadores 1 o 2 o en el firewall). Si desea ser capaz de acceder a su servidor web y/o ftp desde adentro de su fireall usando la direccin IP de su interface externa vea Shorewall FAQ #2. Muchos ISPs bloquean las solicitudes entrantes al puerto 80. Si tiene problemas conectndose a su servidor intente seguir la siguiente regla y conectar al puerto 5000. #ACTION SOURCE DEST PROTO DNAT net loc:10.10.10.2:80 tcp 5000 DEST PORT(S)

En este punto, modifique /etc/shorewall/rules para agregar cualquier regla DNAT que se requiera. Importante Cuando pruebe las reglas DNAT como las anteriores, debe realizar las pruebas desde un cliente AFUERA de su fiewall (en la zona 'net' ). Usted no puede probar estas reglas desde la parte interior del firewall. Para tips de Resolucin de Problemas con DNAT , vea FAQs 1a y 1b. Domain Name Server (DNS) Normalmente, cuando usted conecta con su ISP y como parte del proceso de obtener una direccin IP, el resolutor Domain Name Service (DNS) del firewall ser automticamente configurado (e.g., el archivo /etc/resolv.conf ser rescrito). Alternativamente su ISP puede darle la direccin IP de un par de servidores de nombre DNS para que manualmente los configure como servidores de nombre primario y secundario respectivamente. Sin importar la forma en cmo se configuran los servidores DNS en su firewall, es su responsabilidad configurar el resolutor en sus sistemas internos. Puede escoger uno de dos caminos:

Configura sus sistemas internos para que usen los servidores de nombre de su ISP. Si su ISP le ha suministrado las direcciones de sus servidores DNS o de otros disponibles en su sitio web, usted puede configurar sus sistemas internos para que usen dichas direcciones. Si dicha informacin no est disponible, vea en el archivo /etc/resolv.conf de su sistema firewall -- los servidores de nombre son declarados con los registros "nameserver" en este archivo. Puede configurar un Cache Servidor de Nombres en su firewall. Red Hat tiene un RPM para el cache servidor de nombres (el RPM tambin requier el RPM bind) y para los usuarios Bering , hay un dnscache.lrp. Si toma este camino, usted configurar sus sistemas internos para que usen el mismo firewall como su servidor primario (o nico) de nombres. Usara la direccin IP interna de su firewall (10.10.10.254 en el ejemplo anterior) como direccin del servidor de nombres. Para permitir a los sistemas locales hablar con el cache servidor de nombre, deber abrir el puerto 53 (ambos, UDP y TCP) desde la red local hacia el firewall; esto lo hace agregar las siguientes reglas en /etc/shorewall/rules. #ACTION SOURCE DEST DNS/ACCEPT loc $FW PROTO DEST PORT(S)

Otras Conexiones La muestra two-interface incluye las siguientes reglas: #ACTION SOURCE DEST DNS/ACCEPT $FW net PROTO DEST PORT(S)

Esta regla permite el acceso DNS desde su firewall y puede quitarse si ha quitado el comentario en la lnea de /etc/shorewall/policy que permite todas las conexiones desde el firewall hacia internet. En la regla que se muestra arriba, DNS/ACCEPT es un ejemplo de una invocacin macro. Shorewall incluye una cantidad de macros (vea /usr/share/shorewall/macro.*) y usted puede agregar los suyos. Usted no tiene que usar los macros cuando codifique las reglas en /etc/shorewall/rules; Shorewall arrancar ligeramente ms rpido si codifica sus reglas directamente en vez de usar macros. La regla anterior tambin pudo haber sido codificada as : #ACTION SOURCE DEST ACCEPT $FW net ACCEPT $FW net PROTO 53 53 DEST PORT(S)

udp tcp

En los casos donde Shorewall no incluya un macro que satisfaga sus necesidades, puede ya sea definir un nuevo macro o simplemente codificar las reglas apropiadas directamente. La muestra tambin incluye: #ACTION SOURCE DEST SSH/ACCEPT loc $FW PROTO DEST PORT(S)

Esta regla permite correr el servidor SSH en su firewall y conectarse a l desde los sistemas locales. Si desea habilitar otras conexiones desde su firewall a otros sistemas, el formato general usando macros es: #ACTION SOURCE <macro>/ACCEPT $FW DEST PROTO <destination zone> DEST PORT(S)

El formato general cuando no se usan macros predefinidos es: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW <destination zone> <protocol> <port>

Ejemplo 3. Servidor Web en el Firewall Usted desea correr un servidor Web en su sistema firewall: #ACTION SOURCE DEST Web/ACCEPT net $FW Web/ACCEPT loc $FW PROTO DEST PORT(S)

Estas dos reglas por supuesto seran un agregado a las reglas listadas arriba bajo Puede configurar un Cache Servidor de Nombres en su firewall. Si no sabe qu puerto y protcolo usa una aplicacin particular, mire aqu. Importante No recomendados habilitar telnet desde/hacia internet porque usa texto en claro para su comunicacin (incluso para el login). Si desea acceso shell para su firewall desde Internet use SSH: #ACTION SOURCE DEST SSH/ACCEPT net $FW PROTO DEST PORT(S)

Los usuarios Bering querrn agregar las siguientes dos reglas para ser compatibles con la configuracin Shorewall de Jacques. #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc $FW udp 53 #Allow DNS Cache to work ACCEPT loc $FW tcp 80 #Allow Weblet to work

Ahora edite su archivo /etc/shorewall/rules para agregar o eliminar otras conexiones como se necesario. Algunos Concejos a Mantener en Mente

Usted no puede probar su firewall desde adentro. Slo porque enve solicitudes de conexin a la direccin IP de la interface externa de su firewall no significa que la solicitud ser asociada con la interface externa o con la zona net. Cualquier trfico que se genere desde la red local ser asociado con su interface local y ser tratado como trfico loc->fw . Las direcciones IP son propiedades de los sistemas, no de las interfaces. Es un error pensar que su firewall sea capaz de renviar paquetes slo porque puede hacerle ping a la direccin IP de todas las interfaces IP del firewall desde la red local. La nica conclusin que puede sacar de tal ping exitoso es que el enlace entre el sistema local y el firewall funciona bien y que probablemente tenga bien configurado el default gateway del sistema local. Todas las direcciones IP configuradas en las interfaces del firewall estn en la zona $FW (fw) . Si 192.168.1.254 es la direccin IP de su interface interna entonces puede escribir $FW:192.168.1.254 en una regla, pero no puede escribir loc:192.168.1.254. De forma similar, no tiene sentido agregar 192.168.1.254 a la zonas loc poniendo una entrada en /etc/shorewall/hosts. Los paquetes de respuesta NO necesariamente siguen automticamente el camino reverso al tomado por el paquete original de solicitud. Todos los paquetes son enrutados de acuerdo a la tabla de enrutamiento de la mquina en cada paso en su camino. Este tema usualmente salta a la palestra cuando se instala un firewall Shorewallall en paralelo a un gateway existente y se intenta usar DNAT a travs del Shorewall sin cambiar el default gateway en el sistema que recibe la solicitud renviada. Las solicitudes

entrarn por el firewall Shorewall, donde la direccin IP destino es rescrita, pero la respuesta sale sin modificacin por medio del gateway antiguo. Shorewall no tiene nocin de adentro o afuera por s mismo. Estos conceptos se incorporan en el cmo se configura Shorewall.

Arrancando y Deteniendo Su Firewall

El procedimiento de instalacin configura su sistema para arrancar Shorewall al arrancar (boot) el sistema pero el inicio de Shorewall est deshabilitado por omisin en su configuracin, as que no intente arrancar su Shorewall hasta que termine la configuracin. Una vez que se hay completado la configuracin de su firewall debe editar su /etc/shorewall/shorewall.conf y poner STARTUP_ENABLED=Yes. Importante Los usuarios del paquete .deb deben editar /etc/default/shorewall y poner startup=1. El firewall se arranca usando el comando shorewall start y se detiene con el comando shorewall stop. Cuando el firewall est detenido el enrutamiento est habilitado para aquellas mquinas que tengan una entrada en el archivo /etc/shorewall/routestopped. Un firewall detenido debe ser reiniciado usando el comando shorewall restart . Si desea eliminar totalmente todo rastro de Shorewall de su configuracin Netfilter, use el comando shorewall clear.

Esta muestra two-interface asume que usted desea habilitar el enrutamiento desde/hacia eth1 (la red local) cuando Shorewall est detenido. Si su red local no est conectada a eth1 o si desea habilitar el acceso desde/hacia otras mquinas, cambie apropiadamente el archivo /etc/shorewall/routestopped . Alerta Si usted est conectado a su firewall desde internet no enve el comando shorewall stop a menos que haya agregado una entrada con la direccin IP desde donde se conect al archivo /etc/shorewall/routestopped. Tampoco recomendamos usar shorewall restart; es mejor crear una configuracin alterna y probarla con el comando shorewall try. Lectura Adicional Recomendada Se le recomienda altamente la pagina Archivo de Facilidades de Configuracin Comunes -- contiene tips tiles acerca de las facilidades Shorewall que hacen ms fcil la administracin del firewall Shorewall. Agregando un Segmento Inalmbrico a su Firewall Dos-Interfaces Una vez que tiene su arreglo de dos interfaces funcionando, el siguiente paso lgico es agregar una conexin de red inalmbrica. El primer paso es agergar la tarjeta de red adicional a su firewall, ya sea una tarjeta inalmbirca o una tarjeta ethernet que conecte a un punto de acceso inalmbirco. Precaucin Cuando agrega una tarjeta de red, sta no ser necesariamente detectada como la siguiente interface ethernet superior. Por ejemplo, si tiene dos interfaces ethernet en su sistema (eth0 and eth1) y agrega una tercera tarjeta que usa el mismo manejador (driver) de alguna de las dos anteriores, la tercera no necesariamente ser detectada como eth2; mal pudiera ser detectada como eth0 o eth1. Usted puede ya sea vivir con ello o puede intercambiar las tarjetas en los scates hasta que la nueva tarjeta sea detectada como eth2.

Su nuevo arreglo de red lucir similar a la figura siguiente.

La primera cosa notable es que las computadores en su red inalmbrica estan en una subred diferente a los de su red cableada en la LAN. En el ejemplo de arriba, hemos escogido usar la red 10.10.11.0/24. Las computadoras 3 y 4 seran configuradas con la direccin IP del default gateway IP a 10.10.11.254. Segundo, hemos escogido incluir la red inalmbrica como parte de la zona local. Ya que Shorewall permite el trfico en-la-zona por omisin, el trfico puede fluir libremente entre la red cableada local y la red inalmbrica. Hay slo dos cambios necesarios para nuestra configuracin Shorewall: Se necesita agregar una entrada a /etc/shorewall/interfaces para la interface de red inalmbrica. Si la interface inalmbrica es wlan0, la entrada puede lucir as: #ZONE INTERFACE loc wlan0 detect BROADCAST maclist OPTIONS

Como se muestra en la entrada anterior, se recomienda usar la opcin maclist para el segmento inalmbrico. En paralelo, agregue las entradas para las computadoras 3 y 4 en /etc/shorewall/maclist para prevenir que sus vecinos obtengan una conexin gratuita a internet a sus expensas. Comience por omitir esta opcin; cuando tenga todo funcionando, entonces agregue esta opcin y configure su archivo /etc/shorewall/maclist. Usted necesita agregar una entrada al archivo /etc/shorewall/masq para enmascarar el trfico desde la red inalmbrica hacia internet. Si su interface hacia internet es eth0 y su interface inalmbrica es wlan0, la entrada sera as: #INTERFACE SUBNET eth0 wlan0 ADDRESS

Otra cosa a notar, para poner la red de Microsoft a funcionar entre las redes inalmbrica y cableada necesitar ya sea un servidor WINS o un PDC. Yo personalmente uso Samba configurado como servidor WINS corriendo en mi firewall. Correr un servidor WINS en el firewall requiere las reglas que se listan en documentacin Shorewall/Samba.

Gua de Configuracin de Shorewall Original de Tom Eastep, traduccin Guillermo Gmez (Neotech Venezuela) Precaucin Este artculo aplica a Shorewall 3.0 en adelante. Si est corriendo una versin previa de Shorewall 3.0.0, entonces por favor vea la documentacin para dicha liberacin. Introduccin Esta gua est destinada a los usuarios que desean configurar Shorewall en entornos donde un conjunto de direcciones IP pblicas deben ser manejadas. Para quienes desean conocer ms acerca de Shorewall en otros entornos revise las Guas Rpidas de Shorewall. Debido a las amplias diferentes posibles aplicaciones, la Gua le dar directrices y apuntar hacia otros recursos si ello es necesario. Precaucin Shorewall requiere el paquete iproute/iproute2 instalado (en RedHat, el paquete se llama iproute). Usted puede saber si el paquete est instalado por la presencia del programa ip en su sistema firewall. Como root, puede usar el comando which para verificar este programa: [root@gateway root]# which ip /sbin/ip [root@gateway root]# Se recomienda que primero lea la gua para que se familiarice con lo que est involucrado y luego vuelva hacia atr y comience sobre los cambios de configuracin requeridos. Los puntos donde se recomiendan cambios de configuracin se sealan con. Precaucin Si edita sus archivos de configuracin en un sistema Windows, usted debe salvarlos como archivos Unix si su editor soporta dicha opcin o debe ejecutar dicho archivo con dos2unix antes de usarlo con Shorewall. De forma similar, si copia un archivo de configuracin desde su disco duro en Windows a un disco flexible, debe ejecutar previamente dos2unix contra la copia antes de usarla con Shorewall. Enlace a versin Windows de dos2unix : http://www.simtel.net/pub/pd/51438.html Enlace a versin Linux de dos2unix : http://www.megaloman.com/%7Ehany/software/hd2u/

Conceptos de Shorewall Los archivos de configuracin de Shorewall estn en el directorio /etc/shorewall para la mayora de las configuraciones, slo necesitar lidiar con algunos de ellos como se describe en esta gua. El esqueleto de archivos de configuracin es creado durante el Proceso de Instalacin de Shorewall. Alerta Nota para los Usuarios Debian Si instala usando un .deb, encontrar que el directorio /etc/shorewall est vaco. Esto es intencional. Los archivos del esqueleto correspondientes a la liberacin correspondiente pueden encotrarse en su sistema en el directorio /usr/share/doc/shorewall/default-config. Simplemente copie los archivos que necesite desde ese directorio a /etc/shorewall y modifique las copias.

Note que debe copiar /usr/share/doc/shorewall/default-config/shorewall.conf y /usr/share/doc/shorewall/defaultconfig/modules a /etc/shorewall incluso si no los modifica. En la medida que introducimos cada archivo, sugerimos que revise dicho archivo en su sistema, cada archivo contiene instrucciones detalladas de configuracin. Shorewall ve la red donde est corriendo como si estuviera compuesta de un conjunto de zonas. En esta gua usaremos las siguientes zonas: fw El propio sistema firewall. net La red pblica Internet. loc La red local privada que usa direcciones IP privadas. dmz Una Zona Desmilitarizada que aloja servidores de acceso pblico. Las zonas se definen en el archivo /etc/shorewall/zones. Importante El archivo /etc/shorewall/zones includo en la distribucin est vaco. Usted puede crear el conjunto de zonas estandar descritas anteriormente copiando y pegando el siguiente contenido en dicho archivo: #ZONE TYPE fw firewall net ipv4 loc ipv4 dmz ipv4 OPTIONS

Note que Shorewall reconoce al sistema firewall como su propia zona. El ejemplo anterior sigue la convencin usual de nombres, zona firewall fw. El nombre especificado para la zona firewall (fw en el ejemplo anterior) se almacena en la variable shell $FW cuando se procesa el archivo /etc/shorewall/zones. Con la excepcin del nombre asignado a la zona firewall, Shorewall no asocia ningn significado especial a los nombes de zona. Las zonas son lo que USTED hace de ellas. Ello significa que no debe esperar que Shorewall haga algo especial "porque esta es la zona interna" o "porque esta es la zona DMZ". Edite el archivo /etc/shorewall/zones y haga los cambios necesarios. La reglas acerca de qu trfico permitir y negar se expresan en trminos de las zonas. Usted expresa la poltica por omisin para conexiones desde una a otra zona en el archivo /etc/shorewall/policy . Usted define excepciones a dichas polticas en /etc/shorewall/rules.

Shorewall se construye sobre el motor de kernel Netfilter . Netfilter implementa la funcin de seguimiento de conexiones que permite lo que se denomina como inspeccin por estado (stateful inspection) de paquetes. Esta capacidad de manejar los estados permite que las reglas de firewall sean definidas en trminos de conexiones en vez de paquetes. Con Shorewall usted:

1. 2. 3. 4.

Identifica la zona origen (cliente). Identifica la zona destino (servidor). Si la POLITICA de la zona cliente a la zona servidor es lo que desea para esta pareja cliente/servidor, no necesita hacer nada adicional. Si la POLITICA no es lo que desea, entonces debe agregar una regla. La regla se expresa en trminos de la zona del cliente y de la zona del servidor.

Slo porque las conexiones de un tipo particular desde la zona A hacia el firewall estn permitidas y que tambin estn permitidas desde el firewall a la zona B, NO sigifica que estas conexiones esten permitidas entre la zona A y la zona B (en otras palabras, las polticas y reglas que involucran a la zona firewall no son transitivas). A cambio significa que usted puede tener un proxy corriendo en el firewall que acepta conexiones desde la zona A y luego establece conexiones separadas por s mismo desde el firewall hacia la zona B. Para cada solicitud de conexin que entra al firewall, la solicitud se chequea primero contra el archivo /etc/shorewall/rules. Si ninguna regla del archivo aplica, se aplica a la solicitud de conexin la primera poltica en /etc/shorewall/policy que corresponda con dicha solicitud despus de que haya pasado por la accin comn apropiada (si existe alguna). Previo a Shorewall 2.2.0, el archivo por omisin /etc/shorewall/policy tena las siguientes polticas: #SOURCE ZONE # loc net net all all all Importante El archivo de polticas de la versin actual est vaco. Usted puede copiar y pegar las entradas anteriores para crear un punto de partida para luego personalizar sus polticas. Las polticas anteriores harn que: 1. permitir todas las solicitudes de conexiones desde la red local hacia internet registra un mensaje a nivel informativo (info level log, vea aqu la descripcin de los niveles de registro). rechaza todas las solicitudes de conexiones y registra un mensaje a nivel informativo. Cuando una solicitud se rechaza el firewall devuelve un RST (si el protocolo es TCP) o un paquete ICMP de puerto-inalcanzabe para los otros protocolos. DESTINATION ZONE LEVEL ACCEPT DROP info REJECT info POLICY LOG LIMIT:BURST

2. descartar (ignorar) todas las solicitudes de conexiones desde internet hacia su firewall o red local y se
3.

En este punto, edite su archivo /etc/shorewall/policy y haga los cambios que desee. Interfaces de Red Para el resto de esta gua nos referiremos al siguiente diagrama. Si bien puede que no luzca como el de su red, puede usarse para ilustrar los aspectos importantes de la configuracin Shorewall. En este diagrama: La Zona DMZ consiste de los sistemas DMZ 1 y DMZ 2. Una DMZ se usa para aislar su servidors accesibles desde internet de sus sistemas locales tal que si uno de esos servidores est comprometido, an tendr el firewall entre el sistema comprometido y sus sistemas en la red local. La Zona Local consiste de los sistemas Local 1, Local 2 y Local 3. Todos los sistemas desde el ISP hacia afuera componen la Zona Internet.

La forma ms cimple de definir zonas es asociar el nombre de la zona (previamente definida en /etc/shorewall/zones) con una interface de red. Esto se hace en el archivo /etc/shorewall/interfaces . El firewall ilustrado arriba tiene tres interfaces de red. Donde la conectividad hacia Internet es hecha a travs de un cable "Modem" o DSL, la Interface Externa ser un adaptador Ethernet que se ecneuntra conectado al "Modem" (e.g., eth0) a menos que conecte usando Point-to-Point Protocol over Ethernet (PPPoE) o Point-to-Point Tunneling Protocol (PPTP) en cuyo caso la Interface Externa ser una interface ppp (e.g., ppp0). Si conecta usando un modem regular, su Interface Externa tambin ser ppp0. Si conecta usando ISDN, su interface externa ser ippp0. Si su interface externa es ppp0 o ippp0 entonces desear establecer CLAMPMSS=yes en /etc/shorewall/shorewall.conf. Su Interface Local ser un adaptador Ethernet (eth0, eth1 o eth2) y conectar a un hub o switch. Sus computadores locales estarn conectadas al mismo switch o hub (nota: Si tiene un nico sistema local, puede conectar directamente el firewall al computador utilizando un cable cruzado). Su Interface DMZ tambin ser un adaptador Ethernet (eth0, eth1 o eth2) y se conectar a un hub o switch. Sus computadores DMZ sern conectados al mismo switch o hub (nota: Si tiene un nico sistema DMZ, puede conectar directamente el firewall al computador usando un cable cruzado). Precaucin No conecte la interace interna y externa al mismo hub o switch, exceptuando para pruebas Y est corriendo Shorewall 1.4.7 o superior. Cuando use estas versiones recientes puede probar usando este tipo de configuracin si especifica la opcin arp_filter o la opcin arp_ignore en el archivo /etc/shorewall/interfaces para todas las interfaces conectadas al mismo hub/switch. No se recomienda utilizar tal configuracin con un firewall de produccin. Para el resto de esta gua asumiremos que: La Interface Externa es eth0. La Interface Local es eth1. La Interface DMZ es eth2.

La cinfiguracin Shorewall por omisin no define el contenido de ninguna zona. Para definir la configuracin de arriba usando el archivo /etc/shorewall/interfaces , dicho archivo contendra : #ZONE INTERFACE net eth0 detect loc eth1 detect dmz eth2 detect BROADCAST norfc1918 OPTIONS

Note que la zona $FW no tiene una entrada en el archvio /etc/shorewall/interfaces. Edite el archivo /etc/shorewall/interfaces y defina las interfaces de red de su firewall asociadas con su zona. Si tiene una zona disponible a travs de ms de una interface de red, simplemente incluya una entrada para cada interface y repita el nombre de zona tantas veces como haga falta con su respectiva interface de red. Ejemplo 1. Mltiples Interfaces hacia una Zona #ZONE INTERFACE net eth0 detect loc eth1 detect loc eth2 detect BROADCAST norfc1918 OPTIONS

Usted puede definir zonas ms complicadas usando el archivo /etc/shorewall/hosts pero en la mayora de los casos ello no es necesario. Vea Shorewall_and_Aliased_Interfaces.html y Multiple_Zones.html para algunos ejemplos. Direccionamiento, Subredes y Enrutamiento Normalmente su ISP le asignar un conjunto de direcciones IP Pblicas. Usted configurar su interface externa de su firewall para que use una de dichas direcciones permanentemente y entonces tendr que decidir como usar el resto de sus direcciones. Antes de que contestemos esta pregunta es conveniente primero revisar los fundamentos. Si usted est ampliamente familiarizado con el direccionamiento IP y el enrutamiento, puede ir directo a la prxima seccin. La siguiente discusin revisa someramente el direccionamiento y el enrutamiento IP. Si est interesado en aprender ms acerca del tema le recomendaos ampliamente IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0. Direcciones IP Las direcciones IP versin 4 (IPv4) son nmeros de 32 -bits. La notacin w.x.y.z refiere a una direccin donde el byte de orden superior tiene el valor w, el prximo byte tiene el valor x, etc. Si tomamos la direccin 192.0.2.14 y la expresamos en hexadecimal obtenemos: C0.00.02.0E o vendolo como un entero de 32-bits C000020E Subredes Usted comenzar a escuchar los trminos red Clase A, red Clase B" y "red Clase C". En los primeros das de IP, las redes venan en tres tamaos (exista tambin redes Clase D pero era usada de forma diferente): Clase A - mscara de red 255.0.0.0, size = 2 ** 24 Clase B - mscara de red 255.255.0.0, size = 2 ** 16

Clase C - mscara de red 255.255.255.0, size = 256 La clase de una red era determinada unvocamente por el valor del byte superior de su direccin tal que usted pudiera ver la direccin IP e inmediatamente determinara la mscara asociada. La mscara de red es un nmero que cuando se aplica un Y lgico con la direccin separa la direccin de red del resto que es la direccin de host. Por ejemplo, la direccin Clase C 192.0.2.14, la direccin de red es el hexadecimal C00002 y el nmero de host es 0E. En la medida que internet creci, se hizo claro que tal particionamiento tan grueso de direcciones de 32-bits iva a ser muy limitante (Previamente a las grandes corporaciones y universidades le fueron asignadas sus propias redes clase A!). Despus de unos arranques en falso, la tcnica de subredes evolucion al sistema actual de redes ms pequeas, la tcnica se le refiere como Classless InterDomain Routing (CIDR). Hoy da cualquier sistema que usted probablemente use entender CIDR y las redes basadas en clases son ya algo del pasado. Una subred es un conjunto contiguo de direcciones IP tal que: 1. 2. La cantidad de direcciones en el conjunto es una potencia de 2; y La primera direccin en el conjunto es un mltiplo del tamao del conjunto. La primera direccin en la subred se reserva y se le refiere como la direccin de subred. La tima direccin en la subred est reservada como la direccin de difusin(broadcast) de la subred.

3. 4.

Como puede ver, por definicin, en cada subred de tamao n hay (n - 2) direcciones utilizables (direcciones que se pueden asignar a mquinas). La primera y ltima direccin en la subred son utilizadas como direccin de la subred y direccin de difusin respectivamente. En consecuencia las subredes ms pequeas desperdician ms direcciones IP que las redes ms grandes. Ya que n es una potencia de dos, fcilmente podemos calcular el Logaritmo-Base2 (log2) de n. Para los tamaos ms comunes de subred, el tamao y su logaritmos base 2 son dados por la siguiente tabla: Tabla 1. Logaritmos Base-2 n 8 16 32 64 128 256 512 1024 2048 4096 8192 log2 n (32 - log2 n) 3 4 5 6 7 8 9 10 11 12 13 29 28 27 26 25 24 23 22 21 20 19 18 17 16

16384 14 32768 15 65536 16

Notar que la tabla arriba tambin contiene una columna parar (32 - log2 n). Este nmero es la Variable Length Subnet Mask (VLSM) para una red de tamao n. De la tabla arriba podemos derivar la siguiente que es un poco ms fcil de usar.

Tabla 2. VLSM Subnet Size VLSM Subnet Mask 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 2 ** 24 /29 /28 /27 /26 /25 /24 /23 /22 /21 /20 /19 /18 /17 /16 /8 255.255.255.248 255.255.255.240 255.255.255.224 255.255.255.192 255.255.255.128 255.255.255.0 255.255.254.0 255.255.252.0 255.255.248.0 255.255.240.0 255.255.224.0 255.255.192.0 255.255.128.0 255.255.0.0 255.0.0.0

Note que la VLSM se escribe con barra (/) -- a menudo escuchar de una subred de tamao 64 referida como una subred barra 26 y una de tamao 8 referida como de barra 29. La mscara de subred es simplemente un nmero de 32 bits con los primeros VLSM bits puestos a uno y los remanentes bits puestos a cero. Por ejemplo, para una subred de tamao 64, la mscara de subred tiene los primeros 26 bits en uno : 11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192 La mscara de subred tiene la propiedad de que si se hace un Y lgico con una direccin en la subred, el resultado es la direccin de la subred. Igual de importante, si hace un Y lgico de la mscara de subre con una direccin fuera de la subred, el resultado NO es la direccin de la subred. Como ya veremos, esta propiedad de la mscara de subred es muy til para el enrutamiento. Para una subred cuya direccin es a.b.c.d y cuyo Variable Length Subnet Mask es /v, denotamos la subred como a.b.c.d/v usando Notacin CIDR. Ejemplo: Tabla 3. Subred Subred: Tamao Subred Direccin Subred Notacin CIDR: 10.10.10.0 - 10.10.10.127 128 10.10.10.0 10.10.10.0/25

Direccin Difusin 10.10.10.127 Existen dos subredes degeneradas que merecen ser nombradas, la subred con un miembro, y la subre con 2 ** 32 miembros. Tabla 4. /32 y /0

Tamao Subred Longitud VLSM Mscara Subred Notacin CIDR 1 32 32 0 255.255.255.255 a.b.c.d/32 0.0.0.0 0.0.0.0/0

Asi que cualquier direccin a.b.c.d puede tambin ser escrita como a.b.c.d/32 y el conjunto de todas las direcciones IP posibles como 0.0.0.0/0. Un usuario Shorewall contribuy con este til resumen grfico de la informacin anterior. Ms adelante en esta gua veremos usada la notacin a.b.c.d/v para describir la configuracin de una interface de red (el utilitario ip tambin usa esta sintxis). Esto simplemente significa que la interface est configurada con la direccin ip a.b.c.d y con la mscara de red que corresponde a VLSM /v. Ejemplo 2. 192.0.2.65/29 La interface est configurada con la direccin IP 192.0.2.65 y la mscara de red 255.255.255.248. A partir de Shorewall 1.4.6, /sbin/shorewall soportar el comando ipcalc que automticamente calcula la informacin acerca de la [sub]red Ejemplo 3. Uso del comando ipcalc shorewall ipcalc 10.10.10.0/25 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 BROADCAST=10.10.10.127 Ejemplo 4. Uso del comando ipcalc shorewall ipcalc 10.10.10.0 255.255.255.128 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 BROADCAST=10.10.10.127 Enrutamiento Uno de los propsitos de las subredes es que ste conforma las bases para el enrutamiento. Aqu se muestra una tabla de enrutamiento en un firewall: [root@gateway root]# netstat -nr Kernel IP routing table Destination Gateway Genmask Flgs MSS Win irtt Iface 192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas 206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1 206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3 192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3 192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2 206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo

0.0.0.0 206.124.146.254 0.0.0.0 [root@gateway root]#

UG 40 0

0 eth0

El dispositivo texas es un tunel GRE con un sitio similar en Dallas, Texas. Las tres primeras rutas son rutas host ya que indican cmo llegar a una nica mquina. En la salida de netstat esto puede verse en por la Genmask (Mscara de Subred) de 255.255.255.255 y la H en la columna Flags. Las restantes son rutas de "red ya que le dicen al kernel cmo enrutar los paquetes hacia subredes completas. La ltima ruta se conoce como ruta por omisin y la pasarela mencionada en la ruta es denominado el "default gateway". Cuando el kernel intenta enviar un paquete a la direccin IP A, comienza por el tope de la tabla de enrutamiento y: A se hace Y lgico con el valor de la Genmask en la entrada de la tabla. El resultado se compara con el valor Destination en la entrada de la tabla. Si el resultado y el valor Destination son iguales, entonces: o Si la columna Gateway no es cero, el paquete es enviada al gateway por medio de la interface definida en la columna Iface. o De otra forma, el paquete es enviado directamente a A por medio de la interface nombrada en la columna iface. De otra forma, los pasos anteriores se repiten para la prxima entrada en la tabla.

Ya que la ruta por omisin coincide con cualquier direccin IP (A LAND 0.0.0.0 = 0.0.0.0), los paquetes que no coincidan con ninguna otra ruta en las entradas de la tabla sern enviados al default gateway que usualmente es un enrutador de su ISP. Tomemos un ejemplo. Suponga que deseamos enrutar un paquete a 192.168.1.5. Esta direccin claramente no coincide con ninguna de las rutas host en la tabla pero si hacemos un Y lgico con 255.255.255.0, el resultado es 192.168.1.0 que coincide con la siguiente entrada de la tabla de enrutamiento: 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2

As que para enruta un paquete hacia 192.168.1.5, el paquete se enva directmente por medio de eth2. Se debe enfatizar una cosa ms, todos los paquetes salientes son enviados usando la tabla de enrutamiento y los paquetes respuesta no son un caso especial. Esto parece ser un error comn de concepcin donde las personas piensan que los paquetes de solicitud son como el salmn y contiene cdigo gentico que se transfiere mgicamente hacia los paquetes respuesta ta que las respuestas siguen la ruta reversa tomada por la solicitud. Esto no es el caso, las respuestas pueden tomar una ruta totalmente diferente de vuelta hacia el cliente a la que tom la solicitud, ellas son totalmente independientes. Address Resolution Protocol (ARP) Cuando se envan paquetes sobre Ethernet, las direcciones IP no se usan. En cambio se usa el direccionamiento Ethernet basado direcciones Media Access Control (MAC) . Cada dispositivo Ethernet posee su propia y nica direccin MAC quemada en una PROM en el dispositivo durante su fabricacin. Usted puede obtener la MAC de un dispositivo Ethernet usando el utilitario ip : [root@gateway root]# ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100 link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0 inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0 [root@gateway root]# Como puede ver de la salida del comando anterior, la MAC es de 6 bytes (48 bits) . La MAC de una tarjeta usualmente tambin viene impresa en su superficie en una etiqueta. Ya que IP usa direcciones IP y Ethernet usa

direcciones MAC, se requiere de un mecanismo para traducir una direccin IP a una direccin MAC, este es el propsito del Address Resolution Protocol (ARP). Aqu vemos ARP en accin: [root@gateway root]# tcpdump -nei eth2 arp tcpdump: listening on eth2 09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254 09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0 2 packets received by filter 0 packets dropped by kernel [root@gateway root]# En este intercambio, 192.168.1.254 (MAC 2:0:8:e3:4c:48) desea conocer la MAC del dispositivo con la direccin IP 192.168.1.19. El sistema que tiene la direccin IP responde que la direccin MAC del dispositivo con la direccin IP 192.168.1.19 es 0:6:25:aa:8a:f0. Con la finalidad de evitar el intercambio constante ARP cada vez que un paquete IP se enva, los sistemas mantienen un cache ARP de correspondencias IP<->MAC. Usted puede ver el cache ARP en su sistema (incluyendo su sistema Windows) usando el comando arp : [root@gateway root]# arp -na ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1 ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2 ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2 ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0 ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2 El smbolo "?" al inicio de la salida son el resultado de haber especificado la opcin"n" (el arp de Windows no soporta esta opcin) que provoca que el programa arp evita la traduccin de nombres IP->DNS. Si no hubiera especificado esta opcin, los smbolos "?" hubiesen sido remplazados con sus correspondientes FQDN a cada direccin IP. Note que la ltima entrada enla tabla registra la informacin que vimos usando tcpdump arriba. RFC 1918 Las direcciones IP son asignadas por la Internet Assigned Number Authority (IANA) quien delega a su vez las asignaciones de acuerdo a las zonas geogrficas a los Regional Internet Registries (RIRs). Por ejemplo, las asignaciones para las Americas y para el Africa sub-Sahara Africa se delega al American Registry for Internet Numbers (ARIN). Estos RIRs pueden a su vez delegar a registros nacionales. La mayora de nosotros no lidiamos con estos registros sino que obtenemos nuestras direcciones IP a partir de nuestros ISP. Es un hecho que la mayora de nosotros no podemos justificar tener tantas IPs como dispositivos tenemos as que terminamos usando direcciones IP Privadas. El RFC 1918 reserva varios rangos IP para este propsito: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Las direcciones reservadas por el RFC 1918 son a veces referidas como no ruteables debido a que los enrutadores en Internet no renvan los paquetes que tienen destinos direcciones IP del RFC 1918. Esto se entiende ya que cualquiera puede seleccionar cualquiera de estas direcciones para su uso privado pero el trmino no ruteable es algo desafortunado porque hace pensar errneamente a las personas que dichas direcciones no pueden ser enviadas por medio de enrutadores. Esto definitivamente no es cierto, los enrutadores privados (incluyendo su firewall basado en Shorewall) pueden enviar usando direcciones RFC 1918 igual de bien que con cualquier otra direccin. Cuando seleccione direcciones de estos rangos hay un par de cosas a mantener en mente:

En la medida que el espacio IPv4 se agota, ms y ms organizaciones (incluyendo ISPs) estn comenzando a usar direcciones RFC 1918 en sus infraestructuras. Usted no quiere usar direcciones que este en uso en su ISP o por cualquier otra organizacin con la cual desee establecer una relacin VPN.

As que es buena idea verificar con su ISP para ver si estn usando (o planeando usar) direcciones privadas antes de decidir las direcciones que usar. Alerta En este documento, direcciones IP externas "reales" son de la forma 192.0.2.x. 192.0.2.0/24 est reservada por el RFC 3330 para el uso como direcciones IP pblicas en ejemplos impresos y redes de prueba. Estas direcciones "reales" no deben confundirse con las direcciones en 192.168.0.0/16; como se describen arriba, dichas direcciones se reservan en el RFC 1918 para uso privado. Configuracin De Su Red La escogencia de cmo configurar su red depende primariamente de cuntas direcciones IP Pblicas tenga vs. cuntos dispositivos direecionables tiene en su red. Independientemente de cuntas direcciones tenga, su ISP manejar ese conjunto de direcciones en una de dos maneras: Enrutando - El trfico hacia cualquiera de sus direcciones ser enrutado por medio un nico gateway. Esto generalmente ocurre si su ISP le ha asignado una subred compelta (/29 o mayor). En este caso usted asginar la direccin del gateway como la direccin IP de la interface externa de su router/firewall. No enrutando - Su ISP enviar el trfico directamente a cada una de sus direcciones directamente.

En las siguientes secciones veremos estos escenarios por separado. Antes de comenzar, hay algo que tenemos que verificar: Si esta usando el paquete Debian, verifique su archivo shorewall.conf para asegurarse que lo siguiente esta configurado correctamente, si no es as, corrija adecuadamente: NAT_ENABLED=Yes (versiones Shorewall previas a 1.4.6) IP_FORWARDING=On

Enrutando Asumamos que su ISP le ha asignado la subred 192.0.2.64/28 enrutada por medio de 192.0.2.65. Esto significa que tiene las direcciones IP 192.0.2.64 a 192.0.2.79 y que la interface externa de su firewall tiene la IP 192.0.2.65. Su ISP tambin le ha dicho que debe usar la mscara de red 255.255.255.0 (asi que su /28 es parte de una mayor /24). Con esta cantidad de direcciones IP usted est en la capacidad de hacer subredes de su /28 en dos subredes /29 y configurar su red como su muestra en el siguiente diagrama.

Aqu la DMZ est compuesta de la subred 192.0.2.64/29 y la red Local de la red 192.0.2.72/29. El default gateway para las mquinas en la DMZ ser configurado a 192.0.2.66 y el default gateway para las mquinas en la red local ser 192.0.2.73. Note que este diagrama desperdicia muchas direcciones IP ya que est usando 192.0.2.64 y 192.0.2.72 como direcciones de subred, 192.0.2.71 y 192.0.2.79 como direcciones de difusin de las subredes y 192.0.2.66 y 168.0.2.73 como direcciones internas del firewall/router. An as, muestra cmo funciona el hacer subredes y si estviramos lidiando con una red /24 en vez de una red /28, el uso de 6 direcciones IP de 256 estara justificado slo por la simplicidad de la configuracin. El lector astuto notar que la interface externa del Firewall/Router es de hecho parte de la subred DMZ (192.0.2.64/29). Qu pasa si DMZ 1 (192.0.2.67) intenta comunicarse con 192.0.2.65? La tabla de enrutamiento de DMZ 1 lucira as: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0 0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0 Esto significa que DMZ 1 enviar una solicitud ARP quien-tiene 192.0.2.65 y ningn dispositivo en el segmento Ethernet DMZ tiene esa direccin IP. An as, el firewall responder a la solicitud con la direccin MAC de su Interface DMX! DMZ 1 puede entonces enviar tramas Ethernet a esa direccin MAC y sern recibidos (correctamente) por el firewall/router. Es este inesperado comportamiento ARP en la parte del Kernel Linux que provoca la alerta anterior en esta gua acerca de la conexin de mltiples interfaces del firewall/router al mismo hub/switch. Cuando una solicitud ARP para una de las direcciones IP del firewall/router es enviada por cualquier de los sistemas conectados al hub/switch, todas las interfaces que conectan al hub/switch pueden responder. Es entonces una carrera de cul respuesta "aqu-es" llega primero a quien envo la solicitud ARP. No enrutando Si tiene la situacin anterior pero no es enrutando, puede configurar su red exactamente igual que arriba pero con una vuelta adicional de tuerca: simplemente especifique la opcin "proxyarp" en las tres interfaces del firewall en el archivo /etc/shorewall/interfaces.

La mayora no tenemos el lujo de tener suficientes direcciones IP pblicas para configurar sus redes como se coment en el ejemplo anterior (incluso si la configuracin en enrutando). Para el resto de esta seccin, asuma que su ISP le ha asignado las direcciones IP 192.0.2.176-180 y se le ha dicho que use la mscara de red 255.255.255.0 y el default gateway 192.0.2.254. Claramente este conjunto de direcciones no constituyen una subred y no hay suficientes direcciones para todas las interfaces de red. Hay cuatro tcnicas que se pueden usar para resolver esta situacin: Source Network Address Translation (SNAT). Destination Network Address Translation (DNAT) tambin conocido como Port Forwarding. Proxy ARP. Network Address Translation (NAT) tambin conocido como NAT uno-a-uno.

A menudo una combinacin de estas tcnicas pueden usarse efectivamente. Cada una de ellas sern discutidas por separado en las siguientes secciones. SNAT Con SNAT un segmento interno LAN se configura usando direcciones RCF 1918. Cuando una mquina A en este segmento interno inicia una conexin a una mquina B en internet, el firewall/router rescribe el encabezado IP en la solicitud para usar una de las direcciones IP pblicas como direccin de origen. Cuando B responde y la respuesta es recibida en el firewall, el firewall cambia la direccin destino de vuelta a la direccin RFC 1918 de A y enva la respuesta de vuelta a A. Supongamos que deciden usar SNAT en su zona local y usar la direccin pblica 192.0.2.176 tanto como direccin externa IP del firewall como direccin origen para las solicitudes salientes de dicha zona local.

La zona local ha sido dividida en subredes como 192.168.201.0/29 (mscara de red 255.255.255.248). El sistema en la zona local sera configurado con el default gateway 192.168.201.1 (la direccin IP de la interface local del firewall). SNAT se configura en Shorewall usando el archivo /etc/shorewall/masq . #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 Este ejemplo usa la tcnica normal de asignar la misma direccin IP pblica para la interface externa del firewall y para el SNAT. Si desea usar una direccin IP pblica diferente usted tendra que usar las herramientas de

configuracin de su distribucin Linux para agregar dicha direccin IP a la interface externa o puede poner ADD_SNAT_ALIASES=Yes en /etc/shorewall/shorewall.conf y Shorewall agregar la direccin por usted. DNAT Cuando se usa SNAT es imposible para las mquinas en Internet iniciar una conexin con otra mquina de los sistemas locales ya que dichos sistemas no tienen direcciones IP Pblicas. DNAT provee una forma de permitir conexiones selectivas desde internet. Suponga que su hija desea correr un servidor web en su sistema local "Local 3. Usted pudiera permitir conexiones desde internet hacia su servidor agregando la siguiente entrada en /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) DEST DNAT net loc:192.168.201.4 tcp www ORIGINAL

Si alguna de las amigas de su hija en la direccin A desea acceder al servidor de su hija, ella puede conectar a http://192.0.2.176 (la direccin IP externa del firewall) y el firewall rescribir la direccin IP destino a 192.168.201.4 (el sistema de su hija) y enva la solicitud. Cuando el servidor de su hija responde, el firewall rescribir la direccin origen de vuelta a 192.0.2.176 y enva la respuesta de vuelta hacia a A. Este ejemplo usa la direccin IP externa del firewall para hacer el DNAT. Usted puede usar otra direccin de sus direcciones IP pblicas (colquela en la columna ORIGINAL DEST en la regla anterior arriba) pero Shorewall no agregar esa direccin a la interface externa del firewall por usted. Importante Cuando pruebe reglas DNAT como la anterior, usted debe probar desde un cliente EXTERNO A SU FIREWALL (en la zona 'net'). Usted no puede probar dichas reglas desde las redes internas al firewall! Para tips de resolucin de problemas DNAT For DNAT vea los FAQ 1a y 1b. Proxy ARP La idea detrs de Proxy ARP es: Una mquina H detrs de su firewall se le asigna una de las direcciones IP pblicas (A), y se le asigna la misma mscara de red (M) a la de la interface externa del firewall. El firewall responde las solicitudes ARP "quien tiene" para A de mquinas fuera del firewall. Cuando H enva una solicitud ARP quien tiene por una mquina con una direccin en la red definida por M donde la mquina destino est afuera del firewall, el firewall responder a H (con la MAC de la interface del firewall a la cual est conectada H).

Para una descricpin ms completa de cmo funciona Proxy ARP , vea la Documentacin Shorewall Proxy. Supongamos qeu decidimos usar Proxy ARP en la DMZ en nuestra red ejemplo.

Aqu hemos asignado la direccion IP 192.0.2.177 al sistema DMZ 1 y 192.0.2.178 a DMZ 2. Note que hemos asignado una direccin IP arbitraria RFC 1918 y una mscara de red a la interface DMZ del firewall. Esta direccin y mscara de red no son relevantes, slo asegrese de no solapar otra subred que haya definido. La configuracin Shorewall de Proxy ARP se hace usando el archivo /etc/shorewall/proxyarp . #ADDRESS INTERFACE 192.0.2.177 eth2 eth0 192.0.2.178 eth2 eth0 EXTERNAL No No HAVE ROUTE PERSISTANT

Ya que la columna HAVE ROUTE contiene "No", Shorewall agregar rutas de host a travs de eth2 hacia 192.0.2.177 y 192.0.2.178. Las interfaces ethernet en DMZ 1 y DMZ 2 deberan ser configuradas para tener las direcciones IP que se muestran pero deberan tener el mismo default gateway que el propio firewall -- a saber 192.0.2.254. En otras palabras, ellos deberan configurar tal como si estuvieran en paralelo con el firewall en vez de detrs de l. Precaucin No agregue direcciones con Proxy ARP (192.0.2.177 y 192.0.2.178 en el ejemplo arriba) a la interface externa del firewall (eth0 en nuestro ejemplo). Unas palabras de alerta vienen al caso aqu, los ISPs configuran sus enrutadores con un cache ARP con tiempos de vida muy largos. Si mueve un sistema paralelo a detrs de su firewall con Proxy ARP, probablemente pasarn HORAS antes que el sistema puede comunicarse con internet. Hay un par de cosas que puede intentar: 1. (Cortesa de Bradey Honsinger) La lectura del Stevens' TCP/IP Illustrated, Vol 1 revela que paquetes ARP innecesarios deberan provocar que el enrutador del ISP refresque su cache ARP (seccin 4.7). Un ARP innecesario (gratuituos) es simplemente una mquina solicitando la direccin MAC de su propia IP, adems, para asegurar que la direccin no est duplicada en el segmento,... si la mquina que enva ARP innecesario ha recien cambiado su direccin de hardware..., este paquete provoca que cualqueir otra mquina... que tenga una entrada en su cache para la direccin antigua, actualice su entrada ARP en el cache con la nueva direccin.

Que en turno, es exactamente lo que usted quiere hacer cuado cambia una mquina de estar expuesta a Internet a estar detrs del Shorewall usando Proxy ARP (o NAT uno-a-uno). Felizmente las versiones ms recientes del paquete iputils de RedHat incluyen arping, cuya bandera -U hace exactamente eso: arping -U -I <net if> <newly proxied IP> arping -U -I eth0 66.58.99.83 # for example Stevens continua y menciona que no todos los sistemas responden adecuadamente a los ARP innecesarios (gratuituos), pero googleando con "arping -U" al parecer apunta al soporte de que esta idea funciona la mayora de las veces. 2. Puede llamar a su ISP y pedir que purguen la vieja entrada ARP del cache pero muchos de ellos ni siquiera pueden o quieren purgar entradas individuales.

Usted puede determinar si el cache ARP del gateway de su ISP est estancado usando ping y tcpdump. Suponga que sospecha que el enrutador que funge de gateway tiene una entrada cache ARP estancada para 192.0.2.177. En el firewall, corra tcpdump as: tcpdump -nei eth0 icmp Ahora desde 192.0.2.177, haga ping hacia el gateway del ISP (que asumimos es 192.0.2.254): ping 192.0.2.254 Podemos ahora observar de la salida de tcpdump: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply Note que la direccin origen MAC en la solicitud echo es diferente a la direccin destino MAC en la respuesta al echo. En este caso 0:4:e2:20:20:33 era la MAC del NIC eth0 del firewall mientras 0:c0:a8:50:b2:57 era la direccin MAC de DMZ 1. En otras palabras, el cache ARP del gateway an asocia 192.0.2.177 con la NIC en la NIC de DMZ 1 en ez de la de eth0 del fiewall. NAT uno-a-uno Con NAT uno-a-uno usted asigna direcciones RFC 1918 a los sistemas locales y luego establece un mapa uno-a-uno entre estas direcciones y las direcciones IP pblicas. Para las conexiones salientes ocurre SNAT (Source Network Address Translation) y para las conexiones entrantes ocurre DNAT (Destination Network Address Translation). Volvamos sobre nuestro ejemplo que involucra el servidor web de su hija en el sistema Local 3.

Recuerde que en esta configuracin la red local est usando SNAT y est compartiendo la direccin IP de la interface externa del firewall (192.0.2.176) para las conexiones salientes. Esto se hace con la siguiente entrada en /etc/shorewall/masq: #INTERFACE SUBNET eth0 192.168.201.0/29 ADDRESS 192.0.2.176

Suponga ahora que ha decidido darle a su hija su propia direccin IP (192.0.2.179) tanto para las conexiones entrantes como salientes. Usted hara eso agregando una entrada en /etc/shorewall/nat. #EXTERNAL INTERFACE INTERNAL 192.0.2.179 eth0 192.168.201.4 No ALL INTERFACES LOCAL No

Con esta entrada su hija tiene su propia direccin IP y los otros dos sistemas locales comparten la direccin IP del firewall. Una vez que la relacin entre 192.0.2.179 y 192.168.201.4 se ha establecido por el archivo nat anterior, ya no es apropiado usar la regla DNAT para el servidor web de su hija, en cambio slo use un regla ACCEPT: #ACTION SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) DEST ACCEPT net loc:192.168.201.4 tcp www ORIGINAL

Unas palabras de alerta vienen al caso aqu, los ISPs configuran sus enrutadores con un cache ARP con tiempos de vida muy largos. Si mueve un sistema paralelo a detrs de su firewall con Proxy ARP, probablemente pasarn HORAS antes que el sistema puede comunicarse con internet. Hay un par de cosas que puede intentar: 1. (Cortesa de Bradey Honsinger) La lectura del Stevens' TCP/IP Illustrated, Vol 1 revela que paquetes ARP innecesarios deberan provocar que el enrutador del ISP refresque su cache ARP (seccin 4.7). Un ARP innecesario (gratuituos) es simplemente una mquina solicitando la direccin MAC de su propia IP, adems, para asegurar que la direccin no est duplicada en el segmento,...

si la mquina que enva ARP innecesario ha recien cambiado su direccin de hardware..., este paquete provoca que cualqueir otra mquina... que tenga una entrada en su cache para la direccin antigua, actualice su entrada ARP en el cache con la nueva direccin. Que en turno, es exactamente lo que usted quiere hacer cuado cambia una mquina de estar expuesta a Internet a estar detrs del Shorewall usando Proxy ARP (o NAT uno-a-uno). Felizmente las versiones ms recientes del paquete iputils de RedHat incluyen arping, cuya bandera -U hace exactamente eso: arping -U -I <net if> <newly proxied IP> arping -U -I eth0 66.58.99.83 # for example Stevens continua y menciona que no todos los sistemas responden adecuadamente a los ARP innecesarios (gratuituos), pero googleando con "arping -U" al parecer apunta al soporte de que esta idea funciona la mayora de las veces. 2. Puede llamar a su ISP y pedir que purguen la vieja entrada ARP del cache pero muchos de ellos ni siquiera pueden o quieren purgar entradas individuales.

Usted puede determinar si el cache ARP del gateway de su ISP est estancado usando ping y tcpdump. Suponga que sospecha que el enrutador que funge de gateway tiene una entrada cache ARP estancada para 192.0.2.177. En el firewall, corra tcpdump as: tcpdump -nei eth0 icmp Ahora desde 192.0.2.177, haga ping hacia el gateway del ISP (que asumimos es 192.0.2.254): ping 192.0.2.254 Podemos ahora observar de la salida de tcpdump: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply Note que la direccin origen MAC en la solicitud echo es diferente a la direccin destino MAC en la respuesta al echo. En este caso 0:4:e2:20:20:33 era la MAC del NIC eth0 del firewall mientras 0:c0:a8:50:b2:57 era la direccin MAC de DMZ 1. En otras palabras, el cache ARP del gateway an asocia 192.0.2.177 con la NIC en la NIC de DMZ 1 en ez de la de eth0 del fiewall. Reglas Nota Shorewall tiene una facilidad de macro que incluye macros para muchas aplicaciones estandar. Esta seccin no usa dichos macros sino que define las reglas directamente. Con las polticas por omisin descritas previamente en este documento, su sistemas locales (Local 1-3) pueden acceder a cualquier servidor en internet y la DMZ no puede acceder ninguna mquina (incluyendo al firewall). Con las reglas de excepcin para DNAT que hacen que se traduzcan las direcciones y permitir la solicitud de conexin traducida para que atraviese el firewall, la forma de permitir solicitudes de conexiones a travs de su firewall es usar reglas ACCEPT. Nota Ya que las columnas SOURCE PORT(S) y ORIG. DEST. no se usan en esta seccin, no se mostrarn.

Usted probablemente querr hacer ping entre sus zonas: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request Supngase que usted corre servidores de correo y pop3 en DMZ 2 y un servidor Web en DMZ 1. Las reglas que necesitara son: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.0.2.178 tcp smtp #Mail from #Internet ACCEPT net dmz:192.0.2.178 tcp pop3 #Pop3 from #Internet ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet ACCEPT net dmz:192.0.2.177 tcp http #WWW from #Internet ACCEPT net dmz:192.0.2.177 tcp https #Secure WWW #from Internet ACCEPT loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network Si usted corre un servidor DNS pblico en 192.0.2.177, necesitara agregar las siguientes reglas: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.0.2.177 udp domain #UDP DNS from #Internet ACCEPT net dmz:192.0.2.177 tcp domain #TCP DNS from #Internet ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet Probablemente desear comunicarse con su firewall y con los sistemas DMZ desde la red local, se recomienda SSH que por medio del utilitario scp tambin puede realizar tareas de publicacin y de actualizacin de software.

#ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT loc dmz tcp ssh #SSH to the DMZ ACCEPT net $FW tcp ssh #SSH to the #Firewall Peculiaridades y Fines La discusin anterior refleja nuestras preferencias por el uso de Proxy ARP para nuestros servidores en la DMZ y SNAT/NAT para los sistemas locales. Preferimos usar NAT slo en casos donde un sistema que es parte de una subred RFC 1918 necesita tener su propia direccion IP pblica. Si no lo ha hecho an, es buena idea que revise su /etc/shorewall/shorewall.conf slo para ver si hay algo de su interes. Tambin puede qeu desee ver los otros archivos de configuracin que no ha tocado an para tener una idea para qu otras cosas puede usarse Shorewall. En caso de que no haya mantenido nota, aqu se encuentra el conjunto final de los archivos de configuracin para nuestra red ejemplo. Slo aquellos archivos que fueron modificados de su instalacin original se muestran aqu. /etc/shorewall/interfaces (Las opciones sern muy especficas al sitio). #ZONE INTERFACE net eth0 detect loc eth1 detect dmz eth2 detect BROADCAST OPTIONS rfc1918,routefilter

La configuracin descrita requiere que sus interfaces de red se levanten antes de que Shorewall pueda ser iniciado. Esto abre una pequea ventana de tiempo durante la cual no tiene proteccin de firewall. Si remplaza detect con las direcciones reales de difusin (broadcast) en las entradas anteriores, usted podr levantar Shorewall antes de levantar las interfaces de red. #ZONE INTERFACE BROADCAST net eth0 192.0.2.255 rfc1918 loc eth1 192.168.201.7 dmz eth2 192.168.202.7 /etc/shorewall/masq - Subred Local #INTERFACE SUBNET eth0 192.168.201.0/29 /etc/shorewall/proxyarp - DMZ #ADDRESS EXTERNAL 192.0.2.177 eth2 eth0 192.0.2.178 eth2 eth0 INTERFACE No No HAVE ROUTE ADDRESS 192.0.2.176 OPTIONS

/etc/shorewall/nat- Sistema de mi hija #EXTERNAL INTERFACE INTERNAL 192.0.2.179 eth0 192.168.201.4 No /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ALL INTERFACES LOCAL No

ACCEPT dmz ACCEPT loc ACCEPT net ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT

loc icmp echo-request dmz icmp echo-request loc:192.168.201.4 tcp www #Daughter's #Server net dmz:192.0.2.178 tcp smtp #Mail from #Internet net dmz:192.0.2.178 tcp pop3 #Pop3 from #Internet loc dmz:192.0.2.178 tcp smtp #Mail from local #Network loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall dmz:192.0.2.178 net tcp smtp #Mail to the #Internet net dmz:192.0.2.177 tcp http #WWW from #Internet net dmz:192.0.2.177 tcp https #Secure WWW #from Internet loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network net dmz:192.0.2.177 udp domain #UDP DNS from #Internet net dmz:192.0.2.177 tcp domain #TCP DNS from #Internet loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet loc dmz tcp ssh #SSH to the DMZ net $FW tcp ssh #SSH to the #Firewall

DNS Dado el conjunto RFC 1918 y las direcciones pblicas en esta configuracin, slo tiene sentido tener servidores DNS separados, interno y externo. Usted puede combinar los dos en un nico servidor BIND 9 usando Vistas (Views). Si no est interesado en vistas de Bind 9, puede salta hasta la prxima seccin. Suponga que su dominio es foobar.net y quiere que dos sistemas DMZ se llamen www.foobar.net y mail.foobar.net y quiere que los tres sistemas locales se llamen "winken.foobar.net, blinken.foobar.net y nod.foobar.net". Usted quiere que su firewall sea conocido como firewall.foobar.net externamente y su interface local que sea conocida comos gateway.foobar.net y su interface a la dmz como dmz.foobar.net. Hagamos que el servidor DNS est en 192.0.2.177 que a su vez ser conocido por el nombre ns1.foobar.net.

El archivo /etc/named.conf lucira as: options { directory "/var/named"; listen-on { 127.0.0.1 ; 192.0.2.177; }; transfer-format many-answers; max-transfer-time-in 60; allow-transfer { // Servers allowed to request zone tranfers <secondary NS IP>; }; }; logging { channel xfer-log { file "/var/log/named/bind-xfer.log"; print-category yes; print-severity yes; print-time yes; severity info; }; category xfer-in { xfer-log; }; category xfer-out { xfer-log; }; category notify { xfer-log; }; }; # # This is the view presented to our internal systems # view "internal" { # # These are the clients that see this view # match-clients { 192.168.201.0/29; 192.168.202.0/29; 127.0.0.0/8; 192.0.2.176/32; 192.0.2.178/32; 192.0.2.179/32; 192.0.2.180/32; }; # # If this server can't complete the request, it should use # outside servers to do so # recursion yes; zone "." in { type hint; file "int/root.cache"; }; zone "foobar.net" in { type master; notify no;

allow-update { none; }; file "int/db.foobar"; }; zone "0.0.127.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.127.0.0"; }; zone "201.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.201"; }; zone "202.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.202"; }; zone "176.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.176"; }; zone "177.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.177"; }; zone "178.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.178"; }; zone "179.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.206.124.146.179"; }; }; # # This is the view that we present to the outside world

# view "external" { match-clients { any; }; # # If we can't answer the query, we tell the client so # recursion no; zone "foobar.net" in { type master; notify yes; allow-update {none; }; file "ext/db.foobar"; }; zone "176.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.176"; }; zone "177.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.177"; }; zone "178.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.178"; }; zone "179.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.179"; }; }; Aqu se encuentra los archivos en /var/named (aquellos que no se muestran usualmente estn incluidos en su distribucin de bind). db.192.0.2.176 - Esta es la zona reversa para la interface externa del firewall ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32 ; Filename: db.192.0.2.176 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour)

3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net. db.192.0.2.177 - Zona reversa para el servidor www ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32 ; Filename: db.192.0.2.177 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net. db.192.0.2.178 - Zona reversa para el servidor de correo ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32 ; Filename: db.192.0.2.178 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>.

; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net. db.192.0.2.179 - Zona reversa para el servidor pblico web de mi hija ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32 ; Filename: db.192.0.2.179 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net. int/db.127.0.0 - Zona revers para localhost ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8 ; Filename: db.127.0.0 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001092901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR localhost.foobar.net. int/db.192.168.201 - Zona reversa para la red local. Esta slo se muestra a los clientes internos. ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29 ; Filename: db.192.168.201

; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR gateway.foobar.net. 2 86400 IN PTR winken.foobar.net. 3 86400 IN PTR blinken.foobar.net. 4 86400 IN PTR nod.foobar.net. int/db.192.168.202 - Zona reversa para la interface DMZ del firewall ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29 ; Filename: db.192.168.202 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR dmz.foobar.net. int/db.foobar - Zona para los clientes internos ;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002071501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; foobar.net Nameserver Records (NS)

;############################################################ @ 604800 IN NS ns1.foobar.net. ;############################################################ ; Foobar.net Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 firewall www ns1 mail gateway winken blinken nod dmz 86400 IN A 192.0.2.176 86400 IN A 192.0.2.177 86400 IN A 192.0.2.177 86400 IN A 192.0.2.178 86400 IN A 192.168.201.1 86400 IN A 192.168.201.2 86400 IN A 192.168.201.3 86400 IN A 192.168.201.4 86400 IN A 192.168.202.1

ext/db.foobar - Zona para los clientes externos. ;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002052901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; Foobar.net Nameserver Records (NS) ;############################################################ @ 86400 IN NS ns1.foobar.net. @ 86400 IN NS <secondary NS>. ;############################################################ ; Foobar.net Foobar Wa Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 ; ; The firewall itself ; firewall 86400 IN A 192.0.2.176 ; ; The DMZ ; ns1 86400 IN A 192.0.2.177 www 86400 IN A 192.0.2.177 mail 86400 IN A 192.0.2.178 ; ; The Local Network ; nod 86400 IN A 192.0.2.179

;############################################################ ; Current Aliases for foobar.net (CNAME) ;############################################################ ;############################################################ ; foobar.net MX Records (MAIL EXCHANGER) ;############################################################ foobar.net. 86400 IN A 192.0.2.177 86400 IN MX 0 mail.foobar.net. 86400 IN MX 1 <backup MX>. Algunos Concejos a Manterne en Mente Usted no puede probar su firewall desde adentro. Slo porque pueda enviar solicitudes hacia su direccin IP externa en el firewall no significa que la solicitud ser asociada con la interface externa o la zona net. Cualquier trfico que genere desde la red local ser asociado con su interface local y ser tratada como trfico loc->$FW . Las direcciones IP son propiedad de los sistemas, no de las interfaces. Es un error creer que su firewall es capaz de renviar paquetes solo porque puede hacerle ping a todas las direcciones IP en las interfaces del firewall desde la red local. La nica conclusin que puede sacar de tal ping es que el enlace entre su sistema local y el firewall funciona y que probablemente tiene la configuracin de default gateway bien ajustada. Todas las direcciones IP configuradas en las interfaces del firewall estn en la zona $FW (fw) . Si 192.168.1.254 es la direccin IP de su interface interna entonces puede escribir $FW:192.168.1.254 en una regla pero no puede escribir loc:192.168.1.254. De forma similar, no tiene sentido agregar 192.168.1.254 a la zona loc usando una entrada en /etc/shorewall/hosts. Los paquetes de respuesta NO siguen automticamente la ruta reversa hacia el cliente origen que envi la solicitud. Todos los paquetes son enrutados de acuerdo a la tabla de enrutamiento de la mquina en cada paso de su camino. Este asunto usualmente salta cuando la gente instala el firewall Shorewall en forma paralela con el gateway existente e intentan usar DNAT por medio del Shorewall cambiando el default gateway del sistema que recibe las solicitudes traducidas. Las solicitudes entran por el firewall Shorewall por la interface donde la direccin destino IP fue rescrita pero la respuesta sale sin modificar por medio del viejo gateway. Shorewall en s mismo no tiene nocin de adentro y afuera. Estos conceptos se incorporan en cmo se configure Shorewall.

Arrancando y Deteniendo el Firewall El proceso de Instalacin configura su sistema para que arranque Shorewall al arrancar su sistema (boot). El firewall se arrancar usando el comando shorewall start y se detiene usando el comando shorewall stop. Cuando el firewall est detenido, el enrutamiento est habilitado hacia aquellas mquinas que tienen una entrada en /etc/shorewall/routestopped. Un firewall en ejecucin puede reiniciarse con el comando shorewall restart. Si desea eliminar totalmente cualquier elemento de Shorewall de su configuracin Netfilter, use shorewall clear. Edite el archivo /etc/shorewall/routestopped y configure aquellos sistemas que usted desee que estn disponibles para que accedan al firewall cuando ste est detenido. Precaucin Si usted est conectado a su firewall desde internet, no mande el comando shorewall stop a mesno que haya agergado una entrada para la IP desde la cual se ha conectado en /etc/shorewall/routestopped. Tampoco se recomienda usar shorewall restart; es mejor crear una configuracin alterna y probarlar usando el comando shorewall try

Вам также может понравиться