¿Qué está deshabilitado por defecto en la mayoría de servidores Linux (y por qué es importante)?

Cuando aprovisiona un servidor Linux nuevo — ya sea un VPS, un servidor dedicado, o una máquina virtual alojada en la nube — el sistema arranca en un entorno deliberadamente minimalista y endurecido. Esto no es una inadvertencia ni una configuración incompleta. Es una filosofía de diseño intencional integrada en todas las distribuciones Linux principales.

Las compilaciones modernas de servidores Linux eliminan servicios innecesarios, protocolos e interfaces para minimizar la superficie de ataque, conservar recursos del sistema y dar a los administradores control preciso sobre lo que se ejecuta en su infraestructura. Comprender qué está deshabilitado por defecto — y por qué — es conocimiento fundamental para cualquier administrador de sistemas, ingeniero DevOps o desarrollador que gestione cargas de trabajo en producción.

Esta guía disecciona las características y servicios más comunes que están deshabilitados o ausentes por defecto en servidores Linux, explica la justificación de seguridad y operativa detrás de cada decisión, y le muestra exactamente cómo verificar cada configuración en su propio sistema.

Por qué “Deshabilitado por Defecto” es una Estrategia de Seguridad, No una Limitación

El principio en juego aquí se llama a menudo “seguro por defecto, extensible por elección”. En lugar de enviar un sistema completamente equipado y confiar en que los administradores lo bloqueen, las distribuciones Linux modernas envían un sistema bloqueado y confían en que los administradores habiliten solo lo que necesitan.

Este enfoque reduce directamente el riesgo de configuración incorrecta — una de las principales causas de brechas de seguridad en servidores. Cada servicio que no se ejecuta es un servicio que no puede ser explotado. Cada protocolo que no está habilitado es un protocolo que no puede ser interceptado. Cada puerto abierto que no existe es un punto de entrada que los atacantes no pueden sondear.

Con ese contexto establecido, examinemos cada restricción por defecto en detalle.

1. Inicio de Sesión SSH de Root

Estado: Deshabilitado por defecto en prácticamente todas las distribuciones modernas de servidores Linux

El inicio de sesión directo de root a través de SSH está universalmente deshabilitado en compilaciones contemporáneas de servidores Linux — y por una excelente razón. Permitir acceso remoto de root crea un único punto de fallo catastrófico: una contraseña comprometida le da a un atacante control completo e irrestricto sobre todo el sistema.

El flujo de trabajo correcto es iniciar sesión como un usuario sin privilegios y escalar privilegios usando sudo o su solo cuando sea necesario. Esto crea un registro de auditoría, limita el radio de explosión del robo de credenciales y fuerza una acción deliberada antes de ejecutar comandos privilegiados.

Cómo verificar:

grep PermitRootLogin /etc/ssh/sshd_config

Salida esperada en un servidor correctamente endurecido:

PermitRootLogin no

Si ve PermitRootLogin yes o PermitRootLogin prohibit-password, revise su configuración SSH inmediatamente y alinéela con la política de seguridad de su organización.

Mejor práctica:

Cree un usuario administrativo dedicado, agréguelo al grupo sudo y asegúrese de que PermitRootLogin no esté configurado antes de implementar cualquier servicio de cara al público.

2. Autenticación por Contraseña en SSH

Estado: Deshabilitado por defecto en la mayoría de servidores aprovisionados en la nube

En muchas plataformas en la nube y entornos de alojamiento administrado, la autenticación por contraseña SSH está completamente deshabilitada en el momento del aprovisionamiento. Los pares de claves SSH son el único mecanismo de autenticación aceptado.

Esta es una mejora significativa de seguridad. La autenticación por contraseña es vulnerable a ataques de fuerza bruta, relleno de credenciales y ataques de diccionario. Las claves SSH — particularmente cuando están protegidas por una frase de contraseña — son computacionalmente imposibles de fuerza bruta con la tecnología actual.

Las instalaciones tradicionales basadas en ISO aún pueden permitir inicios de sesión por contraseña por defecto, pero la mejor práctica es deshabilitarlos inmediatamente después de configurar la autenticación basada en claves.

Cómo verificar:

