La red definida por software (SDN) se está moviendo rápidamente de la visión a la realidad con una serie de dispositivos SDN habilitados en desarrollo y producción. La combinación del control separado y la funcionalidad del plano de datos y la programabilidad en la red, que se han debatido durante mucho tiempo, han encontrado su aplicación comercial en la computación en la nube y las tecnologías de virtualización.
Las ventajas de SDN en varios escenarios y en varias redes de backbone ya se han sido probadas con exito. Sin embargo, existen grandes desafíos para una implementación de red de operador a gran escala a traves de SDN (Pero ojo, grandes desafios solo), y dentro de estos, un área clave, que apenas comienza a recibir la atención que merece, la seguridad en SDN.
La arquitectura SDN se puede aprovechar para mejorar la seguridad de la red con la provisión de un sistema de monitorización, análisis y respuesta de seguridad altamente reactivo. Siendo el controlador central una pieza clave para este sistema. El análisis de tráfico o los métodos de detección de anomalías mediante sondas implementadas en la red, generan datos relacionados con la seguridad, que pueden transferirse regularmente al controlador central. Las aplicaciones se pueden ejecutar en el controlador para analizar y correlacionar estos datos de la red. Con base en el análisis, la política de seguridad nueva o actualizada se puede propagar a través dicho controlador de la red en forma de reglas de flujo. Este enfoque consolidado puede acelerar de manera eficiente el control y la contención de las amenazas a la red y su seguridad.
Sin embargo, los mismos atributos de control centralizado y programabilidad asociados con la plataforma SDN presenta desafíos de seguridad de la red. Un mayor potencial para los ataques de Denegación de Servicio (DoS) debido al controlador centralizado y la limitación de la tabla de flujo en los dispositivos de red es un ejemplo perfecto. Otro tema de preocupación basado en la programabilidad abierta de la red es la confianza entre las aplicaciones y los controladores, y entre los controladores y los dispositivos de red.
Se han propuesto varias soluciones a estos desafíos de seguridad SDN en muchos textos academicos y de grandes profesionales, donde estos van desde los esquemas de replicación del controlador hasta la resolución de conflictos de políticas y los mecanismos de autenticación. Del mismo modo, se han realizado una serie de propuestas para explotar el Framework SDN para mejorar la seguridad de la red.
Hoy trataremos los problemas de seguridad según la capa SDN afectada o dirigida, he intentaremos clasificarlos, ya que sin un aumento significativo del enfoque en la seguridad, SDN no podrá soportar la capacidad de evolución asociada con otras variantes como por ejemplo, Virtualización de Funciones de Red (NFV).
Seguridad en SDN
Las propiedades básicas de una red de comunicaciones segura son:
- confidencialidad
- integridad
- disponibilidad de información
- autenticación
- no repudio.
Para proporcionar una red protegida contra ataques maliciosos o daños no intencionales, los profesionales de la seguridad debemos proteger los datos, los activos de la red (por ejemplo, los dispositivos) y las transacciones de comunicación a través de la misma. Las modificaciones en la arquitectura de red introducidas por SDN deben evaluarse para garantizar que la seguridad de la red se mantiene.
En una iteración temprana de lo que hoy se conoce como SDN, consideraró específicamente los aspectos de seguridad de un Framework separado entre el control y el reenvío. Su arquitectura SANE, propuesta en 2006, se centró en un controlador lógicamente centralizado responsable de la autenticación de los hosts y la aplicación de políticas. En el momento de su propuesta, se consideró que era un enfoque extremo que requeriría un cambio radical en la infraestructura de red y los hosts finales, lo que podría ser demasiado restrictivo para algunas empresas.
Ethane extendió el trabajo de SANE pero utilizó un enfoque, que requirió una menor alteración de la red original. Controlaba la red mediante el uso de dos componentes; un controlador centralizado responsable de forzar la política global, y conmutadores etano, que simplemente reenviaban paquetes basados en reglas en una tabla de flujo. Este control simplificado de la red permitió separar los datos y el plano de control para permitir más programabilidad. Aunque la arquitectura de Ethane nos dio una mirada más cercana a lo que lo que SDN y OpenFlow se convertirían, sufrió de una serie de inconvenientes y problemas. Uno de estos es el hecho de que el tráfico de la aplicación podría comprometer la política de la red. En la arquitectura SDN actual, las aplicaciones se utilizan para proporcionar diversos servicios, como, por ejemplo, Virtualización de Funciones de Red (NFV).
El compromiso de las aplicaciones podría afectar a toda la red.
Teniendo en cuenta los problemas específicos de seguridad en SDN desde la perspectiva del framework SDN , podemos identificar los desafíos asociados con cada capa del marco: aplicación, control y planos de datos, y en las interfaces entre estas diferentes capas.
Recientemente se han realizado una serie de análisis de seguridad, que han encontrado que los elementos alterados o la relación entre elementos en el Framework SDN presentan nuevas vulnerabilidades, que no estaban presentes antes de SDN. Uno de esos documentos completa un análisis del protocolo OpenFlow utilizando la metodología de análisis de amenazas STRIDE. La especificación del interruptor OpenFlow describe el uso de la seguridad en la capa de transporte (TLS) con la autenticación mutua entre los controladores y sus conmutadores. Sin embargo, la función de seguridad es opcional y no se especifica el estándar de TLS. La falta de adopción de TLS por parte de los principales proveedores y la posibilidad de ataques DoS son el foco de una evaluación de vulnerabilidad de OpenFlow y algo a tener muy en cuenta. La falta de uso de TLS podría conducir
a la inserción fraudulenta de reglas y modificación de las mismas, con lo que ello conlleva.
Debido a la naturaleza del controlador centralizado y la programabilidad de la red, se introducen nuevas amenazas que requieren nuevas respuestas. Proponen una serie de técnicas para abordar las diversas amenazas,
incluyendo replicación, diversidad y componentes seguros.
Los resultados generales indican el rango de
los problemas de seguridad asociados con el Framework SDN son preocupantes si perdemos el foco de la seguridad de los mismo, donde las capas de control y datos se identifican como objetivos claros de posibles ataques.
Mejoras de la seguridad con SDN
La arquitectura de una red definida por software introduce un increible potencial de innovación en el uso de la red. La combinación de la vista global o de toda la red y la programabilidad de la red respalda el proceso de recopilación de inteligencia de los sistemas de detección de intrusiones (IDS) y los sistemas de prevención de intrusiones (IPS) existentes, seguido del análisis y la reprogramación centralizada de la red. Este enfoque puede hacer que la SDN sea más robusta para los ataques maliciosos que las redes tradicionales.
Una SDN con el controlador integrado en los IDS/IPS , es más segura que las redes tradicionales
El sistema intermedio SDN
Las redes tradicionales utilizan sistemas intermedios para proporcionar funciones de seguridad de red. Recientemente, se ha debatido sobre la integración de los "middle-boxes" de seguridad en SDN que explotan el beneficio de la programabilidad para redirigir el tráfico de red seleccionada a través de estos sistemas intermedios. Por ejemplo, la arquitectura Slick propone un controlador centralizado, que se encarga de instalar y migrar funciones en cuadros intermedios personalizados. Las aplicaciones pueden dirigir al controlador Slick para que instale las funciones necesarias para enrutar flujos particulares en función de los requisitos de seguridad.
La arquitectura FlowTags propone el uso de sistemas intermedios mínimamente modificadas, que interactuen con un controlador SDN a través de una Interfaz de programación de aplicaciones FlowTags (API). Los diagramas de flujo, que consisten en información de flujo de tráfico, están integrados en los encabezados de los paquetes para proporcionar un seguimiento del flujo y permitir el enrutamiento controlado de los paquetes etiquetados. Una clara desventaja de esta arquitectura es el hecho de que funciona solo con políticas predefinidas y actualmente no maneja acciones dinámicas.
La capa SIMPLE de aplicación de políticas es un enfoque para usar SDN para administrar despliegues de middlebox, que a diferencia de las anteriores, no requiere modificaciones de las capacidades SDN o la funcionalidad del cuadro central, lo que la hace las mas adecuada para los sistemas legacy antíguos.
Con base en estas propuestas, parecería que un enfoque simple para la provisión de seguridad de la red sería introducir un elemento/sistema intermedio apropiado y programar la red para dirigir el tráfico seleccionado a través del cuadro central. Sin embargo, no es tan simple como esto. La ubicación e integración apropiadas de los sistemas intermedios SDN debe determinarse teniendo en cuenta la penalización del rendimiento que puede tolerarse cuando el tráfico se desvía a través de un enlace o elemento adicional (Añadimos resistencia y latencia cada vez que metemos un nuevo elemento), estas cuestiones y preguntas aún no han sido resueltas, pero debemos plantearnoslas desde un inicio.
Debemos saber lo que queremos, pero tambien cómo lo queremos
Sin embargo, el rango de ataques que representan una amenaza para la red es bastante amplio, y más allá de los sistemas intermedios, debemos buscar una serie de soluciones que exploten específicamente el marco SDN para proporcionar soluciones de seguridad a nuestra red.
Definiendo la seguridad en SDN
Los atacantes usan varias técnicas de escaneo para descubrir objetivos vulnerables en la red. Una defensa presentada para frustrar estos ataques es el uso de direcciones Virtuales del Protocolo de Internet (IP) al azar usando SDN. Esta técnica utiliza el controlador OpenFlow para administrar un conjunto de direcciones IP virtuales, que se asignan a los hosts dentro de la red, ocultando las direcciones IP reales del mundo exterior. Esto presenta una defensa móvil en movimiento, que es una forma de ciberseguridad adaptativa.
Los sistemas de monitorización son esenciales para proteger la red de posibles ataques. Una forma específica de sistema de monitoreo, el IDS, ha sido el foco de varias soluciones de SDN. Skowyra proponen un aprendizaje IDS, que utiliza la arquitectura SDN para detectar y responder a ataques de red en dispositivos móviles integrados. Un esquema NIDS acelerado por hardware (IDS de red) o NIPS (IPS de red), permitiendo al administrador de red configurar patrones de cadena para su uso por un módulo de inspección profunda de paquetes (DPI).
La posibilidad de mejorar y simplificar la seguridad de la red SDN es evidente y por ello veremos y vemos proximamente multitud de productos comerciales con una gama de productos de seguridad SDN en diversas etapas de desarrollo.
Conclusiones de seguridad con SDN
Hay dos escuelas o movimientos de pensamiento sobre seguridad en las redes definidas por software. La primera es que se pueden lograr mejoras significativas en la seguridad de la red explotando simultáneamente la programabilidad y la vista de red centralizada introducida por SDN. El segundo es que estos mismos dos atributos SDN exponen la red a un rango de nuevos ataques. Hemos categorizado los desafíos de seguridad de SDN. El análisis identifica que, independientemente de nuestra escuela de pensamiento, aún queda mucho por hacer; mucho potencial sin explotar y muchos desafíos sin resolver. Un esfuerzo concertado en ambas direcciones podría generar una Red Definida por Software verdaderamente segura y confiable.
