Defensa contra ataques
La figura siguiente muestra los componentes de virtualización que constituyen el “entorno de ejecución” de Oracle VM Server for SPARC. Estos componentes no están estrictamente separados. La configuración más sencilla es combinar todas estas funciones en un único dominio. El dominio de control también puede actuar como un dominio de E/S y un dominio de servicio para otros dominios.
Figura 1-3 Componentes del entorno de ejecución
Es posible que un atacante intente vulnerar el aislamiento del sistema y manipular el hipervisor u otro componente del entorno de ejecución para acceder a un dominio invitado. Por eso debe proteger cada dominio invitado del mismo modo que protegería cualquier servidor independiente.
En el resto de este capítulo, se presentan posibles amenazas y las distintas medidas que puede tomar para hacerles frente. Cada uno de estos ataques tiene por objeto traspasar o eliminar el aislamiento de los diferentes dominios que se ejecutan en una sola plataforma. En las siguientes secciones, se describen las amenazas que puede recibir cada parte de un sistema de Oracle VM Server for SPARC:
Entorno operativo
El entorno operativo incluye los sistemas físicos y sus componentes, y también a los arquitectos de centros de datos, los administradores y los miembros de la organización de TI. Una infracción de seguridad se puede producir en cualquier punto del entorno operativo.
Mediante la virtualización, se coloca una capa de software entre el hardware real y los dominios invitados que ejecutan los servicios de producción, lo cual eleva la complejidad. Por lo tanto, debe planificar cuidadosamente, configurar el sistema virtual y considerar los errores humanos. Además, debe tener en cuenta que los atacantes pueden intentar acceder al entorno operativo mediante el uso de "ingeniería social".
En las siguientes secciones, se describen las distintas amenazas contra las que tendrá que luchar en el nivel del entorno operativo.
Amenaza: errores involuntarios de configuración
El principal problema de seguridad en un entorno virtualizado es mantener el servidor aislado separando segmentos de redes, segregando el acceso administrativo e implementando servidores en clases de seguridad, que son grupos de dominios que tienen los mismos privilegios y requisitos de seguridad.
Crear canales de comunicación innecesarios entre los dominios invitados de producción y el entorno de ejecución
Crear acceso innecesario a segmentos de red
Crear conexiones no intencionales entre las clases de seguridad discretas
Migrar un dominio invitado a la clase de seguridad equivocada de manera no intencional
Asignar hardware insuficiente, lo cual puede ocasionar una sobrecarga inesperada de los recursos
Asignar discos o dispositivos de E/S al dominio incorrecto
Configure cuidadosamente los recursos virtuales a fin de evitar los siguientes errores:
Contramedida: creación de directrices operativas
Gestión de parches para todos los componentes del entorno
Implementación de los cambios de manera segura, que incluya un seguimiento y esté claramente definida
Comprobación de los archivos de registro con una frecuencia regular
Supervisión de la integridad y la disponibilidad del entorno
Antes de empezar, defina cuidadosamente las directrices operativas para su entorno de Oracle VM Server for SPARC. En estas directrices, se describen las siguientes tareas y su modo de ejecución:
Debe realizar comprobaciones con regularidad para asegurarse de que estas directrices permanezcan actualizadas y sean adecuadas, y para verificar que se estén cumpliendo en las operaciones diarias.
Además de estas directrices, puede que se requieran muchas otras medidas técnicas para reducir el riesgo de que se realicen acciones no intencionales. Consulte Administrador de Dominios lógicos.
Amenaza: errores en la arquitectura del entorno virtual
Cuando mueve un sistema físico a un entorno virtualizado, por lo general, puede mantener la misma configuración de almacenamiento si utiliza los LUN originales. Sin embargo, la configuración de red debe adaptarse al entorno virtualizado, y la arquitectura resultante puede diferir considerablemente de la arquitectura utilizada en el sistema físico.
Debe tener en cuenta cómo mantener el aislamiento de las clases de seguridad discretas y sus necesidades. Además, tenga en cuenta el hardware compartido de la plataforma y los componentes compartidos, como los conmutadores de red y los conmutadores SAN.
Para maximizar la seguridad de su entorno, asegúrese de mantener el aislamiento de los dominios invitados y las clases de seguridad. Cuando diseñe la arquitectura, anticípese a posibles errores y ataques, e implemente líneas de defensa. Un buen diseño ayuda a limitar posibles problemas de seguridad, además de controlar la complejidad y los costos.
Contramedida: asignación cuidadosa de dominios invitados a plataformas de hardware
Use clases de seguridad, que son grupos de dominios que tienen los mismos privilegios y requisitos de seguridad, para aislar dominios individuales entre sí. Mediante la asignación de dominios invitados que estén en la misma clase de seguridad a una determinada plataforma de hardware, incluso una brecha de aislamiento evita que el ataque alcance a otra clase de seguridad.
Contramedida: planificación de la migración de dominios de Oracle VM Server for SPARC
La función de migración de dominio en tiempo real puede vulnerar el aislamiento si un dominio invitado se migra de manera inadvertida a una plataforma asignada a una clase de seguridad diferente, como se muestra en la figura siguiente. Por lo tanto, de planificar cuidadosamente la migración de dominio invitado a fin de garantizar que no se permita realizar una migración que traspase los límites de las clases de seguridad.
Figura 1-4 Migración de dominio que traspasa los límites de seguridad
Para minimizar o eliminar la vulnerabilidad de seguridad que presenta la operación de migración, debe intercambiar e instalar manualmente todos los certificados de host generados por ldmd fuera de banda entre cada par de equipos de origen y de destino. Para obtener información sobre cómo configurar los certificados SSL, consulte Configuración de certificados SSL para migración de Guía de administración para Oracle VM Server for SPARC 3.3 .
Contramedida: configuración correcta de conexiones virtuales
La pérdida de registro de todas las conexiones de red virtual puede hacer que un dominio obtenga acceso erróneo a un segmento de red. Por ejemplo, un acceso que burle el firewall o una clase de seguridad.
Para reducir el riesgo de errores de implementación, planifique cuidadosamente y documente todas las conexiones virtuales y físicas del entorno. Optimice el plan de conexión de dominio para obtener más simplicidad y mejor capacidad de gestión. Documente claramente el plan y compruebe la precisión de la implementación en función del plan antes de entrar en producción. Incluso una vez que su entorno virtual esté en producción, verifique la implementación en función del plan con regularidad.
Contramedida: uso de etiquetas en VLAN
Puede utilizar etiquetas en VLAN para consolidar varios segmentos Ethernet en una única red física. Esta función también está disponible para los conmutadores virtuales. Para mitigar los riesgos que conllevan los errores de software en la implementación de los conmutadores virtuales, configure un conmutador virtual por VLAN y NIC física. Si desea agregar protección contra errores en el controlador Ethernet, no utilice VLAN con etiquetas. Sin embargo, la probabilidad de que se produzcan estos errores es baja, ya que esta vulnerabilidad de VLAN con etiquetas es muy conocida. Las pruebas de intrusión en la plataforma de Sun SPARC T-Series, de Oracle, con el software de Oracle VM Server for SPARC no muestran esta vulnerabilidad.
Contramedida: uso de aplicaciones de seguridad virtuales
Las aplicaciones de seguridad, como los filtros de paquetes y los firewalls, son instrumentos de aislamiento y protegen el aislamiento de las clases de seguridad. Estas aplicaciones son vulnerables a las mismas amenazas que cualquier otro dominio invitado, de modo que su uso no garantiza una protección completa contra una brecha de aislamiento. Por lo tanto, tenga en cuenta todos los aspectos de riesgo y seguridad antes de decidir si desea virtualizar un servicio así.
Amenaza: efectos secundarios del uso compartido de recursos
El uso compartido de recursos en un entorno virtualizado puede provocar ataques de denegación de servicio (DoS), lo cual sobrecarga un recurso hasta que se afecta negativamente otro componente, por ejemplo, otro dominio.
Hiperpaginación de las áreas de caché que se comparten entre hilos y se asignan a dos dominios invitados
La sobrecarga del ancho de banda de la memoria
En un entorno de Oracle VM Server for SPARC, solamente algunos recursos pueden verse afectados por un ataque de denegación de servicio. La CPU y los recursos de memoria se asignan exclusivamente a cada dominio invitado, lo cual impide la mayoría de los ataques de denegación de servicio. Incluso la asignación exclusiva de estos recursos puede ralentizar un dominio invitado mediante lo siguiente:
A diferencia de la CPU y los recursos de memoria, el disco y los servicios de red, generalmente, se comparten entre dominios invitados. Estos servicios se proporcionan a los dominios invitados mediante uno o más dominios de servicio. Analice detalladamente cómo asignar y distribuir estos recursos entre los dominios invitados. Tenga en cuenta que cualquier configuración que permita alcanzar el máximo rendimiento y uso de recursos a la vez minimiza el riesgo de efectos secundarios.
Evaluación: efectos secundarios del uso compartido de recursos
Se puede saturar un enlace de red o se puede sobrecargar un disco, ya sea que estén asignados exclusivamente a un dominio o se compartan entre dominios. Estos ataques afectan la disponibilidad de un servicio mientras dure el ataque. El blanco de ataque no se ve comprometido, y no se pierden datos. Los efectos de esta amenaza se pueden minimizar fácilmente, pero debe tenerla en cuenta aunque esté limitada a los recursos de red y de disco en Oracle VM Server for SPARC.
Contramedida: asignación cuidadosa de los recursos de hardware
Asegúrese de asignar solamente los recursos de hardware necesarios para dominios invitados. Asegúrese de anular la asignación de un recurso cuando ya no sea necesario; por ejemplo, un puerto de red o una unidad de DVD que se requiera solamente durante una instalación. Si esto se pone en práctica, se minimiza la cantidad de puntos de entrada que puede usar un atacante.
Contramedida: asignación cuidadosa de los recursos compartidos
Los recursos de hardware compartidos, como los puertos de red física, pueden ser un blanco vulnerable a los ataques de denegación de servicio. Para limitar el impacto de los ataques de denegación de servicio a un único grupo de dominios invitados, determine con cuidado qué dominios invitados comparten qué recursos de hardware.
Por ejemplo, los dominios invitados que comparten recursos de hardware se pueden agrupar según tengan la misma disponibilidad o los mismos requisitos de seguridad. Además de esta agrupación, puede aplicar diferentes tipos de controles de recursos.
Debe tener en cuenta cómo compartir los recursos de red y de disco. Puede mitigar los problemas separando el acceso al disco mediante rutas de acceso físico dedicado o servicios de disco virtual dedicado.
Resumen: efectos secundarios del uso compartido de recursos
Todas las contramedidas descritas en esta sección requieren que se comprendan todos los detalles técnicos de su implementación y sus consecuencias para la seguridad. Planifique con cuidado, elabore bien la documentación y mantenga la arquitectura tan simple como sea posible. Asegúrese de comprender las consecuencias del hardware virtualizado, de modo que pueda prepararse para implementar el software Oracle VM Server for SPARC de manera segura.
Los dominios lógicos pueden combatir los efectos de uso compartido de la CPU y la memoria, y en realidad el uso compartido es poco. No obstante, es conveniente aplicar controles de recursos, como la gestión de recursos de Solaris en los dominios invitados. El uso de estos controles brinda protección contra el mal comportamiento de la aplicación, ya sea en entornos virtuales o en entornos no virtualizados.
Entorno de ejecución
En Figure 1–3, se muestran los componentes del entorno de ejecución. Cada componente proporciona determinados servicios que, en conjunto, forman la plataforma general en la que se ejecutarán los dominios invitados de producción. Configurar correctamente los componentes es de vital importancia para la integridad del sistema.
Todos los componentes del entorno de ejecución pueden ser puntos vulnerables para un atacante. En esta sección, se describen las amenazas que podrían afectar a cada componente en el entorno de ejecución. Algunas amenazas y contramedidas se pueden aplicar a más de un componente.
Amenaza: manipulación del entorno de ejecución
Mediante la manipulación del entorno de ejecución, puede obtener el control de diversas maneras. Por ejemplo, puede instalar firmware manipulado en el ILOM para que busque en todos los dominios invitados de E/S desde adentro de un dominio de E/S. Mediante tal ataque, se puede acceder al sistema y cambiarle la configuración. Un atacante que asume el control de un dominio de control de Oracle VM Server for SPARC puede volver a configurar el sistema de cualquier manera y un atacante que asume el control de un dominio de E/S puede hacer cambios en dispositivos de almacenamiento conectados, como los discos de inicio.
Evaluación: manipulación del entorno de ejecución
Un atacante que logre acceder al ILOM o a cualquier dominio en el entorno de ejecución puede leer y manipular todos los datos que estén disponibles para el dominio. Este acceso se puede obtener mediante la red o por medio de un error en la pila de virtualización. Es difícil perpetrar un ataque así, ya que normalmente no se puede atacar directamente el ILOM y los dominios.
Las contramedidas para protegerse contra la manipulación del entorno de ejecución son la práctica de seguridad estándar y deben implementarse en todos los sistemas. Las prácticas de seguridad estándar presentan una capa de protección adicional de todo el entorno de ejecución que reduce aún más el riesgo de intrusiones y manipulación.
Contramedida: protección de rutas de acceso interactivo
Asegúrese de crear solamente cuentas que sean necesarias para las aplicaciones que se ejecutan en el sistema.
Asegúrese de que las cuentas que son necesarias para la administración estén protegidas mediante la autenticación basada en claves o contraseñas seguras. Estas claves o contraseñas no se deben compartir entre diferentes dominios. Asimismo, considere la posibilidad de implementar la autenticación de dos factores o la "regla de dos personas" para tomar ciertas medidas.
No utilice el inicio de sesión anónimo como root para garantizar la total rastreabilidad y responsabilidad de los comandos que se ejecutan en el sistema. En su lugar, utilice derechos para otorgar acceso a administradores individuales solamente para las funciones que ellos pueden llevar a cabo. Asegúrese de que el acceso a redes administrativas siempre use cifrado, como SSH, y de que la estación de trabajo de un administrador se trate como un sistema de alta seguridad.
Contramedida: minimización del SO Oracle Solaris
Cualquier software que esté instalado en un sistema puede estar en peligro. Por lo tanto, sebe asegurarse de instalar solamente el software necesario para minimizar las posibilidades de vulneración.
Contramedida: refuerzo de la protección del SO Oracle Solaris
Además de instalar una versión minimizada del SO Oracle Solaris , configure los paquetes a fin de “reforzar” la protección del software contra los ataques. Primero, ejecute servicios de red limitados para desactivar eficazmente todos los servicios de red, salvo SSH. Esta política es el comportamiento predeterminado en los sistemas Oracle Solaris 11. Para obtener información sobre cómo proteger el SO Oracle Solaris , consulte Oracle Solaris 10 Security Guidelines y Oracle Solaris 11 Security Guidelines .
Contramedida: uso de la separación de roles y el aislamiento de aplicaciones
Según la necesidad, las aplicaciones de producción están conectadas a otros sistemas y, como resultado, están más expuestas a ataques externos. No implemente aplicaciones de producción en un dominio que forme parte del entorno de ejecución. En su lugar, asegúrese de implementarlas solamente en dominios invitados que no tengan más privilegios.
El entorno de ejecución sólo debe proporcionar la infraestructura necesaria para estos dominios invitados. La separación del entorno de ejecución de las aplicaciones de producción permite implementar la granularidad en la administración de privilegios. Un administrador de dominio invitado de producción no requiere acceso al entorno de ejecución y un administrador del entorno de ejecución no necesita acceso a los dominios invitados de producción. Si es posible, asigne los distintos roles del entorno de ejecución, como el dominio de control y el dominio de E/S, en diferentes dominios. Este tipo de configuración reduce la magnitud del daño que puede generarse si cualquiera de estos dominios recibe un ataque.
También puede ampliar la separación de roles en el entorno de red que se utiliza para conectar los distintos servidores.
Contramedida: configuración de una red de gestión dedicada
Conecte todos los servidores que estén equipados con procesadores de servicio (SP) a una red de gestión dedicada. Esta configuración también se recomienda para los dominios del entorno de ejecución. Si los dominios estarán en red, alójelos en su propia red dedicada. No conecte los dominios del entorno de ejecución directamente en las redes que se asignan a los dominios de producción. Aunque puede realizar todo el trabajo administrativo mediante una única consola de conexión que está disponible mediante el SP del ILOM, esta configuración complica la administración de modo tal que no se puede llevar a la práctica. Si se separan las redes de administración y de producción, se obtiene protección contra intrusiones y manipulaciones. Con esta separación, también se elimina la posibilidad de ataque en el entorno de ejecución de los dominios invitados por la red compartida.
Figura 1-5 Red de gestión dedicada
ILOM
Gestiona los controles básicos del entorno, como la velocidad del ventilador y la energía del chasis
Permite actualizar el firmware
Proporciona la consola del sistema para el dominio de control
Todos los sistemas Oracle SPARC de la actualidad incluyen un controlador integrado del sistema (ILOM) que tiene las siguientes capacidades:
Puede acceder al ILOM mediante una conexión serie o, para acceder mediante un puerto de red, puede usar SSH, HTTP, HTTPS, SNMP o IPMI. Los Servidores de Fujitsu M10 utilizan XSCF en lugar de ILOM para realizar funciones similares.
Amenaza: total denegación del servicio del sistema
Cortando el suministro de energía de todos los dominios invitados en ejecución
Instalando firmware manipulado para obtener acceso a al menos a un dominio invitado
Un atacante que obtiene control del ILOM puede poner en peligro el sistema de muchas maneras, incluidas las siguientes:
Estos escenarios se aplican a cualquier sistema que tenga un dispositivo controlador. En un entorno virtualizado, los daños pueden ser mucho mayores que en un entorno físico porque muchos dominios que se alojan en el mismo contenedor del sistema pueden estar en riesgo.
Del mismo modo, un atacante que asume el control del dominio de control o de un dominio de E/S puede desactivar fácilmente todos los dominios invitados dependientes y cerrar así los servicios de E/S correspondientes.
Evaluación: total denegación del servicio del sistema
Aunque el ILOM suele estar conectado a una red administrativa, también puede acceder al ILOM desde el dominio de control mediante IPMI con el módulo de acceso de BMC. Por lo tanto, ambas conexiones deben estar bien protegidas y aisladas de las redes de producción comunes.
Asimismo, un atacante puede vulnerar un dominio de servicio desde la red o por un error en la pila de virtualización y, a continuación, bloquear un dominio invitado de E/S o cerrar el sistema. Aunque los daños son limitados porque los datos no se pierden ni se ponen en riesgo, una gran cantidad de dominios invitados pueden verse afectados. Por lo tanto, establezca protección contra esta amenaza latente para limitar los posibles daños.
Contramedida: protección del ILOM
Colocar el puerto de red del ILOM en un segmento de red que esté separado de la red administrativa, que se utiliza para los dominios en el entorno de ejecución.
Desactivar todos los servicios que no sean necesarios para realizar operaciones, como HTTP, IPMI, SNMP, HTTPS y SSH.
Configurar cuentas de administrador personales y dedicadas que otorguen solamente los derechos requeridos. Para maximizar la responsabilidad de las acciones realizadas por los administradores, asegúrese de crear cuentas de administrador personales. Este tipo de acceso es especialmente importante para el acceso a la consola, las actualizaciones de firmware y la gestión de configuraciones de inicio.
Como el procesador de servicio del sistema, el ILOM controla funciones críticas, como el suministro de energía del chasis, las configuraciones de Oracle VM Server for SPARC y el acceso de la consola al dominio de control. Las siguientes medidas permiten proteger el ILOM:
Hipervisor
El hipervisor real, que se implementa en el firmware y es compatible con las CPU de los sistemas.
Los módulos de núcleo que se ejecutan en el dominio de control para configurar el hipervisor.
Los módulos de núcleo y los daemons que se ejecutan en los dominios de E/S y los dominios de servicio para proporcionar E/S virtualizada, y los módulos de núcleo que se comunican por medio de canales de dominio lógico (LDC).
Los módulos de núcleo y los controladores de dispositivos que se ejecutan en los dominios invitados para acceder a dispositivos de E/S virtualizados y los módulos de núcleo que se comunican por medio de los LDC.
El hipervisor es la capa de firmware que implementa y controla la virtualización del hardware real. El hipervisor incluye los siguientes componentes:
Amenaza: vulneración del aislamiento
Un atacante puede usurpar los dominios invitados o todo el sistema vulnerando el entorno de tiempo de ejecución aislado que proporciona el hipervisor. Potencialmente, esta amenaza puede causar los daños más graves en el sistema.
Evaluación: vulneración del aislamiento
El diseño de un sistema modular puede mejorar el aislamiento mediante el otorgamiento de diferentes niveles de privilegios a los dominios invitados, el hipervisor y el dominio de control. Cada módulo funcional se implementa en un módulo de núcleo, controlador de dispositivo o daemon configurable e independiente. Esta modularidad requiere API limpias y protocolos de comunicación simples, lo cual reduce el riesgo de errores en general.
Incluso si parece poco probable que se vulnere un error, con los daños potenciales un atacante puede tomar el control de todo el sistema.
Contramedida: validación de firmas de software y firmware
Aunque se pueden descargar el firmware del sistema y los parches del sistema operativo directamente desde un sitio web de Oracle, estos parches se pueden manipular. Antes de instalar el software, asegúrese de verificar las sumas de comprobación MD5 de los paquetes de software. Oracle publica las sumas de comprobación de todo el software descargable.
Contramedida: validación de los módulos de núcleo
Oracle VM Server for SPARC utiliza varios módulos de núcleo y controladores para implementar la virtualización general del sistema. Los módulos de núcleo y la mayoría de los archivos binarios que se distribuyen con el SO Oracle Solaris incluyen una firma digital. Utilice la utilidad elfsign para comprobar la firma digital de cada módulo de núcleo y controlador. Puede utilizar el comando pkg verify de Oracle Solaris 11 para comprobar la integridad del archivo binario de Oracle Solaris . Consulte https://blogs.oracle.com/cmt/entry/solaris_fingerprint_database_how_it.
Primero, debe establecer la integridad de la utilidad elfsign. Use la herramienta básica de creación de informes de auditoría (BART) para automatizar el proceso de verificación de firma digital. En Integrating BART and the Solaris Fingerprint Database in the Solaris 10 Operating System, se describe cómo combinar la BART y la base de datos de huellas de Solaris para realizar automáticamente comprobaciones de integridad similares. Aunque la base de datos de huellas se haya discontinuado, los conceptos que se describen en este documento se pueden poner en práctica de un modo similar mediante el uso de elfsign y la BART.
Dominio de control
El dominio de control, que a menudo tiene los roles de un dominio de E/S y un dominio de servicio, se deben mantener a salvo porque puede modificar la configuración del hipervisor, el cual controla todos los recursos de hardware conectados.
Amenaza: denegación de servicio de dominio de control
El cierre del dominio de control puede provocar una denegación de servicio de las herramientas de configuración. Debido a que el dominio de control sólo es necesario para realizar cambios de configuración, los dominios invitados no se ven afectados si acceden a su red y sus recursos de disco por medio de otros dominios de servicio.
Evaluación: denegación de servicio de dominio de control
Atacar al dominio de control mediante la red equivale a atacar cualquier otra instancia de SO Oracle Solaris que esté correctamente protegida. El daño que ocasiona el cierre o la similar denegación de servicio del dominio de control es relativamente bajo. Sin embargo, los dominios invitados se ven afectados si el dominio de control también actúa como dominio de servicio para estos dominios invitados.
Contramedida: protección del acceso a la consola
Evite la configuración del acceso de redes administrativas al entorno de ejecución de los dominios. Este escenario requiere el uso del servicio de consola ILOM del dominio de control para realizar todas las tareas de administración. El acceso de consola a todos los otros dominios se puede seguir usando mediante el servicio vntsd que está en ejecución en el dominio de control.
Analice esta opción en detalle. Aunque esta opción reduce el riesgo de recibir ataques por la red administrativa, sólo un administrador a la vez puede acceder a la consola.
Para obtener información sobre cómo configurar vntsd de manera segura, consulte Cómo activar el daemon del servidor de terminal de red virtual de Guía de administración para Oracle VM Server for SPARC 3.3 .
Administrador de Dominios lógicos
El Administrador de Dominios lógicos se ejecuta en el dominio de control y se utiliza para configurar el hipervisor y crear y configurar todos los dominios y sus recursos de hardware. Asegúrese de que se registre y controle el uso del Administrador de Dominios lógicos.
Amenaza: uso no autorizado de utilidades de configuración
Es posible que un atacante tome el control del ID de usuario de un administrador o que un administrador de un grupo diferente obtenga acceso no autorizado a otro sistema.
Evaluación: uso no autorizado de utilidades de configuración
Asegúrese de que un administrador no tenga el acceso innecesario a un sistema mediante la implementación de una gestión de identidades que esté bien mantenida. Asimismo, implemente un control de acceso estricto y detallado, y otras medidas, como la regla de dos personas.
Contramedida: aplicación de la regla de dos personas
Considere la posibilidad de implementar una regla de dos personas para el Administrador de Dominios lógicos y otras herramientas administrativas mediante el uso de derechos. Enforcing a Two Man Rule Using Solaris 10 RBAC. Esta regla protege contra ataques de ingeniería social, cuentas de administrador riesgosas y errores humanos.
Contramedida: uso de derechos para el Administrador de Dominios lógicos
Mediante el uso de derechos para el comando ldm, puede implementar un control de acceso específico y mantener una rastreabilidad completa. Para obtener información sobre la configuración de los derechos, consulte Guía de administración para Oracle VM Server for SPARC 3.3 . El uso de derechos protege contra errores humanos porque no todas las funciones del comando ldm están disponibles para todos los administradores.
Contramedida: refuerzo de la protección del Administrador de Dominios lógicos
Desactive los servicios de administrador de dominios innecesarios. El Administrador de Dominios lógicos proporciona los servicios de red necesarios para el acceso, el control y la migración de dominios. La desactivación de los servicios de red reduce la superficie de ataque del Administrador de Dominios lógicos al mínimo requerido para que funcione normalmente. Este escenario permite combatir los ataques de denegación de servicio y cualquier otro intento de uso indebido de los servicios de red.
Notas - A pesar de que desactivar los servicios de administrador de dominios ayuda a minimizar la superficie de ataque, no se pueden conocer de antemano todos los efectos secundarios que pueden llegar a afectar a una configuración dada.
Servicio de migración en el puerto TCP 8101
Para desactivar este servicio, consulte la descripción de las propiedades ldmd/incoming_migration_enabled y ldmd/outgoing_migration_enabled en la página del comando man ldmd(1M).
La admisión del protocolo extensible de mensajería y comunicación de presencia (XMPP, Extensible Messaging and Presence Protocol) en el puerto TCP 6482
Para obtener información sobre la desactivación de este servicio, consulte Transporte de XML de Guía de administración para Oracle VM Server for SPARC 3.3 .
La desactivación de XMPP impide el funcionamiento de algunas herramientas de gestión y funciones de Oracle VM Server for SPARC clave. Consulte Interfaz XML de Oracle VM Server for SPARC.
El protocolo simple de administración de red (SNMP, Simple Network Management Protocol) en el puerto UDP 161
Active el servicio SNMP para utilizar MIB de Oracle VM Server for SPARC. Instale MIB de Oracle VM Server for SPARC de manera segura. Consulte Cómo instalar el paquete de software de MIB de Oracle VM Server for SPARC de Guía de administración para Oracle VM Server for SPARC 3.3 y Gestión de la seguridad de Guía de administración para Oracle VM Server for SPARC 3.3 .
Desactive el servicio SNMP. Para obtener información sobre cómo desactivar este servicio, consulte Cómo eliminar el paquete de software de MIB de Oracle VM Server for SPARC de Guía de administración para Oracle VM Server for SPARC 3.3 .
Determine si desea utilizar Base de datos de información de administración (MIB) de Oracle VM Server for SPARC para observar los dominios. Esta función requiere que el servicio SNMP esté activado. En función de las opciones que elija, siga uno de estos procedimientos:
Servicio de detección en dirección de multidifusión 239.129.9.27 y puerto 64535
Notas - Tenga en cuenta que el mecanismo de descubrimiento también es utilizado por el daemon ldmd para detectar colisiones cuando se asignan direcciones MAC automáticamente. Si desactiva el servicio de detección, la detección de colisiones de direcciones MAC no funcionará y la asignación automática de direcciones MAC no funcionará correctamente.No puede desactivar este servicio mientras se ejecuta ldmd, el daemon de Administrador de Dominios lógicos. En su lugar, utilice la función de filtro IP de Oracle Solaris para bloquear el acceso a este servicio, que reduce al mínimo la superficie de ataque de Administrador de Dominios lógicos. El bloqueo del acceso impide el uso no autorizado de la utilidad, lo cual protege con eficacia contra los ataques de denegación de servicio y cualquier otro intento de uso indebido de los servicios de red. Consulte Capítulo 20, IP Filter in Oracle Solaris (Overview) de Oracle Solaris Administration: IP Services y Using IP Filter Rule Sets de Oracle Solaris Administration: IP Services .
Desactive cualquiera de los siguientes servicios de red cuando no estén en uso:
También consulte Contramedida: protección del ILOM.
Dominio de servicio
Un dominio de servicio proporciona algunos servicios virtuales a los dominios invitados del sistema. Es posible que entre dichos servicios se incluya un conmutador virtual, un disco virtual o un servicio de consola virtual.
En Figure 1–6, se muestra un ejemplo de dominio de servicio que ofrece servicios de consola. A menudo el dominio de control aloja los servicios de consola y, por lo tanto, también es un dominio de servicio. Los dominios del entorno de ejecución a menudo combinan las funciones de un dominio de control, un dominio de E/S y un dominio de servicio en uno o dos dominios.
Amenaza: manipulación de un dominio de servicio
Un atacante que obtiene el control de un dominio de servicio puede manipular los datos o escuchar cualquier comunicación que se lleve a cabo mediante los servicios ofrecidos. Este control puede incluir el acceso a la consola en dominios invitados, el acceso a los servicios de red o el acceso a los servicios de disco.
Evaluación: manipulación de un dominio de servicio
Aunque las estrategias de ataque son las mismas para un ataque al dominio de control, los posibles daños son menores porque el atacante no puede modificar la configuración del sistema. Los daños resultantes pueden incluir el robo o la manipulación de datos que se ofrezcan por medio del dominio de servicio, pero no la manipulación de las fuentes de los datos. Según el servicio, puede que se requiera que el atacante intercambie los módulos de núcleo.
Figura 1-6 Ejemplo de dominio de servicio
Contramedida: dominios de servicios separados por la granularidad
Si es posible, establezca que cada dominio de servicio ofrezca solamente un servicio a sus clientes. Esta configuración garantiza que sólo un servicio quede en riesgo si se vulnera un dominio de servicio. Sin embargo, debe asegurarse de evaluar la importancia de este tipo de configuración en función de la complejidad adicional. Tenga en cuenta que es muy recomendable tener dominios de E/S redundantes.
Contramedida: aislamiento de dominios de servicio y dominios invitados
Asegúrese de que el dominio de servicio y el dominio invitado no compartan el mismo puerto de red. Además, no conecte ninguna interfaz de conmutador virtual en el dominio de servicio. Para los dominios de servicio de Oracle Solaris 11, no conecte ninguna VNIC en los puertos físicos que se utilizan para los conmutadores virtuales.
Si debe utilizar el mismo puerto de red para el SO Oracle Solaris 10 y el SO Oracle Solaris 11, coloque el tráfico del dominio de E/S en una VLAN que no sea utilizada por los dominios invitados.
Si no puede implementar ninguna de las soluciones anteriores, no conecte el conmutador virtual en el SO Oracle Solaris 10 y aplique los filtros IP en el SO Oracle Solaris 11.
Puede aislar los dominios de servicio de Oracle Solaris 10 y Oracle Solaris 11 de los dominios invitados. Las siguientes soluciones se muestran en el orden preferido de implementación:
Contramedida: restricción del acceso a las consolas virtuales
Asegúrese de que el acceso a las consolas virtuales individuales se limite solamente a los usuarios que deban acceder a ellos. Esta configuración garantiza que ningún administrador tenga acceso a todas las consolas, lo cual impide que se acceda a consolas que no se hayan asignado a una cuenta riesgosa. Consulte Cómo crear servicios predeterminados de Guía de administración para Oracle VM Server for SPARC 3.3 .
Dominio de E/S
Cualquier dominio que tiene acceso directo a dispositivos físicos de E/S, como puertos de red o discos, es un dominio de E/S. Para obtener información sobre la configuración de dominios de E/S, consulte Capítulo 5, Cómo configurar los dominios de E/S de Guía de administración para Oracle VM Server for SPARC 3.3 .
Un dominio de E/S también puede ser un dominio de servicio si proporciona servicios de E/S a los dominios invitados, lo cual proporciona a los dominios el acceso al hardware.
Amenaza: situación de denegación de servicio de un dominio de E/S o un dominio de servicio
Un atacante que bloquea los servicios de E/S de un dominio de E/S se asegura de que todos los dominios invitados dependientes queden igualmente bloqueados. Para que un ataque de denegación de servicio se realice con éxito puede que se sobrecargue la red back-end o la infraestructura de discos, o que se introduzca un fallo en el dominio. Cualquiera de estos ataques puede forzar el dominio para que se bloquee o emita un aviso grave. Del mismo modo, un atacante que suspende servicios del dominio de servicio hace que cualquier dominio invitado que dependa de estos servicios se cuelgue inmediatamente. Si el dominio invitado se cuelga, su funcionamiento se reanuda cuando se reanuda el servicio de E/S.
Evaluación: situación de denegación de servicio de un dominio de E/S o un dominio de servicio
Los ataques de denegación de servicio suelen realizarse en la red. Dicho ataque puede realizarse con éxito si los puertos de red están abiertos para la comunicación, y el tráfico de red puede ocasionar un desborde. Una pérdida de servicio resultante bloquea los dominios invitados dependientes. Un ataque similar a los recursos de disco podría realizarse por medio de la infraestructura SAN o con un ataque al dominio de E/S. El único daño que se ocasiona es la detención temporal de todos los dominios invitados dependientes. Aunque el impacto de las tareas de denegación de servicio podría ser considerable, los datos no se pierden ni quedan en riesgo, y la configuración del sistema permanece intacta.
Contramedida: configuración granular de los dominios de E/S
La configuración de varios dominios de E/S reduce el impacto de que un dominio falle o esté en riego. Puede asignar ranuras PCIe individuales a un dominio invitado para darle capacidades de dominio de E/S. Si el dominio raíz que posee el bus PCIe se bloquea, el bus se restablece, lo cual ocasiona posteriormente un bloqueo del dominio que se había asignado a la ranura individual. Esta función no elimina por completo la necesidad de tener dos dominios raíz que tengan cada uno un bus PCIe independiente.
Contramedida: configuración de dominios raíz y hardware redundantes
La alta disponibilidad contribuye también a mejorar la seguridad porque garantiza que los servicios puedan soportar los ataques de denegación de servicio. Oracle VM Server for SPARC implementa metodologías de alta disponibilidad, como el uso de los discos redundantes y los recursos de red en dominios de E/S redundantes. Esta opción de configuración permite realizar actualizaciones sucesivas de los dominios de E/S y protege contra el impacto de un fallo del dominio de E/S que se ocasione por un ataque certero de denegación de servicio. Gracias a SR-IOV, los dominios invitados pueden tener acceso directo a los dispositivos de E/S individuales. Sin embargo, si SR-IOV no es una opción factible, considere la posibilidad de crear dominios de E/S redundantes. Consulte Contramedida: dominios de servicios separados por la granularidad.
Amenaza: manipulación de un dominio de E/S
Un dominio de E/S tiene acceso directo a dispositivos back-end, por lo general, discos, a los cuales virtualiza para luego ofrecerlos a los dominios invitados. Si un atacante logra su objetivo, obtiene acceso completo a estos dispositivos y puede leer los datos confidenciales o manipular el software en los discos de inicio de los dominios invitados.
Evaluación: manipulación de un dominio de E/S
Es tan probable que se realice un ataque certero al dominio de E/S como a un dominio de servicio o al dominio de control. El dominio de E/S es un blanco atractivo porque brinda acceso potencial a una gran cantidad de dispositivos de disco. Por lo tanto, tenga en cuenta esta amenaza cuando trabaje con datos confidenciales en un dominio invitado que se ejecute en discos virtualizados.
Contramedida: protección de discos virtuales
Cuando un dominio de E/S se encuentra en riesgo, el atacante tiene acceso total a los discos virtuales del dominio invitado.
Cifrado de los contenidos de los discos virtuales. En los sistemas Oracle Solaris 10, puede utilizar una aplicación que cifra sus propios datos, como pgp/gpg o los espacios de tablas cifrados de Oracle 11g. En los sistemas Oracle Solaris 11, puede utilizar conjuntos de datos cifrados ZFS para proporcionar cifrado transparente de todos los datos almacenados en el sistema de archivos.
Distribución de los datos en varios discos virtuales en diferentes dominios de E/S. Un dominio invitado puede crear un volumen en bandas (RAID 1/RAID 5), con bandas en varios discos virtuales que se obtienen de dos dominios de E/S. El atacante tendría dificultades para hacer uso de la parte de los datos que está disponible si uno de estos dominios de E/S se encuentra en riesgo.
Para proteger el contenido de los discos virtuales, haga lo siguiente:
Dominios invitados
Aunque los dominios invitados no forman parte del entorno de ejecución, son el blanco de ataque más probable porque están conectados a la red. Un atacante que vulnera un sistema virtualizado puede atacar el entorno de ejecución.
Contramedida: protección del SO del dominio invitado
El sistema operativo en el dominio invitado suele ser la primera línea de defensa contra cualquier ataque. Con la excepción de los ataques que se originan en el centro de datos, un atacante debe acceder a un dominio invitado que tenga conexiones externas antes de intentar vulnerar el aislamiento del dominio invitado y capturar el entorno completo. Por lo tanto, debe reforzar la protección del sistema operativo del dominio invitado.
Para reforzar más la protección del sistema operativo, puede implementar la aplicación en Zona de Solaris, lo cual coloca una capa adicional de aislamiento entre el servicio de red de la aplicación y el sistema operativo del dominio invitado. Si se efectúa ataque certero en el servicio, se pone en riesgo sólo la zona, y no el sistema operativo subyacente. Esto impide que el atacante logre expandir el control más allá de los recursos que están asignados a la zona. Como consecuencia, finalmente resulta más difícil vulnerar el aislamiento del dominio invitado. Para obtener información sobre cómo proteger el SO huésped, consulte Oracle Solaris 10 Security Guidelines y Oracle Solaris 11 Security Guidelines .