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
Chapter 6. Cómo se escribe una regla 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
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í:
Chapter 6. Cómo se escribe una regla
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.
Warning
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í
Note: 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.
Note: Si obtienes registros de eventos directamente en pantalla y no es éso lo que quieres, no
busques el problema eniptables 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.
Chapter 6. Cómo se escribe una regla 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 desyslog.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 ficherosyslog.confy 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 ysyslog.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
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).
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. Table 6-18. Opciones del objetivo MARK
Opción --set-mark
Ejemplo iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2
Descripción La opción --set-mark se necesita para establecer una marca, que tomará un valor entero. Por ejemplo, podemos establecer una marca con un valor "2" en un flujo específico de paquetes, o en todos los paquetes de un host específico, y efectuar un enrutado avanzado sobre ese flujo/host para incrementar o disminuir el ancho de banda de la red, ...
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.
Chapter 6. Cómo se escribe una regla 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