CGPS

Madaidan escribió una guía sobre cómo aumentar la seguridad en linux. Vamos a ir paso por paso analizando lo que escribió y desmitificar algunos puntos.

Madaidan escribe:

Este es un consejo pésimo. Tanto, que parece que quiere ser (o quiere que ustedes sean) lo menos seguro posible. De verdad no entiendo qué pasa por su mente. Si quieren ver lo "seguro" que es Windows, MacOS etc, pueden simplemente correr cualquier ransomware. Pueden ver The PC Security Channel para ver lo rápido en lo que se infecta. Incluso en el 'superseguro' MacOS, que ha sido demonstrado que contiene puertas traseras. Pueden correr el ransomware de Lockbit, o pueden intentar un "rm -rf" y ver si hay algún tipo de protección o no.

Antes de todo tenemos que aclarar unos puntos claves.

• la mayoría de infecciones malware ocurren por un error de humano. O sea, uno mismo, sin querer, ejecuta el malware.
• Si uno ejecuta el malware por accidente, el malware tiene los mismos privilegios como su usuario. O sea, puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web.

1. Escogiendo la distribución de Linux

Madaidan escribe cuatro factores que considerar:

1. "Evite distribuciones que congelen los paquetes"

Este es un punto erróneo, como vimos con el descubrimiento de una puerta trasera en la utilidad XZ. En ese caso, una versión nueva de XZ incluía una puerta trasera, y afortunadamente, las distribuciones que congelan los paquetes no fueron afectadas, ya que lograron encontrar la puerta trasera antes de que se metiera en esas distribuciones. Lo que en realidad importa es la habilidad de los mantenedores y los equipos de seguridad de rápidamente y efectivamente proveer actualizaciones para los programas en los que se han descubierto vulnerabilidades. En este caso, las distribuciones más grandes, que tienen equipos de seguridad buenos, son las más seguras. Aun que tengan una distribución de 'rolling release', puede tardar tiempo para que un mantenedor cree la versión nueva del paquete.

2. "Eviten distribuciones que usan systemd"

Yo prefiero evitar el uso de systemd, y prefiero usar Runit. Sin embargo, hay poca diferencia en términos de seguridad. Si uno ejecuta el malware, sin importar el sistema init, él puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web. Sí es cierto que un programa enorme como systemd puede crear más posibilidades para encontrar vulnerabilidades. Por ejemplo, systemd tiene un servicio de resolución de DNS (no entiendo por qué debe ser parte de un sistema de init...?) que ha tenido varios problemas de seguridad. Pero, también se puede usar systemd para configurar privilegios restringidos como un sandbox y así proteger el sistema. Así que tiene sus ventajas, y desventajas.

Además, el sistema de init no debería ser un factor para elegir una distribución, ya que en muchos casos es posible cambiar el sistema de init. Yo tengo instrucciones sobre cómo instalar Runit en Debian para remplazar systemd.

Sin embargo, tengan en cuenta que usar un sistema de init diferente no es una defensa contra malware.

3. "Usar Musl, la librería de C"

Yo también prefiero el uso de Musl, y me gustaría si distribuciones lo adoptaran. Por ejemplo, una versión de Void linux, Alpine linux, y Gentoo usan Musl. Sin embargo, no todas los programas pueden ser compilados con Musl, y en términos de seguridad, Si uno ejecuta el malware, sin importar si usa Musl o GlibC, él puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web.

Si todos los programas que usan se pueden compilar con Musl, pueden intentar hacer experimentos con Musl; o sea compilar unos programas claves usando Musl. Pero tengan en cuenta que esto no protege a los programas de vulnerabilidades, ni protege contra malware. Solo disminuye la probabilidad de tener vulnerabilidades en la librería C del sistema.

4. "Usar LibreSSL en vez de OpenSSL"

