[LAC-TF] Mitos sobre la seguridad en IPv6: desmontando falsas ideas
Juan Antonio Matos
jmatos at idac.gov.do
Wed Mar 27 11:21:09 BRT 2013
Interesante punto de vista.
Ciertamante es probable que muchos en algún momento hayamos alardeado sobre bondades en el protocolo con intención de motivar la adopción, aun cuando muchos de los features que se promocionan en IPv6 ya estaban presente o eran logrables en IPv4.
Aun asi creo que cada una de las demistificaciones podrían ser ampliamente discutidas.
Mitos o no, excelente punto de vista.
Saludos,
Juan Antonio Matos
Sent via BlackBerry® device.
-----Original Message-----
From: Fernando Gont <fgont at si6networks.com>
Sender: <lactf-bounces at lacnic.net>
Date: Tue, 26 Mar 2013 22:03:21
To: Lista para discusión de seguridad en redes y sistemas informaticos de la región<seguridad at lacnic.net>; lactf at lac.ipv6tf.org<lactf at lac.ipv6tf.org>
Reply-To: <lactf at lac.ipv6tf.org>
Subject: [LAC-TF] Mitos sobre la seguridad en IPv6: desmontando falsas ideas
FYI. Fuente:
<http://searchdatacenter.techtarget.com/es/cronica/Mitos-sobre-la-seguridad-en-IPv6-desmontando-falsas-ideas>
(es la traducción que se acaba de publicar de un artículo que había
escrito hace tiempo...)
---- cut here ---
Mitos sobre la seguridad en IPv6: desmontando falsas ideas
Fernando Gont
Con el paso del tiempo, han surgido diversos mitos sobre las propiedades
y características de seguridad de IPv6. Este artículo técnico ofrece una
evaluación realista de IPv6 desde la perspectiva de la seguridad y
desmantela muchos de los mitos que aún subsisten sobre sus capacidades
de seguridad.
IPv6, la última versión del Protocolo de Internet, está llamado a
coexistir con IPv4, y finalmente a sustituirlo, proporcionando un mayor
espacio de direcciones que permita impulsar el crecimiento de internet
en los próximos años.
Sin embargo, desde la especificación inicial del protocolo, han surgido
diversos mitos sobre sus propiedades en el ámbito de la calidad del
servicio (QoS), las características “plug-and-play” y especialmente la
seguridad. Muchos de estos mitos han sido alimentados por los defensores
de IPv6, quizás pensando que sus promesas publicitarias estimularían el
despliegue de IPv6. Desgraciadamente, no sólo han fallado en su intento
(IPv6 sólo se está implantando últimamente porque se están agotando las
direcciones en v4), sino que muchos de esos mitos han sido tomados por
realidades, lo que genera falsas expectativas sobre las propiedades y
características que ofrece IPv6.
Veamos cuáles son los mitos más comunes de IPv6 en relación con la
seguridad del protocolo:
Mito Nº1. “IPv6 es más seguro que IPv4, ya que la seguridad se ha tenido
en cuenta durante la fase de diseño del protocolo y no ha sido un
elemento añadido a posteriori”. Los orígenes de este mito se remontan a
la primera especificación de IPv6. En aquel momento, el soporte IPsec
era obligatorio para IPv6, se esperaba un amplio despliegue de
IPv6+IPsec a corto plazo y se pensaba que los proveedores no se
molestarían en añadir soporte IPsec a sus implementaciones IPv4. Sin
embargo, estas previsiones no se cumplieron: casi todas las
implementaciones más populares de IPv4 incorporaron soporte para IPsec,
y el conjunto IPv4+IPsec se desplegó mucho antes que cualquier
despliegue significativo de IPv6 (por no citar el binomio IPv6+IPsec).
También se suele decir que el traductor de direcciones de red (NAT)
habría impedido el despliegue de IPsec para end-to-end, y que dado que
IPv6 iba a eliminar la necesidad de NAT (ver el Mito nº3), el uso de
IPsec end-to-end se haría omnipresente. Esta idea es falsa, ya que
muchos (por no decir todos) los factores que han impedido el despliegue
generalizado de IPsec para un uso general con IPv4 (como el requisito de
una Infraestructura de Clave Pública) siguen estando presentes con IPv6.
Aunque los informes y artículos recientes siguen alimentando la creencia
de que los despliegues IPv6 darán lugar a un aumento del uso de IPsec,
esta idea está más basada en la esperanza que en la realidad.
Mito Nº2: “IPv6 regresará el principio end-to-end a internet, por lo que
las arquitecturas de seguridad pasarán de centrarse esencialmente en la
red a centrarse en el host”. Uno de los principios básicos del diseño de
internet es el conocido “principio end-to-end” , basado en la existencia
de una “red tonta”, donde la mayoría de la “inteligencia” o de las
capacidades de toma de decisiones complejas reside en los hosts. Este
principio da lugar a una arquitectura en la que la red se limita a
enviar datagramas desde un host de origen a un host de destino (o a un
conjunto de hosts) sin efectuar una interpretación de los datagramas
enviados. En internet IPv4, este principio es violado por distintos
dispositivos, siendo los NATs en IPv4 probablemente los más conocidos y
ampliamente desplegados.
Se dice que una internet IPv6 exclusiva sin despliegue de NATs IPv6 (ver
mito nº3) devolvería el principio del end-to-end a internet. Sin
embargo, debemos señalar que aunque la gran cantidad de espacio de
direcciones de IPv6 podría proporcionar direcciones IP únicas a cada
dispositivo conectado a internet, para muchos usuarios o administradores
de seguridad el principio end-to-end no es necesariamente una propiedad
deseada.
Por ejemplo, los administradores quizás no quieran que cada host de una
red sea directamente accesible desde cualquier host arbitrario en
internet, una consecuencia no intencionada de IPv6 que podría dejar a la
red expuesta a ataques exteriores. Por ello, los administradores quizás
prefieran una arquitectura de red donde sólo se permita el tráfico de
retorno (es decir, que sólo se permite el tráfico entrante en respuesta
a comunicaciones originadas en la red interna).
Por consiguiente, lo más seguro sería proteger las subredes IPv6 típicas
con un firewall de estado que sólo permita las comunicaciones originadas
en la red interna. De esta manera, al menos en lo tocante al filtrado de
paquetes, la arquitectura de la subred IPv6 típica no será diferente de
una subred IPv4 típica. A título ilustrativo, un reciente trabajo de la
Internet Engineering Task Force (IETF) sobre capacidades simples de
seguridad en Equipos Locales del Cliente (CPE) parece abogar en esa
dirección.
Mito Nº3: “Las redes IPv6 ya no tendrán NATs”. Este mito está muy
relacionado con el mito Nº2 y se basa en la hipótesis de que IPv6
proporciona mucho más espacio de direcciones y los NATs ya no se
desplegarán en las redes IPv6. Sin embargo, esta idea merece un análisis
más profundo.
Durante la fase de coexistencia entre IPv6 e IPv4 y de transición hacia
una internet exclusivamente basada en IPv6 (suponiendo que esto último
esté comenzando ya), se ha producido un uso creciente de NATs. Por un
lado, dado que la mayor parte de las tecnologías de
transición/coexistencia no dispensan a los hosts de la necesidad de
direcciones IPv4, lo más probable es que se desplieguen los llamados
NATs a gran escala o Carrier-Grade NATs(CGNs), generando así un uso
creciente de NATs en internet IPv4. Por otro lado, la única tecnología
de transición/coexistencia que sí dispensa a las redes de la necesidad
de direcciones IPv4 es NAT64, que permite la comunicación entre nodos
IPv6 y nodos IPv4, pero a su vez introduce otro tipo más de NAT, tanto
en internet IPv4 como en internet IPv6.
El potencial de despliegue de los traductores de direcciones de
red/traductores de puertos (NAT-PTs) en Internet IPv6 también merece un
análisis detallado. Si bien los NATs de IPv4 fueron introducidos como
una solución provisional ante el rápido consumo de direcciones en IPv4,
generalmente son percibidos como beneficiosos en el campo del
enmascaramiento de hosts/redes y en el bloqueo de conexiones entrantes a
la red interna (ya que, como efecto secundario de su modo de
funcionamiento, el dispositivo NAT solo permite las conexiones
iniciadas desde la red interna). Aunque se puede alegar que el bloqueo
de las conexiones entrantes es fácil de conseguir con un firewall de
estado normal (sin traducción de direcciones y puertos), y que el
enmascaramiento de hosts/redes no añade mucho en términos de seguridad,
también es cierto que los seres humanos suelen resistirse a los cambios:
por ello, algunos administradores de redes diseñan sus subredes IPv6 de
forma que imiten las subredes IPv4, es decir, desplegando un NAT-PT para
IPv6 que actúa como pasarela de internet para los nodos internos. Así
que en la mayoría de los escenarios de arquitecturas de red IPv6, parece
que el NAT seguirá perdurando.
Mito Nº4: “El gran espacio de direcciones de IPv6 imposibilitará los
escaneos de direcciones IPv6”. Se supone que el aumento de espacio de
direcciones en IPv6 imposibilitará el escaneo de direcciones IPv6. Sin
embargo, esta afirmación se basa en dos hipótesis que no son
necesariamente ciertas en todos los casos. Primero, se da por supuesto
que las direcciones de host IPv6 estarán uniformemente distribuidas por
todo el espacio de direcciones asignado a la subred correspondiente.
Segundo, se supone que un atacante sólo podrá efectuar un escaneo de
direcciones utilizando la fuerza bruta.
Sin embargo, diversos estudiossobre las políticas empleadas para asignar
direcciones IPv6 indican que no están uniformemente distribuidas; más
bien siguen patrones específicos, como los resultantes de las
configuraciones automáticas sin estado (SLAAC), configuración manual o
uso de tecnologías de transición/coexistencia con IPv6. Además, ya se ha
descubierto en estado salvajeque los atacantes no efectúan el escaneo de
direcciones IPv6 mediante la fuerza bruta, sino que intentan mejorar sus
métodos de escaneo aprovechando los ya conocidos patrones de asignación
de direcciones IPv6.
Los ataques mediante escaneo de direcciones pueden ser mitigados de
distintas formas. Primero, las denominadas “direcciones de privacidad”
especificadas en RFC 4941 serían preferibles a los “Identificadores de
Interfaz basado en el formato EUI-64 modificado” que se suelen utilizar
en la configuración automática de direcciones sin estado. Además, como
se indica anteriormente, otra solución es desplegar en el perímetro de
la organización un firewall con estado que únicamente permita el tráfico
de retorno, de manera que los paquetes de exploración enviados por el
atacante nunca lleguen hasta los hosts internos.
Debemos señalar, asimismo, que la razón por la que son habituales los
ataques de escaneo de direcciones en IPv4 mediante la fuerza bruta es
porque el limitado espacio de direcciones de dicho protocolo facilita
ese procedimiento al atacante (o, dicho de otro modo, no le compensa el
esfuerzo de desarrollar otras estrategias de escaneo de direcciones más
sofisticadas/fundamentadas). Esto significa que los escaneos de
direcciones IPv6 no sólo serán más “fundamentados” sino que, además, es
posible que los atacantes empleen otras estrategias de reconocimiento de
red, como la identificación de hosts “vivos” desde las direcciones IPv6
filtradas por los protocolos de capa de aplicación (por ejemplo,
cabeceras de e-mail), posiblemente en combinación con alguno de los
populares motores de búsqueda en internet.
El objetivo de este artículo ha sido arrojar luz sobre los distintos
mitos surgidos en torno a las características de seguridad de IPv6 .
Dado que es prácticamente imposible lograr un despliegue seguro de IPv6
sin hipótesis o expectativas realistas, nos parece necesario hacer un
análisis a fondo de los citados mitos de seguridad en IPv6.
****
Acerca del autor: Fernando Gont es consultor en materia de redes y
seguridad que ha trabajado en diversos proyectos en nombre de National
Infrastructure Security Coordination Centre (NISCC) y el Centre for the
Protection of National Infrastructure (CPNI), dos organismos del Reino
Unido. Dentro de su labor para estas organizaciones, ha escrito una
serie de documentos con recomendaciones para ingenieros de redes e
implementadores de la suite del Protocolo de Internet. Gont es miembro
activo de la Fuerza de Tareas de Ingeniería de Internet (IETF), donde
participa en diversos grupos de trabajo y ha elaborado varios RFCs
(solicitud de comentario). Asimismo, es ponente habitual en diversas
conferencias, ferias de muestras y encuentros técnicos sobre seguridad
informática, sistemas operativos e ingeniería de internet. Pueden
encontrar más información en su Web: http://www.gont.com.ar.
---- cut here -----
--
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
LACTF mailing list
lactf at lac.ipv6tf.org
https://mail.lacnic.net/mailman/listinfo/lactf
Por favor considere el medio ambiente antes de imprimir este mensaje. Please consider the environment before printing this message.
________________________________
Este mensaje puede contener información privilegiada y confidencial. Dicha información es exclusivamente para el uso del individuo o entidad al cual es enviada. Si el lector de este mensaje no es el destinatario del mismo, queda formalmente notificado que cualquier divulgación, distribución, reproducción o copiado de esta comunicación está estrictamente prohibido. Si este es el caso, favor de eliminar el mensaje de su computadora e informar al emisor a través de un mensaje de respuesta. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de IDAC.
This message may contain information that is priviliged and confidential. It is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, reproduction or copying of this communication is strictly prohibited. If this is the case, please proceed to destroy the message from your computer and inform the sender through reply mail. Information in this message that does not directly relate to the official business of the company shall be understood as neither given nor endorsed by it.
More information about the LACTF
mailing list