Netfilter / IPTables II

Antes de comenzar te recomiendo que también visites lo siguientes posts ( NetFilter / IPTables  I, III, IV, V)

NetFilter y las cadenas de Adromeda

En este artículo haremos un repaso sobre el sistema de manejo de cadenas dentro de una tabla de iptables. Esto nos dara una poderosa herramienta para idear nuestro propio script de firewall.

Repasando

En el articulo anterior vimos el manejo de netfilter atravez de iptables.
Vimos que existen cuatro tablas: filter, raw, nat, y mangle.
Vimos que dentro de filter, existen 3 cadenas: INPUT, OUTPUT, y FORWARD.

Y vimos que podemos ingresar reglas en una cadena en particular usando “-A” ó “-I”.

Hagamos un ejemplo primero que nada para poder creer:

#!/bin/bash
alias iptables=’/sbin/iptables’

iptables -t filter -F #Borra todas las reglas de las cadenas de la tabla filter
iptables -t filter -Z #Borra los contadores de la tabla filter
iptables -t filter -X #Borra las cadenas definidas por el usuario

iptables -t nat -F #Adivinen….
iptables -t nat -Z
iptables -t nat -X

#Establecemos las políticas por defecto en reject
#Apartir de ingresar estas reglas nuestra maquina queda completamente aislada
iptables -P INPUT REJECT
iptables -P OUTPUT REJECT
iptables -P FORWARD REJECT
#En linux el la mayoria de las aplicaciones funcionan con el paradigma de cliente-servidor
#lo que involucra en muchos casos usar la interfaz de loopback, por lo que la desbloquearemos
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -i lo -j ACCEPT
#Habilitamos el SSH solo para la red interna (lo que además deberíamos hacerlo desde el sshd_config)
iptables -A INPUT -s 192.168.4.0/24 -i eth0 -d 192.168.4.1 -p tcp –dport 22 -j ACCEPT
#Aunque paresca redundante especificar algunas cosas. Por ejemplo -i eth0, si se supone que solo esa
#esa interfaz tiene una direccion en ese rango, sin embargo, estamos evitando posibles ataques
#de spoofing

iptables -A OUTPUT -d 192.168.4.0/24 -i eth0 -p tcp –sport 22 -j ACCEPT

#Como establecimos anteriormente las políticas cerradas por defecto, debemos habilitar a los paquetes,
#tanto a entrar como a salir, por eso la regla anterior.

#Habilitamos las consultas a los servidores dns
servidor_dns=”200.200.200.20x” #Variable que contiene el servidor dns (/etc/resolv.conf)
iptables -A INPUT -p udp -sport 53 -s $servidor_dns –dport 1024:65535 -j ACCEPT
iptables -A OUTPUT -p udp -dport 53 -d $servidor_dns –sport 1024:65535 -j ACCEPT
#Como vemos, nuevamente, habilitamos el ingreso y el egreso.
#Es importante tener en cuenta, que las consultas dns se hacen desde nuestro host,
#al puerto 53 del servidor dns (en este caso $servidor_dns) y se hacen desde los puertos 1024 al 65535.
#y obviamente la respuesta, la recivimos desde el puerto 53 al puerto desde el cual fue hecha la consulta

#Habilitamos el ICMP
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
#Existen distintas posturas en cuanto al icmp (si habilitarlo o no, y para donde) pero lo cierto, es que,
#la idea ahora es aprender iptables y no discutir las distintas escuelas de firewalling

# Y habilitamos NAT, es decir el ruteo a travez de nuestro servidor
echo 1 > /proc/sys/net/ipv4/ip_forward
#Esto habilita al kernel a reenviar los paquetes que vienen con intención de ser routeados

#Habilitamos mediante firewall al rango de la lan interna para ser reenviados
iptables -A FORWARD -s 192.168.4.0/24 -i eth0 -d 0.0.0.0/0 -j ACCEPT
# y luego habilitamos el nat
iptables -t nat -A POSTROUTING -s 192.168.4.0/24 -i eth0 -d 0.0.0.0/0 -j MASQUERADE
#Quizas esta regla no la entiendas del todo, pero lo que dice es que a todos los paquetes que son
#routeados, los envie con la direccion ip publica del servidor, y ademas guarda una tabla
#con las conexion que son nateadas, para que cuando lleguen las reenvie al host correspondiente

