Dentro del cortafuegos de aplicaciones web ReportedIP
ReportedIP ofrece un cortafuegos de aplicaciones web que analiza cada solicitud antes de que WordPress la procese. Compara la URL, la cadena de consulta, el cuerpo de la solicitud y el agente de usuario con un conjunto de reglas firmadas, bloqueando inyecciones SQL, XSS, recorrido de rutas, inyección de comandos y una docena de tipos de ataques más; además, las reglas se actualizan automáticamente sin necesidad de lanzar una nueva versión del complemento.
The engine and its baseline ruleset are free on every plan. This guide covers how the firewall inspects traffic, where the rules come from, how a bad regex is stopped from taking the site down, how to clear a false positive from the admin, and how the optional pre-WordPress guard works. It reflects Hive as of version 2.1.21, after the 2.1.5–2.1.21 hardening run.
Qué comprueba el cortafuegos de WordPress en cada solicitud
El WAF se ejecuta en el init Se ejecuta con prioridad 1, inmediatamente después de la comprobación de bloques de IP de Hive. Una solicitud procedente de una IP ya bloqueada nunca llega al cortafuegos, por lo que no se desperdicia esfuerzo. Todo lo demás se inspecciona: la URI de la solicitud, la cadena de consulta, el cuerpo de la solicitud y el agente de usuario se simplifican y se comparan con el conjunto de reglas activo.
El coste es de unos 4 microsegundos de CPU por solicitud, sin consultas adicionales a la base de datos cuando existe una caché de objetos persistente. Las clases de ataque detectadas incluyen inyección SQL, cross-site scripting, recorrido de rutas, inyección de comandos y envoltorios LFI, además de SSRF, Log4Shell/JNDI, inyección de objetos PHP, inyección NoSQL, XXE, carga de shells web, CRLF e inyección de plantillas, cada una con su propio código de motivo de bloqueo.
La inspección es de solo lectura y tiene en cuenta los falsos positivos. Los administradores que hayan iniciado sesión están exentos (los administradores pegan legítimamente código SQL y otro tipo de código en los editores), /wp-admin nunca se revisa, y las direcciones IP incluidas en la lista blanca se omiten. Las entradas válidas se bloquean siguiendo la misma ruta 403, segura para la caché y codificada por referencia, que utilizan los demás sensores, o simplemente se registran cuando el modo de solo informe está activado.
¿Por qué las reglas del cortafuegos se encuentran en el servidor y no en el complemento?
La mayoría de los cortafuegos de WordPress tienen las firmas codificadas de forma fija, por lo que cada actualización de las reglas requiere el lanzamiento de un nuevo plugin. Hive lo hace al revés: las firmas proceden de la API de reglas reportedip.de en forma de conjuntos de reglas versionados, firmados con Ed25519 y escalonados por niveles, que se sincronizan cada seis horas. Las nuevas firmas de ataque llegan a todas las instalaciones en cuestión de horas.
Hay cuatro conjuntos de reglas — waf, bot_signatures, disposable_domains y scan_paths. Cada uno de ellos está firmado con una firma Ed25519 independiente, y el complemento la verifica comparándola con un conjunto de claves públicas incluido (la actual y la siguiente, para la rotación). antes al aplicarla. Si la verificación falla, el feed es demasiado grande o no se puede acceder al servidor, Hive recurre a un conjunto de reglas básicas integrado. Un feed manipulado o secuestrado no puede corromper las reglas, ni siquiera si se filtra una clave API o se rompe el TLS.
La versión básica se incluye en el complemento, por lo que el cortafuegos funciona totalmente sin conexión en el modo «Local Shield», sin necesidad de una cuenta ni de realizar llamadas salientes. La sincronización de reglas es opcional: solo se ejecuta en el modo «Community» si se ha configurado una clave API.
Versión básica gratuita, funciones avanzadas en la versión Professional
La configuración de escalonamiento se basa en el modelo de niveles de paranoia del Conjunto de Reglas Básicas de OWASP, el estándar de facto para WAF utilizado por ModSecurity y Cloudflare.
| Nivel de paranoia | Personaje | Plan de la colmena |
|---|---|---|
| PL1 | La configuración básica, optimizada para minimizar los falsos positivos, cubre el Top 10 de OWASP | Gratis (paquete básico) |
| PL2 | Más vigilancia, algunos falsos positivos más | Colaborador (semanal) / Profesional |
| PL3 | Ataques poco frecuentes, técnicas de ofuscación y cobertura de elusión de WAF, falsos positivos ocasionales | Profesional (Sincronización prioritaria) |
La versión gratuita ofrece un cortafuegos eficaz con un bajo índice de falsos positivos: esa es la promesa de protección. La versión Professional incorpora los conjuntos de reglas PL2/PL3, más exhaustivos y actualizados con frecuencia, a través de Priority Sync, junto con las listas actualizadas en tiempo real de rangos de IP de bots y dominios desechables.
Cómo evita Hive que una regla errónea provoque la caída de tu sitio web
Dado que los patrones proceden de un feed, una expresión regular mal formada supone un riesgo de primer orden: un retroceso catastrófico (ReDoS) llegó a dejar Stack Overflow fuera de servicio durante 34 minutos. Hive se protege contra ello mediante varias capas:
- Reducir el límite de retroceso. Antes del ciclo de inspección, Hive establece
pcre.backtrack_limita 100 000 (frente al valor predeterminado de 1 millón) y lo restablece después, limitando así el tiempo de ejecución máximo por patrón. - Actuar de forma predeterminada en caso de error de expresión regular. Cuando un patrón alcanza el límite,
preg_match()devolucionesfalse, no0o1— un bypass silencioso si no se marca. Hive tratafalseen modo «fail-open» y con registrowaf_pattern_errorevento. Una regla incumplida nunca bloquea el tráfico legítimo ni impide el acceso al sitio: la disponibilidad prima sobre el rigor. - Tamaño máximo del cuerpo: 8 KB. Las solicitudes de cuerpos que superen los 8 KB omiten los grupos de cuerpos, por lo que la base de retroceso queda limitada.
- Linter del lado del servidor. En reportedip.de, cada patrón se comprueba para detectar posibles retrocesos catastróficos antes de ser firmado; los patrones peligrosos nunca se publican.
Los patrones personalizados también dan prioridad a los grupos atómicos y a los cuantificadores posesivos, que no requieren retroceso, y el JIT de PCRE (activado por defecto en WordPress) agiliza la búsqueda de coincidencias.
Clear a false positive from the admin, without touching code
Any signature firewall will occasionally flag a legitimate first-party request — a page builder posting rich HTML, or a security plugin that legitimately ingests attack-like payloads. Since version 2.1.9, Hive handles this the way ModSecurity exclusions and the Wordfence allowlist do: a backend-managed exception list, no code and no report-only detour required.
- One click per log row. Every WAF block in the log carries an Allow action that creates a narrow exception for exactly that rule on that path. The block log records the matched value, the inspected target, the request method, URI, user-agent and paranoia level, so a decision is diagnosable without reproducing the request.
- Scoped, never global. An exception targets a single rule, a rule group, or — for a first-party endpoint — the whole engine on a path, optionally narrowed to an IP or CIDR. A whole-engine exception must carry a path or IP, so the firewall can never be switched off site-wide by accident.
- Network-wide and free. Exceptions are stored as network-wide data (option
reportedip_hive_waf_exceptions, schemadb_version10) and available on every plan — the protection engine itself stays free. - Applies to the pre-WordPress guard too. Extended Protection bakes the same exceptions in and rebakes them whenever the allowlist changes, so a client you allowed in the admin is honoured before WordPress even loads.
The exception form is self-explanatory: the scope selector reveals only the relevant field, and the ambiguous “Rule ID or group” input is split into a Rule ID field and a group dropdown populated from the engine’s known categories. Developers get a code-level escape hatch as well — the reportedip_hive_waf_bypass_routes filter, matched by an anchored str_starts_with test against the resolved REST route, so a bypass token in an unrelated query parameter cannot disable the WAF.
Protección ampliada: bloqueo antes de que se cargue WordPress
El init- El cortafuegos «-hook» se ejecuta una vez que WordPress se ha iniciado. Para garantizar la protección antes de que se ejecute el código de cualquier plugin, Hive ofrece un complemento opcional que ejecuta el WAF a través de PHP. auto_prepend_file directive — the same approach Wordfence calls Extended Protection. It is off by default and additive to the in-WordPress engine, and it inspects request bodies just like the main engine (a hoisting bug that made body inspection a silent no-op was fixed in 2.1.10).
- Apache obtiene un
php_value auto_prepend_filelínea escrita en un espacio marcado.htaccessbloque. - PHP-FPM — including nginx. Hive detects the PHP-FPM SAPI ahead of the nginx server string and writes a document-root
.user.ini, which PHP-FPM honours for every request regardless of nginxlocationblocks. Since 2.1.17 this covers nginx automatically, with no manual step — earlier versions could only offer a hand-pastedlocationsnippet that protected just the one block it landed in. - Fallback snippet. On stacks without a FastCGI PHP SAPI, Hive still generates a copy-paste php.ini / PHP-FPM-pool line and an nginx
fastcgi_param PHP_VALUEblock; the Server Setup tab surfaces these whenever the auto-written.user.iniis not yet taking effect.
Three safety behaviours make the guard predictable. It skips body inspection for signed-in users — it detects the wordpress_logged_in cookie, so an editor saving a post through admin-ajax.php or the REST API is never tripped by an XSS/SQLi signature (URL and user-agent rules still run, and the in-WordPress engine stays the capability-aware backstop). It self-heals on toggle: disabling the WAF or switching it to report-only neutralises the pre-WordPress guard as well, so the firewall can never keep enforcing after it was switched off. And removal is fail-safe: deactivating the plugin strips the directives Hive controls and leaves an inert placeholder instead of deleting the guard file, so a leftover auto_prepend_file line in an nginx or php.ini config Hive cannot edit can never point at a missing file and 500 the site.
The setup is verifiable: the status reports whether the guard actually executed for the current request — “Setup complete” the moment it works — instead of guessing. The setup wizard walks new installs through it with safe defaults.
Los códigos de referencia convierten un bloque erróneo en una consulta de una sola línea
Cada bloque lleva un código de referencia identificable, como por ejemplo WAF_SQLI-3F9A2B71, que se muestra en la página del bloque y se envía como el X-RIP-Ref header. A visitor who is blocked by mistake quotes one short string, and an admin matches it in the logs — then clears it with the one-click Allow action if it was a false positive. The token is a one-way hash of the IP, the reason and the hour, so it exposes no personal data.
Preguntas frecuentes
¿El cortafuegos de aplicaciones web es gratuito?
Sí. El motor WAF y la configuración básica «OWASP Top 10 - Nivel de paranoia 1» están disponibles en todos los planes, incluidos el nivel gratuito y el modo «Local Shield», que funciona totalmente sin conexión. El plan Professional incluye conjuntos de reglas más avanzados de los niveles 2 y 3, así como actualizaciones en tiempo real a través de Priority Sync.
¿El cortafuegos bloqueará mis propias tareas de administración?
No. Logged-in administrators are exempt, /wp-admin is never inspected, and the pre-WordPress guard skips body inspection for any signed-in user. If a front-end form or a first-party endpoint does trip a rule, open the WAF log, click Allow on that row to create a narrow exception, and you are done — no code and no report-only detour needed.
Does the firewall run on nginx?
Yes, and since 2.1.17 the pre-WordPress guard configures itself on nginx automatically by writing a document-root .user.ini that PHP-FPM honours for every request. If your stack disables per-directory INI files, the Server Setup tab shows a php.ini or nginx fastcgi_param line to paste instead.
¿Qué ocurre si no se puede acceder al servidor de reglas?
No se produce ningún fallo. El complemento sigue utilizando el último conjunto de reglas verificado, o la configuración de referencia incluida, y vuelve a intentar la sincronización más tarde. El cortafuegos nunca depende de una conexión activa para funcionar.