Cómo Configurar un Firewall para su Hosting cPanel

Asegurar un servidor cPanel sin un firewall correctamente configurado es como dejar la puerta principal de un centro de datos sin llave. ConfigServer Security & Firewall (CSF) es el estándar de facto para endurecer los entornos cPanel y WHM — se integra directamente en la interfaz de WHM, se envuelve alrededor de iptables (o nftables en kernels más nuevos), y viene con un daemon complementario llamado Login Failure Daemon (LFD) que gestiona la detección de intrusiones en tiempo real. Esta guía recorre un despliegue completo de CSF de nivel productivo: instalación, arquitectura de reglas, mitigación avanzada de amenazas y un flujo de trabajo de mantenimiento continuo.

Ya sea que esté ejecutando un VPS con cPanel o un Servidor Dedicado completo, los principios de configuración son idénticos. La diferencia es que en una máquina dedicada tiene acceso exclusivo al kernel, lo que significa que las funciones de seguimiento de conexiones más agresivas de CSF y la protección contra inundaciones SYN pueden ser llevadas más lejos sin afectar a los inquilinos vecinos.

Por qué un Firewall de Software No es Opcional en Servidores cPanel

cPanel expone una gran superficie de ataque por diseño. Una instalación predeterminada abre docenas de puertos de servicio — WHM (2086/2087), cPanel (2082/2083), FTP (21), envío de correo (587), IMAP (993), POP3 (995), y más. Cada puerto abierto es un vector de entrada potencial. Sin un filtro de paquetes con estado frente a estos servicios:

• Los ataques de fuerza bruta contra SSH, FTP y webmail tienen éxito silenciosamente
• Los bots de relleno de credenciales golpean los endpoints xmlapi y cpsrvd
• El tráfico DDoS basado en amplificación satura la NIC antes de que la capa de aplicación pueda responder
• Las cuentas de hosting compartido comprometidas pueden pivotar lateralmente por el servidor

Un firewall de hardware en el perímetro de la red ayuda, pero no puede ver el contexto de la capa de aplicación — no sabe que una IP ha fallado 20 inicios de sesión IMAP consecutivos en 60 segundos. CSF + LFD opera a nivel de host y reacciona exactamente a ese tipo de señal de comportamiento.

CSF vs. Otras Opciones de Firewall para cPanel

CSF gana en todos los aspectos que importan para un entorno cPanel. La única razón para elegir firewalld o ufw es si está ejecutando una pila sin cPanel y prefiere una herramienta más ligera.

Paso 1: Lista de Verificación Previa a la Instalación

Antes de ejecutar un solo comando, complete estas verificaciones. Omitirlas es cómo los administradores accidentalmente se bloquean a sí mismos fuera de los servidores de producción.

Verifique su acceso fuera de banda. Confirme que tiene acceso a la consola de su proveedor de hosting (KVM over IP, IPMI, o una consola VNC basada en web). Si CSF bloquea su IP durante las pruebas, el acceso a la consola es su vía de recuperación.

Registre su dirección IP de administración. Ejecute lo siguiente desde su máquina local:

curl -4 ifconfig.me

Incluirá esta IP en la lista blanca de CSF antes de habilitar el modo de aplicación.

Verifique el estado actual de iptables:

iptables -L -n --line-numbers

Si otra herramienta de firewall (APF, firewalld) ya está activa, deténgala y deshabilítela antes de instalar CSF para evitar conflictos de reglas.

Confirme que Perl está instalado (CSF está basado en Perl):

perl -v

En un sistema CentOS/AlmaLinux/CloudLinux nuevo, Perl está presente de forma predeterminada. En compilaciones mínimas de Ubuntu, instálelo con apt install perl.

Paso 2: Instalar CSF en su Servidor cPanel

Conéctese a su servidor como root a través de SSH:

ssh root@YOUR_SERVER_IP

Descargue, extraiga y ejecute el instalador:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

