Creación de una máquina Ubuntu con hardening “intenso” aplicado de forma automatizada

¡Hola!

¡Bienvenidos a esta entrada del blog de AsturHackers! Mi nombre es José Manuel Redondo y soy profesor de la Escuela de Ingeniería Informática de la Universidad de Oviedo. Hoy voy a hablaros de cómo se puede conseguir una máquina Ubuntu que tenga un nivel de seguridad muy superior al que se tiene recién instalada… ¡pero de manera completamente automatizada!

Antes de empezar, deciros que todo el código involucrado en la creación de esta máquina (y algunas más) los tenéis disponibles públicamente en mi repositorio de GitHub: https://github.com/jose-r-lopez/SSI_Materials. ¡Así podéis comprobar y editar todo esto como os apetezca!

¿Y qué significa esto? que vamos a conseguir una máquina que, partiendo de un índice de seguridad medio (es decir unos 56/100 puntos, mira la primera imagen), se va a someter a una serie de procesos de hardening que la van a llevar a los 94/100 puntos. Pero todo ello lo vamos a conseguir de una manera automatizada, es decir, que para el usuario va a ser un “lanza la máquina y olvídate”, aunque luego podrá hacerle cambios para adaptarla a su gusto.

Imagen 1. Índice de seguridad *Lynis* de la máquina recién instalada

Espera, espera… ¿puntos? ¿operaciones? ¿qué?

