Algunos problemillas con IPv6

(N.d.E. Hoy tenemos una entrada de Vicente Dominguez, un viejo amigo que hace algún tiempo que decidió comenzar una aventura por su cuenta, que esperamos que le vaya muy bien :)

Después de dar con la entrada de Nacho del mes pasado me fue inevitable eludir mi desviación profesional después de años y años trabajando en un centro de datos y recordé el sobre-esfuerzo que requiere la adaptación a la version 6 de IP para una mente humana que viene de la version 4.

Además de los magníficos problemas que en recursos requiere los 128 bits por cada dirección en su enrutado, las complicaciones para los IDS en recursos y firmas y el mal manejo de algunas utilidades de toda la vida, están los que yo sufrí: los de la mente humana. Éstos lo dejo para el final.

Si nos vamos a la seguridad, que es de lo que va el blog, se me ocurren algunos puntos a tener en cuenta sobre el “rocambolesco” mundo IPv6 con algunas utilidades. Sin pensar demasiado y como ejemplo:

  • Para empezar: las máscaras. Si metéis el típico /24 o /32 en IDS, firewalls o utilidades (por herencia pura) os vais a encontrar examinando 1000 millones o 4 mil millones de direcciones. Ojo con tener reglas que indican el guardado en BBDD de direcciones aplicando estas máscaras. Vais a necesitar mucho mucho espacio, amigos.
  • Más ejemplos: Nmap no permite rangos clásicos. Las formas 192.168.2.* y 192.168.2-30 no funcionan con IPv6. Ojo a esos scripts de autodiscovery de algunas redes.
  • Nping no funciona con rangos directamente en IPv6. Fyodor dice que: “CIDR and octet ranges aren’t supported for IPv6 because they are rarely useful” (Ref: http://nmap.org/book/nping-man-target-specification.html)
  • hping2 no tiene IPv6. O por lo menos no el que uso.
  • Lynx requiere de versión específica compilada.
  • Curl. Este es buenísimo. Las direcciones de IPv6 van entre comillas y entre corchetes aplicando el globoff porque si no, no «parsea» bien. ¡Oh! ¡Cuántos agentes de monitorización dirán adiós! (Ref: http://vicendominguez.blogspot.com/2014/03/curl-IPv6-common-errors-using-direct-ip.html)
  • Medusa en FreeBSD me da un segmentation fault. ¡Genial!
  • Necesitamos cambiar el bind de algunos servicios si están forzados a una interfaz concreta o no será posible alcanzarlos.
  • Iptables, ping y traceroute (entre otros…) usan nuevas utilidades específicas: ip6tables, ping6 y traceroute6.
  • El resto de utilidades requieren de parámetros específicos para invocar el uso de IPv6. ¿Alguna vez será este el uso por defecto de la tool? Quien sabe.

La consecuencia directa de todos estos cambios levanta un claro punto débil: la mente humana.

Es fácil pensar que si todo esto cambia es necesario volver a configurar todo lo ya configurado anteriormente, pero ahora, para este nuevo stack.

Como comentábamos. Las firmas de vuestros IPS, IDS, la cantidad de los datos a guardar y el rango de ips a monitorizar cambia en cualquier IDS que instaleis para este stack. Huelo a vectores de ofuscación fácil. Si no tengo firma o no escucho ahí, no lo veo. O caemos, o nos acordamos, o se nos escurren.

Scripts de monitorización basados en curl, ping, necat, socat etc etc… requieren o nuevas aplicaciones (ping6, traceroute6…) o nuevos parámetros (-6 esta intentando estandarizarse como parámetro de facto para la invocaciones para IPv6). Adaptarse o morir.

Las reglas de firewall tienen que aplicarse en ambos stacks: IPv4 y IPv6 compañeros. Y ambos deben de estar ON amigos. En el caso de linux iptables, pero ahora, ip6tables también.

Con todo esto llegamos de lleno a pruebas más reales. No espereis nada del otro mundo. O por lo menos no por aquí ;) (N.d.E. Voy a perdonarle a Vicente ese desliz…).

Es posible pedir a Hurricane Electric un tunnel IPv6 gratis. No cuesta nada pedirlo y es cero-cero configurarlo. En FreeBSD no me llevó ni dos minutos activarlo. No se como será el resto.

Hecho esto y habiendo leído parte del artículo, no tardamos en darnos cuenta de lo diferente que se comportan los sistemas.

Los IIS7 de las páginas del Ministerio de Industria actúan de forma diferente según stack. Cojo de ejemplo bandaancha.es.

host www.bandaancha.es

www.bandaancha.es has address 193.146.1.84
www.bandaancha.es has IPv6 address 2001:720:438:400::84

Uso normal: Redirect!

curl -i -A Chrome http://www.bandaancha.es
HTTP/1.1 302 Redirect
Content-Type: text/html; charset=UTF-8
Location: http://www.minetur.gob.es/telecomunicaciones/banda-ancha/Paginas/Index.aspx
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 24 Mar 2014 07:39:25 GMT
Content-Length: 209

IPv4: Welcome

curl -i -A Chrome 193.146.1.84
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Tue, 26 Jul 2011 15:34:53 GMT
Accept-Ranges: bytes
ETag: "ad1be390a94bcc1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 24 Mar 2014 07:38:03 GMT
Content-Length: 689

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/
xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>IIS7</title>
<style type="text/css">
<!--
body {
color:#000000;
background-color:#B3B3B3;
margin:0;
}

#container {
margin-left:auto;
margin-right:auto;
text-align:center;
}

a img {
border:none;
}

IPv6: ¡Fiesta de la espuma!

curl -i -6 -g "http://[2001:720:438:400::84]"
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Mon, 24 Mar 2014 07:42:40 GMT
X-Cnection: close
Content-Length: 334

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>

En absoluto es crítico alguno de los mensajes que aparecen pero viene a reflejar perfectamente la diferencia de comportamientos según stack (o acceso). Ojo pues con virtualhosting, htaccess, WAFs y compañia. ¡Avisados estáis!

Creo que no se aporta ningún dato nuevo, pero considerando que el World IPv6 Launch Day fue en 2012 y que hay una extensa lista de sitios ya por IPv6, me sigue llamando la atención el estado actual de todo el sistema.

Si alguno tiene dudas, vamos a arriesgar un pelín más… me voy a un core de un importante IPS que pertenece a nuestra compañía de telecomunicaciones más internacional…

host rou2-mad.xxxx.net
217.x.x.x

IPv4:

telnet 217.x.x.x
Trying 217.x.x.x...
telnet: connect to address 217.x.x.x: Connection refused
telnet: Unable to connect to remote host

IPv6:

telnet -6 2a02:xxx::0:0:0:0:1
Trying 2a02:xxx::0:0:0:0:1...
Connected to 2a02:xxx::0:0:0:0:1.
Escape character is '^]'.
C
(c) Proveedor 2007
Acaba de acceder a rou-mad2.xxxx.net,el acceso es restringido a personal autorizado.
Su conexion ha sido registrada.Si Vd. no ha sido autorizado expresamente para la utilizacion
de este equipo desconecte ahora,de lo contrario puede infringir diversos
articulos del nuevo codigo penal y ser sancionado por ello.

User Access Verification

Username:

Nada grave. Pero creo que sirve como prueba. Es un problema humano: nos olvidamos de cosas.

Y aquí no hemos gastado ni una sola línea acerca de los posibles vectores que da el propio protocolo IPv6 del que sí hay muchas líneas escritas.

¿Estáis preparados?

Un saludo a todos.

Comments

  1. Ese Vicente !!! Gran entrada crack. Espero verte pronto.

    Un abrazo.

  2. Gracias amigo! Nos vemos fijo.

  3. Yo también me he pegado bastante con IPv6, hace poco asistí al curso chorra de RIPE y habrá que cambiar el chip.
    Por ahora y para evitar sustos de ISP, tengo en ip6tables todo en drop.

  4. Esto es lo que yo llamo «tirar la piedra y esconder la mano». No se pueden dejar las cosas a medias. Muy buena la entrada.