El instalador registra CSF como un servicio del sistema, instala el plugin de WHM y coloca el archivo de configuración principal en /etc/csf/csf.conf.

Ejecute la verificación de dependencias integrada para confirmar que todos los módulos Perl requeridos están presentes:

perl /usr/local/csf/bin/csftest.pl

Cualquier línea marcada como FATAL debe resolverse antes de continuar. Las líneas marcadas como WARN son características opcionales — revíselas, pero no impedirán que CSF funcione.

Verifique la versión instalada:

csf -v

Paso 3: Configuración Principal en /etc/csf/csf.conf

Abra el archivo de configuración principal en su editor preferido:

nano /etc/csf/csf.conf

El archivo tiene abundantes comentarios. Las siguientes directivas tienen el mayor impacto en la seguridad y deben revisarse en cada nuevo despliegue.

Modo de Prueba

Cuando CSF se instala por primera vez, TESTING = "1" está configurado de forma predeterminada. En este modo, LFD no se inicia y no se aplican bloqueos — las reglas se cargan pero son temporales. No deshabilite el modo de prueba hasta que haya incluido su IP de administración en la lista blanca y validado todas las reglas de puertos.

TESTING = "0"   # Set this only after full validation

Listas de Puertos Permitidos de Entrada y Salida

TCP_IN y TCP_OUT definen qué puertos TCP están permitidos en cada dirección. Un servidor cPanel mínimo pero funcional necesita:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

Nota operativa crítica: El puerto 2087 es WHM SSL. El puerto 2083 es cPanel SSL. Si los elimina de TCP_IN antes de incluir su IP en la lista blanca, perderá acceso al panel de control inmediatamente. El puerto 123 (UDP saliente) es NTP — eliminarlo rompe la sincronización de tiempo, lo que se traduce en fallos de validación de certificados SSL y rechazos de entrega de correo.

Cierre todos los puertos que no estén en uso activo. Ejecute ss -tlnp para auditar qué está escuchando realmente antes de finalizar esta lista.

Inclusión de su IP de Administración en la Lista Blanca

Agregue su IP a /etc/csf/csf.allow antes de deshabilitar el modo de prueba:

echo "YOUR.MANAGEMENT.IP # My office IP" >> /etc/csf/csf.allow

Alternativamente, use el comando CSF directamente:

csf -a YOUR.MANAGEMENT.IP "Management workstation"

Las IPs en la lista blanca omiten todos los bloqueos de LFD y todas las reglas de limitación de velocidad. Mantenga esta lista al mínimo — cada entrada es una excepción permanente a su política de seguridad.

Bloqueo de IPs Maliciosas Conocidas

Los bloqueos permanentes van en /etc/csf/csf.deny:

csf -d MALICIOUS.IP.ADDRESS "Confirmed scanner"

Para importaciones masivas desde fuentes de inteligencia de amenazas (Spamhaus DROP, Emerging Threats, etc.), agregue CIDRs directamente a /etc/csf/csf.deny y recargue:

csf -r

Paso 4: Configurar el Login Failure Daemon (LFD)

LFD es el componente de detección de intrusiones de comportamiento de CSF. Monitorea los archivos de registro del sistema en tiempo real, cuenta los fallos de autenticación por IP de origen y activa un bloqueo temporal cuando se supera un umbral. Esta es su principal defensa contra los ataques de fuerza bruta de credenciales.

Directivas clave de LFD en csf.conf:

Caso límite a tener en cuenta: Si su servidor está detrás de una puerta de enlace NAT o un router de oficina compartido, múltiples usuarios legítimos comparten una IP externa. Establecer LF_TRIGGER demasiado bajo bloqueará toda su oficina después de algunos errores tipográficos. Aumente el umbral o incluya la IP de la oficina en la lista blanca en csf.allow.

LFD también monitorea procesos sospechosos, eventos de vigilancia de directorios y detección de cambios en archivos (las características LF_DIRWATCH y LF_INTEGRITY). Habilite LF_INTEGRITY para detectar modificaciones no autorizadas en los binarios del sistema:

