En Drovorub: mejores prácticas de seguridad del kernel de Linux


Intro

En un gobierno de Estados Unidos aviso de seguridad cibernética publicado hoy, la Agencia de Seguridad Nacional y la Oficina Federal de Investigaciones advierten sobre una pieza de malware rootkit de Linux no revelada anteriormente llamada Drovorub y atribuyen la amenaza al actor malicioso APT28. El informe es increíblemente detallado y propone varias técnicas de detección complementarias para identificar eficazmente la actividad del malware Drovorub. Se sugieren una multitud de métodos de investigación dado que el problema común con los rootkits es que la detección a gran escala en un host puede ser un verdadero desafío. La NSA y el FBI han sido explícitos en su informe de que los sistemas con una versión del kernel 3.7 o inferior son más susceptibles al malware Drovorub debido a la ausencia de una aplicación adecuada de la firma del kernel.

Mantener un sistema actualizado y completamente protegido no es específico de los entornos basados ​​en Home windows. Los sistemas basados ​​en Linux están muy extendidos en muchas organizaciones empresariales, y a menudo operan fuera de la visibilidad directa de los administradores de sistemas. En parte debido a esta baja visibilidad, los actores de amenazas adoptan Linux Stack como un escondite perfect y un punto de lanzamiento para el movimiento lateral. Esto hace que mantener estos entornos actualizados y seguros sea una alta prioridad.

Para conocer las protecciones específicas de la tecnología de McAfee contra Drovorub, visite el artículo de la KB dedicado a Drovorub aquí.

Además de la orientación proporcionada en el informe del gobierno de EE. UU. Y nuestro producto específico foundation de conocimientos En este artículo, McAfee anima a las organizaciones a tomar nota y aplicar las siguientes prácticas recomendadas (cuando sea posible) para la detección de rootkits y la seguridad del kernel.

Escaneo en busca de rootkits

Al igual que un escáner de malware, un escáner de rootkit puede escanear procesos de bajo nivel para determinar si se cargó algún código malicioso en el arranque. Por ejemplo, a continuación se muestran ejemplos de software package que se pueden utilizar para la detección normal de rootkits:

  • Chrootkit – Un escáner de rootkits para Linux para descubrir rootkits difíciles de encontrar
  • Rkhunter – Un escáner de rootkit para Linux para descubrir puertas traseras y posibles exploits locales.

En este caso específico de Drovorub, se da el consejo de analizar forense la memoria de una máquina con herramientas como Volatility. Usando el complemento Volatility «Linux_Psxview«Se puede detectar la presencia del cliente Drovorub aunque no aparezca en la lista standard de PS.

Endurecimiento del kernel de Linux

El aviso de hoy sugiere que las organizaciones habiliten UEFI Safe Boot en modo «completo» o «completo» en sistemas x86-64. UEFI Secure Boot requiere firmware y kernels firmados criptográficamente. Debido a que no se pueden cargar controladores sin firmar para el hardware, esta acción disminuirá la superficie de ataque al dificultar que un atacante inserte un módulo del kernel malicioso en el sistema y que los rootkits sin firmar permanezcan persistentes después del reinicio.

Sin embargo, las organizaciones deben tener en cuenta que Protected Boot no está integrado en todas las distribuciones de Linux. También existen algunos desafíos para habilitar el arranque seguro. A menudo, requiere una intervención guide cada vez que se actualiza un kernel o módulo o puede evitar que se carguen algunos productos. Esta artículo de la base de conocimientos de VMWare analiza formas de abordar estos problemas de arranque seguro

Asegurando el kernel

Hay varios pasos que las organizaciones pueden tomar para proteger el kernel de Linux y aprovechar las funciones que se proporcionan. Destacaremos algunas de las mejores prácticas que se pueden utilizar y aplicar. Aplíquelos en un entorno de prueba antes de aplicarlos en producción.

Firma del módulo del kernel

Desde Linux 3.7, el kernel ha admitido firmas digitales en módulos de kernel cargables. Esta función se puede habilitar en el kernel con la configuración en CONFIG_MODULE_SIG. Estas opciones pueden requerir firmas válidas habilitar la firma automática de módulos durante la fase de compilación del kernel y especifique qué algoritmo hash utilizar. Además, se pueden utilizar claves locales o remotas. Al requerir firmas digitales válidas, solo se pueden cargar módulos válidos conocidos, lo que lessen la superficie de ataque de su sistema.

Reglas de carga de módulos

Solo los módulos conocidos deben poder cargarse. La compatibilidad con módulos limitados se puede habilitar de forma predeterminada, lo que no permite la carga de módulos del kernel y especifica qué módulos están exentos de la prohibición. El siguiente comando se puede utilizar para deshabilitar la carga:

sysctl kernel.modules_disabled = 1

Algunos módulos necesarios para el funcionamiento del sistema pueden normalmente cargarse durante el funcionamiento del sistema y no durante el arranque. Para garantizar que estos módulos estén disponibles, deben cargarse al inicio antes de que se desactive la carga. Para cargar estos módulos, enumerelos en un archivo ubicado en /etcetera/modules-load.d.

Deshabilitar módulos por completo

Dependiendo del sistema en cuestión, deshabilitar todo el hardware no necesario en la configuración del kernel y compilar todo el código del controlador requerido directamente en el kernel en lugar de usar módulos podría permitir deshabilitar completamente el soporte de módulos cargables del kernel. Para sistemas de uso especial, esta puede ser una opción practical. Al rechazar los módulos por completo, la superficie de ataque de su sistema se puede reducir drásticamente.

Es posible que la desactivación completa del soporte de módulos del kernel solo sea posible para sistemas de propósito especial con un patrón de uso conocido. Es possible que las máquinas de uso basic orientadas al usuario necesiten soporte de módulo para admitir los patrones de acceso de los usuarios.

Usando el bloqueo del kernel de Linux

Los parches de bloqueo se han fusionado en el kernel desde la versión 5.4. Incluso si el Arranque seguro está habilitado, si no se evita, la raíz podría modificar el kernel y, por ejemplo, aplicar un parche y crear un proceso persistente. Lockdown se desarrolló para proporcionar una política que evite que la raíz modifique el código del kernel. El bloqueo tiene dos modos: «integridad» y «confidencialidad». La comunidad generalmente aconseja a las organizaciones que consideren el modo de «integridad» y utilicen el modo de «confidencialidad» para sistemas especiales.

Harden sysctl.conf

El archivo sysctl.conf es el punto de configuración principal para un sistema Linux. Al utilizar valores predeterminados seguros, todo el sistema se beneficiará de una base más segura. Las opciones de ejemplo incluyen deshabilitar IPv6, ignorar los paquetes de transmisión de crimson, habilitar ASLR y activar DEP / NX. (https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-protection-hardening/)

Habilitar SELinux

SELinux es una mejora de seguridad del Kernel de Linux que permite un manage de acceso granular con políticas de seguridad. SELinux está instalado y habilitado de forma predeterminada en las distribuciones Centos / Purple Hat y se puede habilitar fácilmente en Ubuntu y otras distribuciones.

Lo que observamos a menudo es que las personas decidirán deshabilitar SELinux tan pronto como se encuentren con un problema, ya que es fácil de deshabilitar con privilegios de administrador. Pero tomarse el tiempo para aprender cómo permitir servicios y solucionar problemas es muy importante para mantener seguro un sistema Linux.

Fortalecimiento adicional del sistema Linux

A la luz del aviso de hoy, en este artículo nos hemos centrado principalmente en proteger el kernel de Linux. Sin embargo, existen muchas mejores prácticas para proteger Linux, que incluyen:

  • Eliminación de software package no utilizado
  • Deshabilitar servicios no utilizados
  • Habilitación de la auditoría
  • Controlar el acceso a la API
  • Limitar el uso de la cuenta raíz
  • Incorporar una política de privilegios mínimos tanto como sea posible
  • Hacer una copia de seguridad de su sistema
  • Aumentar la entropía de ASLR a través de sysctl para dificultar la explotación confiable, aumentando la cantidad de bibliotecas de ubicaciones que podrían almacenarse en la memoria.

Se pueden descargar guías detalladas de refuerzo y protección para distribuciones de Linux desde:

https://www.cisecurity.org/cybersecurity-ideal-techniques/

Conclusión

El refuerzo del kernel y del sistema de Linux a menudo resulta ser un desafío para las organizaciones y no es tan sencillo como proteger otros sistemas operativos. Sin embargo, dada la información proporcionada en la publicación de la NSA-FBI y la adaptación del malware basado en Linux por parte de los actores de amenazas en typical, recomendamos a las organizaciones que permanezcan atentas, refuercen los sistemas Linux tanto como sea posible e implementen productos de seguridad adecuados.

Para obtener protecciones específicas de la tecnología de McAfee contra DrovorubDrovorub, visite el artículo de KB dedicado a DrovorubDrovorub aquí.





Enlace a la noticia original