6.5. Objetivos/Saltos (Targets/Jumps)

6.5.1. Objetivo ACCEPT

Este objetivo no necesita ninguna opción adicional. En cuanto la especificación de la comparación es satisfecha por un paquete y se indica ACCEPT (aceptar) como objetivo, la regla se acepta y el paquete no continúa atravesando ni la cadena actual, ni cualquier otra de la misma tabla. Advierte sin embargo que un paquete que haya sido aceptado por una cadena todavía podría atravesar las cadenas de otras tablas y podría ser desechado en éllas. Para emplear este objetivo no hay más que indicar -j ACCEPT.

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

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.

6.5.3. Objetivo DROP

El objetivo DROP (desechar) hace precisamente éso: desechar o "tirar" paquetes y no gastar ni ún segundo más de trabajo del procesador en éllos. Un paquete que llegue a una regla, coincida exactamente con el patrón de búsqueda de la comparación y sea desechado, será inmediatamente bloqueado. Ten en cuenta que esta acción puede llegar a tener en determinadas ocasiones un efecto no deseado, ya que puede dejar sockets (conexiones host-hardware) "muertos" en cualquier host. Una solución más acertada, cuando se puedan dar estas circunstancias, es usar el objetivo REJECT (rechazar), especialmente si quieres impedir que los escáners de puertos recojan demasiada información privada, como qué puertos tienes filtrados y otros detalles. Volviendo al objetivo, si se efectúa la acción DROP a un paquete dentro de una subcadena, este paquete ya no será procesado en ninguna de las cadenas principales de ninguna tabla: el paquete estará "muerto" de inmediato y, como ya se ha dicho antes, el objetivo no enviará ninguna información en ninguna dirección, ni siquiera a intermediarios como los routers (se puede decir que a partir de la acción de desechar el paquete es como si éste nunca hubiera existido).

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

6.5.5. Objetivo MARK

El objetivo MARK se usa para establecer marcas (marks) de Netfilter asociadas a paquetes específicos. Este objetivo sólo es válido en la tabla mangle y no funcionará fuera de élla. Los valores de las marcas pueden usarse conjuntamente con las capacidades de enrutado avanzado de Linux, de forma que se envíen diferentes paquetes por diferentes rutas y que se les pueda indicar que usen diferentes disciplinas para hacer cola (qdisc), ... Para mayor información acerca del enrutado avanzado, pásate por Linux Advanced Routing and Traffic Control HOW-TO. Ten en cuenta que el valor de la marca no se establece en el paquete mismo, sinó que es un valor asociado al paquete dentro del núcleo. Dicho de otro modo: no puedes esperar que estableciendo una "MARKa" en un paquete, ese valor permanezca en otro host. Si es éso lo que buscas, mejor mira en el objetivo TOS, que modificará el valor TOS de la cabecera IP.

6.5.6. Objetivo MASQUERADE

El objetivo MASQUERADE se usa básicamente de la misma forma que el objetivo SNAT, pero sin requerir ninguna opción --to-source. La razón es que el objetivo MASQUERADE se creó para trabajar, por ej., con conexiones telefónicas estándar (dial-up), o con conexiones DHCP, que obtienen direcciones IP dinámicas al conectar a la red en cuestión. Ésto quiere decir que sólo debes usar el objetivo MASQUERADE con conexiones IP asignadas dinámicamente, en las que antes de conectar con el ISP no sabemos la dirección que tendremos. Si tienes una conexión IP estática, debes emplear el objetivo SNAT en su lugar.

Enmascarar una conexión significa que estableces la dirección IP utilizada por una tarjeta de red específica, en lugar de utilizar la opción --to-source, por lo que la dirección IP se obtiene automáticamente de la información de la tarjeta específica. El objetivo MASQUERADE también tiene la particularidad de que las conexiones se olvidan, se pierden, cuando una interfaz se viene abajo (o como se suele decir, "se cuelga"), lo cual es extremadamente bueno si "matamos" una interfaz específica. En este caso, si hubiéramos utilizado el objetivo SNAT, podríamos haber llegado a tener un montón de datos viejos de seguimiento de conexión, que podrían haber estado "flotando" por la memoria durante días, devorando casi toda la memoria de seguimiento de conexiones. Así pues el enmascaramiento es, en general, la opción adecuada al trabajar con líneas telefónicas estándar, dónde probablemente se nos asignará una IP diferente cada vez que conectemos. En estos casos al desconectar la conexión se pierde totalmente, puesto que se nos asigna una IP diferente al reconectar, por lo que resulta bastante tonto mantener las entradas existentes del seguimiento de conexiones.

