Hay una situación que se repite con frecuencia en los servicios de hosting.
Un cliente intenta ingresar a su página y no carga.
Prueba cPanel y tampoco responde.
Intenta abrir Webmail y ocurre lo mismo.
Pregunta a otras personas de su oficina y descubre que tampoco pueden acceder.
La conclusión parece evidente:
"Se cayó el hosting."
Sin embargo, desde un teléfono utilizando datos móviles la página abre normalmente. Desde otra ubicación también funciona.
El servidor nunca estuvo caído.
Lo que ocurrió es muy diferente.
La dirección IP desde la que esa oficina se conectaba había sido bloqueada temporalmente por uno de los sistemas de seguridad del servidor.
Cuando esto sucede, la primera reacción suele ser pedir:
"Desactiven eso porque nos perjudica el trabajo."
Comprendemos la molestia. Si varias personas necesitan correo, página web o panel de control y de pronto pierden acceso, el problema afecta su trabajo.
Pero retirar las protecciones que produjeron el bloqueo no suele ser la solución correcta.
Antes conviene entender para qué existen.
Si todas las computadoras fallan al mismo tiempo, no significa necesariamente que el servidor esté caído
Dentro de una oficina puede haber diez, veinte o cincuenta computadoras.
Cada una puede tener una dirección privada diferente dentro de la red.
Sin embargo, al conectarse a Internet es muy habitual que todas salgan utilizando una misma dirección IPv4 pública mediante una tecnología denominada NAT.
Cisco explica precisamente que NAT permite que múltiples dispositivos de una red compartan una única dirección IP pública para acceder a Internet.
Esto explica una situación que desconcierta a muchos usuarios.
Supongamos que una oficina tiene:
25 computadoras
8 teléfonos
varias cuentas de correo
una persona ingresando a cPanel
otra utilizando FTP
y todas las conexiones salen a Internet mediante la misma IP pública.
Para el servidor, muchas de esas conexiones tienen un origen común.
Si esa IP termina bloqueada a nivel del firewall, el problema no afecta únicamente a la computadora donde ocurrió originalmente el error.
Puede afectar a otros dispositivos que utilicen esa misma salida a Internet.
Por eso frases como:
"Pero no funciona en ninguna computadora de la oficina"
no descartan un bloqueo de IP.
En determinadas redes, precisamente eso es lo esperable.
Una prueba sencilla puede aclarar el problema en segundos
Cuando sospechamos que existe un bloqueo de IP, una de las primeras cosas que necesitamos conocer es la dirección pública desde la que el cliente se está conectando.
Para eso puede utilizarse:
https://www.esmidireccionip.com
La herramienta muestra de forma directa la dirección IP pública detectada para esa conexión.
El procedimiento es sencillo.
El cliente abre esmidireccionip.com desde la red donde existe el problema.
Copia la IP que aparece.
La envía al equipo de soporte.
Con ese dato podemos comprobar si esa dirección aparece bloqueada y, cuando corresponda, retirarla del bloqueo.
Es mucho más útil enviarnos la IP que decir únicamente:
"Mi web no abre."
Porque dos problemas que se ven exactamente iguales desde el navegador pueden tener causas completamente diferentes.
¿Qué es CSF?
CSF significa ConfigServer Security & Firewall.
Es una solución de firewall utilizada desde hace muchos años en servidores Linux y especialmente conocida en entornos de hosting.
En servidores cPanel permite administrar reglas de firewall que determinan qué conexiones se permiten y cuáles se rechazan. La documentación actual de cPanel lo describe como una herramienta de terceros que permite gestionar las reglas del firewall del servidor.
CSF trabaja además junto con otro componente denominado LFD.
LFD significa Login Failure Daemon.
Su función es especialmente relevante para entender muchos bloqueos que observan los clientes.
El sistema analiza continuamente registros del servidor buscando comportamientos compatibles con intentos de acceso no autorizados.
Por ejemplo, múltiples intentos fallidos de autenticación en un periodo corto.
La documentación histórica de CSF explica que LFD puede supervisar servicios frecuentemente atacados como SSH, POP3, IMAP, FTP y autenticaciones web. Cuando se alcanza el umbral configurado, puede utilizar CSF para bloquear la IP de origen.
En otras palabras, el servidor no está intentando perjudicar a un usuario legítimo.
Está reaccionando ante una conducta que, desde su punto de vista, también podría corresponder a un ataque.
El servidor no sabe automáticamente si fue un empleado o un atacante
Imaginemos una cuenta de correo:
La contraseña fue cambiada recientemente.
Una computadora sigue teniendo guardada la contraseña antigua.
Outlook intenta conectarse.
La contraseña falla.
Vuelve a intentarlo.
Otro teléfono tiene configurada la misma cuenta con la contraseña anterior.
También falla.
Una tercera aplicación intenta sincronizar.
Continúa fallando.
Para las personas de la oficina no está ocurriendo nada extraño.
Para un sistema de seguridad, en cambio, una misma IP está generando repetidamente autenticaciones incorrectas.
Ese patrón puede parecerse mucho al comportamiento de un programa intentando adivinar una contraseña.
El sistema tiene que tomar una decisión antes de saber quién está detrás de esa IP.
Y esa es precisamente la utilidad de estas protecciones.
¿Qué es la protección contra fuerza bruta?
Un ataque de fuerza bruta consiste básicamente en realizar numerosos intentos para descubrir una contraseña.
Los sistemas automatizados pueden probar combinaciones continuamente contra paneles, correo, FTP, SSH y otros servicios expuestos a Internet.
cPanel incluye su propia protección denominada cPHulk Brute Force Protection.
Según la documentación oficial de cPanel, cPHulk supervisa accesos a servicios como cPanel, WHM, correo mediante Dovecot y Exim, FTP y SSH. Puede controlar tanto intentos asociados a una cuenta como intentos procedentes de una dirección IP determinada.
cPanel recomienda mantener habilitada esta protección dentro de sus configuraciones de seguridad recomendadas.
Esto explica por qué deshabilitar completamente una protección de fuerza bruta para evitar alguna molestia ocasional no suele ser una buena decisión.
Eliminaríamos también la defensa contra los intentos reales.
Un bloqueo puede originarse simplemente por una contraseña equivocada
No todos los bloqueos significan que alguien estaba atacando deliberadamente el servidor.
La propia documentación de cPanel indica que sus reportes de cPHulk pueden registrar intentos fallidos cuando, por ejemplo, un usuario introduce incorrectamente la contraseña de su cuenta.
Esto es importante.
Un bloqueo legítimo puede tener un origen inocente.
Una contraseña antigua almacenada en Outlook.
Un teléfono que sigue intentando sincronizar.
Una aplicación de correo mal configurada.
Una contraseña escrita varias veces incorrectamente.
Un FTP intentando reconectarse automáticamente.
Una computadora antigua que nadie recordó actualizar.
Por eso desbloquear la IP puede restaurar inmediatamente el acceso, pero no necesariamente resuelve la causa.
Si el programa continúa enviando la contraseña incorrecta, es posible que vuelva a producirse otro bloqueo.
¿Entonces por qué soporte pregunta qué estaba haciendo cuando ocurrió?
No se trata de complicar una solución sencilla.
La pregunta ayuda a encontrar el origen.
Si simplemente eliminamos un bloqueo y no averiguamos qué lo provocó, podemos resolver el síntoma durante diez minutos y volver a recibir exactamente el mismo reporte después.
Por eso, si un cliente quiere conocer la causa, conviene proporcionar información útil.
Por ejemplo:
qué estaba intentando abrir
si acababa de cambiar alguna contraseña
si configuró una nueva cuenta de correo
si estaba utilizando FTP
si el problema comenzó después de varios intentos fallidos
si algún programa estaba intentando conectarse automáticamente
si todo empezó después de modificar un sitio web
Con esa información, los registros del servidor pueden tener mucho más sentido.
Investigar también consume tiempo técnico
Existe aquí un punto que conviene explicar con transparencia.
Desbloquear una IP identificada puede ser una operación bastante rápida.
Investigar exactamente por qué fue bloqueada puede requerir revisar logs, horarios, servicios, intentos de autenticación, reglas y eventos relacionados.
Eso constituye trabajo técnico.
Si se solicita esa investigación, lo ideal es utilizar el resultado para corregir la causa.
Si encontramos que una computadora conserva una contraseña antigua, debe corregirse.
Si existe una cuenta configurada incorrectamente, hay que repararla.
Si detectamos un plugin generando peticiones problemáticas, debe revisarse.
Si encontramos intentos de acceso que el cliente no reconoce, habrá que investigar seguridad.
Pedir una investigación detallada para posteriormente ignorar el hallazgo no mejora la seguridad.
Ese mismo tiempo técnico podría utilizarse en tareas preventivas.
La finalidad de investigar no es únicamente saber qué ocurrió.
Es evitar que vuelva a ocurrir.
¿Qué es ModSecurity?
ModSecurity cumple una función diferente.
Es un firewall de aplicaciones web.
En lugar de vigilar principalmente intentos de inicio de sesión a servicios del servidor, analiza las peticiones HTTP que llegan a una web.
cPanel recomienda habilitar ModSecurity para los dominios y advierte que debería desactivarse únicamente mientras se diagnostica un problema relacionado con sus reglas.
En servidores cPanel puede utilizarse junto con OWASP Core Rule Set.
cPanel explica que estas reglas añaden una capa de protección para aplicaciones web como WordPress y pueden incluso ayudar a bloquear intentos que aprovechen vulnerabilidades de aplicaciones desactualizadas.
Esto es especialmente importante en hosting compartido.
El servidor aloja páginas desarrolladas con tecnologías diferentes.
WordPress.
Joomla.
PrestaShop.
Aplicaciones PHP.
Desarrollos propios.
Cada una puede contener errores o vulnerabilidades.
ModSecurity intenta reconocer patrones peligrosos antes de que determinadas solicitudes lleguen a ejecutarse dentro de la aplicación.
ModSecurity no es exactamente lo mismo que bloquear la IP completa
Esta diferencia merece atención.
Una regla de ModSecurity puede rechazar una solicitud web concreta.
El usuario podría recibir, por ejemplo, un error 403 cuando intenta ejecutar una acción que coincide con una regla de seguridad.
Eso no significa necesariamente que su dirección IP haya quedado completamente bloqueada en el firewall.
Sin embargo, CSF/LFD puede configurarse para observar también eventos generados por ModSecurity.
El código mantenido actualmente para CSF contempla específicamente registros y disparadores LF_MODSEC.
En una configuración que relacione ambos sistemas, repetidas detecciones pueden terminar contribuyendo a un bloqueo de IP.
Por eso soporte debe determinar primero qué capa produjo el problema.
No todos los errores 403 son iguales.
Y no todos los bloqueos proceden del mismo sistema.
¿Puede ModSecurity equivocarse?
Sí.
Un sistema de reglas intenta diferenciar tráfico legítimo de tráfico malicioso utilizando patrones.
Eso significa que pueden existir falsos positivos.
Una petición perfectamente legítima puede parecer peligrosa debido a determinados parámetros, código enviado desde un formulario, contenido de una petición o comportamiento de una aplicación.
Eso no significa que la mejor solución sea desactivar ModSecurity completamente.
La propia documentación de cPanel recomienda mantenerlo habilitado y desactivarlo solamente mientras se diagnostican problemas relacionados con sus reglas.
Cuando existe un falso positivo, la solución profesional suele consistir en identificar la regla específica, analizar la petición y aplicar una excepción controlada cuando realmente corresponda.
Desactivar toda la protección porque una regla necesita ajustarse es parecido a retirar la puerta de una casa porque una cerradura necesita mantenimiento.
¿Por qué no simplemente colocamos todas las IP de clientes en una lista blanca?
Porque eso también tiene consecuencias.
Las listas blancas hacen que determinadas protecciones ignoren una IP considerada confiable.
cPanel permite añadir direcciones a la lista blanca de cPHulk y recomienda especialmente hacerlo para accesos administrativos propios que necesitan evitar un bloqueo accidental.
Pero aplicar listas blancas indiscriminadamente a cualquier dirección tiene riesgos.
Una IP puede cambiar.
Puede pertenecer a una conexión residencial.
Puede estar detrás de CGNAT.
Cisco explica que con CGNAT incluso diferentes clientes de un proveedor de Internet pueden compartir una dirección IPv4 pública.
Además, una computadora dentro de una red confiable también puede verse comprometida.
Por eso permitir permanentemente una IP debe ser una decisión consciente y no la respuesta automática a cualquier bloqueo.
En muchos casos basta con retirar el bloqueo temporal y corregir aquello que lo provocó.
Mi página abre utilizando datos móviles pero no desde la oficina
Esta es una prueba especialmente útil.
Si desde el Wi-Fi de la oficina no puede acceder:
a la página
a cPanel
a Webmail
o a otros servicios del mismo servidor
pero desconecta el Wi-Fi del teléfono, activa los datos móviles y todo comienza a funcionar, existe una señal bastante fuerte de que debemos revisar la IP pública de la red de la oficina.
No demuestra por sí sola que exista un bloqueo.
Pero es una prueba excelente para orientar el diagnóstico.
En ese momento visite:
https://www.esmidireccionip.com
Copie la dirección que muestra la herramienta y envíela a soporte.
El equipo técnico podrá contrastarla con los sistemas de seguridad.
"Pero Internet funciona"
Eso también es totalmente posible.
Un bloqueo en el firewall del servidor de hosting no significa que su proveedor de Internet haya dejado de funcionar.
Puede seguir entrando a Google.
Puede utilizar WhatsApp.
Puede ver videos.
Puede visitar cualquier otro sitio.
Simplemente esa IP no puede comunicarse normalmente con determinados servicios del servidor que la bloqueó.
Por eso desde el punto de vista del cliente parece que "solo se cayó mi página".
Desde otro lugar, la web continúa funcionando.
"En otras empresas de hosting nunca me ocurre"
También puede suceder.
No todos los proveedores utilizan las mismas herramientas.
No todos configuran los mismos umbrales.
No todos aplican las mismas reglas.
Y no todos ofrecen el mismo nivel de protección.
Que un servidor nunca bloquee una IP no demuestra por sí mismo que sea mejor.
Del mismo modo, que un sistema de seguridad genere falsos positivos continuamente tampoco sería deseable.
La configuración debe buscar equilibrio.
Protección suficiente para detener ataques reales.
Y procedimientos razonables para resolver rápidamente bloqueos legítimos.
Seguridad y comodidad necesitan equilibrio
Existe una tensión natural.
Cuantas menos restricciones tiene un sistema, menos probable es que un usuario legítimo encuentre obstáculos.
Pero también puede resultar más sencillo atacar.
Cuanto más agresivas sean las protecciones, más ataques pueden detenerse, pero aumentará el riesgo de falsos positivos.
La solución profesional no está en ninguno de los extremos.
No consiste en bloquear a todos.
Tampoco en desactivar todas las defensas.
Consiste en configurar correctamente, monitorizar, revisar falsos positivos y corregir las causas legítimas que producen bloqueos.
Qué debe hacer si sospecha que su IP fue bloqueada
No necesita conocer CSF, ModSecurity ni cPHulk para solicitar ayuda correctamente.
Primero compruebe si el sitio funciona desde otra conexión.
Puede utilizar los datos móviles del teléfono, evitando el Wi-Fi de la misma red afectada.
Si desde allí funciona, visite desde la conexión con problemas:
https://www.esmidireccionip.com
Copie la IP pública mostrada.
Después envíe al equipo de soporte:
la IP
el dominio afectado
qué servicio no puede abrir
aproximadamente a qué hora comenzó
y cualquier actividad previa que considere relevante
Con esos datos el diagnóstico será mucho más rápido.
Después de desbloquear, hay otra pregunta que vale la pena hacer
"¿Por qué ocurrió?"
No siempre necesitaremos una investigación exhaustiva.
Puede haber un motivo evidente y basta con corregirlo.
Pero si los bloqueos se repiten, investigar deja de ser opcional.
Tal vez una computadora siga intentando utilizar una contraseña anterior.
Tal vez una cuenta tenga las credenciales mal configuradas.
Tal vez una aplicación web esté provocando repetidamente una regla.
Tal vez haya intentos que nadie de la empresa reconoce.
Ese último escenario es especialmente importante.
Un bloqueo que inicialmente parece molesto puede ser la primera señal de que una contraseña ha sido comprometida o que alguien está intentando entrar.
Las protecciones que a veces incomodan también están trabajando cuando usted no las ve
La mayor parte del tiempo un firewall hace su trabajo en silencio.
El cliente solamente suele recordar que existe cuando bloquea algo legítimo.
Pero durante el resto del día puede estar rechazando conexiones que nunca llegan a convertirse en un problema visible.
cPanel recomienda mantener activa su protección contra fuerza bruta.
También recomienda mantener ModSecurity habilitado para los dominios.
Y el funcionamiento de CSF/LFD está precisamente diseñado para detectar comportamientos sospechosos y bloquear direcciones cuando se alcanzan determinados umbrales.
Por eso nuestra respuesta ante un falso positivo no debería ser:
"Eliminemos la seguridad."
Debería ser:
"Identifiquemos qué protección actuó, desbloqueemos lo legítimo y averigüemos si existe algo que debemos corregir."
Una IP bloqueada no significa necesariamente una falla del hosting
Para el usuario, la diferencia puede parecer pequeña.
Si no puede abrir la página, siente que la página está caída.
Es comprensible.
Pero técnicamente son situaciones diferentes.
Una caída real puede afectar a todos los visitantes.
Un bloqueo de una IP puede afectar solamente a una empresa, una vivienda, una conexión o un determinado origen.
Incluso puede afectar a toda una oficina porque todos sus equipos comparten la misma IP pública.
Comprender esa diferencia permite resolver el problema mucho más rápido.
Y también evita retirar protecciones que están allí por una razón.
La próxima vez que desde su red deje de poder abrir su web, cPanel o Webmail, mientras desde otra conexión funciona normalmente, no necesita adivinar.
Entre a cuál es mi direcciónn ip esmidireccionip.com, copie su IP y envíela al equipo de soporte.
Podemos desbloquear una conexión legítima.
Y cuando el caso lo requiera, también podemos investigar qué produjo el bloqueo.
Porque una buena seguridad no consiste en impedir trabajar al usuario.
Consiste en permitir el tráfico legítimo, detener el peligroso y aprender a distinguir correctamente entre ambos.