Linux iptables COMO
Rusty Russell, mailing list netfilter@lists.samba.org
Traducido por Jorge Gómezy Pablo Íñigo
v0.0.2, Wed Sep 29 17:44:43 CST 1999
Este documento describe el uso de iptables para filtrar paquetes dañinos para kernels de Linux 2.3.15 y superiores.
1. Introducción
2. ¿Donde esta la página oficial y la lista?
3. ¿Que es el filtrado de paquetes?
3.1 Redes muy básicas
3.2 ¿Que es un filtrado de paquetes?
3.3 ¿Por que quiero filtrar paquetes?
3.4 ¿Como filtro paquetes bajo linux?
4. ¿Quien demonios eres, y que haces jugando con mi núcleo?
5. Que paquetes atraviesan el filtro
6. Utilizando iptables
6.1 Que veras cuando tu ordenador arranca
6.2 Operaciones con una regla simple
6.3 Especificaciones de filtrado
6.4 Especificaciones de destino
6.5 Operaciones en una chain completa
7. Diferencias entre iptables e ipchains
1. Introducción
Bienvenidos, señores lectores
Este HOWTO pasa entre ser una amigable introducción ( la cual os dejará una sensación de tranquilidad, pero desprotegidos en el mundo real) y un crudo discurso ( el cual os ofrecerá una sensación de paranoia, confusión y aturdimiento)
Tu red no es segura. El problema de permitir rápidamente, convenientes comunicaciones mientras se restringe el uso a buenas personas y no a demonios con malas intenciones, es como permitir discursos mientras se desactiva una llamada de fuego en un teatro ardiendo. Esto no será solucionado en el HOWTO.
Así, tu decidirás donde te comprometerás. Yo intentare instruirte en el uso de algunas de las herramientas y algunas vulnerabilidades, y al final tu deberás utilizar estos conocimientos para solucionar problemas, no para crearlos. Lo contrario te creará problemas.
2. ¿Dónde esta la página oficial y la lista?
Hay tres sitios oficiales
Gracias a Penguin Computing. http://sindormir.net/iptables/iptables-HOWTO-2.html
Gracias a The Samba Team and SGI. http://www.samba.org/netfilter
Gracias a Jim Pick . http://netfilter.kernelnotes.org/
Para la lista de correo oficial de netfilter mira Samba’s Listserver. http://lists.samba.org/
3. ¿Qué es el filtrado de paquetes?
3.1 Redes muy básicas
Todo el trafico de una red es mandado a través de paquetes. Por ejemplo, al descargarte este paquete (serán unos 50k) recibirás unos 36 paquetes de 1460 bytes cada uno (por decir un número al azar)
En el principio de cada paquete se dice a donde va, de donde viene, el tipo de paquete y otros detalles de administración. El principio del paquete se llama cabecera. El resto contiene los datos que están siendo transmitidos, que normalmente se llama cuerpo.
Algunos protocolos, como el TCP, el cual se usa para el trafico en la web, correo y logins remotos, utiliza el concepto de conexión ( antes de mandar el paquete se mandan varios de configuración, con unas cabeceras especiales, y las máquinas se comunican diciéndose, ‘ te has conectado’, ‘si’, ‘vale’, ‘gracias’. Los paquetes normales se mandan.
3.2 ¿Como se filtra un paquete?
Un filtrado de paquetes es un software que mira la cabecera de los paquetes para ver si deben pasar, decidiendolo al instante. Yo tengo que decidir entre denegar (deny) los paquetes, aceptarlos (accept ) u ignorarlo (reject) con lo que la maquina se olvida de él.
En Linux, el filtrado de paquetes se crea en el kernel (como un módulo por el momento) y hay pocas cosas que se pueden hacer con los paquetes, pero como principio debemos mirar las cabeceras y decidir el destino del paquete.
3.3 ¿Por que queremos filtrar paquetes?
Control. Seguridad. Vigilancia.
Control:
Cuando se esta usando Linux para conectar la máquina a otra red (como Internet) tienes la oportunidad de permitir ciertos tipos de trafico y de desactivar otros. Por ejemplo, la cabecera de un paquete permite la dirección del destinatario del paquete, así tu puedes prevenir que los paquetes vayan a cierta parte de la red. Otro ejemplo seria, cuando se accede con Netscape a los archivos Dilbert. Hay anuncios de doubleclick.net en la página y Netscape me hace perder el tiempo descargándolos. Diciéndole al filtrado que no permita los paquetes que pertenezcan a doubleclick.net resolveremos el problema (Hay mejores formas de hacer esto).
Seguridad:
Cuando tu máquina Linux es lo único entre el caos de Internet y el maravilloso orden de tu red, es bueno saber que tu puedes restringir el acceso a lo que llama a tu puerta. Por ejemplo, tu debes permitir cualquier cosa que salga fuera de tu red, pero debes tener cuidado con el conocido ‘Ping de la muerte’ que proviene de otras máquinas. Otro ejemplo seria, no permitir a la gente de fuera que hiciera telnet en tu máquina aunque tuvieran todas las cuentas y claves de tu máquina. Pero seguramente (como casi toda la gente) tu seras un observador y no un servidor. Simplemente no dejes nada conectado, mediante un reject a todos los paquetes que pidan activar una conexión.
Vigilancia:
Algunas veces una mala configuración de una máquina en una red local puede decidir devolver todos los paquetes al resto del mundo. Se debería decirle al filtro que nos avise cuando ocurra algo anormal. En este caso tu deberías hacer algo aunque sea por la natural curiosidad.
3.4 ¿Como hacer un filtrado de paquetes en Linux?
El kernel de Linux ha tenido filtrado de paquetes desde la versión 1.1. La primera versión estaba basada en ipfw de BSD, que fue portada por Alan Cox en 1994. Esto fue realizado por Jos Vos y otros para Linux 2.0; la utilidad ‘ipfwadm’ controlaba las reglas de filtrado del kernel. A mediados de 1988, para Linux 2.2, yo rehíce el kernel cuidadosamente con la ayuda de Michael Neuling, e introduje la herramienta ‘iptables’. Finalmente, la cuarta generración de herramientas, ‘iptables’, y otro kernel reescrito ocurrió a mediados de 199 para Linux 2.4. Esto es iptables , sobre el cual nos vamos a centrar en este HOWTO.
Para utilizarlo te hace falta un kernel que tenga la infraestructura de netfilter; netfilter es un framework general dentro del kernel de Linux, con otras cosas (como el modulo iptables) que se pueden meter. Esto significa que tu necesitas el kernel 2.3.15 y responder que si a la pregunta CONFIG_NETFILTER, en la configuración del kernel.
La herramienta de iptables le habla al kernel y le dice que paquetes tiene que filtrar. A no ser que seas programador o extremadamente curioso, es como controlaras el filtrado de paquetes.
iptables
La herramienta iptables inserta y borra reglas desde la tabla de filtrado de paquetes del kernel. Esto significa que si tu lo configuras, esta perderá al reiniciar la máquina; Mira Making Rules Permanent para saber que tienes que hacer si quieres guardar la configuración para la próxima vez que reinicies la máquina.
iptables reemplazo a ipfwadm y a ipchains. Mira Using ipchains and ipfwadm para aprender iptables sin miedo, si estas usando una de estas herramientas.
Crear reglas permanentes
Tu configuración actual del firewall esta almacenada en el kernel, y esto se pierde al reiniciar la máquina. Tengo en mi lista de cosas por hacer los comandos iptables-save e iptables-restore. Cuando lo haga sera guay, lo prometo.
Mientras tanto pon los comandos requeridos y las reglas en un scrpit que se inicien al arrancar la máquina. Comprueba que haces algo inteligente si uno de los comandos falla (normalmente ‘exec /sbin/sulogin’).
4. ¿Quién demonios eres, y que haces jugando con mi núcleo?
Soy Rusty; el mantenedor del Firewall IP de Linux y sólo otro buen programador que ha caído en el lugar adecuado en el momento adecuado. Escribí ipchains (ver ¿Cómo hago un filtrado de paquetes bajo Linux? para ver todas las personas que hicieron el trabajo actual), y aprendí lo suficiente acerca de filtrado de paquetes. Espero.
WatchGuard, una buena empresa de firewalls que vende el excelente plug-in de Firebox, me ofreció pagarme por no hacer nada, de forma que pudiera dedicarme a escribir esto y a mantener lo que ya había hecho anteriormente. Predije 6 meses, y llevó 12, pero al final, sentí que lo que había hecho estaba Bien. Muchas re-escrituras, un disco duro roto, un portátil robado, un par de sistemas de ficheros corruptos y posteriormente una pantalla rota, y aquí está el resultado.
Ya que estoy aquí, quiero aclarar ciertas cosas que la gente suele pensar: No soy un gurú del kernel. Sé esto porque mi trabajo con el kernel me llevó a contactar con varios de los gurús del kernel: David S. Miller, Alexey Kuznetsov, Andi Kleen, Alan Cox, ellos están ocupados haciendo la «magia oculta» del kernel, dejándome caminar por la zona poco profunda donde se está mas seguro.
5. Cómo pasan los paquetes por los filtros
El kernel empieza con tres listas de reglas, estas listas son llamadas firewall chains, o sólo chains. Las tres chains son INPUT, OUTPUT y FORWARD (Entrada, Salida y Reenvío)
¡Esto es muy diferente de cómo trabajaban los kernels 2.0 y 2.2 !
Para los fans del arte ASCII, las reglas se interpretan así:
_____
/ \
-->[Decisión]--->|REENVÍO|------->
[de ruteo] \_____/ ^
| |
v ____
_______ / \
/ \ |SALIDA|
|ENTRADA| \____/
\_______/ ^
| |
----> Proceso Local ----
Los tres «círculos» representan las tres chains mencionadas anteriormente. Cuando up paquete alcanza uno de los círculos del diagrama, se examina la chain para decidir el destino del paquete. Si la chain dice que se debe hacer un DROP del paquete, éste muere ahí, pero si se acepta el paquete, continúa a través del diagrama .
Una chain es una lista de reglas. Cada una de ellas dice «si la cabecera de un paquete se parece a esto, entonces esto es lo que se debe hacer con ese paquete». Si una regla no corresponde con el paquete, entonces la siguiente regla de la chain se examina. Finalmente, si no hay más reglas que consultar, el kernel mirará la política para decidir qué se debe hacer. En un sistema con una buena política de seguridad, la política normalmente será de hacer DROP del paquete.
Cuando un paquete llega (digamos, por la tarjeta Ethernet) el kernel mira el destino de dicho paquete, esto se llama «ruteo» o «enrutamiento».
Si está destinado a ese equipo, el paquete pasa a la chain de entrada. Si la pasa, cualquier proceso esperando el paquete lo recibirá.
De otro modo, si el kernel no tiene activado el reenvío, o si no sabe cómo reenviar el paquete, éste será ignorado (DROP). Si el reenvío está activado y el paquete está destinado para otro interface de red (si tienes otro), entonces el paquete irá al chain de reenvío (FORDWARD). Si es aceptado, se enviará fuera.
Finalmente, si un programa ejecutándose en el equipo puede enviar paquetes, éstos pasarán por la chain de salida (OUTPUT) inmediatamente. Si dice aceptar, entonces el paquete saldrá a donde quiera que estuviese destinado.
6. Utilizando iptables
iptables tiene una detallada página de manual (man iptables ), por si necesita información más concreta acerca de su uso. Aquellos que están que estén familiarizados con ipchains puede que
únicamente deseen mirar en Diferencias entre iptables e ipchains; ya que son muy similares
N.dT: Utilizaremos ‘chain’ en este documento por cuestiones de simplicidad, aunque deberemos entender ‘chain’ como un conjunto, grupo o encadenamiento de reglas de filtrado.
Hay varias cosas diferentes que puede hacer con iptables. Primero las operaciones para manejar chains en general. Se empieza con tres chains predefinidas de entrada, salida y reenvío que no se pueden eliminar.
Crear una nueva chain (-N)
Eliminar una chain vacía (-X)
Cambiar la política de una chain predefinida (-P)
Mostrar las chains (-L)
Vaciar las reglas de una chain (-F)
Poner a cero los contadores de paquetes y bytes en todas las reglas de una chain (-Z)
Hay varias formas de manipular las reglas dentro de un chain:
Append a new rule to a chain (-A).
Añadir una nueva regla a una chain (-A)
Insertar una nueva regla en la misma posición de una chain (-I)
Reemplazar una regla en la misma posición de una chain (-R)
Eliminar una regla en la misma posición de una chain (-D)
Eliminar la primera regla que coincida en una chain (-D)
6.1 Que verás cuando tu ordenador arranca
Por el momento (Linux 2.3.15), iptables es un módulo llamada `iptables.o’. Necesitarás añadirlo al kernel antes de poder usar el comando iptables. En un futuro, estará disponible dentro del kernel.
N.dT: En el momento de escribir esta traducción, el kernel (2.4.4) soporta iptables integrado en su código.
Antes de ejecutar cualquier comando iptables (ten cuidado: algunas distribuciones iniciarán iptables en sus scripts de inicio), ten en cuenta que no habrá reglas en las chains predefinidas. t (`INPUT’, `FORWARD’ y `OUTPUT’), las chains INPUT y OUTPUT tendrán una política de ACCEPT, y la de FORWARD tendrá una política de DROP (puedes cambiar esto mediante la opción `forward=1′ en el módulo iptables).
6.2 Operaciones con una regla simple
Esta es la base del filtrado de paquetes, la manipulación de reglas. Normalmente utilizarás los comandos de añadir (-A) y eliminar (-D), las otras (-I para insertar y -R para reemplazar) son extensiones de estos conceptos.
Cada regla especifica un conjunto de condiciones que un paquete debe cumplir, y lo que haremos si cumple dichas condiciones (efectuaremos una ‘acción’). Por ejemplo, puede que quieras hacer DROP de los paquetes ICMP provenientes de la dirección 127.0.0.1. En este caso definiremos el protocolo como ICMP, la dirección de origen como 127.0.0.1 y la acción será DROP.
127.0.0.1 es el interface ‘loopback’ que tendrá en su máquina incluso si no dispone de una conexión real a la red. Puede hacer un ‘ping’ para generar paquetes dichos paquetes (un ping simplemente envía paquetes ICMP del tipo 8 (petición de eco) que todos los hosts operativos deberán responder con un paquete ICMP de tipo 0 (respuesta del eco)). Esto hace ping muy útil para el testeo.
# ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes --- 127.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss #
Puedes ver aquí como funciona el ping (el parámetro ‘-c 1’ le indica a ping que envíe un único paquete).
Después añadimos (-A) a la chain ‘INPUT’ (de entrada) una regla especificando que los paquetes que vengan de 127.0.0.1 (-s 127.0.0.1) con el protocolo ICMP (-p icmp) deberán tomar la acción DROP (-j DROP)
Una vez hecho esto, probamos la regla con un segundo ping. El programa esperará una respuesta que nunca llegará Podemos eliminar esta regla de dos formas. La primera, ya que sabemos que es la única regla en la chain de entrada (input), podemos utilizar su número para borrarla:
# iptables -D INPUT 1
La segunda forma es igual a la del comando -A, pero sustituyendo -A por -D. Esto es útil cuando tiene varias reglas complejas y no quieres tener que contarlas hasta encontrar la que buscabas. Para estos casos usaremos:
# ipchains -D INPUT -s 127.0.0.1 -p icmp -j DROP
La sintaxis de -D debe ser exactamente igual a la de -A (o -I o -R). Si hay múltiples reglas iguales en la misma chain, sólo la primera será eliminada
6.3 Especificaciones de filtrado
Hemos visto el uso de `-p’ para especificar un protocolo, y `-s’ para especificar una dirección de origen, pero hay otras opciones mediante las cuales podemos definir otras opciones de los paquetes. Lo que viene a continuación es un compendio exhaustivo.
Especificando direcciones IP deOrigen y Destino
Las direcciones de Origen (`-s’, `–source’ o `–src’) y Destino (`-d’, `–destination’ o `–dst’) pueden ser especificadas de varias formas. La más común es usar el nombre completo, como `localhost’ o `www.linuxhq.com’. La segunda forma es es utilizando sus direcciones IP como `127.0.0.1′.
La tercera y cuarta forma permite especificar un grupo de direcciones IP, como `199.95.207.0/24′ o `199.95.207.0/255.255.255.0′. Ambas indican las direcciones IP desde 199.95.207.0 a 199.95.207.255; los número después de `/’ dicen las partes de la dirección IP significativas: `/32′ o `/255.255.255.255′ es lo normal (todas las direcciones IP de esa red). Para especificar cualquier dirección de internet podemos utilizar `/0′:
# ipchains -A input -s 0/0 -j DENY
#
Esto no se suele utilizar, ya que obtendríamos el mismo resultado sin especificar la opción de origen `-s’ .
Invirtiendo los filtros
Muchas opciones incluyendo `-s’ y `-d’ pueden tener sus argumentos precedidos de `!’ (pronunciado `not’) para que las direcciones que encajen sean las que no correspondan con la regla dada. Por ejemplo `-s ! localhost’ hará coincidir cualquier paquete que no venga de localhost.
Especificación del Protocolo
El protocolo puede ser especificado con el parámetro `-p’. Puede ser un número (Si conoces los valores numéricos del protocolo para IP) o el nombre para casos especiales como `TCP’, `UDP’ o `ICMP’. No se distingue entre mayúsculas y minúsculas.
El protocolo puede ser precedido de un `!’, para invertirlo, ej.: `-p ! TCP’.
Especificando un Interface
Las opciones `-i’ (or `–in-interface’) y`-o’ (or `–out-interface’) indican el nombre de un interface para una regla. Un interface es el dispositivo físico por el que los paquetes entran (`-i’) y salen (`-o’). Puede usar el comando ifconfig para mostrar una lista de los interfaces que están activados.
Los paquetes que atraviesan la chain INPUT no tendrán nunca un interface de salida, así que cualquiera regla -o en esta chain no tendrá validez. Igualmente, los paquetes que atraviesan la chain OUTPUT no tendrán nunca una interfaz de entrada, así que la regla -i no funcionará.
Sólo los paquetes que atraviesen la chain de FORWARD tendrán ambos interfaces (INPUT y OUTPUT).
Es perfectamente válido especificar un interface que no existe, la regla no coincidirá con ningún paquete hasta que se active dicho interfaz. Esto es muy útil para conexiones tipo PPP y similares.
Como un caso especial, un nombre de interfaz con el sufijo ‘+’ hará coincidir con todas los interfaces (existan o no) que empiezan por esa cadena. Por ejemplo, para indicar una regla que corresponda con todos los interfaces PPP, usaremos la opción -i ppp+.
El nombre del interface puede ser precedido por un ‘!’ para hacer coincidir los paquetes que no correspondan con el/los interfaz(es)especificado(s).
Especificando fragmentos
Aveces un paquete es demasiado grande para que pasen varios a la vez. Cuando esto sucede, el paquete se divide en fragmentos, y es enviado como múltiples paquetes. En el otro extremo se re-ensamblan y se reconstruye el paquete entero.
El problema con la fragmentación es que la cabecera IP es una parte del paquete. Buscar dentro de los paquetes las cabeceras de protocolo (como lo que hacen las extensiones TCP; UDP y ICMP) no es posible, ya que estas cabeceras están contenidas en el primer fragmento.
Si estás utilizando connection tracking o NAT, los fragmentos serán juntados antes de que alcancen el código de filtrado de paquetes, de forma que no hay que preocuparse de los fragmentos. De otra forma puedes cargar el módulo ‘ip_defrag.o’ que realizará la misma tarea. (Nota: esto sólo es posible si eres la única conexión entre las dos redes).
De cualquier forma, es importante comprender cómo los paquetes son tratados por las reglas de filtrado. Cualquier regla que pregunta por información que no tenemos, no coincidirá. Esto significa que el primer fragmento es tratado como cualquier otro paquete. El segundo y posteriores no. La regla -p TCP –sport www nunca coincidirá con un fragmento que no sea el primero. Tampoco la regla opuesta -p TCP –sport ! www.
Puedes también especificar una regla para todos los demás paquetes usando la opción ‘-f’ (o ‘–fragment’). También es posible indicar reglas que no correspondan con el segundo y posteriores fragmentos precediendo ‘-f’ con ‘!’.
Normalmente se considera seguro dejar pasar el segundo y posteriores paquetes ya que el filtrado afectará al primer fragmento y así se evita la reconstrucción en el host destino. De cualquier forma se conocen algunos bugs que permiten ‘tirar’ máquinas simplemente mediante el envío de
fragmentos. Tu decides.
Nota: Los paquetes mal formados (Los paquetes TCP, UDP e ICMP demasiado cortos para analizar el puerto, código ICMP y tipo) son ignorados (dropped) cuando dichos paquetes intentan llegar. Así que hay fragmentos TCP que comienzan en la posición 8.
Como ejemplo, la siguiente regla ignoraría todos los fragmentos con destino 192.168.1.1
# iptables -A OUTPUT -f -d 192.168.1.1 -j DROP #
Extensiones a iptables: Nuevas pruebas
iptables es extensible, lo que significa que tanto el kernel como iptables pueden ser ampliados para proporcionar nuevas características.
Algunas de esas extensiones son comunes, y otras más exóticas. Pueden estar programadas por otras personas y distribuidas de forma independiente.
Las extensiones del kernel, normalmente se encuentran en el subdirectorio de módulos del kernel, como /lib/modules/2.3.15/net/ . Actualmente (Linux 2.3.15) no hay carga de módulos bajo demanda, de forma que deberás insertar los que quieras a mano. En el futuro puede que sean cargados bajo demanda de nuevo.
Las ampliaciones a iptables son librerías compartidas que normalmente están en /usr/local/lib/iptables/, aunque alguna distribución pueda ponerlos en /lib/iptables o en /usr/lib/iptables.
Puede haber dos tipos de extensiones: nuevas acciones y nuevas pruebas (tests); hablaremos de las nuevas acciones más abajo. Algunos protocolos automáticamente ofrecen nuevas pruebas: actualmente TCP, UDP e ICMP como se muestra a continuación.
Para aquellos que queráis especificar nuevas pruebas, en la línea de comando después de la opcion `-p’ cargaremos la extensión. Para cargar nuevas pruebas explicita-mente, la opción `-m’ carga la extensión, después de lo cual las opciones extendidas estarán disponibles.
Para conseguir ayuda sobre extensiones, utiliza la opción de carga (`-p’ o `-m’) seguida por `-h’ o `–help’.
Extensiones TCP
Las extensiones TCP son cargadas automáticamente si se especifica `–protocol tcp’ y ninguna otra coincidencia más. Proporciona las siguientes opciones (ninguna coincidirá con fragmentos).
–tcp-flags
Seguidos de un opcional `!’, y dos cadenas de flags, permite filtrar flags específicas de TCP. La primera cadena de flags es la máscara: la lista de flags que quieres mirar. La segunda cadena de flags determinará cual(es) serán definidas. Por ejemplo,
# iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DENY
indicará que todas las flags sean examinadas (`ALL’ incluye `SYN,ACK,FIN,RST,URG,PSH’), pero sólo SYN y ACK serán definidas. También hay un argumento `NONE’ que indica ‘sin flags’.
–syn
Opcionalmente precedida de un `!’. Es un atajo para `–tcp-flags SYN,RST,ACK SYN’.
–source-port
Puede usar opcionalmente `!’, luego un puerto TCP o un rango de puertos. Los puertos pueden ser nombres listados en /etc/services o números. Los rangos son dos números de puertos separados por un `-‘, o un número de puerto con un guión (-) después para indicar todos los puertos desde el dado, o un guión seguido del número de puerto para indicar todos los puertos anteriores al puerto dado.
–sport
Es lo mismo que `–source-port’.
–destination-port
y
–dport
son lo mismo que los anteriores pero indicando el puerto de destino en lugar del de origen.
–tcp-option
seguido de un `!’ opcional y un número de puerto, hará coincidir todos los paquetes con una opción TCP igual al número indicado. Un paquete que no tenga una cabecera TCP completa será ignorado (dropped) automáticamente si intenta examinar las opciones TCP.
Explicación de las flags TCP
A veces es útil permitir las conexiones TCP en una dirección, pero no en la otra. Por ejemplo, puedes querer conexiones a un servidor WWW, pero no conexiones desde dicho servidor.
Una aproximación inocente sería bloquear los paquetes TCP provenientes del servidor. Desafortunadamente, las conexiones TCP necesitan que los paquetes viajen en ambas direcciones para funcionar correctamente.
La solución es bloquear sólo los paquetes de petición de conexión. Estos paquetes se llaman SYN (si, técnicamente hay paquetes con la flag SYN establecida y las FIN y ACK limpias, pero les llamaremos paquetes SYN para abreviar). Para des-habilitar estos paquetes, podemos parar las peticiones de conexión en su transcurso.
La flag `–syn’ se utiliza para esto. Sólo es válido para reglas que especifiquen TCP como protocolo. Por ejemplo, para especificar intentos de conexión TCP desde 192.168.1.1:
-p TCP -s 192.168.1.1 –syn
Esta flag puede ser invertida utilizando `!’, lo que significa que cada paquete que no sea un intento de iniciar la conexión.
Extensiones UDP
Estas extensiones son automáticamente cargadas si se especifica `–protocol udp’ y no hay ninguna otra coincidencia. Proporciona las opciones `–source-port’, `–sport’, `–destination-port’ y `–dport’ como se detalla para TCP más arriba.
Extensiones ICMP
Esta extensión es automáticamente cargada si se especifica `–protocol icmp’ y no hay ninguna otra coincidencia. Proporciona sólo una opción:
–icmp-type
Seguida de un opcional `!’ y un nombre de tipo ICMP (como host-unreachable), un tipo numérico (ej, ‘3’), o un tipo numérico y un código separado por una barra `/’ (ej, `3/3′). Una lista de los nombres de tipos ICMP puede conseguirse usando `-p icmp –help’
Otras Extensiones de coincidencia
Las otras dos extensiones en el paquete netfilter son extensiones de demostración, que (si están instaladas) pueden ser llamadas mediante la opción `-m’.
mac
Este módulo debe ser especificado explícita-mente con `-m mac’ o `–match mac’. Se utiliza para comparar paquetes de las direcciones de origen de Ethernet (MAC), y puede ser útil para los paquetes que pasen a través de las chains INPUT y OUTPUT. Proporciona sólo una opción:
–mac-source
se cuida de un `!’ opcional, luego la dirección Ethernet en notación hexadecimal separada por dos puntos (:). Ej `–mac-source 00:60:08:91:CC:B7′.
limit
Este módulo debe ser especificado explícita-mente con `-m limit’ o `–match limit’. Se usa para restringir el ratio de las coincidencias, por ejemplo para reducir mensajes de log. Sólo coincidirá un número dado de veces por segundo (por defecto 3 coincidencias por hora, con un burst de 5). Tiene dos argumentos opcionales:
–limit
seguido de un número; especifica el número medio máximo de coincidencias que se permitirán por segundos. El número puede ser especificado explícita-mente usando `/second’, `/minute’, `/hour’ o `/day’, o partes de ellos (de forma que `5/second’ es lo mismo que `5/s’).
–limit-burst
seguido de un número, indica el «burst» máximo antes de que el límite anterior entre en juego.
Esta coincidencia (match) puede ser utilizada casualmente con la acción LOG para hacer un log limitando el ratio. Para comprender como funciona, miremos la siguiente regla, que loggea paquetes con los parámetros por defecto del límite:
# iptables -A FORWARD -m limit -j LOG
La primera vez que llega a esta regla, el paquete será loggeado; de hecho, ya que el burst por defecto es de 5, serán los cinco primeros paquetes los loggeados. Después de esto, pasarán veinte minutos antes de que otro paquete sea loggeado por esta regla sin tener en cuenta cuantos paquetes la alcanzarán. También cada veinte minutos que sucedan sin coincidir un paquete, uno de los burst será recuperado; si no coinciden paquetes en 100 minutos, el burst será completamente recuperado; vuelta al comienzo.
No es posible crear una regla en la que se se especifique un tiempo de recarga mayor de 59 horas, así que si desea establecer un mayor ratio que uno al día, entonces el el ratio de burst deberá ser menor de 3.
unclean
Este módulo debe ser especificado explícita-mente con `-m unclean o `–match unclean’. Hace varios chequeos aleatorios de integridad en los paquetes. Este módulo no ha sido auditado y no debería ser usado como un dispositivo de seguridad (probablemente haga cosas mal ya que puede tener fallos en sí mismo). No proporciona ninguna opción.
6.4 Especificaciones de destino
Ahora que sabemos qué podemos examinar en un paquete, necesitamos una forma de decidir que hacer con los paquetes que coincidan con los tests. Esto recibe el nombre de acción de la regla (NdT: Traducimos target como acción en lugar de objetivo)
Hay dos acciones muy simples pre-compiladas: DROP y ACCEPT. Ya las conocemos. Si una regla coincide con un paquete y su acción es una de estas dos, no se consultarán más reglas: lo que pase con ese paquete ya está decidido.
Hay dos tipos de acciones a parte de las pre-compiladas: Las extensiones y las definidas por el usuario.
Reglas definidas por el usuario
Una poderosa característica de iptables heredada de ipchains es la capacidad para permitir al usuarios crear nuevas chains a parte de las tres pre-compiladas (INPUT, FORWARD and OUTPUT). Por convención, las chains definidas por el usuario son nombradas mediante minúsculas para distinguirlas entre ellas. (describiremos cómo crear nuevas reglas definidas por el usuario más abajo en operaciones on an Entire Chain ).
Cuando un paquete coincide con una regla cuya acción es una chain definida por el usuario, los paquetes comienzan a atravesar la regla en esa chain definida por el usuario. Si esta chain no decide el futuro del paquete , entonces una vez que el paso por esa chain se ha completado, una vez atravesada la regla continua en la siguiente regla de la chain.
Es hora de arte ASCII. Consideremos dos chains: INPUT (la chain predefinida) y test (una chain definida por el usuario)
`INPUT' `test'
---------------------------- ----------------------------
| Rule1: -p ICMP -j DROP | | Rule1: -s 192.168.1.1 |
|--------------------------| |--------------------------|
| Rule2: -p TCP -j test | | Rule2: -d 192.168.1.1 |
|--------------------------| ----------------------------
| Rule3: -p UDP -j DROP |
----------------------------
Considera un paquete TCP llegando desde 192.168.1.1 hasta 1.2.3.4. Si entra por la chain INPUT y el test con la regla 1 no coincide. La regla 2 coincide y su acción es test, así que la próxima regla a examinar es el principio de test. La regla 1 en test coincide pero no especifica una acción, así que la siguiente regla que se examina es la 2. Estas no coinciden, así que rechazamos la chain. Volvemos a la chain INPUT, donde habíamos examinado la regla 2, así que examinamos la regla 3, que tampoco coincide.
Así que el paquete es:
v __________________________
`INPUT' | / `test' v
------------------------|--/ -----------------------|----
| Rule1 | /| | Rule1 | |
|-----------------------|/-| |----------------------|---|
| Rule2 / | | Rule2 | |
|--------------------------| -----------------------v----
| Rule3 /--+___________________________/
------------------------|---
v
Las chains definidas por el usuario pueden saltar a otras chains definidas por el usuario (pero no se pueden hacer bucles: Los paquetes serán ignorados si se encuentran en un bucle)
Extensiones de iptables: Nuevas acciones
El otro tipo de acciones son una extensión. Una extensión de una acción es un módulo del kernel, y una extensión opcional de iptables permite una nueva opción de linea de comandos. Hay varios tipos de extensiones por defecto en la distribución de netfilter.
LOG
Este modulo ofrece al kernel poder logar los paquetes coincidentes. Esto ofrece opciones adicionales:
–log-level
seguido por el nombre o número de un nivel. Los nombres validos son ‘debug’, ‘info’, ‘notice’, ‘warning’, ‘err’, ‘crtl’, ‘alert’ y ‘emerg’, que corresponden a los números de 0 a 7. Mira la página man de syslog.conf para ver la explicación de estos niveles.
–log-prefix
Seguido de una cadena de caracteres de mas de 14 caracteres, El mensaje se manda al principio del log de mensajes, para permitir su identificación única.
Este módulo es el más utilizado después de un limite de acciones, así no tienes que inundar tus logs
REJECT
Este módulo tiene el mismo efecto que ‘DROP’, a no ser que se envíe un mensaje de error de ICMP ‘port unreachable’. Date cuenta que el mensaje de error de ICMP no se manda si (ver la RFC 1122)
· El paquete filtrado era un mensaje de error ICMP en primer lugar o un tipo de ICMP desconocido
· El paquete filtrado era un fragmento sin cabecera
· Se han mandado demasiados mensajes de error ICMP al destinatario recientemente.
Acciones especiales predefinidas
Hay dos acciones especiales predefinidas: RETURN y QUEUE
RETURN tiene el mismo efecto que desprenderse del final de la chain: para una chain predefinida, la política de la chain es ejecutarse. Para una regla definida por un usuario, se continuará con la anterior chain, justo antes de la regla que salto a esta chain.
QUEUE es una acción especial, la cual encola los paquetes para procesarla en el espacio del usuario. A no ser que haya algo esperando por el paquete ( por ejemplo que no haya sido escrito todavía), el paquete sera dropado.
6.5 Operaciones en una Chain completa
Una característica muy util de iptables es su capacidad de agrupar reglas dentro de una chain. Se puede llamar a estas chain como se quiera, pero es recomendable utilizar las letras minúsculas para evitar confusiones con las chain predefinidas y las acciones. Una chain puede tener una máximo de 16 caracteres.
Crear una nueva Chain
Vamos a crear una nueva chain. Como soy una persona con mucha imaginación, la vamos a llamar test. Usaremos la opción ‘-N’ o ‘–new-chain’:
# iptables -N test #
Es así de simple. Ahora puedes poner todas las reglas que quieras como hemos definido antes.
Borrar una Chain
Borrar una chain es muy simple, usando la opción ‘-X’ o ‘–delete-chain’. ¿Por que ‘-X’? Bueno, todas las adecuadas ya estaban usadas.
# iptables -X test #
Hay unas cuantas restricciones para borrar chains: Esta debe estar vacía (mira vaciar una Chain a continuación) y no puede ser una acción de una regla. No puedes borrar ninguna de la tres reglas predefinidas.
Si no especificas una chain, todas las chain definidas por el usuario se borraran, si es posible.
Vaciar una Chain
Hay una forma simple de vaciar todas las reglas de una chain, usando ‘-F’ (o ‘–flush’)
# ipchains -F forward #
Si no especificas una chain, entonces todas las chain serán vaciadas
Listando una chain
Se puede listar todas las reglas en una chain usando el comando ‘-L’
El ‘refcnt’ lista para cada chain definida por el usuario, el número de reglas que tiene cada chain y las acciones de esta. Esto debe ser cero ( y la chain estará vacía) antes de que la chain se pueda borrar.
Si se omite el nombre de la chain, se listarán todas las chain, menos las vacías.
Hay tres opciones que pueden acompañar a ‘-L’. La opción ‘-n’ (numérico) es muy usada para prevenir que iptables busque la la dirección IP, lo cual (en el caso de usar DNS como casi todo el mundo) causará largas esperas si tu DNS no esta configurado adecuadamente, o si se tiene definido un filtro la salida de peticiones del DNS. Esto causa que los puertos TCP y UDP imprimidos sean bastantes mas que los nombres.
La opción ‘-v’ muestra todos los detalles de las reglas , así como la cuenta de paquetes y bytes, la comparación TOS, y los interfaces. De otra forma estos valores serán omitidos.
Nota que los contadores de paquetes y bytes se imprimen usando los sufijos ‘K’,’M’ o ‘G’ para 1000, 1000000 y 100000000 respectivamente. Usando la flag ‘-x’ (expande números) imprime los números completos, no como son de grandes.
Reseteando (Zeroing) Contadores
Suele ser útil resetear los contadores. Esto se puede realizar la opción ‘-Z’ (o ‘–zero’).
El problema de realizar esta acción es que a veces necesitas saber el valor del contador inmediatamente después de resetearlo. En el anterior ejemplo, algunos paquetes pueden pasar entre los comandos ‘-L’ y ‘-Z’ . Por esta razón se puede usar ‘-L’ y ‘-Z’ a la vez , pasar resetear los contadores a la vez que los lees.
Seleccionando política
Estamos tocando muy por encima lo que ocurre cuando un paquete llega al final de una chain predefinida, cuando discutimos como un paquete atraviesa una regla rápidamente, la política de la chain determina el destino del paquete. Solo las chain predefinidas (INPUT, OUTPUT y FORDWARD) tienen políticas, por que si un paquete llega al final de una chain definida por el usuario, regresa a la chain anterior.
La política puede ser ACCEPT o DROP.
Usando ipchains y ipfwadm
Hay módulos en la distribución de netfilter llamados ichains.o y ipfwadm.o. Inserta uno de estos en tu kernel (NOTA: Hay incompatibilidades con iptables.o, ip_conntrack.o y ip_nat.o!). Entonces podrás usar ipchains o ipfwadm como en los buenos viejos tiempos.
Esto será soportado todavía por un tiempo. He pensado en una formula razonable que es 2* [noticia de cambio – primera versión estable],mas allá de la fecha en que una versión estable este lista.
El significado para ipfwadm, el final del soporte (Toma fecha reales):
2 * [Octubre 1997 (2.1.102 release) – Marzo 1995 (ipfwadm 1.0)]
+ Enero 1999 (2.2.0 release)
= Noviembre 2003.
El significado para ipchains, el final del soporte (Toma datos reales):
2 * [Agosto 1999 (2.3.15 release) – Octubre 1997 (2.2.0 release)]
+ Enero 2000 (2.3.0 release?)
= Septiembre 2003.
Así que no te debes preocupar hasta el 2004
7. Diferencias entre iptables e ipchains
Primero, los nombres de los chains predefinidos han sido cambiados de minúsculas a MAYÚSCULAS, ya que las chains INPUT y OUTPUT ahora sólo cogen paquetes con destino u origen local. Se usan para ver todos los paquetes de entrada y todos los de salida respectivamente.
El parámetro ‘-i’ ahora indica el interface de entrada, y sólo funciona con las chains INPUT y FORWARD. Las reglas en las chains OUTPUT y FORWARD que usaban ‘-i’ deben ser cambiadas a ‘-o’.
Los puertos TCP y UDP necesitan ser introducidos con las opciones –source-port o –sport (o –destination-port/–dport), y deben ser situadas después de las opciones`-p tcp’ o `-p udp’, ya que esto carga las extensiones TCP o UDP (puede que necesites insertar los módulos ipt_tcp and ipt_udp manualmente).
La opción ‘-y’ de TCP es ahora ‘–syn’, y debe ir después de `-p tcp’.
La acción DENY es ahora DROP
Se puede poner a cero una regla simple mientras trabaja
Poniendo a cero las chains predefinidas también se limpia los contadores de políticas.
Las chains de Listing da ahora los contadores individualmente.
REJECT y LOG son ahora acciones extendidas, lo que indica que están en diferentes módulos del kernel.
Los nombres de las chains pueden tener hasta 16 caracteres.
MASQ y REDIRECT no son ahora acciones. Hay un subsistema NAT para ello. Vea el HOWTO ipnatctl
Probablemente varias otras cosas que he olvidado.
Mas información