Cómo proteger un servidor Linux básico: seguridad mínima imprescindible

Cómo proteger un servidor Linux básico: seguridad mínima imprescindible

Un servidor Linux recién instalado no debería ponerse en producción sin una seguridad mínima. Aunque parezca limpio, rápido y vacío, en cuanto queda expuesto a Internet puede empezar a recibir intentos automáticos de acceso, escaneos de puertos, peticiones sospechosas y ataques contra servicios habituales.

Proteger un servidor Linux no significa convertirlo en una fortaleza imposible de administrar. Para una microempresa, un VPS con WordPress, una web corporativa o un proyecto de formación online, el objetivo inicial debe ser más práctico: reducir riesgos evidentes, controlar accesos, mantener el sistema actualizado, limitar servicios expuestos y preparar copias de seguridad.

Este artículo explica la seguridad básica que conviene aplicar antes de confiar un proyecto serio a un servidor Linux, sin caer en recetas extremas ni en configuraciones que luego nadie sabe mantener.

Índice

• El punto de partida: ningún servidor expuesto es invisible
• Mantener el sistema actualizado
• Usar usuarios seguros y evitar trabajar siempre como root
• Proteger el acceso SSH
• Configurar un firewall básico
• Reducir servicios expuestos
• Revisar permisos de archivos y directorios
• Revisar logs y señales de actividad sospechosa
• Tener copias de seguridad restaurables
• Seguridad del servidor cuando hay WordPress
• Errores frecuentes al proteger un servidor Linux
• Conclusión
• Preguntas frecuentes

El punto de partida: ningún servidor expuesto es invisible

Una idea peligrosa es pensar que un servidor pequeño no interesa a nadie. En Internet no hace falta que alguien conozca tu empresa para que tu máquina reciba tráfico malicioso. Muchos ataques son automáticos y buscan direcciones IP con servicios abiertos, versiones vulnerables o credenciales débiles.

Un VPS recién creado puede recibir intentos de acceso por SSH, peticiones contra rutas típicas de WordPress, escaneos de puertos o solicitudes contra archivos que ni siquiera existen en tu servidor. No es algo personal; es ruido automatizado de Internet.

Por eso, la seguridad básica debe aplicarse desde el principio, incluso si el proyecto todavía no tiene tráfico, clientes ni posicionamiento SEO. Un servidor abandonado o mal configurado puede usarse para enviar spam, alojar malware, atacar a terceros o comprometer una web corporativa.

Si estás construyendo la infraestructura desde cero, este artículo encaja después de entender qué es realmente un servidor web, elegir entre VPS o servidor dedicado e instalar una base como Ubuntu Server.

Mantener el sistema actualizado

La primera medida de seguridad es sencilla: mantener el sistema actualizado. Muchas vulnerabilidades conocidas se corrigen mediante actualizaciones de paquetes. Si el servidor no se actualiza, acumula riesgo con el tiempo.

Actualizar no significa aplicar cambios sin mirar en plena campaña comercial o en horario crítico. Significa tener una rutina. En servidores de producción conviene revisar actualizaciones, entender si afectan a servicios importantes y reiniciar cuando sea necesario de forma planificada.

En Ubuntu Server, un flujo básico puede incluir:

sudo apt update
sudo apt upgrade

También conviene comprobar si el sistema solicita reinicio tras actualizar componentes importantes. En servidores que alojan webs reales, reiniciar sin planificación puede causar una interrupción breve, pero no reiniciar nunca también puede dejar parches sin aplicar.

La seguridad no es instalar una vez y olvidarse. Un servidor Linux necesita mantenimiento periódico, especialmente si aloja nginx, Apache, PHP, MariaDB, WordPress u otros servicios expuestos.

Usar usuarios seguros y evitar trabajar siempre como root

Trabajar siempre como root es cómodo, pero aumenta el riesgo de cometer errores graves. Un comando mal ejecutado como root puede borrar archivos críticos, cambiar permisos sensibles o afectar a todos los servicios del servidor.

Lo habitual en un servidor Linux bien administrado es usar un usuario personal o técnico con permisos mediante sudo. Así se mantiene control sobre quién entra, qué privilegios tiene y cuándo se elevan permisos.

Buenas prácticas básicas:

• Crear usuarios separados para administración.
• Evitar cuentas compartidas entre varias personas.
• Usar contraseñas largas y únicas.
• Eliminar usuarios que ya no deban tener acceso.
• Revisar periódicamente quién puede usar sudo.
• No usar root para tareas ordinarias.

También es importante distinguir entre usuarios humanos y usuarios de servicio. El usuario que administra el servidor no tiene por qué ser el mismo que ejecuta nginx, PHP-FPM o procesos internos.

Este punto merece una guía específica, por eso conviene continuar con cómo crear usuarios seguros en Linux cuando quieras profundizar en permisos, sudo y separación de responsabilidades.