Si mal no recuerdo, Void Linux intentó usar LibreSSL, pero tuvieron que regresar a OpenSSL. No sé si LibreSSL está bien mantenido.

Madaidan recomienda usar Gentoo Linux porque se puede configurar completamente. A mí también me gusta Gentoo, y me gusta que se puede configurar. En términos de seguridad, uno puede configurar Gentoo de una manera mínima, pero... Si uno ejecuta el malware, sin importar si usa Gentoo o Debian o Void o Ubuntu etc, él puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web.

2. Kernel

Es cierto que si encuentran y arreglan bugs/vulnerabilidades, pueden no pasarse a los kernels LTS antiguos. Sin embargo, también hay equipos de seguridad que intentan arreglarlas en los kernel LTS. Lo mejor es usar el kernel disponible en las versiones modernas / actualizadas de distribuciones grandes como Debian/Ubuntu/RHEL. Escoger la versión estable o experimental (como en debian stable/testing) depende más de sus propios gustos, y no de la seguridad. Si prefieren tener los paquetes más actualizados y nuevos, con un riesgo (pequeño) de encontrar bugs, usen la rama testing. Si prefieren la estabilidad, usen la rama estable.

Más importante es asegurarse de que tengan actualizaciones automáticas prendidas, y reinicien la máquina muy a menudo, especialmente cuando haya una actualización del kernel.

Aquí menciona muchas opciones del kernel que pueden activar / desactivar por varias razones.

En principio, estoy de acuerdo con sus recomendaciones. Específicamente, recomiendo usar el kernel de whonix que contiene varias mejoras de seguridad. Sin embargo... Si uno ejecuta el malware, sin importar cuántos módulos del kernel desactivan, él puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web. Esto no requiere ninguna vulnerabilidad en el kernel. (Hay muy pocas razones por las que un malware tenga que encontrar una vulnerabilidad en el kernel. Por ejemplo, si el malware fue ejecutado como un usuario, y quiere acceder a los archivos de otro usuario (en un sistema que tenga muchos usuarios). O, si tienen un servidor de web, es común que corra bajo otro usuario como www-data...)

Si tienen tiempo libre, y quieren experimentar un poco, les recomiendo que compilen su propio kernel. Pueden escoger y activar sólo los módulos que de verdad usan/necesitan, y puede que la máquina se inicie más rápido (ya que el kernel es más pequeño). Tengan en cuenta que un malware puede causar mucho daño sin atacar el kernel.

3. Control de acceso / Mandatory Access Control

Estoy de acuerdo con Madaidan. Es bueno usar un MAC como AppArmor o SELinux. Sin embargo, no hay necesidad de escoger el sistema. Distribuciones como Debian/Ubuntu etc usan AppArmor, mientras que RHEL/Fedora/Centos usan SELinux. Los MACs son unos sistemas de defensa que pueden prevenir que un programa actúe muy fuera de la norma. Por ejemplo, puede prevenir que un navegador web acceda a archivos o tenga funcionalidad extra, basado en un una configuración hecha antemano.

Sin embargo,

• Para ser efectivos, los programas deben tener una configuración muy restringida de AppArmor/SELinux hecha antemano.

• No protege si ejecutas un programa/malware, que no tenga una configuración de AppArmor/SELinux!. Si ejecutas un malware, no le va a proteger. Sin embargo, hay un intento para tener configuraciones por defecto para todos los programas.. Este proyecto es muy interesante, y espero quelas distribuciones lo adopten. Pero, puede fallar en el siguiente punto.
• Aunque haya una configuración muy restringida, eso no asegura que el malware no sea efectivo. Por ejemplo, si uno usa el navegador web para enviar / descargar documentos, fotos etc, significa que el navegador web debería poder acceder esos directorios. Eso significa que si el malware corre desde el navegador web, también puede cifrar todo en esos directorios. El navegador web también guarda y accede los cookies de sitios web. Eso significa que el malware puede robar los cookies, y así meterse en las cuentas del web que usan.