De aquí podemos empezar a comprender de forma un poco mas práctica como trabaja NetFilter.
Con un poco de trabajo, y aplicando lo que ya vimos podrías armar un firewall funcional y podría ser muy bueno, si aplicas tus conocimientos de scripting, sin embargo, no estarías utilizando todo el potencial de NetFilter.

Comentamos ya, en el artículo anterior, que podemos crear nuestras propias cadenas, y que esto brindaba una mayor flexibilidad a nuestro firewall.
Veamos exactamente de que estamos hablando…

Las cadenas hechas de reglas para las tablas!!!

Para visualizar de forma simple lo que queremos ver, vamos a suponer, que simplemente, tenemos un host especial, el cual, queremos tratar de forma única. Podemos suponer, que sera un host desde el cual controlaremos el servidor, o bien un host destinado a cierto tipo de testeo, en cualquier caso, lo importante sera, que este host en particular va a tener un tratamiento especial.

Siguiendo el metodo del script anterior, tendríamos que ingresar varias reglas para darle un tratamiento especial en cuanto a los puertos habilitados, y eso no seria demasiado complicado, sin embargo, si tubieramos varios tipos de host especiales, quizas se complicaría un poco.
Vuelvo a aclarar, que el escenario que estoy proponiendo es solo uno de los ejemplos posibles.

Definimos entonces a 204.34.33.3x como a la cual, queremos darle un tratamiento especial
Vamos a meter un poco de mano, para que se vea más:

#!/bin/bash
alias iptables=’/sbin/iptables’

#omito la seccion del flush para acortar
iptables -P INPUT REJECT
iptables -P OUTPUT REJECT
iptables -P FORWARD REJECT

#imaginemos que tenemos las mismas reglas que antes…
iptables -N tratamiento_especial
#Hemos creado una cadena nueva, y podemos verla, invocando el siguiente conjuro: iptables -L -n
#ó bien iptables -L tratamiento_especial

#Como queremos tratar de forma especial a este host, haremos que antes de aplicar
#alguna regla, verifiquemos si el paquete proviene de 204.34.33.3x
#para lo cual insertaremos la regla arriba de todas para que sea la primera en comparar
iptables -I INPUT -s 204.34.33.3x -j tratamiento_especial
#Recordemos que “-I” sin ningún numero, inserta la regla por ensima de las demas regla de la cadena
#Por lo que lisa y llanamente, todo lo que provenga de 204.34.33.3x, se comparará con
#las reglas de la cadena tratamiento_especial
#De la misma manera que agregamos (-A) reglas a las cadenas INPUT ó OUTPUT ó bien FORWARD
#podemos agregar reglas a las cadenas que creemos nosotros
iptables -A tratamiento_especial -p tcp –dport 1:1023 -j ACCEPT
iptables -A tratamiento_especial -p udp –dport 1:1023 -j ACCEPT

Bien, te recomiendo que hagas un iptables -L -n, para ver como las reglas se insertan una tras otra en la cadena tratamiento_especial, además podes insertar una regla a mano (desde la consola) con la opción “-I” y ver como se posiciona en el primer lugar.

Lo que sucederá aquí, es lo siguiente:
#A todos los paquetes que ingresen (no destinados a ser routeados) ( INPUT )
Si el paquete proviene de la ip 204.34.33.3x saltamos a la tabla de tratamiento_especial
SI la interfaz es “lo”, es aceptado
Si el paquete proviene de la red 192.168.4.0/24 y viene hacia el puerto 22 tcp a travez de la interfaz eth0, es aceptado
Si el paquete es udp y proviene del puerto 53 del servidor DNS y tiene como destino un puerto entre
el 1024 y el 65535, es aceptado
Si no cumple con ninguna la politíca es REJECTarlo

Por lo cual, cualquier paquete que ingrese al host, verificará si se cumple la primer regla, si se cumple,
automaticamente pasará a comprobar las reglas establecidas en tratamiento especial, y estas indican que:
Si es un paquete tcp entre el puerto 1024 y el 65535, es aceptado
Si es un paquete udp entre el puerto 1024 y el 65535, es aceptado

Si el paquete no proviene del host 204.34.33.3x, entonces seguira las comprobaciones (si proviene de la interfaz lo, si proviene de 192.168.4.0/24.. etc)

Ahora bien, si suponemos que ingresa un paquete icmp proveniente del paquete 204.34.33.3x, este ingresará en la tabla de tratamiento especial, pero no coincidirá con ninguna de las reglas allí establecidas… que pasará?
Se aplica la politica por defecto de rechazarlo?
Se aplica continua con las comprobaciones de la cadena INPUT?