Proteger el acceso SSH

SSH es una herramienta imprescindible para administrar servidores remotos, pero también es uno de los objetivos más habituales de intentos automáticos de acceso. Si SSH está expuesto a Internet, debe protegerse con criterio.

Medidas recomendables:

• No permitir acceso directo como root.
• Usar contraseñas robustas o autenticación por clave pública.
• Limitar qué usuarios pueden acceder por SSH.
• Revisar logs de intentos fallidos.
• Valorar restricciones por IP si el entorno lo permite.
• Evitar dejar cuentas antiguas activas.

La autenticación por clave pública suele ser preferible a una contraseña simple, especialmente en servidores expuestos. Pero incluso con claves, conviene mantener una política clara de acceso, copia segura de claves y revocación cuando sea necesario.

Herramientas como fail2ban pueden ayudar a bloquear intentos repetidos, pero no sustituyen una configuración SSH razonable. Primero hay que reducir el riesgo de base; después se añaden capas adicionales.

Para una protección más específica frente a intentos repetidos, puedes enlazar este punto con cómo configurar fail2ban correctamente y cómo evitar ataques automáticos a tu servidor.

Configurar un firewall básico

Un firewall permite controlar qué conexiones entran o salen del servidor. En un servidor web básico, normalmente no hace falta exponer muchos servicios. Cuantos menos puertos estén abiertos, menor será la superficie de ataque.

En una configuración típica de servidor web público, podrían necesitarse:

• Puerto 22 para SSH, si se administra remotamente.
• Puerto 80 para HTTP.
• Puerto 443 para HTTPS.

Otros servicios, como bases de datos, paneles internos o herramientas administrativas, no deberían exponerse a Internet salvo que exista una razón clara y una protección adecuada.

En Ubuntu, una herramienta sencilla para gestionar firewall es UFW. Un esquema básico podría permitir SSH, HTTP y HTTPS, bloqueando el resto de entradas no autorizadas.

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Estos comandos son orientativos. Antes de activar un firewall en un servidor remoto, hay que asegurarse de no bloquear el propio acceso SSH. Perder acceso a un VPS por una regla mal aplicada es un clásico desagradable.

Reducir servicios expuestos

Una regla sencilla de seguridad es no exponer lo que no se necesita. Cada servicio abierto es una posible puerta de entrada, una fuente de errores o una pieza más que mantener.

En un servidor Linux conviene revisar qué servicios están activos y qué puertos escuchan conexiones. Puede haber servicios instalados por pruebas anteriores, paneles, bases de datos, demonios auxiliares o herramientas que ya no se usan.

Preguntas útiles:

• ¿Qué servicios están escuchando en red?
• ¿Todos son necesarios?
• ¿Deben estar accesibles desde Internet?
• ¿Están actualizados?
• ¿Quién los mantiene?

Una base limpia suele ser más segura que un servidor lleno de herramientas instaladas “por si acaso”. En proyectos de microempresa, la simplicidad operativa es una ventaja: menos piezas, menos sorpresas, menos mantenimiento oculto.

Este enfoque también aplica al servidor web. Instalar nginx o Apache correctamente no consiste solo en que respondan, sino en evitar configuraciones innecesarias y mantener una estructura comprensible. Si trabajas con nginx, puedes apoyarte en cómo instalar nginx correctamente.

Revisar permisos de archivos y directorios

Los permisos mal configurados son una fuente muy habitual de problemas. A veces se abren permisos excesivos para resolver errores rápidos, pero eso puede dejar archivos modificables por procesos que no deberían tener ese nivel de acceso.

En un servidor web, hay que equilibrar tres necesidades:

• Que nginx o Apache puedan leer los archivos públicos.
• Que aplicaciones como WordPress puedan escribir donde realmente lo necesitan.
• Que archivos sensibles no queden expuestos ni modificables indebidamente.

Permisos como 777 aplicados de forma indiscriminada son una mala señal. Pueden parecer una solución rápida, pero abren un riesgo claro si un proceso vulnerable consigue escribir donde no debería.

También conviene revisar la propiedad de archivos y carpetas. En Ubuntu, procesos web suelen ejecutarse con usuarios como www-data, pero no todo el árbol del proyecto debe tratarse igual. Subidas, cachés, configuración y código no tienen las mismas necesidades.

En WordPress, este punto es especialmente delicado porque hay actualizaciones, plugins, temas y archivos subidos. Por eso conviene conectar la seguridad del servidor con cómo proteger WordPress desde nginx cuando la web use esa arquitectura.

Revisar logs y señales de actividad sospechosa

Los logs son una de las herramientas más útiles para entender qué ocurre en un servidor. Sin logs, muchos problemas parecen misteriosos: caídas, errores 500, intentos de acceso, consumo elevado o peticiones extrañas.

En un servidor Linux básico conviene conocer, al menos, dónde revisar:

