Security (Español)
Este artículo contiene recomendaciones y buenas prácticas para fortalecer la seguridad de un sistema Arch Linux.
Conceptos
- Es posible inutilizar un sistema si se le aplica demasiada seguridad, por lo que conviene aplicar ésta de forma adecuada.
- Aunque hay muchas formas de aplicar y mejorar la seguridad, los usuarios son y serán la mayor amenaza. La seguridad se distribuye en capas, y cuando un ataque rompe una capa, otra capa debería detenerlo. Un sistema no es 100% seguro a menos que lo desconectes de cualquier red, lo aisles dentro de una caja fuerte cerrada y no lo utilices.
- Ser un poco paranoico ayuda, y sospechar de todo también. Si algo parece demasiado bueno para ser cierto, ¡lo mismo lo es!
- El principio de mínimo privilegio: cualquier usuario, proceso, programa o servicio de un sistema solo puede tener acceso a la información y recursos para los que tiene autorización, y a nada más.
Contraseñas
Las contraseñas son fundamentales para garantizar la seguridad de un sistema Linux. Garantizan la seguridad de las cuentas de usuario, sistemas de archivos cifrados, y claves SSH/GPG. Todo lo anterior es importante para que un ordenador identifique a la persona que lo usa y confíe en él, por lo que buena parte de la seguridad consiste en utilizar contraseñas seguras y mantenerlas protegidas.
Utilización de contraseñas seguras
Una contraseña fiable es lo suficientemente compleja como para no dar con ella fácilmente a partir, por ejemplo, de infomación personal o mediante el uso de técnicas de descrifrado como la ingeniería social o los ataques de fuerza bruta. La longitud y la aleatoriedad son características fundamentales de las contraseñas fiables. En criptografía, la calidad de una contraseña se refiere a su seguridad entrópica.
Las contraseñas inseguras son las que contienen:
- Información personal que pueda identificar al usuario, como por ejemplo el nombre del perro, la fecha de nacimiento, el código postal, su videojuego favorito, etc.
- Sustituciones sencillas de letras, por ejemplo:
M4r1aM0ren0, pues los ataques de diccionario modernos lo tienen en cuenta. - Palabras o textos sencillos con números, símbolos o caracteres delante o detrás, como por ejemplo:
$casaroja7. - Frases cortas con sentido, por ejemplo:
todas las luces amarillasaunque incluyan sustituciones de caracteres. - Cualquiera de las indicadas en la lista de contraseñas más utilizadas.
La mejor contraseña es la que tiene entre 8 y 64 caracteres (si son más mejor todavía) y generados por una fuente aleatoria.
Aplicaciones como pwgen y apgAUR pueden generar contraseñas aleatorias pero pueden ser difíciles de memorizar. Una forma de memorizar contraseñas (para los que les gusta escribir) es generar una contraseña muy larga, memorizar los primeros caracteres (al menos 8) para poder utilizarla y escribir la contraseña completa en un papel; después ir incorporando en la memoria el resto de caracteres de uno en uno y poco a poco hasta memorizar la contraseña completa. Si bien esta técnica es más complicada, es una de las más seguras, a prueba de ataques de fuerza bruta.
También hay distintas técnicas para generar contraseñas seguras y fáciles de memorizar.
Una técnica adecuada para crear una buena contraseña es utilizar los caracteres de cada palabra de una frase incluyendo alguna sustitución, por ejemplo, si se toma como base la frase «la chica camina por la calle mientras llueve», puede deducirse la siguiente contraseña: 1cCp!mL1. Con esta técnica puede recordarse fácilmente una contraseña pero hay que tener en cuenta que hay letras que tienen más probabilidades que otras de estar al principio de una palabra. Si se utiliza una letra con altas probabilidades de que se encuentre al principio de una palabra, la contraseña resultante no sería lo suficientemente robusta. Hay más información en la Wikipedia: Frecuencia de aparición de letras.
Otra técnica es recordar muchas palabras que no tengan relación entre sí, unirlas en una frase y utilizarla como contraseña. Si la frase es suficientemente larga, tendrá entropía suficiente como para compensar la pérdida de entropía por utilizar palabras del diccionario; en el XKCD comic lo demuestra muy bien. El método Diceware Passphrase[enlace roto 2021-05-17] genera este tipo de contraseñas largas mediante un generador de números aleatorios (game dice).
Otra técnica muy efectiva es escribir contraseñas generadas de forma aleatoria en un papelito y guardarlo en un lugar seguro, como un monedero, una cartera o una caja fuerte. La mayoría de las personas normalmente saben cómo proteger sus cosas tangibles o físicas de valor de un posible ataque y lo entienden mejor en comparación con la seguridad digital. En este artículo Bruce Schneier muestra la efectividad de esta técnica.
También es muy efectivo combinar las técnicas de memorización y aleatoriedad para alojar contraseñas largas y aleatorias en un gestor de contraseñas, accediendo a él mediante una "contraseña maestra" que debería memorizarse y no guardarse en ningún otro lugar. El gestor de contraseñas debería instalarse en un sistema que proporcione las contraseñas de una forma sencilla, y dependiendo de la situación esto puede ser un inconveniente o un aspecto de la seguridad. Algunos gestores de contraseñas son aplicaciones que se pueden instalar en smartphones, de forma que las contraseñas quedan disponibles para verlas e introducirlas de forma manual en sistemas donde el gestor de contraseñas no está instalado. Es importante saber que un gestor de contraseñas tiene un punto único de fallo, esto es: si se olvida la contraseña maestra no habrá forma de acceder a las contraseñas.
Hay más información en el artículo de Bruce Schneier Choosing Secure Passwords, The passphrase FAQ o Wikipedia:Password strength.
Gestión de contraseñas
Las buenas contraseñas hay que guardarlas bien. Hay que tener cuidado con los keyloggers (tanto de software como de hardware), los screen loggers (virus que capturan la pantalla), la ingeniería social, el mirar por encima del hombro y no utilizar la misma contraseña en varios servidores, de forma que si un atacante compromete uno, no pueda saltar a otro. Los gestores de contraseñas están bien para disponer de muchas contraseñas complejas, pero al copiar la contraseña desde el gestor de contraseñas para pegarla en la aplicación que la necesita, después hay que asegurarse de eliminar esa contraseña de la memoria. También es necesario asegurarse de que una contraseña no quede registrada en un log; esto ocurre por ejemplo al incluir una contraseña como parámetro de una orden en la línea de comandos, de forma que quede registrada en el historial, concretamente en archivos como .bash_history.
Hay que tener en cuenta la siguiente regla: aunque las contraseñas seguras sean difíciles de recordar, no hay que utilizar contraseñas débiles. Es mejor tener contraseñas seguras (largas y complejas) guardadas en una base de datos cifrada con una contraseña maestra también segura, que recordar contraseñas débiles. Otra forma que quizá puede ser igual de efectiva es apuntar las contraseñas seguras en un papel[1] y guardarlo con las medidas físicas de protección adecuadas.
Otro aspecto importante es saber si hay contraseñas en otras partes del sistema de archivos donde fácilmente pueda tenerse acceso. Si se utiliza la misma contraseña para cifrar un disco que para iniciar sesión (esto tiene sentido por comodidad, al montar de forma automática un directorio o una partición cifrada al iniciar sesión), hay que asegurarse de que el fichero /etc/shadow esté ubicado en la partición cifrada o contenga las contraseñas cifradas con un algoritmo fuerte de cifrado, como por ejemplo sha512/bcrypt y no MD5. Hay más información en contraseñas cifradas con SHA.
Si una copia de seguridad de la base de datos de contraseñas se guarda en una unidad cifrada con contraseña o en un servicio de almacenamiento remoto protegido con contraseña, hay que asegurarse de que esta última contraseña no esté registrada única y exclusivamente en la base de datos cifrada, pues de ser así en un caso donde no se disponga de esta contraseña puede perderse el acceso a la copia de seguridad. En estos casos es muy útil crear un hash sencillo de la contraseña maestra de la base de datos y utilizarlo como contraseña de acceso a los lugares donde se guardan las copias de seguridad. Si hay sospecha de que la contraseña maestra ha sido comprometida, esta hay que cambiarla inmediatamente en la base de datos de contraseñas y en los lugares donde se alojen las copias de seguridad. Garantizar la seguridad de varias versiones de la copia de seguridad puede ser muy complicado pues implica proteger cada versión con una contraseña maestra distinta. Como no es sencillo averiguar en qué momento se ha podido filtrar o comprometer la contraseña maestra, lo mejor es ir cambiando esta contraseña maestra con cierta frecuencia. Si hay sospecha de que al menos una copia de seguridad ha sido comprometida, lo mejor es cambiar todas las contraseñas que contiene la base de datos antes de que alguien pueda averiguarlas mediante fuerza bruta.
Cifrado de contraseñas
Arch guarda en /etc/shadow las contraseñas cifradas de los usuarios y solo lo puede leer el usuario root, y en /etc/passwd guarda el resto de información de cada usuario y lo puede leer cualquier usuario. Hay más información en Users and groups (Español)#Base de datos del usuario y también en #Restringir el uso de la cuenta root.
Las contraseñas se crean con el comando passwd y se guardan en /etc/shadow cifradas con la función crypt mediante técnicas Key stretching. Hay más información en SHA password hashes. A las contraseñas también se les aplica [[Wikipedia:es:Sal (criptografía)|sal criptográfica] para evitar ataques de tipo tabla arcoíris.
Hay más información en Cómo guarda Linux las contraseñas (Entendiendo el cifrado con las utilidades shadow)[enlace roto 2021-11-19].
Política de contraseñas seguras con pam_cracklib
pam_cracklib es una librería que ofrece protección contra ataques de diccionario y facilita la implementación de una política de contraseñas seguras en todo el sistema.
Por ejemplo, para aplicar la siguiente política de contraseñas:
- en caso de error, introducir 2 veces la contraseña
- mínimo 10 caracteres (opción minlen)
- al menos 6 caracteres distintos de la contraseña anterior (opción difok)
- al menos un dígito (opción dcredit)
- al menos una letra mayúscula (opción ucredit)
- al menos una letra minúscula (opción lcredit)
- al menos un caracter distinto de los anteriores indicados (ocredit option)
se edita el fichero /etc/pam.d/passwd para dejarlo con el siguiente contenido:
#%PAM-1.0 password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 password required pam_unix.so use_authtok sha512 shadow
La opción password required pam_unix.so use_authtok indica al módulo pam_unix que utilice la política de contraseñas de pam_cracklib.
En pam_cracklib(8)[enlace roto 2020-09-13] y pam_unix(8) hay más información.
CPU
Microcódigo
Consultar microcode (Español) para ver cómo instalar actualizaciones de seguridad importantes para el microcódigo de la CPU.
Desactivación de Hyper-Threading
El desarrollador del kernel Greg Kroah-Hartman demuestra en este video que desactivar el Hyper-Threading mejora la seguridad de un sistema que ejecuta código no confiable. Un ejemplo de código no confiable es un navegador web con Javascript activado. Esta solución puede implicar pérdida de rendimiento.
El Hyper-Threading se puede desactivar en el kernel (consultar #Desactivación de hyper-threading 2) y probablemente también se pueda desactivar desde el firmware del sistema. Es recomendable consultar la documentación de la placa base para ver cómo hacerlo.
Vulnerabilidades de la CPU
A raíz de las vulnerabilidades Spectre/Meltdown de las CPUs más populares, el kernel tiene una serie de configuraciones para reducir los riesgos relacionados. Hay más detalles en la documentación del kernel.
Memoria
Versión segura de malloc
malloc() es una función de la librería glibc y hardened_malloc (hardened_mallocAUR) es su versión segura. hardened_malloc lo empezó a desarrollar Daniel Micay (desarrollador de GrapheneOS) en las librerías Bionic y musl formando parte también en las distribuciones Linux estandar de la arquitectura x86_64.
Aunque hardened_malloc no viene en la librería glibc (se agradece colaboración para conseguirlo), es sencillo utilizarlo mediante el uso de LD_PRELOAD como puede verse más adelante. En las pruebas realizadas activando hardened_malloc de forma global en /etc/ld.so.preload solo falla con algunas aplicaciones, como por ejemplo con man. Como hardened_malloc penaliza el rendimiento es conveniente su uso en las aplicaciones que lo requieran y mantengan un equilibrio adecuado con la seguridad.
Para probarlo puedes utilizar el script hardened-malloc-preload o iniciar directamente una aplicación con LD_PRELOAD:
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox
Para utilizar hardened_malloc con Firejail hay información en su página wiki y en el repositorio de github de hardened_malloc hay más información para desarrolladores.
Almacenamiento
Cifrado de discos
La única manera de evitar el robo de información de un disco cuando el ordenador está apagado o el disco en cuestión no está montado es el cifrado de discos de forma completa y con una contraseña fuerte.
Un disco cifrado deja accesible su información cuando el ordenador está encendido y el disco está montado, por lo que es recomendable montar las particiones que se vayan a utilizar y desmontarlas en el momento que dejen de utilizarse.
Algunos programas como dm-crypt (Español) pueden cifrar un fichero de imagen de disco y utilizarlo como un volumen virtual, de forma que es una alternativa al cifrado completo del disco en el caso de proteger ciertas partes del sistema.
Sistema de archivos
Como el kernel protege los enlaces duros y los simbólicos mediante la activación de fs.protected_hardlinks y fs.protected_symlinks respectivamente con sysctl, ya no hace falta mantener separados en puntos de montaje distintos los directorios donde todos los usuarios tienen permiso de escritura.
Aunque es poco elegante mantener esta separación de directorios, sirve para limitar el daño producido en el caso de falta de espacio en disco, por lo que mantener en puntos de montaje distintos los directorios /var y /tmp previene la parada de servicios producida por este motivo. Las cuotas de disco es uno de los mecanismos más flexibles para evitar estos problemas, además del uso de algunos sistemas de archivos como Btrfs que proporciona cuotas en subvolúmenes.
Opciones de montaje
Siguiendo el principio del mínimo privilegio, los sistemas de archivos deben montarse con las restricciones máximas posibles sin perder funcionalidad.
Las opciones más relevantes son:
-
nodev: No tiene en cuenta a los dispositivos especiales o de bloques del sistema de archivos. -
nosuid: Bloquea el funcionamiento de los bits suid y sgid de un archivo. -
noexec: No permite la ejecución directa de ningún archivo binario.- Establecer
noexecen/homeimpide la ejecución de scripts dejando de funcionar, por ejemplo Wine* y Steam. - Algunos paquetes como las fuentes de nvidia-dkms pueden necesitar
execen/var.
- Establecer
exec si está instalado en /home, no para ejecutar los binarios de Windows.Los sistemas de archivos destinados a alojar datos solo deberían montarse con nodev, nosuid y noexec.
Los directorios a tener en cuenta en estos casos son:
/var/home/dev/shm/tmp/boot
Permisos de archivos
Si un atacante toma el control de cuentas de usuario normales como http o nobody (distintas a root) tendrá acceso de lectura a muchos archivos proporcionándole mucha información valiosa sobre el sistema. Esto es debido a que la configuración por defecto de los permisos de los archivos hace que todos los usuarios tengan permiso de lectura sobre cada nuevo archivo que se va creando en el sistema. Para evitar esta situación es conveniente cambiar los permisos sobre los archivos correspondientes de forma que solo su propietario tenga permiso de lectura y nadie más.
Por ejemplo:
# chmod 700 /boot /etc/{iptables,arptables}
La configuración por defecto que hace que cada archivo nuevo pueda leerlo cualquiera viene de configurar Umask a 0022 y para mejorar la seguridad es conveniente cambiarlo. La guía de seguridad NSA RHEL5 Security Guide aconseja configurar umask a 0077 en casos de máxima seguridad, de forma que los archivos nuevos solo puedan leerlos su propietario y ningún usuario más. Consultar Umask (Español) para más información.
Configuración de usuarios
Después de la instalación del sistema no utilices la cuenta root para el día a día, utiliza una cuenta normal de usuario.
Retraso después de un intento fallido de inicio de sesión
Para retrasar el próximo inicio de sesión durante 4 segundos cuando se produce un intento fallido añadir la siguiente línea a /etc/pam.d/system-login:
/etc/pam.d/system-login
auth optional pam_faildelay.so delay=4000000
4000000 es el número de microsegundos de retraso.
Bloqueo de un usuario después de tres intentos fallidos de inicio de sesión
Para mejorar la seguridad se puede bloquear o impedir el inicio de sesión de un usuario después de un número determinado de intentos fallidos. El usuario root puede desbloquear estas cuentas y también se pueden desbloquear automáticamente pasado un tiempo determinado.
Para bloquear a un usuario durante 10 minutos unlock_time=600 después de tres intentos fallidos de inicio de sesión deny=3, añadir los siguientes parámetros a la configuración de PAM:
/etc/pam.d/system-login
auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog
Eso es todo, pruébalo para ver como funciona. Para desbloquear a un usuario de forma manual utiliza la cuenta de root y este comando:
# pam_tally2 --reset --user nombre_de_usuario
unlock_time se refiere a segundos. Para bloquear a un usuario de forma permanente después de 3 intentos fallidos de inicio de sesión elimina unlock_time y su valor de la línea correspondiente. En este caso el usuario no podrá iniciar sesión hasta que el usuario root realice el desbloqueo correspondiente.
Número máximo de procesos
Cuando un sistema lo utilizan muchos usuarios es importante limitar el número de procesos abiertos que puede tener cada uno. De esta forma pueden evitarse las Bombas fork y otros ataques de denegación de servicio. En el archivo de configuración /etc/security/limits.conf se determinan el número de procesos abiertos que un usuario o un grupo de usuarios puede tener. Por defecto todas las configuraciones están comentadas y no tienen efecto. Agregando las dos líneas de abajo se limita por defecto a 100 procesos abiertos a cada usuario del sistema, pero si alguno de ellos utiliza el comando prlimit puede sobrepasar este límite a 200 procesos en la sesión actual. Estos valores pueden cambiarse dependiendo del hardware de la máquina que se administre.
* soft nproc 100 * hard nproc 200
Se puede averiguar el número de hilos por usuario en un momento dado con ps --no-headers -Leo user | sort | uniq --count. Los resultados pueden servir de ayuda para calcular de forma adecuada los valores a aplicar en este tipo de límite.
Iniciar Xorg sin la cuenta de root
Xorg (Español) se considera inseguro por su arquitectura y diseño, y no es recomendable iniciarlo con la cuenta root.
Se puede consultar Xorg#Rootless Xorg para ver cómo iniciarlo sin la cuenta root.
Restringir el uso de la cuenta root
Por definición la cuenta root es la más poderosa de un sistema y para evitar daños hay formas de limitar este poder, o al menos dejar un registro de sus acciones.
Utilizar sudo en lugar de su
Para acceder al sistema con privilegios elevados es preferible utilizar sudo (Español) en lugar de su (Español) por una serie de razones.
- Guarda un log con las acciones privilegiadas realizadas por el usuario.
- No es necesario conocer la contraseña de la cuenta root.
- Al utilizar
sudono se crea un terminal exclusivo para la sesión de root, evitando que un usuario ejecute de forma accidental comandos root si estos comandos no necesitan privilegios de root. Esto hace cumplir el principio de mínimo privilegio. - En lugar de proporcionar un entorno completo de root a un comando, se puede limitar este entorno a ciertos usuarios para ejecutar ciertos programas. Por ejemplo, para dar al usuario alicia acceso a un programa concreto:
# visudo
/etc/sudoers
alice ALL = NOPASSWD: /ruta/al/programa
O hacer que todos los usuarios puedan acceder a comandos determinados. Para que cualquier usuario normal pueda montar recursos compartidos de un servidor Samba:
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs
Esto hace que los usuarios del grupo users puedan ejecutar los comandos /sbin/mount.cifs y /sbin/umount.cifs desde cualquier máquina (ALL).
Para utilizar la versión restringida de nano en lugar de vi con visudo,
/etc/sudoers
Defaults editor=/usr/bin/rnano
Exportar EDITOR=nano visudo se considera un riesgo grave de seguridad pues cualquier cosa puede utilizarse como valor en EDITOR.
Editar archivos utilizando sudo
Ejecutar un editor de texto como root puede ser un riesgo de seguridad pues muchos editores pueden ejecutar comandos del sistema o afectar a otros archivos además del que se edita. Para evitar esta situación se utiliza sudoedit nombrearchivo o lo que es lo mismo sudo --edit nombrearchivo para editar archivos. Esto hace que la edición del archivo se realice con los privilegios normales de tu cuenta y una vez cerrado el editor, con sudo, escribe el archivo original con los privilegios elevados. En la variable de entorno SUDO_EDITOR se indica el editor que utilizará sudoedit. Por ejemplo, para indicar que vim sea el editor que utilice sudoedit:
$ export SUDO_EDITOR=vim
Otra opción es utilizar el editor rvim, que incorpora funcionalidades limitadas para ejecutarlo de forma segura como root.
Limitar el inicio de sesión de root
Configurado sudo (Español) adecuadamente, puede denegarse el inicio de sesión de root o restringirlo lo máximo posible. Para deshabilitar root y utilizar sudo (Español) se utiliza passwd --lock root.
Permitir el uso de su a ciertos usuarios
El modulo PAM (Español) pam_wheel.so hace que solo los usuarios del grupo wheel puedan utilizar su (Español). Consultar su (Español)#su y wheel.
Denegar el inicio de sesión en SSH
Aunque se permita el inicio de sesión como root a usuarios locales, siempre es una buena práctica denegar el inicio de sesión de root en SSH. El propósito es disponer de una capa más de seguridad ante la posibilidad de que puedan comprometer el sistema de forma remota.
Restringir el inicio de sesión con access.conf
Cuando un usuario intenta iniciar sesión con PAM (Español), el archivo de configuración /etc/security/access.conf aplica unas reglas para determinar si tiene acceso o no y desde donde.
+:root:LOCAL -:root:ALL
Pueden aplicarse reglas a usuarios y grupos. En el siguiente ejemplo, el usuario archie, los miembros del grupo whell y los miembros del grupo adm solo pueden iniciar sesión de forma local y el resto de usuarios no tienen acceso desde ningún lugar:
+:archie:LOCAL +:(wheel):LOCAL +:(adm):LOCAL -:ALL:ALL
Hay más información en access.conf(5)
Control de Acceso Obligatorio (MAC)
En Arch y en la mayoría de distribuciones de Linux se utiliza como política de seguridad el Control de Acceso Discrecional (DAC) y se distingue mucho del Control de Acceso Obligatorio (MAC). Fundamentalmente, MAC significa que antes de que un programa realice una acción sobre el sistema, ésta se comprueba con unas reglas. Si bien un usuario puede modificar las políticas DAC, no puede modificar las MAC. Utilizar la política MAC mejora significativamente la seguridad del sistema y hay varias formas de implementarla.
MAC basado en nombre de ruta
El MAC basado en nombre de ruta es un control de acceso simple que proporciona permisos dependiendo de la ruta de un archivo dado. La desventaja de este control de acceso es que un archivo no incorpora sus permisos, por lo que los pierde si se mueve a otra ubicación. Como ventaja, el MAC basado en nombre de ruta puede utilizarse en muchos sistemas de archivos.
- AppArmor es una implementación MAC mantenida por Canonical y se considera como una alternativa sencilla a SELinux.
- Tomoyo es otra opción MAC fácil de usar. Tiene pocas dependencias y está diseñado para ser simple en su uso e implementación.
Etiquetas MAC
Este sistema de control de acceso se basa en el uso de etiquetas y consiste en gestionar la seguridad de un archivo mediante sus atributos extendidos. Si bien este sistema es más flexible que el de MAC basado en nombre de ruta, solo funciona en sistemas de archivos que soporten estos atributos extendidos.
- SELinux se basa en un proyecto de la NSA cuyo objetivo es mejorar la seguridad de Linux mediante la implementación de MAC independientemente de usuarios y roles. Este sistema proporciona una implementación multicapa muy robusta de políticas de seguridad MAC, a la vez que facilita su gestión y control en sistemas que van cambiando y creciendo.
Listas de Control de Acceso
Access Control Lists (Español) (ACLs) son una alternativa para implementar reglas de alguna forma y directamente en el sistema de archivos. Las ACLs implementan el control de acceso de un programa mediante una lista de acciones permitidas.
Mejoras en la seguridad del Kernel
Autoprotección del Kernel / reducción de vulnerabilidades
El paquete linux-hardened utiliza un conjunto básico de parches de fortificación del kernel y proporciona más opciones relacionadas con la seguridad que el paquete linux. Se puede compilar un kernel personalizado para tener un equilibrio distinto entre seguridad y rendimiento que el que viene por defecto.
Si se utiliza un driver propietario como NVIDIA (Español) es posible que se tenga que utilizar su paquete DKMS correspondiente.
ASLR en procesos de usuario
El paquete linux-hardened proporciona una implementación mejorada de ASLR (Aleatoriedad en la disposición del espacio de direcciones) para procesos de usuario. El comando paxtest puede utilizarse para obtener una estimación de la entropía proporcionada:
Procesos de 64-bit
linux-hardened 5.4.21.a-1-hardened
Anonymous mapping randomization test : 32 quality bits (guessed) Heap randomization test (ET_EXEC) : 40 quality bits (guessed) Heap randomization test (PIE) : 40 quality bits (guessed) Main executable randomization (ET_EXEC) : 32 quality bits (guessed) Main executable randomization (PIE) : 32 quality bits (guessed) Shared library randomization test : 32 quality bits (guessed) VDSO randomization test : 32 quality bits (guessed) Stack randomization test (SEGMEXEC) : 40 quality bits (guessed) Stack randomization test (PAGEEXEC) : 40 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed) Offset to library randomisation (ET_EXEC): 34 quality bits (guessed) Offset to library randomisation (ET_DYN) : 34 quality bits (guessed) Randomization under memory exhaustion @~0: 32 bits (guessed) Randomization under memory exhaustion @0 : 32 bits (guessed)
linux 5.5.5-arch1-1
Anonymous mapping randomization test : 28 quality bits (guessed) Heap randomization test (ET_EXEC) : 28 quality bits (guessed) Heap randomization test (PIE) : 28 quality bits (guessed) Main executable randomization (ET_EXEC) : 28 quality bits (guessed) Main executable randomization (PIE) : 28 quality bits (guessed) Shared library randomization test : 28 quality bits (guessed) VDSO randomization test : 20 quality bits (guessed) Stack randomization test (SEGMEXEC) : 30 quality bits (guessed) Stack randomization test (PAGEEXEC) : 30 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed) Offset to library randomisation (ET_EXEC): 28 quality bits (guessed) Offset to library randomisation (ET_DYN) : 28 quality bits (guessed) Randomization under memory exhaustion @~0: 29 bits (guessed) Randomization under memory exhaustion @0 : 29 bits (guessed)
linux-lts 4.19.101-1-lts
Anonymous mapping randomization test : 28 quality bits (guessed) Heap randomization test (ET_EXEC) : 28 quality bits (guessed) Heap randomization test (PIE) : 28 quality bits (guessed) Main executable randomization (ET_EXEC) : 28 quality bits (guessed) Main executable randomization (PIE) : 28 quality bits (guessed) Shared library randomization test : 28 quality bits (guessed) VDSO randomization test : 19 quality bits (guessed) Stack randomization test (SEGMEXEC) : 30 quality bits (guessed) Stack randomization test (PAGEEXEC) : 30 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed) Offset to library randomisation (ET_EXEC): 28 quality bits (guessed) Offset to library randomisation (ET_DYN) : 28 quality bits (guessed) Randomization under memory exhaustion @~0: 28 bits (guessed) Randomization under memory exhaustion @0 : 28 bits (guessed)
Procesos de 32-bit (en un kernel x86_64)
linux-hardened
Anonymous mapping randomization test : 16 quality bits (guessed) Heap randomization test (ET_EXEC) : 22 quality bits (guessed) Heap randomization test (PIE) : 27 quality bits (guessed) Main executable randomization (ET_EXEC) : No randomization Main executable randomization (PIE) : 18 quality bits (guessed) Shared library randomization test : 16 quality bits (guessed) VDSO randomization test : 16 quality bits (guessed) Stack randomization test (SEGMEXEC) : 24 quality bits (guessed) Stack randomization test (PAGEEXEC) : 24 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed) Offset to library randomisation (ET_EXEC): 18 quality bits (guessed) Offset to library randomisation (ET_DYN) : 16 quality bits (guessed) Randomization under memory exhaustion @~0: 18 bits (guessed) Randomization under memory exhaustion @0 : 18 bits (guessed)
linux
Anonymous mapping randomization test : 8 quality bits (guessed) Heap randomization test (ET_EXEC) : 13 quality bits (guessed) Heap randomization test (PIE) : 13 quality bits (guessed) Main executable randomization (ET_EXEC) : No randomization Main executable randomization (PIE) : 8 quality bits (guessed) Shared library randomization test : 8 quality bits (guessed) VDSO randomization test : 8 quality bits (guessed) Stack randomization test (SEGMEXEC) : 19 quality bits (guessed) Stack randomization test (PAGEEXEC) : 19 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed) Offset to library randomisation (ET_EXEC): 8 quality bits (guessed) Offset to library randomisation (ET_DYN) : 13 quality bits (guessed) Randomization under memory exhaustion @~0: No randomization Randomization under memory exhaustion @0 : No randomization
Restricción de acceso a los logs del kernel
Un atacante puede utilizar la información que proporcionan los logs del kernel para intentar comprometerlo, como por ejemplo direcciones de memoria sensibles. La opción kernel.dmesg_restrict solo deja acceder a los logs del kernel a procesos que tienen el permiso CAP_SYS_ADMIN, que por defecto son los procesos iniciados por root.
/etc/sysctl.d/51-dmesg-restrict.conf
kernel.dmesg_restrict = 1
Ocultación de punteros del kernel en /proc/kallsyms
Si se configura kernel.kptr_restrict a 1 hace que los usuarios normales (sin el permiso CAP_SYSLOG) no puedan ver en /proc/kallsyms ninguna dirección de símbolos del kernel. Si se dispone de un kernel compilado esta configuración reduce bastante las posibilidades de comprometer el kernel debido a que no se podrían averiguar de forma dinámica las direcciones de símbolos del kernel. En el caso de disponer de un kernel precompilado de Arch Linux como el que se instala por defecto esta configuración no sirve de nada pues el atacante puede obtener los símbolos directamente de las fuentes del paquete del kernel. Esta configuración hace que algunas operaciones del comando perf no funcionen cuando lo ejecuta un usuario normal (no root), aunque si es cierto que para que este comando funcione plenamente es necesario ejecutarlo con permisos de root. En FS#34323 hay más información.
Configurar kernel.kptr_restrict a 2 oculta en /proc/kallsyms las direcciones de símbolos del kernel en cualquier caso.
/etc/sysctl.d/51-kptr-restrict.conf
kernel.kptr_restrict = 1
Mejoras en la seguridad de BPF
BPF es un sistema que carga y ejecuta bytecode en el kernel de forma dinámica y en tiempo de ejecución. Este sistema suelen utilizarlo otros subsistemas del kernel de Linux relacionados con el procesamiento de paquetes de red (por ej. XDP), la depuración y seguimiento del kernel (kprobes, uprobes, tracepoints) y la seguridad mediante aislamiento de procesos como seccomp. Este sistema es muy útil en situaciones de seguridad avanzada de red, medición de rendimiento y la depuración dinámica del kernel.
En un principio BPF era un acrónimo de "Berkeley Packet Filter" pues se utilizaba en BSD para capturar paquetes de red, después evolucionó a BPF Extendido (eBPF) y poco después cambió el nombre de nuevo a BPF pero sin ser un acrónimo. Si bien BPF puede utilizarse en herramientas de filtrado de paquetes de red no hay que confundirlo con iptables o netfilter.
El código BPF puede interpretarse o compilarse mediante un compilador JIT (Compilador en Tiempo de Ejecución). Por defecto el kernel de Arch está compilado con CONFIG_BPF_JIT_ALWAYS_ON de forma que no puede interpretar BPF pero sí puede ejecutarlo mediante un compilador JIT. Esta situación hace más complicado llevar a cabo ataques del estilo SCPECTRE mediante BPF. Hay más detalles en el parche del kernel que trata sobre CONFIG_BPF_JIT_ALWAYS_ON.
El kernel incluye una mejora en la seguridad para disminuir el riesgo de los ataques JIT spraying pero penaliza el rendimiento y la capacidad de depurar/hacer seguimiento de los programas BPF. Esta mejora puede activarse para código no privilegiado configurando net.core.bpf_jit_harden a 1 o en todo el código con 2.
Hay más detalles en las configuraciones de net.core.bpf_* de la documentación del kernel.
El alcance de ptrace
Yama LSM es un módulo de Linux que viene activado por defecto en Arch y proporciona la opción kernel.yama.ptrace_scope. Esta opción se activa por defecto y evita que un proceso sin el permiso CAP_SYS_PTRACE realice llamadas de tipo ptrace a otros procesos fuera de su alcance. Esta situación mejora significativamente la seguridad, si bien muchos depuradores no podrán funcionar plenamente. Sin esta opción activada, un proceso de un usuario podría realizar las llamadas indicadas a cualquier otro proceso del mismo usuario si los dos procesos comparten el mismo espacio de nombres y si no existe alguna otra cosa que los separe. Esta situación demuestra el riesgo de la depuración de procesos.
Ejemplos de depuradores que funcionan
gdb -p $PIDstrace -p $PIDperf trace -p $PIDreptyr $PID
hidepid
- Esto puede dar problemas con aplicaciones que utilicen Xorg (Español) dentro de una sandbox (consultar alternativa).
- También puede dar problemas con D-Bus (Español), PulseAudio (Español) y bluetooth (Español) utilizando systemd > 237.64-1.
Un usuario que no sea root puede ver sus procesos y los de otros usuarios en /proc. Como esta situación puede producir riesgos de seguridad, el kernel puede hacer que un usuario que no sea root solo pueda ver sus procesos o ninguno en /proc. Esto es posible mediante el montaje de proc con las opciones hidepid= y gid=. Estas opciones están documentadas [2].
El uso de estas opciones hace que un intruso no pueda obtener información sobre otros usuarios y los procesos que tengan activos, como por ejemplo si un demonio se ejecuta con privilegios elevados o si algún usuario está ejecutando algún programa vulnerable o sensible. Además, estas opciones evitan que un intruso acceda a información sensible que pueda estar contenida en los argumentos de programas que no han tenido en cuenta criterios básicos de seguridad.
Si es necesario que un usuario o servicio sin privilegios de root tenga acceso a /proc/<pid> para que pueda ver la información de los procesos de todos los usuarios, es necesario incluir al usuario en cuestión en el grupo proc y también es necesario configurar /etc/fstab así:
/etc/fstab
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
Para que las sesiones de los usuarios funcionen correctamente es necesario configurar de la siguiente forma el servicio systemd-logind:
/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service] SupplementaryGroups=proc
Restricción de la carga de módulos
El kernel de Arch tiene la opción CONFIG_MODULE_SIG_ALL activada por defecto; esto quiere decir que todos los módulos del paquete linux están firmados y que el kernel solo cargará módulos firmados con una clave válida. En la práctica, el kernel no cargará los modulos compilados de forma local o proporcionados por paquetes como wireguard-arch[enlace roto: replaced by linux]. Esta restricción también puede realizarse agregando module.sig_enforce=1 en la línea de comandos del kernel. Hay más información en https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html.
Desactivación de kexec
Kexec permite iniciar otro kernel desde el kernel actual.
/etc/sysctl.d/51-kexec-restrict.conf
kernel.kexec_load_disabled = 1
Restricción de acceso al kernel (kernel lockdown)
El kernel de Linux a partir de la versión 5.4 tiene la opción kernel lockdown para restringir el acceso al kernel, cuyo objetivo es mejorar la separación entre el kernel y el UID 0 del usuario root. Al activar esta opción algunas aplicaciones que acceden al kernel o al hardware pueden dejar de funcionar. Esta opción tiene dos modos para restringir el acceso de los usuarios al kernel:
-
integrity: impide la modificación del kernel que se ejecuta actualmente, como podría hacerse con kexec y bpf. -
confidentiality: impide la extracción de información confidencial del kernel.
Para activar kernel lockdown en tiempo de ejecución (modo puede ser integrity o confidentiality):
# echo modo > /sys/kernel/security/lockdown
Para activar kernel lockdown en el arranque hay que utilizar el parámetro del kernel lockdown=mode.
Desactivación de hyper-threading
En caso de tener una CPU Intel (Español), hay que considerar desactivar hyper-threading debido a la vulnerabilidad MDS. Hay más información en https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html.
Para comprobar si la máquina está afectada, puede realizarse la siguiente comprobación:
$ grep . -r /sys/devices/system/cpu/vulnerabilities/
Si el resultado contiene SMT vulnerable, es necesario desactivar hyper-threading. Para ello, hay que agregar los siguientes parámetros del kernel:
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force
Después de un reinicio es necesario comprobar de nuevo si la máquina está afectada de forma que el resultado indique SMT disabled.
Desactivar hyper-threading implica pérdida de rendimiento, por lo que es necesario evaluar si compensa o no.
Aislamiento de aplicaciones
Consultar también aislamiento de procesos.
CONFIG_USER_NS hace que el kernel proporcione espacios de nombres de usuario de forma que los contenedores (vservers) puedan utilizarlos para separar la información de un usuario entre servidores virtuales. Esta configuración viene activada por defecto en linux (versión 4.14.5 y posteriores), en linux-lts (versión 4.14.15 y posteriores) y en linux-hardened. Si este elemento de configuración no está activado pueden perderse ciertas funcionalidades relacionadas con el aislamiento de aplicaciones.CONFIG_USER_NS_UNPRIVILEGED viene activada por defecto en linux (versión 5.1.8 y posteriores), en linux-lts (versión 4.19.55-2 y posteriores) y en linux-zen (versión 5.1.14.zen1-2 y posteriores) a menos que kernel.unprivileged_userns_clone sysctl esté configurada a 0. Tener activada esta configuración aumenta el riesgo de ataques por escalación de privilegios, por lo que es aconsejable desactivarla manualmente o utilizar el kernel de linux-hardened. Hay más información en FS#36969.Firejail
Firejail es una herramienta para aislar aplicaciones y servidores fácil de utilizar. Se recomienda su uso para navegadores web, aplicaciones con conexión a Internet, así como para cualquier servidor en producción.
bubblewrap
bubblewrap es una herramienta para aislar aplicaciones desarrollada por Flatpak que tiene menor impacto en la instalación que Firejail. Aunque bubblewrap no tiene ciertas funcionalidades como el uso de listas de rutas de archivo permitidas, proporciona otras como puntos de montaje enlazados o la creación de espacios de nombres para user/IPC/PID/network/cgroup. La herramienta bubblewrap puede aislar aplicaciones de forma simple o compleja. Para facilitar el uso de bubblewrap a la hora de aislar ciertas aplicaciones conocidas hay disponible una colección de scripts aquí[3].
Jaulas root (chroots)
Para disponer de un entorno totalmente aislado se pueden crear jaulas root (chroot (Español)) de forma manual.
Contenedores linux (LXC)
Los Linux Containers son una buena opción cuando se necesita aislar más todavía un entorno que las opciones vistas pero sin llegar al aislamiento que proporcionan KVM y VirtualBox. LXC lo ejecuta el kernel de linux en una especie de jaula como chroot con su propio hardware virtual.
Otras opciones de virtualización
Se puede mejorar el aislamiento y la seguridad de aplicaciones de alto riesgo o navegar por sitios web peligrosos con la virtualización proporcionada por soluciones como VirtualBox (Español), KVM, Xen (Español) o Qubes OS (basado en Xen).
Servicios de red y cortafuegos
Cortafuegos
El kernel de Arch tiene distintos cortafuegos como Netfilter que utiliza el módulo iptables (Español) y por otro lado el módulo nftables (Español). Si bien estos dos módulos del kernel no vienen activados por defecto, es conveniente activar alguno de ellos y utilizarlo como cortafuegos para proteger los servicios de red del sistema aunque no se sepa muy bien qué servicios proteger.
- Hay información general en iptables (Español) y nftables.
- Consultar Simple stateful firewall (Español) para utilizar y configurar el cortafuegos iptables.
- Consultar Category:Firewalls para configurar netfilter de varias formas.
- Consultar Ipset para bloquear direcciones IP proporcionadas en una lista, como las listas proporcionadas por Bluetack.
Parámetros del kernel
Los parámetros del kernel relacionados con los servicios de red se pueden configurar con Sysctl y Sysctl#TCP/IP stack hardening indica como hacerlo.
SSH
Para reducir el riesgo de los ataques de fuerza bruta se recomienda utilizar la autenticación basada en claves en lugar de usuario/contraseña (más información en OpenSSH (Español)#Forzamiento de autenticación con claves públicas). También hay disponibles otras soluciones menos efectivas como Fail2ban y Sshguard (Español) basadas en el seguimiento de logs de autenticación para comprobar conductas sospechosas de IPs remotas de forma que mediante la aplicación de iptables rules puedan bloquearse las IPs sospechosas, temporalmente o de forma definitiva. De todas maneras estas soluciones no evitan un ataque por denegación de servicio en el caso de que un atacante intercepte la IP remota de un administrador del servicio SSH y la utilice de forma abusiva para suplantar el inicio de conexión.
También puede mejorarse la seguridad utilizando autenticación de dos pasos. En este sentido Google Authenticator (Español) proporciona un procedimiento de autenticación de dos pasos que utiliza códigos de acceso de un solo uso (OTP).
Es una buena recomendación denegar el acceso a la cuenta de root, tanto para realizar un seguimiento de posibles intrusos como para comprobar los intentos de inicio de sesión del usuario root después de implementar su denegación. En el caso de OpenSSH se puede ver cómo realizar esta configuración en OpenSSH (Español)#Denegar.
DNS
En la mayoría de los sistemas las consultas DNS no van cifradas ni autenticadas, por lo que es posible un ataque de intermediario. Este tipo de ataque consiste en que un atacante intercepta consultas DNS de un cliente web y cambia las respuestas para devolver al cliente web una IP distinta a la verdadera. En esta situación el cliente web utilizará esta IP "ilegítima" para conectar con un servidor web, preparado con una copia adaptada de la web legítima, y realizar un ataque de suplantación o phising. El objetivo del ataque es robar información que proporciona el cliente a la web "ilegítima" como un nombre de usuario y contraseña o información de una tarjeta de crédito. Este ataque es posible debido a que el protocolo DNS del cliente confía siempre en las respuestas que recibe, vengan de donde vengan.
DNSSEC (Español) proporciona autenticación e integridad de información DNS mediante firmas digitales criptográficas. Si bien su uso no está muy extendido, DNSSEC hace que un atacante no pueda realizar modificaciones en las consultas y respuestas DNS, aunque sí podría leerlas.
DNSCrypt (Español) proporciona DNS sobre TLS y DNS sobre HTTPS para cifrar la comunicación con los servidores DNS mediante uno de estos protocolos. Hay más información en Domain name resolution#DNS servers.
En caso de disponer de un nombre de dominio, es conveniente activar la política Sender Policy Framework para evitar la suplantación de correo electrónico.
Proxies (intermediarios)
Normalmente los proxies se utilizan como una capa extra entre aplicaciones y la red, filtrando datos desde orígenes desconocidos. Un proxy pequeño que se ejecute con privilegios bajos tiene mucho menos riesgo que una aplicación compleja que utilice los privilegios de un usuario final.
Por ejemplo, un servidor DNS utiliza las librerías glibc, y si estas librerías tuvieran un bug de forma que un atacante pudiera aprovecharse de él y comprometer el servidor DNS, cualquier cliente DNS que se ejecute con privilegios de root y realice consultas DNS al servidor DNS comprometido, podría aceptar respuestas "envenedadas" y ser comprometido a su vez, produciendo por ejemplo la ejecución remota de código. Esta situación puede evitarse mediante la instalación de un servidor de caché DNS como dnsmasq (Español), que actuaría como proxy o intermediario entre los clientes DNS y los servidores DNS. [4]
Gestión de certificados SSL
Consultar OpenSSL y Network Security Services (NSS) para gestionar certificados SSL propios en servidores. Se aconseja tener en cuenta el proyecto Let’s Encrypt.
El paquete ca-certificates y sus dependencias proporcionan las cadenas de confianza por defecto de certificados SSL para Internet. Arch confía en fuentes de confianza como ca-certificates-mozilla para proporcionar al sistema los certificados de confianza por defecto.
En algunas ocasiones es prudente no confiar en algún certificado, por ejemplo, cuando se leen noticias como esta y no esperar a que lo hagan los proveedores que proporcionan la fuente de confianza. Con Arch es fácil:
- Obtener el certificado en cuestión en formato .crt, por ejemplo en el sitio https://crt.sh se pueden ver o descargar certificados. Si el certificado es de una Autoridad de confianza de certificación raíz, se puede encontrar en la ruta del sistema.
- Copiar el certificado en
/etc/ca-certificates/trust-source/blacklist/. - Con el usuario root ejecutar update-ca-trust.
Para comprobar que funciona basta con navegar a alguna web que utilice alguno de los certificados ubicados en la lista negra del paso 2 y esperar ver en el navegador la alerta indicando que el certificado utilizado por esa web no es de confianza.
Autenticación de paquetes
Los ataques a gestores de paquetes suelen producirse cuando estos no gestionan bien el firmado de paquetes, pero también pueden afectar a gestores de paquetes que gestionan de forma adecuada sistemas de firmado. Arch utiliza por defecto el firmado de paquetes y confía en una red de confianza basada en 5 claves maestras de confianza. Hay más detalles en pacman-key (Español).
Actualizaciones
Es importante mantener el sistema actualizado y al día.
Reiniciar después de actualizar
Normalmente no se actualizan los procesos en ejecución, por lo que es necesario reiniciarlos para que su actualización sea efectiva.
Una vez actualizado el kernel, es complicado que en él se apliquen bien todos los cambios, y la opción más segura es realizar después un reinicio del sistema. Si hay casos donde reiniciar puede suponer un problema, lo mejor es utilizar las actualizaciones en vivo del kernel; de esta forma puede actualizarse el kernel sin tener que reiniciar después.
Seguimiento de alertas de vulnerabilidades
Es fundamental estar al día con las actualizaciones sobre alertas de seguridad de CVE (Common Vulnerabilities and Exposure de la National Vulnerability Database). En su página web pueden descargarse estas alertas. En Arch Linux Security Tracker hay una tabla que combina información del Arch Linux Security Advisory (ASA), el Arch Linux Vulnerability Group (AVG) e información del CVE. Es conveniente conocer el funcionamiento del Equipo de Seguridad de Arch en Arch Security Team.
Seguridad perimetral
Alguien con tiempo y los recursos suficientes puede obtener acceso como root a un ordenador. Implementando las barreras físicas suficientes puede conseguirse un nivel práctico de seguridad para evitarlo.
Un atacante puede tomar control total de un ordenador conectando un dispositvo malicioso a él como un IEEE 1394 (Firewire) o una tarjeta PCI Express o Thunderbolt con acceso total a la memoria. Poco se puede hacer contra esto excepto actualizar firmwares maliciosos contenidos en memorias flash. [5][enlace roto 2021-05-17] En cualquier caso la mayor parte de los atacantes no suelen tener determinación y conocimiento suficiente cómo para realizar este tipo de operaciones maliciosas.
El #Cifrado de discos hace que los datos de un disco duro de un ordenador no estén accesibles en caso de robo del ordenador. No obstante aunque un disco duro esté cifrado, un atacante ingenioso puede utilizar un firmware malicioso en el próximo inicio de sesión para obtener los datos sin cifrar del disco duro.
Protección mediante la BIOS
Establecer una contraseña en la BIOS es una buena medida para evitar que alguien pueda iniciar el ordenador desde un dispositivo externo y tomar control total del ordenador. Hay que asegurarse de que el orden de arranque en BIOS comienza con el disco duro donde reside el sistema operativo del ordenador y si es posible, configurar el resto de dispositivos para que no puedan arrancar el ordenador.
Gestores de arranque
Es muy importante mantener protegido el gestor de arranque. Sin protección podría iniciarse el ordenador directamente a una shell sin usuario/contraseña, como por ejemplo en el caso de utilizar init=/bin/sh como parámetro del kernel.
Syslinux
Syslinux permite utilizar contraseñas de forma que requiera una contraseña para arrancar de forma global o una contraseña para cada elemento del menú de arranque.
GRUB
GRUB también puede utilizar contraseñas. Hay más detalles en GRUB (Español)/Tips and tricks (Español)#Proteger con contraseña el menú de GRUB. GRUB también puede cifrar /boot, de forma que solo algunas partes del código del gestor de arranque permanezcan sin cifrar. La configuración de GRUB, el kernel y initramfs están cifrados.
Utilizar un pendrive como partición de arranque
Una idea bastante conocida es colocar la partición de arranque en un pendrive de forma que el sistema no pueda arrancar sin utilizar ese pendrive como medio de arranque. Los seguidores de esta idea suelen utilizar el cifrado total del disco y también el cifrado del sistema mediante cabeceras separadas y cifradas en la partición de arranque.
Cierre de sesión automático
Con Bash o Zsh se puede utilizar la variable de entorno TMOUT para establecer un tiempo de inactividad antes de que la sesión se cierre de forma automática.
Por ejemplo, la siguiente configuración hace que se cierre la sesión automáticamente de cualquier consola virtual después de 10 minutos de inactividad (60*10). Esta configuración no afecta a las sesiones de los emuladores de terminal iniciadas desde X11:
/etc/profile.d/shell-timeout.sh
TMOUT="$(( 60*10 ))"; [ -z "$DISPLAY" ] && export TMOUT; case $( /usr/bin/tty ) in /dev/tty[0-9]*) export TMOUT;; esac
Si es necesario que todas las sesiones de Bash/Zsh (incluidas las iniciadas desde X) tengan este tiempo de inactividad, hay que utilizar:
$ export TMOUT="$(( 60*10 ))";
Esta configuración no funcionará si hay algún comando ejecutándose en la shell, como una sesión SSH o cualquier otra shell que no tenga en cuenta TMOUT. Esta configuración es muy útil cuando se cuelga GDM/Xorg en un ordenador porque se evita tener que acceder de forma local como root para reiniciarlo.
Protección contra dispositivos USB dañinos
USBGuard es un software que ayuda a proteger el ordenador de dispositivos USB dañinos mediante el uso de reglas basadas en los atributos de los dispositivos. Estos dispositivos USB dañinos pueden implementarse con BadUSB[enlace roto 2021-11-19], PoisonTap o con LanTurtle.
Recompilación de paquetes
Se puede modificar el código fuente de los paquetes para eliminar funciones y aspectos que reduzcan o eviten riesgos de seguridad y después volver a compilarlos. Por ejemplo, para evitar la vulnerabilidad CVE-2016-3189, se puede modificar el código fuente del paquete bzip2, eliminar bzip2recover y volver a compilarlo.