viernes, 5 de febrero de 2010

El agujero de seguridad mas grande de Internet



En Agosto de 2008, en la conferencia DEFCON 16 se presentó la ponencia "Robando Internet", por Alex Pilosov y Tony Capella. La ponencia describe un ataque "Man in the Middle" que puede ejecutarse con relativa facilidad utilizando las vulnerabilidades del protocolo BGP.

Lo inquietante de esta vulnerabilidad es que puede permitir interceptar prácticamente TODO el tráfico dirigido a un rango de direccionamiento en Internet, y que puede ser casi imposible de detectar. Las medidas de seguridad del afectado, equipos de seguridad, ISOs 27000, no pueden ni detectar el problema ni participar en su resolución. Únicamente la participación del proveedor del acceso a Internet puede permitir su detección e intentar abordar un posible plan de acción.

Para entender el ataque es necesario explicar el funcionamiento del protocolo BGP:
BGP4 (RFC 1771 y RFC 1772) es el protocolo que se utiliza para intercambiar tráfico entre los proveedores de servicios de Internet. Sus funciones son bastante simples: básicamente permite que los sistemas autónomos (AS) – las subdivisones organizativas que gestionan los prefijos de enrutamiento en Internet, habitualmente un ISP – comuniquen a otros sistemas autónomos como alcanzar redes en Internet. Específicamente BGPv4 intercambia prefijos de direcciones de Internet seguidas de los identificadores de los sistemas autónomos a través de los cuales se alcanza dicho direccionamiento.

BGP utilizará siempre el número de saltos mas pequeño para alcanzar un prefijo, es decir, el número de sistemas autónomos que el tráfico tendrá que atravesar. Un router BGP siempre envia el tráfico dirigido al prefijo más específico (el que engloba un número menor de direcciones IP) siguiendo la ruta de ASs asociadas al anuncio de dicho prefijo. Por ejemplo, el prefijo 11.1.18.0/24 contiene 256 direcciones IP y es más específico que el 11.1.18.0/20 que contiene 4096 direcciones. Si se anuncian estos 2 prefijos y llegan a un mismo AS, el tráfico dirigido a la subred más específica se enrutará por los ASs anunciados con ese prefijo.

Todas las decisiones de los routers BGP se toman en local, con la información de las rutas proporcionada por sus vecinos. Estas rutas se intercambian asumiendo que son correctas, en lo que se conoce como confianza transitiva, es decir, los routers BGP de los operadores de tránsito IP creen lo que les comunican sus vecinos, ya su vez transmiten dicha información de enrutamiento a sus restantes interconexiones (en este caso sesiones BGP).

En este escenario, Pilosov y Capella han demostrado que es posible que un sistema autónomo "secuestrador" intercepte todo el tráfico dirigido a un sistema autónomo, reenviánolo después al afectado sin que éste se de cuenta de la acción.

El mecanismo consiste en anunciar un rango de direccionamiento con un prefijo más específico que el que utiliza el AS del cliente para anunciarse en Internet. Una vez propagada esta ruta por la red de sistemas BGP, todo el tráfico de Internet se dirigirá al AS "secuestrador" en lugar de hacerlo al AS del cliente. El secuestrador puede asegurar una ruta IP hasta el AS del secuestrado, despriorizando una de las rutas existentes entre él y el AS secuestrado. Tras interceptar todo el tráfico dirigido al cliente desde el AS "secuestrador", éste se reenrutará hacia el AS secuestrado por la ruta que el secuestrador ha protegido previamente.

El tráfico llega al AS "secuestrado" simplemente con retardo, lo que no será fácil de detectar por el cliente. La única evidencia del ataque es que el tráfico solo llegará al cliente por las rutas decididas por el "secuestrador" y que tendrá un TTL inhabitual. El secuestrador también puede modificar el TTL para ocultar su existencia, haciéndose el ataque prácticamente indetectable.

¿Cómo puede ser esto? ¿Es que no hay ningún control?

Los operadores de trásito IP son los que en realidad intercambian rutas BGP libremente, es decir, hoy y desde el ataque a YouTube en 2008, se filtran con rigor las direcciones que los ASs anunciamos a nuestros proveedores, haciendo complicada la puesta en práctica de este ataque. En cualquier caso, el sistema no es ni mucho menos perfecto, porque depende de un filtrado manual perfecto de todas las direcciones y en todos los ASs del planeta, lo que sin duda está abierto a posibles ataques con las peores intenciones.

viernes, 11 de septiembre de 2009

Mi PUE es 1.04

KC Mares, de Megawatt consulting comenta en su blog que su compañía ha construido 3 centros con PUEs de 1.04, 1.05 y 1.08. Esto es sin duda una cifra muy llamativa en la actual carrera de los PUEs, aunque el señor Mares no parece ser precisamente ajeno a ella, ya que está detrás de algunos de los principales diseños de centros de datos de Sun y Google.

Los datos comunes en cuanto al diseño de los 3 centros de datos son muy significativos:
- 10 MW de carga de sistemas
- Diseño de 400-500 Watios por pie cuadrado; =4305 W/m2 o en racks europeos aprox. 1550 Watios/rack - o lo que sea, que igual no es un rack. No es mucho, menos de los 2kW de una instalación estándar de 16 A.
- Tier III o Tier III+ (¿qué será Tier III+)
- Ubicación en una zona cuya temperatura máxima en verano supera los 32º C.
- Ninguno utiliza una masa de agua (un lago o río) para intercambiar calor.
- Todos se mantienen dentro de los rangos de operación recomendados por el TC9.9 de ASHRAE (comité técnico de ASHRAE sobre instalaciones de misión crítica) y dentro de los permitidos únicamente unas horas al año.

La cuestión es ... ¿Cómo?

Según da a entender el post, que no da demasiados detalles, el diseño se ha planteado con mucho "free cooling", SIN UPSs y con la mínima redundancia en la climatización.

Parece... muy complicado en cualquier caso, por las dimensiones de cada uno de los centros, particularmente en cuanto a climatización.

En racks de 1550 W (que es una aproximación, pero suficiente para estos números) estamos hablando de 6450 racks. Con un PUE de 1.05 estaríamos gastando 500 kW totales de consumo de las infraestructuras. Suponiendo que todo se gasta en climatización 500.000 W/6450 = 77,52 Watios de consumo de los sistemas de climatización por rack.

Definitivamente impresionante, tendremos que estudiar más sobre free cooling.


miércoles, 9 de septiembre de 2009

Dean Nelson, de Sun a eBay

Dean Nelson, el responsable de infraestructuras de centros de datos de Sun acaba de ser fichado por eBay. Mas detalles en su blog.

martes, 8 de septiembre de 2009

PUE en manos de los departamentos de marketing


Un ejemplo de Mike Manos de PUE de un CPD a lo largo de los meses

Mike Manos, ex-Microsoft y desde hace algunos meses en Digital Realty Trust ha publicado un post esclarecedor acerca del uso incorrecto de las métricas de eficiencia energética en su blog en DRT.

Sus propuestas para redefinir o mejor dicho desmenuzar la métrica PUE son:

Design Target PUE (DTP)
PUE que teóricamente puede alcanzar el diseño antes de su construcción. Pura teoría en papel, en condiciones ideales.

Commissioned Witnessed PUE (CWP)
PUE medida en el momento de la certificación de la instalación de un centro de datos, medido con la carga teórica que se va a soportar, obviamente en modalidad de pruebas.

Annual Average PUE (AAP)
PUE media anual medida según un estándar todavía por determinar que al menos fije la frecuencia de medida.

Annual Average Peak PUE (APP)
PUE media anual máxima - la media de los picos medidos durante el año. Según Manos, este es el valor que importa en las operaciones de un datacenter.

lunes, 7 de septiembre de 2009

HP y CISCO suavizan la guerra de los estándares del datacenter virtual

Computerweekly informa que HP y CISCO han acordado una posición común en los nuevos estándares de comunicaciones de datos que están en proceso de aprobación en el comité 802.1 de IEEE. Parece ser que existían importantes discrepancias entre los 2 gigantes tecnológicos acerca de las funciones de gestión.

Las infraestructuras con sisitemas y elementos de red completamente virtuales están a la vuelta de la esquina.

Hadoop al asalto del sector financiero

Hadoop, la implementación opensource de MapReduce del proyecto Apache se lanza al asalto de la industria financiera con su primer congreso en Nueva York, el Hadoop World en New York City. En CNET hay una interesante entrevista al equipo de Hadoop al respecto del evento.

Transferencia sin límites en 1&1

El proveedor de hosting 1&1 www.1and1.com acaba de lanzar su oferta de transferencia ilimitada en todos sus planes. Yahoo y GoDaddy ya lo habían hecho en algunos planes durante 2009. ¿Y eso? El ancho de banda está muy barato para determinados tipos de tránsito IP, pero no es gratis. Habitualmente este tipo de ofertas no están planteando ofrecer ni mucho menos ancho de banda garantizado, sino el uso compartido de determinados recursos. Luego habitualmente si hay limites.

Buscando en las condiciones contractuales de los servicios de 1&1 encontramos algunos detalles esclarecedores:

2.12 Salvo pacto en contrario, se considera incluído en la tarifa un volumen de transmisión de datos de dos Gigabytes mensuales. El volumen de transmisión de datos utilizado se deduce de la suma de todas las transmisiones de datos relacionadas con el encargo del cliente (como por ejemplo, correos electrónicos, descargas, cargas, páginas web). Para la determinación del volumen de transmisión de datos, un Gigabyte equivale a mil Megabyte, un Megabyte equivale a mil Kilobyte y un Kilobyte equivale a mil Byte.

En caso de que el CLIENTE supere en un mes el volumen de transmisión incluído en la tarifa, 1&1 se reserva el derecho de facturar la diferencia entre el volumen incluído en la tarifa contratada y el volumen consumido realmente a los precios de 1&1 vigentes en dicho momento.


2 Gigabytes mensuales equivalen a 6,17 Kbps garantizados las 24 horas del día. En cualquier caso, no se indica dónde consultar los precios vigentes para transmisión de datos.