Fortalecer un servidor Linux significa fortificar y asegurar dicho servidor para protegerlo de vulnerabilidades y amenazas. Aunque la seguridad total siempre será un objetivo en movimiento en la carrera armamentística de la seguridad, este artículo explora algunas medidas fundamentales importantes que puedes tomar para ayudar a mantener tus servidores seguros y protegidos.
Ningún riesgo de seguridad es lo suficientemente pequeño como para ignorarlo
Por desgracia, incluso las vulnerabilidades más pequeñas pueden transformarse en graves amenazas para la seguridad. Es importante recordar que cualquier código que se ejecute en tu sistema podría contener fallos que permitan a intrusos acceder a un shell de comandos o a usuarios legítimos sin privilegios elevar su acceso a derechos de superusuario. Por muy bajo que sea el nivel de riesgo, siempre es mejor abordar los riesgos de seguridad menores antes de que se conviertan en amenazas de ciberseguridad mayores. Al reforzar el servidor Linux, los equipos de TI pueden fortalecer sus defensas antes de que se produzca una amenaza grave, lo que ayudará a evitar que aparezcan problemas importantes desde un principio.
Actualizaciones del sistema y parches de seguridad
Actualizar periódicamente tu servidor Linux es esencial para mantener su seguridad y su salud general, sobre todo teniendo en cuenta que el 57% de los ataques externos proceden de sistemas sin parches. El software y los sistemas operativos se mejoran y perfeccionan constantemente para subsanar vulnerabilidades y puntos débiles. Si aplicas las actualizaciones con prontitud, te estás asegurando de que los fallos de seguridad conocidos están parcheados, lo que reduce el riesgo de explotación por parte de las ciberamenazas. Además, las actualizaciones suelen incluir correcciones de errores y mejoras de rendimiento, lo que se traduce en un entorno de servidor más estable y eficaz. No actualizar regularmente puede dejar el sistema expuesto a posibles ataques y comprometer su integridad.
Utilizar software obsoleto y dejar vulnerabilidades sin parchear supone riesgos significativos para tus servidores Linux. Los ciberdelincuentes atacan activamente vulnerabilidades conocidas para obtener acceso no autorizado, comprometer datos o interrumpir servicios. Cuando las vulnerabilidades se hacen públicas, los agentes maliciosos pueden aprovecharlas para poner en peligro los sistemas que no han recibido actualizaciones. Retrasar las actualizaciones aumenta la ventana de oportunidad para que los atacantes aprovechen los puntos débiles de las defensas de tus servidores, por lo que las actualizaciones periódicas son una medida de defensa fundamental.
Elegir las estrategias de parcheo adecuadas y buenas prácticas para la gestión de parches de tu servidor es crucial para mantener un servidor Linux seguro. Por lo general, todas las distribuciones actuales de Linux para empresas disponen de algún tipo de servicio automatizado de gestión de parches, ya sea mediante un servicio de suscripción de pago o gracias a los esfuerzos de la comunidad. Los servicios de pago a menudo van más allá de simplemente parchear los archivos del sistema para protegerlos; algunos de estos servicios también incluyen una solución para parchear en vivo el núcleo en ejecución, lo que permite que los sistemas en ejecución permanezcan parcheados incluso antes de tener que reiniciarlos.
Introducción a los gestores de paquetes
Los gestores de paquetes varían de una distribución a otra, pero tienden a utilizar dos formatos principales: DEB y RPM. DEB se utiliza en sistemas basados en Debian y se gestiona mediante apt; RPM (Redhat Package Manager), por su parte, se gestiona mediante dnf o yum para sistemas basados en Red Hat/Enterprise Linux o zypper para SUSE. Todos los gestores de paquetes facilitan la instalación, actualización y eliminación de paquetes de software, además de resolver dependencias. Utiliza gestores de paquetes para gestionar eficazmente el software y agilizar el proceso de actualización. Los principales gestores de paquetes también son compatibles con repositorios remotos, lo que permite centralizar el control de las actualizaciones y los despliegues de software.
Configurar actualizaciones automáticas para parches de seguridad críticos
Configurar tu servidor Linux para que instale automáticamente los parches de seguridad críticos garantiza que las actualizaciones de alta prioridad se apliquen rápidamente sin intervención manual, minimizando la ventana de vulnerabilidad y reduciendo la carga de los administradores. Las distribuciones para empresas suelen permitir configurar esta opción durante la instalación. Échale un vistazo a los paquetes de configuración si deseas configurarlo en tu sistema actual:
Ubuntu: sudo apt install unattended-upgrades
Red Hat/CentOS: sudo yum install dnf-automatic
SUSE: sudo zypper install yast2-online-update-configuration-> abre YaST, selecciona Software -> Online Update Configuration, y configúralo según tus preferencias.
Ahora bien, ten cuidado al activar las actualizaciones automáticas, ya que pueden afectar a la estabilidad del sistema o requerir pruebas de compatibilidad. Las pruebas son especialmente importantes cuando se utilizan herramientas de administración remota masiva como ansible o puppet para realizar actualizaciones de servidores en un entorno informático heterogéneo.
Configurar la elevación sudo y el acceso shell
Configurar correctamente las cuentas de usuario y los permisos es esencial para tener un sistema seguro que siga permitiendo el acceso adecuado. Los permiso que no han sido configurados correctamente pueden crear algunos problemas, por lo que es mejor asegurarse de que están configurados correctamente desde el principio.
Usar el comando sudo en todo su potencial con la configuración correcta de/etc/sudoers te permite limitar y permitir los derechos de acceso root sin contraseña en función de cada aplicación. Utiliza siempre el comando visudo para editar /etc/sudoers, ya que esto mantiene los permisos correctos en ese archivo crítico:
sudo visudo
Haz cambios similares a estos, reemplazando ninja con tu nombre de usuario y ajustando la lista separada por comas de comandos permitidos para adaptarlos a tu caso de uso:
someuser ALL=(ALL:ALL) ALL
a
someuser ALL = NOPASSWD: /bin/systemctl restart nginx, /bin/kill, /usr/sbin/reboot
A continuación guarda y sal. Ten en cuenta que sudo lee el archivo /etc/sudoers de abajo hacia arriba, por lo que si que los cambios que haces no parecen ser efectivos, intenta mover la línea que hayas editado para que esté cerca de la parte inferior del archivo sudoers.
Unas palabras acerca de los shells
Puedes establecer el shell por defecto de un usuario ejecutando el comando chsh como root, o en masa editando el archivo /etc/passwd como root. Esto es útil y recomendable en algunos casos, como cambiar el shell por defecto de una cuenta sólo FTP a /sbin/nologin, ya que una cuenta de este tipo nunca debería necesitar ejecutar ningún comando de terminal. Eliminar el acceso al shell en tal caso reduciría la superficie potencial de ataque del sistema.
Proteger el acceso SSH con claves y desactivar el inicio de sesión root
Secure Shell (SSH) es un protocolo de red estándar que permite el acceso remoto a un sistema desde la línea de comandos. Existe la creencia profundamente arraigada en el mundo de la tecnología de que el acceso shell debería ser, por diseño, equivalente a «como si fueras local», por lo que es fundamental limitar el acceso SSH sólo a los usuarios necesarios, y también asegurarse de que sólo los usuarios adecuados pueden hacer cosas como root.
Buenas prácticas para proteger el acceso SSH a servidores Linux
Por lo general, es una buena idea deshabilitar por completo tanto el inicio de sesión root a través de SSH como el acceso SSH basado en contraseña. Mientras que el texto de la contraseña en la autenticación basada en contraseña se transmite de forma cifrada por las claves de host SSH que se intercambian durante el protocolo de transferencia cliente/servidor SSH previo al inicio de sesión, la contraseña se transmite a través de múltiples redes de alguna manera. Este es otro aspecto de la superficie de ataque: si las claves de host de tu servidor SSH se generaron utilizando un algoritmo antiguo/inseguro, por ejemplo, alguien puede husmear tus contraseñas.
Los inicios de sesión con claves SSH no son vulnerables a este tipo de ataque; tus claves públicas son las únicas partes que se transmiten en «texto plano» y han sido diseñadas para ser distribuidas públicamente. Al igual que ocurre con la propia clave privada, la frase de contraseña que usas para desbloquearla durante el inicio de sesión con la clave SSH no se transmite a través de la red.
Utiliza claves SSH para la autenticación
Ten en cuenta que los fragmentos de código que aparecen a continuación están anotados con comentarios del autor indicados con «##» para facilitar las instrucciones.
- Genera una clave SSH utilizando el comando ssh-keygen. Por defecto, se utiliza el formato de clave de cifrado RSA estándar en el sector, pero se recomienda utilizar el estándar de cifrado de curva elíptica ed25519, más rápido y seguro.
user@host:~> ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (/home/user/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_ed25519 Your public key has been saved in /home/user/.ssh/id_ed25519.pub The key fingerprint is: SHA256:NjPk3GbSIL6wdITiSrEQ3U9uXqqaYJdtS62cwCahKoM user@host The key's randomart image is: +--[ED25519 256]--+ |.. . | | .. ... | |... .+o o | |..o. o+=.+ | | +. ooooS = | |o.o.o++o B | |=o *.=.. | |E.+.* + | |o.o. = | +----[SHA256]-----+ user@host:~>
- Copia tu clave pública en tu plataforma de alojamiento en línea. Si todavía tienes acceso con contraseña al servidor en cuestión, puedes utilizar el comando ssh-copy-id para configurar automáticamente los archivos de configuración SSH de tu cuenta remota con tu clave SSH recién generada copiada en los lugares correctos:
ssh-copy-id -i ~/.ssh/id_ed25519.pub remoteuser@remotehost
- Forms de utilizar claves SSH para iniciar sesión:A) Directamente en la línea de comandos:
ssh -i ~/.ssh/id_ed25519 remoteuser@remotehost:port
O utilizando el archivo~/.ssh/config:
- Edita el archivo~/.ssh/config con cualquier editor de texto. Haz esto como la cuenta/el usuario que utilizará la configuración SSH para conectarse remotamente.
- Añade estrofas con el siguiente formato:
Host server1 ## Arbitrary label/handle for easy usage Hostname server1.example.com ## Real hostname/IP User remote_user_1 ## Remote Linux username Port 12345 ## Remote port, default 22 IdentityFile ~/.ssh/id_ed25519 ## NB! Private key file ForwardX11 yes ## Optional, forwards remote GUI apps Host server2 Hostname server2.example.com User remote_user_2 Port 34567 IdentityFile ~/.ssh/id_ed25519
Deben quedar espacios en blanco verticales entre las estrofas.
- Ahora puedes aplicar SSH simplemente escribiendo:
ssh server1
Ya que todo lo demás está especificado bajo esa etiqueta stanza en tu archivo .ssh/config. Consejo: si has adoptado el completado por tabulación de Linux (también conocido como completado de bash), te alegrará saber que el archivo de configuración SSH se conecta automáticamente a los sistemas de completado bash de la mayoría de las distribuciones Linux modernas.
Desactivar la autenticación de inicio de sesión y contraseña de root SSH
- Asegúrate AL 100% de que puedes iniciar sesión con tu clave SSH. Si esto no funciona correctamente, puedes quedarte fuera de tu sistema.
- Utiliza tu editor favorito como root para cambiar las siguientes líneas en /etc/ssh/sshd_configa la siguiente configuración:
PermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no KbdInteractiveAuthentication no
- Opcionalmente, haz que tu servidor SSH se ejecute en un puerto no estándar:
Port 12345
- Guarda este archivo y vuelve a cargar tu servicio SSH:
sudo systemctl restart sshd
- Ahora intenta iniciar sesión a través de SSH sin la clave SSH:
ssh remote_user_1@server1 [-p port]
Si no puedes iniciar sesión sin especificar una clave SSH, has realizado este paso correctamente.
Implementar un firewall en servidores Linux
Si estás funcionando con un servidor Linux de producción y tu distribución viene con un firewall preconfigurado, entonces empiezas con buen pie. Siempre que los datos de un servidor de producción vayan a estar expuestos a Internet, lo mejor es protegerlos implementando un firewall. Las variantes Enterprise Linux/Red Hat suelen incluir firewalld, mientras que Debian/Ubuntu incluyen ufw («Uncomplicated Firewall»). Consulta los comandos man firewall-cmd o man ufw para más detalles.
Configurar las reglas y políticas de un firewall
Las reglas y políticas de un firewall, sin no entramos en los detalles, deberían reducirse a «bloquear todo excepto lo que permito específicamente»- de nuevo, generalmente están preconfiguradas por defecto en los sistemas Linux modernos, especialmente en las variantes Enterprise Linux. Cualquier caso de uso no cubierto por estos valores por defecto queda fuera del ámbito de este documento.
Supervisar y gestionar el firewall
- Tanto el firewalld como el ufw se conectan a los principales sistemas de registro journald y/o [r]syslog.
- Aparte de las herramientas de gestión de firewall de línea de comandos firewall-cmd y ufw, otros frontends de gestión remota como Cockpit, WebMin y YaST ofrecen módulos que permiten la gestión de firewalls. Otras herramientas de gestión remota como ansible y puppet también disponen de módulos para la configuración y gestión automática de firewalls.
Proteger los servicios de red
Buenas prácticas para proteger los servicios de red:
- Ten el menor código posible en tu sistema.
- Ejecuta el mínimo posible de servicios.
- No ejecutes un servicio público como root.
- Los servidores no necesitan una interfaz gráfica de usuario. Código extraño y servicios en ejecución = mayor superficie de ataque.
- Los servicios Linux dependen de que asegures el sistema con certificados de encriptación. Certbot/Let’s Encrypt tiene el proceso más sencillo para generar certificados de encriptación gratuitos.
- La mayoría de los servicios Linux escuchan en puertos separados para sus conexiones seguras e inseguras; consulta el man de cada servicio para más detalles sobre seguridad y otras opciones de configuración.
- Puedes utilizar el comando netstat -tulpen para ver los puertos en los que tu sistema está escuchando (tanto si esos puertos están bloqueados por tu firewall como si no; esto muestra los puertos de escucha por proceso)
El minimalismo es tan importante para la seguridad de los servidores Linux como la acción
En el mundo actual, conectado a la nube, la elección de la distribución del servidor Linux y de las soluciones de gestión remota es más importante que nunca. El software de gestión remota Linux integrado en NinjaOne te da la libertad de utilizar cualquier plataforma de sistema operativo de endpoint manteniéndolo seguro y parcheado.
Se puede afirmar con seguridad que la infraestructura tecnológica de la mayoría de las PYME incluye algunos servidores Linux como parte de su infraestructura crítica. Si tienes un sitio web, lo más probable es que se ejecute en un servidor Linux; si utilizas online banking, lo más probable es que dependa de la seguridad de decenas de servidores Linux. Dado que incluso el propio Android es (simplificando mucho) un núcleo Linux con algunas cosas de interfaz gráfica de usuario añadidas, el tema de la seguridad de Linux puede ser más importante de lo podrías haber imaginado.
