Por qué se ha escrito este documento

Bueno, encontraba un gran vacío en los CÓMOs (HOWTO's) existentes, en los cuales faltaba informacion sobre las funciones "iptables" y "Netfilter" del nuevo kernel 2.4.x de Linux. Entre otras cosas, voy a intentar responder las preguntas que algunos podéis tener sobre las nuevas posibilidades, como la comparación por estado (state matching). Muchas de estas cuestiones se ilustrarán con un ejemplo rc.firewall.txt que podéis usar en vuestros scripts /etc/rc.d/. [Sí, este archivo se basa en el COMO sobre enmascaramiento (masquerading), para aquellos que lo reconozcan].

Además hay un pequeño guión que he escrito por si te lías tanto como yo durante la configuración. Está disponible como rc.flush-iptables.txt.

Cómo se ha escrito

He consultado a Marc Boucher y otras personas del equipo del núcleo de NetFilter. Les agradezco de todo corazón su trabajo y su ayuda en este tutorial, que escribí para boingworld.com y ahora lo mantengo en mi propio sitio web frozentux.net. Este documento os guiará paso a paso a través del proceso de configuración y espero que os ayude a comprender algo más acerca del paquete iptables. Basaré la mayor parte del estudio desarrollado aquí en el ejemplo del archivo rc.firewall, ya que encuentro en ese ejemplo una buena vía para aprender a usar iptables. He decidido estudiar sólamente las cadenas básicas y desde ahí adentrarme en todas y cada una de las cadenas atravesadas en su orden correspondiente. De esta forma el tutorial es un poquito mas complicado de seguir, aunque también es la forma más lógica. Siempre que encuentres algo difícil de comprender, simplemente vuelve a este tutorial.

Términos empleados en este documento

Este documento contiene algunos términos que pueden necesitar explicaciones más detalladas antes que los leas. Esta sección intentará cubrir los más obvios y cómo los he escogido para usarlos en el documento.

DNAT - Destination Network Address Translation (Traducción de la Dirección de Red de Destino). DNAT se refiere a la técnica de traducir la dirección IP de destino de los paquetes, o sea, de cambiarla. Se emplea conjuntamente con SNAT para permitir a varios hosts (máquinas) compartir una sola dirección IP de conexión con Internet entre todos ellos y al mismo tiempo que todavía puedan seguir ofreciendo funciones de servidor. Normalmente ésto se consigue asignando diferentes puertos a la dirección IP externa (la dirección enrutable) y a continuación informando al encaminador/enrutador (router) de Linux dónde debe enviar el tráfico.

SNAT - Source Network Address Translation (Traducción de la Dirección de Red de Origen). Se refiere a las técnicas empleadas para traducir la dirección de origen de un paquete en otra distinta. Como en DNAT, se emplea para que varios hosts puedan compartir una misma dirección IP de salida a Internet. Estas técnicas se emplean debido a que cada vez hay menos direcciones de Internet disponibles a causa de la propia estructura de IPv4 (la versión 6 del protocolo IP, IPv6, solucionará este problema).

Flujo (de datos) (Stream) - Este término se refiere a una conexion que envía y recibe paquetes relacionados entre sí de algún modo. Básicamente, he usado este término para cualquier conexión que envíe 2 ó más paquetes en ambas direcciones. En TCP ésto puede corresponder a una conexión que envía un paquete SYN y entonces responde con un paquete SYN/ACK; pero también puede ser equivalente a una conexión que envía un paquete SYN y responde con un mensaje ICMP de servidor (host) inalcanzable. En otras palabras, uso este término muy libremente.

Estado (State) - Este término se refiere a en qué estado se encuentra el paquete, de acuerdo con el estándar RFC 793 - Transmission Control Protocol o bien con los estados de usuario empleados en Netfilter/iptables. Ten en cuenta que los estados usados interna y externamente no siguen totalmente la especificación RFC 793. La razón principal es que Netfilter tiene hacer varias suposiciones acerca de las conexiones y los paquetes.

Espacio de usuario (User space) - Con este término me refiero a cualquier cosa que tenga lugar fuera del núcleo. Por ejemplo, la ejecución de iptables -h tiene lugar fuera del núcleo, mientras que iptables -A FORWARD -p tcp -j ACCEPT tiene lugar (parcialmente) dentro del núcleo, puesto que se añade una nueva regla al conjunto de reglas.

Espacio del núcleo (Kernel space) - Esto es más o menos lo opuesto al espacio de usuario. Ésto implica las acciones que tienen lugar dentro del núcleo y no fuera de él.

Dónde conseguir iptables

El paquete de espacio de usuario de iptables se puede descargar desde la página de inicio de Netfilter. El paquete iptables también utiliza las capacidades del espacio del núcleo, las cuales pueden configurarse durante la ejecución de make configure. Los pasos necesarios se discutirán a continuación.

Configuración del núcleo (kernel)

Para ejecutar lo más básico de iptables tienes que configurar las siguientes opciones en el núcleo mientras ejecutas make config o uno de sus comandos relacionados:

CONFIG_PACKET - Esta opción permite que las aplicaciones y las utilidades que lo necesiten puedan trabajar directamente con distintos periféricos de red. Ejemplos de estas utilidades son tcpdump o snort.

En sentido estricto, CONFIG_PACKET no es necesario para que iptables funcione, pero puesto que tiene tantos usos diferentes, he decidido incluirlo. Si crees que no lo necesitas, no lo incluyas.

CONFIG_NETFILTER - Esta opción se requiere cuando vas a utilizar tu ordenador como cortafuegos o como puerta de enlace (gateway) con Internet. En otras palabras, es imprescindible para que funcione cualquier cosa de las que se explican en este tutorial. Entiendo que éso es lo que deseas, ya que estás leyendo el tutorial.

Y, por supuesto, necesitas añadir los controladores (drivers) necesarios para que tus interfases funcionen correctamente, es decir, el adaptador Ethernet y las interfases PPP y SLIP. Todo lo anterior sólo añade un poco de lo más básico de iptables. En realidad no serás capaz de hacer nada realmente productivo, ya que sólo añade la estructura básica al núcleo. Si quieres utilizar las opciones más avanzadas de iptables, tendrás que configurar las opciones necesarias en el núcleo. A continuación te mostraré las opciones disponibles en una versión 2.4.9 básica del núcleo y las explicaré brevemente:

CONFIG_IP_NF_CONNTRACK - Este módulo es necesario para efectuar el seguimiento de las conexiones. El seguimiento de las conexiones lo emplean, entre otros, la traducción de direcciones (NAT) y el enmascaramiento (Masquerading). Si necesitas proteger con un cortafuegos las máquinas de una red local, definitivamente debes marcar esta opción. Por ejemplo, este módulo lo necesita el script rc.firewall.txt para funcionar.

CONFIG_IP_NF_FTP - Este módulo es necesario si quieres hacer seguimiento de conexiones en las conexiones FTP. Puesto que estas conexiones son bastante difíciles de monitorizar en condiciones normales, el conntrack necesita lo que se denomina un asistente y esta opción lo compila en el núcleo. Si no añades este módulo no serás capaz de hacer transferencias FTP correctamente a través del cortafuegos o la puerta de enlace.

CONFIG_IP_NF_IPTABLES - Esta opción es necesaria si quieres realizar algún tipo de filtrado, enmascaramiento (masquerading) o traducción de direcciones (NAT). Añade toda la estructura de identificación de iptables al núcleo. Sin ésto, no serás capaz de hacer nada en absoluto con iptables.

CONFIG_IP_NF_MATCH_LIMIT - Este módulo no es imprescindible, pero se emplea en el ejemplo rc.firewall.txt. Esta opción añade la comparación LIMIT (límite), ofreciendo la posibilidad de controlar el número de paquetes por minuto que se deben comparar, gobernado por la regla adecuada. Por ejemplo, con -m limit --limit 3/minute compararíamos un máximo de 3 paquetes por minuto. Mediante este módulo también podemos evitar ciertos ataques de denegación de servicios (en inglés: Denial of Service attacks, DoS attacks).

CONFIG_IP_NF_MATCH_MAC - Este módulo nos permite comparar paquetes basándonos en las direcciones físicas MAC: cada adaptador de red Ethernet tiene su propia dirección MAC, distinta a la de cualquier otro adaptador, aunque sea de la misma marca y modelo. Así, por ejemplo podremos bloquear paquetes en función de la dirección MAC utilizada y bloquear ordenadores concretos puesto que la dirección MAC de esos ordenadores raramente cambia (ya que raramente se sustituye el adaptador Ethernet por uno nuevo). No se utiliza esta opción ni en el ejemplo rc.firewall.txt ni en ningún otro sitio.

CONFIG_IP_NF_MATCH_MARK - Nos permite utilizar la comparación MARK. Por ejemplo, podemos utilizar el objetivo MARK para marcar paquetes, de forma que más adelante se puedan comparar y filtrar paquetes dependiendo de si tienen la marca o no. De hecho esta opción es la comparación MARK y más adelante veremos el objetivo MARK.

CONFIG_IP_NF_MATCH_MULTIPORT - Este módulo permite que comparemos paquetes con un amplio rango de puertos de origen o de destino. Normalmente ésto no sería posible, pero con este módulo sí lo es.

CONFIG_IP_NF_MATCH_TOS - Con esta comparación podemos comparar paquetes en base a su campo TOS, es decir, su Tipo de Servicio (Type Of Service). El tipo de servicio se puede establecer mediante determinadas reglas en la tabla mangle y mediante los comandos ip/tc.

CONFIG_IP_NF_MATCH_TCPMSS - Esta opción nos ofrece la posibilidad de comparar los paquetes TCP en función de su campo MSS.

CONFIG_IP_NF_MATCH_STATE - Aquí tenemos una de las mayores novedades respecto a ipchains. Con este módulo podemos realizar comparaciones por flujos de paquetes (stateful matching). Por ejemplo, si en una conexión TCP ya hemos visto tráfico en dos direcciones, los paquetes que les sigan serán considerados como ESTABLISHED (establecido), aplicándoles por éllo las mismas acciones que a los paquetes que iniciaron el flujo. Este módulo se usa ampliamente en el ejemplo rc.firewall.txt.

CONFIG_IP_NF_MATCH_UNCLEAN - Este módulo nos brinda la posibilidad de comparar paquetes IP, TCP, UDP e ICMP que no cumplen con las normas o son inválidos. En condiciones normales se desecharán estos paquetes, pero nunca sabremos si son legítimos o no. Además, ten en cuenta que esta comparación todavía está en fase experimental y puede que no funcione correctamente en todos los casos.

CONFIG_IP_NF_MATCH_OWNER - con esta opción tendremos la oportunidad de comparar en base al propietario de la conexión. Por ejemplo, podremos permitir acceso a Internet únicamente al usuario "root". Este módulo se escribió para mostrar lo que se podía lograr con el nuevo iptables. Ten en cuenta que esta comparación es experimental y puede que no le funcione bien a todo el mundo.

CONFIG_IP_NF_FILTER - este módulo añade la tabla filter básica que permitirá efectuar el filtrado IP. En la tabla filter encontraremos las cadenas INPUT, FORWARD y OUTPUT. Este módulo es necesario si pretendemos hacer algún tipo de filtrado en los paquetes que recibamos y/o enviemos.

CONFIG_IP_NF_TARGET_REJECT - este objetivo nos permite especificar que se debe enviar un mensaje de error ICMP como respuesta a los mensajes entrantes, en lugar de simplemente desecharlos e ignorarlos. Ten en cuenta que las conexiones TCP, al contrario que las ICMP y las UDP, siempre se reinician o rechazan con un paquete TCP RST.

CONFIG_IP_NF_TARGET_MIRROR - sirve para permitir a los paquetes que sean devueltos ("rebotados") al remitente. Por ejemplo, si configuramos un objetivo MIRROR en el puerto de destino HTTP, en nuestra cadena INPUT, y alguien intenta acceder a este puerto, le devolveremos sus paquetes y como resultado probablemente acabará viendo su propia pagina web inicial (homepage).

CONFIG_IP_NF_NAT - este módulo permite que se efectúe la traducción de dirección de red (network address translation), o NAT, en sus diferentes variantes. La opción nos da acceso a la tabla nat en iptables y es necesaria si queremos hacer reenvío a puertos (port forwarding), enmascaramiento (masquerading), etc. Ten en cuenta que esta opción no es imprescindible para el cortafuegos y el enmascaramiento de una LAN, pero deberías tenerlo activo a no ser que seas capaz de asignar direcciones IP únicas para cada uno de los hosts. Así pues, esta opción es necesaria para que el script de ejemplo rc.firewall.txt funcione correctamente, y es ciertamente imprescindible si no puedes asignar direcciones IP únicas a cada host.

CONFIG_IP_NF_TARGET_MASQUERADE - este módulo añade el objetivo MASQUERADE. Por ejemplo, si no sabemos qué dirección IP tenemos para conectar a Internet, ésta será la forma ideal de conseguir la IP en vez de utilizar DNAT o SNAT. En otras palabras, si utilizamos DHCP, PPP, SLIP o cualquier otra conexión que nos asigne una IP, necesitamos utilizar este objetivo en lugar de SNAT. El enmascaramiento produce una carga en el sistema algo mayor que NAT, pero funcionará sin que necesitemos conocer previamente la dirección IP.

CONFIG_IP_NF_TARGET_REDIRECT - este objetivo es útil al emplearlo junto a proxies de aplicación, por ejemplo. En vez de dejar simplemente que el paquete pase, lo remapeamos para que se dirija a nuestra máquina local. En otras palabras, de esta forma tenemos la posibilidad de crear un proxy transparente.

CONFIG_IP_NF_TARGET_LOG - esta opción añade el objetivo LOG y su funcionalidad a iptables. Podemos utilizar este módulo para registrar determinados paquetes en el syslogd y así ver qué les está pasando. Ésto sólo ya es inestimable de cara a las auditorías de seguridad, forenses o de depuración de errores del script que estés escribiendo.

CONFIG_IP_NF_TARGET_TCPMSS - esta opción se puede emplear para evitar a los Proveedores de Servicios de Internet (ISPs) y a los servidores que bloquean los paquetes "ICMP Fragmentation Needed". Los efectos de esta acción pueden ser páginas web que no lleguen, pequeños correos que sí lleguen mientras que los grandes no lo consigan, las conexiones ssh funcionan pero las conexiones scp se pierden ("mueren") tras el saludo inicial, ... En estos casos podemos utilizar el objetivo TCPMSS para superar el problema ajustando nuestro MSS (tamaño máximo de segmento) al PMTU (Path Maximum Transmit Unit, unidad máxima de transmisión). De esta forma seremos capaces de trabajar con lo que los autores de Netfilter llaman (en la ayuda para la configuración del kernel) "criminally brain-dead ISPs or servers", algo así como "servidores o ISPs absolutamente descerebrados".

CONFIG_IP_NF_COMPAT_IPCHAINS - añade un modo de compatibilidad con el obsoleto ipchains. No confíes en este módulo como solución a largo plazo para resolver la migración de los núcleos 2.2 a los 2.4, ya que es probable que desaparezca con la llegada del núcleo 2.6.

CONFIG_IP_NF_COMPAT_IPFWADM - módulo de compatibilidad con el obsoleto ipfwadm. Ni se te ocurra recurrir a este módulo como solución a largo plazo.

Como puedes observar hay un buen puñado de opciones. Acabo de explicar brevemente los tipos de comportamiento extras que puedes esperar con cada módulo, aunque sólo se trata de las opciones disponibles en un núcleo 2.4.9 simple, sin ningún extra. Si quieres ver más opciones, te recomiendo que mires las funciones existentes en el "patch-o-matic" (POM) de la zona de usuario de Netfilter, pues encontrarás montones de opciones extras para el núcleo. Los parches del POM son opciones extra que supuestamente se añadirán al núcleo en el futuro, pero que todavía no se han desarrollado lo suficiente como para añadírselos. Las razones pueden ser variadas, como que el parche todavía no sea estable, o que Linus Torvalds no pueda mantenerlo, o incluso que no quiera introducir el parche en el desarrollo del núcleo por ser todavía experimental.

Necesitarás tener compiladas en el núcleo las opciones siguientes, o bien tenerlas como módulos, para que el script rc.firewall.txt pueda funcionar. Si necesitas ayuda acerca del resto de opciones necesarias para los otros scripts, léete el capítulo sobre los scripts de ejemplo.

• CONFIG_PACKET

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_FTP

• CONFIG_IP_NF_IRC

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_TARGET_LOG

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_TARGET_MASQUERADE

Como mínimo necesitarás lo anterior para utilizar el script rc.firewall.txt. Para el resto de scripts explicaré lo que necesitan en sus respectivas secciones. Por el momento intentemos centrarnos en el ejemplo principal.

Configuración de la zona de usuario

Para empezar veremos cómo se compila el paquete iptables. Es importante comprender que la mayor parte de la configuración y compilación de iptables va de la mano de la configuración y compilación del núcleo (kernel). Determinadas distribuciones de Linux vienen con el paquete iptables preinstalado, como ocurre por ejemplo con Red Hat. Sin embargo en esta distribución por defecto está desactivado y ahora veremos cómo activarlo.

---

Compilando las aplicaciones de la zona de usuario

Empieza por descomprimir (desempaquetar) el paquete iptables. Para este ejemplo hemos utilizado el paquete iptables 1.2.6a y el núcleo 2.4 sin extras. Descomprime como es habitual, utilizando el comando bzip2 -cd iptables-1.2.6a.tar.bz2 | tar -xvf - (aunque también puedes teclear tar -xjvf iptables-1.2.6a.tar.bz2, que con las versiones más recientes de tar dará el mismo resultado). El paquete debería haberse descomprimido en un nuevo directorio llamado iptables-1.2.6a. Para una explicación más completa de la compilación y la forma de hacer que funcione el programa, léete el fichero iptables-1.2.6a/INSTALL.

Tras ésto, tienes la opción de configurar e instalar módulos/opciones extra en el núcleo. El procedimiento que describiremos sólo comprobará e instalará parches estándar que están pendientes de incluirse en el núcleo; existen otros parches de tipo experimental que sólo estarán disponibles al seguir otro tipo de configuración.

Algunos de estos parches son realmente experimentales y no sería una buena idea instalarlos. Sin embargo, hay montones de comparaciones y objetivos extremadamente interesantes en este punto de la instalación, así que no tengas miedo de, al menos, echarles un vistazo. Para empezar a instalar, ejecutaremos un comando similar al siguiente desde el directorio raíz del paquete iptables:

make pending-patches KERNEL_DIR=/usr/src/linux/

La variable KERNEL_DIR debería indicar la localización actual de tu núcleo. Normalmente este directorio será /usr/src/linux/, aunque puede ser diferente y lo más probable es que ya sepas dónde se encuentra el código fuente del núcleo.

Con el comando anterior sólo añadiremos determinados parches que de todas formas están a punto de entrar en el núcleo. Puede que hayan más parches y añadidos que los desarrolladores de Netfilter estén a punto de añadir al núcleo, pero que todavía no se encuentran listos para dar este paso. Una forma de instalar estos extras es mediante el siguiente comando:

make most-of-pom KERNEL_DIR=/usr/src/linux/

De esta forma se preguntará si se instalan algunos añadidos de lo que en la jerga de Netfilter se llaman patch-o-matic, pero eludiendo los parches más extremos, ya que pueden causar la desintegración del núcleo. Date cuenta que se ha dicho "se preguntará" porque ésto es lo que hará el comando: preguntará antes de cambiar algo en el código fuente del núcleo. Para poder instalar todo el material presente en el patch-o-matic necesitarás ejecutar el siguiente comando:

make patch-o-matic KERNEL_DIR=/usr/src/linux/

No olvides leer completamente la ayuda de cada parche antes de hacer nada. Algunos parches destruyen a otros parches, mientras que otros pueden destruir el núcleo si se usan junto a otros determinados parches del patch-o-matic, etc.

No es imprescindible seguir los pasos anteriores los pasos anteriores, por éllo puedes ignorarlos si no quieres "parchear" tu núcleo. Sin embargo, hay cosas muy interesantes en el patch-o-matic a las que sería conveniente echar un vistazo, por lo que no estaría de más ejecutar los comandos aunque sólo fuera para ver lo que contienen.

En este punto ya has terminado la parte de la instalación referida al patch-o-matic y es momento de compilar un nuevo núcleo utilizando los nuevos parches que hayas añadido al código fuente. No olvides configurar de nuevo el núcleo, ya que probablemente los nuevos parches no se habrán añadido aún a las opciones configuradas. Por otra parte, si quieres puedes compilar primero el programa iptables y dejar para el final la compilación del núcleo.

Compila ahora el programa de zona de usuario iptables. Para éllo ejecuta el siguiente comando:

make KERNEL_DIR=/usr/src/linux/

La aplicación de zona de usuario debería compilarse correctamente. Si no es así, tendrás que buscar soluciones por tí mismo, o puedes subscribirte a la lista de correo de Netfilter (en inglés), dónde tendrás la oportunidad de pedir que alguien te ayude a solucionar tus problemas. Puede que haya algo que no vaya bien durante la instalación, pero no te preocupes: intenta pensar de manera lógica sobre el problema y averigua qué es lo que va mal, o pídele a alguien que te ayude.

Si todo ha ido bien, estarás preparado para instalar los archivos binarios. Para éllo, escribe:

make install KERNEL_DIR=/usr/src/linux/

En principio todo debería funcionar en el programa. Para utilizar los cambios efectuados en iptables deberías recompilar y reinstalar tu núcleo y sus módulos, si es que todavía no lo has hecho. Para una explicación más detallada de la instalación a partir del código fuente de las aplicaciones de zona de usuario, lee el archivo INSTALL que viene con el código fuente, pues contiene excelente información sobre todo lo referente a la instalación.

---

Instalación en Red Hat 7.1

La distribución Red Hat en su versión 7.1 viene precompilada con un núcleo 2.4.x que contiene a Netfilter e iptables. Además, contiene los programas básicos de zona de usuario, así como los ficheros de configuración necesarios para ejecutarlos. Sin embargo, los de Red Hat han desactivado el paquete completo y en su lugar utilizan el módulo ipchains por compatibilidad con versiones anteriores. Molesto, por no decir otra cosa, y fuente de multitud de consultas en las listas de correo preguntando por qué no funciona iptables. Así pues, echemos un vistazo a cómo desactivar el módulo ipchains y cómo instalar iptables en su lugar.

La instalación por defecto de Red Hat 7.1 incluye una decepcionante versión antigua de las aplicaciones de zona de usuario, por lo que es posible que desees compilar una nueva versión de estas aplicaciones, además de instalar un núcleo nuevo y personalizado antes de exigirle el máximo rendimiento a iptables.

Antes de empezar tendrás que desactivar los módulos de ipchains de manera que no vuelvan a arrancar de ahora en adelante. Para conseguirlo deberás cambiar algunos nombres de fichero en los subdirectorios existentes en /etc/rc.d/. Con el siguiente comando tendrás suficiente:

chkconfig --level 0123456 ipchains off

Una vez ejecutado modificarás todos los enlaces virtuales ("soft links") que apuntan al script /etc/rc.d/init.d/ipchains y los convertirás en K92ipchains. La primera letra, que por defecto es una S, le indica a los scripts de inicio que se ejecuten. Al cambiarla por una K se le indica a los scripts que terminen el servicio, o que no lo ejecuten si no estaba arrancado. De esta forma el servicio ya no arrancará nunca.

Sin embargo, para detener un servicio que se está ejecutando en este momento necesitamos introducir otro comando: service, que puede utilizarse para actuar sobre servicios actualmente en ejecución. Así pues, para parar el servicio ipchains escribiremos:

service ipchains stop

Por último, para arrancar el servicio iptables necesitamos saber en qué niveles de ejecución ("run-levels") queremos que se inicie. Normalmente serán los niveles 2, 3 y 5, que se usan para:

• 2. Multiusuario sin NFS o lo mismo que el nivel 3 si no existe ninguna red.

• 3. Modo multiusuario completo, es decir, el nivel de ejecución habitual en el que se trabaja.

• 5. X11. Este modo se utiliza cuando al arrancar el sistema entras directamente en las Xwindows (el modo gráfico). Actualmente cada vez son más las distribuciones que entran por defecto en este modo.

Para conseguir que iptables se ejecute en estos niveles de ejecución, escribiremos:

chkconfig --level 235 iptables on

Es decir, instruímos a iptables para que se ejecute en los niveles 2, 3 y 5. Si quieres que se ejecute en cualquier otro nivel, deberás añadirlo al comando anterior. Sin embargo, ninguno de los otros niveles debería usarse para ejecutar iptables, por lo que en realidad no necesitas activarlo en éllos: el nivel 1 es el modo monousuario (1 sólo usuario), empleado cuando necesitas arreglar una instalación. El nivel 4 no debería usarse y el nivel 6 es para apagar el ordenador.

Para activar el servicio iptables, ejecutaremos:

service iptables start

No hay ninguna regla en el script de iptables. Para añadirlas en Red Hat 7.1 normalmente se emplean dos métodos. El primero es editar el script /etc/rc.d/init.d/iptables, teniendo como efecto secundario no deseado el hecho de que borrarás todas las reglas si actualizaste el paquete iptables mediante un RPM. El otro método consistiría en cargar/crear el conjunto de reglas y luego guardarlo con el comando iptables-save, de forma que después se carguen automáticamente mediante los scripts rc.d.

Primero explicaremos cómo configurar iptables mediante el socorrido método de copiar y pegar al script "init.d" de iptables. Para añadir reglas que se tengan que ejecutar cuando el sistema arranca el servicio, añádelas en la sección "start)", o en la función "start()". Ten en cuenta que si añades las reglas en la sección "start)" no debes olvidar parar la función "start()" dentro de esa misma sección "start)". Además, tampoco olvides editar la sección "stop)" para indicarle al script qué debe hacer, por ejemplo cuando es sistema se esté cerrando (apagando), o cuando se entre en un nivel de ejecución que no necesite de iptables. Por último, no olvides repasar las secciones "restart" y "condrestart". También debes tener en cuenta que todo este trabajo no servirá de nada si, por ejemplo, actualizas automáticamente tus paquetes mediante el Red Hat Network, o si actualizas mediante el paquete RPM de iptables.

En cuanto al segundo método de realizar la configuración, se basa en los siguientes pasos: primero crea un conjunto de reglas en un fichero de script de línea de comandos (un script de shell), o bien directamente con iptables, que cumpla con tus necesidades y empieza a experimentar con él durante un tiempo. Cuando tengas una configuración que funcione correctamente (o al menos que tú creas que no tiene errores), utiliza el comando iptables-save. Puedes utilizar: iptables-save > /etc/sysconfig/iptables, con lo que grabarías el conjunto de reglas en el fichero /etc/sysconfig/iptables. Este fichero lo usará en el futuro el script rc.d de iptables para cargar de nuevo el conjunto de reglas. Otra forma de conseguir un resultado equivalente es mediante el comando service iptables save, que automáticamente guardará el script en el fichero /etc/sysconfig/iptables. Así, la próxima vez que reinicies el sistema, el script rc.d de iptables utilizará el comando iptables-restore para cargar el conjunto de reglas desde el fichero /etc/sysconfig/iptables. Atención: no mezcles ambos métodos, ya que se pueden perjudicar gravemente el uno al otro y dejar la configuración del cortafuegos completamente inútil.

Cuando hayas terminado todos estos pasos, puedes desinstalar los paquetes ipchains e iptables preinstalados. De esta forma no permitiremos al sistema que mezcle las nuevas aplicaciones de zona de usuario de iptables con las viejas versiones preinstaladas. Sin embargo, este paso sólo es necesario si vas a instalar iptables desde el código fuente. No es raro que el paquete nuevo se mezcle con el viejo, puesto que la instalación basada en rpm instala el paquete en directorios no estándar, de forma que la nueva instalación no sobreescribirá a la vieja. Para efectuar la desinstalación, escribe:

rpm -e iptables

Y como no tiene mucho sentido mantener instalado ipchains cuando no lo vas a utilizar nunca más, desinstálalo de la misma forma:

rpm -e ipchains

Tras todo ésto, habrás finalizado la actualización del paquete iptables mediante el código fuente, habiendo seguido las instrucciones del código. Además ningún viejo ejecutable, librería o fichero auxiliar permanecerá instalado.

Generalidades

Cuando un paquete entra en el cortafuegos (firewall), alcanza el hardware y es procesado en el núcleo por su driver correspondiente. Después el paquete empieza a recorrer una serie de etapas en el núcleo antes de ser enviado a la aplicación adecuada (localmente), reenviada hacia otro host, o cualquier otra operación.

En primer lugar, echemos un vistazo a un paquete destinado a nuestro propio host local (nuestra máquina). Recorrerá los siguientes pasos antes de ser entregado a la aplicación que lo requiere:

Date cuenta que esta vez el paquete ha atravesado la cadena INPUT en lugar de la cadena FORWARD y ésto es bastante lógico. Lo más probable es que ahora al principio sea lo único que te parecerá realmente lógico acerca de cómo se atraviesan las tablas y cadenas, pero conforme sigas pensando en éllo con el paso del tiempo, lo irás viendo todo aún más claro.

Ahora nos centraremos en los paquetes que salen de nuestro host y las etapas por las que pasan.

En este ejemplo estamos asumiendo que el paquete está destinado a otro host de otra red. El paquete sigue los siguientes pasos, de esta manera:

Como puedes ver hay bastantes pasos que dar. El paquete puede ser bloqueado en cualquiera de las cadenas de iptables o en algún otro sitio si está malformado; sin embargo, estamos principalmente interesados en la parte relacionada con iptables. Ten en cuenta que no hay cadenas o tablas específicas para interfases diferentes ni nada por el estilo. La cadena FORWARD es siempre atravesada por todos los paquetes que son reenviados a través de este cortafuegos/router.

¡No uses la cadena INPUT para filtrar en el escenario anterior! INPUT está pensada sólamente para nuestro host local, no para hacer enrutamientos a ningún otro destino.

Hemos visto hasta ahora cómo las cadenas son atravesadas en tres escenarios independientes. Si deseáramos hacer un buen esquema de todo ésto, podría asemejarse a algo como:

Para aclarar esta imagen considera lo siguiente: si llega un paquete que no está destinado a nuestra máquina local, en la primera decisión de enrutamiento será dirigido hacia la cadena FORWARD. Por otra parte, si el paquete está destinado a una dirección IP que está siendo escuchada por nuestra máquina local, el paquete sería enviado a la cadena INPUT y después a la máquina local.

También conviene advertir el hecho de que los paquetes pueden estar destinados a la máquina local y, sin embargo, la dirección de destino ser modificada por la cadena PREROUTING haciendo NAT. Dado que ésto tiene lugar antes de la primera decisión de enrutamiento, el paquete será revisado tras dicho cambio. Debido a ésto, el camino a seguir por el paquete (debido a una modificación de la IP de destino) podría cambiar antes de que la decisión de enrutamiento sea tomada. Date cuenta que todos los paquetes irán a través de un camino u otro de esta imagen. Si haces DNAT devolviendo el paquete a la misma red por la que vino, seguirá viajando por el resto de cadenas hasta que regrese a dicha red.

Si crees que necesitas más información puedes usar el script rc.test-iptables.txt. Este script "de laboratorio" debería proporcionarte las reglas necesarias para comprobar cómo son atravesadas las tablas y las cadenas.

Tabla mangle

Esta tabla debe ser principalmente usada para modificar paquetes, como ya hemos dicho antes. En otras palabras, aquí puedes usar libremente las comparaciones de modificación para cambiar el campo TOS (Type Of Service), entre otras cosas.

Es más que recomendable no usar esta tabla como filtro: ni DNAT, ni SNAT, ni Masquerading trabajan en esta tabla.

Objetivos para los que únicamente se destina la tabla mangle:

• TOS

• TTL

• MARK

El TOS es usado para definir y/o cambiar el campo Type Of Service del paquete. Puede ser usado para configurar políticas en la red considerando cómo deben ser enrutados los paquetes y tareas similares. Ten en cuenta que éste tema no ha sido perfeccionado y no está realmente implementado en Internet, por lo que la mayoría de los routers no hacen caso del valor de este campo y aún más, a veces actúan de manera imperfecta sobre los paquetes que reciben. En otras palabras, no lo uses para paquetes que vayan hacia Internet, a menos que quieras tomar decisiones de enrutamiento sobre ellos con iproute2.

El TTL es usado para cambiar el campo TTL (Time To Live) de un paquete y con éllo conseguir que los paquetes tengan un TTL específico. Una buena razón para hacerlo podría ser que no queramos ser descubiertos por ciertos proveedores de servicios de internet (ISP) demasiado fisgones: a algunos ISPs no les gustan los clientes que usan multiples ordenadores bajo una única conexión y saben que se trata de una única conexión porque de un mismo host llegan paquetes con diferentes valores de TTL (entre otros muchos signos delatores).

El Mark se usa para para marcar (mark) los paquetes con valores específicos. Estas marcas pueden ser reconocidas posteriormente por los programas iproute2 para realizar diferentes enrutamientos dependiendo de la marca que tengan o no tengan los paquetes. También podemos limitar en ancho de banda y realizar Class Based Queuing (colas basadas en clases, CBQ) según dichas marcas.

Tabla nat

Esta tabla debe ser usada sólo para hacer NAT (Network Address Translation) a los diferentes paquetes. En otras palabras, debe ser empleada solamente para traducir el campo origen del paquete o el campo destino. Ten en cuenta que tal como hemos dicho antes, sólo el primer paquete de un flujo alzanzará esta cadena. Después, al resto de paquetes del mismo flujo de datos se les aplicará la misma acción que al primero. Los objetivos que hacen este tipo de cosas son:

• DNAT

• SNAT

• MASQUERADE

El objetivo DNAT (Destination Network Address Translation) se emplea principalmente en los casos donde se tiene una IP pública y se quiere redirigir los accesos al firewall hacia algún otro host (en una "zona desmilitarizada", DMZ, por ejemplo). Dicho de otro modo, cambiamos la dirección de destino del paquete y lo re-enrutamos a otro host.

SNAT (Source Network Address Translation) es principalmente usada para cambiar la dirección de origen de los paquetes. La mayoría de las veces querrás esconder tus redes locales, DMZ, etc. Un ejemplo muy bueno podría ser cuando queremos sustituir las direcciones IP de la red local que está tras el cortafuegos, por la dirección IP del propio cortafuegos, que posee una IP pública hacia fuera. Con este objetivo el firewall automaticamente hará SNAT y de-SNAT sobre los paquetes, lo cual hace posible que las conexiones provenientes de la LAN salgan a Internet. Por ejemplo, si tu red usa 192.168.0.0/máscara_de_red, los paquetes nunca regresarán de Internet, porque IANA ha designado dicho rango de direcciones (entre otras) como privadas y sólo para ser usadas en redes locales aisladas.

El objetivo MASQUERADE se usa exactamente para lo mismo que SNAT, pero MASQUERADE requiere un poquito más de trabajo del procesador. La razón es que cada vez que llega un paquete al objetivo MASQUERADE, automáticamente chequea qué dirección IP debe asignarle, en lugar de hacer como SNAT, que simplemente utiliza la dirección IP configurada. MASQUERADE hace posible trabajar con las direcciones IP Dinámicas por DHCP que tu ISP pueda proporcionarte a través de conexiones a Internet vía PPP, PPPoE o SLIP.

tabla Filter

La tabla filter se usa principalmente para el filtrado de paquetes: podemos comparar y filtrar paquetes de la forma que queramos. Se trata del lugar en que miramos el contenido de los paquetes y tomamos la determinación de desecharlos ((DROP)) o aceptarlos ((ACCEPT)). Por supuesto, podemos hacer filtrado antes, pero esta tabla en particular fue diseñada para realizar todas las operaciones de filtrado. Casi todos los objetivos se pueden usar en esta tabla. Trataremos ésto más ampliamente, pero desde ahora ya sabes que esta tabla es el lugar correcto para llevar a cabo el principal filtrado.

Introducción

La máquina de estados es una parte especial de iptables que no debería llamarse así ("máquina de estados"), puesto que en realidad es una máquina de seguimiento de conexiones. Sin embargo, mucha gente la conoce por el primer nombre. A lo largo del capítulo utilizaré ambos nombres como si fueran equivalentes, aunque ésto no debería ocasionar demasiados problemas. El seguimiento de conexiones se efectúa para que la estructura de Netfilter sepa cuál es el estado de cada conexión específica. Los cortafuegos que trabajan de esta manera normalmente se denominan "stateful firewalls" (cortafuegos que consideran las peticiones y respuestas de una máquina como una única conexión de un mismo flujo de datos; podríamos traducirlo como "cortafuegos de flujos"), mientras que los que no lo hacen se denominan "non-stateful firewalls" (cada petición es independiente, aunque provenga de la misma máquina; podríamos traducirlo como "cortafuegos de conexiones"). Los cortafuegos de tipo "stateful" son mucho más seguros, pues nos permiten elaborar conjuntos de reglas mucho más precisos.

En iptables los paquetes se pueden relacionar con las conexiones mediante cuatro "estados" diferentes: NEW (nuevo), ESTABLISHED (establecido), RELATED (relacionado) e INVALID (inválido o no válido). Los trataremos en profundidad más adelante. Mediante la comparación --state podemos controlar fácilmente qué o quién tiene permiso para iniciar nuevas sesiones.

Todo el seguimiento de las conexiones la realiza una estructura especial del núcleo llamada "conntrack". El "conntrack" puede cargarse como módulo o como una parte más del núcleo, pero sea como sea la mayoría de las veces necesitaremos y pediremos un seguimiento de conexiones más específico que el que proporciona por defecto el motor del conntrack. Por éllo, hay unas partes específicas que se encargan de los protocolos TCP, UDP o ICMP, entre otros. Estos módulos captan información específica, única, de los paquetes, de forma que pueden mantener un seguimiento de cada flujo de datos. La información que recopilan los módulos se utiliza para indicarle al conntrack en qué estado se encuentra el flujo en cada momento. Por ejemplo, los flujos UDP normalmente se identifican y distinguen por su dirección IP de destino, su dirección IP de origen, su puerto de destino y su puerto de origen.

En anteriores núcleos teníamos la posibilidad de ejecutar o parar la desfragmentación de paquetes, sin embargo, desde que se introdujeron iptables y Netfilter y en particular desde que se introdujo el seguimiento de conexiones, esta opción fue eliminada. La razón es que el seguimiento de conexiones no funciona correctamente sin defragmentar los paquetes, por lo que se ha introducido en el conntrack y el proceso se realiza automáticamente. No se puede parar si no paramos también el seguimiento de conexiones. En otras palabras, desde el momento en que se emplea el seguimiento de conexiones, se emplea la desfragmentación de paquetes.

Todo el seguimiento de conexiones se efectúa en la cadena PREROUTING, excepto los paquetes generados localmente, que son controlados en la cadena OUTPUT. Ésto significa que iptables realizará todo el recálculo de estados en estas dos cadenas de la tabla Nat: si somos nosotros los que enviamos el paquete inicial del flujo, su estado se establece como NEW (nuevo) en la cadena OUTPUT, mientras que al recibir el paquete de retorno (el que "contesta" al paquete inicial) el estado del flujo se cambia a ESTABLISHED (establecido) en la cadena PREROUTING. Por el contrario, si el primer paquete no lo hemos originado nosotros, el estado NEW se establece en la cadena PREROUTING.

Las "entradas" del conntrack

Entendamos como "entrada" el registro que mantiene el conntrack de cada conexión y toda la información necesaria correspondiente a esa conexión. Así pues, veamos una entrada del conntrack tal como la podríamos encontrar en /proc/net/ip_conntrack y aprendamos a interpretarla (en este fichero encontraremos un listado de todas las entradas presentes en la base de datos del conntrack). Si tienes cargado el módulo ip_conntrack, un "cat" de /proc/net/ip_conntrack podría parecerse a:

tcp      6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
     dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
     dport=32775 use=2
     

Este ejemplo contiene toda la información que el módulo conntrack mantiene para saber en qué estado se encuentra una conexión determinada. Para empezar tenemos el protocolo, que en este caso es el tcp. A continuación tenemos la misma información en su notación decimal equivalente ("6"). Después viene el tiempo de vida restante para esta entrada en particular: en el ejemplo a esta conexión le quedan 117 segundos, que irán disminuyendo hasta que se vea más tráfico perteneciente a la conexión. Cuando llega ese nuevo tráfico el contador se establece de nuevo a su valor por defecto (valor que depende del estado en que se encuentra la conexión en el momento de recibir nuevos paquetes). Sigue la información del estado actual en que se encuentra la entrada. En el ejemplo estamos viendo un paquete que se encuentra en el estado SYN_SENT. El valor interno de una conexión es ligeramente distinto a los empleados externamente por iptables. El valor SYN_SENT nos dice que tenemos delante una conexión que sólo a visto un paquete TCP SYN en una dirección. Después vemos la dirección IP de origen, la dirección IP de destino, el puerto de origen y el puerto de destino. En este punto vemos una clave específica que nos indica que no hemos visto ningún tráfico de retorno para esta conexión. Para terminar, vemos los datos que esperamos en los paquetes de retorno: las direcciones de origen y destino (que están invertidas respecto a las anteriores, ya que el paquete será devuelto hacia nosotros) y los puertos de origen y destino (también invertidos respecto a los anteriores). Así pues, éstos son los valores que podrían ser de nuestro interés.

Las entradas del seguimiento de conexiones pueden tomar diferentes valores, todos éllos especificados en las cabeceras ("headers") disponibles en los archivos linux/include/netfilter-ipv4/ip_conntrack*.h. Estos valores dependen del subprotocolo IP que estemos usando. Los protocolos TCP, UDP o ICMP toman los valores por defecto especificados en linux/include/netfilter-ipv4/ip_conntrack.h. Lo estudiaremos en detalle al revisar cada protocolo, sin embargo, no ahondaremos demasiado en este capítulo puesto que sólo se utilizan dentro del conntrack. Por otra parte, según cambia el estado también cambia el valor por defecto del tiempo que debe transcurrir hasta eliminar la conexión (el "contador de vida restante de la conexión" explicado anteriormente).

Desde hace poco hay un nuevo parche en el "patch-o-matic" de iptables llamado "tcp-window-tracking". Este parche añade, entre otras cosas, todos los tiempos límite mencionados a variables especiales del "sysctl", con lo que se pueden cambiar (los tiempos) al instante, mientras el sistema está en marcha. Gracias a ésto ya no es necesario recompilar el núcleo cada vez que se deseen cambiar los límites de los contadores de tiempo. Estos límites se pueden modificar utilizando llamadas al sistema específicas que se encuentran disponibles en el directorio /proc/sys/net/ipv4/netfilter. Concretamente debes buscar las variables /proc/sys/net/ipv4/netfilter/ip_ct_*.

Cuando una conexión ha visto tráfico en ambas direcciones, se modificará su entrada del conntrack eliminando la clave [UNREPLIED] (que nos indica que la conexión no ha visto tráfico en ambas direcciones) y añadiendo (casi al final de la entrada) la clave [ASSURED]. Esta clave nos dice que la conexión está asegurada y por éllo no será eliminada si alcanzamos el límite máximo de conexiones simultáneas soportadas por el conntrack, todo lo contrario a aquellas que no están marcadas como [ASSURED], que sí serán borradas al alcanzar el límite de conexiones. El número de conexiones mantenidas en la tabla del seguimiento de conexiones depende de una variable, que puede establecerse a través de las funciones de ip-sysctl en los núcleos Linux más recientes. El valor por defecto de esta variable depende en gran medida de la cantidad de memoria que tengas instalada: para 128 MB de RAM tendrás un máximo de 8192 entradas, mientras que con 256 MB de RAM llegarás hasta las 16376 entradas. Puedes ver y modificar estos valores a través de la propiedad /proc/sys/net/ipv4/ip_conntrack_max.

Estados del espacio de usuario

Como has podido ver, los paquetes pueden tomar distintos estados dentro del núcleo, dependiendo del protocolo considerado. Sin embargo, fuera del núcleo sólo tenemos los cuatro estados descritos anteriormente. Principalmente estos estados se pueden emplear junto a la comparación de estados (state match), con lo cual esta comparación será capaz de diferenciar paquetes en función del estado en que se encuentren dentro del seguimiento de conexiones. Los estados válidos son: NEW, ESTABLISHED, RELATED e INVALID. La siguiente tabla explica brevemente cada posible estado:

Los anteriores estados pueden usarse conjuntamente con la comparación --state para diferenciar paquetes en función de su estado en el seguimiento de conexiones. Ésto es lo que hace que la máquina de estados sea tan increíblemente fuerte y eficiente para nuestro cortafuegos. En el pasado, frecuentemente nos veíamos obligados a abrir todos los puertos por encima del 1024 para permitir el tráfico de retorno a nuestra red local. Con la máquina de estados funcionando ya no es necesario, pues podemos abrir el cortafuegos sólo para el tráfico de retorno, no para todo tipo de tráfico.

Conexiones TCP

En esta sección y las siguientes vamos a repasar en profundidad los estados y cómo son gestionados para cada uno de los tres protocolos básicos: TCP, UDP e ICMP. Asimismo, veremos cómo se gestionan por defecto las conexiones si no se pueden incluir en ninguno de los anteriores protocolos. Empezaremos con el protocolo TCP, ya que es un protocolo de "flujos" en sí mismo (stateful protocol: como ya se ha explicado en la introducción, "stateful" implicaría que todos los paquetes de un mismo flujo son considerados como la misma cosa, como un todo que llega "en porciones"); además contiene muchos detalles interesantes respecto a la máquina de estados en iptables.

Una conexión TCP siempre se inicia con el "apretón de manos en tres pasos" (3-way handshake), que establece y negocia la conexión sobre la que se enviarán los datos. La sesión entera se inicia con un paquete SYN, seguido por un paquete SYN/ACK y finalmente por un paquete ACK, para confirmar el establecimiento de la sesión (1-"hola, ¿quieres hablar conmigo?", 2-"de acuerdo", 3-"bien, pues empecemos"). En este momento la conexión se establece y está preparada para empezar a enviar datos. El gran problema es: ¿cómo maneja el seguimiento de conexiones todo este tráfico? En realidad de una forma bastante simple.

Al menos en lo que concierne al usuario, el seguimiento de conexiones trabaja más o menos de la misma manera para todo tipo de conexiones. Échale un vistazo al gráfico de abajo para ver exactamente en qué estado entra el flujo durante las diferentes fases de la conexión. Como puedes observar, desde el punto de vista del usuario el código del seguimiento de conexiones realmente no acompaña al flujo de la conexión TCP. Una vez ha visto un paquete (el SYN), considera la conexión como nueva (NEW). En cuanto ve el paquete de retorno (SYN/ACK), considera la conexión como establecida (ESTABLISHED). Si piensas en éllo un momento, entenderás por qué: con esta particular forma de trabajar puedes permitir a los paquetes NEW y ESTABLISHED que abandonen tu red local, pero permitiendo únicamente a las conexiones ESTABLISHED que vuelvan a la red local y funcionen correctamente. Por el contrario, si la máquina de seguimiento de conexiones tuviera que considerar todo establecimiento de conexión como NEW, no seríamos capaces de detener los intentos de conexión desde el exterior hacia nuestra red local, puesto que tendríamos que permitir el retorno de todos los paquetes NEW. Para complicarlo todo un poco más, existen varios estados internos más dentro del núcleo que se usan para las conexiones TCP, pero que no están disponibles en el espacio de usuario. Básicamente siguen los estándares de estados especificados en RFC 793 - Protocolo de Control de Transmisiones, páginas 21-23 (en inglés). Los tendremos en cuenta un poco más adelante en esta misma sección.

Como puedes ver, desde el punto de vista del usuario es bastante simple. Sin embargo, desde el punto de vista del núcleo el esquema es un poco más complejo. Veamos un ejemplo que ilustra a la perfección cómo cambian los estados de la conexión en la tabla /proc/net/ip_conntrack. El primer estado es registrado a la recepción del primer paquete SYN de una conexión.

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1
   

Como puedes ver en la entrada anterior, tenemos un estado concreto en el cual un paquete SYN ha sido enviado (se establece la bandera SYN_SENT) y que todavía no ha recibido ninguna respuesta (de ahí la bandera [UNREPLIED]). El siguiente estado interno se alcanzará cuando se vea un paquete en la otra dirección.

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1
   

En este caso hemos recibido el correspondiente paquete SYN/ACK como respuesta. En cuanto llega, el estado cambia una vez más, esta vez a SYN_RECV: indica que el paquete SYN original llegó correctamente y que el paquete SYN/ACK de retorno también ha atravesado correctamente el cortafuegos. Además, esta entrada del seguimiento de conexiones ya ha visto tráfico en ambas direcciones y por éllo se considera que ha obtenido respuesta. Este hecho no es explícito, pero se considera asumido de la misma forma que ocurría con la bandera [UNREPLIED] anterior. El último paso se dará cuando veamos el paquete ACK final del "apretón de manos" (3-way handshake).

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 use=1
   

En este último ejemplo ya hemos visto el paquete ACK final y la conexión a entrado en el estado ESTABLISHED (establecida), al menos hasta donde llega el control de los mecanismos internos de iptables. Después de unos pocos paquetes más, la conexión se convertirá en [ASSURED] ("asegurada"), tal como se ha mostrado en la introducción del capítulo.

Cuando una conexión TCP se cierra, lo hace de la siguiente manera y tomando los siguientes estados:

Como puedes ver, en realidad la conexión nunca se cierra hasta que se envía el último paquete ACK. Ten en cuenta que este gráfico sólo muestra cómo se cierra una conexión en circunstancias normales. También puede cerrarse enviando un paquete RST ("reset", reiniciar) si la conexión se tiene que rechazar. En este caso la conexión será cerrada tras un periodo de tiempo predeterminado.

En condiciones normales, cuando una conexión TCP se cierra, entra en el estado TIME_WAIT ("tiempo de espera"), que por defecto es de 2 minutos. Este lapso de tiempo se emplea para que todos los paquetes que se han quedado "atascados" de alguna manera puedan atravesar igualmente el conjunto de reglas, incluso después de que la conexión se haya cerrado; de esta forma se dispone de una especie de "buffer"/colchón de tiempo para que los paquetes que se han quedado parados en algún enrutador congestionado, puedan llegar al cortafuegos o al otro extremo de la conexión sin problemas.

Si la conexión se reinicia por un paquete RST, el estado cambia a CLOSE ("cerrar"). Esta orden implica que la conexión por defecto dispone de 10 segundos antes de que se cierre definitivamente. Los paquetes RST no piden consentimiento de ninguna clase y cortan la conexión directamente.

También hay otros estados además de los que ya se han comentado. A continuación tienes la lista completa de los posibles estados que puede tomar un flujo TCP y sus tiempos límites.

Estos tiempos no son de ninguna manera definitivos, ya que pueden cambiar con las revisiones del núcleo, además de poderse cambiar a través del sistema de ficheros proc mediante las variables /proc/sys/net/ipv4/netfilter/ip_ct_tcp_*. Sin embargo, en la práctica los valores por defecto deberían estar bastante bien definidos. Los tiempos se indican en "jiffies" (centésimas de segundo), es decir, 3000 significa 30 segundos.

Ten en cuenta que la parte del espacio de usuario de la máquina de estados no se fija en las banderas TCP establecidas en los paquetes TCP. Hacer éso normalmente es una mala idea, ya que puedes querer permitir que los paquetes en el estado NEW puedan atravesar el cortafuegos, pero cuando especificas la bandera NEW lo que en la mayoría de las ocasiones quieres permitir son los paquetes SYN. En la implementación actual de los estados no ocurre ésto, ya que incluso un paquete sin ningún valor establecido o sin una bandera ACK, se considerará como NEW. Este tipo de comparación puede ser útil en sistemas con cortafuegos redundantes, pero en general es una malísima idea en tu red personal, dónde sólo tienes un cortafuegos. Para evitar este comportamiento puedes usar el comando explicado en la sección Paquetes cuyo estado es NEW pero cuyo bit SYN no se ha establecido del apéndice Problemas y preguntas frecuentes. Otra forma de conseguirlo es instalando la extensión tcp-window-tracking que encontrarás en el patch-o-matic, que permitirá que el cortafuegos sea capaz de hacer el seguimiento de los estados en función de las configuraciones de las ventanas TCP.

Conexiones UDP

Las conexiones UDP son en sí mismas "conexiones sin flujo". Existen varias razones para éllo, principalmente porque no implican ningún establecimiento o cierre de conexión; más que nada les falta algún tipo de secuenciamiento: recibir dos datagramas UDP en un orden específico no dice nada acerca del orden en que fueron enviados. Sin embargo es posible establecer estados en las conexiones dentro del núcleo. Veamos cómo se puede seguir una conexión y cómo podría verse en el conntrack.

Como puedes observar, desde el punto de vista del espacio de usuario la conexión se inicia casi exactamente de la misma forma que una conexión TCP. Internamente, sin embargo, la información del conntrack es bastante diferente, pero intrínsecamente los detalles son los mismos. Para empezar, veamos la entrada tras haber enviado el paquete UDP inicial.

udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
     [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1
   

Como puedes ver en los dos primeros valores, se trata de un paquete UDP. El primer valor es el nombre del protocolo, mientras que el segundo es el número del protocolo. Es lo mismo que se encuentra en las conexiones TCP. El tercer valor indica el "tiempo de vida" en segundos que le queda a esta entrada de estado. Tras ésto vienen los valores de origen y destino del paquete que hemos visto, la bandera [UNREPLIED], que nos indica que hasta el momento no ha habido respuesta al paquete, y por fin un listado de los valores que se esperan en los paquetes de respuesta. Estos últimos valores son los mismos que antes pero en sentido inverso. El tiempo de vida ("timeout") por defecto es de 30 segundos.

udp      17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
     dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1
   

En este ejemplo el servidor ya ha visto una respuesta al paquete inicial y la conexión se considera ESTABLISHED (establecida). Este detalle no se muestra en el seguimiento de conexiones, como puedes ver. La diferencia principal es la ausencia de la bandera [UNREPLIED]. Además el tiempo de vida por defecto a cambiado a 180 segundos: en el ejemplo ya han pasado 10 segundos y por eso el valor es 170; en diez segundos más el valor disminuirá a 160 y así hasta que se agote el tiempo. Sin embargo, hay un detalle que se ha visto antes y que ahora falta: la bandera [ASSURED]. Para que se establezca esta bandera en el seguimiento de conexiones, debe haber habido un mínimo de tráfico en la conexión.

udp      17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
     dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
     dport=1025 [ASSURED] use=1
   

En este momento la conexión ya está asegurada. Este ejemplo parece exactamente igual que el anterior, excepto por la bandera [ASSURED]. Si la conexión no es utilizada en 180 segundos, entonces caduca. Este tiempo (180 segundos) es un valor relativamente bajo, pero debería ser suficiente para la mayoría de los casos. Cada vez que un paquete coincide con los valores indicados en el paquete inicial (los valores que se esperan de los paquetes de respuesta ya comentados antes) y atraviesa el cortafuegos, el contador vuelve al valor por defecto, igual que ocurre con el resto de estados internos.

Conexiones ICMP

Los paquetes ICMP no pueden estar más lejos de ser conexiones de flujo (o "stateful connections"), ya que sólo se usan para el control de las conexiones y nunca deberían establecer ninguna conexión por sí mismos. Sin embargo, hay cuatro tipos ICMP que generarán paquetes de retorno y que presentan 2 estados diferentes: estos mensajes ICMP pueden tomar los estados NEW (nuevo) y ESTABLISHED (establecido). Los tipos ICMP de los que hablamos son: Echo request (petición de eco) y su reply (respuesta o Echo reply), Timestamp request (petición de "marca de tiempo", el valor del momento exacto en que se envía el paquete) y su reply, Information request (petición de información) y su reply, y por último Address mask request (petición de máscara de subred) y su reply. De éstos, los tipos timestamp request e information request están obsoletos y lo más probable es que simplemente se puedan desechar. Sin embargo, los mensajes de Echo se emplean en varias configuraciones, como hacer "pings" a los hosts. Las peticiones de máscara de subred (Address mask requests) no se suelen utilizar, pero pueden ser útiles en ocasiones y vale la pena permitirles que atraviesen el cortafuegos. Para tener una idea de cómo funciona una conexión de este tipo, veamos la siguiente imagen:

Como puedes observar, el host envía una petición de eco (echo request) al destinatario y el cortafuegos considera el paquete como nuevo (NEW). El destinatario responde con una respuesta de eco (echo reply) que el cortafuegos considera mediante el estado "establecido" (ESTABLISHED). Cuando ya se ha visto la primera petición de eco, se crea la siguiente entrada en el ip_conntrack.

icmp     1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
     id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
     type=0 code=0 id=33029 use=1
   

Como ya te habrás dado cuenta, esta entrada es un poco diferente a las entradas estándar para los paquetes TCP y UDP. Vemos el protocolo, su número, el tiempo de vida que le queda a la entrada, así como las direcciones de origen y destino. La diferencia viene después: tenemos 3 campos nuevos llamados type (tipo), code (código) e id (identidad/identificación). En realidad no son nada especiales: el valor type indica el tipo ICMP y el valor code indica el código ICMP. Todos éllos están disponibles en el apéndice Tipos ICMP. El valor de id indica el ICMP ID: cada paquete ICMP toma un valor ID (de identificación) cuando se envía y al responder el receptor también establece este mismo ID; de esta forma al llegar la respuesta al host que envió la petición se puede unir esa respuesta a la petición ICMP correcta.

En el siguiente campo volvemos a encontrar la bandera [UNREPLIED] que hemos visto anteriormente. Como entonces, la entrada del seguimiento de conexiones que estamos viendo implica que sólo se ha visto tráfico en una dirección. Por último vemos los datos que se esperan en el paquete de respuesta ICMP, que obviamente son los valores iniciales pero invertidos. Por lo que respecta al tipo y al código, se cambian por los valores adecuados al paquete de retorno, de forma que una petición de eco se transforma en una respuesta de eco, etc. El ICMP ID, lógicamente, se mantiene idéntico al paquete de petición.

El paquete de respuesta se considera como ESTABLISHED, tal como ya se ha explicado. Sin embargo, sabemos con seguridad que tras la respuesta ICMP no habrá absolutamente ningún tráfico legal en la misma conexión. Por esta razón la entrada del seguimiento de conexiones es destruida en cuanto la respuesta ha atravesado la estructura de Netfilter.

En cada uno de los casos anteriores la petición se considera como nueva (NEW), mientras que la respuesta se considera como establecida (ESTABLISHED). Más exactamente, cuando el cortafuegos ve un paquete de petición lo considera como nuevo, mientras que cuando el host envía un paquete de respuesta a la petición, se considera como establecido.

Ésto implica que el paquete de respuesta debe seguir el criterio fijado en la entrada del seguimiento de conexiones, para poder ser considerado como establecido, de la misma manera que ocurre en el resto de tipos de tráfico.

Las peticiones ICMP tienen un tiempo de vida por defecto de 30 segundos, que puedes cambiar en la entrada /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout. En general éste es un buen valor, ya que permitirá captar la mayoría de paquetes en tránsito.

Otra parte importantísima de ICMP es el hecho de que se emplea para indicarle a los hosts qué ha pasado con las conexiones UDP y TCP o con los intentos de conexión. Por este motivo las respuestas ICMP muy a menudo serán reconocidas como relacionadas (RELATED) con conexiones o intentos de conexión. Un ejemplo sencillo sería el de los mensajes ICMP Host unreachable (mensaje de host inalcanzable, no se puede llegar al host) e ICMP Network unreachable (mensaje de red inalcanzable, no se puede llegar hasta la red). Este tipo de mensajes se envían automáticamente de vuelta a nuestro host cuando el paquete no consigue efectuar la conexión con un host porque la red o el host de destino están fuera de servicio, de manera que el último enrutador (router) que intente conectar con el destino nos contestará con un mensaje ICMP diciéndonos lo que ocurre. En este caso la respuesta ICMP se considera como un paquete relacionado (RELATED). El siguiente gráfico debería aclarar lo que ocurre:

En el ejemplo enviamos un paquete SYN a una dirección concreta: ésto es considerado como una nueva conexión (NEW) por el cortafuegos. Sin embargo no se puede llegar a la red a la que se está intentando enviar el paquete, por lo que un router (el último) nos devuelve un error ICMP de red inalcanzable. El código de seguimiento de conexiones puede reconocer este paquete como relacionado (RELATED) gracias a la entrada ya existente, por lo que la respuesta ICMP es correctamente enviada al cliente que generó el paquete inicial y, si todo va bien, éste abortará la conexión. Mientras tanto el cortafuegos ya habrá eliminado la entrada del seguimiento de conexiones, puesto que sabe que se trata de un mensaje de error.

El mismo comportamiento se experimenta con las conexiones UDP si tienen problemas como en el caso anterior. Todo mensaje ICMP devuelto como respuesta a conexiones UDP es considerado como relacionado (RELATED). Observa el siguiente gráfico:

En esta ocasión se envía un paquete UDP al host. Esta conexión UDP se considera como nueva NEW. Sin embargo la red está prohibida administrativamente por algún cortafuegos o router antes de llegar a destino y por éllo nuestro cortafuegos recibe un mensaje ICMP Network Prohibited (red prohibida). El cortafuegos sabe que este mensaje ICMP de error está relacionado con la conexión UDP abierta y lo envía como un paquete RELATED (relacionado) al cliente. Acto seguido, elimina la entrada del seguimiento de conexiones mientras el cliente recibe el mensaje y aborta la conexión.

Conexiones por defecto

En algunos casos el conntrack no sabe cómo gestionar un protocolo específico, bien sea porque no conoce el protocolo o porque no sabe cómo funciona. En estos casos sigue un comportamiento por defecto, como ocurre por ejemplo con NETBLT, MUX y EGP. El procedimiento seguido es básicamente el mismo que en el seguimiento de las conexiones UDP: el primer paquete se considera como nuevo (NEW) y el tráfico de respuesta y subsiguiente es considerado como establecido (ESTABLISHED).

Cuando se emplea el comportamiento por defecto todos los paquetes afectados tendrán el mismo "tiempo de vida" (timeout) por defecto, que se puede establecer a través de la variable /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout. El valor por defecto es de 600 segundos (10 minutos). En función del tipo de tráfico que estés intentando enviar a través de un enlace que utilice este comportamiento por defecto, es posible que necesites cambiarlo, especialmente si estás conectado a través de satélite o algo similar, pues la comunicación puede llegar a tardar bastante tiempo.

Los protocolos complejos y el seguimiento de conexiones

Determinados protocolos son más complejos que otros, lo cual implica que a la hora de realizar el seguimiento de conexiones el trabajo será más difícil. Buenos ejemplos de éllo son los protocolos ICQ, IRC y FTP. Cada uno de éllos incluye información dentro del bloque de datos de los paquetes, por lo que para funcionar correctamente requieren de asistentes especiales para el seguimiento de conexiones.

Empecemos por ejemplo con el procolo FTP. Este protocolo comienza abriendo una única conexión llamada sesión "FTP control" (sesión de control ftp). En cuanto enviamos comandos a través de esta sesión, se abren otros puertos para transportar el resto de datos relacionados con esos comandos. Estas conexiones se pueden crear de dos maneras: activamente o pasivamente. Cuando una conexión se genera activamente, el cliente FTP envía al servidor un puerto y una dirección IP a los que conectarse. Tras ésto el cliente FTP abre el puerto indicado y el servidor conecta con él desde su propio puerto 20 (conocido como "FTP-Data"), enviando datos a través de él.

El problema radica en que el cortafuegos no tiene conocimiento de esas conexiones extras, ya que son negociadas a través del bloque de datos que transporta el paquete (lo que se conoce como "payload" o carga de información; recordemos que a grosso modo un paquete IP tiene una cabecera con información sobre la conexión y un bloque de datos que es lo que desea el host que lo recibe). Debido a ésto el cortafuegos no será capaz de saber que debería dejar conectarse al servidor con el cliente a través de estos puertos concretos.

La solución al problema pasa por añadir un asistente especial al módulo del seguimiento de conexiones, que escaneará los datos de la conexión de control para detectar sintaxis e información específicas: cuando encuentre la información adecuada, la añadirá en una nueva entrada etiquetada como relacionada (RELATED) y gracias a esta nueva entrada el servidor ya será capaz de efectuar un seguimiento de la conexión. Observa la siguiente imagen para entender los estados cuando el servidor FTP ya ha creado la conexión con el cliente.

El ftp pasivo ("Passive FTP") funciona completamente a la inversa: el cliente FTP le indica al servidor que quiere determinados datos, a lo que el servidor responde con una dirección IP y un puerto a los que conectarse. Tras recibir estos datos, el cliente se conectará a ese puerto desde su propio puerto 20 (el puerto FTP-data) y cogerá los datos en cuestión. Si tienes un servidor FTP tras tu cortafuegos, necesitarás de este módulo además de los módulos estándar de iptables para permitir que los clientes desde Internet puedan conectar correctamente con tu servidor FTP. De igual forma necesitarás el módulo si eres extremadamente restrictivo con tus usuarios y sólo quieres dejar que utilicen servidores HTTP y FTP de Internet, bloqueando cualquier otro puerto. Observa la siguiente imagen y su relación con el ftp pasivo ("Passive FTP").

Algunos asistentes del conntrack ya están disponibles en el núcleo, más concretamente, en el momento de escribir estas líneas los protocolos FTP e IRC ya disponen de estos asistentes. Si no puedes encontrar en el núcleo los asistentes que necesitas, debes echar un vistazo al patch-o-matic, en la sección de zona de usuario de iptables: podrás encontrar más asistentes del conntrack, como es el caso de los protocolos ntalk o H.323. Si no están disponibles en el patch-o-matic, todavía dispones de algunas opciones más, como el CVS ("Concurrent Versioning System") de iptables, si recientemente a entrado en él. O también puedes ponerte en contacto con la lista de correo Netfilter-devel y preguntar si está disponible. Si no lo está y no está planeado añadirlo, te quedas solo y lo más probable es que quieras leer el "CÓMO" de Rusty Russell: Rusty Russell's Unreliable Netfilter Hacking HOW-TO (en inglés), del cual tienes un enlace en el apéndice Otras fuentes y enlaces.

Los asistentes del conntrack pueden ser compilados estáticamente o como módulos en el núcleo. Si se compilan como módulos puedes cargarlos con el siguiente comando:

modprobe ip_conntrack_*
   

Ten en cuenta que el seguimiento de conexiones no tiene nada que ver con la traducción de direcciones (NAT), por lo que es posible que necesites más módulos si también estás "NATeando" (traduciendo) las conexiones. Por ejemplo, si quisieras traducir las direcciones y realizar un seguimiento de las conexiones FTP, necesitarías también el módulo NAT. Todos los asistentes NAT tienen el mismo prefijo en su nombre: "ip_nat_", seguido por el nombre del asistente en cuestión. Por ejemplo, el asistente para FTP con NAT (traducción de direcciones) se llamaría ip_nat_ftp y el módulo IRC se llamaría ip_nat_irc. Los asistentes del conntrack siguen la misma regla de nomenclatura, por lo que el asistente del conntrack para IRC se llamaría ip_conntrack_irc, mientras que el asistente para FTP sería ip_conntrack_ftp.

Considerando la velocidad

Una de las razones más convincentes para utilizar los comandos iptables-save e iptables-restore es que aceleran considerablemente la carga y la copia de los conjuntos de reglas más grandes. El principal problema al ejecutar un script en la línea de comandos que contenga reglas de iptables, es que cada vez que se invoca a iptables en el script se procede en primer lugar a extraer el conjunto de reglas completo del espacio del núcleo de Netfilter, para a continuación insertar, añadir o efectuar el cambio que sea necesario por el comando específico. Por último, devolverá el conjunto de reglas desde su propia memoria al espacio del núcleo. Utilizando un script, estas operaciones se ejecutan en cada una de las reglas que queramos insertar y consecuentemente cada vez cuesta más extraer e insertar el conjunto de reglas, pues cada vez hay más reglas en el conjunto.

Para resolver este problema se han creado los comandos iptables-save e iptables-restore. El primero (iptables-save) se usa para guardar el conjunto de reglas en un fichero de texto con un formato especial, mientras que iptables-restore carga ese fichero de texto de nuevo en el núcleo. Lo mejor de todo ésto es que cargan y guardan el conjunto de reglas mediante una sóla petición: iptables-save captará el conjunto de reglas completo del núcleo y lo guardará en un fichero en un sólo paso; iptables-restore cargará en el núcleo un conjunto de reglas específico en un paso por cada tabla. O sea, en vez de copiar el conjunto de reglas desde el núcleo, que en un ejemplo grande podría significar repetir el proceso 30.000 veces (si hubieran 30.000 reglas) y después volverlo a cargar en el núcleo otras tantas veces, podremos copiar desde el núcleo de una vez y volver a cargar en el núcleo en 3 pasos (suponiendo que hayan sólo 3 tablas).

Como puedes comprender, estas herramientas son exactamente lo que necesitas si estás trabajando con una gran cantidad de reglas y debes insertarlas en el conjunto de reglas. Sin embargo tienen sus inconvenientes, como discutiremos a continuación.

Inconvenientes con la restauración

Es posible que te estés preguntando si iptables-restore soporta de alguna manera los scripts. Y la respuesta es que de momento no, y lo más probable es que nunca lo haga. Este es el principal problema derivado del uso de iptables-restore, puesto que no podrás hacer una gran cantidad de tareas con estos ficheros. Por ejemplo: ¿qué ocurre cuando tienes una conexión a la que se le asigna dinamicamente su dirección IP y quieres captar esta dirección cada vez que el ordenador arranca para utilizarla en tus scripts? Con iptables-restore, ésto es prácticamente imposible.

Una posibilidad de conseguirlo es crear un pequeño script que primero capte los valores que quieres usar en las reglas, después busque ciertas claves en el fichero creado por iptables-save y las sustituya por los valores captados anteriormente. Una vez llegados a este punto, puedes salvar el fichero modificado en un fichero temporal y utilizar el comando iptables-restore para cargar los nuevos valores. Sin embargo ésta manera de proceder causa un montón de problemas y no podrás utilizar correctamente iptables-save, pues probablemente eliminará los valores añadidos manualmente (por el script). En definitiva es una solución, cuando menos, poco acertada.

Otra posible solución sería cargar los ficheros con iptables-restore y a continuación ejecutar un script que inserte reglas más dinámicas en los lugares adecuados. Por descontado, esta manera de proceder es tan poco acertada como la anterior. La cuestión de fondo es que iptables-restore no está adaptado para aquellas configuraciones dónde las direcciones IP se asignan al cortafuegos dinámicamente, o dónde deseas diferentes comportamientos dependiendo de los valores de determinadas opciones de configuración.

Otro inconveniente de iptables-restore e iptables-save es que de momento no son plenamente funcionales. El problema radica en los pocos usuarios que utilizan estos comandos y por tanto son pocos los que buscan fallos, de forma que es posible que algunas comparaciones y objetivos se inserten mal, y ésto lleve a comportamientos extraños o no esperados. A pesar de todo, aunque existen estos problemas, recomendaría encarecidamente utilizar estas herramientas, ya que deberían funcionar perfectamente bien para la mayoría de conjuntos de reglas, siempre que no contengan algunos de los nuevos objetivos o comparaciones que no sabe cómo manejar convenientemente. En un par de frases: si tus conjuntos de reglas no están absolutamente "a la última", estas herramientas funcionan como caídas del cielo.

iptables-save

El comando iptables-save es una herramienta para guardar el conjunto de reglas existente en iptables a un fichero que puede utilizar iptables-restore. Este comando es bastante fácil de usar y sólo tiene dos argumentos. Échale un vistazo al siguiente ejemplo para entender la sintaxis apropiada del comando.

iptables-save [-c] [-t tabla]

La opción -c le indica a iptables-save que guarde también los valores existentes en los contadores de bytes y de paquetes. Ésto puede ser útil si queremos reiniciar el cortafuegos sin perder los valores de estos contadores, que servirán, por ejemplo, para continuar con nuestras rutinas estadísticas sin problemas. Por supuesto el valor por defecto es no conservar los datos de los contadores.

La opción -t indica a iptables-save qué tablas guardar. Sin este argumento el comando guardará en el fichero todas las tablas disponibles. A continuación tienes un ejemplo de la salida que puedes esperar del comando iptables-save si no tienes ningún conjunto de reglas cargado (lógicamente la salida es en inglés).

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*filter
:INPUT ACCEPT [404:19766]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [530:43376]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*mangle
:PREROUTING ACCEPT [451:22060]
:INPUT ACCEPT [451:22060]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [594:47151]
:POSTROUTING ACCEPT [594:47151]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002

Como puedes ver los comentarios comienzan con el signo #. Cada tabla se marca así: *<nombre-tabla>, como por ejemplo *mangle. A continuación, dentro de cada tabla se encuentran las especificaciones de las cadenas y las reglas. Una especificación de cadena es similar a: :<nombre-cadena> <política-cadena> [<contador-paquetes>:<contador-bytes>]. El nombre de cadena puede ser, por ej., PREROUTING, la política ya se ha descrito antes y puede ser ACCEPT. Por otra parte, los contadores de paquetes y de bytes son los mismos que obtenemos con iptables -L -v. Por último, cada declaración de tabla finaliza con la clave COMMIT. Esta clave nos indica que en ese punto debemos enviar al núcleo todas las reglas que se han ido leyendo.

El ejemplo anterior es bastante básico y por éllo considero que es apropiado mostrar un breve ejemplo que contiene un pequeño Iptables-save. Si quisiéramos ejecutar iptables-save con éste conjunto de reglas cargado en el núcleo, la salida sería algo similar a (otra vez, en inglés):

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*filter
:INPUT DROP [1:229]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*mangle
:PREROUTING ACCEPT [658:32445]
:INPUT ACCEPT [658:32445]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [891:68234]
:POSTROUTING ACCEPT [891:68234]
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*nat
:PREROUTING ACCEPT [1:229]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
-A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1 
COMMIT
# Completed on Wed Apr 24 10:19:55 2002

Como puedes ver, a cada comando se le ha añadido como prefijo los contadores de bytes y paquetes, puesto que se ha empleado la opción -c en el comando. Excepto éste detalle, la línea de comandos es casi igual al script. El único problema ahora es cómo guardar la salida del comando en un fichero, aunque la solución es bastante simple y ya deberías conocerla si has trabajado con Linux antes: sólo se trata de dirigir la salida del comando hacia un fichero con el nombre que desees. Ésto puede parecerse a:

iptables-save -c > /etc/iptables-save

El comando anterior guardará el conjunto de reglas con los valores de sus contadores en un fichero llamado /etc/iptables-save.

iptables-restore

El comando iptables-restore se emplea para volver a cargar en el núcleo el conjunto de reglas guardado con iptables-save. Sin embargo, por ahora carga toda la información desde la entrada estándar y no desde un fichero. La sintaxis es:

iptables-restore [-c] [-n]

El argumento -c reestablece los contadores de bytes y paquetes y es la opción que debes usar cuando quieras volver a cargar los valores guardados con iptables-save de estos contadores. La opción también puede escribirse en su forma extendida: --counters.

El argumento -n le indica a iptables-restore que no sobreescriba las reglas existentes en la tabla o tablas en que esté escribiendo. El comportamiento por defecto de iptables-restore es eliminar cualquier regla preexistente. La opción en su "versión larga" sería: --noflush.

Para cargar conjuntos de reglas con el comando iptables-restore tenemos varias alternativas, aunque veremos la más simple y más utilizada.

cat /etc/iptables-save | iptables-restore -c

Simplificando: con éllo imprimiremos en la salida estándar (la pantalla) el contenido del conjunto de reglas existente en el fichero/etc/iptables-save y a continuación esa salida se dirigirá al comando iptables-restore, que captará el conjunto de reglas y lo cargará en el núcleo, incluyendo los valores de los contadores de bytes y paquetes. Ésta es la forma más sencilla de comenzar a usar el comando, aunque el ejemplo anterior se puede modificar hasta la saciedad, con diferentes posibilidades de redireccionamiento de la salida. Sin embargo, ésto se sale del objetivo de éste capítulo y prefiero dejar al lector que experimente por su cuenta.

El conjunto de reglas debería ahora estar cargado correctamente en el núcleo y todo debería funcionar. Si no es así, probablemente has cometido algún fallo al escribir los comandos, o habrás encontrado un "bug".

Conceptos Básicos

Como ya se ha dicho, cada regla es una línea que lee el núcleo para saber qué hacer con un paquete. Si todos los criterios (o comparaciones) se cumplen, entonces se ejecuta la instrucción objetivo (o salto). Normalmente deberías escribir tus reglas con una estructura similar a ésta:

iptables [-t tabla] comando [comparación (match)] [objetivo/salto (target/jump)]

En ningún sitio se especifica que la instrucción objetivo (el salto) deba ser la última función de la línea. Sin embargo, deberías seguir esta estructura para conseguir que sea lo más legible posible. De todas formas, la mayoría de las reglas que veas se han escrito de esta forma. Así pues, si lees un script de otra persona, lo más seguro es que reconozcas la estructura y entiendas fácilmente la regla.

Si quieres utilizar cualquier otra tabla que no sea la estándar, puedes especificarla en la parte que dice [tabla]. Sin embargo, no es necesario especificar qué tabla usar, puesto que por defecto iptables utiliza la tabla filter (filtro) para incluir todos los comandos. Tampoco es preciso que especifiques la tabla justo en ese punto de la regla. La verdad es que puede estar casi en cualquier parte de la línea. De todas formas, está más o menos aceptado que se especifique la tabla al principio.

Eso sí, debes tener en cuenta que el comando debería ser siempre lo primero, o a lo sumo justo detrás de la especificación de la tabla. Se emplea el "comando" para decirle al programa qué hacer, como por ejemplo insertar o añadir una regla al final de una cadena, o borrar una regla. Veremos ésto en detalle más adelante.

La comparación es la parte de la regla enviada al núcleo que especifica el carácter concreto del paquete, lo cual lo diferencia de todos los demás paquetes. Aquí es dónde se puede determinar de qué dirección IP viene el paquete, de qué interfaz de red, la IP destino, el puerto, el protocolo o cualquier cosa. Hay un montón de comparaciones diferentes que pueden emplearse y que se verán en detalle en este capítulo.

Por último tenemos el objetivo del paquete. Si todas las comparaciones se cumplen para un paquete, le decimos al núcleo qué hacer con él. Por ejemplo, podemos hacer que envíe el paquete a otra cadena que hayamos creado y que es parte de esta tabla. Podemos hacer que deseche el paquete y no haga nada más con él, o podemos enviar una respuesta específica al remitente. También estudiaremos los detalles en este capítulo.

Tablas

La opción -t especifica qué tabla utilizar. Por defecto se emplea la tabla filter, aunque se puede usar cualquiera de las siguientes tablas (ten en cuenta que este es un corto resumen del capítulo Atravesando tablas y cadenas):

Todo lo anterior debería haber aclarado los conceptos básicos sobre las tres tablas diferentes que hay disponibles. Deben usarse para propósitos completamente diferentes y además deberías saber cómo utilizar cada una de las cadenas existentes. Si no comprendes cómo se usan, es fácil que introduzcas un agujero en el cortafuegos que tarde o temprano descubrirá y explotará alguien. Ya se han discutido en profundidad las tablas y cadenas en Atravesando tablas y cadenas. Si no lo entiendes a la perfección, te recomiendo que vuelvas a leerlo hasta que lo comprendas totalmente.

Comandos

En esta sección trataremos los distintos comandos y qué se puede hacer con ellos. Un comando le indica a iptables qué hacer con el resto de la regla que enviamos al analizador. Normalmente desearemos añadir o eliminar algo en una tabla determinada. En iptables están disponibles los siguientes comandos:

Siempre deberías escribir una línea completa de comando, a no ser que sólo quieras ver la ayuda de iptables o conocer la versión del comando. Para mostrar la versión, emplea la opción -v y para la ayuda, usa la opción -h. Vamos, como siempre.

Ahora vamos a ver unas cuantas opciones que pueden usarse con varios comandos. Observarás que se indica con qué comandos se pueden emplear y qué resultados ofrecen. Ten en cuenta que no se incluye ninguna opción que afecte a reglas o comparaciones. Estas otras opciones se verán en profundidad más adelante.

Comparaciones ("matches")

En esta sección hablaremos sobre las comparaciones. He decidido agrupar las comparaciones en cinco categorías diferentes: para empezar tenemos las comparaciones genéricas, que pueden usarse en todas las reglas; a continuación vienen las comparaciones TCP que sólo pueden aplicarse a los paquetes TCP; después vienen las comparaciones UDP y las comparaciones ICMP, que sólo se aplican a paquetes UDP e ICMP respectivamente; por último queda un grupo de comparaciones especiales, como las de estado, las de propietario, comparaciones límite, etc. Este último grupo se ha clasificado en subcategorías, aunque en realidad no tienen por qué ser comparaciones diferentes. Espero que esta clasificación sea razonable y todo el mundo pueda entenderla.

---

Comparaciones explícitas

Las comparaciones explícitas son aquellas que se deben cargar específicamente con la opción -m o --match. Por ej., las comparaciones de estado exigen añadir la directiva -m state antes de introducir la comparación que deseas usar. Algunas de estas comparaciones pueden ser específicas de un protocolo. Otras pueden ser independientes de los protocolos, como las de los estados de conexión: NEW (NUEVO; el primer paquete de una conexión que todavía no está establecida), ESTABLISHED (ESTABLECIDO; una conexión que ya está registrada en el núcleo), RELATED (RELACIONADO; una nueva conexión que ha sido creada por otra conexión ya establecida y más antigua), etc. Existen unas cuantas, por otra parte, que pueden haber evolucionado con propósitos experimentales o de prueba, o simplemente para mostrar de qué es capaz iptables. Ésto significa que no todas estas comparaciones tienen una aplicación directa o "útil" a primera vista. Sin embargo es perfectamente posible que en tu caso concreto encuentres utilidad a alguna comparación específica. Además, cada vez hay más con cada nueva versión de iptables y que les encuentres utilidad dependerá en gran medida de tu imaginación y tus necesidades. La diferencia entre comparaciones cargadas implícita o explícitamente es que las implícitas se cargarán automáticamente cuando, por ej., compares las propiedades de los paquetes TCP, mientras que las explícitas nunca se cargarán automáticamente: es tarea enteramente tuya que descubras y actives las comparaciones explícitas.

---

Comparación Límite

La comparación limit (límite o limitación) debe ser cargada de forma explícita mediante la opción -m limit. Como ejemplo típico, esta comparación puede usarse para limitar el registro de actividad de reglas específicas. Ésto es, puedes comprobar que los paquetes no hayan excedido un determinado valor, a partir del cual se limita el registro de ese evento en cuestión. Imagina un límite de tiempo: puedes limitar las veces que una regla puede ser alcanzada en un periodo de tiempo dado, como cuando quieres minimizar los efectos de un "ataque de denegación de servicio por desbordamiento" (DoS). Éste es su principal uso, pero hay más, por supuesto. La comparación también puede ser invertida escribiendo el símbolo ! antes de la comparación límite: -m limit ! --limit 5/s, que quiere decir que todos los paquetes se compararán después de sobrepasar el límite de 5 veces por segundo.

Para ampliar la explicación, se puede decir que es básicamente como un "monedero virtual". Consideremos un monedero del que sacamos X monedas para gastar y al que introducimos monedas cada cierto tiempo. X se define dependiendo de cuántos paquetes recibimos que concuerdan con la comparación, por lo que suponiendo que son 3 paquetes, sacaremos del monedero 3 monedas en esa unidad de tiempo. La opción --limit nos dice con cuántos paquetes (monedas) rellenaremos el monedero por unidad de tiempo, mientras que --limit-burst indica la cantidad de monedas iniciales del monedero, así como cuántas de esas monedas admite el monedero. Así pues, escribiendo --limit 3/minute --limit-burst 5, crearemos un "monedero" con 5 "monedas"; si recibimos a continuación 5 paquetes seguidos que concuerden con la comparación, como resultado el "monedero" se vaciará. Tras 20 segundos, el "monedero" se rellena con otra "moneda" (recordemos que se rellena a razón de 3 por minuto) y a ese ritmo seguirá "rellenándose" hasta que se alcance el tope impuesto por el --limit-burst o hasta que sean usadas y el "monedero" vuelva a estar vacío.

Vamos a ver otro ejemplo algo más realista para aclarar mejor el funcionamiento:

1. Creamos una regla que contenga la siguiente comparación: -m limit --limit 5/second --limit-burst 10/second. El contador se establece con un valor inicial de 10. Cada paquete que coincida con el filtro de la regla resta una unidad al contador.

2. Recibimos una serie de paquetes (1-2-3-4-5-6-7-8-9-10) que coinciden con la regla, todos éllos en 1/1000 de segundo.

3. Ahora el contador está a cero ("vacío") y los paquetes que coincidan con la regla no serán filtrados por ésta y saltarán a la siguiente regla si existe, o en caso de no existir seguirán la política por defecto de la cadena.

4. Por cada 1/5 de segundo sin paquetes que coincidan, el contador aumenta una unidad hasta el valor máximo de 10. 1 segundo después de haber recibido los 10 paquetes anteriores, volveremos a aceptar hasta 5 paquetes seguidos.

5. Y por supuesto, el contador irá descontando 1 unidad por cada paquete correcto que se reciba.

Table 6-8. Opciones de comparación límite

Comparación	--limit
Ejemplo	iptables -A INPUT -m limit --limit 3/hour
Descripción	Mediante esta opción se establece el valor más alto del ratio medio de comparaciones positivas para la comparación limit. Se especifica mediante un valor numérico y un valor opcional de medida del tiempo. Las unidades de tiempo aceptadas actualmente son: /second (segundo), /minute (minuto), /hour (hora) y /day (día). El valor por defecto es de 3 cada hora, o lo que es lo mismo 3/hour. Así pues, con esta opción se consigue indicar a limit cuántas veces se le permite actuar a la comparación por unidad de tiempo (por cada minuto, por ej.).
Comparación	--limit-burst
Ejemplo	iptables -A INPUT -m limit --limit-burst 5
Descripción	Mediante esta opción le dices a iptables el número máximo de paquetes que concuerden con la comparación en un tiempo determinado. Este número (la cantidad de paquetes que han llegado a la comparación) disminuye en una unidad por cada unidad de tiempo (definida por la opción --limit) en que el evento no se presenta (no llega ningún paquete), hasta llegar al valor mínimo (1). Si se repite el evento (empiezan a llegar paquetes), el contador se va incrementando hasta que llega al tope establecido por --limit-burst, para volver a empezar (si no llegan paquetes el contador disminuye, mientras que cuando van llegando aumenta hasta el umbral definido por --limit-burst). El valor por defecto es 5. La manera más simple de comprobar cómo funciona esta opción es utilizando el ejemplo Limit-match.txt. Con él podrás comprobar por tí mismo cómo funciona simplemente enviando pings a diferentes intervalos de tiempo y con diferentes valores tope. Todas las respuestas de eco (echo replies) serán bloqueadas hasta que se vuelva a alcanzar el umbral límite.

---

Comparación MAC

La comparación MAC (Ethernet Media Access Control, o control de acceso a tarjetas Ethernet) se usa para comparar paquetes en función de su dirección MAC de origen [MAC source address; ésta es la dirección física de la tarjeta de red Ethernet: se trata de un código registrado en el hardware de la tarjeta que la hace única frente a todas las demás tarjetas fabricadas y por fabricar, es decir, no debería haber dos tarjetas Ethernet con la misma dirección MAC]. Por ahora esta comparación está un poco limitada, aunque en el futuro es posible que evolucione y sea más útil. Insistamos un poco: esta comparación SÓLO compara paquetes en función de su dirección MAC de ORIGEN.

Ten en cuenta que para usar este módulo lo cargamos explícitamente con la opción -m mac. Y digo ésto porque mucha gente se pregunta si la opción correcta no debería ser -m mac-source, pero no es el caso.

Table 6-9. Opciones de la comparación MAC

Comparación	--mac-source
Ejemplo	iptables -A INPUT -m mac --mac-source 00:00:00:00:00:01
Descripción	Como ya se ha dicho, esta comparación se emplea para buscar paquetes basándose en su dirección MAC de origen. La dirección MAC indicada debe tener el siguiente aspecto: XX:XX:XX:XX:XX:XX, pues de lo contrario no sería correcta (el programa la consideraría una dirección "ilegal"). La comparación también puede ser invertida con !, y se parecerá a --mac-source ! 00:00:00:00:00:01. En este ejemplo se aceptarán todos los paquetes excepto aquellos que provengan de la tarjeta Ethernet especificada (la que tenga la dirección MAC 00:00:00:00:00:01). Ten en cuenta que las direcciones MAC sólo se emplean en las redes de tipo Ethernet, por lo que sólo será viable emplear la comparación con tarjetas Ethernet. Además, sólo será válida en las cadenas PREROUTING, FORWARD e INPUT y en ninguna más.

---

Comparación Mark

Esta extensión se emplea para comparar paquetes basándose en las marcas que tengan establecidas. Una marca (mark) es un campo especial mantenido por el núcleo, que se asocia a los paquetes mientras viajan por el ordenador. Las marcas pueden usarse por diferentes rutinas del núcleo para tareas como la configuración y el filtrado del tráfico. Hoy por hoy sólo existe una manera de establecer una marca en Linux y ésta es mediante el objetivo MARK en iptables. Anteriormente se establecía con el objetivo FWMARK de ipchains y por éllo hay gente que todavía se refiere a FWMARK en tareas avanzadas de enrutado. El campo "marca" se establece mediante un número entero positivo de entre los 4.294.967.296 valores posibles en un entorno de 32 bits. O sea, que es más bien difícil que puedas verte limitado por este valor durante bastante tiempo.

Table 6-10. Opciones de la comparación de marca

Comparación	--mark
Ejemplo	iptables -t mangle -A INPUT -m mark --mark 1
Descripción	Empleamos la comparación para buscar paquetes que hayan sido marcados con anterioridad. Las marcas pueden establecerse gracias al objetivo MARK, que será tratado en la próxima sección. Todos los paquetes que atraviesan Netfilter reciben un campo de marca (mark field) especial y se asocian a él. Cabe destacar que este "mark field" no se propaga ni dentro ni fuera del paquete, sinó que permanece en el ordenador que lo creó. Si el campo marca coincide con la marca, entonces hay concordancia. El campo marca es un número entero positivo, por lo que pueden haber un máximo de 4.294.967.296 marcas diferentes (en entornos de 32 bits). También puedes utilizar una máscara en la marca, con lo cual su aspecto se podrá parecer a --mark 1/1. Si se especifica la máscara se efectuará una suma lógica (AND) con la marca especificada antes de ejecutar la comparación.

---

Comparación Multipuerto

La extensión multiport se emplea para especificar puertos múltiples y rangos de puertos múltiples. Si no tuviéramos la funcionalidad de esta comparación, necesitaríamos escribir múltiples reglas del mismo tipo simplemente para comparar diferentes puertos no contiguos (que no se pueden especificar mediante un rango).

No puedes emplear la comparación estándar de puertos junto a la comparación múltiple de puertos en la misma regla; por ej., no puedes escribir: --sport 1024:63353 -m multiport --dport 21,23,80, puesto que simplemente no funcionarán las dos a la vez, sinó que iptables ejecutará el primer elemento de la regla e ignorará el otro (en este caso ignorará la comparación multipuerto).

Table 6-11. Opciones de comparación multipuerto

Comparación	--source-port
Ejemplo	iptables -A INPUT -p tcp -m multiport --source-port 22,53,80,110
Descripción	Mediante esta comparación se buscarán los puertos de origen indicados, que serán como máximo 15. Los puertos se delimitarán mediante comas, como en el ejemplo. La comparación sólo se puede emplear conjuntamente con las comparaciones -p tcp o -p udp. Básicamente es una versión ampliada de la comparación estándar --source-port.
Comparación	--destination-port
Ejemplo	iptables -A INPUT -p tcp -m multiport --destination-port 22,53,80,110
Descripción	De la misma forma que la anterior, se comparan puertos múltiples, aunque esta vez son los puertos de destino de los paquetes. También presenta el límite de una lista con un máximo de 15 puertos y sólo puede utilizarse junto a -p tcp o -p udp.
Comparación	--port
Ejemplo	iptables -A INPUT -p tcp -m multiport --port 22,53,80,110
Descripción	Esta extensión puede emplearse para comparar paquetes basándose en su puerto de origen/destino. Funciona igual que las dos anteriores, con las mismas limitaciones, pero con la diferencia de que sólo se aceptarán paquetes que provengan y se destinen al mismo puerto; en el ejemplo estaríamos hablando de paquetes que provengan del puerto 22 y vayan al puerto 22, provengan del 53 y vayan al 53, etc.

---

Comparación Propietario (Owner)

La extensión owner se emplea para comparar paquetes en función de la identidad del proceso que los creó. Se puede especificar como la identificación (ID) del proceso del usuario que ejecutó la orden en cuestión; este usuario puede ser el grupo, el proceso, la sesión o el comando en sí mismo. Esta extensión se creó originalmente para demostrar de qué es capaz iptables. La comparación owner sólo funciona en la cadena OUTPUT por razones obvias: es prácticamente imposible encontrar alguna información sobre la identidad del proceso que envió el paquete desde el otro extremo y menos aún si existe algún punto intermedio entre el origen y el destino. Incluso en la cadena OUTPUT no tiene un comportamiento muy fiable, pues ciertos paquetes pueden no tener un propietario (como ocurre por ejemplo con las diferentes respuestas ICMP, ya que éstas nunca serán aceptadas por la comparación).

Table 6-12. Opciones de comparación de propietario

Comparación	--uid-owner
Ejemplo	iptables -A OUTPUT -m owner --uid-owner 500
Descripción	En esta comparación se aceptarán todos los paquetes que hayan sido generados por el usuario especificado (en inglés se habla de User ID o UID, siendo 500 la ID del ejemplo). Así pues, con esta regla podemos filtrar paquetes dependiendo del usuario que los haya creado. Una utilidad podría ser bloquear cualquier intento de abrir una conexión fuera del cortafuegos, siempre que el usuario no sea el administrador ("superuser", "su" o "root"). Otro posible uso sería bloquear a cualquier usuario que intente enviar paquetes por el puerto HTTP excepto al usuario http (con lo que minimizamos los ataques de troyanos que trabajen a través de ese puerto).
Comparación	--gid-owner
Ejemplo	iptables -A OUTPUT -m owner --gid-owner 0
Descripción	En este caso se compara el grupo al que pertenece el usuario que crea el paquete (en inglés, Group ID o GID). Con esta opción podemos bloquear a todos los usuarios que no pertenezcan al grupo network, de forma que sólo éstos últimos puedan acceder a Internet; o como ya se ha dicho antes, permitir sólo a los miembros del grupo http crear paquetes que salgan por el puerto HTTP.
Comparación	--pid-owner
Ejemplo	iptables -A OUTPUT -m owner --pid-owner 78
Descripción	En este caso se comparan los paquetes en función del número de proceso que lo generó (en inglés, Process ID o PID). Esta comparación es un poco más complicada de usar, pero un ejemplo podría ser al querer limitar el envío de paquetes por el puerto HTTP: suponiendo que el proceso número 78 (PID 78) sea el único que debe tener permiso, escribiendo la regla del ejemplo lo lograríamos, eso sí, siempre y cuando este proceso no esté dividido en varios procesos paralelos (threaded). Para facilitar las cosas, podemos escribir un pequeño script que capte el PID del demonio deseado desde la salida generada por el comando ps y cree una regla para ese PID. A modo de ejemplo tienes una regla en Pid-owner.txt.
Comparación	--sid-owner
Ejemplo	iptables -A OUTPUT -m owner --sid-owner 100
Descripción	Como en el resto del grupo, esta comparación busca paquetes basándose en la identificación de sesión empleada por el programa que genera los paquetes (en inglés, Session ID o SID). El valor del SID de un proceso es el del proceso mismo y todos los subprocesos creados a partir de él. Estos subprocesos pueden ser procesos paralelos (threads) o "hijos" del proceso original. A modo de ejemplo, en un equipo con el HTTPD dividido en procesos paralelos, todos estos procesos HTTPD "hijos" deberían tener el mismo SID que su proceso "padre" (el proceso HTTPD original); la mayoría de los demonios HTTPD funcionan de esta manera, como Apache y Roxen, por citar alguno. Para mostrártelo tienes a tu disposición un pequeño script llamado Sid-owner.txt. Con unos cuantos retoques este script podría ejecutarse cada hora de forma que compruebe si el HTTPD realmente está en marcha, arrancándolo si no es así y en ese caso modificando adecuadamente la cadena OUTPUT.

---

Comparación de Estado

La extensión state (estado) se emplea conjuntamente con el código de seguimiento de conexiones (connection tracking) del núcleo. La comparación de estado accede a la máquina de seguimiento de conexiones y averigua en qué estado se encuentra el paquete. Éste procedimiento funciona con prácticamente todos los protocolos, incluyendo aquellos que no poseen estado, como el ICMP y el UDP. En cualquier caso por defecto habrá un intervalo de espera para la conexión, a partir del cual será eliminada de la base de datos de seguimiento de conexiones. La comparación se debe cargar explícitamente añadiendo -m state a la regla, teniendo acceso a partir de entonces a una nueva comparación llamada "estado". El concepto de comparación de estado se trata en profundidad en el capítulo La máquina de estados, ya que es un tema bastante extenso.

Table 6-13. Comparaciones de Estado

Comparación	--state
Ejemplo	iptables -A INPUT -m state --state RELATED,ESTABLISHED
Descripción	Esta opción le indica a la comparación state (estado) qué paquetes deben ser comparados, en función de sus estados. Por ahora hay 4 estados que puedan ser utilizados: INVALID, ESTABLISHED, NEW y RELATED (inválido, establecido, nuevo y relacionado, respectivamente). INVALID implica que el paquete no está asociado a ningún flujo o conexión conocida y que puede contener datos o cabeceras erróneas. ESTABLISHED indica que el paquete pertenece a una conexión ya establecida, totalmente válida y que "ha visto" un flujo de paquetes en ambas direcciones. NEW significa que el paquete ha creado o está creando una nueva conexión, o que está asociado a una conexión que todavía no "ha visto" paquetes en ambas direcciones. Por último, RELATED es para paquetes que empiezan una nueva conexión pero están asociados a otra conexión ya establecida (como puede ocurrir en una transferencia de datos FTP, o en un error ICMP asociado a una conexión TCP o UDP). Ten en cuenta que el estado NEW ignora los bits SYN en los paquetes TCP que están intentando empezar una nueva conexión, por lo que no debe ser usado sin modificar en los casos en que exista sólo un cortafuegos y no haya balance de carga entre diferentes cortafuegos. Sin embargo, pueden haber circunstancias donde ésto sea útil. Para mayor información sobre cómo utilizarlo, lee el capítulo La máquina de estados.

---

Comparación TOS

La comparación TOS puede emplearse para comparar paquetes basándose en su campo TOS (TOS field). TOS es la abreviatura de Type Of Service (Tipo de Servicio), tiene un tamaño de 8 bits y se encuentra en las cabeceras IP. Esta comparación se carga explícitamente cuando añadimos -m tos a la regla. El Tipo de Servicio se suele usar para informar a los hosts intermedios por los que van pasando los paquetes de la llegada de un flujo y de su contenido (bueno, en realidad no hace eso, pero informa sobre cualquier requerimiento específico del flujo, como por ej. si tiene que reenviarse lo más rápidamente posible, o si necesita que se le permita contener tanta información como sea posible). De qué manera manejen los routers y administradores esa información depende exclusivamente de éllos. La mayoría la ignora, mientras que algunos intentan manejar los flujos y datos de la manera más acorde a la información del TOS.

Table 6-14. Comparaciones TOS

Comparación	--tos
Ejemplo	iptables -A INPUT -p tcp -m tos --tos 0x16
Descripción	Esta comparación se usa tal como se ha descrito y puede filtrar paquetes en función de su campo TOS y la información que contiene. Ésto es de utilidad, entre otras cosas, al trabajar conjuntamente con iproute2 y con funciones avanzadas de Linux, marcando paquetes para un uso posterior. La comparación reconoce como opción un valor hexadecimal o también numérico, aunque posiblemente también acepte uno de los nombres resultantes de ejecutar "iptables -m tos -h". En el momento de escribir el tutorial, se reconocen los siguientes nombres/valores/valores hexadecimales: Minimize-Delay 16 (0x10), Maximize-Throughput 8 (0x08), Maximize-Reliability 4 (0x04), Minimize-Cost 2 (0x02) y Normal-Service 0 (0x00). Minimize-Delay se refiere a minimizar el retardo en dar curso a los paquetes (ejemplos de servicios estándar que lo requieren son telnet, SSH y FTP-control). Maximize-Throughput implica un rendimiento tan grande como sea posible (un protocolo estándar podría ser FTP-data). Maximize-Reliability pide que se maximice la fiabilidad de una conexión y que se empleen líneas tan fiables como sea posible (por ej. para BOOTP y TFTP). Minimize-Cost pide que se minimice el coste de paquetes que atraviesan cada vínculo intermedio hasta el cliente o el servidor (por ej. encontrando la ruta que cueste menos de atravesar; algunos protocolos que podrían requerir ésto son RTSP (Real Time Stream Control Protocol) y otros protocolos de transporte de flujos de video/radio). Normal-Service, por último, podría servir para cualquier protocolo que no tenga necesidades especiales.

---

Comparación TTL

La comparación TTL se emplea para filtrar paquetes en función de su campo TTL (Time To Live, "tiempo de vida"), el cual se encuentra en las cabeceras IP. Este campo contiene 8 bits de datos y su valor va disminuyendo en una unidad cada vez que el paquete es procesado por un host intermedio entre el host origen y el destinatario. Si el valor TTL llega a ser 0, se transmite al remitente un mensaje informándole del problema. Este mensaje es un ICMP tipo 11 código 0 (el TTL ha tomado valor nulo durante el tránsito) o código 1 (el TTL ha tomado valor nulo durante el reensamblaje). Esta comparación únicamente efectúa un filtrado dependiendo del valor del TTL de los paquetes, pero sin cambiar nada. Para cargar esta comparación, necesitas añadir -m ttl a la regla.

Table 6-15. Comparaciones TTL

Comparación	--ttl
Ejemplo	iptables -A OUTPUT -m ttl --ttl 60
Descripción	Con esta opción se especifica el valor TTL a comparar. Este valor será de tipo numérico y se comparará con el valor presente en cada uno de los paquetes. No hay inversión posible y no hay otras opciones. A modo de ejemplo, se puede emplear para efectuar chequeos en busca de fallos (debug) en tu red local, como podrían ser hosts de la red local que parecen tener problemas para conectar con otros hosts situados en Internet; o también se puede emplear para encontrar posibles troyanos que se hayan introducido en tu red. Sin embargo su uso es relativamente limitado y su utilidad depende principalmente de tu imaginación. Por ejemplo, se pueden encontrar hosts con valores anormales de TTL (debidos posiblemente a una pila TCP/IP mal implementada, o a una simple mala configuración).

Objetivos/Saltos (Targets/Jumps)

Cuando la comparación de una regla encuentra un paquete que coincide con las condiciones que impone (tal como hemos visto hasta ahora), se recurre al objetivo/salto dónde se le indica a la regla qué debe hacer con ese paquete. Hay dos objetivos básicos que trataremos primero: ACCEPT y DROP, pero antes de empezar veamos brevemente cómo se efectúa un salto.

La orden de salto se ejecuta de la misma manera que la orden de objetivo, excepto en que el salto necesita que exista una cadena dentro de la misma tabla a la que pueda dirigirse. Para crear una cadena, tal como ya se ha explicado, se utiliza el comando -N. Por ejemplo, supongamos que queremos crear una cadena en la tabla "filter" llamada tcp_packets, por lo que escribiremos:

iptables -N tcp_packets
    

A partir de entonces podremos referirnos a esa cadena para efectuar un salto siempre que lo necesitemos:

iptables -A INPUT -p tcp -j tcp_packets
    

De esta forma todos los paquetes TCP saltarán desde la cadena INPUT hasta la cadena tcp_packets y serán filtrados por élla. Si algún paquete llega al final de la cadena y no ha habido una concordancia (el paquete no presenta coincidencias con las reglas de la cadena), volverá a la cadena original (en nuestro caso la cadena INPUT) justo después de la regla que originó el salto y seguirá pasando por el resto de reglas de esta cadena. Por el contrario, si alguna de las reglas de la cadena "tcp_packets" acepta (ACCEPT) los paquetes, éstos efectuarán el salto/objetivo de la regla y seguirán su curso por el resto de cadenas, sin pasar nunca por el resto de reglas de la cadena de origen (INPUT). Para mayor información de cómo los paquetes atraviesan las tablas y cadenas, léete el capítulo Atravesando tablas y cadenas.

Por otra parte, los objetivos especifican la acción a ejecutar con el paquete en cuestión. Así, se podrá aceptar (ACCEPT) o desechar (DROP) el paquete dependiendo de lo que queramos hacer. Existen además otra serie de acciones que podemos querer hacer con el paquete, y las describiremos más adelante. Debes tener en cuenta que saltar a un objetivo puede dar diferentes resultados, dependiendo del que se trate. Algunos objetivos harán que el paquete deje de atravesar una cadena específica y todas las superiores a élla, como se ha descrito antes (buenos ejemplos de éllo son DROP y ACCEPT): las reglas que son paradas no pasarán ninguna regla más, ni de esa misma cadena, ni de ninguna cadena "superior" a élla (superiores serán aquellas que han producido saltos hacia la cadena actual: la cadena A produce un salto a la cadena B y ésta última a la cadena C, donde el paquete se para en alguna regla y por tanto deja de atravesar la cadena C y sus superiores, la A y la B). Otros objetivos pueden efectuar alguna acción sobre el paquete, después del cual éste continuará pasando por el resto de reglas. Por ejemplo tenemos los objetivos LOG, ULOG y TOS: con éllos podemos registrar los paquetes, modificarlos y después pasárselos a otras reglas en el mismo conjunto de cadenas. Podemos querer hacer ésto para, por ejemplo, poder modificar tanto el valor del TTL como el del TOS de un paquete/flujo específico. Algunos objetivos aceptan opciones adicionales (qué valor TOS utilizar, ...), mientras otros no necesitan opciones obligatoriamente (aunque se puedan incluir si se desea, como ocurre con los prefijos de los registros, los puertos que se enmascararán, ...). Intentaremos incluir todos estos puntos tal como describamos los objetivos, así que empecemos a ver qué tipo de objetivos hay.

---

Objetivo DNAT

El objetivo DNAT se emplea para efectuar traducciones de direcciones de red de destino (Destination Network Address Translation), que significa que se emplea para reescribir la dirección IP de destino de un paquete. Con este objetivo en la regla, en cuanto un paquete coincide con la comparación, él y todos los paquetes pertenecientes a ese mismo flujo de datos verán modificada su dirección de destino y serán redirigidos a la red/host/dispositivo adecuado. Este objetivo puede ser extremadamente útil cuando, por ej., tienes un host ejecutando el servidor web dentro de una red local (LAN), pero sin una IP real que ofrecerle y que sea válida en Internet. Entonces puedes indicarle al cortafuegos que cuando lleguen paquetes dirigidos a su propio puerto HTTP los reenvíe hacia el servidor web real dentro de la red local. También se pueden especificar todo un rango de direcciones IP de destino y el mecanismo DNAT escogerá aleatoriamente la dirección IP de destino para cada flujo de datos. Mediante este sistema seremos capaces de abordar una especie de balance de carga.

Observa que el objetivo DNAT sólo está disponible en las cadenas PREROUTING y OUTPUT de la tabla nat, así como aquellas cadenas a las que las dos anteriores hayan dirigido un salto (es decir, cualquier cadena a la que se haya saltado desde una de las dos mencionadas). Insistimos en que las cadenas que contengan objetivos DNAT no pueden usarse desde otras cadenas, como podría ser el caso de la cadena POSTROUTING.

Table 6-16. Objetivo DNAT

Opción	--to-destination
Ejemplo	iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10
Descripción	La opción --to-destination le indica al mecanismo DNAT qué IP de Destino establecer en la cabecera IP y dónde enviar los paquetes que concuerden con el filtro. El ejemplo anterior enviará todos los paquetes destinados a la dirección IP 15.45.23.67 a un rango de direcciones LAN, en este caso el rango 192.168.1.1 a 192.168.1.10. Ten en cuenta que, tal como se ha dicho, un flujo concreto siempre usará el mismo host, mientras que a cada flujo se le asignará aleatoriamente una dirección IP a la que siempre serán destinados todos los paquetes de ese flujo. También se podría haber especificado una sola dirección IP, en cuyo caso siempre estaríamos conectados al mismo host. También podemos añadir un puerto o rango de puertos a los que será redirigido el tráfico. Para ello sólo tenemos que añadir el puerto o rango de puertos después de ":", como en --to-destination 192.168.1.1:80 para un puerto único, o como en --to-destination 192.168.1.1:80-100 para un rango de puertos. Como puedes ver, la sintaxis es la misma para los objetivos DNAT y SNAT, aunque es evidente que los resultados de uno y otro son totalmente diferentes. Por otra parte, las especificaciones de puertos sólo son válidas en aquellas reglas dónde se especifiquen los protocolos TCP o UDP en la opción --protocol.

Puesto que el objetivo DNAT exige bastante trabajo para funcionar correctamente, he decidido ampliar la explicación sobre cómo usarlo. Para empezar estudiaremos un pequeño ejemplo acerca de cómo deberían hacerse las cosas normalmente: queremos publicar nuestro sitio web aprovechando nuestra conexión a Internet, aunque sólo tenemos una dirección IP y el servidor HTTP se encuentra en nuestra red interna. El cortafuegos tiene la dirección IP externa $INET_IP, nuestro servidor HTTP tiene la dirección IP interna $HTTP_IP y por último el cortafuegos tiene la dirección IP interna $LAN_IP. Lo primero que hay que hacer es añadir la siguiente regla a la cadena PREROUTING de la tabla nat:

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT --to-destination $HTTP_IP
    

Desde ahora todos los paquetes que provengan de Internet y se dirijan al puerto 80 de nuestro cortafuegos, serán redirigidos a nuestro servidor HTTP interno. Si lo compruebas desde Internet, todo debería funcionar perfectamente. Pero, ¿qué ocurre cuando intentas conectar desde un host de la misma red local a la que pertenece el servidor HTTP?. Sencillo, simplemente no podrás. En realidad éste es un problema de enrutado: comenzaremos estudiando lo que ocurre en el caso normal. Para mantener la estructura del ejemplo, consideremos que la máquina externa tiene una dirección IP $EXT_BOX.

1. El paquete deja el host (con IP $EXT_BOX) que quiere conectar con la página web para dirigirse a $INET_IP.

2. El paquete llega al cortafuegos.

3. El cortafuegos efectúa la traducción DNAT en el paquete y lo envía a través del resto de cadenas.

4. El paquete deja el cortafuegos y viaja hacia $HTTP_IP.

5. El paquete llega al servidor HTTP y la máquina HTTP responde a través del cortafuegos (siempre que la base de datos de enrutado tenga definido el cortafuegos como el puente entre la red local y $EXT_BOX). En general éste será el puente por defecto del servidor HTTP.

6. El cortafuegos deshace la traducción que había hecho con DNAT sobre el paquete, de forma que parece que es el cortafuegos el que responde.

7. El paquete de respuesta viaja de vuelta al cliente $EXT_BOX.

Ahora consideremos qué ocurre si el paquete se origina en un cliente de la misma red a la que pertenece el servidor HTTP. El cliente tiene la dirección IP $LAN_BOX, mientras el resto de máquinas mantienen los mismos valores (nombres).

1. El paquete deja $LAN_BOX para dirigirse a $INET_IP.

2. El paquete llega al cortafuegos.

3. El paquete sufre la traducción DNAT y todas las acciones necesarias se toman en consecuencia, si bien al paquete no se le efectúa ninguna traducción SNAT y mantiene la misma dirección IP de origen.

4. El paquete sale del cortafuegos y alcanza el servidor HTTP.

5. El servidor HTTP intenta responder al paquete y observa en las bases de datos de enrutado que el paquete viene de una máquina local de la misma red, por lo que intenta enviar el paquete directamente a la dirección IP de origen (que a partir de ese momento se convierte en la dirección IP de destino).

6. El paquete llega al cliente, que no sabe qué hacer puesto que el paquete devuelto no proviene del host al que envió la petición original. Por éllo el cliente desecha el paquete y continúa esperando la respuesta "auténtica".

La solución más simple para este problema es efectuar la traducción SNAT a todos los paquetes que entren al cortafuegos y a los que sabemos que también se les va a aplicar la traducción DNAT. Por ej., consideremos la siguiente regla: vamos a efectuar una traducción SNAT a los paquetes que entren al cortafuegos y estén destinados a $HTTP_IP en el puerto 80, de forma que parecerá que provengan de $LAN_IP. Ésto forzará al servidor HTTP a devolver los paquetes a través del cortafuegos, que invertirá la traducción DNAT y los reenviará al cliente. La regla será algo así:

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \ --to-source $LAN_IP
    

Recuerda que la cadena POSTROUTING se procesa en último lugar, después del resto de cadenas, por lo que el paquete será "retraducido" cuando llegue a esa cadena específica. Por éllo comparamos los paquetes en función de su dirección interna.

Esta última regla afectará seriamente el registro de actividades, por lo que es altamente recomendable no emplear este método, si bien el ejemplo todavía es válido para aquellos que no pueden permitirse crear una "zona desmilitarizada" (DMZ) específica o algo parecido. Lo que ocurrirá es que el paquete llegará desde Internet, sus direcciones IP serán traducidas por SNAT y por DNAT, llegando por fin al servidor HTTP (por ejemplo). El servidor sólo verá una petición que viene del cortafuegos y, por tanto, registrará todas las peticiones de Internet como si vinieran del cortafuegos. También pueden haber consecuencias más serias. Piensa en un servidor SMTP de la red local: éste admite peticiones desde la red interna y tienes configurado el cortafuegos de forma que redirija el tráfico SMTP hacia el servidor. Lo que has creado en la práctica es un servidor SMTP "universal" [en inglés se llama "open relay SMTP server", es decir, un servidor de correo que acepta servir mensajes que no ha escrito ningún usuario local, ni van destinados a ningún usuario local], ¡con un registro de eventos horroroso! Así pues, será mejor que resuelvas estos problemas configurando un servidor DNS distinto y separado para tu red local, o creando una "zona desmilitarizada" (DeMilitarized Zone, DMZ) separada de la red interna. Esta última opción es la preferida, si es que tienes el dinero necesario para éllo.

¿Crees que ya está todo solucionado? Bueno, por ahora sí, salvo que consideres un último aspecto dentro de todo este cuadro. ¿Qué pasaría si el cortafuegos intenta acceder al servidor HTTP? ¿Dónde irá a parar? Como puede suponerse, intentará acceder a su propio servidor HTTP y no al servidor que hay en $HTTP_IP. Para corregir este problema necesitamos añadir una regla DNAT más a la cadena OUTPUT. Siguiendo con el ejemplo anterior, la regla podría quedar así:

iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \ --to-destination $HTTP_IP
    

Con esta última regla todo debería funcionar perfectamente: todas aquellas redes que no pertenezcan a la misma red del servidor HTTP funcionarán como la seda; todos los hosts de la misma red del servidor HTTP podrán conectar sin tropiezos; por último, el cortafuegos será capaz de efectuar conexiones por sí mismo. Todo funciona bien y no tiene por qué haber ningún tipo de problema.

Cabe destacar que estas reglas sólo controlan cómo se efectúan las traducciones DNAT y SNAT. Por éllo, quizá necesites otras reglas en la tabla "filter" (en la cadena FORWARD) para que los paquetes puedan atravesar el resto de cadenas. No olvides que todos los paquetes han pasado primero por la cadena PREROUTING y pueden haber cambiado sus direcciones de destino debido al DNAT de esta última cadena.

---

Objetivo LOG

El objetivo LOG se ha diseñado especialmente para registrar información detallada sobre los paquetes. Ésto podría considerarse ilegal, o simplemente como una forma de buscar defectos y fallos. Este objetivo ofrece información específica sobre los paquetes, como la mayoría de las cabeceras IP y otros datos considerados interesantes. Ésto se consigue a través del servicio de registro del núcleo, normalmente syslogd, y puede ser leída directamente con los registros de dmesg, o bien mediante otros programas. Es un objetivo excelente para depurar y afinar tus conjuntos de reglas, puesto que puedes ver qué paquetes van dónde y qué reglas se aplican en qué paquetes. También puede ser una gran idea usar el objetivo LOG en lugar del objetivo DROP mientras estás testeando una regla de la que no estás seguro al 100% en un cortafuegos en servicio que esté usando más gente, pues un error en el conjunto de reglas puede causar problemas severos de conectividad a todos los usuarios. Y si estás generando un registro realmente extenso, puede que encuentres interesante el objetivo ULOG, ya que puede escribir los registros directamente en bases de datos como las de MySQL.

Si obtienes registros de eventos directamente en pantalla y no es éso lo que quieres, no busques el problema en iptables o en Netfilter, sinó más bien en la configuración de tu syslogd (lo más probable es que el problema esté en el fichero /etc/syslog.conf). Para información sobre este tipo de problema, repásate la ayuda escribiendo en la línea de comando: man syslog.conf.

El objetivo LOG hoy por hoy tiene 5 opciones que pueden ser interesantes si necesitas información específica, o si quieres establecer diferentes opciones con valores específicos. Las explicamos a continuación.

Table 6-17. Opciones del objetivo LOG

Opción	--log-level
Ejemplo	iptables -A FORWARD -p tcp -j LOG --log-level debug
Descripción	Esta es la opción con la que le indicas a iptables y a syslog qué nivel de registro utilizar. Para ver una lista completa de niveles de registro, léete el manual de syslog.conf. Normalmente se presentan los siguientes niveles de registro (o prioridades, como normalmente se les suele llamar): debug, info, notice, warning, warn, err, error, crit, alert, emerg y panic. El nivel error es el mismo que err, warn es lo mismo que warning y panic es lo mismo que emerg. Sin embargo la primera opción de cada pareja se considera obsoleta y está condenada a desaparecer, por lo que no uses error, warn ni panic. La prioridad define la severidad del mensaje registrado. Todos los mensajes se registran a través del servicio ofrecido por el núcleo. O sea que escribiendo kern.=info /var/log/iptables en tu fichero syslog.conf y dejando a continuación que todos tus mensajes de LOG de iptables usen el nivel de información de registro (info), causará que todos los mensajes aparezcan en el fichero /var/log/iptables. Recuerda que también pueden haber otros mensajes de otras partes del núcleo que utilicen la prioridad de información. Si quieres conocer más detalles acerca del registro, te recomiendo que leas los manuales de syslog y syslog.conf, así como otros COMOs (HOWTOs) y ayudas publicadas en Internet.
Opción	--log-prefix
Ejemplo	iptables -A INPUT -p tcp -j LOG --log-prefix "INPUT packets"
Descripción	Esta opción le dice a iptables que añada un prefijo específico a todos los mensajes del registro, lo cual es útil al emplear aplicaciones como grep para efectuar un seguimiento de problemas específicos y de registros generados por diferentes reglas. El prefijo puede tener hasta 29 caracteres, incluyendo espacios en blanco y otros caracteres especiales.
Opción	--log-tcp-sequence
Ejemplo	iptables -A INPUT -p tcp -j LOG --log-tcp-sequence
Descripción	Esta opción añadirá los números de la Secuencia TCP (TCP Sequence) a cada mensaje registrado. El número de la Secuencia TCP es un número especial que identifica a cada paquete e indica dónde encaja dentro de una secuencia TCP, además de cómo debe ser reensamblado un flujo. Ten en cuenta que esta opción constituye un riesgo de seguridad si los registros pueden ser leídos por usuarios no autorizados o hasta por el resto del mundo. De la misma forma es un riesgo el acceso no autorizado a cualquier registro que contenga datos generados por iptables.
Opción	--log-tcp-options
Ejemplo	iptables -A FORWARD -p tcp -j LOG --log-tcp-options
Descripción	Esta opción registra las diferentes opciones presentes en las cabeceras de los paquetes TCP y puede ser útil cuando se intentan depurar los fallos o lo que pudiera llegar a ir mal. La opción no tiene ninguna variable ni nada parecido, como le ocurre a la mayoría de opciones de LOG.
Opción	--log-ip-options
Ejemplo	iptables -A FORWARD -p tcp -j LOG --log-ip-options
Descripción	Con la opción --log-ip-options registraremos la mayoría de opciones presentes en las cabeceras de los paquetes IP. Trabaja exactamente igual que la opción --log-tcp-options, salvo porque trabaja sobre las opciones IP. Ésto puede ser útil al tratar de depurar o perseguir determinados delincuentes, además de para corregir errores (de la misma forma que la anterior opción).

---

Objetivo TOS

El objetivo TOS se emplea para establecer el campo Tipo de Servicio (Type of Service) de la cabecera IP. Este campo tiene un tamaño de 8 bits y se usa para ayudar a direccionar (enrutar) los paquetes. Éste es uno de los campos que pueden usarse directamente en iproute2 y su subsistema de políticas de enrutado. Vale la pena destacar que si controlas varios cortafuegos y enrutadores separados, ésta es la única manera de difundir información de encaminamiento (enrutado) junto a los paquetes que circulan entre esos enrutadores y cortafuegos. Como ya se ha comentado, el objetivo MARK (que establece una "MARKa" asociada a un paquete específico) sólo está disponible dentro del núcleo y no se puede enviar junto con el paquete. Si necesitas enviar información de enrutado con un paquete o flujo específicos, debes recurrir al campo TOS, pues se diseñó para éso.

En la actualidad hay muchos enrutadores en Internet que trabajan muy mal con este tema, por lo que puede ser bastante inútil intentar modificar el campo TOS antes de enviar los paquetes a Internet. Como mucho los enrutadores no prestarán atención al campo TOS. En el peor de los casos, lo leerán y harán alguna cosa incorrecta. Sin embargo, tal como se ha dicho antes, el campo TOS puede ser muy útil si tienes una WAN (Red de Área Extensa) o una LAN (Red de Área Local) de dimensiones respetables y con múltiples enrutadores. De hecho tienes la posibilidad de darle a los paquetes diferentes encaminamientos y preferencias, basándote en el valor de su TOS (aunque ésto sólo puedas tenerlo bajo control en tu propia red).

El objetivo TOS sólo es capaz de establecer valores o nombres específicos a los paquetes. Estos valores predefinidos se pueden encontrar en los archivos del "kernel include" (ficheros de código fuente del núcleo), o más exactamente en el archivo Linux/ip.h. Las razones son muchas y de hecho no deberías necesitar ningún otro valor; sin embargo, hay formas de superar esta limitación: para evitar la limitación de sólo poder establecer valores nominales (con nombres) a los paquetes, puedes usar el parche FTOS disponible en Paksecured Linux Kernel patches, web mantenida por Matthew G. Marsh; sin embargo, ¡sé extremadamente cauteloso con este parche!, pues nunca deberías tener la necesidad de utilizar ningún valor aparte de los valores por defecto, a excepción de casos extremos.

Ten en cuenta que este objetivo sólo es válido dentro de la tabla mangle y no puede usarse fuera de élla.

También es importante que entiendas que algunas viejas versiones de iptables (1.2.2 o anteriores) proporcionan una implementación incompleta de este objetivo y no corrigen la suma de comprobación (checksum) del paquete a la hora de modificarlo, por lo que generan mal los paquetes y como resultado necesitan una retransmisión. Ésto lo más probable es que obligue a una nueva modificación y con éllo que el ciclo vuelva a empezar, dando como resultado que la conexión nunca funcione.

El objetivo TOS sólo tiene la opción que explico a continuación.

Table 6-23. Objetivo TOS

Opción	--set-tos
Ejemplo	iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10
Descripción	Esta opción le dice al procedimiento de modificación TOS qué valor establecer en los paquetes que coincidan con el filtro. Este valor es numérico (hexadecimal o decimal). Como el valor TOS tiene 8 bits, el número estará comprendido entre 0 y 255 (en hexadecimal entre 0x00 y 0xFF). Recuerda que en el objetivo TOS estándar estás limitado a los valores nominales (con nombre) disponibles, que deberían estar más o menos estandarizados. Estos valores estándar son: Minimize-Delay [minimizar el retardo] (valor decimal/dec 16, valor hexadecimal/hex 0x10), Maximize-Throughput [maximizar el rendimiento] (valor dec 8, valor hex 0x08), Maximize-Reliability [maximizar la fiabilidad] (valor dec 4, valor hex 0x04), Minimize-Cost [minimizar el coste] (valor dec 2, valor hex 0x02) ó Normal-Service [servicio normal] (valor dec 0, valor hex 0x00). El valor por defecto en la mayoría de paquetes es Normal-Service, ó 0. Además, obviamente puedes utilizar los nombres en lugar de los valores hexadecimales (y viceversa) para establecer el valor TOS; sin embargo, normalmente se recomienda utilizar el nombre, pues los valores asociados con los nombres pueden cambiar en el futuro. Para ver una lista completa de los "valores descriptivos", ejecuta en la línea de comandos: iptables -j TOS -h. Esta lista se considera completa en la versión 1.2.5 de iptables y debería seguir así por un tiempo.

---

Objetivo TTL

Este objetivo necesita del parche TTL del patch-o-matic, en el directorio raíz, en http://www.netfilter.org/documentation/index.html#FAQ - Las Frequently Asked Questions (Preguntas Frecuentes) oficiales de Netfilter. Éste es también un buen lugar de comienzo cuando empiezas a preguntarte qué hacen iptables y Netfilter..

El objetivo TTL se usa para modificar el campo Time To Live de la cabecera IP. Una aplicación útil para ésto puede ser cambiar todos los valores Time To Live al mismo valor en todos los paquetes dirigidos al exterior de la red. Una razón para necesitar ésto es que tengas un ISP abusivo que no te permita tener más de una máquina conectada a la misma conexión de Internet, y que lo persiga activamente. Estableciendo todos los valores TTL al mismo valor le harás un poco más difícil (al ISP) darse cuenta de lo que estás haciendo. Así pues, podemos establecer el valor TTL de todos los paquetes de salida a un valor estandarizado, como 64, que es el valor estándar del núcleo de Linux.

Para más información sobre cómo establecer el valor por defecto usado por Linux, léete el ip-sysctl.txt, que puedes encontrar en el apéndice Otras fuentes y enlaces.

El objetivo TTL sólo es válido en la tabla mangle y en ninguna tabla más. De momento tiene 3 opciones que describo a continuación.

Table 6-24. Objetivo TTL

Opción	--ttl-set
Ejemplo	iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64
Descripción	La opción --ttl-set le dice al objetivo TTL qué valor TTL establecer en el paquete. Un valor de referencia bastante correcto podría estar alrededor de 64, un valor ni muy alto ni muy bajo. Lo que no debes hacer es establecer un valor demasiado alto, pues puede afectar a tu red local y además resulta un poco inmoral, puesto que el paquete puede empezar a rebotar entre dos enrutadores mal configurados y cuanto más alto sea el TTL, más ancho de banda consumirá innecesariamente en un caso así. Este objetivo puede emplearse para limitar lo alejados que pueden estar nuestros clientes, como por ej. en el caso de los servidores DNS, dónde no queremos que los clientes estén muy lejos.
Opción	--ttl-dec
Ejemplo	iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-dec 1
Descripción	La opción --ttl-dec hace que se decremente el tiempo de vida del paquete una cantidad equivalente al valor indicado tras la opción (en el ejemplo, el decremento indicado es de uno). Así pues, si el TTL de un paquete entrante es de 53 y hemos establecido un decremento --ttl-dec 3, el paquete verá reducido su TTL hasta el valor 49. La razón de esta diferencia estriba en que el código de gestión de redes reducirá automáticamente el TTL en un punto, por lo que el paquete sufrirá un decremento de 3+1, desde 53 hasta 49. Mediante este sistema podemos limitar lo alejados que pueden estar los usuarios de nuestros servicios. Por ejemplo, los usuarios siempre deben usar un DNS cercano, y en consecuencia podemos comparar todos los paquetes que dejen nuestro servidor DNS y reducir el TTL en varias unidades. Por supuesto, la opción --set-ttl es más adecuada para este uso.
Opción	--ttl-inc
Ejemplo	iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1
Descripción	La opción --ttl-inc es la opuesta a la anterior, es decir, se incrementa el TTL en una cantidad expresada a continuación de la opción. Ten en cuenta que en este caso el código de gestión de redes también actúa automáticamente reduciendo el TTL en 1, por lo que si escribimos --ttl-inc 4, un paquete entrante con un TTL de 53 dejará el host con un valor TTL de 56, ésto es, 53+4-1. Con esta opción podemos hacer nuestro cortafuegos un poco más invisible a los trazadores de rutas (traceroutes), entre otras cosas: al establecer el valor TTL de los paquetes entrantes a un valor más alto, conseguimos que el cortafuegos se oculte a los trazadores. Los trazadores de rutas son utilidades amadas y odiadas al mismo tiempo, puesto que facilitan información excelente sobre problemas con las conexiones y dónde ocurren, si bien al mismo tiempo le ofrecen al hacker/cracker que te haya localizado muy buena información sobre tus conexiones con el exterior. Para ver un buen ejemplo de cómo puedes usarlo, mira el script Ttl-inc.txt.

Ejemplo de rc.firewall

De acuerdo, ya tienes todo listo y estás preparado para revisar un ejemplo de script de configuración. O al menos deberías estarlo si has llegado hasta aquí. El ejemplo rc.firewall.txt (también incluído en el apéndice Código fuente de los scripts de ejemplo) es bastante largo pero sin demasiados comentarios. En vez de buscar los comentarios, te recomiendo que leas el script entero para tener una idea general y luego vuelvas a estas líneas para obtener todos los detalles prácticos.

Explicación del rc.firewall

---

Carga inicial de módulos extra

Para empezar, vemos que se comprueba si los archivos de dependencias de módulos están actualizados ejecutando el comando /sbin/depmod -a. A continuación se cargan los módulos que se requerirán en el script. Evita siempre cargar módulos que no vayas a necesitar y si es posible trata de evitar tener módulos sólo "por si acaso" a no ser que los vayas a usar. La razón de ésto es por seguridad, ya que de otra manera supondrá un esfuerzo extra escribir reglas adicionales. Así, si por ejemplo quieres tener soporte para los objetivos LOG, REJECT y MASQUERADE y no los tienes compilados estáticamente en el núcleo, deberás cargar los módulos como sigue:

/sbin/insmod ipt_LOG
/sbin/insmod ipt_REJECT
/sbin/insmod ipt_MASQUERADE
    

En éste y los demás scripts de ejemplo forzamos la carga de módulos, lo cual puede originar fallos durante el proceso de carga. Estos fallos pueden deberse a muchos factores y generarán mensajes de error. Si alguno de los módulos más básicos no se cargan, el error más probable es que el módulo o funcionalidad esté compilado estáticamente en el núcleo. Para más información al respecto, léete la sección Problemas en la carga de módulos del apéndice Problemas y preguntas frecuentes.

Seguimos con los módulos no requeridos y encontramos la opción de cargar el módulo ipt_owner, que entre otras cosas se puede utilizar para permitir únicamente a determinados usuarios la posibilidad de establecer determinadas conexiones. Este módulo no se utiliza en el presente ejemplo, pero básicamente podrías permitir sólo al usuario root establecer conexiones FTP y HTTP con "redhat.com" y DROP (denegárselo/desechar) a todos los demás. También puedes denegar el acceso desde tu máquina hacia Internet a todos los usuarios excepto a tu propio usuario (tú mismo) y a root, lo cual puede no gustar a los demás, pero estarás un poco más seguro ante los ataques tipo "bouncing" (de forma que parezca que la conexión la realiza tu host) y ante los ataques en que el hacker sólo utilizará tu host como máquina intermedia. Para mayor información sobre la comparación ipt_owner léete la sección Comparación Propietario (Owner) del capítulo Cómo se escribe una regla.

En este momento también podemos cargar módulos extra para la comparación de estados. Todos los módulos que mejoran el comportamiento del código de comparación de estados y de seguimiento de las conexiones se llaman ip_conntrack_* e ip_nat_*. Los asistentes para el seguimiento de las conexiones son módulos especiales que le indican al núcleo cómo hacer un seguimiento adecuado de conexiones de un tipo específico. Sin estos asistentes, el núcleo no sabrá qué buscar al intentar hacer un seguimiento de esas conexiones específicas. Por otra parte, los asistentes NAT son a su vez extensiones de los anteriores asistentes y le indican al núcleo qué buscar en paquetes específicos, además de cómo interpretarlos para que las conexiones funcionen. Por ejemplo, FTP es un protocolo complejo por definición, que envía la información de conexión dentro del contenido del paquete. Así pues, si una de tus máquinas "NATeadas" conecta con un servidor FTP de Internet, enviará su propia dirección IP de la red local dentro del paquete y le indicará al servidor FTP que realice la conexión con esa dirección. Puesto que las direcciones locales no son válidas fuera de tu propia red local, el servidor FTP no sabrá qué hacer con éllas y la conexión se perderá. Los asistentes FTP NAT efectúan las conversiones necesarias en estas conexiones, de manera que el servidor FTP sabrá con quién debe establecer la conexión. El mismo caso ocurre con las transferencias (envíos) DCC de archivos y los chats. La creación de este tipo de conexiones precisa la dirección IP y los puertos con los que conectar a través del protocolo IRC, lo cual exige ciertas "traducciones". Sin estos asistentes determinadas tareas con FTP e IRC se podrán llevar a cabo, qué duda cabe, pero habrá otras que no. Por ejemplo, serás capaz de recibir ficheros mediante DCC, pero no podrás enviarlos. Éllo es debido a la manera de establecer conexiones de DCC. Al iniciar una conexión, le indicas al receptor que quieres enviarle un fichero y dónde debe conectarse. Sin los asistentes para la conexión DCC, este aviso inicial parecerá indicarle al receptor que debe conectarse a algún host de su propia red local (la del receptor). Como resultado la conexión se perderá. Sin embargo, cuando seas tú el que descargue ficheros no habrá problemas puesto que lo más probable es que el que te diga dónde debes conectar, te envíe la dirección correcta.

Si estás experimentando problemas con los mIRC DCCs y tu cortafuegos, mientras que todo funciona perfectamente con otros clientes IRC, léete la sección Problemas con mIRC DCC del apéndice Problemas y preguntas frecuentes.

En el momento de escribir estas líneas, sólo existe la opción de cargar módulos que añadan soporte para los protocolos FTP e IRC. Si necesitas una explicación más profunda sobre estos módulos (conntrack y nat), lee el apéndice Problemas y preguntas frecuentes. También se pueden encontrar asistentes para seguimiento de conexiones (conntrack) de tipo H.323 (entre otros) en el patch-o-matic, así como otros asistentes para NAT. Para poder utilizarlos tienes que utilizar el patch-o-matic y compilar tu propio núcleo. Para ver una explicación detallada de cómo hacer ésto, léete el capítulo Preparativos.

Ten en cuenta que necesitas cargar los módulos ip_nat_irc e ip_nat_ftp si quieres que funcione correctamente la traducción de direcciones (Network Addres Translation) tanto en el protocolo FTP como en el IRC. Además, tendrás que cargar los módulos ip_conntrack_irc e ip_conntrack_ftp antes de cargar los módulos NAT anteriores. Se emplean de la misma forma que los módulos conntrack y permitirán al ordenador efectuar traducciones NAT en estos dos protocolos.

---

Configuración de /proc

Es ahora cuando arrancamos el reenvío IP (IP forwarding) al enviar el valor "1" a /proc/sys/net/ipv4/ip_forward con el comando siguiente:

echo "1" > /proc/sys/net/ipv4/ip_forward

Puede valer la pena pensar dónde y cuándo arrancamos el reenvío IP. En este script, como en el resto de este tutorial, se arranca antes de crear cualquier tipo de filtros IP (o sea, los conjuntos de reglas de iptables). Esto implica que durante un breve lapso de tiempo el cortafuegos aceptará el reenvío de cualquier tipo de tráfico desde cualquier lugar, estando este lapso comprendido entre un milisegundo y algunos minutos, dependiendo del script que estemos ejecutando y de la velocidad de la máquina. Así pues, la "gente interesada" (los "chicos malos") tendrá su oportunidad de atravesar el cortafuegos. Como podrás comprender en realidad esta opción debería ejecutarse después de crear todas las reglas del cortafuegos, si bien he decidido hacerlo antes para mantener una estructura consistente en todos los scripts.

Si necesitaras soporte para IPs dinámicas, como cuando usas SLIP, PPP o DHCP, puedes activar la siguiente opción (ip_dynaddr) ejecutando lo siguiente:

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Si existe cualquier otra opción que necesites arrancar, debes hacerlo de la forma indicada en los dos ejemplos anteriores. Existen otros documentos que explican cómo hacerlo de otra manera, aunque ésto queda fuera de los objetivos del tutorial. Puedes leer un buen (y corto) documento sobre el sistema proc disponible con el núcleo y que también tienes en el apéndice Otras fuentes y enlaces. Este apéndice es un buen punto de partida cuando busques información de áreas específicas que no hayas encontrado aquí.

El script rc.firewall.txt, así como el resto de scripts de este tutorial, contiene una pequeña sección de configuraciones no requeridas de proc, las cuales pueden ser un buen punto de partida cuando algo no funciona tal como deseas. Sin embargo, no cambies nada antes de saber qué significa.

---

Estableciendo las políticas por defecto

Casi al comenzar el proceso de creación de nuestro conjunto de reglas, establecemos las políticas por defecto en las diferentes cadenas con un comando bastante simple, como puedes ver a continuación:

iptables [-P {cadena} {política}]

La política por defecto se utiliza siempre que los paquetes no coincidan con ninguna regla de ninguna cadena. Por ejemplo, supongamos que llega un paquete que no encaja en ninguna regla de todas las que tenemos en nuestro conjunto de reglas. Si ésto ocurre debemos decidir qué debe pasarle al paquete en cuestión y es aquí donde entra en escena la política por defecto.

Se cuidadoso con la política por defecto que estableces en las cadenas de otras tablas, pues no están pensadas para filtrar como la tabla FILTER y pueden desembocar en comportamientos realmente extraños.

---

Definiendo cadenas de usario en la tabla Filter

Ahora ya tienes una buena idea de qué queremos conseguir con el cortafuegos, así que empecemos con la creación del conjunto de reglas. Es el momento de cuidarnos de especificar todas las reglas y cadenas que deseamos crear y utilizar, así como todos los conjuntos de reglas en las cadenas.

Después de esta introducción, empezaremos por crear las diferentes cadenas especiales que necesitamos, mediante el comando -N. Las nuevas cadenas se crean vacías, sin ninguna regla en éllas, y tal como ya se ha dicho son: icmp_packets, tcp_packets, udp_packets y la cadena allowed, que es utilizada por la cadena tcp_packets. Los paquetes entrantes por $INET_IFACE, de tipo ICMP, serán redirigidos a la cadena icmp_packets. Los paquetes de tipo TCP, serán redirigidos a la cadena tcp_packets y los paquetes de tipo UDP a la cadena udp_packets. Todo ésto se explica en profundidad más adelante, en la sección La cadena INPUT. Crear una cadena es bastante sencillo, pues sólo consiste en una corta declaración similar a:

iptables [-N cadena]

En las secciones siguientes desarrollaremos ampliamente cada una de las cadenas que acabamos de crear. Veremos cómo son y qué reglas contendrán, así como qué conseguiremos con éllas.

---

La cadena "bad_tcp_packets"

La cadena bad_tcp_packets se ha concebido para contener reglas que inspeccionen los paquetes entrantes e identifiquen cabeceras malformadas, entre otros problemas. Así pues, decidimos incluir únicamente dos filtros: el primero bloquea todos los paquetes TCP entrantes que sean considerados como nuevos (NEW), pero no tengan establecido el bit SYN; el segundo bloquea los paquetes SYN/ACK que se consideren nuevos (NEW). Esta cadena se puede utilizar para comprobar posibles inconsistencias como las anteriores, o también como los chequeos de puertos XMAS, etc. También podemos añadir reglas que busquen el estado INVALID.

Si deseas entender a fondo el "NEW not SYN", deberías leerte la sección Paquetes cuyo estado es NEW pero cuyo bit SYN no se ha establecido del apéndice Problemas y preguntas frecuentes, acerca del estado "NEW and non-SYN" de los paquetes que atraviesan otras reglas. Bajo determinadas circunstancias a estos paquetes se les puede permitir atravesar el cortafuegos, aunque en el 99% de los casos no querremos que pasen, por lo que registramos su llegada en los registros (logs) y los desechamos (DROP).

El motivo para rechazar(REJECT) los paquetes SYN/ACK que se consideran nuevos es muy simple. Se describe en profundidad en la sección Paquetes SYN/ACK y NEW del apéndice Problemas y preguntas frecuentes. Básicamente, hacemos ésto como cortesía hacia otros hosts, ya que les prevendrá de ataques de predicción de secuencia numérica (sequence number prediction attack).

---

La cadena "allowed"

Si un paquete que llega a la interfaz $INET_IFACE es del tipo TCP, viajará por la cadena tcp_packets, y si la conexión es a través de un puerto en el que permitimos el tráfico, desearemos hacer algunos chequeos finales para ver si realmente le permitiremos el paso al paquete o no. Todo estos chequeos finales se realizan en la cadena allowed (permitido).

Empezamos comprobando si estamos ante un paquete SYN. Si es así, lo más probable es que sea el primer paquete de una nueva conexión, por lo que, obviamente, le permitimos el paso. Entonces comprobamos si el paquete procede de una conexión establecida (ESTABLISHED) o relacionada (RELATED). Si lo es, de nuevo permitimos el paso. Una conexión ESTABLISHED es aquélla que ha "visto" tráfico en ambas direcciones y puesto que nos hemos encontrado con un paquete SYN, la conexión debe estar en el estado ESTABLISHED, de acuerdo con la máquina de estados. La última regla de esta cadena desechará (DROP) todo lo demás. Ésto viene a englobar todo aquéllo que no ha "visto" tráfico en ambas direcciones, es decir, o no hemos respondido al paquete SYN, o están intentando empezar una conexión mediante un paquete "no-SYN". No existe ninguna utilidad práctica en comenzar una conexión sin un paquete SYN, a excepción de la gente que está haciendo escaneo de puertos. Hasta dónde yo sé, no hay actualmente ninguna implementación de TCP/IP que soporte la apertura de una conexión TCP con algo diferente a un paquete SYN, por lo que casi con total certeza se tratará de un escaneo de puertos y es recomendable desechar (DROP) estos intentos de conexión.

---

La cadena "tcp_packets"

La cadena tcp_packets especifica qué puertos se podrán alcanzar desde Internet a través del cortafuegos. Sin embargo, hay más chequeos para estos paquetes, ya que los enviamos a la cadena "allowed", descrita anteriormente.

La opción -A tcp_packets le indica a iptables en qué cadena debe añadir la nueva regla, la cuál se incluirá al final de la lista de reglas de esa cadena. La opción -p TCP especifica el primer requisito a cumplir por el paquete, es decir, debe ser un paquete TCP; de la misma forma, -s 0/0 busca (compara) las direcciones de origen, empezando por la 0.0.0.0 con máscara de red 0.0.0.0, es decir todas las direcciones de origen. Aunque éste es el comportamiento por defecto, lo indico para que todo quede lo más claro posible (en este caso todos los puertos de origen cumplirán el requisito exigido por la regla). La opción --dport 21 indica el puerto de destino 21, o sea que si el paquete está destinado al puerto 21, cumplirá el último criterio de selección de la regla. Si todos los criterios coinciden, el paquete será enviado a la cadena allowed. Si no coincide con alguna de las opciones, será devuelto a la cadena original (la que generó el salto a la cadena tcp_packets).

Tal como queda el ejemplo, permito el puerto TCP 21, o sea, el puerto de control FTP, empleado para controlar las conexiones FTP. Ésto unido a que más alante se permiten todas las conexiones relacionadas (RELATED), permitirá las conexiones ftp PASIVAS y ACTIVAS, pues en principio el módulo ip_conntrack_ftp ya se habrá cargado. Si no queremos permitir ningún tipo de conexión FTP, podemos descargar (o no cargar) el módulo ip_conntrack_ftp y borrar (o no añadir) la línea $IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j allowed del fichero rc.firewall.txt.

El puerto 22 es el SSH y emplear este puerto cuando dejas a cualquiera acceder a tu máquina mediante shell, es definitivamente mucho mejor que permitir el acceso mediante telnet por el puerto 23. Ten en cuenta que estás trabajando con un cortafuegos y siempre es una mala idea permitir a alguien más que tú mismo cualquier tipo de acceso a la máquina del cortafuegos. Los usuarios con acceso al cortafuegos siempre deben limitarse al mínimo imprescindible y ninguno más.

El puerto 80 es el de HTTP, o sea, tu servidor web. Borra esta línea si no quieres ejecutar un servidor web directamente en tu cortafuegos.

Y, por último, se permite el puerto 113, que es el IDENTD y puede ser necesario para algunos protocolos como IRC, para trabajar correctamente. Ten en cuenta que puede ser interesante utilizar las librerías oidentd si quieres efectuar traducciones NAT de varios hosts en tu red local. oidentd admite peticiones de retransmisión de IDENTD a las máquinas correctas de tu red local.

Si necesitas añadir más puertos abiertos en el script, parece bastante obvio cómo deberías hacerlo: simplemente copia y pega una de las líneas de la cadena tcp_packets y cambia el puerto que necesitas abrir.

---

La cadena "udp_packets"

Si se nos presenta un paquete UDP en la cadena INPUT, lo enviamos a la cadena udp_packets, dónde comenzaremos las comprobaciones empezando por el protocolo con -p UDP y después comprobaremos que proviene de cualquier dirección comenzando por la 0.0.0.0 y con máscara de red 0.0.0.0, o sea, que de nuevo cualquier dirección de origen es válida. Sin embargo sólo aceptamos puertos UDP específicos que queramos mantener abiertos para hosts de Internet. Puedes observar que no necesitamos abrir agujeros dependiendo del puerto de origen del host que envía el paquete, ya que de éllo se debería ocupar la máquina de estados. Sólo necesitamos abrir puertos en nuestro host si vamos a ejecutar un servidor en algún puerto UDP, como el servidor DNS, etc. Los paquetes que lleguen al cortafuegos y sean parte de una conexión ya establecida (por nuestra red local), serán aceptados automáticamente por las reglas --state ESTABLISHED,RELATED del principio de la cadena INPUT.

Tal como está el ejemplo, NO aceptamos (ACCEPT) paquetes UDP entrantes por el puerto 53, pues es el puerto usual cuando se efectúan búsquedas DNS. Observa que la regla está ahí, pero por defecto está comentada (#) y por éllo no se aceptan paquetes destinados al puerto 53. Si deseas que tu cortafuegos actúe como servidor DNS, elimina el símbolo de comentario (para permitir el tráfico por ése puerto).

Personalmente también permito el acceso por el puerto 123, que es el empleado por NTP (o Network Time Protocol). Este protocolo se emplea para ajustar la hora del reloj de tu ordenador de acuerdo a la hora de ciertos "servidores de horas" (time servers) que poseen relojes muy precisos. La mayoría de la gente probablemente no utiliza este protocolo y por éllo por defecto no está permitido el acceso a este puerto. Al igual que antes, sólo tienes que eliminar el símbolo de comentario para activar la regla.

En el ejemplo autorizamos el uso del puerto 2074, empleado por ciertas aplicaciones multimedia en tiempo real, como speak freely, con la que puedes hablar con otra gente en tiempo real (lógicamente a través de Internet), mediante unos altavoces y un micrófono o bien unos auriculares con micro. Si no deseas utilizar este servicio, simplemente comenta la línea (#).

El puerto 4000 es el del protocolo ICQ. Debería ser un protocolo conocidísimo, usado por la aplicación de Mirabilis denominada ICQ. Hay al menos 2 ó 3 clones diferentes de ICQ para Linux y es uno de los programas de chat más ampliamente difundido. Dudo que se necesiten más explicaciones.

Una vez en este punto, tienes disponibles dos reglas más para cuando experimentes un número excesivo de entradas en el registro debidas a distintas circunstancias. La primera regla bloqueará los paquetes de difusión (broadcast packets) hacia el rango de puertos entre el 135 y el 139. Este tipo de paquetes los emplean NetBIOS o SMB para gran parte de los usuarios de las plataformas de Microsoft. Con éllo bloquearemos todas las entradas de registro que pudiéramos tener a causa de Redes Microsoft desde el exterior de nuestra red local. La segunda regla también se ha creado para evitar los problemas de un excesivo número de entradas en el registro, pero en este caso se encarga de las peticiones DHCP que provienen del exterior. Ésto es especialmente cierto si tu red exterior se basa en una red de tipo "Ethernet no conmutado", donde los clientes reciben sus direcciones IP a través de DHCP. En estas circunstancias y debido únicamente a éllo, puedes verte barrido por una gran cantidad de registros.

Ten en cuenta que las dos últimas reglas son especialmente opcionales, puesto que habrá quien tenga interés en conservar este tipo de registros. Si estás teniendo problemas por un excesivo número de entradas legítimas en el registro, prueba a eliminar las originadas por estas clases de paquetes. También hay algunas reglas más del mismo tipo justo antes de las reglas de registro en la cadena INPUT.

---

La cadena "icmp_packets"

Aquí es donde decidimos qué tipos ICMP permitiremos. Si un paquete ICMP llega a través de la interfaz eth0 hasta la cadena INPUT, lo enviamos a la cadena icmp_packets tal como ya se ha explicado en los casos anteriores. Es entonces cuando comprobamos a qué tipo ICMP pertenece y si le permitimos el paso o no. Por el momento, sólo permito el paso a las peticiones de eco ICMP (Echo requests), al "tiempo de vida del paquete nulo durante el tránsito" (TTL equals 0 during transit) y al "tiempo de vida nulo durante el reensamblado" (TTL equals 0 during reassembly). La razón para no permitir el paso a ningún otro tipo ICMP como opción por defecto es que prácticamente todos éllos deben ser gestionados por las reglas para el estado "paquete relacinado" (RELATED).

Si un paquete ICMP es enviado como respuesta a un paquete existente o a un flujo de paquetes, se considera como relacionado (RELATED) con el flujo original. Para más información sobre los estados, léete el capítulo La máquina de estados.

A continuación explicaré las razones por las que permito estos tipo de paquetes ICMP: las peticiones de eco se utilizan para pedir una respuesta de eco de la máquina destino, lo cual sirve principalmente para hacer "pings" a otros hosts y ver si están disponibles en alguna red. Sin esta regla los demás hosts no serán capaces de hacer ping sobre nuestra máquina y no podrán saber si estamos disponibles en alguna conexión de red. Hay que destacar sin embargo que hay quien elimina esta regla, simplemente porque no desean ser "vistos" (ser detectables) en Internet. Borrando esta regla consigues que cualquier ping que llegue a tu cortafuegos sea inútil, ya que el cortafuegos no le contestará.

En cuanto al "tiempo excedido" (TTL equals 0 during transit o bien TTL equals 0 during reassembly), nos convendrá que los paquetes ICMP de este tipo tengan permiso para atravesar el cortafuegos siempre que deseemos conocer la ruta hasta un host (o sea, efectuar un trace-route), o también en los casos en los que un paquete que hayamos enviado a alcanzado el estado "Time To Live=0" y deseemos recibir notificación del evento.

Por ejemplo, cuando efectúas un trace-route a alguien, empiezas enviando un paquete con TTL = 1, lo cual implica que en el primer salto entre hosts (en el primer "hop") el TTL se reduce en una unidad y se iguala a 0, de forma que se envía de vuelta un paquete ICMP de tipo Time Exceeded desde el primer punto de la ruta de acceso que lleva al host que tratamos de localizar. Entonces se envía otro paquete, pero esta vez con TTL = 2 y en el segundo "hop" la pasarela (gateway) devolverá un ICMP Time Exceeded, con lo que ya se conocen los dos primeros puntos de la ruta. Continuando de manera análoga se llegará hasta el host que deseamos alcanzar, con lo que conoceremos la ruta completa y podremos saber qué host intermedio tiene problemas.

Para ver un listado completo de los tipos ICMP, léete el apéndice Tipos ICMP. Para más información acerca de los tipos ICMP y su utilización, te recomiendo leer los siguietes documentos e informes:

• Protocolo de Mensajes de Control de Internet por Ralph Walden.

• RFC 792 - Protocolo de Mensajes de Control de Internet por J. Postel.

Debo advertir que desde tu punto de vista puedo estar equivocado al bloquear algunos de los tipos ICMP, pero en mi caso todo funciona perfectamente después de bloquear todos los tipos ICMP a los que no permito el paso.

---

La cadena PREROUTING de la tabla nat

La cadena PREROUTING es básicamente lo que indica su nombre: realiza la traducción de direcciones de red en los paquetes, antes de que lleguen a la decisión de asignación de ruta que les enviará a las cadenas INPUT o FORWARD de la tabla filter. La única razón por la que nos referimos a esta cadena en el script es que nos sentimos obligados a repetir que NO DEBES efectuar ningún tipo de filtrado en élla. La cadena PREROUTING sólo es atravesada por el primer paquete de un flujo, lo cual significa que todos los demás paquetes del flujo serán totalmente ignorados por esta cadena. Tal como está definido este script, no utilizamos en absoluto la cadena PREROUTING, si bien es el lugar donde deberíamos trabajar si quisiéramos hacer alguna traducción DNAT en paquetes específicos: por ejemplo si quisieras albergar tu servidor web dentro de tu red local. Para más información acerca de la cadena PREROUTING, léete el capítulo Atravesando tablas y cadenas.

La cadena PREROUTING no debe usarse para ningún tipo de filtrado puesto que, entre otras causas, esta cadena sólo es atravesada por el primer paquete de un flujo. La cadena PREROUTING debe usarse únicamente para efectuar traducciones de direcciones de red, a no ser que sepas realmente lo que estás haciendo.

Estructura del script rc.firewall.txt

Todos los scripts de este tutorial se han escrito basados en una estructura específica. La razón es que deben estar bastante parejos y ser fácilmente diferenciables entre ellos. Dicha estructura debería estar suficientemente documentada en este breve capítulo, dónde se intenta proporcionar una pequeña explicación de por qué se han escrito todos los scripts de la manera en que se ha hecho y por qué se ha escogido esa estructura.

A pesar de que ésta es la estructura elegida, ten presente que quizá no es la estructura que más te conviene para tus scripts. Es simplemente la estructura que yo he escogido, ya que se ajusta a la necesidad de que sea fácil de leer y de seguir, de acuerdo con mi lógica.

---

La estructura

Esta es la estructura que todos los scripts de este tutorial deberían seguir. Si difieren en algo será probablemente un error por mi parte, a no ser que se diga específicamente el por qué se ha abandonado la estructura.

1. Configuración - En primer lugar nos encontramos con las opciones de configuración que todos los scripts deben usar. Las opciones de configuración deben ser casi siempre lo primero en cualquier script en línea de comandos (shell-script).

   1. Internet - Este es el apartado de configuración referente a la conexión a Internet. Puedes saltarte este apartado si no tienes ninguna conexión a Internet. Ten en cuenta que podría haber más subsecciones que las listadas aquí, pero sólo aquéllas referentes a nuestra conexión a Internet.

      1. DHCP - Si se requieren opciones específicas para DHCP en el script, las configuraremos aquí.

      2. PPPoE - Si existe la posibilidad de que el usuario quiera usar este script en concreto y por cualquier motivo resulta que está usando una conexión PPPoE, añadiremos las opciones específicas aquí.

   2. LAN - Si hay una LAN habilitada detrás del cortafuegos (firewall), añadiremos las opciones pertinentes en esta sección. Ésto será lo más probable, de aquí que esta sección esté casi siempre habilitada.

   3. DMZ - Si hay alguna razón para éllo, añadiremos las opciones de configuración de una DMZ ("Zona Desmilitarizada") en este punto. La mayor parte de los scripts carecen de esta sección, principalmente porque ninguna red casera normal o pequeña red de empresa tendrá DMZs.

   4. Localhost - Estas opciones pertenecen a nuestro host local. Es muy improbable que estos valores cambien, pero los hemos puesto como variables de todas formas. En principio no debería haber motivos para hacer cambios en estas variables.

   5. iptables - Esta sección contiene la configuración específica de iptables. En la mayoría de scripts y situaciones, sólo se requiere una variable que indique dónde está ubicado el archivo binario (ejecutable) "iptables".

   6. Otras - Si existe cualquier otra opción o variable concreta debe ser incluida, antes que en cualquier otro sitio, en su subsección (si pertenecen a la conexión a Internet, deben colocarse en dicha subsección, etc). Si no van en ninguna, entonces deben colocarse directamente en algún lugar entre las opciones de configuración.

2. Carga de módulos - Esta sección del script debe albergar una lista de módulos. La primera parte debe contener los módulos requeridos (necesarios), mientras que la segunda contendrá los no requeridos.

   Ten en cuenta que algunos modulos que permiten aumentar la seguridad o añadir determinados servicios o posibilidades, se pueden haber añadido aunque no estén estrictamente requeridos. Cuando así suceda, normalmente se mencionará expresamente en los scripts de ejemplo.

   1. Modulos requeridos - Esta sección debería contener los módulos requeridos y, posiblemente, los módulos que mejoren la seguridad o añadan servicios especiales al administrador o a los clientes.

   2. Modulos No requeridos - Esta sección contendrá los módulos que no son requeridos para operaciones normales. Todos estos modulos aparecen por defecto como si fueran comentarios, por lo que si quieres añadir el servicio que proporcionan, deberás eliminar el símbolo de comentario (#).

3. Configuración proc - Esta sección tratará cualquier configuración especial que necesite el "sistema de ficheros proc" (éste es un sistema virtual creado bajo demanda que permite interactuar con el núcleo y los procesos que se ejecutan en él). Si algunas opciones son requeridas, serán listadas como tales, pero si no es así se escribirán por defecto como comentarios y se listarán bajo las configuraciones no-requeridas de proc. La mayoría de las configuraciones proc útiles serán listadas aquí, pero ni mucho menos se incluirán todas.

   1. Configuración proc requerida - Esta sección debe contener todas las configuraciones proc requeridas por el script en cuestión. También podría contener posiblemente configuraciones que aumenten la seguridad o que pueden añadir servicios o posibilidades especiales para el administrador o los clientes.

   2. Configuración proc no-requerida - Esta sección debe contener las configuraciones proc no-requeridas que podrían resultar utiles. Todas ellas se escriben como si fueran comentarios porque no son necesarias para que el script trabaje. Esta lista está lejos de contener todas las configuraciones de proc.

4. Escritura de las reglas - Después de todo lo anterior, el script ya debe estar listo para que se inserte el conjunto de reglas. He decidido clasificar todas las reglas tras la tabla y los nombres de las cadenas. Todas las cadenas específicas de usuario se crean antes de que hagamos nada en las cadenas por defecto del sistema. También he decidido organizar las cadenas y sus reglas específicas en el mismo orden en que son mostradas con el comando iptables -L.

   1. Tabla Filter - Antes que nada vamos directos a la tabla filter y a su contenido. En primer lugar debemos configurar las políticas de la tabla.

      1. Configuración de las políticas - empezamos por configurar todas las políticas por defecto para las cadenas del sistema. Normalmente pondré la política DROP por defecto en las cadenas de la tabla filter y específicamente usaré la política ACCEPT para los servicios y flujos que yo quiera permitir. De esta manera podremos evitar que la gente use puertos que no queremos que estén disponibles.

      2. Creación de las cadenas específicas del usuario - en este punto creamos todas las cadenas propias que queremos usar más tarde en esta tabla. No podremos referirnos a estas cadenas en las del sistema si no están ya creadas, por lo que debemos llegar a éllas lo antes posible.

      3. Crear los contenidos de las cadenas creadas por el usuario - después de crear las cadenas específicas de usuario, podemos escribir todas las reglas que llevarán esas cadenas. La única razón que tengo para escribir estos datos en este punto es por tener las cadenas propias y sus reglas lo más juntas posible. Sin embargo puedes ponerlas más adelante en el script, es decisión tuya.

      4. Cadena INPUT - llegados aquí ya no nos quedan muchas más cosas que hacer en la tabla filter, así que nos adentramos en la cadena INPUT. Ahora es cuando debemos añadir todas las reglas a la cadena INPUT.

         Es en este momento cuando empezamos a seguir la salida del comando iptables -L, como podrás combrobar. No hay razón para que continúes con esta estructura, pero no obstante, trata de evitar mezclar datos de diferentes tablas y cadenas, ya que puede hacerse muy duro leer y comprender el conjunto de reglas, así como encontrar la solución a posibles problemas.

      5. Cadena FORWARD - vamos a añadir las reglas a la cadena FORWARD. Ningún comentario acerca de esta decisión.

      6. Cadena OUTPUT - lo último que queda por hacer en la tabla filter es añadir las reglas que van en la cadena OUTPUT. En principio no debería haber mucho por hacer en esta cadena.

   2. Tabla nat - después de la tabla anterior, centramos nuestra atención en la tabla nat. Abordamos esta tabla después de la tabla filter debido a varias razones referentes a estos scripts: para empezar no queremos activar todo el mecanismo de reenvío (forwarding) y la función NAT en una etapa demasiado temprana, pues posiblemente podría dejar pasar los paquetes a través del cortafuegos en un momento erróneo (es decir, cuando el NAT se activa, pero ninguna regla de filtrado ha arrancado todavía). Además, veo la tabla nat como una especie de capa que está por encima de la tabla filter y que la rodea de alguna manera. Así pues la tabla filter debería ser el núcleo, mientras que la tabla nat actuaría como una capa que la recubre y por último la tabla mangle rodearía a la tabla nat como una segunda capa. Ésto puede ser erróneo desde algún punto de vista, pero no está demasiado lejos de la realidad.

      1. Configurar las políticas - antes que nada establecemos las políticas por defecto en la tabla nat. Normalmente estoy satisfecho con la política por defecto que hemos establecido al principio, es decir, ACCEPT. Esta tabla no debe ser usada para filtrar y no debemos bloquear los paquetes aquí, ya que pueden ocurrir algunas cosas realmente feas en dichos casos debido a nuestras presunciones. Dejo estas cadenas configuradas como ACCEPT puesto que no hay razón para no hacerlo.

      2. Creación de las cadenas específicas del usuario - ahora crearemos cualquier cadena específica del usuario que queramos añadir a la tabla nat. Normalmente no tengo ninguna, pero he añadido esta sección de todas formas, sólo por si acaso. Ten en cuenta que las cadenas específicas del usuario deben ser creadas antes de que puedan ser usadas en las cadenas del sistema.

      3. Creación del contenido de las cadenas específicas del usuario - ahora es el momento de añadir las reglas a las cadenas que irán en la tabla nat. Podemos decir lo mismo que con las cadenas específicas del usuario en la tabla filter. Añadimos estas reglas aquí, ya que no veo razón alguna para no hacerlo.

      4. Cadena PREROUTING - La cadena PREROUTING es la usada para hacer DNAT a los paquetes en caso de que tengamos la necesidad de hacerlo. En la mayoría de los scripts esta característica no se usa, o como mínimo está en forma de comentario; ésto es así para no abrir enormes agujeros hacia nuestra red local sin tener conocimiento de éllos. En algunos scripts tenemos esta cadena habilitada por defecto, ya que el único propósito de dichos scripts es proveer de tales servicios.

      5. Cadena POSTROUTING - la cadena POSTROUTING se usa bastante a menudo en los scripts que he escrito, puesto que la mayor parte de éllos se basan en el hecho de que tienes una o más redes locales que quieres defender de Internet mediante un cortafuegos. Principalmente intentaremos usar el objetivo SNAT pero en ciertos casos estaremos forzados a usar el objetivo MASQUERADE en su lugar.

      6. Cadena OUTPUT - la cadena OUTPUT es escasamente usada en algún script. Aunque lo parezca, no es que no funcione, pero no he sido capaz de encontrar un buena razón para usar esta cadena. Si alguien encuentra una razón para usarla, que me envíe unas líneas y añadiré esta cadena en el tutorial.

   3. Tabla mangle - la última tabla en la que hacer algo es la tabla mangle. Normalmente no usaré esta tabla, y no debería usarla nadie, a no ser que se tengan necesidades específicas como por ejemplo enmascarar todos los paquetes para que usen el mismo TTL o para cambiar el campo TOS, etc. En otras palabras, me decanto por dejar estas partes de los scripts más o menos en blanco, con unas pocas excepciones dónde añado unos cuantos ejemplos acerca de para qué se puede usar.

      1. Configurar las políticas - configurar las políticas por defecto de la cadena. Ocurre prácticamente lo mismo que en la tabla nat: esta tabla no está hecha para filtrar y de ahí que debas evitar hacerlo. Yo no he configurado ninguna política en la tabla mangle en ninguno de los scripts y te recomiendo que tú tampoco lo hagas.

      2. Crear cadenas específicas del usuario - crear todas las cadenas específicas del usuario. Ya que apenas uso la tabla mangle en los scripts, no he creado ninguna cadena aquí, puesto que es claramente inservible si no hay datos en los que emplearlas. Sin embargo, esta sección fue añadida por si hay alguien que la necesite en un futuro.

      3. Crear el contenido de las cadenas específicas del usuario - si tienes alguna cadena dentro de esta tabla debes añadirle las reglas en este momento.

      4. PREROUTING - hasta este momento apenas hay información en ningún script de este tutorial que contenga reglas aquí.

      5. Cadena INPUT - hasta este momento apenas hay información en ningún script de este tutorial que contenga reglas aquí.

      6. FORWARD chain - hasta este momento apenas hay información en ningún script de este tutorial que contenga reglas aquí.

      7. OUTPUT chain - hasta este momento apenas hay información en ningún script de este tutorial que contenga reglas aquí.

      8. POSTROUTING chain - hasta este momento apenas hay información en ningún script de este tutorial que contenga reglas aquí.

Esperemos que todo ésto ayude a entender mejor cómo está estructurado cada script y por qué está estructurado de dicha manera.

Ten en cuenta que estas descripciones son extremadamente breves, y principalmente deben ser vistas exclusivamente como una breve explicación de cómo y por qué los scripts han sido divididos como se ha hecho. Nadie dice que ésta sea la única y mejor manera de hacerlo.

rc.firewall.txt

El script rc.firewall.txt es el "centro neurálgico" en el que se basan el resto de scripts. El capítulo El archivo rc.firewall debería explicar detenidamente cada detalle del script. Principalmente se ha escrito para una red local casera dual, como por ejemplo cuando tienes una red local y una conexión a Internet. Este script también asume que tienes una dirección IP estática para la conexión a Internet, por lo que no usa ni DHCP, ni PPP, ni SLIP, ni ningún otro protocolo que te asigne automáticamente una dirección IP. Si lo que buscas es un script que funcione con esas configuraciones, mejor échale un vistazo al script rc.DHCP.firewall.txt.

El script rc.firewall.txt necesita que las siguientes opciones sea compiladas estáticamente en el núcleo, o bien compiladas como módulos. Sin alguna de éllas quedará penalizado en mayor o menor medida, puesto que habrán funcionalidades requeridas, necesarias en el script, que quedarán inutilizables. Asímismo, conforme vayas cambiando el script para adaptártelo, posiblemente necesitarás más opciones compiladas en el núcleo (dependiendo siempre de lo que quieras utilizar).

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_TARGET_LOG

rc.DMZ.firewall.txt

El script rc.DMZ.firewall.txt va destinado a aquellos que tienen una Red Interna de Confianza (Trusted Internal Network), una Zona "Desmilitarizada" (De-Militarized Zone) y una Conexión a Internet (Internet Connection). La Zona Desmilitarizada en este caso es "NAT-eada" 1-a-1 y requiere que hagas algo de solapamiento (aliasing) en tu cortafuegos, ésto es, debes conseguir que la máquina reconozca paquetes de más de una IP. Hay varias formas de conseguirlo: una es establecer la traducción NAT de 1 a 1; si dispones de una subred completa, otra forma sería crear una subred, dándole al cortafuegos una IP a la vez interna y externa. A partir de aquí, puedes establecer las IPs en las máquinas de la zona DMZ tal como desees. Sin embargo, ten encuenta que este sistema te "robará" dos IPs: una para la dirección de difusión (broadcast) y otra más para la dirección de red. Al final es decisión tuya qué implementar, pero este tutorial sólo te dará las herramientas para conseguir configurar la parte del cortafuegos y del NAT, siendo el resto tarea tuya, puesto que no te indicará qué debes hacer a partir de ahí (ésto se sale fuera de la intención del tutorial).

El script rc.DMZ.firewall.txt requiere las siguientes opciones compiladas en el núcleo, bien de forma estática, bien en forma de módulos. Sin estas opciones al menos disponibles en el núcleo, no serás capaz de utilizar la funcionalidad del script. O sea, que obtendrás un montón de errores respecto a módulos, objetivos/saltos o comparaciones no encontrados. Si tienes en mente efectuar un control del tráfico o algo similar, debes asegurarte que también tienes todas las opciones necesarias compiladas en el núcleo.

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_TARGET_LOG

Como puedes ver en la imagen, necesitas tener dos redes internas con este script. Una utiliza el rango IP 192.168.0.0/24 y se trata de una Red Interna de Confianza. La otra utiliza el rango IP 192.168.1.0/24, tratándose de la Zona Desmilitarizada a la que le efectuaremos la traducción NAT 1-a-1. Por ejemplo, si alguien desde Internet envía un paquete a nuestra DNS_IP, utilizaremos DNAT para enviar el paquete a nuestro DNS en la red DMZ. Cuando el DNS comprueba el paquete, lo envía a la dirección IP del DNS de la red interna y no a la IP del DNS externo. Si el paquete no hubiera sido traducido, el DNS nunca hubiera respondido al paquete. Veamos a continuación un pequeño ejemplo del aspecto del código DNAT:

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP \
--dport 53 -j DNAT --to-destination $DMZ_DNS_IP
    

Ésto viene a significar los siguiente: para empezar, la traducción DNAT sólo se puede efectuar en la cadena PREROUTING de la tabla nat. Después, buscamos el protocolo TCP en nuestra interfaz $INET_IFACE con la IP de destino que coincida con nuestra $DNS_IP y que esté dirigido al puerto 53, que es el puerto TCP para las transferencias de zona entre servidores de nombres. Si tenemos un paquete con estas características, hacemos que efectúe un salto DNAT. En resumen, efectuamos un DNAT. Después de ésto especificamos dónde queremos que vaya el paquete mediante la opción --to-destination y le damos el valor $DMZ_DNS_IP (la IP del DNS de nuestra red DMZ). Así es como trabaja básicamente el DNAT. Cuando la respuesta al paquete "DNATeado" se envía a través del cortafuegos, automáticamente se "des-DNATea".

Llegados a este punto, deberías comprender suficientemente bien cómo funciona todo, de manera que no te suponga ningún problema importante comprender bastante bien este script. Si hay algo que no entiendes y no ha sido tratado en el resto del tutorial, envíame un correo, pues probablemente sea un fallo por mi parte.

rc.DHCP.firewall.txt

El script rc.DHCP.firewall.txt es casi idéntico al original (rc.firewall.txt). Sin embargo, en este caso no se usa la variable STATIC_IP, lo cual es la mayor diferencia con el script original (rc.firewall.txt). La razón es que no funcionaría en una conexión con IP dinámica. Los cambios necesarios en el script original son mínimos, pero ha habido gente que me ha preguntado cómo solventar el problema de las IPs dinámicas, así que este script será una buena solución para todos los que tengan las mismas dudas. Este script es válido para todos aquellos que utilicen conexiones DHCP, PPP y SLIP para acceder a Internet.

El script rc.DHCP.firewall.txt requiere las siguientes opciones compiladas estáticamente en el núcleo, o al menos como módulos, para funcionar correctamente.

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_TARGET_MASQUERADE

• CONFIG_IP_NF_TARGET_LOG

Los cambios principales efectuados al script consisten en la supresión de la variable STATIC_IP, como ya he dicho, y de todas las referencias a élla. En lugar de utilizarla, el script ejecuta la mayor parte del filtrado a través de la variable INET_IFACE. Es decir, se ha cambiado -d $STATIC_IP por -i $INET_IFACE. Básicamente éstos son los únicos cambios necesarios.

De todas formas, hay algunas cosas más en las que debemos pensar. Ya no podemos filtrar en la cadena INPUT en función de, por ejemplo, --in-interface $LAN_IFACE --dst $INET_IP. Ésto nos obliga a filtrar únicamente basándonos en interfases en aquellos casos dónde las máquinas internas deben acceder a la IP direccionable de Internet. Un buen ejemplo es cuando ejecutamos un servidor HTTP en nuestro cortafuegos: si nos dirigimos a la página principal, la cual contiene enlaces estáticos a su mismo host (que puede tener alguna solución de dns dinámico, o dyndns), nos encontraremos con un problema realmente peliagudo. La máquina "NATeada" le preguntará al DNS por la IP del servidor HTTP, para luego intentar acceder a esa IP. Si filtrásemos basándonos en la interfaz y en la IP, la máquina "NATeada" sería incapaz de llegar al servidor HTTP, puesto que la cadena INPUT simplemente desecharía los paquetes. Ésto también puede aplicarse de alguna forma en el caso de que tengamos una IP estática, pero aquí tenemos la oportunidad de evitar el problema añadiendo reglas que chequeen si hay paquetes destinados a la INET_IP que provengan de la interfaz LAN, en cuyo caso los aceptará.

Como puedes observar, puede ser una buena idea conseguir un script (o escribirlo) que gestione más razonablemente las IPs dinámicas. Así, por ejemplo podemos escribir un script que capte la IP a través de ifconfig y la asigne a una variable, tras el arranque inicial de la conexión a Internet. Una buena forma de conseguirlo sería emplear los scripts ip-up que ofrece pppd, entre otros programas. Un buen sitio para buscar scripts es la página web sobre iptables "linuxguruz.org", dónde podrás encontrar y descargar montones de éllos. Encontrarás el enlace en el apéndice Otras fuentes y enlaces.

El script rc.DHCP.firewall.txt puede ser un poco más inseguro que el rc.firewall.txt, por lo que te sugiero que utilices éste último al no ser tan susceptible a ataques desde el exterior.

Además, existe la posibilidad de añadir algo parecido a lo siguiente en tus scripts:

INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ' ' -f 1`
    

Con éllo se captaría automáticamente la dirección IP de la variable $INET_IFACE, buscando la línea que contuviera la dirección IP y eliminando todo lo innecesario hasta obtener una dirección manejable. Para hacer todo ésto de una manera más elaborada, puedes aplicar las porciones de código disponibles en el script retreiveip.txt, que captarán automáticamente tu dirección IP de Internet al ejecutarlo. Ten en cuenta que, en cambio, con éllo se pueden obtener comportamientos algo extraños, como conexiones ralentizadas desde y hacia el cortafuegos en la parte interna. Los comportamientos extraños más comunes se describen en la siguiente lista:

1. Si el script se ejecuta desde otro script, que a su vez es ejecutado por, por ejemplo, el demonio PPP, todas las conexiones activas en ese momento se "colgarán", debido a las reglas "NEW not SYN" (léete el capítulo Paquetes cuyo estado es NEW pero cuyo bit SYN no se ha establecido). Es posible evitarlo si, por ejemplo, eliminas las reglas NEW not SYN, aunque esta solución es cuestionable.

2. Si tienes reglas que son estáticas y siempre tienen que estar activas, es bastante difícil añadir y borrar reglas contínuamente sin dañar las ya existentes. Por ejemplo, si quieres bloquear todos los intentos de conexión al cortafuegos provenientes de los hosts de tu LAN y, al mismo tiempo, ejecutar un script desde el demonio PPP, ¿cómo lo consigues sin borrar las reglas activas que están bloqueando tu LAN?

3. Puede complicarse innecesariamente, tal como se ha visto, lo cual puede llevar a comprometer la seguridad. Si el script se mantiene simple, es más fácil descubrir problemas y mantener un orden.

rc.UTIN.firewall.txt

El script rc.UTIN.firewall.txt, al contrario que el resto de scripts, bloqueará la red local (LAN) que haya por detrás nuestro. Es decir, que no nos fiaremos de nadie en ninguna red a la que estemos conectados. Además tampoco permitiremos a aquellos que estén en nuestra LAN que puedan hacer nada excepto tareas específicas en Internet. Lo único que permitiremos será el acceso a los servicios POP3, HTTP y FTP de Internet. Tampoco permitimos el acceso al cortafuegos a los usuarios internos en mayor medida que los usuarios desde Internet.

El script rc.UTIN.firewall.txt requiere que las opciones listadas más abajo se compilen estáticamente, o como módulos, en el núcleo. Sin una o más de éllas, tendrá un comportamiento defectuoso puesto que habrán funcionalidades necesarias que no podrán emplearse. Además, conforme vayas modificando el script según tus necesidades, posiblemente necesites más opciones compiladas en el núcleo.

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_TARGET_LOG

El script sigue la regla de oro de no fiarse de nadie, ni siquiera de tus propios empleados [en muchas ocasiones, aún menos de éllos]. Es una triste realidad, pero una gran parte de los "hacks" y "cracks" (accesos ilícitos) que sufre una compañía son debidos a personal de la propia plantilla. Quizá este script te sugiera algunas pistas sobre qué puedes hacer con tu cortafuegos para hacerlo más invulnerable. No es demasiado diferente al script rc.firewall.txt, pero ofrece algunas ideas sobre lo que normalmente dejaríamos pasar, ...

rc.test-iptables.txt

El script rc.test-iptables.txt se puede utilizar para chequear las diferentes cadenas, aunque puede necesitar algún ajuste que otro en función de tu configuración, como activar el ip_forwarding, configurar el enmascaramiento (masquerading), etc. Prácticamente le irá bien a todo aquél que tenga la configuración básica y las tablas básicas cargadas en el núcleo. Lo que hace es establecer algunos objetivos LOG, que registrarán las peticiones y respuestas a los ping. De esta forma obtendrás información sobre qué cadenas han sido atravesadas y en qué orden. Por ejemplo, ejecuta el script y después lanza el siguiente comando en la shell:

ping -c 1 un.host.de.internet
    

Y tail -n 0 -f /var/log/messages mientras se está ejecutando el primer comando. De esta forma deberías ver las diferentes cadenas empleadas y en qué orden, a no ser que las entradas del registro se trastoquen por algún motivo.

Este script se escribió únicamente para tareas de chequeo. O sea, no es una buena idea tener reglas de este estilo que lo registren todo, puesto que las particiones que tengas asignadas para los ficheros de registro pueden llenarse rápidamente y éllo podría convertirse en un ataque de Denegación de Servicios (DoS) muy efectivo contra tí, pudiendo conducir a ataques reales que no serían registrados tras el ataque DoS inicial.

rc.flush-iptables.txt

El script rc.flush-iptables.txt en realidad no se debería llamar un script en sí mismo. Lo que hará es reiniciar y "lavarle la cara" a todas tus tablas y cadenas. El script comienza por establecer la política por defecto a ACCEPT en las cadenas INPUT, OUTPUT y FORWARD de la tabla filter. Tras ésto, reiniciará las políticas por defecto de las cadenas PREROUTING, POSTROUTING y OUTPUT de la tabla nat. Se hace todo ésto en primer lugar para no tener que preocuparnos de conexiones cerradas y paquetes que no pueden entrar. El script está pensado para configurar y depurar errores en tu cortafuegos, por lo que sólo tenemos en cuenta el trabajo de abrir el cortafuegos y reiniciar todo a sus valores por defecto.

Tras éllo se limpian todas las cadenas, en primer lugar en la tabla filter y a continuación en la tabla NAT. De esta forma nos aseguramos que no hay reglas redundantes escondidas por cualquier sitio. Cuando ya se ha conseguido ésto, se salta a la siguiente sección, dónde borraremos todas las cadenas especificadas por el usuario en las tablas NAT y filter. Tras este paso se considera ejecutado el script. Sin embargo, puedes considerar necesario añadir reglas para limpiar la tabla mangle, si es que la utilizas.

Un apunte final: determinadas personas me han escrito pidiéndome que añada este script en el script original rc.firewall utilizando la sintaxis de Red Hat Linux, de forma que escribas algo parecido a "rc.firewall start" y el script se ejecute. Sin embargo no lo voy a hacer ya que éste es un tutorial y debería ser entendido principalmente como un lugar dónde encontrar ideas, por lo que no debería llenarse de scripts de shell [línea de comandos] y sintaxis extrañas. Añadir tales funcionalidades haría los scripts difíciles de leer desde el punto de vista que me he propuesto, ya que el tutorial se ha escrito con la legibilidad como pilar fundamental y así seguirá siendo.

Limit-match.txt

El script limit-match.txt es un test de chequeo de menor importancia que te permitirá comprobar la comparación límite (limit match) y ver cómo funciona. Carga el script y empieza a enviar paquetes ping a diferentes intervalos para ver cuáles atraviesan el cortafuegos y con qué frecuencia lo consiguen. Todas las echo replies (respuestas de eco) serán bloqueadas hasta que se alcance de nuevo el umbral del "burst limit".

Pid-owner.txt

El script pid-owner.txt es un pequeño ejemplo que muestra cómo podemos usar la comparación "PID owner" [propietario del número de identificación de proceso]. No hace nada útil, pero deberías ser capaz de ejecutarlo y ver en la salida de iptables -L -v que la regla está funcionando.

Sid-owner.txt

El script sid-owner.txt es otro pequeño ejemplo, que en este caso muestra cómo podemos usar la comparación "SID owner". No hace nada útil, pero deberías ser capaz de ejecutarlo y ver en la salida de iptables -L -v que la regla está funcionando.

Ttl-inc.txt

Un pequeño script de ejemplo: ttl-inc.txt. Este script muestra cómo hacer invisible al cortafuegos/enrutador frente a trazadores de ruta (traceroutes), que de otra forma ofrecerían bastante información a posibles atacantes.

Iptables-save

Un pequeño script de ejemplo utilizado en el capítulo Salvando y restaurando grandes conjuntos de reglas y que ilustra cómo se puede usar el comando iptables-save. Este script no es funcional, por lo que no debería usarse para otra cosa distinta a tenerlo como referencia.