LF_INTEGRITY = "3600"   # Check every hour

Paso 5: Funciones Avanzadas de Mitigación de Amenazas

Protección contra Inundaciones SYN

Los ataques de inundación SYN agotan la tabla de conexiones TCP enviando grandes volúmenes de paquetes SYN sin completar el protocolo de enlace. Habilite la mitigación integrada de CSF:

SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Estos valores permiten 100 nuevos paquetes SYN por segundo con una tolerancia de ráfaga de 150 antes de que se active la regla. Ajuste estos números según su tráfico legítimo máximo — un sitio de comercio electrónico durante una venta flash puede necesitar valores de ráfaga más altos.

Seguimiento de Conexiones

El seguimiento de conexiones limita el número total de conexiones simultáneas desde una única IP en todos los puertos. Esto es efectivo contra ataques DDoS de baja velocidad y el agotamiento de conexiones:

CT_LIMIT = "300"
CT_INTERVAL = "30"
CT_BLOCK_TIME = "1800"
CT_SKIP_LOCAL = "1"

CT_SKIP_LOCAL evita que las conexiones de localhost y loopback cuenten hacia el límite — esencial en servidores donde los daemons de cPanel se comunican internamente a través de TCP.

Detección de Escaneo de Puertos

CSF puede detectar y bloquear hosts que sondean múltiples puertos en una ventana corta:

PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_BLOCK_TIME = "3600"
PS_PERMANENT = "0"

Una IP que accede a 10 o más puertos cerrados en 300 segundos queda bloqueada durante una hora. Establezca PS_PERMANENT = "1" solo si está seguro de que sus usuarios legítimos nunca activarán esto accidentalmente — algunos clientes de correo y herramientas de monitoreo sondean múltiples puertos durante la negociación de conexión.

Bloqueo a Nivel de País

Si su aplicación no tiene usuarios legítimos en ciertas regiones de alto riesgo, bloquear a nivel de país reduce drásticamente el ruido en sus registros y la carga de trabajo de LFD. Edite csf.conf:

CC_DENY = "CN,RU,KP,NG"
CC_ALLOW = ""

Los códigos de país siguen el estándar ISO 3166-1 alfa-2. CSF descarga datos GeoIP automáticamente. Sea preciso aquí — bloquear países enteros es un instrumento contundente. Un mejor enfoque para la mayoría de los despliegues es CC_ALLOW (incluir en la lista blanca solo los países donde se encuentran sus usuarios) combinado con CC_ALLOW_PORTS para restringir el acceso basado en países solo a puertos específicos.

Restricciones SMTP de Salida

Las instalaciones de WordPress comprometidas y los scripts vulnerables se utilizan frecuentemente como relés de spam. CSF puede restringir el SMTP saliente solo a procesos de correo autorizados:

SMTP_BLOCK = "1"
SMTP_ALLOWUSER = "mailman"
SMTP_ALLOWGROUP = "mail"

Esto bloquea todas las conexiones salientes en el puerto 25 excepto las de procesos que se ejecutan como el usuario o grupo especificado. La entrega de correo legítima a través de su MTA (Exim en cPanel) no se ve afectada porque Exim se ejecuta como el grupo mail. Esta única directiva elimina toda una clase de abuso de spam por cuentas comprometidas.

Si necesita infraestructura de correo saliente de nivel profesional junto con su hosting, considere combinar su servidor con una solución dedicada de Hosting de Correo Electrónico para correo transaccional y de marketing.

Paso 6: Aplicar y Probar la Configuración

Una vez que haya revisado todas las directivas, recargue CSF para aplicar los cambios sin un reinicio completo:

csf -r

Para reiniciar completamente tanto CSF como LFD:

csf -ra

Verifique el estado actual y el recuento de reglas activas:

csf -l

Verifique que LFD está en ejecución:

systemctl status lfd

