Con el apoyo de la comunidad de código abierto y un estricto sistema de privilegios integrado en su arquitectura, Linux tiene la seguridad integrada en su diseño. Dicho esto, ya han pasado los días en que los administradores de sistemas Linux podían salirse con la suya con prácticas de seguridad deficientes. Los ciberdelincuentes han llegado a considerar a Linux como un objetivo de ataque viable debido a su creciente popularidad, a los valiosos dispositivos que alimenta en todo el mundo y a una serie de nuevas y peligrosas variantes de malware para Linux que han surgido en los últimos años.
Se ha puesto de manifiesto que la mayoría de los ataques a los sistemas Linux pueden atribuirse a una configuración errónea y a una administración deficiente, y la falta de seguridad del kernel de Linux suele ser, al menos en parte, la culpable. La seguridad del kernel es un determinante clave de la seguridad general del sistema, ya que el kernel de Linux es la base del sistema operativo Linux y la interfaz principal entre el hardware de un ordenador y sus procesos.
Por suerte, el kernel de Linux posee un surtido de defensas de seguridad integradas y eficaces -a saber, cortafuegos que utilizan filtros de paquetes integrados en el kernel, Secure Boot, Linux Kernel Lockdown y SELinux o AppArmor- que los administradores deberían aprovechar al máximo. Este artículo examinará la importancia de una seguridad robusta del kernel y explorará varias medidas que los administradores pueden tomar para asegurar el kernel de Linux y proteger sus sistemas de malware y otros exploits.
¿Cómo de seguro es el Kernel de Linux?
La seguridad del kernel es una preocupación constante para los administradores de sistemas Linux, y asegurar el kernel es uno de los aspectos más complejos de la seguridad de un sistema Linux. A pesar de que el kernel de Linux se somete a un escrutinio constante en busca de errores de seguridad por parte de los «muchos ojos» de la vibrante comunidad global de código abierto, las vulnerabilidades del kernel siguen siendo una amenaza persistente y grave. Los fallos son inevitables en cualquier sistema operativo, y una gran parte de los bugs del kernel de Linux presentan potenciales problemas de seguridad, que a menudo resultan en una escalada de privilegios o en ataques de denegación de servicio (DoS). Las vulnerabilidades críticas del kernel a menudo pueden ser explotadas por atacantes remotos, sin necesidad de que la víctima realice ninguna acción. Algunos de los fallos de seguridad más conocidos del núcleo de Linux descubiertos y corregidos en los últimos años son:
- CVE-2017-18017: Esta vulnerabilidad crítica, que reside en la función netfilter tcpmss_mangle_packet, es altamente peligrosa debido al papel central que desempeña en el filtrado de las comunicaciones de red mediante la definición del tamaño de segmento máximo que se permite para aceptar cabeceras TCP. Sin estos controles, los usuarios son susceptibles de sufrir problemas de desbordamiento y ataques DoS. El fallo afecta a las versiones del kernel anteriores a la 4.11.
- CVE-2016-10229: Este fallo de udp.c, que también afecta a las versiones del kernel anteriores a la 4.5, permite a un atacante remoto ejecutar código arbitrario a través del tráfico UDP, desencadenando una segunda suma de comprobación no segura durante la ejecución de una llamada al sistema recv con la bandera MSG_PEEK.
- CVE-2016-10150: Esta vulnerabilidad use-after-free, que afecta a las versiones del kernel anteriores a la 4.8.13, podría ser explotada por hackers para obtener privilegios y lanzar ataques DoS.
- CVE-2015-8812: Esta grave vulnerabilidad que afecta a las versiones del kernel anteriores a la 4.5, descubierta en los controladores del kernel de Linux, permite a un atacante remoto ejecutar código arbitrario o provocar un ataque DoS (use-after-free) a través de paquetes crafteados.
- CVE-2014-2523: Esta grave vulnerabilidad de netfilter, que afecta a las versiones del kernel hasta la 3.13.6, se atribuye al uso incorrecto de un puntero de cabecera DCCP. El defecto permite a un atacante remoto causar un ataque DoS (caída del sistema) o ejecutar código arbitrario a través de un paquete DCCP que desencadena una llamada a la función dccp_new, dccp_packet o dccp_error.
El seguimiento de los avisos es fundamental para protegerse de las vulnerabilidades del núcleo y mantener un sistema seguro y actualizado. Suscribirse a nuestro boletín semanal Linux Advisory Watch es una forma fácil y cómoda de mantenerse al día de los últimos avisos y actualizaciones de su distribución de Linux.
¿Qué es la autoprotección del Kernel y por qué es importante?
La autoprotección del kernel de Linux, o el diseño e implementación de sistemas y estructuras dentro del kernel de Linux para protegerse de los fallos de seguridad del propio kernel, es una excelente forma de añadir otra capa de seguridad al kernel de Linux. Incluye métodos de defensa como la reducción de la superficie de ataque, la integridad de la memoria, las defensas probabilísticas y la prevención de la exposición de la información. Examinemos algunos consejos y mejores prácticas para asegurar el kernel de Linux implementando estos métodos de defensa para proteger a sus usuarios, sus sistemas y sus datos.
Consejos para proteger el Kernel de Linux
Aplicar los parches de seguridad del kernel
El kernel de Linux se parchea con frecuencia para mitigar las últimas vulnerabilidades de seguridad que se han descubierto y, aunque sea monótono, estar al tanto de las actualizaciones de seguridad del kernel es imprescindible para mantener un sistema Linux seguro. El método más sencillo para actualizar el kernel de Linux es rastrear los avisos de seguridad de la distribución y aplicar las últimas actualizaciones disponibles directamente desde su distribución de Linux. Hay otros tres métodos para actualizar el kernel: en la línea de comandos, con kexec, o con una herramienta de parcheo del kernel en vivo sin reiniciar. Actualizar el kernel desde la línea de comandos es el método que probablemente esté cubierto en la documentación de su distribución. Sin embargo, una de las principales desventajas de parchear el kernel desde la línea de comandos es que tendrá que sufrir el tiempo de inactividad de un reinicio del sistema. Los administradores pueden acelerar el proceso de reinicio utilizando la llamada al sistema kexec. Sin embargo, este método es arriesgado, ya que puede causar pérdida y corrupción de datos. El tercer método -actualizar el kernel automáticamente utilizando una herramienta de parcheo del kernel en vivo sin reinicio, como Livepatch, Ksplice, Kpatch, Kgraft o KernelCare- es generalmente el método elegido por los administradores, pero no es un sustituto de las actualizaciones completas del kernel, ya que sólo aplica parches para vulnerabilidades de seguridad o correcciones de errores críticos.
Activar el arranque Secure Boot en “Full” o “Thorough” Mode
UEFI Secure Boot es un mecanismo de verificación para asegurar que el código lanzado por el firmware UEFI de un dispositivo es de confianza. La función está diseñada para evitar que se cargue y ejecute código malicioso antes de que se haya cargado el sistema operativo. Al habilitar el arranque seguro de UEFI en modo «completo» o «exhaustivo», los administradores pueden reducir la superficie de ataque en los sistemas x86-64. El arranque seguro de la UEFI requiere firmware y kernels firmados criptográficamente. Por lo tanto, no se pueden cargar controladores no firmados para el hardware en sistemas con UEFI Secure Boot habilitado en modo «completo» o «minucioso». Esto hace que sea mucho más difícil para un atacante insertar un módulo de kernel malicioso en un sistema y que los rootkits sin firmar permanezcan persistentes después del reinicio.
Sin embargo, los administradores deben ser conscientes de que la activación de Secure Boot conlleva algunos inconvenientes potenciales. Por ejemplo, requiere la intervención manual cada vez que se actualiza un kernel o un módulo. El uso de Secure Boot también activa el modo «lockdown», que desactiva varias características que pueden ser utilizadas para modificar el kernel. Cubriremos esto en mayor profundidad en la siguiente sección.
Aprende más sobre el arranque seguro UEFI y cómo instalar un sistema Linux con el arranque seguro activado en este tutorial de Linux.org.
Utilice el bloqueo del kernel de Linux
El Bloqueo del Núcleo de Linux es una opción de configuración del núcleo desarrollada para proporcionar una política que evite que la cuenta root modifique el código del núcleo, reforzando la división entre los procesos de la tierra del usuario y el código del núcleo. Así, en el caso de que una cuenta de root se vea comprometida, tener activado el modo Lockdown hará mucho más difícil que la cuenta comprometida pueda comprometer el resto del sistema operativo. Aunque Lockdown no se introdujo hasta el lanzamiento de la versión 5.4 del kernel, el trabajo en esta característica comenzó hace más de una década, y fue encabezado por el ingeniero de Google Matthew Garrett.
El soporte de Lockdown puede activarse con el parámetro del kernel lockdown=. El módulo tiene dos modos: el modo «integridad» y el modo «confidencialidad». Por lo general, se aconseja utilizar el modo «integridad», y sólo utilizar el modo «confidencialidad» para los sistemas especiales que contienen información sensible que ni siquiera el root debería poder ver, como la clave de firma EVM, que puede utilizarse para evitar la modificación de archivos fuera de línea. El uso del modo de confidencialidad bloquea el acceso a toda la memoria del kernel, impidiendo que los administradores puedan inspeccionar y sondear el kernel para propósitos tales como la resolución de problemas, el desarrollo y la prueba y verificación de las medidas de seguridad. Configurar lockdown=integrity bloqueará las características del kernel que permiten al espacio de usuario modificar el kernel en ejecución, mientras que configurar lockdown=confidencialidad bloqueará que el espacio de usuario extraiga información sensible del kernel en ejecución. Los administradores tienen la opción de aplicar permanentemente el modo de bloqueo de integridad o de confidencialidad a través de SECURITY_LOCKDOWN_LSM_EARLY. Todas estas configuraciones se controlan a través de la opción Kconfig SECURITY_LOCKDOWN_LSM para habilitar el módulo.
Los administradores deben ser conscientes de que el uso de Lockdown impide que se carguen varias funciones y módulos que pueden utilizarse para modificar el kernel. Por ejemplo, Lockdown deshabilita:
- Cargar módulos del kernel que no estén firmados por una clave de confianza, como los módulos fuera del árbol, incluidos los controladores gestionados por DKMS.
- Uso de kexec para iniciar una imagen del kernel no firmada.
- Hibernación y reanudación de la hibernación.
- Acceso del espacio de usuario a la memoria física y a los puertos de E/S.
- Parámetros de módulos utilizados para establecer direcciones de memoria y puertos de E/S.
- Escritura en MSRs a través de /dev/cpu/*/msr.
- El uso de métodos y tablas ACPI personalizadas.
- Inyección de errores ACPI APEI.
Habilitar las reglas de firma y carga de módulos del kernel
El kernel de Linux admite firmas digitales en los módulos del kernel que se pueden cargar, lo que garantiza que sólo se pueden cargar módulos conocidos y válidos y disminuye la superficie de ataque de un sistema con este requisito. La firma de módulos del kernel debe estar habilitada en el kernel con la configuración en CONFIG_MODULE_SIG. Los administradores pueden configurar el kernel para que requiera firmas válidas, habilitar la firma automática de módulos durante la fase de construcción del kernel y especificar qué algoritmo hash utilizar. También se pueden utilizar claves locales o remotas.
Además, el soporte limitado de módulos puede ser habilitado por defecto usando el comando sysctl kernel.modules_disabled=1. Sysctl es una forma de que los administradores se comuniquen directamente con el kernel para controlar su funcionamiento. Estas funciones también se pueden configurar en el archivo /etc/sysctl.conf. Explicamos cómo los administradores pueden endurecer este archivo en la siguiente sección.
Desactivar los módulos por completo puede reducir drásticamente la superficie de ataque de un sistema, pero sólo es práctico en casos de uso especiales.
Endurecer el archivo Sysctl.conf
El archivo sysctl.conf es el principal punto de configuración de parámetros del kernel para un sistema Linux. Al utilizar valores predeterminados seguros, todo su sistema se beneficiará de una base más segura.
Con /etc/sysctl.conf puedes configurar varios parámetros de red y del sistema Linux para mejorar la seguridad:
- Limitación de la configuración transmitida por la red para IPv4
- Limitación de la configuración transmitida por la red para IPv6
- Activación de la protección execshield
- Protección contra ataques syn flood
- Activación de la verificación de la dirección IP de origen
- Protección de la dirección IP de un servidor contra ataques de spoofing
- Registro de paquetes sospechosos como paquetes falsos, paquetes enrutados en origen y redirecciones
Aprenda a endurecer el archivo sysctl.conf en este tutorial de nixCraft.
Habilitar SELinux o AppArmor
Los sistemas Linux modernos incluyen los sistemas de mejora de la seguridad AppArmor o SELinux (dependiendo de la distribución) instalados por defecto para protegerse de amenazas como la desconfiguración de los servidores, las vulnerabilidades de software y los exploits de día cero, que podrían comprometer todo un sistema sin estos controles. SELinux está instalado y activado por defecto en los sistemas operativos CentOS y RedHat Enterprise Linux, mientras que AppArmor está instalado y activado por defecto en los sistemas Ubuntu y SuSE Linux Enterprise. Estos sistemas de mejora de la seguridad permiten un control de acceso granular con políticas de seguridad, proporcionando una capa adicional de seguridad en todo el sistema.
SELinux define los controles de acceso para las aplicaciones, los procesos y los archivos de un sistema, utilizando políticas de seguridad para hacer cumplir estos controles de acceso. Cuando una aplicación o proceso -conocido como «sujeto»- hace una solicitud para acceder a un «objeto» como un archivo, SELinux comprueba con una caché de vectores de acceso (AVC), donde se almacenan en caché los permisos para sujetos y objetos. Si SELinux no puede tomar una decisión sobre el acceso basándose en los permisos almacenados en la caché, la solicitud se reenvía al servidor de seguridad, que comprueba el contexto de seguridad del sujeto y del objeto en la base de datos de políticas de SELinux. El permiso se concede o se deniega. Si el permiso es denegado, un mensaje «avc: denied» estará disponible en /var/log.messages.
Para los casos de uso típicos, recomendamos que los administradores configuren SELinux en modo permisivo. Al operar en modo permisivo, la política no se aplica y el sistema sigue siendo operativo. En otras palabras, SELinux no deniega ninguna operación, sino que sólo registra los mensajes de AVC, que los administradores pueden utilizar para la resolución de problemas, la depuración deAppArmor y la mejora de las políticas.
Al igual que SELinux, Apparmor aísla las aplicaciones y los procesos entre sí con perfiles por programa incorporados en el núcleo, así como cualquier perfil que haya generado un administrador. AppArmor puede configurarse para que aplique estos perfiles o para que se queje cuando se infrinjan las reglas del perfil. AppArmor es menos complejo que SELinux, pero a su vez ofrece menos control sobre cómo se aíslan los procesos.
Desgraciadamente, es bastante común que los administradores desactiven SELinux o AppArmor cuando se encuentran con un problema, en lugar de aprender a solucionar el problema con estos servicios activados. Esta es una mala práctica de administración y seguridad, y puede restarle importancia a la postura de seguridad general de un sistema al dejarlo susceptible a los mismos ataques que SELinux o AppArmor están diseñados para prevenir.
Implementar permisos estrictos
Cuando toda la memoria del kernel es escribible, es fácil que los ataques redirijan el flujo de ejecución, por lo que es imperativo que la memoria del kernel esté protegida con un conjunto de permisos estrictos. Los permisos deben ser tan estrictos como sea práctico en un entorno determinado.
Los administradores deberían empezar por asegurarse de que el código ejecutivo y los datos de sólo lectura no son escribibles. Las configuraciones CONFIG_STRICT_KERNEL_RWX y CONFIG_STRICT_MODULE_RWX, que buscan asegurar que el código no es escribible, los datos no son ejecutables, y los datos de sólo lectura no son ni escribibles ni ejecutables, son las opciones por defecto para la mayoría de las arquitecturas de Linux. En el caso de que estas configuraciones sean seleccionables por el usuario, un administrador puede seleccionar ARCH_OPTIONAL_KERNEL_RWX para habilitar un aviso de Kconfig. CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT determina la configuración por defecto cuando ARCH_OPTIONAL_KERNEL_RWX está activado.
Es fundamental que los punteros a funciones y las variables sensibles, que son buscadas por el kernel y utilizadas para continuar la ejecución, sean de sólo lectura, no de escritura. Muchas de estas variables pueden hacerse de sólo lectura configurándolas como «const» para que residan en la sección .rodata en lugar de la sección .data del kernel.
Los permisos siempre deben ser configurados para reforzar la segregación de la memoria del kernel de la memoria del espacio de usuario. Estas reglas pueden ser aplicadas a través de restricciones basadas en hardware o a través de la emulación. Al bloquear la memoria del espacio de usuario, los ataques se ven forzados a operar completamente en la memoria del núcleo.
Utilice AuditD para la supervisión continua del sistema
La monitorización cuidadosa del kernel de Linux permite a los administradores descubrir fallos de seguridad, infracciones o violaciones de las políticas, lo que les permite mitigar los posibles daños causados por estas amenazas y verificar la seguridad de sus sistemas. El uso del sistema de auditoría de Linux (AuditD) es un método popular y eficaz para supervisar los eventos que se producen en un sistema. AuditD es una característica nativa del kerneAuditdl de Linux, que se instala por defecto en la mayoría de las distribuciones y se ejecuta automáticamente, que recoge información sobre la actividad del sistema, como las modificaciones de los permisos de los archivos, los servicios que se activan o desactivan y los eventos de red, para facilitar la investigación de posibles incidentes de seguridad. Registra la información de acuerdo con sus reglas, así como con las reglas personalizadas que haya añadido el administrador. El kernel es el único que puede realizar estas funciones porque sólo él tiene acceso directo a todos los dispositivos y a la memoria del sistema.
Este es un ejemplo del tipo de información que proporciona el demonio de auditoría AuditD. Muestra los usuarios que ejecutan comandos específicos como /usr/bin/sudo y ssh generando una nueva clave de sesión
type=USER_CMD msg=audit(1611763205.568:1621017): pid=1829220 uid=991 auid=4294967295 ses=4294967295 msg='cwd="/" cmd=2F7573722F6C6962363 exe="/usr/bin/sudo" terminal=? res=success'UID="nrpe" AUID="unset" type=CRYPTO_KEY_USER msg=audit(1611762843.231:1620894): pid=1825289 uid=0 auid=0 ses=49526 msg='op=destroy kind=server fp=SHA256:d7:c2:5a7 direction=? spid=1825289 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' UID="root" AUID="root" SUID="root"
Este es un ejemplo de cómo se utiliza «aureport» para generar un informe resumido de los eventos que han ocurrido en el sistema.
[root@myhost ~]# aureport Summary Report ====================== Range of time in logs: 01/23/2021 04:54:03.379 - 01/27/2021 11:36:05.388 Selected time for report: 01/23/2021 04:54:03 - 01/27/2021 11:36:05.388 Number of changes in configuration: 67 Number of changes to accounts, groups, or roles: 0 Number of logins: 1457 Number of failed logins: 6249 Number of authentications: 1461 Number of failed authentications: 178 Number of users: 4 Number of terminals: 7 Number of host names: 661 Number of executables: 7 Number of commands: 1 Number of files: 0 Number of AVCs: 0 Number of MAC events: 65 Number of failed syscalls: 0 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 45395 Number of integrity events: 0 Number of virt events: 0 Number of keys: 0 Number of process IDs: 25064 Number of events: 136817 [root@myhost ~]# aureport -x --summary Executable Summary Report ================================= total file ================================= 71421 /usr/sbin/sshd 22796 /usr/sbin/crond 17905 /usr/lib/systemd/systemd 12344 /usr/bin/sudo 290 /usr/libexec/ipsec/pluto 26 /usr/bin/crontab 24 /usr/bin/su
Para garantizar una seguridad y eficacia óptimas, AuditD debe estar correctamente configurado y reforzado. Los administradores deben comprobar que la configuración de AuditD es inmutable utilizando la opción de control «-e 2» y confirmar que los registros se almacenan en una ubicación centralizada y segura – idealmente un servidor dedicado a aceptar eventos syslog remotos.
AuditD tiene algunos puntos débiles que deben ser considerados – a saber, los errores, la sobrecarga excesiva, la falta de granularidad, la falta de soporte de contenedores y la salida onerosa;
Aprenda a instalar y configurar AuditD, crear reglas y ver el registro de AuditD en este tutorial de TechRepublic.
Puntos clave
Linux se está convirtiendo en un objetivo cada vez más atractivo para los ciberdelincuentes debido a su creciente popularidad y a los dispositivos de gran valor que utiliza en todo el mundo. La seguridad efectiva depende de la defensa en profundidad, y la seguridad del kernel es un elemento clave de la seguridad general del sistema que no se puede pasar por alto. Después de todo, el kernel es la base de un sistema, y si el kernel no es seguro, entonces nada en el sistema es seguro. Por lo tanto, es de vital importancia que los administradores de sistemas Linux den prioridad a la seguridad del núcleo y permanezcan atentos a la implementación de los consejos y las mejores prácticas discutidas en este artículo para protegerse contra las vulnerabilidades de seguridad y evitar los exploits.
Espero que les sirva de ayuda
