Skip to content

Planificar y ejecutar una auditoría de redes SAN (Storage Area Network): aspectos fundamentales

Publicado por Sergio Hernando el 24 marzo 2011

Hola,

Justo hace un ratito he soltado un par de tuits sobre redes de almacenamiento empresariales, concretamente, sobre tejidos SAN. Me vais a permitir que emplee la palabra inglesa fabric, porque traducirla a tejido me resulta algo extraño, y además os será más fácil encontrar referencias empleando el anglicismo.

No voy a entrar mucho en la teoría, es larga y compleja, pero sí que merece la pena al menos definir un par de conceptos:

  • SAN: Storage Area Network. Es la manera más normal de referirnos a una red de área de almacenamiento, y se compone principalmente de cabinas de disco, switches para la transferencia de información y otros elementos auxiliares, como por ejemplo, las consolas centralizadas de gestión o el cableado.
  • Fibre channel: Es la topología usual en redes SAN, y generalmente está asociada a clústers informáticos de alta capacidad y con elevados requisitos de rendimiento. Es frecuente el empleo de Fibre Channel Protocol (FCP) para el transporte de comandos SCSI sobre redes de fibre channel como protocolo de operación.
  • Fabric, o tejido, el conjunto de elementos que conforman la red SAN y la manera en la que están interconectado.

Auditar una SAN

Auditar una SAN al milímetro puede ser una tarea compleja y muchas veces, injustificada. No sólo por el número de elementos y porque no deja de ser un segmento tecnológico poco conocido, sino porque además el enfoque suele estar más orientado a la configuración de seguridad que al pentesting, ya que estos elementos no suelen estar expuestos al tráfico de redes públicas (por no hablar de la escasa disponibilidad de herramientas). Aún así, habida cuenta de la existencia de pilas IP, el pentesting es factible, aunque poco útil en la mayoría de los casos si es lo único que realizamos.

Estos factores hacen muy necesario que antes de tirarnos al charco dediquemos un mínimo de tiempo a realizar una evaluación de riesgos: limitar el alcance en función a un risk assessment es siempre saludable, ya que evita incurrir en trabajos improductivos y hace que el coste de la auditoría sea efectivo. En un campo técnico complejo, donde el conocimiento no es precisamente abundante, hay que reservar tiempo para investigar y documentarse, y no malgastarlo en tareas que no ayudan a valorar el riesgo. Para rematar la faena, los fabricantes de componentes de SAN fabric han ido cada uno por su lado a la hora de desarrollar su tecnología, y en muchos casos la manera de implementar seguridad es radicalmente opuesta: este es un trabajo para realizarlo bien acompañado de white papers, referencias y guías de administración. ¿Crees que para cada montaje hay un checklist disponible? Olvídate de ello.

Y una vez planificado ¿por dónde abrimos el melón? Es ahora cuando me veo obligado a defraudar a los que esperan encontrar aquí un programa de trabajo de la A a la Z. Como he explicado, la variabilidad es tal que es imposible unificarlo todo en un artículo. Creo que puede ser más interesante dejar alguna pista, y que tú, el lector-auditor, las uses para enfocar tu trabajo. Tampoco entraré en otros detalles más de índole administrativa, como políticas, procedimientos y similares, que son extremadamente importantes, pero que no trataré en este artículo.

En esencia yo destacaría los siguientes elementos como imprescindibles a la hora de auditar una red SAN:

  • Topología. Sí, deberías haberla estudiado en la evaluación de riesgos, pero vuelvela a mirar. Aunque lo usual es que sean del tipo switched, las hay también punto a punto y de bucles arbitrados. No es usual encontrar topologías chapuceras en este campo, ya que la mayoría de clientes de este tipo de soluciones se apoya en pesonal extremendamente cualificado para desplegar redes SAN. Merece la pena, no obstante, identificar la correcta estrategia de zonas, todos los puntos de administración, las interconexiones y los posibles enlaces a redes externas, si los hubiera. Apúntate bien las IPs, te harán falta después. Especialmente relevante identificar en todos los casos los puntos de salida de la SAN, como por ejemplo, servidores NFS y servicios donde se puedan estar volcando datos procedentes de la red. Por supuesto, los sistemas destino, como sistemas que son, deben ser considerados a la hora de valorar la necesidad de auditarlos (sistemas operativos, permisos, aplicaciones de gestión, etc.)
  • Cabinas de disco. Existen al menos 3 puntos clave a la hora de auditarlas: los interfaces Web de administración (cada día más frecuentes), las líneas de mandato que pueda ofrecer el sistema operativo de gestión y los módulos de gestión del fabricante, generalmente módems que conectan con el proveedor para informar preventivamente del estado de la cabina en términos de mantenimiento. Para los interfaces Web podemos echar mil horas viendo a ver si hay XSS o no, pero esto no aporta gran cosa al riesgo. Una cabina de discos es una matriz de discos, luego los riesgos SIEMPRE están relacionados con la confidencialidad, disponibilidad e integridad de los datos que contienen, luego yo me centraría en analizar el control de acceso (usuarios por defecto que no se han eliminado, también necesario para la línea de mandatos) y en la propia configuración de seguridad declarada en el sistema. Es aquí donde toca tirar de manuales, y revisar lo que consideremos fundamental según el caso. Para los módulos de servicio del fabricante, generalmente están segregados de los datos físicamente, y en algunos casos es directamente imposible el acceso a los datos, pero merece la pena dedicarle un ratito a entender cómo se comunica la cabina con el fabricante, y cómo se orquesta la segregación entre datos y módulos de servicio.
  • Switches. Son necesarios para que la red pueda transportar información, y el enfoque es similar al de las cabinas de disco: análisis del control de acceso, y revisión de la configuración de seguridad. Cada fabricante tiene su propia manera de hacerlo, y no sería capaz de enumerarlas todas. Los switches Brocade son usuales en despliegues relevantes, aunque te los puedes encontrar QLogic, Cisco, HP ... Este es un punto interesante para la parte sociológica de la auditoría, ya que no todos los fabricantes tienen los manuales de administración disponibles en línea, y cuando están, generalmente requieren acceso con credenciales de cliente, con lo que es un buen momento para llevarse bien con el auditado, y pedirle su cooperación. Lo usual en este tipo de elementos es que haya problemas con el control de acceso, bien sea por la presencia de usuarios por defecto, contraseñas débiles, servicios innecesarios a la escucha, etc, así como la propia configuración técnica del dispositivo.
  • Logic Unit Number (LUN) Masking. El enmascaramiento LUN es un punto que cito aparte por su especial importancia. Su misión fundamental es impedir la degradación o la corrupción entre discos en la SAN, pero obviamente, puede servir para hacer la instalación más segura, habida cuenta de la posibilidad de adulterar los patrones de identificación en los adaptadores, como por ejemplo, las IPs, las MAC, etc. Conviene dedicar tiempo a entender cómo está implementado el enmascaramieto LUN y observarlo no sólo desde el punto de vista de la seguridad, sino de la propia estabilidad del montaje.
  • Enterprise Fabric Management Tools. Cada vez más frecuentes, son interfaces de control que aglutinan a todos los elementos. El razonamiento es el mismo que el anterior: si están basados en Web, control de acceso y ojo a la declaración de roles, ya que no es nada anormal encontrarse interfaces de este tipo donde todo el mundo es administrador, y cosas similares. Si admiten configuración por línea de comando, revisar puntos de acceso, control de acceso y ficheros de configuración.

Si alguien quiere un ejemplo real, SANS publicó un programa de trabajo bastante detallado para redes SAN basadas en componentes EMC. Este trabajo está específicamente orientado a cabinas Symmetrix 8730 y switches fibre channel Connectrix DS-32M, pero puede servir para ayudaros a organizar vuestros propios programas de trabajo. Las ideas que he escrito en el artículo no contienen, ni mucho menos, la totalidad de elementos que podemos someter a auditoría, con lo que si alguien quiere dejar su granito de arena es bienvenido :)

Un saludo,

Be Sociable, Share!

Categoría/s → Auditoria, Seguridad

4 comentarios
  1. 29 marzo 2011
    Ramon Pinuaga permalink

    Si te interesan este tipo de auditorias, te recomiendo el libro: “Securing Storage” de Himanshu Dwivedi. Felicidades por el Blog.

  2. 7 abril 2011
    Jesús permalink

    Falla el enlace al programa de trabajo de SANS

  3. 16 abril 2011

    @Jesús,

    Correcto. Parece que han movido algunos contenidos tras actualizar el sitio. Lamento no saber cuál es la nueva ubicación en estos momentos.

    Busca por el sitio de SANS de vez en cuando, es posible que lo vuelvan a indexar en breve.

    Saludos,

Trackbacks & Pingbacks

  1. de la red – 26/03/2011 « Tecnologías y su contexto

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS