Configuración del Cortafuegos del Servidor: Protege tu Servidor contra DDoS y Bots Maliciosos

La configuración del cortafuegos en un servidor consiste en mantener abiertos únicamente los puertos necesarios y bloquear cualquier acceso innecesario; es la primera línea de defensa contra ataques DDoS, fuerza bruta y tráfico malicioso generado por bots. En la práctica, el objetivo es limitar el acceso SSH, abrir los servicios web de forma controlada, aplicar límites de tasa a las solicitudes sospechosas, monitorear los registros y, cuando sea posible, filtrar el tráfico antes de que llegue al servidor mediante capas superiores como CDN o WAF.

En cuanto un servidor web se conecta a internet, en cuestión de minutos comienzan los escaneos de puertos, intentos de acceso SSH, bots buscando vulnerabilidades y agentes de usuario falsos. Esto es especialmente crítico en instalaciones que ejecutan WordPress, comercio electrónico, paneles de administración, APIs o servidores de juegos, donde el cortafuegos no es solo una opción técnica, sino una necesidad para garantizar la continuidad. En esta guía construiremos paso a paso una arquitectura de cortafuegos aplicable en servidores Linux, abordando herramientas como UFW, firewalld, nftables, Fail2ban, cortafuegos de aplicaciones web y estrategias para mitigar ataques DDoS.

Un hecho importante para destacar: el cortafuegos local del servidor por sí solo no puede detener ataques DDoS de gran volumen. Cuando un ataque de 20 Gbps, 80 Gbps o más llega al centro de datos o a la columna vertebral de la red, puede saturar el ancho de banda antes de que los paquetes alcancen las reglas del sistema operativo. Por eso, la estrategia correcta es la seguridad en capas: protección DDoS a nivel de proveedor, CDN/WAF, cortafuegos a nivel del sistema operativo, limitación de tasa en la aplicación y análisis regular de logs deben trabajar en conjunto. Para elegir una infraestructura adecuada, puedes visitar la página Soluciones de servidor VPS y VDS Hostragons y para opciones seguras de alojamiento web, la página Paquetes de hosting web Hostragons.

¿Para Qué Sirve un Cortafuegos en el Servidor?

El cortafuegos del servidor es una capa de seguridad que filtra el tráfico de red según la IP de origen, IP destino, puerto, protocolo, estado de la conexión y, en algunos casos, características del paquete. Por ejemplo, los puertos 80 y 443 deben estar abiertos para tu sitio web, pero el puerto de la base de datos 3306 no debería estar accesible desde internet. Para SSH, en lugar de permitir intentos desde cualquier IP en el puerto 22, es más seguro restringir el acceso solo a la IP de tu oficina.

El objetivo principal del cortafuegos no es eliminar todos los ataques milagrosamente, sino reducir la superficie de ataque. Cuanto menor sea la superficie, menos opciones tendrá el atacante para intentar vulnerar el sistema. Por ejemplo, en un servidor Linux recién instalado, SSH, panel web, servicio de correo, base de datos, agente de monitoreo y servicios de prueba pueden estar abiertos simultáneamente, cada uno representando un riesgo separado. Un cortafuegos bien configurado opera bajo el principio “denegar por defecto, permitir solo lo necesario”.

Comprendiendo el Tráfico DDoS y de Bots

¿Por qué los Ataques DDoS Son Diferentes?

Un ataque DDoS (Denegación de Servicio Distribuida) busca saturar un servicio objetivo con una gran cantidad de tráfico proveniente de múltiples fuentes para dejarlo inaccesible. Estos ataques pueden saturar el ancho de banda, agotar los recursos de CPU y RAM del servidor o activar operaciones costosas en la capa de aplicación. Por ejemplo, un servidor de aplicaciones pequeño que recibe 50,000 solicitudes HTTP por segundo puede quedar sin respuesta no porque la red esté saturada, sino por la carga en PHP-FPM, Node.js o en el pool de conexiones de la base de datos.

¿Son Siempre Maliciosos los Bots?

No. Bots como Googlebot, Bingbot y algunos de monitoreo son útiles. Sin embargo, los bots maliciosos escanean paneles de administración, buscan directorios abiertos, generan spam en formularios, copian contenido, abusan de XML-RPC, crean cuentas falsas e intentan logins fraudulentos. Por ello, la gestión de bots no consiste en bloquear todos, sino en distinguir comportamientos. Indicadores importantes son tasas altas de error, demasiadas solicitudes en poco tiempo, encabezados que no se comportan como un navegador real y patrones sospechosos en las URLs.

Lista de Verificación Antes de Empezar

El mayor riesgo al configurar reglas de cortafuegos en un servidor en producción es bloquearse a uno mismo fuera del servidor. Por eso, antes de aplicar cambios, es necesario preparar una lista de control. A continuación, una estrategia segura comúnmente usada en entornos productivos:

• No cierres tu sesión SSH activa; realiza pruebas desde una segunda terminal.
• Confirma que tu proveedor de servidor ofrece acceso a consola, VNC o modo recuperación.
• Lista los puertos abiertos actualmente con comandos como ss -tulpn o netstat -tulpn.
• Anota qué puertos usan servicios como web, correo, DNS, base de datos, panel y monitoreo.
• Si usas IPv6, planifica también reglas para el cortafuegos IPv6.
• Primero aplica las reglas de permisos (allow), luego las de denegación (deny).
• Asegúrate que las reglas sean persistentes tras reinicios.

Por ejemplo, en un servidor típico que solo aloja un sitio web, los puertos abiertos suelen ser 80, 443 y un puerto SSH limitado. Si no operas un servidor de correo, puertos como 25, 465, 587 o 993 no deben estar abiertos. Si la base de datos es solo local, los puertos 3306 o 5432 deben permanecer cerrados al exterior.

¿Qué Herramienta de Cortafuegos Deberías Elegir?

En el mundo Linux existen varias herramientas que manejan la misma infraestructura de filtrado del núcleo pero con diferentes facilidades de uso. Para principiantes, UFW es sencillo y rápido. En sistemas empresariales o basados en Red Hat es común el uso de firewalld. Para escenarios avanzados, nftables ofrece una estructura moderna y flexible. La siguiente tabla ayuda a elegir:

Configuración Paso a Paso del Cortafuegos del Servidor

1. Identifica Puertos y Servicios Abiertos

El primer paso es saber qué puertos están activos. El comando ss -tulpn en Linux muestra qué servicios están escuchando en qué puertos. Por ejemplo, si nginx está en 0.0.0.0:80 y 0.0.0.0:443, significa que acepta tráfico web desde todas las interfaces. Si MariaDB escucha en 0.0.0.0:3306, esto puede ser riesgoso, pues normalmente la base de datos debería estar limitada a 127.0.0.1.

Una regla práctica es: ningún servicio que no deba ser accesible desde internet debe escuchar en 0.0.0.0. Primero corrige la configuración del servicio y luego bloquea con el cortafuegos. Así, aunque el cortafuegos falle, el servicio no estará expuesto.

2. Configura la Política Predeterminada para Denegar

En reglas seguras, el tráfico entrante se niega por defecto y el saliente se permite según necesidad. Esto evita que servicios nuevos se abran accidentalmente al exterior. En un servidor Ubuntu con UFW, la lógica es: primero permite SSH, luego abre puertos 80 y 443, establece la política predeterminada para negar tráfico entrante y finalmente activa el cortafuegos.

Ejemplo: permite SSH solo desde tu IP administrativa, abre HTTP y HTTPS, bloquea puertos innecesarios y activa UFW. Activar el cortafuegos sin permitir SSH puede causar pérdida de acceso, especialmente en servidores remotos.

3. Restringe el Acceso SSH

SSH es uno de los servicios más atacados. Un servidor con el puerto 22 abierto puede recibir cientos o miles de intentos de contraseña diariamente. La forma más segura es restringir SSH a IPs específicas. Si usas IP fija, permite solo la IP de oficina o VPN. De no ser así, usa autenticación con clave y desactiva el acceso por contraseña.

• Deshabilita acceso directo como root vía SSH.
• Usa claves SSH en lugar de contraseñas.
• Limita usuarios con AllowUsers o AllowGroups.
• Usa Fail2ban para bloquear intentos fallidos automáticamente.
• Si tienes panel de administración, limita también el puerto de acceso.

Cambiar el puerto SSH no garantiza seguridad, pero reduce el ruido de bots automáticos. La verdadera protección viene con restricción de IP, autenticación fuerte y monitoreo de logs.