Pruebe desde una IP externa (no su IP de administración incluida en la lista blanca) que el bloqueo de puertos funciona como se espera. Use nmap desde una máquina separada:

nmap -sS -p 1-65535 YOUR_SERVER_IP

Solo los puertos explícitamente listados en TCP_IN deben aparecer como abiertos. Todos los demás deben devolver filtered.

Deshabilite el modo de prueba solo después de que esta validación sea exitosa:

# In /etc/csf/csf.conf, set TESTING = "0", then:
csf -r

Paso 7: Configuración de la GUI de WHM

Para los administradores que prefieren una interfaz gráfica, CSF se integra completamente en WHM. Navegue a WHM > Plugins > ConfigServer Security & Firewall. Desde aquí puede:

• Ver la lista de bloqueos en vivo y desbloquear IPs manualmente
• Agregar entradas temporales y permanentes de permitir/denegar
• Activar una verificación de configuración que valida la sintaxis de csf.conf
• Ver los registros de LFD en una interfaz paginada y con búsqueda
• Ejecutar la herramienta de sincronización de clúster si gestiona múltiples servidores

La interfaz de WHM es particularmente útil para el personal de soporte que necesita desbloquear la IP de un cliente legítimo sin acceso SSH. Otorgue acceso al plugin CSF a las cuentas de revendedor de WHM de forma selectiva — no todos los revendedores necesitan capacidad de gestión del firewall.

Paso 8: Monitoreo, Análisis de Registros y Mantenimiento

Monitoreo de Registros en Tiempo Real

LFD escribe eventos de bloqueo en /var/log/lfd.log. Monitoréelo durante un incidente activo:

tail -f /var/log/lfd.log

El registro de actividad propio de CSF está en /var/log/csf.log. Para un resumen de las IPs bloqueadas con más frecuencia en las últimas 24 horas:

grep "Blocked" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Alertas por Correo Electrónico

Configure LFD para enviar alertas a su dirección administrativa:

LF_ALERT_TO = "admin@yourdomain.com"
LF_ALERT_FROM = "lfd@yourdomain.com"

Habilite tipos de alerta específicos:

LF_EMAIL_ALERT = "1"      # Block alerts
LT_EMAIL_ALERT = "1"      # Login tracking alerts
RT_EMAIL_ALERT = "1"      # Resource usage alerts

Evite habilitar todos los tipos de alerta en un servidor ocupado — la fatiga de alertas hace que los administradores comiencen a ignorar las notificaciones, lo que anula completamente el propósito.

Actualización de CSF

CSF publica actualizaciones con frecuencia. Ejecute el actualizador integrado:

csf -u

Esto descarga la última versión, conserva sus archivos de configuración y reinicia el servicio. Programe esto en un trabajo cron semanal:

0 3 * * 0 /usr/sbin/csf -u >> /var/log/csf_update.log 2>&1

Integración con cPHulk

cPanel viene con su propia herramienta de protección contra fuerza bruta llamada cPHulk. Ejecutar tanto cPHulk como LFD simultáneamente crea bloqueos redundantes y puede causar confusión durante la respuesta a incidentes. El enfoque recomendado: deshabilite cPHulk y confíe exclusivamente en LFD, que es más configurable y se integra con la lista de bloqueos unificada de CSF.

Deshabilite cPHulk a través de WHM en Security Center > cPHulk Brute Force Protection.

Arquitectura de Firewall para Entornos Multi-Servidor

Si gestiona múltiples servidores cPanel — un patrón común con clústeres de Hosting VPS o un servidor web principal combinado con un servidor de base de datos separado — la función de sincronización de clúster de CSF le permite propagar listas de bloqueos en todos los nodos simultáneamente.

Configure los miembros del clúster en /etc/csf/csf.conf:

CLUSTER_MASTER = "PRIMARY_SERVER_IP"
CLUSTER_SENDTO = "SECONDARY_SERVER_IP"
CLUSTER_RECVFROM = "PRIMARY_SERVER_IP"
CLUSTER_KEY = "your_shared_secret_key"