Antes hablé de puntos, y es normal que suene muy extraño que algo tan complejo como la seguridad de una máquina se mida en “puntos”, como los del carnet 😊. Esto realmente no es así, porque efectivamente la seguridad es muy compleja y dependiente del contexto (dónde está la máquina, qué servicios tiene, qué necesidades se supone que debe cubrir…), pero lo cierto es que hay determinadas cosas que deberían estar presentes en todos o casi todos esos contextos, y hay herramientas que te dicen automáticamente si las tienes o no. Una de ellas es Lynis, de Cisofy (https://cisofy.com/lynis/). Es gratuita, muy sencilla de usar y no solo te da una puntuación, sino que te dice lo que tienes que hacer para mejorarla, es decir, te da pistas de las operaciones que tienes que hacer (mira la imagen 2).

Imagen 2. Consejos de *Lynis* para securizar el sistema

Es decir, que la herramienta te dice las operaciones que tienes que hacer. Pero no es la única que lo hace, y ni siquiera es la única guía que te dice cómo hacerlo. No voy a entrar en qué guía es mejor de todas, pero lo importante es seguir una que sea internacional, validada, mantenida y probada por cuantas más empresas o usuarios mejor. En este caso la herramienta de Cisofy va a ser la guía de operaciones primaria, pero voy a usar otra de respaldo cuando la primera no deje claro lo que hay que hacer: Los CIS Benchmarks (https://www.cisecurity.org/cis-benchmarks/).

Vamos, que securizar una máquina consiste en ejecutar una lista de operaciones para hacerla más segura. A cada una de ellas se la llama control de seguridad. Lo difícil es saber cuáles, cuántos, y para qué se hacen, pero eso nos lo dan esas guías. Moraleja: no sigas un blog, un post o How to de por ahí: sigue estas guías, que para eso son fiables y están validadas 😊.

Además, las dos cosas que vamos a usar tienen versión gratuita. En el caso de los CIS Benchmark, previo registro (gratuito), te puedes descargar en PDF la guía de controles de seguridad para diferentes productos comunes. Ya no solo me refiero a sistemas operativos como Windows 10, Windows Server, Linux de diferentes clases (CentOS, Fedora, Ubuntu, Debian, Red Hat Enterprise Linux…) sino que también hay software (Firefox, Nginx…) la suite de Office, etc… ¡hay más de 100 guías que podéis seguir de cara a estar seguros de que vuestros productos están bien securizados!

Vale, pero ¡quiero saber cómo has securizado la máquina ya!

Vale, vamos entonces a lo que nos ocupa 😊. Lo primero que debemos tener en cuenta es que una máquina que queramos securizar tiene que partir de la base de software más pequeña posible. ¿Qué quiere decir eso? ¡que tenemos que procurar instalar la menor cantidad de software que podamos! A menor software menos probabilidad de vulnerabilidades y menos complejo el mantenimiento. Es decir, menos actualizaciones y productos que tenemos que vigilar y preocuparnos por si les apareciese alguna vulnerabilidad. Por tanto, lo primero es minimizar la cantidad de software que instalamos convirtiendo la máquina de base en lo que llaman un Ubuntu Server minimizado.

¡Pero me estás hablando de máquinas e instalarles cosas!, ¡y me prometiste automatización! Sí, sí, lo sé. Es que la “minimización” también va a ser automática. ¿Qué queremos? Automatización. ¿Cuándo la queremos? Ahora 😊. Para ello vamos a usar uno de los sistemas de automatización para crear máquinas virtuales (con el software que queramos dentro) más famoso mundialmente (¡y gratuito!): Vagrant (https://www.vagrantup.com/).

Vagrant es una forma de conseguir Infrastructure as Code o, dicho de otra forma, tú le pasas un programa, él lo procesa y, como resultado, sale una máquina virtual como si la hubieras hecho tú manualmente. No es el único ni el más adecuado para todos los escenarios (este se usa para construir entornos de desarrollo o infraestructuras relativamente pequeñas de VMs), pero para nuestro post nos viene de perlas. Resulta que, si usas Vagrant no partes de cero, sino que su propio fabricante tiene una nube pública llamada la Vagrant Cloud (imagen 3), donde uno se puede descargar modelos de máquinas “prefabricados” que puede personalizar, ampliar y modificar a placer. Estos “modelos de máquinas” se llaman Vagrant Boxes.

¿No lo entiendes? En ese sentido es como el Google Play Store, es decir, hay máquinas creadas por fabricantes oficiales, como son Debian, Ubuntu y HashiCorp (¡el fabricante de Vagrant!), etc. Y salvo catástrofe (¡esos malditos supply-chain attacks son siempre una amenaza latente) te puedes fiar de que no lleven “bicho” dentro. Pero a esta nube puede subir boxes cualquiera, y de estas nos podemos fiar…o no. Cómo vamos a hacer una máquina segura, vamos a partir de una máquina oficial, en este caso una Ubuntu 18.04 proporcionada por HashiCorp. Gracias a Vagrant y a como se creó esta box inicial, podemos hacer esto en VirtualBox, en Hyper-V o en VMWare Desktop, ya que la box inicial es compatible con estos 3 sistemas de virtualización. ¡Esta mayor independencia del sistema de virtualización es una de las grandes ventajas que nos da Vagrant!. Eso sí, la box inicial que usemos debe estar preparada para ello (¡y hay unas cuantas que soportan un nº de hipervisores que os sorprenderá!). En el caso que nos ocupa, ésta la use para mi asignatura y ningún alumno tuvo problemas, ni con su hipervisor ni con su sistema operativo de base. ¡La asignatura era Windows, Linux y MacOS-friendly! 😊.

Cómo vamos a hacer una máquina mínima, sus requisitos no van a ser muy grandes: 2Gb de RAM, dos cores, 80 gigas de disco duro (que, sinceramente he sido bastante generoso, probablemente con 20 podemos tirar, pero como el disco es dinámico da un poco igual 😊). Cómo no vamos a tener GUI (¡porque evidentemente queremos minimizar el software instalado!), vamos a asignar solo un buffer de 32 megas de RAM de vídeo. No tenemos aceleración de vídeo en 3D, ni audio. Toda esta información hay que meterla en un fichero de texto llamado Vagrantfile en el formato que admite Vagrant. Hecho esto, se puede instalar el software que queramos meter en la máquina virtual con uno o varios provisioners (software que instala programas con la máquina arrancada). La imagen 4 muestra tanto una Vagrantfile como la llamada a sus provisioners.

Provisioners puede haber muchos: Puppet, Ansible, Chef…pero os adelanto que el resto de software que vamos a instalar se van a hacer con scripts de bash normales y corrientes (¡eso también puede ser un provisioner!). Gracias a eso podéis poner el trabajo de los provisioners en funcionamiento en cualquier máquina que tengáis por ahí muy fácilmente sin necesidad de instalar nada más. También ayuda el hecho de que he refactorizado todo el código de los scripts de manera que cada uno haga solo una función muy concreta y sea muy sencillo localizarlos 😊.

Antes de empezar deciros que todo lo que os voy a contar está en mi repositorio de GitHub (https://github.com/jose-r-lopez/SSI_Materials), listo para descargar usar y probar. Por tanto, todo lo que os voy a escribir aquí lo podéis ver en funcionamiento y hacer los cambios que consideréis oportunos si hay algo que no os convence o queréis ver qué pasa. Además, incluyo unos scripts que automatizan todo el proceso de arrancado y construcción de máquinas, para que no tengáis que estudiar mucho más antes de “levantar” vuestra primera máquina con Vagrant. Esta entrada del blog va a servir para explicaros todo lo que está pasando por debajo en la máquina “Magic the Hardening” (https://github.com/jose-r-lopez/SSI_Materials/tree/main/Vagrantfiles/machines/debian/Hardened/magic_the_hardening) de mi repositorio de GitHub.

Fase 1: instalación

He dividido todo este proceso en dos fases. La primera es la instalación, donde no voy a hacer nada de hardening porque solo quiero tener una base de software sobre la que luego voy a trabajar. Como podéis ver en mi repo, la instalación no es más que la ejecución de una serie de scripts. Lo que hago es que cuando arranco la máquina copio todos los scripts y los ficheros que usan a una carpeta conocida de la máquina virtual (/home/vagrant) (esto está en la Vagrantfile) y como ya sé que están ahí, luego esos scripts van a funcionar presuponiendo esa ruta. Si queréis saber qué hacen estos scripts de instalación podéis entrar dentro de cada uno de ellos, pero os lo voy a resumir en la siguiente lista:

Minimiza el software instalado (aka “dieta de adelgazamiento” 😊): para eso instalo un meta-paquete llamado ubuntu_server y deja instalado otro software como es OpenSSH, systemd, netplan y algún otro, que son lo mínimo para que la máquina pueda arrancar. Todo lo demás se elimina, dejando la máquina con 200Mb menos de software. Existe un paquete aún más pequeño (ubuntu_server_minimal), pero por desgracia si lo instalamos la máquina no volverá a arrancar… hecho esto, también eliminamos otra serie de servicios del meta-paquete que tienen un uso minoritario en máquinas servidor. Script: minimize_software.sh
El siguiente paso es hacer una actualización completa de todo el software que queda instalado de la base anterior. Script: full_os_upgrade.sh
Luego instalamos una serie de software muy ligero para trabajar mejor en consola: un multiplexador de terminales (tmux), un navegador de ficheros en modo texto (mc, Midnight Commander), una configuración especial para el nano (números de línea y otras cosas que nos ayuden a editar ficheros), y utilidades típicas como curl, wget, etc. Ya sé que así el servidor no es mínimo realmente, pero un poco de comodidad no hace daño a nadie. Y si no te interesa, ¡quitarlo es comentar una línea! :). Script: basic_cmd_software_install.sh
El siguiente paso es poner esa configuración especial en la cuenta del único usuario que vamos a crear que para poder usar la máquina con Vagrant (usuario vagrant). Script: vagrant_user_setup.sh
Luego se cambia el teclado a español, porque por defecto la máquina viene con él en inglés. Script: change_keyboard_layout_es.sh
Ya terminando instalamos las VirtualBox Additions (o el paquete equivalente si usáramos otros sistemas de virtualización). Cabe decir que aquí solamente he podido probar VirtualBox y Hyper-V al no disponer de VMWare 🙁. Script: install_additions.sh
Instalamos después la última versión de Lynis, la herramienta que usaremos para medir el índice de seguridad de la máquina. Script: install_lynis.sh
Por último, nos deshacemos de una serie de ficheros que no vamos a usar en esta máquina minimizada: limpiar la caché de apt, los ficheros de los Locales y los manuales (man) de las aplicaciones instaladas. Este proceso lo haremos otra vez después de todo el hardening para eliminar los correspondientes al resto de software que instalaremos. Script: minimize_files.sh

Después de todo esto, la máquina tiene el siguiente índice de seguridad (imagen 5). Verás que es mayor que el anterior, y es que las actualizaciones tienen su importancia en el proceso de securización, ¡aunque aún estamos muy lejos del objetivo!

Imagen 5. Índice de seguridad *Lynis* de la máquina actualizada y minimizada

Fase 2: ¡Hardening!

En esta fase también vamos a lanzar una serie de scripts que tiene una función única, solo que en este caso cada vez que instalemos uno mejorará el índice de seguridad de nuestra máquina. Como antes, vamos a describirlos en forma de lista y, para cualquier duda, podéis mirar mi repositorio de GitHub, donde están todas las operaciones que hace cada script descritas al detalle. ¡Empezamos!:

Lo primero es instalar un software anti-malware (en este caso clamav) y anti-rootkit, un tipo de malware muy peligroso, (chrootkit). Con este software tendremos una determinada capacidad para detectar cualquier malware que puede aparecer en nuestro servidor. ¿Es importante tener este tipo de software en un servidor? Si. ¿Es la solución definitiva de seguridad? Pues como veis en la siguiente imagen, no… ¡hay mucho más por hacer!. Script: install_antimalware.sh

Imagen 6. Índice *Lynis* tras la instalación de anti-malware y anti-rootkit

El siguiente paso es instalar una serie de paquetes que está reconocido que ayudan a detectar posibles problemas a la hora de instalar nuevo software con apt. Detectan vulnerabilidades, evitan la instalación de paquetes corruptos, etc. Script: install_base_security_packages.sh
Posteriormente, instalamos el soporte para process accounting. Se trata del paquete acct, y podemos leer más acerca de su utilidad y usos aquí: https://linuxhint.com/enable-process-accounting-ubuntu/ . Script: install_process_accounting.sh
La siguiente operación es instalar un servicio para envío de emails llamado Postfix (https://ubuntu.com/server/docs/mail-postfix). ¿Por qué hacemos algo así cuando estamos intentando minimizar el software? Bueno, en este caso es porque varios de los productos que vamos a instalar posteriormente usan el mail para notificar incidencias a la dirección de correo que nosotros queramos. Por tanto, si no tenemos esto instalado esos programas quedarán “mudos” y no podremos enterarnos si detectan algún tipo de incidencia. No obstante, en esta máquina de prueba no se ha configurado ninguna cuenta externa de email que reciba dichos correos, que acabarán en el email privado del usuario root. Ni que decir tiene que en caso de que queramos hacer algo que esté en producción tendremos que reconfigurar Postfix. Script: install_postfix.sh
¡Y no nos olvidamos del log tampoco! Si bien una solución de producción debería enviar el log a una máquina externa, especializada en recibir y analizar los logs de otras máquinas, en esta ocasión jugamos con una sola, por lo que no lo vamos a hacer. Pero el análisis de log sigue siendo necesario, y por tanto instalaremos un programa que detecta determinados patrones de posibles ataques en el log local de la máquina: LogCheck. Nuevamente, insistir en que una instalación real debería usar Rsyslog o similar para enviar los logs fuera (https://help.clouding.io/hc/es/articles/360019217019-C%C3%B3mo-Configurar-Rsyslog-en-un-servidor-cloud-Ubuntu-20-04), y allí ya usar una solución que los analice para detectar muchos más patrones de ataque y problemas. Script: install_logcheck.sh
El siguiente paso instala el software sysstat para monitorizar la actividad y el rendimiento del sistema: https://www.linuxito.com/gnu-linux/nivel-medio/785-como-instalar-sysstat-y-visualizar-sus-datos-graficamente-a-traves-de-un-navegador . Script: install_sysstat.sh
Otra de las cosas que instalaremos tiene algo más que ver con la seguridad física. Todos hemos oído hablar de la existencia de dispositivos USB qué, bien por cómo están construidos o por el software que pueden tener, pueden causar un problema serio de seguridad a cualquier servidor. Para evitarlo, USBGuard solamente deja conectarse dispositivos USB que nosotros autoricemos expresamente, de manera que si alguien enchufa un dispositivo USB desconocido no podrá funcionar, y por tanto si lleva algún tipo de malware no podrá entrar en nuestro sistema: https://esgeeks.com/usbguard-proteger-puertos-usb-en-linux/ . Script: install_usbguard.sh
Otra herramienta de seguridad que vamos a incorporar es muy popular y se llama Fail2Ban. Fundamentalmente se usa para evitar intentos de ataque por fuerza bruta al servicio ssh. El funcionamiento es sencillo: si ocurren más de x peticiones erróneas en menos de un tiempo que nosotros definimos, la IP que lanza esas peticiones erróneas queda bloqueada, y no puede volver a acceder a nuestra máquina durante un tiempo determinado. Esa es la función más conocida, si bien Fail2Ban tiene además definidas una serie de reglas adicionales que se llaman jails, que también le permiten funcionar con servidores Apache o Nginx y detectar patrones de ataque. El efecto será nuevamente un bloqueo temporal de quien los desencadene. Script: install_fail2ban.sh
Y, hablando de protección ssh, en esta máquina hemos preparado una “trampa” con el siguiente programa que vamos a instalar: PortSentry. El servicio SSH de esta máquina no está escuchando en el puerto 22, como es habitual. Sin embargo, el puerto 22 sí que está abierto, pero detrás de él está PortSentry. Este es un programa que detecta determinados tipos de escaneo, por ejemplo los que se hacen con la popular herramienta nmap. En esta máquina está preparado para que si otra máquina lanza un escaneo, esta quede automáticamente bloqueada de forma permanente, impidiendo el acceso a nuestro servidor. ¿Qué significa eso? Que, la primera vez que se lance un escaneo, la máquina que escanea no va a obtener resultados útiles y además van a tardar mucho tiempo. La siguiente vez, la máquina que escanea lo que verá es NADA: es decir, que nuestro servidor no estará accesible para ella permanentemente. ¿Dónde está entonces el servicio ssh real? en el puerto 53245. ¿Y por qué ese puerto precisamente? En este caso he elegido un puerto muy alto porque la mayoría de los escaneos que ocurren a máquinas se limitan a un número muy restringido de puertos, y es más raro que alguien haga un escaneo a todo el rango de puertos posible de un servidor. Por tanto, se ha hecho así para evitar una parte de los posibles escaneos automatizados que hay en internet. Tras la instalación de todo este software de seguridad, vamos que el índice de seguridad ha subido sustancialmente, ¡aunque aún tenemos un buen margen de mejora!. Script: install_portsentry.sh

Imagen 7. Índice *Lynis* tras instalar una batería de software de seguridad

La siguiente fase de nuestro proceso de Hardening es bastante más complejo de explicar brevemente, pero lo voy a intentar: resulta que existe un protocolo que se ha creado para hacer esto mismo que estoy intentando yo (automatizar la seguridad), pero de forma estandarizada y soportada por varias herramientas (herramientas SCAP-compatible). El ejercito americano tiene una, los CIS Benchmarks tienen otra (de pago) y en este paso nosotros vamos a usar la gratuita (OpenSCAP, https://www.open-scap.org/). ¿Me estás diciendo que todo este proceso está ya disponible con una herramienta externa que siga este protocolo? Si, y no. Las herramientas necesitan ficheros en un formato tipo XML que especifica el protocolo SCAP. Por desgracia, los ficheros más completos y potentes (los que automatizan la mayor parte de cosas) son de pago. Los que tiene OpenSCAP funcionan, pero hacen menos cosas. Y algunas están todavía pendientes de hacer…y otras tienen errores. OpenSCAP es un proyecto comunitario en constante crecimiento y actualización, y lo que hemos hecho en este caso es descargarnos la herramienta OpenSCAP (línea de comandos), los últimos ficheros SCAP disponibles (https://github.com/ComplianceAsCode/content) y aplicar el correspondiente a Ubuntu 18.04 para que ejecute automáticamente todos los controles de seguridad que pueda. Vamos que la subida de puntos no ha sido muy grande, pero hay que tener en cuenta que ya hemos hecho muchas cosas, y varias ya las podría hacer hecho esta herramienta. Podemos verla como “una forma rápida de subir el hardening de una máquina sin hacer nada más que lanzar una herramienta” 😊. ¡Si, la seguridad también puede automatizarse con protocolos internacionales! :D. Script: install_oscap.sh

Imagen 8. Índice *Lynis* tras ejecutar *OpenSCAP*

Vemos como el índice de seguridad va escalando, y como podemos seguir aún “dándole caña”. El siguiente paso instala el daemon auditd, para hacer log de todo lo importante que ocurra en nuestro sistema. ¿y qué es lo importante? No tenemos que decidirlo nosotros: incorpora todas las reglas de auditoría de eventos que potencialmente pueden suponer un posible problema de seguridad que están recogidas en la guía de los CIS Benchmark. Es decir, no solo tenemos la capacidad de auditar todo lo que pasa en la máquina sino que, además, se van a recoger todos los que están reconocidos internacionalmente como de especial importancia a la hora de averiguar si ha pasado algo que pueda resultar peligroso. Obviamente toda esta información sería muy interesante mandársela una máquina externa, y que un sistema potente se encargue de analizarla, pero de momento al menos tenemos la información en alguna parte. Script: install_auditd.sh
Ahora vamos a meternos con algo de más bajo nivel, como es configurar una serie de parámetros del kernel del sistema operativo para evitar determinados tipos de ataque, y que de nuevo siguen las líneas establecidas por los CIS Benchmarks. De la misma forma, el script siguiente también cambia los permisos de determinadas partes del sistema de ficheros para seguir dichas guías, y lograr el nivel de seguridad recomendado. Script: install_kernel_hardening.sh
Cuando hablamos de que tenemos que minimizar el software instalado en el servidor no solo nos limitamos a programas, sino que también tenemos que desactivar todos los protocolos o servicios que no vamos a usar. Eso es lo que hace el siguiente script: desactivar dos protocolos de red que rara vez tienen uso en un entorno estándar. Script: disable_rare_network_protocols.sh
Otra de las cosas con las que debemos tener cuidado es no dejar la información sensible al alcance de posibles usuarios maliciosos. Por eso, el siguiente script deshabilita los core dumps, de manera que cuando un programa falle escriban al disco duro zonas de memoria donde puede haber datos sensibles. Pensad que esto es un servidor de producción y no uno de desarrollo, por tanto tener un core dump tiene menos importancia. Script: disable_core_dumps.sh

Imagen 9. *Lynis* tras el *hardening* de *kernel*, permisos y otras operaciones. ¡Ya estamos en verde!

El siguiente script instala una política de passwords que podría ser más rigurosa, pero en este caso sirve como ejemplo para para evitar que las passwords de los usuarios pueden ser extremadamente simples. Si este servidor lo queréis usar para algo en producción, yo recomiendo seguir una política de passwords más estricta (y nuevamente por ejemplo usar la que recomiendan los CIS Benchmark 😉). Scripts: ban_common_passwords.sh y install_password_policies.sh
Un nuevo paso en el proceso de securización del servidor es instalar las unattended upgrades, es decir, las actualizaciones automáticas. Esto sirve para que no se nos olvide actualizar el software, y no nos encontremos con que tenemos instalada una versión vulnerable después de bastante tiempo y por culpa de eso seamos víctimas de un zero day o de una vulnerabilidad conocida hace muy poco tiempo para la que existe solución. Script: enable_unattended_upgrades.sh
El siguiente script instala ARPWatch, que es un programa que vigila el protocolo de red ARP para evitar posibles ataques por ejemplo Man in the Middle: https://www.elmundoenbits.com/2014/08/arpwatch-arp-control-spoofing.html. Script: install_arpwatch.sh
Y seguimos con nuevo software de seguridad, en este caso Aide, que es un Host Intrusion Detection System (HIDS). Este programa crea una base de datos con los hashes de los ficheros de la máquina que él considera importantes. Si alguno de ellos se modifica de manera no autorizada, podremos saber que esa modificación ha ocurrido y actuar en consecuencia. Hay que destacar que una modificación de un fichero que él considera importante no tiene por qué ser un ataque: muchas veces esas modificaciones ocurren como consecuencia de actualizaciones. No obstante, no está de más tener esa información disponible, no vaya a ser que algún software haga una modificación extraña, este programa lo detecte, y gracias a eso tengamos una pista de que algo malo está pasando en nuestro servidor. Como se puede ver, esta nueva batería de software de seguridad incrementa nuestro índice otro poco más, estando ya cerca del objetivo final. Script: install_aide.sh

Imagen 10. *Lynis* tras la segunda batería de software de seguridad.

Ya estamos finalizando las medidas de seguridad, y en este caso vamos a hacer una que no está recogida en ninguna de las guías pero yo creo que es conveniente. Vamos a usar la lista de sitios maliciosos conocidos de Stephen Black (https://github.com/StevenBlack/hosts), que es un señor que tiene un repositorio en GitHub que actualiza muy frecuentemente con una serie de nombres e IP es de sitios que son conocidos por no tener nada bueno 😉. Estos sitios están divididos en varias categorías, y vamos a hacer que cualquier acceso que nuestra máquina haga alguna de esas IPs sea automáticamente prohibido. De esta forma, corremos el riesgo de acceder a un sitio malicioso sea cual sea el programa que estemos usando. Para esto se usa el fichero hosts del sistema operativo, que es un fichero donde se hace un mapeo de las IPS a nombres DNS pero local y que siempre se consulta antes de ir al DNS como se hace habitualmente. Con esto tenemos un filtro de sitios maliciosos aplicable a cualquier programa que nos puede librar de más de un disgusto. Script: enable_malicious_hosts_block.sh
¡Y ya casi acabamos!, solamente nos queda cambiar las opciones de montaje por defecto de determinadas carpetas conocidas para seguir las guías CIS (esto lo hacemos con un script de inicialización del servicio rc.local, script: change_default_mount_options.sh), activamos el soporte de DNSSEC (Script: enable_dnssec.sh), activamos también una password para el gestor de arranque GRUB, (https://www.techrepublic.com/article/how-to-password-protect-the-grub-boot-loader-in-ubuntu/) de manera que nadie que no conozca esa password puede arrancar el sistema operativo en un modo que le permita sacar información y saltarnos el resto de las medidas de seguridad (Script: add_grub_password.sh), y por último también hemos preinstalado el soporte para tener múltiple factor de autentificación (MFA) en el acceso a ssh usando Google Authenticator: https://derechodelared.com/segundo-factor-de-autenticacion-ssh/ (Script: preinstall_ssh_mfa.sh). Con todo esto, y arreglando una serie de sugerencias rápidas menores de Lynis (Scripts: enable_ssh_ufw.sh y install_hardened_system_files.sh), conseguimos el índice ansiado final: 94/100 puntos, es decir, ¡38 puntos más que la máquina inicial!

¡Y ya hemos terminado! hecho esto, el script de securización limpia los paquetes que hayan podido quedar sin borrar de las instalaciones anteriores, vuelve a borrar los ficheros que no vamos a usar para minimizar el espacio consumido, y reinicia la máquina. La máquina se va a reiniciar dos veces si usáis el sistema automatizado del repositorio de GitHub del que os hablé. La primera es cuando el instala todo, y la segunda es cuando termina de hacer todo el proceso de hardening. ¿por qué es necesario hacer dos reinicios? La razón es que en la primera fase cuando se instala todo el software actualizado es muy probable que cambiemos la versión del kernel. Es necesario reiniciar la máquina para que la nueva versión entre en funcionamiento, y que el resto de software que instalamos en una segunda fase pueda funcionar adecuadamente.

Y después de todo esto que tenemos una máquina que saca 94 puntos sobre 100 en el índice Lynis, lo cual está muy bien. No tiene en sí ningún servicio más allá del SSH, pero podemos instalar cualquier cosa que necesitemos sobre esta base segura, y que desde luego es mucho más resistente a diferentes tipos de ataque que la original. Además, tenemos la ventaja de que todo esto se hace de manera automatizada, y simplemente tenemos que esperar a que la máquina termine de instalarse para tener todo el sistema operativo con un nivel de securización muy alto.

¡Y nada más! espero que esto os haya sido de interés. Si queréis saber más, podéis consultar los scripts que os digo, que además están completamente comentados. Espero que gracias a esto podáis securizar cualquier máquina Ubuntu que tengáis por ahí, y si no tanto como esta, podéis coger una parte de lo que se ha hecho y adaptarlo a vuestro propio escenario. Cabe decir que en el futuro quiero hacer algo similar con una máquina de tipo Red Hat porque estoy convencido que todas estas operaciones tienen una traducción más o menos directa.

¡Y gracias por todo! ¡hasta la próxima!