4. Abre Puertos Web con Control

Los puertos 80 y 443 son esenciales para la mayoría de servidores web. Hoy en día, el puerto 443 (HTTPS) debe ser el principal y el 80 solo para redireccionar a HTTPS. Los sitios sin certificado SSL afectan la confianza del usuario y el SEO. Aquí es una buena oportunidad para enlazar a Certificados SSL Hostragons y guiar al lector hacia una instalación segura de HTTPS.

Al abrir puertos web, considera la IP real que llega al servidor. Si usas CDN o proxy inverso, es mejor permitir tráfico solo de las IPs de la CDN en los puertos 80 y 443, evitando exponer la IP real del servidor y dificultando ataques directos.

5. Cierra el Acceso a Bases de Datos y Servicios Internos

Servicios como MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch o MongoDB son un riesgo grave si están accesibles desde internet. La falta de autenticación en Redis, acceso sin permisos a índices de Elasticsearch o puertos abiertos de MongoDB han causado numerosas fugas de datos. Estos servicios deben escuchar solo en localhost o en redes privadas.

Por ejemplo, en un servidor con WordPress, la base de datos debe conectar solo vía 127.0.0.1. Si usas servidores separados para aplicación y base de datos, solo permite el acceso desde la IP interna del servidor de aplicaciones. Dejar puertos como 3306 o 5432 abiertos es un error común que aprovechan los bots para escanear continuamente.

6. Bloquea Intentos de Fuerza Bruta con Fail2ban

Fail2ban monitorea los archivos de log y bloquea temporalmente IPs que intentan accesos fallidos repetidos. Se pueden crear “jaulas” (jails) para SSH, nginx, Apache, Postfix, Dovecot, WordPress y paneles de administración. Por ejemplo, bloquear durante una hora una IP que falle cinco veces el login SSH en diez minutos es un buen punto de partida.

Ten cuidado con reglas muy agresivas que puedan bloquear usuarios legítimos. Es recomendable empezar con tiempos razonables, monitorear logs y endurecer las reglas gradualmente.

7. Añade Limitaciones de Tasa y Conexiones

El sistema operativo puede ayudar a limitar la tasa de conexiones para mitigar DDoS y bots. Por ejemplo, restringir el número de conexiones nuevas por segundo desde una misma IP. En el servidor web, nginx ofrece módulos como limit_req y limit_conn, y Apache tiene soluciones como mod_evasive. En la aplicación, es necesario implementar límites en logins, búsquedas, carritos, pagos y endpoints de API.

Un ejemplo concreto: permitir 10 intentos de login por minuto por IP puede ser razonable, mientras que en un endpoint de búsqueda 2 a 5 solicitudes por segundo pueden ser suficientes. En APIs se deben combinar límites por token, IP y análisis de comportamiento para evitar que el atacante simplemente cambie IP y supere los límites.

Ejemplo de Configuración Segura con UFW

En un servidor web basado en Ubuntu o Debian, un escenario seguro básico se puede implementar así: verifica los servicios activos, permite SSH solo desde tu IP administrativa, abre puertos 80 y 443, establece la política predeterminada para negar tráfico entrante y activa UFW. Si no tienes IP fija para SSH, puedes permitirlo temporalmente desde todas las IPs y luego migrar a VPN o IP fija.

Un conjunto de reglas ejemplo con IP administrativa 203.0.113.10: SSH solo desde esa IP, tráfico web abierto en 80 y 443 para todos, puertos de base de datos, Redis, panel y pruebas cerrados. Esta configuración es un buen punto de partida para muchos sitios empresariales pequeños y medianos. Para una correcta configuración de dominio y DNS, consulta Consulta de dominio y registro Hostragons.

firewalld y la Lógica de Zonas

En servidores basados en AlmaLinux, Rocky Linux y RHEL, firewalld es común. Funciona con el concepto de zonas: la zona public para interfaces abiertas a internet, trusted para redes confiables y drop para descartar tráfico no deseado silenciosamente. Un punto clave es entender la diferencia entre reglas en tiempo de ejecución (runtime) y permanentes (permanent). Las primeras se aplican al instante pero desaparecen tras reinicio; las segundas son duraderas pero requieren recarga.