A pesar de todo, es posible usar el objetivo MASQUERADE en lugar del SNAT aunque tengas una IP estática, si bien no es conveniente puesto que genera un gasto extra de recursos y pueden haber futuras inconsistencias que desbaratarán tus scripts y los harán "inútiles".

Recuerda que el objetivo MASQUERADE sólo es válido en la cadena POSTROUTING de la tabla nat, igual que el objetivo SNAT. Además, el objetivo MASQUERADE acepta una opción, aunque ésta sea opcional.

6.5.7. Objetivo MIRROR

El objetivo MIRROR es únicamente experimental y de demostración, por lo que estás avisado para no utilizarlo: puede dar como resultado bucles infinitos (entre otras lindezas) que desemboquen en serias Denegaciones de Servicio (Denial of Service, DoS). Este objetivo se emplea para invertir los campos de origen y destino en la cabecera IP y después retransmitir el paquete. Esto puede crear efectos realmente divertidos y apuesto a que gracias a este objetivo más de un endemoniado cracker ha penetrado en su propio ordenador. El resultado de utilizar este objetivo es simple, por decirlo de alguna manera: digamos que establecemos un objetivo MIRROR para el puerto 80 del ordenador A y el host B (que proviene de yahoo.com) quiere acceder al servidor HTTP del host A; en estas condiciones el objetivo MIRROR devolverá al host de yahoo la página web de su propio servidor HTTP en Yahoo.com.

Debes tener en cuenta que el objetivo MIRROR sólo es válido cuando se utiliza en las cadenas INPUT, FORWARD y PREROUTING, así como en aquellas cadenas definidas por uno mismo y que sean llamadas desde alguna de las anteriores cadenas. Además, los paquetes salientes derivados de este objetivo no pasan por ninguna de las cadenas normales de las tablas filter, nat o mangle, lo que puede dar lugar a bucles infinitos y un rosario de problemas que pueden derivar en dolores de cabeza imprevistos. Por ejemplo, un host puede enviar un paquete camuflado (spoofed) con un TTL de 255 a otro host que utilice el objetivo MIRROR, de forma que parezca que el paquete viene de un tercer host que también usa el objetivo MIRROR; como consecuencia el paquete irá y volverá de un extremo al otro incesantemente, hasta que se completen el número de saltos (hops) definidos; si sólo hay un salto entre hosts, el paquete irá y vendrá 240-255 veces (no está mal para un cracker, pues enviando 1,5 kbytes de datos será capaz de consumir 380 kbytes de la conexión; siempre teniendo en cuenta que éste sería el mejor resultado para el cracker, script kiddie, novato, o como quiera llamársele).

6.5.8. Objetivo QUEUE

El objetivo QUEUE se emplea para poner en cola los paquetes dirigidos a programas y aplicaciones del Espacio de Usuario. Se usa con programas o utilidades que son externos a iptables y puede utilizarse, por ej., en contabilidad de red, o con aplicaciones específicas y avanzadas que filtren o den servicios de caché (proxy) a los paquetes. No desarrollaremos este objetivo en profundidad, puesto que la programación de esas aplicaciones excede los objetivos de este tutorial: para empezar costaría mucho tiempo y además esa documentación no tendría nada que ver con la programación de Netfilter e iptables; todo ésto debería estar perfectamente descrito en "COMO Programar Netfilter" (Netfilter Hacking HOW-TO).

6.5.9. Objetivo REDIRECT

El objetivo REDIRECT sirve para redirigir paquetes y flujos hacia la máquina. Ésto quiere decir que podemos redirigir todos los paquetes destinados a los puertos HTTP hacia un caché HTTP como squid, o hacia nuestro host. Los paquetes generados localmente son "mapeados" a la dirección 127.0.0.1, o lo que es lo mismo, se reescribe la dirección de destino con la de nuestro host en los paquetes que son reenviados o acciones similares. El objetivo REDIRECT es extremadamente recomendable si queremos un servicio de caché transparente, donde los hosts de la red local ni siquiera advierten que existe un caché (proxy).

Como viene siendo habitual, este objetivo sólo funciona en determinadas cadenas, que en este caso son PREROUTING y OUTPUT, ambas de la tabla nat. Asímismo, también es válido en cualquier cadena creada por el usuario, siempre que sea llamada por una de las anteriores cadenas. Y en cuanto a las posibles opciones, se reducen a una.

6.5.10. Objetivo REJECT

