Completed

Security Bot — reactive perimeter defense.

CTO @ Funiglobal

Python system that protects the perimeter of Funidelia, an e-commerce company from Zaragoza: blocking abusive IPs and mitigating endpoint abuse in real time.

A system for automated response to anomalous traffic patterns at Funiglobal's perimeter: real-time blocking of suspicious IPs, mitigation of public endpoint abuse, and correlation of signals with the SIEM. Built as a set of Python daemons that consume streaming metrics (InfluxDB), enrich them against dynamic rules in Redis, and persist an audit trail in Elastic.

Problem

The perimeter of a modern e-commerce site receives abusive traffic that a traditional WAF can't classify: scraping bots that rotate IPs, distributed credential stuffing, abuse of search endpoints where the cost of the request exceeds that of the response. Static rules like "100 req/min" either fall short (false negatives) or punish the legitimate user (false positives).

Architecture

The bot operates across three planes:

  • Ingestion: consumes application metrics and nginx logs from InfluxDB every N seconds. No polling against the backend; zero pressure on production services.
  • Decision: a Python rules engine that evaluates dynamic signatures — ratios between endpoints, user-agent fingerprints, geo-clustering of new IPs — against state held in Redis. Rules are updated hot, with no redeploy.
  • Response: graduated actions — captcha, rate-limit, soft-ban, hard-ban — issued via Bash scripts that touch iptables / fail2ban / WAF depending on the level. Full audit trail to Elastic for post-hoc review.

Outcome

A measurable reduction in the cloud cost associated with non-human traffic on expensive endpoints (search, paginated catalog) without degrading the legitimate experience. The system has been in production since 2022 and is still active — the best sign that the dynamic signatures remain useful.

Why it works

The key is that the rules are dynamic and updated hot: instead of static thresholds like "100 req/min" — which generate false positives and negatives in equal measure — the engine correlates signals (ratios between endpoints, user-agent fingerprints, geo-clustering of new IPs) and scales its response gradually, from captcha to hard-ban. And by drawing on metrics already present in InfluxDB rather than probing the services, it adds zero pressure on the production backend while protecting the most expensive endpoints.