Cuando LFD bloquea una IP en el servidor principal, el bloqueo se propaga automáticamente a todos los miembros del clúster en segundos. Esto es particularmente valioso cuando un escáner que sondea su servidor web también intenta fuerza bruta SSH en su nodo de base de datos.

Para entornos de alto tráfico o cargas de trabajo intensivas en GPU que se ejecutan junto con servicios web, la infraestructura de Hosting GPU se beneficia del mismo enfoque de endurecimiento con CSF — la configuración del firewall es idéntica, pero los valores de CT_LIMIT generalmente necesitan ser más altos para acomodar conexiones API paralelas legítimas.

Consideraciones de Seguridad SSL y de Puertos

Un firewall controla el acceso a los puertos, pero no valida la integridad criptográfica de las conexiones en esos puertos. Asegúrese de que cada servicio expuesto a través de sus reglas de firewall también esté protegido con un certificado SSL/TLS válido. Un puerto 443 abierto con un certificado expirado o autofirmado es un riesgo de phishing y MITM.

Combine su configuración de firewall con certificados emitidos correctamente por una CA de confianza. AlexHost proporciona Certificados SSL que se integran directamente con el flujo de trabajo AutoSSL de cPanel, garantizando que sus endpoints HTTPS expuestos sean criptográficamente seguros.

Errores Comunes y Cómo Evitarlos

Bloquearse a sí mismo durante la configuración inicial. Siempre incluya su IP en la lista blanca en csf.allow antes de establecer TESTING = "0". Siempre confirme el acceso a la consola antes de realizar cambios de aplicación.

Bloquear los propios servicios internos de cPanel. Los daemons de cPanel se comunican a través de localhost y a veces a través de la IP principal del servidor. CT_SKIP_LOCAL = "1" y una revisión cuidadosa de TCP_OUT evitan interrupciones de servicio autoinfligidas.

LF_DURATION demasiado agresivo en hosting compartido. Si usuarios legítimos comparten una IP NAT con atacantes, un bloqueo de 24 horas perjudica a clientes inocentes. Use LF_DURATION = "3600" y LF_PERMBLOCK_COUNT = "4" para escalar solo a los reincidentes a prohibiciones permanentes.

Olvidar abrir los puertos del agente de monitoreo. Si usa un servicio de monitoreo externo (Zabbix, Nagios, Datadog), su agente requiere un puerto de entrada abierto. Agréguelo a TCP_IN e incluya la IP del servidor de monitoreo en la lista blanca en csf.allow.

No probar las reglas de salida. Los administradores se centran en TCP_IN de entrada pero descuidan TCP_OUT. Las reglas de salida demasiado restrictivas rompen el sistema de actualización de cPanel, las renovaciones de certificados Let’s Encrypt (puerto 80 de salida hacia servidores ACME) y las conexiones remotas a MySQL.

Ejecutar CSF en un servidor con proxy de Cloudflare. Cuando el tráfico pasa a través de Cloudflare, la IP de origen que ve CSF es una IP de nodo perimetral de Cloudflare, no la IP real del visitante. Bloquear una IP de Cloudflare bloquea todo el tráfico a través de ese nodo perimetral. Use el archivo csf.allow para incluir en la lista blanca los rangos de IP publicados de Cloudflare y configure su aplicación para leer el encabezado CF-Connecting-IP para las IPs reales de los visitantes.

Matriz de Decisión Técnica: Elección de su Perfil de Configuración CSF

Puntos Clave: Lista de Verificación de Preparación para Producción

Antes de considerar su despliegue de CSF listo para producción, verifique cada elemento a continuación:

• La IP de administración está presente en /etc/csf/csf.allow y confirmada con csf -g YOUR.IP

TESTING = "0" está configurado y csf -r ha sido ejecutado
TCP_IN contiene solo puertos con servicios activos e intencionales — verificados con ss -tlnp