grep PasswordAuthentication /etc/ssh/sshd_config

Salida esperada:

PasswordAuthentication no

Cómo deshabilitar la autenticación por contraseña:

Edite /etc/ssh/sshd_config y establezca:

PasswordAuthentication no
PubkeyAuthentication yes

Luego recargue el demonio SSH:

# Ubuntu/Debian
sudo systemctl reload ssh

# RHEL/AlmaLinux/Rocky Linux
sudo systemctl reload sshd

> Advertencia: Siempre confirme que su clave SSH funciona antes de deshabilitar la autenticación por contraseña, o corre el riesgo de quedar bloqueado fuera del servidor.

3. Protocolos de Red Heredados y en Texto Plano

Estado: Ausentes de compilaciones modernas de servidores

Servicios como Telnet, FTP, Rlogin y Rsh no están instalados en imágenes modernas de servidores Linux. Estos protocolos fueron diseñados en una era anterior a que el cifrado fuera una prioridad. Transmiten credenciales, comandos y datos en texto plano — lo que los hace trivialmente fáciles de interceptar con un analizador de paquetes en cualquier segmento de red entre cliente y servidor.

Estos protocolos han sido reemplazados por alternativas seguras:

Cómo verificar que no hay servicios heredados en ejecución:

ss -tulnp

Si los puertos 21 (FTP) o 23 (Telnet) no aparecen en la salida, esos servicios no están activos. Si aparecen, investigue inmediatamente y elimine o deshabilite a menos que haya un requisito específico y justificado.

4. Interfaces Gráficas de Usuario (GUI)

Estado: No instalado en ediciones de servidor

Las distribuciones de servidor — incluyendo Ubuntu Server, Debian, AlmaLinux, Rocky Linux y CentOS Stream — no incluyen entornos de escritorio gráficos como GNOME, KDE Plasma o XFCE. Esta es una elección deliberada y bien razonada.

Un entorno GUI:

• Consume recursos significativos de RAM y CPU que deberían dedicarse a cargas de trabajo
• Introduce una gran cantidad de paquetes de software adicionales, cada uno de los cuales representa una vulnerabilidad potencial
• Es completamente innecesario para la administración de servidores, que se realiza a través de la línea de comandos sobre SSH

La expectativa es inequívoca: los servidores se administran a través de la CLI. Si se encuentra deseando una interfaz gráfica en un servidor de producción, eso es generalmente una señal de que un proceso o flujo de trabajo necesita ser reconsiderado.

> Nota: Herramientas como Paneles de Control VPS — como cPanel, Plesk o DirectAdmin — proporcionan interfaces de gestión gráficas basadas en web sin requerir que un entorno de escritorio completo esté instalado en el servidor.

5. Cadenas de Herramientas de Desarrollo y Compiladores

Estado: No instalado en imágenes de servidor mínimas

Compiladores como gcc y utilidades de compilación como make, cmake y autoconf están intencionalmente ausentes de la mayoría de imágenes mínimas de servidores Linux. La justificación es doble:

1. Tamaño de imagen reducido: Las imágenes mínimas se implementan más rápido, son más fáciles de respaldar y consumen menos recursos.
2. Endurecimiento de seguridad: Si un atacante obtiene acceso a un servidor, la ausencia de un compilador les impide compilar binarios maliciosos o código de exploit directamente en el sistema. Este es un obstáculo significativo en muchas cadenas de ataque.

Cómo verificar:

gcc --version

Si la cadena de herramientas no está instalada, verá:

-bash: gcc: command not found

Cómo instalar si es necesario:

# Ubuntu/Debian
sudo apt update && sudo apt install build-essential

# RHEL/AlmaLinux/Rocky Linux
sudo dnf groupinstall "Development Tools"

Instale herramientas de desarrollo solo en servidores donde la compilación es un requisito operativo genuino — como servidores de compilación o entornos de desarrollo — y evite instalarlos en servidores de aplicaciones de producción o servidores de bases de datos.

6. ICMP (Respuestas de Ping)

Estado: Habilitado por defecto a nivel del SO; a menudo restringido a nivel de red/firewall