La respuesta a la primera pregunta es NO
Simplemente por que las cadenas creadas personalmente no tienen politica, para ver esto, pueden ejecutar,
el conocido comando de listado iptables -L ó bien iptables -L tratamiento_especial. Donde podemos diferenciar de las cadenas pre establecidas que no existe una política (Policy)
La respuesta a la siguiente pregunta es SI,
si el paquete fuera icmp, ‘cruzaría’ la tabla tratamiento_especial y seguiría nuevamente por las reglas de la cadena INPUT, donde llegaria hasta la regla que dice que si el paquete es icmp, sin importar de donde venga o vaya, es aceptado.
Sin embargo, si esto no es lo que Uds esperaban, no se preocupen, por que se puede arreglar.
Como habran visto, cada vez que mandamos un paquete hacia un objetivo (“-j ACCEPT, o -j tratamiento_especial)
usamos la opción “-j”, que viene de “jump”, saltar.
Pero existe otra opción, similar a sentencias de los lenguajes de programación modulares, y esta es “-g” ó “–goto”.
Si usaramos:
iptables -I INPUT -s 204.34.33.3x -g tratamiento_especial
en lugar de
iptables -I INPUT -s 204.34.33.3x -j tratamiento_especial
En tonces, el paquete icmp, que no queda atrapado en ninguna regla de la cadena tratamiento_especial, simplemente, se le aplica la politica por defecto de INPUT.

Antes de terminar, hagamos unas pruebas para que todo esto sea verdaderamente comprobable y ya no creas mas por fe, si no antes bien, que prácticamente lo palpes.

Haremos pruebas con una herramienta muy util y ancestral… el ping.

#!/bin/bash
iptables -P INPUT DROP #Por política rechazo todo
iptables -A INPUT -i lo -j ACCEPT #acepto todo lo que pase por la interfaz de loopback
iptables -A INPUT -p tcp -j ACCEPT #acepto todo lo que sea tcp
iptables -A INPUT -p udp -j ACCEPT #acepto todo lo que sea udp
#Es decir que lo unico que queda bloqueado es el imcp

iptables -N tratamiento_icmp #creamos la cadena tratamiento_icmp
iptables -A tratamiento_icmp -i lo -j ACCEPT #ingresamos una regla a la cadena que acepta
#todo lo que ingresa por la interfaz loopback

iptables -I INPUT -p icmp -g tratamiento_icmp
#Ingresamos una regla en INPUT para que todo lo que sea ICMP lo envie a la cadena tratamiento_icmp
#hubiese sido lo mismo, definir la cadena tratamiento_icmp primero, y luego usar
# iptables -A INPUT -p icmp -g tratamiento_icmp

Ahora bien, con este script, podemos modificar la opcion -g por -j para probar los distintos funcionamientos
La primera prueba seria, correr el script así solito, y usar el comando: ping localhost, y como todo lo que sea icmp que venga por la interfaz “lo”, sera enviado (con –goto) a la cadena tratamiento_icmp, el ping responderá , ya que queda atrapado en la primera (y única) regla de la cadena, la cual acepta el icmp.

Ahora es cuestion que uses tu imaginación y observes si los cambios que haces en el script son los esperados o no, hasta que tu mente comienze ver iptables como el mejor amigo de un segu-geek!

Hay mas pruebas, pero la idea no es darte todo masticado…
Si se te ocurre algun aporte o algo te parece confuso comentamelo.
Hasta el proximo!!!

NetFilter / IPTables I

Antes de comenzar te recomiendo que también visites lo siguientes posts ( NetFilter / IPTables  II, III, IV, V)

NetFilter el grande

Los firewalls, son una parte fundamental de la seguridad, en los sistemas operativos de hoy en día, ya que las redes son parte fundamental de los sistemas computacionales.
En este caso revisaremos el caso de uno de los mejores firewalls por software existentes: NetFilter
NetFilter, es el sistema de filtrado de paquetes de los Kernels Linux de la rama 2.4 y 2.6, y para mucha mas info, podes pasar por www.netfilter.org

Por que escribir un artículo mas sobre iptables?
Simplemente por que no encontré alguno que lo explique como a mi me hubiese gustado.
Otra razón, es por que uno termina aprendiendo mucho mas.
Para una guia mas rápida, con muchos ejemplos recomiendo el artículo de bulma

