Duplicidad Tecnológica

En el Blog solemos hablar más de técnicas ofensivas que de técnicas defensivas. Aunque está claro que ambas son igual de importantes en caso de conflicto, las de ataque suelen ser más “divertidas”. Hoy sin embargo vamos a analizar una técnica de ingeniería de computadores destinada a mejorar su resistencia frente a ataques.

A la hora de diseñar un sistema informático crítico siempre se suele acudir a medidas que eviten la existencia de puntos únicos de fallo que puedan provocar un corte del servicio ofrecido.

La técnica de protección más habitual para esto es la Redundancia, que consiste en disponer de 2 o más sistemas similares para la realización de una misma tarea. De esta forma si uno de los sistemas falla, estarán listos otros para sustituirlo.

La Redundancia se puede aplicar duplicando equipos o duplicando los componentes hardware de los mismos. De esta forma ciertas partes del sistema pueden fallar sin que esto afecte al funcionamiento del mismo.

Hay diversas formas de distribución de equipos redundantes:
• En línea: Todos los equipos que forman el sistema redundante están activos y es el cliente del servicio el que elige cual utilizar.
• Balanceo de carga: Todos los equipos del sistema están activos, pero la carga de trabajo se reparte automáticamente entre ellos.
• En stand-by: Los equipos de reserva se encuentran inactivos y se activan cuando el equipo principal falla.

Cualquiera de estas alternativas es válida para garantizar la continuidad del servicio cuando hablamos de fallos “naturales”, pero puede que no sean suficientes cuando estamos hablando de fallos provocados por ataques intencionados.

En estos casos la Redundancia puede ser vulnerada. Por ejemplo si un atacante ha conseguido hacer caer un sistema principal ¿Qué le impide hacer lo mismo cuando entren en funcionamiento los equipos de reserva, si son iguales?

Por eso en seguridad de sistemas críticos además de medidas de Redundancia se suelen utilizar medidas de Duplicidad tecnológica.

Hablamos de Duplicidad tecnológica cuando se utilizan 2 o más sistemas diferentes (que utilizan tecnologías diferentes) para ofrecer el mismo servicio. Por ejemplo cuando tenemos 2 servidores Web que albergan las mismas páginas, pero que ejecutan software diferente.

La razón de utilizar 2 tecnologías diferentes es que si aparece una vulnerabilidad de software en una de ellas, esta no afectara a la otra.

Supongamos por ejemplo el caso de una red crítica, en la que tenemos 2 servidores de nombres DNS basados en Windows. Estos utilizan un diseño redundante que hace que cuando uno cae el otro toma su lugar, de forma que el servicio siempre esté disponible para el resto de equipos de la red. Pero por simplificar su gestión, ambos utilizan la misma versión de Windows y la misma configuración.

Si un día aparece una vulnerabilidad 0-day en Windows, ambos equipos podrían ser comprometidos mientras no se publicase el parche oficial. Y no existiría la opción de desconectarlos de la red ya que el resto de equipos se quedaría sin servicio.

Para esta situación, lo ideal sería tener un tercer equipo basado en Linux que pudiese dar un servicio de DNS equivalente. De esta forma si apareciese una vulnerabilidad en los sistemas Windows, estos podrían desconectarse de la red mientras son parcheados y el Linux ocuparía su función de forma segura.

El diseño en Duplicidad Tecnológica también es muy recomendable cuando se configura un sistema de protección (por ejemplo una barrera de cortafuegos). En estos diseños, lo ideal suele ser disponer de 2 capas de cortafuegos, una primera capa basada en tecnología de un fabricante y una segunda capa basada en tecnología de otro fabricante distinto.

De esta forma si se descubre una vulnerabilidad que permite saltarse los controles de seguridad del software de uno de los fabricantes, probablemente no afecte al otro.

Pero hay que tener cuidado con estas decisiones ya que algunos fabricantes utilizan tecnologías similares que si podrían ser vulnerables a los mismos ataques. Por ejemplo podríamos decidir utilizar 2 servidores Web, uno basado en Apache HTTP Server y otro basado en IBM HTTP Server, sin ser conscientes de que el segundo utiliza muchos componentes del primero.

La mayor pega de estos diseños es su alto coste. Ya que no solo aumentamos el coste de disponer de equipos adicionales, sino que al ser tecnologías diferentes probablemente tengamos que disponer de personal técnico diferente. Aunque de cara a la gestión de la seguridad esto también sería una ventaja.

Otra desventaja de tener 2 tecnologías diferentes es que tendremos el doble de probabilidades de que aparezcan vulnerabilidades (y el doble de trabajo de securización). Por eso cuando se aplica Duplicidad Tecnológica se recomienda trabajar con una distribución en stand-by, de forma que los equipos no activos se encuentren desconectados de la red para que no puedan ser atacados.