Los servidores Linux responden a solicitudes de eco ICMP (ping) por defecto a nivel del sistema operativo. Sin embargo, muchos proveedores de alojamiento y plataformas en la nube bloquean ICMP a nivel del firewall de red o grupo de seguridad, haciendo que los servidores parezcan inalcanzables para ping incluso cuando están completamente operativos.

Suprimir respuestas ICMP hace que un servidor sea menos descubrible durante escaneos de reconocimiento de red. Sin embargo, también complica el monitoreo y diagnóstico legítimos — herramientas como ping y traceroute dependen de ICMP para funcionar correctamente.

Cómo probar:

ping your_server_ip

Cómo bloquear ICMP a nivel del SO usando iptables (si es necesario):

sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

La decisión de bloquear ICMP debe tomarse deliberadamente, sopesando el beneficio de seguridad marginal contra el costo operativo para los flujos de trabajo de monitoreo y solución de problemas.

7. IPv6

Estado: Habilitado por defecto en la mayoría de distribuciones; puede estar restringido a nivel del proveedor

IPv6 está habilitado por defecto en distribuciones Linux modernas incluyendo Ubuntu, Debian, Fedora y derivados de RHEL. Sin embargo, muchos proveedores de alojamiento deshabilitan IPv6 a nivel de red si su infraestructura no lo soporta, lo que significa que el SO puede estar configurado para IPv6 pero el servidor no tendrá una dirección IPv6 enrutable.

Cómo verificar direcciones IPv6:

ip a | grep inet6

Si solo ::1 (la dirección de loopback) aparece, IPv6 no está configurado a nivel de red incluso si está habilitado en el SO.

Si su carga de trabajo no requiere IPv6 y su proveedor no lo ofrece, puede deshabilitarlo a nivel del kernel agregando lo siguiente a /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Luego aplique el cambio:

sudo sysctl -p

8. Servicios y Demonios del Sistema Innecesarios

Estado: Varía según la distribución; las instalaciones mínimas deshabilitan la mayoría de servicios no esenciales

Más allá de los elementos enumerados anteriormente, las instalaciones mínimas de servidores Linux típicamente deshabilitan u omiten una variedad de servicios que están presentes en compilaciones de escritorio o completamente equipadas:

• Bluetooth — irrelevante en servidores; no instalado
• Avahi/mDNS — descubrimiento de red local; innecesario y potencialmente una preocupación de seguridad en servidores
• Cups (impresión) — sin caso de uso en un servidor
• ModemManager — irrelevante en hardware de servidor
• NetworkManager — a menudo reemplazado por systemd-networkd o configuración manual de netplan en servidores

Cómo auditar servicios en ejecución:

systemctl list-units --type=service --state=running

Revise esta lista periódicamente y deshabilite cualquier servicio que no sirva un propósito documentado en ese servidor específico.

Lista de Verificación Práctica de Seguridad para un Servidor Linux Recién Aprovisionado

Después de aprovisionar un nuevo servidor — ya sea alojamiento web compartido actualizado a un VPS o un nuevo servidor dedicado — ejecute esta lista de verificación para confirmar su postura de seguridad de base:

Elegir el Entorno de Alojamiento Correcto para Sus Requisitos de Seguridad

La postura de seguridad predeterminada de su servidor también está influenciada por el entorno de alojamiento que elige. Un VPS con cPanel proporciona una interfaz administrada basada en web que simplifica la administración mientras preserva el modelo de seguridad Linux subyacente. Un servidor dedicado de metal desnudo le da control total sobre cada capa de la pila, desde firmware hasta aplicación.

Para equipos que ejecutan aplicaciones web aseguradas con SSL, emparejar su servidor con un certificado SSL correctamente configurado es un complemento esencial para el endurecimiento a nivel de servidor — cifrando datos en tránsito así como la autenticación de clave SSH protege el acceso al servidor mismo.

Conclusión

Los servidores Linux listos para usar se aprovisionan en un estado deliberadamente seguro y simplificado. El inicio de sesión SSH de root está deshabilitado. La autenticación por contraseña está restringida o eliminada. Los protocolos heredados en texto plano están ausentes. No se instala entorno gráfico. Los compiladores y herramientas de compilación se excluyen de imág