• Logs del sistema.
• Logs de autenticación.
• Logs de nginx o Apache.
• Logs de PHP-FPM si se usa PHP.
• Logs de base de datos si hay problemas de rendimiento.

No hace falta vivir mirando logs todo el día, pero sí saber consultarlos cuando algo falla. Un pico de intentos SSH, muchas peticiones a rutas inexistentes o errores repetidos en nginx pueden anticipar problemas.

La revisión de logs también ayuda a diferenciar entre ataques automáticos normales, errores de configuración y problemas reales de aplicación. No todo tráfico raro implica una intrusión, pero ignorarlo por completo tampoco es buena idea.

Si el servidor empieza a comportarse de forma extraña, también puede ser útil revisar cómo monitorizar recursos del servidor y cómo detectar consumo excesivo de CPU.

Tener copias de seguridad restaurables

La seguridad no termina en evitar accesos no autorizados. También implica poder recuperarse cuando algo falla. Un servidor sin copias de seguridad restaurables es un riesgo operativo serio.

Las copias deben cubrir, según el caso:

• Archivos de la web.
• Bases de datos.
• Configuraciones importantes.
• Certificados o información necesaria para reconstruir el servicio.
• Scripts propios.
• Documentación técnica mínima.

Una copia que nunca se ha probado no debería considerarse completamente fiable. Lo importante no es solo hacer backups, sino saber restaurarlos. En una web profesional, una restauración rápida puede ahorrar muchas horas de caída y pérdida de confianza.

También hay que evitar guardar todas las copias únicamente dentro del mismo servidor. Si el servidor se corrompe, se borra o queda comprometido, las copias locales pueden perderse o quedar afectadas.

Este tema merece tratamiento propio en cómo hacer backups automáticos del servidor.

Seguridad del servidor cuando hay WordPress

WordPress añade una capa adicional de responsabilidad. No basta con que Linux esté actualizado si WordPress, sus plugins o su tema quedan abandonados.

En servidores con WordPress, conviene cuidar:

• Actualizaciones del núcleo de WordPress.
• Plugins instalados y realmente necesarios.
• Temas activos e inactivos.
• Permisos de archivos y carpetas.
• Protección del acceso al panel.
• Copias de base de datos y archivos.
• Reglas del servidor web para proteger archivos sensibles.
• Uso correcto de HTTPS.

Una web WordPress puede recibir ataques automáticos contra rutas conocidas, formularios, XML-RPC, plugins vulnerables o páginas de login. Por eso la seguridad debe tratarse por capas: Linux, servidor web, PHP, base de datos y WordPress.

Si el servidor todavía no tiene WordPress instalado, puedes seguir con cómo instalar WordPress manualmente. Si ya lo tiene y usas nginx, el siguiente paso natural es cómo proteger WordPress desde nginx.

Errores frecuentes al proteger un servidor Linux

Uno de los errores más frecuentes es aplicar medidas sueltas sin entenderlas. Copiar reglas de firewall, cambiar puertos, instalar herramientas o modificar SSH sin saber qué se está haciendo puede dejar el servidor peor que antes.

Otro error habitual es pensar que una herramienta soluciona todo. Fail2ban ayuda, un firewall ayuda, HTTPS ayuda, pero ninguna medida aislada sustituye una administración cuidadosa.

Errores típicos:

• No actualizar el sistema.
• Trabajar siempre como root.
• Usar contraseñas débiles o reutilizadas.
• Dejar servicios innecesarios expuestos.
• Aplicar permisos excesivos para resolver problemas rápidos.
• No revisar logs.
• No tener backups restaurables.
• Instalar paneles o herramientas sin mantenerlos.
• Configurar firewall sin comprobar acceso SSH.
• No documentar cambios importantes.

La seguridad básica funciona mejor cuando es simple, comprensible y sostenible. Una configuración demasiado sofisticada que nadie mantiene acaba siendo un decorado técnico.

Conclusión

Proteger un servidor Linux básico no consiste en aplicar una lista interminable de trucos, sino en construir una base razonable: sistema actualizado, usuarios bien definidos, SSH protegido, firewall, servicios mínimos, permisos correctos, logs revisables y copias de seguridad restaurables.

Para una microempresa o proyecto digital serio, esta seguridad mínima es parte de la operativa normal. No es un lujo técnico. Si la web sostiene ventas, posicionamiento SEO, captación de clientes o formación online, el servidor debe tratarse como una pieza crítica del negocio.

Un servidor seguro no es el que tiene más herramientas instaladas, sino el que está bien mantenido, documentado y preparado para recuperarse cuando algo falla.

La buena noticia es que no hace falta hacerlo todo perfecto desde el primer día. Pero sí conviene empezar con una base limpia y no dejar la seguridad para cuando ya haya ocurrido el problema.

Preguntas frecuentes