Este sistema está basado en el manejos de tablas, el cual se administra desde la aplicación iptables.
Esta aplicación configura todas las reglas de filtrado, pero no es en si mismo el firewall, esto es importante de destacar, ya que no tenemos un proceso corriendo para administrar los paquetes, si no que iptables administra las reglas que el kernel maneja. Así, no corremos el peligro de que el programa si cuelgue o contenga un bug y termine por ser una puerta trasera, en lugar de ser una protección.
Es cierto que nada es perfecto, si embargo hasta el momento, no he escuchado de ninguna vulnerabilidad que haya puesto en vilo la seguridad de los servidores protegidos con Netfilter.
Vale recalcar, que Netfilter pertenece a la lista de 100 herramientas de seguridad mas importantes según Insecure.org.

Comencemos:

Decíamos que iptables maneja las tablas de filtrado del kernel, y, cada tabla contiene una serie de instrucciones condicionales (reglas).
Un ejemplo sería:

Tabla_1
Si proviene del puerto 2934 con destino al puerto 80 aceptar
Si proviene de la ip 200.32.xxx.xxx rechazar
Si proviene de la ip 201.9.xxx.xxx rechazar

Cuando comparamos un paquete (de red) con esta tabla, lo haremos hasta encontrar la primer coincidencia, y dejaremos comparar.

Si para este ejemplo enviamos un paquete proveniente del puerto 2000, desde la ip 200.32.xxx.xxx (la misma del ejemplo), compararía regla por regla de la siguiente forma:

Si proviene del puerto 2934 con destino al puerto 80 aceptar = Falso / no cumple
Si proviene de la ip 200.32.xxx.xxx rechazar = Verdadero
Fin de comprobaciones

Lo que aca vemos, es que al no cumplir con la primer regla de la tabla, prosigue con la siguiente, y asi seguiría mientras no cumpla con ninguna regla (de forma completa). En este ejemplo, cumple todas las condiciones de la segunda regla, por lo cual, no comprueba la tercera y rechaza el paquete.
Podemos deducir, que es de suma importancia el orden en el cual colocaremos las reglas ya que, si colocamos reglas muy generales al principio, se parará la comparación en esa regla y quizas no filtremos como lo deseamos.

Esta forma de filtrado nos permitirá (por lo contrario de lo que suele parecer al principio) mucha flexibilidad.

Veamos un poco mas:

Cada tabla, no es solo una lista de instrucciones a revisar, si no que cada tabla tiene ‘Cadenas’, algunas predefinidas, y otras a definir por el usuario. Para aclarar, podemos decir, que las reglas se listan en cadenas, las cuales, se agrupan dentro de las tablas.
TABLA_1
Cadena_1
Regla_1
Regla_2
Regla_3
…
Regla_x
Cadena_2
Regla_1
….

Pero antes de ver mas teoría de esto, empecemos a visualizar y toquetear un poco.

Como dijimos netfilter se maneja mediante tablas, y estas son manejadas por iptables, ergo, para configurar las tablas y cadenas de nuestro firewall usaremos este poderoso comando.

Ejemplo 1
#iptables -t filter -L

Si no tienes configurado, ningún script para iptables, veras lo siguiente:

Ejemplo 2

Chain INPUT (policy ACCEPT)

target     prot opt source      destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Analizando todo

Usamos iptables con la opcion “-t filter”. La opción -t nos permite seleccionar una tabla en particular. En este caso “filter”, es la tabla mas común, o principal, ya que es por donde pasan todos los paquetes, sin embargo, existen otras, y estas son: raw, mangle,  y nat.

Si son curiosos y no se aguantan, pueden hacer un man iptables y seguir investigando mas.

La opcion -L, permite listar una cadena particular o bien lista todas las existentes en la tabla, como lo hicimos en este caso. Por lo que vemos que dentro de la tabla, existen tres cadenas: INPUT, FOWARD y OUTPUT.

Cada una de estas cadenas, tienen una política por defecto, lo que significa, que si el paquete comparado, con una cadena, no coincide con ninguna regla, se aplica la política de la cadena. En el ejemplo anterior, podemos ver que en cada cadena aparece “(policy ACCEPT)”, por lo cual, como decíamos, si un paquete no coincide con ninguna regla de la cadena, se ACCEPTa (je).

Para establecer otra política por defecto usamos “-P”:

#iptables -t filter -P INPUT REJECT

De esta manera, por ejemplo, indicamos a netfiltes, que REJECTe (jeje) por defecto todo lo que entre (INPUT) al host. Luego deberiamos ingresar reglas en la cadena INPUT, para que deje pasar ciertas cosas o no tendríamos conexión con nada! (lo vemos mas adelante)

