Objetivo del artículo
Esta guía explica cómo usar el cortafuegos de aplicación proporcionado por el módulo Securantis para PrestaShop (1.7 a 9). Aprenderá a elegir entre modo de observación y bloqueo, activar las reglas dedicadas al comercio electrónico (pedidos, pagos, webhooks, AJAX), autorizar IP y URL, y verificar la compatibilidad y el comportamiento «fail‑open» para evitar cualquier interrupción de la tienda en producción.
Público y prerrequisitos
- Módulo Securantis instalado y vinculado a su cuenta Securantis.
- PrestaShop 1.7 a 9; PHP 7.2+ recomendado por el editor.
- Acceso de administrador al back‑office de PrestaShop.
- Copia de seguridad reciente (archivos y base de datos) antes de cualquier cambio de configuración.
Comportamiento general y principios
- Modos del cortafuegos: observación (solo registros) y bloqueo (interrupción de peticiones maliciosas). Siempre empiece en observación en una tienda activa para medir los falsos positivos.
- Reglas e‑commerce: conjuntos de firmas y heurísticas diseñadas para minimizar los bloqueos en las acciones sensibles (pago, pedido, carrito, webhooks). Estas reglas pueden activarse por separado.
- Listas de autorización: puede declarar IP o URL exentas del filtrado para asegurar el acceso a proveedores terceros (IP de pasarela de pago, IP de monitorización) o ciertos endpoints internos.
- Fail‑open: en caso de error interno del módulo o de la infraestructura, el modo de contingencia neutraliza los bloqueos para mantener la tienda disponible.
Pasos recomendados (despliegue progresivo en producción)
- Paso a observación
- Active el cortafuegos en modo observación. El objetivo: recopilar las detecciones reales e identificar los falsos positivos sin impactar a los clientes.
- Déjelo funcionar durante varios días cubriendo sus picos de actividad (p. ej. semana y fin de semana).
- Revisión de eventos y reglas e‑commerce
- Examine los registros: priorice las detecciones en los recorridos de checkout, API y webhooks.
- Active las reglas «e‑commerce» o «protección tienda» si están disponibles: reducen la severidad en operaciones críticas a la vez que señalan los ataques.
- Autorizaciones (IP y URL)
- Lista de IP autorizadas: añada las direcciones IP de sus proveedores (pasarelas de pago, servicios de facturación, herramientas de monitorización) para que estén exentas del filtrado.
- Lista de URL autorizadas: autorice los endpoints conocidos (webhooks, endpoints de API internos) si el cortafuegos marca peticiones legítimas.
- Pruebe cada autorización en simulación (observación) antes de pasar a bloqueo.
- Paso a bloqueo progresivo
- Active el bloqueo para un subconjunto de reglas no críticas (p. ej. firmas XSS generales) durante unas horas observando los incidentes.
- Si no se constata impacto en clientes, amplíe el bloqueo a las reglas críticas manteniendo las reglas e‑commerce en modo más permisivo si es necesario.
- Supervisión continua
- Programe informes y alertas para seguir la tasa de bloqueo, las reglas más activas y las IP bloqueadas.
- Mantenga períodos regulares de observación tras modificaciones importantes (actualización de módulos, lanzamiento de promociones).
Ajustes prudentes y recomendaciones
- No bloquee inmediatamente las firmas que afectan a pagos o webhooks. Favorezca un período de observación y acciones graduales.
- Prefiera autorizar una IP antes que desactivar globalmente una regla: es más seguro y más específico.
- Documente cada cambio (quién, cuándo, por qué) para poder revertir rápidamente en caso de problema.
- Active el modo «fail‑open» o verifique su presencia: en caso de error del módulo, esto evita la pérdida de ventas.
Errores frecuentes y causas
- Falsos positivos en endpoints AJAX o webhooks: frecuentemente causados por firmas demasiado estrictas o payloads JSON no reconocidos.
- Bloqueo de pasarelas de pago: ausencia de las IP del proveedor en la lista de autorización.
- Pérdida de acceso al back‑office para ciertos empleados: IP dinámica no autorizada o regla demasiado restrictiva en las páginas administrativas.
- Alerta «módulo no conectado» o imposibilidad de verificar la licencia: problemas de red salientes o información de licencia aún no activada.
Resolución de problemas paso a paso
- Si la tienda sufre bloqueos a clientes
- Cambie inmediatamente el cortafuegos a observación o active el modo de contingencia para restablecer el acceso.
- Identifique los eventos recientes: URL bloqueadas, IP de origen, reglas disparadas.
- Añada con urgencia las IP legítimas a la lista de autorización y pruebe los recorridos afectados.
- Si fallan los pagos
- Revise los logs para localizar las peticiones enviadas a la pasarela de pago y añada la IP de la pasarela a las IP autorizadas.
- Confirme con el proveedor de pago la lista de sus IP o dominios si es necesario.
- Si el back‑office es inaccesible para algunas cuentas
- Compruebe si hay una regla que apunte a las páginas administrativas; desactívela temporalmente o autorice la IP afectada.
- Verifique la presencia de un plugin de terceros en el back‑office que modifique rutas y genere firmas no reconocidas.
- Si el módulo informa de una actualización o problema de licencia
- Verifique la conexión de red del servidor hacia los servicios Securantis y el estado de la licencia en el área de cliente.
- Si se propone una actualización, planifíquela fuera de los picos de actividad y pase a observación tras la instalación.
Precauciones y buenas prácticas
- No elimine automáticamente archivos marcados como maliciosos: la eliminación o cuarentena exige una decisión humana.
- No comparta nunca contraseñas por email o chat para el soporte. Si se necesita acceso para una intervención de pago, se facilitará vía el área de cliente segura tras el pago.
- Pruebe siempre los cambios de una regla en una tienda de preproducción si es posible.
- Mantenga copias de seguridad antes de cualquier modificación mayor del cortafuegos o actualización del módulo.
Compatibilidad y limitaciones
- El módulo Securantis para PrestaShop está diseñado para PrestaShop 1.7 a 9 y funciona en PHP 7.2+. No instale el módulo en versiones no soportadas.
- El cortafuegos aplica reglas generales para SQLi, XSS, rutas sensibles y controles de tasa, pero no garantiza la detención de todos los ataques. Algunas herramientas de terceros o personalizaciones de tienda pueden requerir excepciones específicas.
- En caso de un entorno de alojamiento atípico (reverse proxy, CDN, configuración de cabeceras X‑Forwarded‑For), ajuste la configuración para que el módulo lea correctamente la IP de origen.
Cuándo contactar al soporte Securantis
Contacte al soporte si:
- Bloqueos persistentes que afectan las ventas a pesar de añadir autorizaciones y pasar a observación.
- Comportamiento incoherente tras una actualización del módulo o de PrestaShop.
- Dudas sobre la detección de un archivo crítico: necesita ayuda para analizar antes de cualquier eliminación o cuarentena.
- Necesita una intervención más profunda (auditoría o resolución por nuestros técnicos). Tenga en cuenta que para una intervención que requiera accesos, éstos se solicitarán vía el área de cliente segura tras un acuerdo comercial.
Resultado esperado
Siguiendo esta guía debería:
- Tener un cortafuegos activo en observación y reglas e‑commerce ajustadas sin interrupción del servicio.
- Reducir progresivamente los falsos positivos y, si se desea, activar el bloqueo para firmas no críticas.
- Mantener los pagos, webhooks y recorridos de clientes funcionales gracias a las listas de autorización IP/URL y al modo fail‑open.
Anexo — Puntos rápidos
- Siempre empezar en observación.
- Autorizar las IP de proveedores de pago y monitorización.
- Conservar la cuarentena y la eliminación para una decisión humana.
- Contactar al soporte para bloqueos críticos o análisis de archivos dudosos.
Palabras clave: cortafuegos PrestaShop, WAF, reglas e‑commerce, lista blanca IP, autorización URL, fail‑open, PrestaShop 1.7–9, PHP 7.2+