Objetivo
Esta guía explica cómo, de forma segura, volver a poner el cortafuegos en modo observación (monitor), identificar qué regla bloqueó una petición legítima y, a continuación, añadir la excepción más limitada posible para restaurar la acción deseada sin perder una protección eficaz.
A quién va dirigido este artículo
- Administradores de sitio que utilizan Securantis (agent WordPress/WooCommerce, module PrestaShop o la interfaz SaaS).
- Equipos que desean reaccionar rápido ante un bloqueo legítimo sin abrir demasiado el cortafuegos.
Requisitos
- Acceso de administrador al panel Securantis correspondiente (plugin WordPress / module PrestaShop o el panel SaaS según su configuración).
- Acceso FTP/SFTP o gestor de archivos si se requiere modificar archivos del servidor (raro).
- Información sobre la petición bloqueada: URL, IP origen, marca temporal y tipo de evento (p. ej. SQLi, XSS, rate limit). La tabla de eventos debe contener estos datos.
Vista general del procedimiento
- Volver a observación (modo monitor) para evitar bloquear otras peticiones durante el diagnóstico.
- Reproducir o localizar el evento bloqueado y recopilar sus metadatos.
- Identificar la regla y la condición precisa que provocó el bloqueo.
- Crear una excepción mínima (IP, ruta, parámetro, cabecera o regla de exclusión específica).
- Probar y volver al modo bloqueo si todo es correcto.
Pasos detallados (procedimiento aplicable a WordPress, WooCommerce, PrestaShop y al SaaS)
- Pasar temporalmente a observación
- En la interfaz del plugin/module o del panel, cambie el cortafuegos a modo observación/monitor. Esto evita el bloqueo activo mientras sigue registrando los eventos.
- Mantenga este modo el menor tiempo necesario para el diagnóstico (generalmente unos minutos a una hora).
Resultado esperado: el sitio deja de estar bloqueado pero los eventos continúan siendo registrados.
- Reunir la información sobre el bloqueo
- Reproduzca la acción legítima si es posible (por ejemplo: enviar el formulario o recrear la petición API).
- Anote o exporte el evento correspondiente: marca temporal, URL completa, método HTTP, cuerpo/parámetros (si son visibles), IP origen, user‑agent, estado del cortafuegos (categoría de ataque: sqli, xss, etc.).
Consejo: si el evento fue notificado por un usuario, pídale la hora exacta y la página afectada para localizar la entrada en los logs.
- Identificar la regla responsable
- En la lista de detecciones del cortafuegos, busque el evento por marca temporal y URL.
- Examine el detalle: la mayoría de los registros indican la regla (o la firma) que disparó la alerta y la condición (parámetro, patrón de cabecera, payload detectado).
- Si el log no especifica la regla, active temporalmente la auditoría detallada para la misma ventana de reproducción y repita la acción.
Atención: evite desactivar categorías enteras (p. ej. todas las firmas XSS) para identificar una regla: prefiera la auditoría y el análisis focalizado.
- Redactar la excepción mínima
Objetivo: abrir únicamente lo necesario para la petición legítima.
Tipos de excepciones comunes
- Excepción por IP: si la petición proviene de una dirección IP estable y de confianza. Limítela en el tiempo y documente la razón.
- Excepción por ruta/endpoint: dirigir la exclusión a la URL o al prefijo únicamente (p. ej. /wp-json/your-endpoint).
- Excepción por parámetro: excluir un parámetro específico conocido por contener caracteres detectados como maliciosos.
- Excepción por user‑agent o cabecera: raro, pero útil para integraciones de API legítimas.
- Desactivación de una regla específica: si el sistema identifica una firma concreta, cree una exclusión solo para esa firma.
Cómo crear la excepción
- Elija el tipo de excepción más restrictivo que resuelva el problema.
- En la interfaz del cortafuegos, añada la exclusión precisando el alcance (IP, ruta, parámetro, regla) y una duración de expiración corta (p. ej. 24–72 horas) si es posible.
- Documente la razón en el comentario de la excepción.
Resultado esperado: la acción legítima se realiza sin generar el bloqueo, y el resto de las protecciones siguen funcionando.
- Probar y volver al modo bloqueo
- Reproduzca la acción desde el entorno del usuario afectado (misma IP / misma aplicación).
- Verifique que el evento ya no genera bloqueo activo pero que, si procede, sigue siendo registrado.
- Si todo está conforme, vuelva a poner el cortafuegos en modo bloqueo (block) para restaurar la protección completa.
Ajustes prudentes y buenas prácticas
- Limite la duración de las excepciones automáticas: prefiera una excepción temporal en lugar de una exclusión permanente.
- Priorice las excepciones por ruta o por firma en lugar de por categoría amplia.
- Documente cada excepción (quién la creó, por qué, duración) para futuras auditorías.
- En tiendas WooCommerce y PrestaShop, excluya preferentemente rutas específicas de checkout o webhooks conocidos en lugar de excluir AJAX de forma global.
Errores frecuentes
- Añadir una excepción demasiado amplia (p. ej. desactivar toda la categoría XSS) que expone la superficie de ataque.
- Olvidar restringir la excepción en el tiempo.
- Confundir bloqueo a nivel de servidor (reglas .htaccess, WAF de red) con bloqueo a nivel del agent: verifique el origen del bloqueo.
- No reproducir la petición desde la misma IP o con las mismas cabeceras, lo que falsea el diagnóstico.
Solución de problemas (si la petición sigue bloqueada)
- Revise el log inmediatamente después de intentar reproducirla: ¿interviene otra regla?
- Si el evento muestra un identificador de firma distinto, cree una excepción para esa firma en lugar de ampliar la anterior.
- Confirme que ningún otro WAF (proveedor de hosting, reverse proxy) esté aplicando una regla similar.
- En WordPress/WooCommerce, asegúrese de que las rutas AJAX y REST sensibles no estén excluidas globalmente; apunte al endpoint exacto.
Precauciones de seguridad
- Nunca solicite contraseñas para realizar estas acciones por email o chat.
- Los archivos detectados como maliciosos no deben eliminarse automáticamente: la cuarentena, la restauración o la eliminación requieren una decisión humana.
- Si un cambio de excepción implica intervenir en el servidor (archivos de configuración), haga una copia de seguridad de los archivos antes de modificarlos.
Cuándo contactar al soporte de Securantis
Contacte al soporte si:
- No puede identificar la regla pese a la auditoría detallada.
- La excepción mínima no resuelve el bloqueo y el sitio está afectado en producción.
- Tiene dudas sobre el impacto de la excepción (p. ej. ruta crítica o tráfico importante).
- Sospecha que se trata de un ataque encubierto y no de un falso positivo.
Información que aportar al soporte
- Marca temporal precisa de los eventos reproducidos.
- URL completa, IP origen y user‑agent usados durante la reproducción.
- Captura de pantalla del registro de eventos si es posible.
- Descripción de la solución deseada (p. ej. autorizar temporalmente la IP X para el endpoint Y).
Conclusión
La regla de oro: abrir sólo lo estrictamente necesario y durante el tiempo imprescindible. En modo observación puede diagnosticar sin afectar a los usuarios y, después, aplicar excepciones focalizadas que restablezcan el funcionamiento legítimo manteniendo un alto nivel de protección. Si duda, contacte al soporte con los logs y los detalles solicitados para recibir asistencia guiada.