- Todavía no me mostraste como modificar nada y eso es aburrido!

Ok, si te gusta la acción podes experimentar con esta regla y de paso tratar de deducirla antes de seguir leyendo:

iptables -t filter -A INPUT  -p tcp --source-port 2934 --destination-port 80 -j ACCEPT

Como ya vimos, -t filter, sirve para seleccionar con que tabla que trabajaremos, en este caso, al ser la tabla filter, la tabla por defecto, podemos obviarla y usar “iptables -A INPUT –source-p….”.

Lo siguiente que vemos, “-A INPUT” sirve para ingresar una regla en una cadena, en este caso “INPUT”.  Por defecto, todo lo que entra al host (con destino al host). Así mismo, todo lo que sale del host (con cualquier destino, pasa por la cadena OUTPUT), y todo lo que ingresa al host con destino de ser reenviado, se compara con la cadena FORWARD.
En el ejemplo usamos “-A”, esta opción ingresa una regla al final de las reglas de la cadena, pero como pudimos ver, es muy importante el orden en que se introducen las reglas, ya que, cuando encuentra la primera coincidencia, dejará de comparar. Existe otra opción, “-I” con la cual, la regla se inserta en la primer posición de la cadena.
Pero además iptables nos permite ingresar las reglas por número de orden, sin embargo, para eso podes remitirte al man de iptables.
Las siguientes opciones son faciles de deducir:

-p tcp : Coincide si el paquete es un paquete TCP
–source-port : Coincide si el puerto de origen del paquete es 2934
–destination-port : Coincide si el puerto de destino es 80

y finalmente, “-j” establece el objetivo, es decir, que es lo que se hará con el paquete si coincide con dicha regla, las opciones predefinidas, son : ACCEPT (Aceptar el paquete) REJECT (Rechaza el paquete enviando un mensaje ICMP de que fue rechazado), DROP (obvia el paquete, es decir, lo rechaza sin avisar de que lo rechazó).
Existen otros objetivos predefinidos, pero por ahora conviene ver solo estos.
Además de las opciones predefinidas, se pueden poner como objetivos una cadena de la misma tabla.

Muy bien, estas son las cuestiones básicas de iptables, solo nos falta ver otras opciones que podemos ingresar en una regla, para poder empezar a tirar unas lineas y comprender varios scripts de iptables que andan dando vuelta.

Pequeño Laurouse Ilustrado de Iptables:

–source : Dirección de origen (ip o rango de red)
–destination : Destino del paquete (ip o rango de red)
–in-interface : Interface de red por donde ingresa el paquete (eth1, wlan0 …)
–out-interface : Interface por donde sale el paquete (lo mismo eth1, wlan0…)
–fragment : Aplica la regla a los fragmentos sucesivos al primero
y las opciones q vimos antes:
–protocol : Protocolo con el que debe coincidir la regla, puede ser tcp, udp, icmp o all
–source-port : Coincide si el puerto de origen del paquete es el indicado
–destination-port : Coincide si el puerto de destino es el indicado

A todas estas opciones se les puede agregar un ! para indicar lo contrario, por ejemplo si usamos “-p ! tcp”, estamos indicando todos los protocolos que no sean tcp, o si indicamos “-s ! 10.0.0.0/24″, la regla coincide solo si el paquete no proviene de la red 10.0.0.0/24.

Ahora si ya podemos escribir algunas lineas concienzudamente:
Pongamos un ejemplo común: un servidor web, el cual queres manejar remotamente mediante ssh desde una ip en particular, y acceso a ftp desde la red interna.

Si es un servidor web, debemos dejar el puerto 80 abierto
Si queremos dejar el servidor ssh para la administración habilitamos el puerto 22 para nuestra ip
y para el ftp habilitamos el puerto 21

Lo más común es establecer un política por defecto cerrada y abrir lo que haga falta:

iptables -P INPUT REJECT
iptables -A INPUT -p tcp -s 0.0.0.0/0 -dport 80 -j ACCEPT
iptables -A INPUT -p tcp -s 204.54.45.x -dport 22 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.6.0/24 -dport 21 -i eth1 -j ACCEPT

Primero habrán observado, que no uso “-t filter” , y es que como dije antes, la tabla “filter” es la tabla por defecto, y se puede obviar. Así mismo, uso -dport en lugar de –destination-port, y es por que esta es la opción recortada de la misma.

Bueno, aunque hay pocas cosas prácticas, suficiente por hoy, espero que les sirva.

/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */