Para sobrevivir a los ataques del futuro hay que diseñar contra fallos

CloudRedesSeguridad

Mes tras mes, la frecuencia, tamaño y complejidad de los ataques contra los negocios online están creciendo. En vez de convertirse en más civilizado, Internet lo es cada vez menos. Andy Ellis, arquitecto jefe de seguridad en Akamai, nos aporta detalles realmente interesantes en base a su dilatada experiencia.

La Falta de Fiabilidad del DNS (Domain Name Service)

Consideremos el caso del DNS. Este protocolo que parece inocuo, que simplemente traduce nombres de hosts (como www.csoandy.com) en direcciones IP (como 96.17.149.33) es una base de Internet tan importante que sin ella, los humanos tendríamos graves problemas para tratar de modo significativo con un sistema distribuido tan amplio. La Web, tal y como la conocemos, no existiría sin el DNS. Lo bueno que tiene el DNS es su sencillez: formulas una pregunta y consigues una respuesta.

Pero si no se puede conseguir una respuesta, entonces ya no funciona nada – su navegador de Web no puede cargar noticias, su cliente de correo electrónico no puede descargar los emails y su reproductor de música no puede descargar las últimas canciones. Es importante asegurar una alta disponibilidad del DNS; en contra de la intuitividad, lo construimos asumiendo que es probable que falle. Y de esto podemos aprender cómo construir infraestructuras que son capaces de sobrevivir.

Primero, el DNS utiliza principalmente UDP en vez de TCP para el transporte. UDP (a menudo apodado el “Unreliable Data Protocol” Protocolo de Datos Poco Fiable) se parece más a pasar notas que a tener una conversación; el remitente no tiene ni idea de si su mensaje ha llegado a su destinatario. Un cliente envía una solicitud UDP a un servidor de nombres, el servidor de nombres devuelve una respuesta UDP (si esto se hubiera implementado en TCP, la conversación hubiera ocupado 7 paquetes). Si el cliente no recibe una respuesta en un lapso de tiempo dado, volverá a intentarlo, pero entonces el cliente solicitará una dirección IP de servidor diferente.

Debido a que el DNS no tiene ninguna “garantía” de fiabilidad desde UDP (y, francamente, la garantía de fiabilidad que TCP hubiera ofrecido no vale mucho más), la implementaciones tenían que asumir, correctamente, que el fallo ocurriría, y ocurren con regularidad. Por lo tanto, todo estaba previsto para el fallo. Debido a que la solicitud/respuesta del DNS se realiza en un solo paquete, la fidelidad al servidor no es necesaria. Se puede colocar un grupo de servidores DNS detrás de una única dirección IP, solo hace falta un sencillo balanceado de carga sin estado, no se requiere ningún balanceador de carga con estado complejo (incluso sistemas de DNS superiores pueden utilizar IP-anycasting, para que una dirección IP responda desde múltiples regiones geográficas, sin estado compartido entre los sitios). Los clientes pueden y de hecho aprenden qué servidores tienen una alta tasa de respuesta y preferentemente los utiliza.

Además de esta infraestructura propensa a fallos – un mecanismo de transporte poco fiable, servidores que pueden fallar en cualquier momento y un Internet que por desgracia tiende a perder paquetes – un sistema con altas probabilidades de sobrevivir emerge, con apagones totales de DNS que rara vez ocurren. Incluso frente a adversarios, el DNS puede reforzarse de forma relativamente fácil, simplemente escalando hacia arriba y hacia fuera.

Últimos Whitepapers