En ambientes corporativos, firewalld facilita abrir servicios en zonas específicas. Por ejemplo, HTTP y HTTPS en zona public, SSH solo para ciertas IPs. Si tienes redes separadas para administración, respaldo y usuarios, la segmentación por zonas mejora seguridad y claridad.

CDN, WAF y Protección DDoS a Nivel Proveedor

El cortafuegos local decide después de que el paquete llega al servidor. En ataques DDoS masivos, la clave es filtrar el tráfico antes de que llegue. Por eso la protección a nivel proveedor, CDN y WAF es fundamental. La CDN entrega contenido estático desde ubicaciones cercanas al usuario, el WAF filtra solicitudes maliciosas en la capa de aplicación, y la protección del proveedor absorbe o limpia ataques volumétricos en la red.

El modelo ideal es que los registros DNS pasen por la CDN, la IP real del servidor esté oculta, y solo se permita tráfico desde las IPs de la CDN en los puertos 80 y 443 del cortafuegos local. Los puertos de administración deben ser accesibles solo vía VPN o IP fija. Este esquema reduce la posibilidad de ataques directos y permite filtrar bots antes de llegar a la aplicación. Para temas combinados de seguridad y rendimiento web, consulta Guías de aceleración y seguridad de sitios web.

Medidas en la Capa de Aplicación contra Bots

Bloquear bots no se limita a listas negras de IPs. Los bots modernos usan proxies, redes móviles, IPs de centros de datos y cambian agentes de usuario constantemente. Por eso se requiere un enfoque basado en comportamiento. Se deben analizar múltiples factores: intentos de login rápidos desde la misma IP, escaneos con muchos errores 404, alta actividad en wp-login.php o xmlrpc.php, patrones de clic distintos a usuarios normales y encabezados sospechosos.

• Limita la tasa en formularios de login y registro.
• Deshabilita o restringe acceso innecesario a XML-RPC.
• Protege paneles de administración con URL personalizada, restricciones IP y autenticación multifactor.
• Filtra patrones sospechosos de user-agent y referer a nivel WAF.
• Usa CAPTCHA o mecanismos invisibles de validación de bots de forma equilibrada.
• Para APIs, implementa control con claves, firmas, cuotas y marcas de tiempo.

En la gestión de bots es vital no perjudicar la experiencia del usuario. CAPTCHA excesivos, bloqueos agresivos o filtros geográficos erróneos pueden afectar a clientes legítimos. La mejor práctica es medir, probar y endurecer gradualmente las reglas.

Monitoreo de Logs y Reglas de Alerta

Creer que la configuración terminó es un error común. El cortafuegos es un sistema vivo que requiere monitoreo constante. Revisa logs como auth.log o secure para intentos SSH, logs de acceso de nginx para picos anormales, logs de error para aumentos de 404 y 500 y métricas del sistema como CPU y conexiones activas. Una alerta sencilla puede ganar minutos valiosos ante un ataque.

Ejemplos de umbrales iniciales: más de 100 errores 404 desde la misma IP en 5 minutos, más de 20 intentos de login en 1 minuto, CPU por encima del 90% por 10 minutos, o un aumento de conexiones a 3 veces el promedio. Estos valores varían según el sitio, pero lo importante es conocer tu tráfico normal.

Errores Comunes y Cómo Evitarlos

• Activar el cortafuegos sin permitir SSH: Puede dejarte sin acceso remoto; siempre prueba con una segunda sesión abierta.
• Olvidar IPv6: Aunque cierres IPv4, IPv6 puede quedar abierto y exponer servicios.
• Dejar base de datos accesible desde internet: Puertos 3306, 5432, 6379, 9200 son escaneados constantemente por bots.
• Usar CDN y dejar la IP real del servidor expuesta: El atacante puede saltarse la CDN y atacar directo.
• Modificar reglas sin documentarlas: Hace difícil entender qué hace cada regla en emergencias.
• No planear acceso de respaldo: Sin consola o modo recuperación, resolver bloqueos puede tomar mucho tiempo.

Ejemplo Práctico de Política de Cortafuegos

Para una web corporativa pequeña, una política resumida puede ser: tráfico entrante denegado por defecto; puerto 443 abierto para todos; puerto 80 solo para redirección a HTTPS; SSH solo accesible vía VPN o IP fija de administrador; base de datos limitada a localhost o red privada; si se usa CDN, solo permitir IPs de CDN en puertos 80 y 443; Fail2ban monitorea SSH y logins web; logs diarios enviados a un sistema centralizado de monitoreo.

