Security (Español)

Esta traducción de
Security
fue revisada el
2020-02-21
. Si existen
cambios
puede
actualizarla
o avisar al
equipo de traducción
.
Artículos relacionados
Arch Security Team
Recomendaciones generales
PAM
Capabilities
Lista de aplicaciones/Seguridad
Security package guidelines
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 amarillas
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
pwgen
y
apg
AUR
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
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:es:Seguridad de la contraseña
.
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)
.
Política de contraseñas seguras con pam_pwquality
pam_pwquality
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.
Advertencia
Esta política no afecta a la cuenta
root
.
Nota
Si es necesario realizar una excepción y no aplicar la política de contraseñas sobre la contraseña de un usuario, esta contraseña debe crearla la cuenta
root
.
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_pwquality.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_pwquality
.
En
pam_pwquality(8)
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_malloc
AUR
) 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
noexec
en
/home
impide la ejecución de scripts dejando de funcionar, por ejemplo
Wine
* y
Steam
.
Algunos paquetes como las fuentes de
nvidia-dkms
[
enlace roto
: replaced by
nvidia-open-dkms
]
pueden necesitar
exec
en
/var
.
Nota
Wine necesita tener activado
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
sudo
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
/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).
Sugerencia
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
Sugerencia
En
linux-hardened
esta restricción viene activada por defecto.
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
Nota
linux-hardened
establece
kptr_restrict=2
por defecto en lugar de
0
.
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
Nota
Los siguientes comandos pueden ejecutarse sin problema como root, y también mediante
sudo
a los usuarios permitidos con o sin contraseña.
gdb -p $PID
strace -p $PID
perf trace -p $PID
reptyr $PID
hidepid
Advertencia
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
virtualbox-host-modules-arch
. 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://docs.kernel.org/admin-guide/module-signing.html
.
Desactivación de kexec
Sugerencia
kexec viene desactivado por defecto en
linux-hardened
.
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
.
Nota
Kernel lockdown no puede desactivarse en tiempo de ejecución.
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
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
.
Nota
El elemento de configuración
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.
Advertencia
La configuración
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 (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.
[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.
Advertencia
No se recomienda realizar
actualizaciones parciales
, pues no son compatibles, pueden dejar el sistema inestable y se puede complicar el proceso de actualización si el sistema no viene actualizándose con bastante frecuencia: al actualizar un componente, se debe actualizar el sistema completo.
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
.
Advertencia
No es conveniente realizar actualizaciones parciales (
partial upgrades
), no están contempladas en Arch Linux y pueden dejar el sistema inestable: cuando se actualiza un componente es necesario actualizar el sistema completo. Cuidado con no tener las actualizaciones al día, pues puede complicar los procesos de actualización.
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]
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
2025-01-22]
,
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.
Véase también
Arch Linux Security Tracker
CentOS Wiki: OS Protection
Hardening the Linux desktop
Hardening the Linux server
Linux Foundation: Linux workstation security checklist
privacytools.io Privacy Resources
Red Hat Enterprise Linux 7 Security Guide
Securing Debian Manual
The paranoid #! Security Guide