Cuando alguien dice "mi hosting tiene firewall", casi siempre está hablando de dos cosas muy distintas sin saberlo. Una es el firewall de red, que existe desde siempre y decide qué puertos están abiertos. La otra es el WAF, un firewall de aplicaciones web, que lee el contenido de cada pedido que llega a tu sitio y decide si tiene pinta de ataque. Son capas diferentes, resuelven problemas diferentes, y confundirlas te deja creyendo que estás protegido cuando no lo estás.
El firewall de toda la vida y sus límites
Un firewall de red trabaja a nivel de puertos y direcciones. Su trabajo es decir "el puerto 3306 de MySQL no se abre al mundo, solo al propio servidor" o "esta IP que intentó conectarse doscientas veces en un minuto queda bloqueada". Es imprescindible y todo hosting serio lo tiene.
El problema es que ese firewall no entiende qué es una página web. Para él, alguien que visita tu formulario de contacto y alguien que le manda a ese mismo formulario un texto diseñado para robarte la base de datos son exactamente lo mismo: tráfico legítimo entrando por el puerto 443. Los dos llegan por la puerta correcta, con el protocolo correcto. El firewall de red los deja pasar a ambos, y hace bien: no es su trabajo.
Qué hace distinto un WAF
Un WAF se sienta delante de tu aplicación y lee el contenido de cada pedido: la URL, los parámetros, las cookies, lo que se envió en el formulario, las cabeceras. Después compara eso contra un conjunto de reglas que describen cómo se ven los ataques conocidos, y bloquea lo que coincide.
Un ejemplo concreto. Si alguien pide una URL como tusitio.com/producto?id=5 OR 1=1--, el firewall de red ve una petición normal a tu web. El WAF ve un intento clásico de inyección SQL y lo corta antes de que tu código lo procese. Lo mismo con textos que intentan meter JavaScript en un comentario, con pedidos que buscan leer archivos del sistema, o con formularios que reciben mucho más contenido del que deberían.
Los ataques que realmente frena
Inyección SQL. Sigue siendo el ataque más rentable que existe, porque el premio es la base de datos entera: usuarios, contraseñas cifradas, pedidos, direcciones. Un WAF con reglas actualizadas frena la enorme mayoría de los intentos automatizados.
Cross-site scripting. Consiste en dejar código JavaScript escondido en algún lugar del sitio (un comentario, un perfil, una reseña) para que se ejecute en el navegador de otras personas y les robe la sesión. Es tremendamente común en sitios con contenido enviado por visitantes.
Explotación de plugins recién descubiertos. Este es el caso donde el WAF salva más sitios de los que la gente imagina. Cuando se publica una vulnerabilidad en un plugin popular, empiezan los escaneos masivos a las pocas horas. Vos quizás tardes tres días en actualizar. Un WAF con reglas virtuales puede bloquear ese patrón de ataque específico desde el primer día, aunque tu plugin siga sin parchear. En la jerga se lo llama parche virtual, y es una red de contención mientras hacés lo que corresponde.
Fuerza bruta y escaneo. Los intentos repetidos de adivinar contraseñas y los robots que recorren tu sitio buscando archivos de instalación olvidados, copias de bases de datos o paneles de administración expuestos.
Qué NO hace un WAF
Acá conviene ser honesto, porque hay mucha venta de humo. Un WAF no arregla un sitio mal hecho. Si tu formulario guarda las contraseñas en texto plano, el WAF no lo soluciona. Si dejaste una carpeta de respaldos accesible desde el navegador con un nombre adivinable, el WAF probablemente la deje pasar porque el pedido parece legítimo. Y si alguien consigue tu contraseña de administrador porque la usaste también en un foro que sufrió una filtración, va a entrar por la puerta principal con credenciales válidas y ninguna regla lo va a detener.
El WAF es una capa más. Buena, útil, muchas veces decisiva, pero una capa. Sigue haciendo falta actualizar, usar contraseñas únicas, activar segundo factor y tener copias de seguridad que funcionen.
Los falsos positivos y cómo convivir con ellos
El costo de tener un WAF es que a veces bloquea algo que era legítimo. Los casos típicos: un editor que escribe un artículo sobre programación y pega un fragmento de código SQL, un formulario que envía un texto muy largo, o un plugin que hace peticiones con un formato poco habitual.
La solución nunca es apagar el WAF entero. Es mirar el registro de bloqueos, identificar qué regla se disparó y crear una excepción específica para esa regla en esa URL. Cualquier WAF decente te muestra ese registro y te deja hacer la excepción en dos clics. Si el tuyo no te deja ver por qué bloqueó algo, es un mal WAF.
Dónde vive el WAF y por qué importa
Hay tres lugares posibles y no dan lo mismo. El primero es un plugin dentro de tu sitio: es el más fácil de instalar, pero el más débil, porque el ataque ya llegó a tu servidor y ya arrancó PHP para procesarlo. Consume tus propios recursos para defenderse.
El segundo es a nivel del servidor, integrado en el software que atiende las peticiones. Es bastante mejor: bloquea antes de que tu sitio se entere, sin gastar tus recursos, y protege todo lo que esté alojado ahí, no solo WordPress.
El tercero es un WAF en la nube, que se pone delante de tu hosting y filtra el tráfico antes de que llegue. Es el más potente, especialmente contra ataques de volumen, pero implica pasar todo tu tráfico por un tercero y suele tener un costo mensual aparte.
Para la mayoría de los sitios, la combinación razonable es un WAF a nivel de servidor incluido en el plan, más las buenas prácticas de siempre. Recién cuando el sitio factura en serio o recibe ataques dirigidos tiene sentido sumar una capa en la nube.
Qué preguntar antes de contratar
Cuando evalúes un hosting, no te alcances con leer "firewall incluido" en la tabla de características. Preguntá tres cosas concretas: si el firewall es de red o de aplicaciones, con qué frecuencia se actualizan las reglas, y si podés ver el registro de lo que bloqueó y crear excepciones vos mismo. Las respuestas te dicen mucho más que cualquier ícono de escudo en la página de precios.
En el caso de BanaHosting, la protección viene en varias capas desde el propio servidor: firewall a nivel de aplicación con reglas que se actualizan solas, mitigación de ataques de denegación de servicio y análisis de malware sobre los archivos de la cuenta. No es un plugin que instalás y consume tus recursos: trabaja antes, en la infraestructura, que es donde conviene que trabaje.