Cómo ERPly S.R.L. Maneja la Mitigación de Bots en Odoo 19 y el Click Fraud en Google Ads

En ERPly S.R.L. tratamos esto como un solo problema con dos impactos: riesgo operativo en el ERP (bots, escaneo de vulnerabilidades, fuerza bruta, DoS) y pérdida financiera en marketing (click fraud, tráfico inválido, granjas de clics). Por eso, diseñamos una estrategia defensiva integrada que protege el Odoo 19 alojado en Odoo.sh y, al mismo tiempo, reduce el gasto desperdiciado en Google Ads.

Este artículo explica, a nivel práctico y entendible, cómo lo hacemos.

El riesgo real: bots atacan su ERP y su presupuesto publicitario

Los bots no solo “visitan” su web. En escenarios reales, el tráfico automatizado puede:

• Saturar el login de Odoo con intentos de autenticación (fuerza bruta).

• Generar picos de solicitudes que degradan el rendimiento (DoS a nivel aplicación).

• Extraer información de endpoints públicos (scraping).

• Hacer clic en anuncios repetidamente para agotar presupuesto (click fraud).

Si su empresa depende de Odoo para facturación, inventario, cobros, compras o producción, un evento de este tipo no es una molestia: es una interrupción del flujo de caja, y en RD eso se siente “al momento” en operaciones.

Mitigación en el borde: AWS CloudFront + AWS WAF como primera línea

Cuando el ERP está en Odoo.sh, la infraestructura es gestionada por Odoo. Eso es positivo para velocidad de despliegue, pero limita controles directos de red. La forma más robusta de elevar la postura de seguridad sin romper el modelo PaaS es mover el “perímetro” hacia afuera:

CloudFront: performance y control de tráfico

En ERPly colocamos AWS CloudFront como punto de entrada para el dominio público del ERP. Esto permite:

• Absorber tráfico y reducir carga directa hacia Odoo.sh.

• Cachear recursos estáticos (mejor experiencia para usuarios).

• Centralizar políticas de seguridad y registro.

AWS WAF: filtrado inteligente antes de que toque el ERP

Acoplamos AWS WAF a CloudFront para bloquear:

• Patrones comunes de ataque web (OWASP Top 10).

• IPs con reputación maliciosa.

• Bots conocidos y automatización sospechosa.

• Exceso de solicitudes por IP (rate limiting), especialmente en rutas críticas como login.

Resultado: el bot “se estrella” en el borde. Odoo recibe menos ruido, opera más estable, y el equipo gana visibilidad accionable.

Odoo 19 detrás de proxies: preservación de IP real y estabilidad de sesión

Cuando se agrega una capa perimetral (CDN/WAF) delante de Odoo.sh, se introduce una cadena de proxies. Si no se configura correctamente, Odoo puede “ver” la IP del proxy en vez de la IP real del usuario. Eso afecta auditoría, seguridad y puede causar comportamientos indeseados con sesiones y redirecciones.

En ERPly implementamos mejores prácticas para Odoo 19:

• Activación de proxy_mode.

• Estabilización de URL canónica con web.base.url y bloqueo con web.base.url.freeze.

• Ajustes de confianza de proxies para que Odoo interprete correctamente X-Forwarded-For, X-Forwarded-Proto y X-Forwarded-Host.

Esto es especialmente importante cuando su operación incluye integraciones, accesos externos, portales o flujos sensibles donde una URL mal resuelta puede romper autenticación o generar loops.

Click Fraud en Google Ads: del enfoque reactivo a la prevención proactiva

Google filtra una parte del tráfico inválido, pero el click fraud sofisticado puede colarse. El error común es manejar esto con una lógica reactiva: revisar campañas tarde, pelear reembolsos, y seguir pagando durante el problema.

En ERPly aplicamos dos capas:

Higiene base en campañas

• Ajuste de ubicaciones a “Presencia” (personas que están realmente en la ubicación), evitando “interés” como criterio amplio.

• Exclusiones de ubicaciones/segmentos que no son negocio.

• Depuración de placements en Display/Video cuando aplica.

• Control de términos de búsqueda, concordancias y negativos.

Automatización: exclusión de IPs con inteligencia del firewall

Aquí es donde integramos seguridad y marketing.

Cuando AWS WAF bloquea una IP por comportamiento malicioso (bots, ataques, rate limit), esa señal tiene un valor enorme: es evidencia de automatización o abuso.

Implementamos una arquitectura donde:

• WAF registra eventos de bloqueo.

• CloudWatch dispara una función (AWS Lambda).

• Lambda llama a la API de Google Ads y agrega la IP a exclusión (con rotación inteligente por límites).

Este “feedback loop” reduce la probabilidad de volver a pagar por el mismo bot, y acelera el aprendizaje defensivo del ecosistema digital.

Monitoreo y gobierno: seguridad operativa sin afectar usuarios legítimos

Toda automatización debe incluir controles para evitar “friendly fire” (bloqueos indebidos). ERPly opera esto con:

• Allowlist de IPs críticas (oficinas, socios, integraciones).

• Umbrales de rate-limit calibrados por tipo de operación (un usuario de almacén puede generar bursts legítimos).

• Dashboards para ver bloqueos por regla, picos de tráfico, y correlación con métricas de campaña.

• Alertas por fallos de automatización (por ejemplo, expiración de tokens de Google Ads API).

La meta no es bloquear por bloquear; la meta es mantener continuidad operativa y eficiencia comercial con control.

Qué gana su empresa con este enfoque ERPly

En términos ejecutivos (sin humo), el impacto se traduce en:

• Menos interrupciones: Odoo 19 se mantiene estable ante picos de bots.

• Mejor trazabilidad: registros y auditoría con IP real, útil para control interno.

• Menor desperdicio en Ads: menos clics inválidos drenando presupuesto.

• Decisiones con evidencia: visibilidad de amenazas y costo evitado.

• Arquitectura escalable: crece con su operación sin reinventar seguridad cada trimestre.