Security (Español)

Este artículo contiene recomendaciones y buenas prácticas para fortalecer la seguridad de un sistema Arch Linux.

Esta traducción de Security fue revisada el 2020-02-21. Si existen cambios puede actualizarla o avisar al equipo de traducción.

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: aunque 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 y 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: . 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 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 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 las contraseñas cifradas de los usuarios y solo lo puede leer el usuario root, y en 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 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).

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 para dejarlo con el siguiente contenido:

La opción indica al módulo pam_unix que utilice la política de contraseñas de pam_cracklib.

En ^{[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 () 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 . 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 y 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 y 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:

: No tiene en cuenta a los dispositivos especiales o de bloques del sistema de archivos.
: 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 noexec en /home impide la ejecución de scripts dejando de funcionar, por ejemplo Wine* y Steam.
- Algunos paquetes como las fuentes de pueden necesitar en .

Los sistemas de archivos destinados a alojar datos solo deberían montarse con , y noexec.

Los directorios a tener en cuenta en estos casos son:

/home

Permisos de archivos

Si un atacante toma el control de cuentas de usuario normales como o (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 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

auth optional pam_faildelay.so delay=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 después de tres intentos fallidos de inicio de sesión , añadir los siguientes parámetros a la configuración de PAM:

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

se refiere a segundos. Para bloquear a un usuario de forma permanente después de 3 intentos fallidos de inicio de sesión elimina  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 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 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 no 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

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 y /sbin/umount.cifs desde cualquier máquina (ALL).

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 o lo que es lo mismo 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 se indica el editor que utilizará . Por ejemplo, para indicar que vim sea el editor que utilice :

$ export SUDO_EDITOR=vim

Otra opción es utilizar el editor , 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 .

Permitir el uso de su a ciertos usuarios

El modulo PAM (Español) hace que solo los usuarios del grupo 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 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

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 utiliza un conjunto básico de parches de fortificación del kernel y proporciona más opciones relacionadas con la seguridad que el paquete . 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 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)

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 solo deja acceder a los logs del kernel a procesos que tienen el permiso , que por defecto son los procesos iniciados por root.

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 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 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 hay más información.

Configurar kernel.kptr_restrict a 2 oculta en las direcciones de símbolos del kernel en cualquier caso.

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 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 a o en todo el código con .

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 . Esta opción se activa por defecto y evita que un proceso sin el permiso realice llamadas de tipo 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

Nota: Los siguientes comandos pueden ejecutarse sin problema como root, y también mediante sudo a los usuarios permitidos con o sin contraseña.

hidepid

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 con las opciones y . Estas opciones están documentadas .

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 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 y también es necesario configurar así:

Para que las sesiones de los usuarios funcionen correctamente es necesario configurar de la siguiente forma el servicio systemd-logind:

Restricción de la carga de módulos

El kernel de Arch tiene la opción activada por defecto; esto quiere decir que todos los módulos del paquete 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 en la línea de comandos del kernel. Hay más información en https://docs.kernel.org/admin-guide/module-signing.html.

Desactivación de kexec

Kexec permite iniciar otro kernel desde el kernel actual.

Restricción de acceso al kernel (kernel lockdown)

El kernel de Linux a partir de la versión 5.4 tiene la opción 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:

: impide la modificación del kernel que se ejecuta actualmente, como podría hacerse con kexec y bpf.
: impide la extracción de información confidencial del kernel.

Para activar kernel lockdown en tiempo de ejecución (modo puede ser o ):

# echo modo > /sys/kernel/security/lockdown

Para activar kernel lockdown en el arranque hay que utilizar el parámetro del kernel .

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://docs.kernel.org/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 , 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.

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í.

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 (Español), 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 (Español).
Consultar Simple stateful firewall (Español) para utilizar y configurar el cortafuegos iptables.
Consultar Category:Firewalls para configurar netfilter de varias formas.
Consultar Ipset (Español) 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 (Español) 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.

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 y sus dependencias proporcionan las cadenas de confianza por defecto de certificados SSL para Internet. Arch confía en fuentes de confianza como 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 .
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. 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 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:

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, 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 , eliminar bzip2recover y volver a compilarlo.

Véase también

gollark: Trivially.

gollark: <@151391317740486657> Here's the obliterator so far. Isn't it cool?

gollark: I am implementing Monopsony.

gollark: I once even had Opus on my neural interface (in an outdated copy of the potatOS sandbox).

gollark: Yes.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.