Los MACs son un sistema de defensa muy básico e inflexible. Aunque pueden proteger en ciertos casos, no pueden distinguir entre acciones normales y acciones maliciosas al menos que vayan muy fuera de lo normal. Para poder efectivamente distinguir entre acciones normales y acciones maliciosas, se usa un Antivirus, con detección de comportamiento

4. Sandboxing

Estoy de acuerdo con Madaidan sobre lo que cuenta de Sandboxing. Si usan un sistema de sandboxing, eso limita lo que puede hacer un malware. Sin embargo, tiene el mismo problema que los sistemas de MAC. Digamos que crean un sandbox para su navegador web. Ustedes descargan archivos, por lo que le dan acceso a la carpeta ~/Descargas, ~/Fotos y ~/Videos Ustedes mandan correos electrónicos, o necesitan subir unos documentos por motivos de trabajo, por lo que le dan acceso a la carpeta ~/Documentos. El navegador web guarda sus cookies en el folder ~/.local/navegador. Si debido a una vulnerabilidad, el malware se llega a apoderar del navegador web, puede:

• cifrar todos los Documentos, Fotos, Videso y Descargas
• robar los cookies, y apoderarse de sus cuentas en el internet.

Sin embargo, si usan unos sandbox de una manera sabia, sí pueden mitigar algunos riesgos. Por ejemplo, pueden darle acceso a solamente una carpeta específica, y así no puede causar daños en otras partes. Una manera fácil de configurar los permisos de bubblewrap y crear un sandbox, es usando flatpak y flatseal. Usando flatseal, pueden configurar y limitar las acciones de flatpaks. Es una capa adicional de protección que pueden usar.

Estoy 100% de acuerdo. Consideren usar máquinas virtuales. Las máquinas virtuales son la mejor forma de separar procesos, y son muy difícil de escapar. Tanto que pueden correr muchos malware dentro de una sin tener miedo. Por eso me fascina QubesOS, que usa máquinas virtuales para separar los programas. Usar QubesOS es la mejor forma de protejerse.

5. Hardened Memory Allocator

A mí me gusta mucho el asignador de memoria de GrapheneOS, y espero que lo puedan incluir en más distribuciones. Sin embargo...

Si uno ejecuta el malware, sin importar qué Alocador de Memoria usen, él puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web.

Tengan en cuenta que usar este 'Hardened Memory Allocator' puede causar problemas con AppArmor (que no le permite usar ld.preload).

6. Controles de compilación

Si uno ejecuta el malware, sin importar qué controles de compilación usen, él puede acceder y cifrar / mandar todas sus fotos preciadas, documentos importantes, y cookies del navegador web.

7. Lenguajes de programación

Como escribí antes, Es verdad que lenguajes de programación que son 'seguros de memoria' pueden ser más seguros para el sistema operacional ya que es menos probable que hayan bugs relacionados con over/underflows de memoria. Sin embargo, eso no es todo el cuento. Pueden existir vulnerabilidades en cualquier programa, irrespectivo al lenguaje de programación. Hasta han habido vulnerabilidades en sudo-rs, escrito en su preferido Rust.

Estoy de acuerdo, por que pueden haber menos vulnerabilidades.

8. Eliminar root

El root es todo-poderoso, por lo cual hay que tener cuidado cuando lo usan.

Hay muchas razones por las que uno necesita privilegios root. Si necesitan usar un chroot desde un USB cada vez que quieren instalar paquetes o usar root, es supremamente inconveniente, por ganas algo minúsculo de seguridad.

9. Usar un contrafuego

Estoy 100% de acuerdo con Madaidan. Pueden usar UFW, que es un contrafuegos fácil. Si están usando la máquina como una computadora personal, eso es suficiente, porque simplemente bloquea las conecciones entrantes. Si tienen un servidor, entonces les recomiendo que investiguen a Crowdsec. Específicamente, les recomiendo colocar/configurar un WAF (Web Application Firewall), como el de crowdsec (appsec). La razón es que si tienen un servidor, debe poder recibir conecciones entrantes (como de http), por lo que el puerto tiene que estar abierto. Pero, deseamos destinguir si las conecciones son legítimas o si intentan atacar el servidor. Un WAF puede analizar las conecciones y decidir si las bloquea o las deja pasar. Un WAF también puede proteger contra vulnerabilidades.

10. Identificadores

Es una manera muy difícil y muy rara para identificar a alguien.

No se preocupen mucho sobre eso, ya que hay otras maneras.

Sí, esto definitivamente es una manera en la que pueden intentar identificar a personas. Pero no son los únicos factores. El navegador web tiene muchas características que comparte con sitios web, y que puede ser usado para identificar al usuario. Estas características incluyen las que Madaidan menciona, pero también incluyen la resolución de la pantalla, la versión del navegador web / webGL, el modelo de CPU y GPU, y muchas otras características. Por lo tanto, no es suficiente simplemente cambiar la zona horaria. Mejor, usen un navegador web que no comparte esta información, como el navegador TOR, Librewolf, Brave u otro.

Es posible, si un atacante controla la red wifi, puede identificar que alguna máquina con un MAC específico se conecta / se desconecta.

Recomiendo usar macchanger.

En teoría, es posible. Afortunadamente Whonix usa sdwdate para calcular el tiempo. Chrony con NTS trambién se puede usar para asegurarse que el tiempo es correcto (y proteger contra certificados revocados / expirados). Pero no soluciona el problema de identificar a un usuario basado en las diferencias de su reloj. Para eso es mejor usar sdwdate.

Es posible identificar usuarios basado en cómo escriben; o sea las pausas entre las claves, etc. Esto puede ocurrir si teclean una frase en un sitio web que guarda esta información. Por eso estoy de acuerdo con Madaidan, y recomiendo que instalen y usen kloak. Kloak crea unas pausas aleatoreas en cuanto escriben para que sea más difícil rastrear a un usuario/escritor. Otro método es aún más fácil: simplemente escribir en otro programa, como kate/libreoffice, y luego copiar y pegar el texto que escribieron en un sitio web que sospechan que puede no ser seguro.

Sin embargo, aunque usen kloak, o copien y peguen el texto, hay otro ataque/posibilidad que Madaidan no menciona: Es posible rastrear a un usuario basado en sus hábitos, lo que escriben, y cómo lo escriben. Por ejemplo, digamos que un usuario le gusta usar una frase o construcción gramática. Y digamos que ese usuario típicamente está presente/ausente en tales horas. Si alguien recompila suficiente información, es posible rastrear a un usuario.

Aunque parezca que sea muy difícil usar esta información, nosotros sabemos que esto sí ocurre en la vida real. Es una manera por la que pueden identificar / adivinar de qué país lanzaron un cíber-ataque. Por ejemplo, si los desarolladores de un malware escribieron unos errores ortográficos específicos, es probable de que hablen uno u otro idioma. Como otro ejemplo, supuestamente el hacker que logró introducir una puerta trasera en XZ utils usó un nombre que parecía chino, pero al investigar un poco más, resulta que ese nombre consiste de dos apellidos. O sea, parece poco probable que un chino escoja ese nombre. Es como si alguien escogiera "John Harry" en vez de "John Smith". Y luego averiguaron que aunque su zona de horario sea de ~california, ese individuo estaba en línea en tiempos muy raros para california (ej por la noche). En vez, su horario laboral coincidía con una región como la de Israel.

11. Permisiones de archivos

Esto puede ser útil si comparten una máquina con otros usuarios.

Pero no le van a proteger si corren un malware con su usuario.

12. Core Dumps

Estoy de acuerdo.

13. Swap

Estoy de acuerdo con Madaidan.

Esto es un riesgo real, por lo que recomiendo asegurarse de que desactiven el swap, o que se aseguren que la partición dónde vive el Swap esté cifrada.

14. PAM

Aquí es importante tener una clave buena y larga. Si un hacker tiene acceso físico a su computadora, pueden completamente evadir el PAM si hacen boot de un USB.

15. Actualizaciones del Microcódigo

Estoy completamente de acuerdo con Madaidan. Es muy importante tener el sistema actualizado, incluyendo el microcódigo.

16. IPv6 privacy extensions

Estoy de acuerdo.

También se puede simplemente desactivar IPv6 por cuestiones de privacidad.

17. Opciones de Montar las Particiones

Aquí me gusta que se puede colocar noexec en el directorio /home. Pienso que puede proteger a un usuario si por accidente descarga un malware, e intenta ejecutarlo desde el directorio ~/Descargas (en /home). Sin embargo, no estoy seguro si protege a un programa que no sea binario. Por ejemplo, puede que no puedas ejecutar un script como ./script, pero sí lo puedes ejecutar con bash ./script.sh o python ./script.py, ya que en ese caso, técnicamente ejecuta a bash/python, y le pide que lea el script...

18. Entropía

Creo que antes esto era un problema, ya que Linux usaba entropía del procesador (y esa entropía puede no ser aleatoria). Pero creo que ahora también usa otras fuentes, como la actividad del disco etc. Pero en teoría no veo ninún problema con instalar fuentes adicionales.

19. Editar archivos como root

El mayor riesgo de editar archivos como root es del propio usuario, no de un malware. Además, un malware puede simplemente remplazar a sudoedit con una versión vulnerable/mala (por ejemplo modificando el $PATH en .bashrc).

20. Distribution specific hardening

Estoy de acuerdo. Asegurense de que los repositorios APT usen https.

Puede que sea mejor activar esa opción.

Sin embargo, si están instalando un paquete malicioso, seccomp-bpf es la última de sus preocupaciones. Un paquete puede causar muchos más daño sin necesidad de usar seccomp-bpf. Por ejemplo, el paquete puede remplazar un programa que usan como cron o un agente de correo electrónico, y la próxima vez que reinicien la computadora (o el servicio), la versión nueva (y maliciosa) se va a ejecutar (posiblemente con privilegios root!).

21. Seguridad física

Estoy completamente de acuerdo con Madaidan. Todo, sin excepcion, deben cifrar sus discos, porque sino, cualquier persona que tenga 5 min con su computadora, puede completamente evadir cada método de seguridad al arrancar desde un USB y montar el disco.

Básicamente, el problema es que la computadora necesita arrancar algo, o sea, necesita tener al menos 1 programa que no esté cifrado, y luego ese programa puede pedir la contraseña del disco y dejar entrar al resto del sistema.

Ahora, si un hacker simplemente se roba la computadora, no van a poder entrar, ya que el disco mismo está cifrado. Lo único que puede encontrar es grub y el kernel. Pero, el problem as: qué pasa si el hacker primero modifica esa parte que no está cifrada? Por ejemplo, coloca su versión de LUKS que guarda la contraseña en /boot/efi? Si uno no se da cuenta, entra a su computadora como siempre, entrando la contraseña. Pero si luego el hacker se roba la computadora, va a encontrar la contraseña en /boot/efi, y puede entrar al sistema.

Esto se llama un ataque 'Evil Maid'.

Verified boot sigue con varios problemas. Secure Boot es muy vulnerable porque cada empresa tiene su propia versión, y con el código cerrado. Mejor, pongan las particiones de /boot y /boot/efi en un USB, y guarden ese USB muy bien (por ejemplo, lo llevan colgado como un collar). Necesitan usar ese USB a menudo (para arrancar la computadora), por lo que no lo pueden simplemente esconder. De esta manera, el hacker no puede acceder a /boot/efi sin que uno se de cuenta. Y si se da cuenta, puede elejir no entrar la contraseña.

El ataque 'Evil Maid' tiene otra posibilidad: Remplazar la computadora con una que se ve igualita a la suya. Y cuando entre la contraseña, la manda al hacker. Una sugerencia para combatir este ataque es encontrar y memorizar un rasguño o rayaduras de su computadora. El hacker puede no saber/pensar sobre ellas, y darle una computadora sin esos rasguños, pensando que es algo común, y que nadie lo notará. Y es difícil copiarlas a otra computadora (pienso yo). Así pueden identificar una computadora falsa.

BIOS / UEFI hardening

Estoy completamente de acuerdo.

Bootloader passwords

De acuerdo. Pero mejor simplemente colocar las particiones /boot y /boot/efi en un USB.

Contraseña de Grub

Si colocan las particiones /boot y /boot/efi en un USB, no es necesario.

Verified Boot

En general, Linux necesita más trabajo para crear un sistema de Verified Boot. Lo que existe ahora no es lo suficiente seguro.

BadUSB

Esto es definitivamente un riesgo. Existen dispositivos que actúan como un teclado (pre-programado con unas acciones como de un malware), pero que se disfrazan como un USB. Uno puede conectar ese dispositivo, pensando que es un USB, pero al conectarlo, en menos de un segundo, logra a correr un malware. Es un ataque real, que no tiene muchas defensas. Recomiendo usar USBGuard y un antivirus, que puede que encuentre el malware. La única defensa razonable que he encontrado es Lockdown Mode en MacOS. Espero que Linux tenga algo similar en el futuro.

Direct Memory Access

Teoréticamente es posible interceptar las comunicaciones entre los chips de la computadora para extraer secretos. Recomiendo activar los grupos IOMMU. Sin embargo, hay formas mucho más fáciles para hackear.

Cold Boot Attacks

Teoréticamente es posible enfriar el RAM para tratar de extraer secretos. Sin embargo, hay formas mucho más fáciles para hackear. Y si alguien está tan desesperado para entrar a su computadora, y tiene los recursos y conocimiento para este tipo de ataques (como los servicios de inteligencia), entonces ya perdieron. En vez de atacar a la computadora, van a atacarlos a ustedes directamente, y en poco tiempo ustedes mismos le van a contar la contraseña.

Conclusión

Madaidan se enfoca en ataques teoréticamente possibles, pero no plausibles, y desafortunadamente pierde vista de lo que realmente es importante. Cuando uno se mete tan profundo a investigar tipos de ataques, siempre hay que permanecer con el sentido común, y preguntarse: Hay un camino más fácil por la que un hacker va a tomar?

Mis pensamientos sobre la seguridad en Linux: Lo mejor es pensar en términos de recursos/tiempo/conocimiento necesario para entrar y hackear un sistema. Dado suficientes recursos/tiempo/conocimiento (como las que poseen las agencias nacionales), ningún sistema es invulnerable. Pero, si uno hace que un atacante gaste más recursos que potencialmente gane, eso es una victoria.

Uno puede, de una manera (relativamente) fácil, asegurar un sistema lo suficiente para que sea difícil hackear la computadora. La clave es:

1. Cifrar todo el disco entero, (y colocar las particiones /boot y /boot/efi en un lugar seguro, como un USB).
2. Usar el model de separar sus acciones en la computadora. La manera más segura es usar máquinas virtuales, tal y como lo hace QubesOS.
3. Utilizar un antivirus bueno, en zonas de riesgo (ej en cubos de qubes-os conectados al internet)
4. Actualizar el sistema de forma automática.
5. Simplemente tener cuidado, y pensar 5 segundos antes de ejecutar cualquier programa, o instalar algo nuevo. Y tratar de solo usar los repositorios oficiales (de Debian/Ubuntu/Fedora etc).