Xtables-addons
Extendiendo Iptables
•
Índice de contenido
Introducción...3
Xtables-addons contra Patch-o-matic...3
Instalación en sistemas Debian...4
Descripción de los módulos disponibles...5
Módulos de matching...5
Condition...5
dhcpmac...6
fuzzy...6
geoip...7
iface...7
ipp2p...8
ipv4options...9
length...9
lscan...10
psd...10
quota2...11
pknock...12
Módulos de targets...12
ACCOUNT...12
DELUDE...13
TARPIT...13
CHAOS...14
DHCPMAC...14
IPMARK...15
LOGMARK...16
RAWDNAT, RAWSNAT...16
STEAL...16
SYSRQ...17
TEE...17
Introducción
Iptables es una herramienta de cortafuegos que permite filtrar paquetes, realizar traducción de direcciones o mantener registros de log, entre otras muchas funcionalidades. Forma parte del entorno Netfilter, que tiene también otros componentes tanto en espacio de usuario como del núcleo.
Una característica muy importante y sobre la que vamos a basar este estudio, es su
extensibilidad mediante módulos adicionales. La herramienta iptables ya está preparada para ello, aunque también es habitual que se haga uso de utilidades adicionales.
El proyecto que contiene toda esa serie de módulos y utilidades adicionales que no vienen incluídas en iptables se llama Xtables-addons. Estos módulos añaden diferentes matches y targets que añaden funcionalidades de todo tipo, algo sobre lo que ahondaremos en la siguiente sección.
Xtables-addons contra Patch-o-matic
Tradicionalmente, las extensiones para Iptables se distribuían en forma de parches para el núcleo Linux con un sistema llamado Patch-o-matic. Era tratado en parte como un playground
donde probar toda clase de código que extendiera la funcionalidad de Iptables, sin prestar mucha atención a la calidad ni a la mantenibilidad. Esto causaba varios problemas:
• A menudo algunos parches conflictían entre ellos, bien al aplicarse o en el momento de su funcionamiento.
• No había un proceso de revisión del código, se aceptaba prácticamente cualquier cosa que fuera código que compilase.
• Como tan solo eran parches de código, normalmente era necesario recompilar los módulos de iptables y en ocasiones también el núcleo.
• Como el API de iptables iba evolucionando en diferentes versiones del núcleo Linux, el código de los parches estaba plagado de condiciones de preprocesado según la versión del núcleo para la que fueran a ser compilados.
Xtables-addons ha querido mejorar este escenario, y soluciona esos problemas en mayor medida:
• Las extensiones se encapsulan en módulos independientes, ya no parchean directamente el código de iptables, por lo que no es necesario recompilar ni iptables ni el núcleo.
• El código sufre un proceso de revisión y se intenta que unos módulos no conflictan con otros, aunque la naturaleza experimental del proyecto sigue estando ahí.
Instalación en sistemas Debian
El código de Xtables-addons puede descargarse de su página web y compilarse, siempre y cuando dispongamos del entorno de construcción adecuado. Necesitaremos las cabeceras del núcleo,a demás de las bibliotecas y utilidades básicas de compilación.
En sistemas derivados de Debian, como es el caso de Ubuntu, la instalación se puede hacer siguiendo el sistema de paquetes de la distribución, lo que nos permitirá un mayor y mejor control.
En las últimas versiones de estas distribuciones todos los paquetes están en los repositorios principales. Partimos de la suposición de que estos están activados y actualizados.
Primero, debemos instalar los paquetes xtablesaddonssource y xtables addonscommon. Esto instalará también todo lo necesario para compilar los módulos de Xtables-addons, como module-assistant y las cabeceras del núcleo.
# apt-get install xtables-addons-source xtables-addons-common
Tras hacerlo, ya podremos compilar e instalar los módulos de Xtables-addons utilizando la herramienta module-assistant:
# module-assistant build xtables-addons # module-assistant install xtables-addons
Eso es todo. Naturalmente, los módulos no se cargan solos. Si queremos hacer uso de alguno de ellos, deberemos cargarlos de forma manual, bien introduciéndolos en un sistema de carga de módulos o a través de la herramienta modprobe.
Los módulos comienzan todos por «xt_» y sigue el nombre del módulo, una palabra en minúsculas si es el nombre de matching, o una palabra en mayúscula si es el nombre de un
target. Por ejemplo:
# modprobe xt_ACCOUNT # modprobe xt_geoip
Descripción de los módulos disponibles
Como ya hemos comentado anteriormente, cada uno de los módulos de Xtables-addons hacen una de estas dos cosas: o añadir un target o añadir un match.
El target es la parte de las reglas de Iptables que especifica qué hacer con un paquete, una vez ya se ha determinado que debe hacer algo con él. El match es la parte de las reglas de Iptables que se encarga de determinar si debe hacerse algo con el paquete o no.
Módulos de matching
Con Iptables pueden establecerse algunas condiciones básicas para determinar si debe hacerse algo con un paquete o no, pero gracias a estos módulos podemos extender estas condiciones. Normalmente se indican con el parámetro «-m» y necesitan algún parámetro más. Ahora veremos cada uno de estos módulos en detalle.
Condition
Este match permite establecer una condición arbitraria. Que se cumpla la condición o no depende del valor almacenado en un archivo del sistema de archivos proc, de la forma
/proc/net/nf_condition/nombre.
Hay una única opción que sirve para establecer el nombre del archivo que almacenará el valor de la condición:
--condition nombre
Para utilizarlo es necesario cargar el módulo correspondiente:
# sudo modprobe xt_condition
Vamos a poner un ejemplo. La siguiente regla sirve para aceptar los paquetes TCP que lleguen por el puerto 80:
# iptables -A INPUT -p tcp -m condition --condition web --dport 80 -j ACCEPT
Entonces, para que esta regla funcione, debe establecerse a verdadero el archivo /proc/net/nf_condition/web:
Para que deje de hacerlo, debe establecerse a falso de la misma forma:
# echo 0 > /proc/net/nf_condition/web
dhcpmac
Con este match podemos encontrar coincidencias en los paquetes DHCP que provengan desde una interfaz de red con una mac determinada.
Dispone de una única opción que sirve para establecer la mac con la que queremos enncontrar coincidencia:
--mac aa:bb:cc:dd:ee:ff/mask
La parte del valor «/mask» nos permite especificar una máscara para encontrar coincidencias solo con una parte de la MAC.
Para utilizarlo es necesario cargar su módulo correspondiente:
# modprobe xt_dhcpmac
La siguiente regla sirve para rechazar todos los paquetes DHCP con un rango de direcciones MAC determinado (que empiece por 00:50:26):
# iptables -A INPUT -m dhcpmac --mac 00:50:56:00:00:00/24 -j DROP
fuzzy
Este match implementa un controlador de lógica borrosa (Fuzzy Logic Controller) llamado Takagi-Sugeno-Kang Fuzzy Controller Logic que permite encontrar coincidencias según el número de paquetes por segundo.
En este caso disponemos de dos opciones, que permiten establecer el rango de aceptación. Como los algoritmos son complejos, no es tan sencillo como establecer un único valor de paquetes por segundo a partir del cual la regla se acepta, sino que hay un mínimo y un máximo:
--lower-limit minimo --upper-limit maximo
Para utilizarlo hay que cargar el módulo correspondiente:
# modprobe xt_fuzzy
Por ejemplo, la siguiente regla permite evitar ataques DoS, comenzando a rechazar algunos paquetes a partir de 100 por segundo y prácticamente todos a partir de 1000 por segundo:
# iptables -A INPUT -m fuzzy --lower-limit 100 --upper-limit 1000 -j REJECT
geoip
Este match permite encontrar coincidencias según el país de origen o de destino del paquete. Dispone de dos opciones, precisamente para establecer el país de origen o el país de destino, que debe especificarse en su código ISO3166:
--source-country paisorigen
--destination-country paisdestino
Es necesario descargar una base de datos actualizada de correspondencias de direcciones IP con países1 y descomprimirla en el directorio /var/geoip. Además, hay que cargar el
módulo:
# modprobe xt_geoip
La siguiente regla sirve para aceptar todos los paquetes destinados a una IP situada en España o en Francia:
# iptables -A OUTPUT -m geoip --destination-country ES,FR -j ACCEPT
iface
Con este match es posible comparar el estado y propiedades de la interfaz de red por la que pasa un paquete.
La opción más sencilla es «iface» en la que se debe especificar el nombre de la interfaz de red. Recibe un argumento con el nombre:
--iface nombre
El resto de opciones sirven para realizar las comprobaciones sobre esa interfaz, buscando flags
de la misma que definen sus propiedades. Son autoexplicativas: --up, --down
--broadcast --loopback --pointtopoint --running --noarp, --arp --promisc --multicast --dynamic --lower-up --dormant
Por supuesto, para utilizarlo debemos antes cargar el módulo:
# modprobe xt_iface
Este ejemplo sirve para descartar todos los paquetes salientes de la interfaz wlan0 cuando está en modo promiscuo:
# iptables -A OUTPUT -m iface --iface wlan0 --promisc -j DROP
ipp2p
Este match permite encontrar coincidencias con ciertos paquetes P2P. No está diseñado para capturar todos los paquetes de una conexión P2P, pero sí puede ser suficiente para identificar si hay tráfico P2P y entorpecerlo, entre otras posibilidades.
Dispone de muchísimas opciones, para detectar los diferentes tipos de tráfico P2P que soporta: eDonkey/eMule, KaZaA, Gnutella, Direct Connect, BitTorrent, AppleJuice, SoulSeek, WinMX y Ares.
--edk --kazaa --gnu --dc --bit --apple --soul --winmx --ares
Además, dispone de una opción para registrar alguna información sobre su funcionamiento en el log del núcleo, algo que puede ser de utilidad a la hora de probarlo:
Como anteriores matches, este también necesita su correspondiente módulo para funcionar:
# modprobe xt_ipp2p
Por ejemplo, con la siguiente regla podemos entorpecer la comunicación mediante Bittorrent rechazando todos los paquetes que identifique como pertenecientes a este protocolo de comunicación P2P:
# iptables -A FORWARD -m ipp2p --bit -j DROP
ipv4options
Este match nos permite buscar flags en las cabeceras IP, en comunicaciones que utilizan Ipv4. La opción esencial para realizar esto es «flags», que permite especificar los flags que debe buscar separados por comas. Podemos negar la aparición de alguno anteponiendo un «!».
--flags flag1,flag2,!flag3
Normalmente se comprueban todos los flags con una operación AND. Podemos especificar que queremos buscar solo uno de ellos (operación OR) con la opción «any».
--any
Ya no hace falta que lo digamos, para utilizarlo debemos cargar su módulo correspondiente «xt_ipv4options». Por ejemplo, la siguiente regla busca paquetes que tengan el flag traceroute
o el router-alert y los descarta:
# iptables -A OUTPUT -m ipv4options --flags traceroute,router-alert --any -j DROP
length
Este match nos permite encontrar coincidencias según la longitud de los paquetes.
El funcionamiento básico es mediante el parámetro «length», que permite especificar una longitud determinada o un rango de longitudes de aceptación:
--lenght 120 --length 80:250
Debemos especificar también la capa que intentamos medir estableciendo otro parámetro: «layer3» para las cabeceras IP más el payload, «layer4» para las cabeceras TCP/UDP más el
--layer3 --layer4 --layer5
Tras cargar el módulo «xt_length» requerido, ya podemos establecer reglas. Por ejemplo, la siguiente regla rechaza todos los paquetes cuyo payload TCP sea superior a 100 bytes e inferior a 200 bytes en tamaño:
# iptables -A INPUT -m length --length 100:200 -j DROP
lscan
Este match permite detectar intentos de escaneo a bajo nivel según el contenido de los paquetes, con la intención por ejemplo de bloquear futuras conexiones desde la máquina que lanza el escaneo.
Hay disponibles cuatro opciones, que sirven para encontrar coincidencias con cuatro tipos de escaneos distintos:
• «stealth» coincide si el paquete no pertenece a ninguna conexión TCP conocida.
• «synscan» coincide si la conexión fue un escaneo SYN, es decir, si la conexión se perdió tras el segundo paquete en el handshake de tres paquetes.
• «cnscan» coincide si la conexión fue un escaneo connect, es decir, si la conexión se persió después de completarse el handshake de tres paquetes.
• «grscan» coindide si la conexión fue únicamente unidireccional hacia fuera, por ejemplo, si la conexión se perdió después de que un servicio enviase datos de autenticación. Este tipo de conexiones son habituales en algunos protocolos, así que solo debería utilizarse en puertos en los que efectivamente se espera una respuesta. Tras cargar el módulo «xt_lscan» ya podemos utilizarlo. Por ejemplo, la siguiente regla registra en el log del núcleo cuándo detecta escaneos del tipo synscan:
# iptables -A INPUT -p tcp -m lscan --synscan -j LOG --log-prefix "[SYNSCAN] "
psd
• «psd-weight-threshold» para especificar el umbral, en peso total, por el que se considera un positivo.
• «psd-delay-threshold» para especificar las centésimas de segundo máximas por las que paquetes enviados a distintos puertos se consideran como una secuencia de escaneo.
• Con «psd-lo-ports-weight» podemos darle un peso a las detecciones en puertos inferiores a 1024.
• Con «psd-hi-ports-weight» hacemos lo propio con los puertos superiores.
Lógicamente, debemos cargar el módulo «xt_psd». Una vez hecho esto ya podemos utilizarlo. Por ejemplo, la siguiente regla intenta encontrar escaneos con una separación máxima de 1 segundo entre paquetes, un umbral de 200 y un peso en puertos bajos de 3. Al enconrar coincidencias lo registra en el log del núcleo.
# iptables -A FORWARD -m psd weight-threshold 200 --psd-delay-threshold 10 --psd-lo-ports-weight 1 --psd-hi-ports-weight 3 -j LOG --log-prefix "[PSD] "
quota2
Con este match tenemos un contador que puede ser incrementado o decrementado a voluntad cuando se encuentran coincidencias. Puede contar tanto paquetes como bytes. Este valor se puede leer y alterar mediante el sistema de archivos proc.
La opción por defecto es decrecer el contador. Con «grow» lo aumentamos. Debemos además ponerle un nombre con «name» y un valor inicial con «quota». Por defecto cuenta bytes, pero podemos especificar que cuente paquetes con la opción «packets».
Además de leer su valor a través del sistema de archivos proc para establecer sistemas de cuotas o contar el tráfico, se pueden crear filtros más complejos. Por ejemplo, este filtro
bytebucket que solo deja salir tanto tráfico como entra por un puerto determinado, realizado en base a dos reglas:
# iptables -A INPUT -p tcp --dport 6881 -m quota --name bt --grow
# iptables -A OUTPUT -p tcp --sport 6881 -m quota --name bt -j ACCEPT
pknock
Este match nos permite realizar golpeo de puertos (port knocking) directamente con Iptables. Se trata de una implementación bastante completa, con multitud de opciones.
Veamos directamente un ejemplo de funcionamiento. Previamente ya hemos cargado el módulo «xt_pknock» que posibilita el funcionamiento de este match.
iptables -A INPUT -p tcp -m pknock --knockports 8902,8901,8907 --strict --name SSH --time 10 --autoclose 60 --dport 22 -j ACCEPT
Esta regla permitirá las conexiones TCP al puerto 22 tras un golpeo de puertos satisfactorio. El golpeo de puertos lo hemos especificado de la siguiente forma:
• La secuencia de puertos la definimos con el parámetro «knockports» y es la secuencia formada por el 8902, el 8901 y el 8907.
• El parámetro «strict» nos permite definir que no debe haber otros paquetes por el medio del golpeo.
• Definimos que la duración máxima del golpeo de puertos son 10 segundos con el parámetro «time». Pasados esos 10 segundos, si no se ha completado el golpeo no se completará.
• El puerto volverá a cerrarse tras 60 minutos, algo que definimos con el parámetro «autoclose».
• Se registrará el estado del puerto en el archivo /proc/net/xt_pknock/SSH. También se pueden hacer golpeos más avanzados, establecimiendo llaves de paso en el
payload de los paquetes y otras opciones avanzadas. Módulos de targets
¿Qué debe hacerse con un paquete una vez que hemos determinado que queremos hacer algo con él? Estos módulos sirven para extender estas posibilidades. Solos o en combinación con algunos de los matches que vimos antes pueden crear muchas posibilidades interesantes. Como los targets que vienen con Iptables, se establecen con la opción «-j». Algunos de ellos llevan parámetros adicionales. Pasaremos ahora a ver en detalle cada uno de ellos.
ACCOUNT
Recibe dos parámetros obligatorios: la dirección o direcciones de red que queremos
contabilizar con el parámetro «addr» y el nombre de la tabla donde se almacenará toda esta información con el parámetro «tname».
--addr direccion/máscara --tname nombre
Los datos pueden consultarse posteriormente con una biblioteca llamada libxt_ACCOUNT_cl, o bien mediante la utilidad iptaccount, que dispone de una interfaz sencilla mediante línea de comandos.
Es necesario cargar el módulo «xt_ACCOUNT». Una vez lo hagamos ya podemos crear contadores:
# iptables -A FORWARD -j ACCOUNT --addr 0.0.0.0/0 --tname todo
Con este comando contabilizamos todo el tráfico. Podemos consultarlo posteriormente con la utilidad iptaccount, como hemos comentado antes:
# iptaccount -l todo
DELUDE
Este target contestará a todos los paquetes SYN con SYN-ACK y al resto con RST. De esta forma se pueden engañar a los escaneadores de puertos haciendo que hacen escaneos TCP half-open, haciéndoles creer que los puertos están abiertos cuando en realidad no lo están.
No recibe ningún parámetro. Para que funcione debemos cargar el módulo «xt_DELUDE». En el siguiente ejemplo utilizamos este target para hacer creer a un escáner de puertos que todos están abiertos:
# iptables -A INPUT -m lscan --stealth -j DELUDE
TARPIT
Este target captura y mantiene las conexiones TCP. Las acepta, pero las establece en un modo de persistencia (establece la byte window a 0 bytes) en que el lado remoto pregunta a intervalos de 60-240 segundos si puede continuar. Los intentos de cerrar la conexión se ignoran. Esto permite mantener las conexiones abiertas cerca de 12-24 minutos.
# iptables -A FORWARD -p tcp -j TARPIT
CHAOS
Este target sirve para provocar el caos y la confusión en la otra punta de la comunicación haciendo cosas inesperadas con los paquetes que recibe. Contestará a las peticiones o no (de forma aleatoria) con un comportamiento definido por alguna de estas opciones:
• «delude» utiliza los targets REJECT y DELUDE alternativamente para intentar reiniciar la conexión, engañando a algunos escáneres de red para que obtengan resultados aleatorios.
• «tarpit» utiliza los targets REJECT y TARPIT para intentar, o no, mantener la conexión el máximo tiempo posible abierta.
El factor de aleatoriedad de contestar o no puede establecerse mediante el sistema de archivos
proc o al cargar su módulo, «xt_CHAOS», mediante un parámetro.
Por ejemplo, con la siguiente regla, cuando detectamos un escaneo de puertos, intentamos engañar a la máquina que lo hace devolviéndole resultados aleatorios:
# iptables -A INPUT -m lscan --stealth -j CHAOS --delude
DHCPMAC
Este target permite reemplazar direcciones MAC. Utilizado en conjunción con el match
dhcpmac, permite cambiar las MAC de interfaces en escenarios donde no es posible hacerlo en la propia interfaz (por ejemplo, al arrancar mediante PXE o al utilizar ciertas máquinas
virtuales que no permiten establecer direcciones MAC libremente).
Requiere el módulo «xt_DHCPMAC» y dispone de un único parámetro que permite establecer la dirección MAC. Puede cambiarla completamente o solo una parte, mediante una máscara:
--set-mac aa:bb:cc:dd:ee:gg/mask
En el siguiente ejemplo, cambiamos la MAC de una máquina para que sea aceptada por un servidor DHCP al arranque por PXE:
iptables -t mangle -A FORWARD -p udp --dport 67 -m dhcpmac --mac 00:50:56:00:00:00/24 -j DHCPMAC --set-mac
ab:cd:ef:00:00:00/24
iptables -t mangle -A FORWARD -p udp --dport 68 -m dhcpmac --mac ab:cd:ef:00:00:00/24 -j DHCPMAC --set-mac
IPMARK
Este target permite marcar un paquete basándose en su dirección IP, realizando operaciones AND y OR sobre las mismas.
Por ejemplo, si queremos marcar todos los paquetes de un rango determinado de IPs y en la marca queremos establecer información sobre la IP, sin este target tenemos que crear múltiples reglas:
iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.5.2 -j MARK --set-mark 0x10502
iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.5.3 -j MARK --set-mark 0x10503
iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.5.4 -j MARK --set-mark 0x10504
iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.5.5 -j MARK --set-mark 0x10505
Pero con este target, como podemos tomar la IP y realizar operaciones con ella, podemos reducirlo a una única regla:
# iptables -t mangle -A POSTROUTING -o eth0 -J IPMARK --addr dst --and-mask 0xffff --or-mask 0x10000
Con esto creamos una marca compuesta de un 1 y los dos últimos campos de la IP, tal y como hacíamos en el ejemplo anterior.
Para que funcione debemos cargar el módulo «xt_IPMARK». Las opciones son las que ya hemos visto: «and-mask» y «or-mask» para realizar operaciones AND u OR, y «addr» para especificar si queremos basarnos en la IP de origen o destino.
--and-mask mask --or-mask mask --addr src|dst
Además disponemos de la opción «shift» para establecer marcas con valores de las IPs que no están en la posición deseada.
--shift desplazamiento
Por ejemplo, si tenemos la IP 10.20.30.40 y quemos guardar el 20 en la marca, tenemos que hacer un desplazamiento de 16 bits a la derecha:
LOGMARK
Este target registrará las marcas de paquetes en el syslog.
Recibe dos parámetros, level» para especificar un nivel de registro del 0 al 8, y «log-prefix» para establecer el prefijo que aparecerá en el registro.
--log-level 0
--log-prefix prefix
Es necesario cargar el módulo «xt_LOGMARK». Por ejemplo, para registrar todas las marcas de paquetes:
# iptables -A FORWARD -J LOGMARK --log-level 0 --log-prefix "[LOGMARK] "
RAWDNAT, RAWSNAT
Los targets RAWDNAT y WARSNAT sirven para realizar traducción de direcciones de destino y origen, respectivamente. Se utilizan en las tablas raw o rawpost.
Al contrario que los targets DNAT y SNAT, no cambia la dirección de las conexiones, sino de los paquetes. Por lo tanto puede traducir direcciones de conexiones ya establecidas de
antemano, o ya traducidas en la conexión.
Según el target, acepta el parámetro «to-source» o «from-source» para realizar la traducción de direcciones.
--to-source direccion/mascara --from-source direccion/mascara
Requiere la carga del módulo correspondiente, «xt_RAWDNAT» o «xt_RAWSNAT». En el siguiente ejemplo traducimos la dirección origen de los paquetes provenientes de
192.168.1.10.
# iptables -t rawpost -A POSTROUTING -o lan0 -s 192.168.1.10 -j RAWSNAT --to-source 192.168.0.1
STEAL
SYSRQ
Este target permite disparar de forma remota funciones del sistema de emergencia sysrq
(también conocido como magic SysRq keys) de la máquina.
Para poder utilizarlo debe cargarse el módulo «xt_SYSRQ». No recibe parámetros, pero sí puede establecerse una contraseña al cargar el módulo o mediante el sistema de archivos proc.
Por ejemplo, para aceptar peticiones desde una IP y una MAC determinada, comprobando que la IP de destino está bien para mayot seguridad, en el puerto UDP 9:
# iptables -A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d 10.10.25.7 -p udp --dport 9 -j SYSRQ
Ahora establecemos una contraseña:
echo -n "password" >/sys/module/xt_SYSRQ/parameters/password
Para realizar las llamadas podemos utilizar este pequeño script que hace uso de netcat:
sysrq_key="s"
password="password" seqno="$(date +%s)"
salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null | openssl enc -base64)"
req="$sysrq_key,$seqno,$salt"
req="$req,$(echo -n "$req,$password" | sha1sum | cut -c1-40)" echo "$req" | netcat -uw1 10.10.25.7 9
Con este script activamos la función de la tecla «s» en el ordenador con la IP 10.10.25.7, que es el que hemos configurado previamente. Está escuchando peticiones por el puerto UDP 9 y con la contraseña «password» que hemos establecido antes.
La tecla «s» sirve para sincronizar los sistemas de archivos. Otras teclas útiles son la «o» para apagar, la «b» para reiniciar o la «u» para montar los sistemas de archivos como solo lectura. Con la documentación del núcleo Linux viene la lista de teclas completa.
TEE
Por último, este target clona un paquete y redirige su clon a otra máquina de ese segmento de la red local. Es decir, el destino debe ser el siguiente salto. Sino, se deberá configurar la máquina donde haga el siguiente salto también.
--gateway direccionip
Por ejemplo, para reenviar todo el tráfico entrante en la interfaz eth0 a la máquina con la IP 192.168.0.10, se puede utilizar esta regla:
Bibliografía
• Página oficial de Xtables-Addons
Obtenida el 3 de junio de 2010
http://xtables-addons.sourceforge.net/
• Página oficial de Iptables/Netfilter
Obtenida el 3 de junio de 2010
http://www.netfilter.org
• Presentación «Introduction to Xtables-addons» del NFWS2008 Obtenida el 4 de junio de 2010
http://jengelh.medozas.de/documents/IntroXta.pdf
• Página de manual de Xtables-Addons 1.21