En un e-commerce mediano, además se permiten IPs específicas para callbacks de pago, el panel administrativo queda detrás de VPN, se aplican cuotas por usuario en la API, se activan reglas WAF para SQL Injection y XSS, y se planean filtros temporales por país o ASN. Esta planificación debe estar documentada, ya que en un ataque es mejor seguir un procedimiento predefinido que improvisar.

¿Cómo Probar que las Reglas Funcionan?

Después de configurar el cortafuegos, debes probarlo. Desde otra red, haz un escaneo de puertos, verifica que SSH solo funcione desde la IP permitida, que el sitio web sea accesible por HTTPS y que el puerto de la base de datos esté cerrado. Si usas CDN, intenta acceder directamente a la IP real con una solicitud HTTP para confirmar que está bloqueada.

Durante las pruebas evita escaneos agresivos que puedan afectar la producción. El objetivo es verificar seguridad sin dañar el sistema. Además, exporta o documenta las reglas tras cada cambio para poder revertir en caso de problema.

Plan de Mantenimiento y Actualización

La seguridad del servidor no es una tarea única, sino un proceso continuo. Cada vez que se añade un servicio, revisa qué puertos necesita; al eliminar servicios, borra permisos asociados; aplica actualizaciones de seguridad regularmente y revisa logs periódicamente. Una buena práctica es auditar puertos abiertos mensualmente y revisar las reglas del cortafuegos cada tres meses.

Además, un plan de respaldo forma parte de la estrategia de seguridad. Un ataque DDoS puede afectar el acceso, pero ransomware o accesos no autorizados pueden causar pérdida de datos. La seguridad debe contemplar hosting seguro, SSL, gestión de dominios y backups. En este sentido, los contenidos Aspectos a tener en cuenta al elegir hosting seguro y cómo se realiza la instalación del certificado SSL son recursos complementarios naturales.

Conclusión

Configurar un cortafuegos en el servidor no hace que sea completamente invisible ante ataques DDoS o bots, pero reduce significativamente la superficie de ataque, disminuye el riesgo de accesos no autorizados y permite una respuesta más controlada ante incidentes. La mejor protección se logra combinando la seguridad a nivel proveedor (DDoS), CDN/WAF, políticas estrictas de puertos, restricciones SSH, Fail2ban, limitación de tasa y monitoreo constante de logs.

Si estás lanzando un nuevo proyecto, planificar la política de cortafuegos desde el inicio es mucho más fácil que corregir después. Al evaluar servidores, hosting, dominios y SSL en Hostragons, considera también tus necesidades de seguridad para crear un entorno web robusto. Si deseas, empieza con esta sencilla lista de control: cierra puertos abiertos innecesarios, limita SSH, obliga HTTPS y monitorea logs.

Preguntas Frecuentes

¿El cortafuegos del servidor bloquea completamente los ataques DDoS?

No. El cortafuegos local puede mitigar ataques pequeños o ciertos ataques a nivel de protocolo, pero para ataques DDoS de gran volumen es necesario usar protección a nivel proveedor, CDN y WAF.

¿Qué puertos deben permanecer abiertos en un servidor web?

Normalmente los puertos 80 y 443 están abiertos. El puerto SSH debe permitir conexiones solo desde IPs administrativas. Los puertos de base de datos y servicios internos deben estar cerrados al exterior.

¿Debería usar UFW o firewalld?

Para Ubuntu y Debian, UFW es más sencillo para comenzar. En sistemas basados en AlmaLinux, Rocky Linux y RHEL, firewalld es estándar. Para escenarios avanzados o personalizados, nftables es una buena opción.

¿Puedo detener el tráfico de bots solo bloqueando IPs?

Generalmente no. Los bots modernos utilizan IPs variables y proxies. Además del bloqueo de IP, se deben usar limitaciones de tasa, reglas WAF, análisis de comportamiento, CAPTCHA y cuotas en la aplicación.

¿Cuál es el mayor riesgo al configurar el cortafuegos?

El riesgo más grande es bloquear tu propio acceso SSH por error. Por eso siempre define permisos para SSH primero, prueba con una segunda sesión y asegúrate de tener acceso a la consola del proveedor.