lunes, 28 de marzo de 2011

NAT/PAT con Iptables

En una anterior entrega discutimos sobre los posibles opciones y sus características a la hora de diseñar una red segura que ofreciese servicios web  a Internet. EL empleo de NAT (Network Adress Translation) es un elemento común a la hora de poner una red interna con direcciones privadas tras un router con salida hacia internet. Además suele ir acompañada de las redirecciones de puertos, conocido como PAT (Port Adress Translation).  Con ello logramos que las direcciones/puertos internos sean "transparentes" hacia afuera ya que al ser enrutadas se las "enmascara" con la IP pública. NAT es por ello considerado una medida de seguridad, pero no es suficiente y debe ser complementado con un firewall. Vamos a mostrar el funcionamiento de NAT/PAT con un ejemplo usando un servidor Linux e iptables

Un diseño común y sencillo de topología utilizando un sólo firewall y sacándole el máximo partido es el siguiente:


Tenemos un firewall con 3 interfaces o "patas" (three-legged firewall). Una dirigida hacia el router de salida a internet,  otra para la DMZ y una tercera para la LAN interna.

NOTA: Quizás lo más estricto si pensamos en la red 192.168.1.0/24 como DMZ es que  estuviera delante del FW, en el segmento 172.28.0.0/24 (y ahorrar un interfaz de red, eth2). En ese caso la DMZ estaría directamente expuesta a internet sin ningún tipo de filtrado y es una opción que aunque válida nunca acabó de convencerme. El caso que presento es un firewall con   zonas de seguridad donde podemos  colocar distintos niveles de filtrado de forma mas ordenada para la LAN y la DMZ.  Este diseño de 3 patas, dentro de las topologias más simples (de un solo firewall) es lo recomendable.

Partiendo  de este diseño veamos unas breves indicaciones de como se implementaría el firewall y como haríamos NAT/PAT.

Bien, lo primero es preparar el kernel de nuestra máquina Linux de modo que pueda actuar como router, para ello debemos fijar los parámetros del kernel :

Paso 1: Preparar el kernel para actuar como router

net.ipv4.ip_forward = 1--------------------------> Nos permite reenviar paquetes entre interfaces (eth0-->eth1<-->eht2)

Añadimos por seguridad:
net.ipv4.conf.default.rp_filter =1------> Activar la verificacion de la ruta origen, rechaza si la IP no corresponde con el segmento esperado del interfaz 

Paso 2: Limpieza de IPtables
Limpiaremos cuaquier rastro de reglas de firewall y establecemos políticas por defecto.

iptables -F
iptables -X
iptables -Z
iptables -t nat -F

Paso 3: Políticas por defecto
Tenemos 2 opciones: Bien dejar la política por defecto a ACCEPT e ir cerrando acceso o bien denegar por defecto e ir aceptando conexiones. La opción más cómoda es la primera pero, a efectos de asegurar todo bien es mejor adoptar la denegación por defecto aunque ello suponga mucho más trabajo al tener que ir  habilitando lo necesario para tener una comunicación fiable (ICMP, DNS, SYN, MAIL, puertos espcíficos...)

Politica permitir por defecto:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

O,

Politica denegar por defecto:


iptables -P INPUT  DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT


Paso 4: Escribir reglas del firewall.

Escojeremos la política de denegación por defecto al ser mas didáctica y  empezamos a filtrar...

Pero antes, aclaremos las nociones de reenvío y traducción de direcciones con NAT

Conceptos de NAT ( Network Adress Translation )

Reenvío  y enmascaramiento de la red interna

Para que los usuarios de la LAN puedan salir a Internet y obtener tráfico de vuelta, debemos establecer NAT ya que de lo contrario al regreso en el router WAN se encontraría con una dirección de destino 192.168.0.x que no sabría redirigirla al ser una red interna que desconoce.

Para ello enmascaramos la LAN y la DMZ:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 MASQUERADE   # (LAN)
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 MASQUERADE   # (DMZ)


Con ello decimos al firewall que cuando pase una direccion origen  de la LAN o la DMZ hacia el interfaz externo eth0 (172.28.0.254) la enmascare con esa dirección (NAT)

Ahora tenemos permitido el tráfico de la LAN y la DMZ  a internet, pero sin ningún tipo de filtrado y si la política es permisiva deberíamos filtrar las conexiones, de modo que se acepten solo si se originaron desde dentro.

Para la LAN una primera aproximación sería denegar las conexiones que no estuviesen originadas desde dentro, sustituyendo:

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
por
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED, ESTABLISHED -j ACCEPT

Así la conexión desde fuera entrará solo si previamente fue establecida o relacionada con un conexión desde dentro.

Traducción de direcciones de red con NAT


El uso de  NAT  permite a un firewall  modificar las direcciones de origen y destino de los paquetes así como  los puertos a los que van dirigidos.
Principalmente, encontramos 2 tipos de reglas NAT:
  1. Traducción de direcciones de red de destino: DNAT (cambiamos la IP destino del paquete)
  2. Traducción de direcciones de red de origen: SNAT (cambiamos la IP origen del paquete)
Con Iptables hay que recordar unas cuestiones muy simples pero importantes:
  • DNAT se utiliza con la cadena PREROUTING
  • SNAT se utiliza con la cadena POSTROUTING
  • Al modificar un paquete en el origen (SNAT) , la cadenas INPUT,FORWARD y OUTPUT ven la dirección de origen sin modificar
  • Si modificamos el paquete en destino  (DNAT) ,  las cadenas FORWARD e INPUT  ven la dirección modificada
Veremos algunos ejemplos de aplicación.

  1. Traducción de direcciones de red destino. DNAT. Acceso de clientes externos a servicios internos
Este tipo de traducción puede cumplir 3 objetivos:

A. Envío en representación transparente. Como si fuese un proxy transparente reverso
B. Reenvío a puertos .PAT
C. Balanceo de carga.

       A. DNAT como envío transparente
.
           Permite a los clientes usar una dirección interna "prestada", de ahí que digamos que es como un proxy            transparente. DNAT lo usaremos para ofrecer nuestros servicios a redes externas. 
Por ejemplo:
iptables -t nat -A PREROUTING -i eth0  -j DNAT --to-destination 192.168.1.50

Con esta regla redirigimos todas las peticiones y de cualquier puerto entrantes por eth0 a la máquina de la DMZ 192.168.1.50, es decir, traducimos(cambiamos) la dirección destino que recibimos (la del FW) por la de  la máquina destino interna que queremos reciba el paquete  . Ahora necesitamos PAT para filtrar el puerto

      B.  Reenvío a puertos. PAT

Por ej:
Filtramos un poco más para redirigir todo el tráfico entrante dirigido al puerto 80 al servidor web:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.1.50:80

Con esta regla, a todo paquete entrante se le cambia la IP destino y se manda a la IP y al puerto 80 del servidor web de la DMZ.

      C. Balanceo de carga

No es caso del ejemplo, pero imaginemos que tenemos 6 servidores Web (192.168.1.50 al 192.168.1.55) y queremos que las peticiones entrantes al puerto 80 se balanceen entre ellos:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.50-192.168.1.55

¿A que mola?

     2.  Traducción de direcciones de red de origen: SNAT.De clientes internos a servicios externos

SNAT es lo opuesto a DNAT, mientras que DNAT modifica las direcciones y puertos destino de los paquetes, SNAT lo hace con el origen de los mismos, es decir es la traducción de dentro hacia afuera. Observemos que con MASQUERADE ya hacíamos esto de forma generalizada para todos los hots, pero si queremos especificar debemos usar SNAT.

SNAT puede usarse para:
  • Comunicar con  máquinas internas que no tienen enrutado con otras redes o con internet
  • Permitir que varios hosts de la red interna compartan una dirección de salida.
  • Ocultar la verdadera IP de una máquina.
  • Resolver problemas que pueden surgir con DNAT.
 Como vemos hace justamente el inverso a DNAT. Si DNAT se ocupaba de los accesos de clientes externos a servicios internos, con SNAT damos comunicación desde clientes internos a servicios externos, traduciendo direcciones en origen en lugar de en destino. Podemos entender SNAT como proxy (transparente) y DNAT como  reverso.

Recordemos, siempre:

                  DNAT:                                                                                       SNAT:
cadena PREROUTING                                                        cadena POSTROUTING
-i interfaz                                                                              -o interfaz
modificar puertos y direcciones de destino:                        modificar puertos y direcciones  de origen:
-d , --dport y -to-destination                                               -s, --sport, --to-source

Ejemplo:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 172.28.0.254

Esta regla proporciona SNAT para toda la red LAN interna traduciendo la dirección origen (192.168.0.x)  a 172.28.0.254, que será la que vean los hosts con los que comunica. Esta regla es equivalente a MASQUERADE ya que no especificamos ningún host/puerto y damos salida a toda la red.

Si solo quiséramos que un host (92.168.0.25) saliera a internet (puerto 80), la regla a aplicar sería:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.25 -p tcp --dport 80  -j SNAT --to-source 172.28.0.254

Si queremos dar salida a todos los hosts y hay mucho tráfico puede que nos quedemos sin puertos si solo estamos dando una dirección de salida. Podemos hacer NAT permitiendo varias:

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 172.28.0.250-172.28.254

Con esto nos hemos hecho una idea del uso de iptables para hacer NAT/PAT.
Estas reglas habría que ir complementándolas con más reglas para conseguir un filtrado y control eficaz del flujo de tráfico entre nuestra red e internet.
Por ejemplo el control de la salida hacia internet de los usuarios de la LAN, el control de las conexiones entre la DMZ y la LAN (por ejemplo, consultas hacia la BBDD desde el servidor Web), etc

Otro día profundizaremos un poco más y  añadiremos más reglas para formar un firewall completo

Ver tambien:

1 comentario: