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:

jueves, 17 de marzo de 2011

Aplicaciones Web. Seguridad de Red (II de II): Ejemplo



Seguridad en el diseño de Red

Los reglas a la hora de establecer la seguridad de una red serán:

  • División en capas 
Estableciendo varios niveles de filtrado aseguramos que en caso de fallar una de ellas exista otro punto de control. Además dividimos áreas en función a su riesgo
  • Diversificación
Distintos puntos de defensa --Implementar medidas defensivas como antivirus, firewall, autenticación en múltiples ubicaciones tales como servidores, estaciones de trabajo, switches..

Distintas medidas -- Uso de distintas tecnologías y fabricantes evitará que una vulnerabilidad afecte a todos los recursos

  • Zonas de Seguridad

Identificar las distintas zonas en función a su nivel de exposición y riesgo potencial.
Segmentando la con red, vlans, firewalls tendremos un cerco mas controlable y restringido.

Zona DMZ: Ubicarán sistemas y servicios para proporcionar a redes externas y será la zona más expuesta.Pueden crearse varias DMZ para evitar que un ataque DoS afecte a todos los servicios.
                   Ej: DMZ1---Servidor Web. DMZ2---Mail, DNS

Zonas de Seguridad para Recursos Internos:

            Zona de estaciones de trabajo
            Zona de Servidores internos: BBDD, Backups
            Zonas diferenciadas para entornos de desarrollo y pruebas
            Zona para el control de la seguridad y monitorización
            Zona de seguridad para sistemas sinconfianza como accesos wifi o acceso a servidores  externos



  • Sistemas de Detección/Prevención de Intrusiones IDS/IPS

Su localización es crucial.
Posicionar en el camino entre las poteciales entradas de amenazas y los recursos

  • Proxys
Las zonas internas no deben tener acceso directo a internet , mediatizarse a través de un proxy y controlar el tráfico con un IDS o IPS. Especial control para HTTP/S, SMTP, IMAP, POP3..
Fig 1. Seguridad en el diseño de red

Finalmente, recomiendo visitar el enlace al US-CERT donde exponen recomendaciones sobre el diseño de arquitectura de red. Diseño seguro de Arquitectura de Red


domingo, 13 de marzo de 2011

Aplicaciones Web. Securidad de Red (I de II): Capas y componentes de seguridad

En esta primera entrega discutiremos como organizar la seguridad de aplicaciones web a nivel de diseño de red. Posteriormente en la segunda entrega veremos un ejemplo.

Organización lógica y física. Modelo de capas


Capas de acceso lógico

La mayor parte de las aplicaciones Web basan su interfaz con el cliente en el protocolo HTTP o HTTPs. Este interfaz va a interaccionar para establecer el flujo de datos entre el cliente,  la aplicación y los datos. El objetivo es securizar ese flujo de modo que, tanto la aplicación como los datos estén  siempre bajo el control del lado servidor. Lo ideal es establecer una división lógica en capas:  interfaz<-->aplicación<-->datos.
Fig. 1 Capas lógicas
Capas de acceso físico

Una vez identificadas las zonas lógicas el siguiente paso es segmentarlas en distintas zonas de red y ubicaciones físicas. Así, tendríamos un servidor web como interface, un servidor de aplicaciones y una base de datos:

Fig 2. Capas fisicas de red


Zonas de seguridad

Hay que considerar 3 grandes  zonas:

  • Zona Internet (WAN)
  • Zona DMz : Zona de la red perteneciente al lado servidor y que es accesible directamente desde internet. . Su objetivo es establecer una frontera común entre internet y la red interna (DMZ externa) o entre distintas áreas de la red interna (DMz interna)
  • Zona Intranet. Es transparente, protegida e inaccesible al usuario de internet
Para lograr segmentar y conformar estas zonas nos apoyaremos en dispositivos tanto hardware como software:

  • Firewall, routers, switches
  • Servidores
  • IDS / IPS (Intrusion Detection/Prevention Sytems)
  • Honey Pots (sistemas que actúan como señuelo para engañar al atacante)
  • Accesos inalámbricos
  • Sistemas de alertas y monitorización, etc
Pasos en el diseño de red

  1. Política de Seguridad: 
    • Fijar el alcance , los activos a proteger, identificar amenazas y riesgos.
    • Seleccionar los controles y las medidas a tomar
     
  2. Clasificar las zonas de seguridad y su nivel de protección
  3. Selección de dispositivos de red apropiados: routers, switches
  4. Firewalls para segmentar las zonas de seguridad
    • Interconexión de los distintos sectores de seguridad. Control de paquetes
    • Control de acceso entre los sectores
    • Propiedades añadidas: Balanceo de carga, VPN, NAT.... 
  5. Servicios adicionales: IDS/IPS, VPNs
Sistemas de deteccion / prevención de intrusos

Su misión es inspeccionar el tráfico de red para prevenir intrusos
Pueden estar basados en software o en hardware y ubicarse para controlar un host HIDS (HostIDSo un segmento de red NIDS (NetworkIDS)
Un Sistema de Prevención de Intrusos, al igual que un Sistema de Detección de Intrusos, funciona por medio de módulos, pero la diferencia es que este último alerta al administrador ante la detección de un posible intruso (usuario que activó algún Sensor), mientras que un Sistema de Prevención de Intrusos establece políticas de seguridad para proteger el equipo o la red de un ataque; se podría decir que un IPS protege al equipo proactivamente y un IDS lo protege reactivamente
Los dispositivos hardware generalmente IPS hacen una copia del tráfico (span) y tienen menos impacto en el rendimiento de red.
Aunque parecidos, un IPS no es un firewall. El IPS  basa sus decisiones de control de acceso en el contenido del tráfico mientras que un firewal estándar solo lo hace teniendo en cuenta la direccion IP o el puerto.
Fig 3. IDS y firewalls

miércoles, 9 de marzo de 2011

Saga Ipv6 Episode III: Plan de direccionamiento en Ipv6



Direcciones Obligatorias Nodo IPv6

Direcciones obligatorias en un Host IPv6:


  1. Dirección Link Local para cada interfaz
  2. Cualquier otra dirección Unicast y Anycast adicional que se haya configurado en las interfaces del nodo (manual o automáticamente).
  3. Dirección de loopback
  4. Direcciones multicast de todos-los-nodos (All-Nodes)(FF01::1, FF02::1).
  5. Dirección multicast Solicited-Node para cada una de las direcciones unicast y anycast.
  6. Direcciones Multicast de todos los grupos a los que el nodo pertenezca


Direcciones obligatorias en un Router IPv6:

Host +:
  1. Direcciones Anycast Subnet-Router para todas las interfaces para las que este configurado que se comporte como un router.
  2. Todas las demás direcciones Anycast que se hayan configurado en el router.
  3. Direcciones multicast All-Routers (FF01::2, FF02::2, FF05::2).
• Mecanismos para asignar y configurar dirección IPv6:

En función del grado de control que se quiera dar a cada red se deben usar distintos
mecanismos de configuración de direcciones. De menor a mayor control y
trazabilidad son:
  1. Autoconfiguración Stateless. Existen dos alternativas:
    •  Identificador de interfaz mediante números aleatorios (extensiones de privacidad). Esta opción no es recomendable cuando es necesario por razones legales, el tener un registro del uso de la red por parte de cada usuario. Tampoco cuando se necesitan direcciones estáticas, por ejemplo, para aplicaciones Peer-to-Peer (lo que generalmente conlleva el registro de direcciones en DNS).
    •  Identificador de interfaz a partir de la dirección MAC.Problema: La MAC identifica al usuario y esto evita su privacidad en internet
  2.  Autoconfiguración Stateful: utilizando DHCPv6
  3.  Direccionamiento configurado manualmente.

• Criterios para asignar dirección IPv6:

Una vez obtenido un prefijo de red por un RIR se debe trazar un plan de direccionamiento para dotar de dirección nuestras máquinas/redes.  Dicha asignación es para las diferentes redes y subredes existentes
en una red operativa así como las planeadas a futuro

 Para ello se pueden considerar los siguientes criterios (RFC3177 y tendencias reales)

– Todas las redes internas que vayan a desplegar IPv6 tendrán un prefijo /64. Necesario para la construcción automática de direcciones IPv6 de tipo Unicast y/o Anycast

Fig1. Dirección Ipv6 de prefijo /64. 1 red


– Los usuarios finales, clientes residenciales (acceso xDSL, FTTx, etc.), como corporativos (empresas, ISPs,Universidad, etc.) podrán recibir prefijos de longitud /48, dejando 16 bits del bloque de red para crear subredes (link)
Fig2. Dirección Ipv6 de prefijo /48. 1 red, 2¹⁶ subredes
Un dirección de prefijo /48 posibilita crear hasta 2^16 (65.536) subredes IPv6 de prefijo /64
La asignación de 65.536 posibles subredes IPv6 de prefijo /64 puede parecer “a priori” excesiva, sin embargo existen varias razones para ello como implementación de servicios nuevos como voz y tv sobre IP (VoIP, IPTV, etc.,) cuya distribución puede requerir el uso de redes /64 específicas para cada usuario final. Además es previsible la llegada en los próximos años de nuevas
aplicaciones y/o servicios, aun inimaginables, basadas en domótica, inteligencia ambiental etc que requieran un espacio de direccionamiento propio y separado del resto de tráfico, en la red del usuario final. Por ejemplo, podría ser necesario tener redes IP  /64 exclusivas IPv6 para conectar electrodomésticos de la cocina, otra red diferente para sensores de presencia ubicados en las habitaciones del usuario, otra red para dispositivos de seguridad como detectores de humo, gas, etc

Para la elaboración del plan de direccionamiento se deben tener en cuenta las diversas subredes existentes susceptibles  de desplegar IP 6 en algún momento, estas pueden incluir:

– Subredes susceptibles de ser nativas IPv6 desde el primer momento del despliegue de IPv6
– Subredes susceptibles de ser nativas IPv6 a medio o largo plazo,no necesariamente desde el comienzo del despliegue de IPv6

• Transición de  IPv4 a IPv6:


Se han creado diversos métodos para hacer la transición hacia IPv6 gradualmente, conviviendo IPv4 e IPv6
Servicios de transición de Ipv4  a IPv6:
  • Dual Stack : Servidores/hosts soportando ambos protocolos
  • Tuneles: Para conectar islas IPv6
    • 6to4: Protocolo Ipv6 sobre Ipv4 más común. Los extremos del túnel deben  tener una  dirección pública Ipv4. Esa dirección pública está enbebida en la dirección Ipv6. Estas direcciones tienen todas el prefijo 2002::/16 seguido de la dirección ipv4 expresada en hexadecimal que las identifica 
      • Ej: Si la IP pública es 64.46.34.10 la direccion 6to4 será 2002:402E:220A::/48
      • Si la IP pública es 82.116.25.31 la direccion 6to4 será 2002:5274:191F::/48
    • Teredo: Protocolo  que encapsula direcciones Ipv6 en datagramas IPv4. No necesita de extremos con dirección con IPv4 pública que tienen una Ipv6 global estableciendo las comunicaciones unicast a través de  NAT. Usado por windows
  • Métodos de traducción: (“IPv4-only to IPv6-only”)
• DNS y IPv6:


Las diferencias dns entre ipv4 e ipv6 en los registros de dirección A (que traduce la dirección IP a nombre) y el registro reverso PTR (Pointer que actua al contrario, de nombre de dominio a IP)
En Ipv4 , un registro (A) pinta así:


www IN A 123.45.67.89

El correspondiente reverso (PTR) es de esta forma:

89.67.45.123.in-addr.arpa PTR www.whazzamattau.edu.


Notese que los octetos son escritos en oreden inverso y la frase  “in-addr.arpa” es añadida.

In IPv6. un registro de dirección ( se denota AAAA) es así:

www IN AAAA 2001:ec8:4008::1234:5678:9abc:def0

El correspondiente PTR:

f0.de.bc.9a.78.56.34.12.0.0 P.ipv6.arpa PTR www.whazzamattau.edu.


Durante la transición IPv4 a IPv6 será necesario mantener los dos tipos de registros:


IPv4 Host Record – registro A
IPv6 Host Record – registro AAAA
IPv4 PTR Record –en el dominio IN-ADDR.ARPA
IPv6 PTR Record – en el dominio IP6.ARPA 

Creados manual o automáticamente por dhcp

El objetivo es tratar de garantizar que no se requerirá modificar la estructura del plan de direccionamiento en el futuro, cuando el despliegue de IPv6 en la red se haga de forma masiva.




lunes, 7 de marzo de 2011

Saga Ipv6 Episode II: Direcciones Ipv6. Formato y tipos

El cambio más significativo en las direcciones respecto a IPv4 ha sido que, ahora, las direcciones IPv6 son asignadas a interfaces, no a nodos. Cuando un nodo tiene más de un interfaz, el nodo puede direccionarse mediante la dirección de cualquiera de sus interfaces.
Un conjunto de interfaces puede tener asignada una sola dirección IPv6, esta agrupación elimina la posibilidad de que cada uno de los interfaces que comparten una dirección pueda tener asignada cualquier otra.
Los routers pueden tener interfaces sin dirección asignada en enlaces PPP (Point to Point Protocol, Protocolo Punto a Punto). Los interfaces de enlaces PPP no necesitan dirección IP si no son origen o destino de datagramas IPv6.

Representación de direcciones

La dirección IPv6 (128 bits) se representa usualmente en hexadecimal, creando grupos separando cada dos octetos mediante dos puntos (:). 

Ejemplo:


                             2001:0db8:85a3:0000:0000:8a2e:0370:7334

La notación Ipv6 se puede simplificar con las siguientes reglas que afectan a los ceros:

Ceros iniciales
Los ceros iniciales de cada grupo pueden omitirse.De ese modo, la dirección IPv6 ejemplo podría escribirse:
                              2001:db8:85a3:0:0:8a2e:370:7334

Cada grupo debe contener al menos un dígito hexadecimal, excepto para el caso descrito a continuación.

Grupos de ceros
Uno o más grupos de ceros pueden ser sustituidos por dos puntos. Esta sustitución puede realizarse únicamente una vez en la dirección. En caso contrario, obtendríamos una representación ambigua. Si pueden hacerse varias sustituciones, haremos la mayor número de grupos; si el número de grupos es igual, haremos la situada más a la izquierda.
Con esta regla, reduciríamos aún más la dirección ejemplo:
                             
                               2001:db8:85a3::8a2e:370:7334
Ejemplo no válido: 2001:0:0:0:2:0:0:1  -> 2001::2::1 (debería ser 2001::2:0:0:1 ó 2001:0:0:0:2::1)

La dirección de loopback, 0:0:0:0:0:0:0:1, y la dirección IPv6 indefinida, 0:0:0:0:0:0:0:0, se reducen a ::1 y :: respectivamente.Notación decimal con puntos

Direcciones IPv4-mapeada
Se ha introducido una notación especial para expresar direcciones IPv6 que sean IPv4-mapeada,  representando los últimos 32 bits de la dirección IPv6 en el formato decimal con puntos usado en IPv4.
Por ejemplo,  IPv6 del tipo IPv4-mapped 

                           ::ffff:c000:280 se puede representar como ::ffff:192.0.2.128

Tipos de direcciones

En el IPv6 existen tres tipos básicos de direcciones:

  • Direcciones unicast: Están dirigidas a un único interfaz en la red. Actualmente se dividen en varios grupos, y existe un grupo especial que facilita la compatibilidad con las direcciones de la versión 4. 
  • Direcciones anycast: Identifican a un conjunto o grupo de interfaces de red. El paquete se enviará a cualquier interfaz que forme parte del conjunto. En realidad son direcciones unicast que se encuentran asignadas a varios interfaces. Un paquete IPv6 con una dirección destino anycast es encaminado a uno y sólo uno de los interfaces identificados por la dirección. 
  • Direcciones multicast: Identifican a un conjunto de interfaces de la red, de manera que cada paquete es enviado a todos y cada uno de ellos individualmente.

No existen direcciones broadcast en IPv6 , su función es realizada por las direcciones multicast.

Identificación del tipo

Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los primeros bits de cada dirección
::              La dirección con todo ceros indica la ausencia de dirección, y no se asigna ningún nodo
::1            La dirección de loopback 
::ffff:0:0   La dirección IPv4 mapeada  
fe80::       El prefijo de enlace local. La dirección sólo es válida en la red local
ff00::       El prefijo de multicast. Se usa para las direcciones multicast.

Resto , unicast global. Direcciones válidas globalmente en internet.

Asignando direcciones Ipv6. Formato


Como hemos visto las direcciones Ipv6 se clasifican en tres grupos: unicast, multicast y anycast. Para reconocerlas se dividen los 128 bits en bloques que representan distintas características de la dirección.

Formato Unicast


Se compone de 2 grandes bloques de 64 bits, el primero asignado por el ISP (prefijo de red) y el segundo por el usuario (bloque de interfaz). El primer bloque puede subdividirse en 2 trozos uno de 48 bits para el prefijo y otro de 16 bits para identificar subredes, quedando

Formato general unicast
Bits481664
campoprefijo de redsubnet ididentificador de interfaz 

La asignación más recomendable es que el proveedor nos fije los primeros 48 bits y deje los 16 bits siguientes al administrador local para asignación de subreredes (hasta 2¹⁶=65536 subredes). Los 64 bits de interfaz se pueden generar:
Automáticamente, a partir de la MAC del interface (48 bits) insertando FF:FE en el medio de la MAC   expresada en hexadecimal, por ejemplo 00:1D:BA:06:37:64 --> 00:1D:BA:FF:FE:06:37:64
   Problema: La MAC identifica al usuario y esto evita su privacidad en internet
- Asignada por DHCPv6
- Aleatoriamente de forma automática
- Asignada manualmente


Link-local Unicast
La dirección link-local es el caso especial que representa una dirección unicast solo válida en una red interna y no es enrutable en internet. En este caso el bloque de interface es igual , cambiando el bloque de red por el prefijo FE80 con 10 bits, seguido de 54 ceros hasta completar los 64 bits del bloque de red
Formato Unicast Link-local 
Bits10 (FE80)5464
campoprefijocerosidentificador de interfaz

El prefijo FE80 identifica la dirección unicast como no enrutable y será descartado en los routers.

Global Unicast

Son las direcciones unicast  enrutables
Los tres primeros bits del bloque de 64 de red se fijan a 001 (primer digito hexadecimal 0010 ó 0011):

Formato Goblal Unicast
Bits0010..
0011..
4864
campoprefijoresto de direccion globalidentificador de interfaz

                2xxx:                        xxxx:xxxx:xxxx
                3xxx:                        xxxx:xxxx:xxxx

El prefijo 2xxx ó 3xxx nos indica un dirección global unicast, enrutable, cualquier otra cosa se ignora en un router.



Formato Multicast
  • Se comporta cómo multicast de IPv4
  • Casi todo el hardware ya lo entiende
  • IPv6 requiere que esto esté extendido
  • Los hosts se unen a un grupo multicast y entonces les llega la comunicación
  • Los routers y switches son los encargados de mantener la tabla de miembros multicast
  • Un host manda a un grupo y el resto de la infraestructura se encarga de enviar a el resto de los miembros



Formato general multicast
Bits8
FF
44112
Campoprefjoflagsscopegroup ID


• Flags: 0RPT: El flag de más peso está reservado y debe inicializarse a 0
                      – T: Asignación Transitoria, o no
                      – P: Asignación basada o no, en un prefijo de red
                      – R: Dirección de un Rendezvous Point incrustada, o no
• Scope:
                     1 - Interface-Local
                     2 - link-local
                     4 - admin-local
                     5 - site local
                     8 - organization-local
                     E - global
(3,F reservados)(6,7,9,A,B,C,D sin asignar)

Direcciones "Well Known multicast"


FF01::1 – todas las dir de este interfaz
FF02::1 – todas las dir en este link
FF01::2 – todos los routers de este interfaz
FF02::2 – todos los routers de este link
FF05::2 – todos los routers de este site

FF02::1:FFnn:nnnn – “nodo solicitado”
Un host debe unirse a un grupo multicast para cada dirección configurada en cada interfaz



Resumen 64 bits de red

  • 2 or 3 – unicast global (Enrutable por Internet)
  • FE80 – unicast link-local (APIPA)
  • FEC0 – unicast site-local (desaparece)
  • FC00 – unicast unique local (IP privada)
  • FF – multicast
Saga Ipv6 Episode I: Características y objetivos
Saga Ipv6 Episode II: Direcciones Ipv6. Formato y tipos
Saga Ipv6 Episode III: Direccionamiento en IPv6


jueves, 3 de marzo de 2011

Comienza al Rooted CON 2011 !!!

Hoy y hasta el sábado 5/03/2011 tendrá  lugar en Madrid, la conferencia sobre seguridad informática Rooted CON 2011. Las ponencias y agenda pueden consultarse aquí.
Yo estoy inscrito, asi que vaaamos para allá !!

miércoles, 2 de marzo de 2011

Esquivando Firewalls con Smart Spoofing

Vamos a ver el uso de arp spoofing e iptables para burlar un firewall basado en IP mediante la técnica de Man in the Middle.

Escenario:
Fg1. Escenario de red
La red está configurada como vemos:

  • Red 10.10.10.x 
    • Odenador Verde con Ip permitida para salir hacia 172.12.x.x
    • Ordenador Rojo. Ip rechazada en el firewall de la puerta de enlace
    • Azul: Puerta de enlace y firewall. Comunica las redes 10.10.10.x y 172.12.x.x
  • Red 172.16.x.x
    • Servidor 172.16.61.1, mundo exterior a la red 10
Configuración:

En la puerta de enlace  configuraremos NAT (1)  y activaremos el reenvío de paquetes (2):


# iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.16.61.136                         (1)
# echo 1 > /proc/sys/net/ipv4/ip_forward                                                                                         (2)

En la máquina verde y roja como la puerta predeterminada fijaremos el ordenador azul:

# route add default gw 10.10.10.1

Nota: recuerda que el comando de arriba hay que introducirlo en ambos ordenadores  verde y rojo

De esta forma ambos, verde y rojo  llegan a 172.16.61.1 a través de azul:

Fig2. Antes de establecer las reglas de firewall en azul, tanto rojo como verde llegan a 172.16.61.1
Ahora haremos que la puerta no deje pasar en el mundo los paquetes que proceden del ordenador rojo

Para ello en la puerta de enlace introducimos el comando:

# iptables -A FORWARD -s 10.10.10.102 -j REJECT

Comprobamos que el comando consiguió el resultado , impidiendo que rojo llegue al servidor 172.16.61.1:
Fig3. Rojo, con ip 10.10.10.102, no llega al servidor debido a la regla del firewall
Ataque SmartSpoofing:

El ataque estará compuesto de dos elementos:
  1.  Primero realizaremos un  arp spoofing, para hacer un Man in The Middle y  el tráfico de red entre el verde y la puerta de enlace/firewall pase a través del ordenador de rojo
  2. Luego configuraremos iptables en el ordenador rojo para que los paquetes salientes del rojo tengan cabeceras convertidas con  la dirección IP del ordenador verde y así sean permitidos en el firewall tanto de entrada como de salida (NAT)
1. Arp Spoofing y Man in the Middle:



En el ordenador rojo activamos el reenvío de paquetes:

# echo 1 > /proc/sys/net/ipv4/ip_forward 

 # iptables -A OUTPUT -p icmp --icmp-type host-redirect -j DROP
Empieza arp spoofing. Tenemos que engañar tanto a verde como a la puerta de enlace
El el ordenador ROJO:

  • En la una consola (alt+F1) introducimos el comando para spoofear a puerta de enlace  y le hacemos creer que el rojo es el verde:
                                       # arpspoof -t 10.10.10.1 10.10.10.101 

  • En la segunda consola (alt+F2), spoofeamos a verde haciéndole creer que rojo es el gateway:

                                       # arpspoof -t 10.10.10.101 10.10.10.1

Ahora todo el tráfico pasa por rojo spoofeando las tablas ARP de verde y gateway:
Fig4. Man in the Middle con arp spoofing


Bien, una vez conseguido hacer creer al firewall que el ordenador rojo es  el verde, fijaremos una regla iptables en el  rojo para que sus paquetes (propios, no redirigidos)  salgan con la ip del verde y nos sean devueltos. Esto es necesario porque el gateway hace NAT y que solo permite la ip del verde con lo cual al regresar el tráfico y deshacer el NAT lo traducirá de nuevo a la IP del verde lo que nos obliga a utilizar esa misma IP si queremos recibir el tráfico de retorno.

2. Iptables para gestionar el tráfico propio de rojo y redirigir el de verde:

Debemos de manera respectiva configurar iptables en el ordenador rojo para que modifique la dirección del remitente en los paquetes salientes y distinga  entre los paquetes entrantes los propios y los reenvío.

Afortunadamente, este asunto complicado se arregla con un simple comando:

# iptables -t nat -A POSTROUTING -j SNAT --to-source 10.10.10.101

Y ya está, hemos realizado el smart spoofing y ahora tanto rojo como verde pueden mandar y recibir tráfico desde 172.16.x.x, quedando la cosa asi:
Fig 5-Situación Final. Evitando firewall


Saludos del lobobonario!!

martes, 1 de marzo de 2011

Saga Ipv6 Episode I: Características y objetivos

Objetivo IPv6: Incrementar  espacio de direcciones

Comenzamos hablando de la necesidad de un nuevo sistema de direccionamiento al quedarse IPv4 con sus 32 bits escaso. En IPv6, cada dirección consta de 128 bits de tal forma que IPv6 tiene 2 ^ 96 veces más direcciones que IPv4. Aunque en realidad, considerando que la subred mínima de IPv6 es de 64 bits de longitud, en IPv6 es más correcto hablar de un espacio total de 2 elevado a 64 subredes con 2 elevado a 64 posibles direcciones en cada una.

En resumen:


2^128 --> 2340 282 366 920 938 463 463 374 607 431 768 211 456 de posibles direcciones
2^64 subredes , 2^64 nodos por subred
Tamaño fijo de subred. No necesidad de subnetting, CIDR

Suficiente, ¿ no ? :-)


Características IPv6


 Aprovechando la revisión del protocolo, se han introducido otras mejoras y nuevas funcionalidades:
  • Autoconfiguración y reconfiguración automáticas de la dirección IP sin necesidad de servidores (sin estado).
  • Soporte nativo y mejorado del direccionamiento multicast , desaparece el broadcast y creación del direccionamiento anycast.
  • Implementación obligatoria de IPsec. 
  • Simplificación de cabeceras
  • Enrutado más eficiente. Cabeceras mas sencillas, los routers no hacen fragmentación y los nodos IPv6 requieren ya sea hacer descubrimiento de MTU, realizar fragmentación extremo a extremo o enviar paquetes menores al MTU mínimo de IPv6 de 1280 bytes. No se comprueba checksum (se hace en la capa de enlace y transporte). 
  • Implementación de etiquetas para QoS 
  • Movilidad de Red (NEMO, por Network Mobility) (RFC 3963), que permite que redes enteras se muevan a nuevos puntos de conexión de routers sin reasignación de numeración
  • Jumbogramas (paquetes de gran tamaño de hasta 4Gb, frente a los 64kb de ipv4). Reduce fragmentacion y mejora la eficiencia en redes con alto MTU
Todo ello unido claro está, a la motivación principal: la extensión del espacio de direcciones.


Este gran aumento en el número de direcciones IP disponibles hará posible que un número
prácticamente ilimitado de elementos tales como electrodomésticos, automóviles, sensores,
etc. se puedan interconectar para ofrecer nuevos servicios.



Fig 1. Cabeceras IPv4 - IPv6






IPv6, necesidad espacio de direcciones

Como ya comenté en un anterior post ipv4 ha dado sus últimos coletazos. Desde ahora para obtener  y usar direcciones IP de nuestra propiedad debemos recurrir a IPv6.

Ipv4 y problemática

En ipv4 las direcciones son  de 32 bits, permitiendo un espacio  de 4.294.967.296 (2³²) direcciones posibles .Esos 32 bits se divididen  en 4 octetos y se organizan en clases según cojamos un octeto (clase A), dos (clase B) o tres (clase C) para destinar a la red aplicando la máscara correspondiente.

Fig 1. Clases IPv4

Direcciones privadas: Existen en cada clase una serie de direcciones reservadas que no se pueden usar en internet y se destinan a uso de intranet:

Clase A: 10.0.0.0 a 10.255.255.255 (8 bits red, 24 bits hosts).
Clase B: 172.16.0.0 a 172.31.255.255 (12 bits red, 20 bits hosts). 16 redes clase B contiguas, uso en universidades y grandes compañías.
Clase C: 192.168.0.0 a 192.168.255.255 (16 bits red, 16 bits hosts). 256 redes clase C contiguas, uso de compañías medias y pequeñas.

Las clases D y E son reservadas a multicast y se usan para identificar grupos.

Además dentro de cada segmento tenemos 2 direcciones particulares, la dirección de red que es la primera dirección del segmento y que identifica la propia red y la direccion de broadcast que identifica a todos los host incluidos en la red. Por ejemplo, en una direccion de  clase C como la 192.168.1.140, los tres primeros octetos son los de red, la dirección 192.168.1.0 identifica la red y la dirección 192.168.1.255 es el broadcast que referencia todo el rango. El resto,  192.168.1.1--192.168.1.254 son las direcciones asignables a host.
Con esta forma de direccionamiento y a pesar de hacerse uso de  técnicas como NAT y CIDR para ahorrar direcciones, nos encontramos que el día 3 de febrero de 2011 la IANA (organismo que gestiona y asigna las direcciones IP) comunicó la entrega de las últimas 5 clases A

Solución: IPv6

Ipv6 nace en 1996 tras algunas aproximaciones anteriores reflejado en el estándar IETF RFC 2460 por la necesidad de expandir el espacio de direcciones ipv4. En ipv6 pasamos de tener 32 bits  a tener 128 bits para conformar la dirección , y con ello de las 4.294.967.296 posibles ipv4 a 340.282.366.920.938.463.463.374.607.431.768.211.456 (2¹²⁸) direcciones en ipv6. Con esto se podrían asignar 670 mil Billones de IP's a cada mm cuadrado de la Tierra. Suficiente ¿no? :-)

La cosa está clara. Hay que adapatarse a Ipv6. El cambio será gradual y se estima que durante 10 años convivirán Ipv4 e Ipv6, pero es necesario ir poniendo manos a la obra.

En próximas entregas iré comentando aspectos de funcionamiento, configuración y como no, seguridad de IPv6