SMTP_BLOCK = "1" está habilitado a menos que el servidor sea un relé de correo dedicado
LFD está en ejecución — confirmado con systemctl status lfd

LF_PERMBLOCK_COUNT y LF_PERMBLOCK_INTERVAL están configurados para escalar a los reincidentes
CT_LIMIT está configurado y ajustado a sus conexiones simultáneas máximas esperadas
SYNFLOOD = "1" está habilitado con valores de velocidad apropiados para su volumen de tráfico
Las alertas por correo electrónico están configuradas y se ha recibido una alerta de prueba
cPHulk está deshabilitado en WHM para evitar conflictos con LFD
Un trabajo cron semanal de csf -u está programado
El acceso a la consola/IPMI ha sido probado independientemente de SSH
Las reglas de puertos de salida (TCP_OUT) han sido validadas — las actualizaciones de cPanel, Let’s Encrypt y NTP funcionan correctamente
Si usa Cloudflare, los rangos de IP de Cloudflare están incluidos en la lista blanca en csf.allow

Preguntas Frecuentes

¿Cuál es la diferencia entre CSF y un firewall de hardware, y necesito ambos?

Un firewall de hardware opera en el perímetro de la red y filtra el tráfico antes de que llegue a la NIC de su servidor. CSF opera a nivel del sistema operativo y agrega detección de comportamiento con conciencia de aplicación que los firewalls de hardware no pueden proporcionar — como bloquear una IP después de repetidos fallos de inicio de sesión en cPanel. En un entorno de producción, ambas capas son complementarias. El filtrado de hardware reduce la carga de DDoS volumétrico; CSF gestiona los intentos de intrusión dirigidos.

¿Cómo desbloqueo una IP que CSF ha prohibido permanentemente?

Ejecute csf -dr BLOCKED.IP.ADDRESS para eliminarla de la lista de denegación, luego csf -r para recargar las reglas. Alternativamente, use la interfaz del plugin CSF de WHM en “Desbloquear una IP”. Para evitar el rebloqueo, agregue la IP a csf.allow con csf -a IP.ADDRESS "reason".

¿Interferirá CSF con las renovaciones de certificados Let’s Encrypt / AutoSSL?

Solo si el puerto 80 de salida está bloqueado en TCP_OUT o si las IPs del servidor de validación de Let’s Encrypt están inadvertidamente en csf.deny. Asegúrese de que el puerto 80 esté en TCP_IN (para respuestas al desafío HTTP-01) y en TCP_OUT (para la comunicación con el servidor ACME). Si las renovaciones fallan después de la instalación de CSF, verifique csf.deny para cualquier rango de IP de Let’s Encrypt y revise /var/log/lfd.log para conexiones de salida bloqueadas.

¿Cómo pruebo de forma segura una nueva regla de CSF sin arriesgarme a un bloqueo?

Vuelva a habilitar temporalmente el modo de prueba estableciendo TESTING = "1" en csf.conf y ejecutando csf -r. En modo de prueba, las reglas se cargan pero no se aplican, y LFD no se inicia. Valide sus cambios, luego establezca TESTING = "0" y recargue. Siempre confirme el acceso a la consola antes de volver al modo de aplicación.

¿Protege CSF contra ataques de capa de aplicación como inyección SQL o XSS?

No. CSF opera en las capas de red y transporte (L3/L4) y no tiene visibilidad sobre las cargas útiles de las solicitudes HTTP. Los ataques de capa de aplicación requieren un Firewall de Aplicaciones Web (WAF) como ModSecurity con el Conjunto de Reglas Básicas de OWASP, que se integra con Apache y Nginx en servidores cPanel. CSF y ModSecurity son complementarios — CSF gestiona las amenazas a nivel de red mientras que ModSecurity gestiona los ataques a nivel HTTP. LFD puede configurarse para bloquear IPs que activen repetidamente las reglas de ModSecurity a través de la directiva LF_MODSEC.