El objetivo REJECT (rechazar) funciona básicamente igual que el objetivo DROP, aunque en este caso sí que se devuelve un mensaje de error al host que envió el paquete bloqueado. El objetivo REJECT, hoy por hoy, sólo es válido en las cadenas INPUT, FORWARD y OUTPUT o sus "sub-cadenas"; después de todo, son las únicas cadenas donde tiene sentido utilizar este objetivo. De momento sólo hay una opción que modifique su forma de trabajar, pero en cambio tiene un montón de variables dónde escoger (la mayoría son fáciles de entender, siempre que tengas un conocimiento básico sobre TCP/IP).

6.5.11. Objetivo RETURN

El objetivo RETURN hará que el paquete que está atravesando una cadena pare allí donde se encuentre con el objetivo; si está en una "sub-cadena", el paquete continuará atravesando la cadena superior desde donde la dejó; si, por el contrario, es una cadena principal (tal como la cadena INPUT), se ejecutará la política por defecto sobre el paquete. La política por defecto normalmente está definida como ACCEPT, DROP o algo similar.

Por ejemplo, un paquete entra en la cadena INPUT y llega a una regla en la que coincide con su comparación y que tiene definida la acción --jump CADENA_DE_EJEMPLO como objetivo; como consecuencia el paquete empezará a atravesar la CADENA_DE_EJEMPLO hasta que llegue a una regla donde coincida con la comparación y cuyo objetivo sea --jump RETURN; entonces volverá a la cadena INPUT y seguirá desde la regla siguiente a la que produjo el salto. Otro ejemplo sería que el paquete llegara a una regla de la cadena INPUT y se le aplicara la acción --jump RETURN, a consecuencia de lo cual se le aplicaría inmediatamente la política por defecto y abandonaría esta cadena, para seguir por el resto de cadenas de la tabla, si las hay.

6.5.12. Objetivo SNAT

El objetivo SNAT se emplea para efectuar las traducciones de dirección de red de origen (Source Network Address Translation), lo cual implica que este objetivo reescribirá la dirección IP de origen en la cabecera IP del paquete (ésto es deseable cuando varios hosts tienen que compartir una conexión a Internet). Así pues, podemos activar el reenvío de paquetes IP a nivel de núcleo y escribir una regla SNAT que cambiará la dirección IP de origen de todos los paquetes que salgan de la red local, por la dirección IP de origen de nuestra conexión a Internet. Si no se efectuara esta traducción, el mundo exterior no sabría dónde enviar los paquetes de respuesta, puesto que la mayoría de las redes internas utilizan las direcciones IP especificadas por el IANA para las redes locales. Si los paquetes llegaran tal cual, nadie sabría quién los ha enviado. El objetivo SNAT efectúa todas las traducciones necesarias para llevar a cabo esa tarea, haciendo que todos los paquetes que salgan de la red local parezca que salen de un host concreto (por ej. el cortafuegos).

El objetivo SNAT sólo es válido en la tabla nat y dentro de la cadena POSTROUTING. Sólo el primer paquete de una conexión es modificado por SNAT, después del cual todos los paquetes pertenecientes a la misma conexión serán modificados de la misma manera que el primero: el primer paquete llega al cortafuegos y entra en la tabla nat, dónde pasa en primer lugar por la cadena PREROUTING y se le modifica la dirección de destino con DNAT; a continución llega a la cadena POSTROUTING y se le modifica la dirección de origen con SNAT; después sigue su curso a través del resto de tablas, cadenas y reglas; en cambio el segundo y siguientes paquetes del mismo flujo ni siquiera tocan la tabla nat, sinó que se les aplican directamente las mismas traducciones que al primer paquete. Entre otras razones, es por esta forma de trabajar de la tabla nat por lo que no se recomienda filtrar en élla.

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

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

6.5.15. Objetivo ULOG

Este objetivo se emplea para proporcionar capacidades de registro en el espacio de usuario a los paquetes que concuerden. Si un paquete coincide con la comparación del filtro (de la regla) y se ha establecido el objetivo ULOG, la información del paquete es difundida mediante una "multidifusión" (multicast), junto con el paquete entero, a través de una conexión virtual de red (netlink socket). A partir de entonces, uno o varios procesos de espacio de usuario pueden subscribirse a varios grupos de multidifusión y recibir el paquete. Ésta es una capacidad más completa y sofisticada de registro que hasta ahora sólo utilizan iptables y Netfilter y que tiene mucha más capacidad para el registro de paquetes. Este objetivo nos permite registrar información en bases de datos MySQL, entre otras, haciendo más fácil la búsqueda de paquetes específicos y el agrupamiento de entradas de registro. Puedes encontrar las aplicaciones de espacio de usuario de ULOGD en Página del proyecto ULOGD.