Open Source Rust MVP funcional

Deception Mesh: telemetría defensiva con sensores señuelo distribuidos

Plataforma open source de deception telemetry en Rust para detectar actividad sospechosa temprana con sensores señuelo distribuidos, severidad por reglas, webhooks y exportación CSV. Esta landing concentra la documentación pública del MVP, con foco en qué problema resuelve, cómo está compuesto, cómo levantarlo y cuáles son sus límites actuales.

Ver quickstart Ver en GitHub Hablar de una prueba piloto
Rust Axum Tokio PostgreSQL Docker JWT RBAC Honeypots Webhooks CSV

HEAD /login

Un toque mínimo que normalmente se pierde entre logs dispersos.

/wp-login.php

Prueba típica de reconocimiento automatizado sobre servicios expuestos.

Intento SSH

Autenticaciones inválidas que pasan a ser evidencia accionable.

Qué resuelve

Convierte “ruido” temprano en evidencia útil

En vez de esperar una intrusión ya avanzada, Deception Mesh busca capturar el primer toque ambiguo sobre servicios trampa y convertirlo en telemetría priorizable.

Problema

Señales pequeñas, dispersas y fáciles de ignorar

Un HEAD /login, una prueba a /wp-login.php o un intento SSH inválido pueden quedar mezclados con tráfico normal o perdidos entre logs de bajo contexto.

Respuesta

Señuelos ligeros con alta fidelidad operativa

El proyecto usa sensores señuelo distribuidos para que cualquier interacción con servicios fuera del uso normal se convierta en un evento tipado, priorizado y exportable.

Capacidades

Lo que hoy sí puedes mostrar públicamente

La landing prioriza capacidades que ya aparecen en el README y la documentación del repositorio.

Sensor Agent

Honeypots HTTP y SSH

Expone rutas trampa y servicios señuelo ligeros para capturar el primer contacto sospechoso.

  • Rutas HTTP como /login, /admin y /wp-login.php
  • Honeypot SSH sin shell real
  • Captura evidencia mínima útil para triage
Control Plane

Registro, heartbeat y estado online/offline

Los sensores se enrolan por token, reportan heartbeats y quedan visibles según su último estado.

  • Registro por token de enrolamiento
  • Heartbeat con last_seen
  • Seguimiento active / offline
Telemetría

Severidad, auditoría y exportación

Los eventos se validan, persisten y se priorizan por reglas simples, con auditoría y salida operativa.

  • Esquema EventV1
  • Severidad por reglas y repetición
  • Exportación CSV y auditoría administrativa
Operación

Webhooks, Docker y suites E2E

El MVP se puede levantar de forma reproducible con Docker y verificar con scripts de quickstart y pruebas.

  • Webhook queue con reintentos y backoff
  • Quickstart reproducible
  • Workflows CI y scripts operativos
Arquitectura

MVP centrado en sensor agent, control plane y storage

El flujo está planteado para capturar, validar, almacenar y despachar telemetría defensiva sin convertir el sistema en una plataforma ofensiva.

  1. 1. Sensor Agent en red observada

    Expone servicios señuelo, captura IP origen, ruta o intento de login y reporta eventos.

  2. 2. Control Plane central

    Valida autenticación, aplica RBAC por tenant, persiste eventos y gestiona webhooks.

  3. 3. Postgres como storage

    Mantiene eventos, auditoría, heartbeats y estado operativo del MVP.

  4. 4. Operación y salida

    Permite filtros, consultas, CSV y notificaciones a herramientas externas por webhook.

architecture.txt 
scanner / atacante
        │
        ▼
  sensor_agent
  ├─ SSH trap
  ├─ HTTP trap
  └─ reporter + heartbeat
        │
        ▼
  control_plane API
  ├─ auth / RBAC
  ├─ ingest
  ├─ severity engine
  ├─ audit log
  ├─ webhook queue
  └─ CSV export
        │
        ▼
     Postgres
Quickstart

Ruta corta para levantar el MVP

La idea de esta sección es ayudar a convertir la landing en una página útil para SEO y también para usuarios técnicos.

quickstart 
bash scripts/t29_install_mvp_local.sh
bash scripts/e2e_t29_quickstart.sh
manual-demo 
docker compose up -d --build postgres control_plane
curl -fsS http://127.0.0.1:8080/health
curl -fsS http://127.0.0.1:8080/ready

bash scripts/demo.sh
Flujo recomendado para VPS

Secuencia mínima de despliegue

  1. Copiar .env.production.example a .env.production y ajustar secretos.
  2. Preparar SQL y construir imágenes locales.
  3. Levantar control plane + base de datos con el script de despliegue.
  4. Crear admin y tenant inicial.
  5. Registrar el sensor y ejecutar el smoke test de producción.
Recursos y documentación

Todo el material técnico público en un solo lugar

Además del README, el repo ya trae arquitectura, quickstart, consultas operativas y notas de seguridad que merece la pena enlazar desde la landing.

Arquitectura MVP

Componentes, flujo de datos, superficies de red y principios de seguridad del diseño.

Ver arquitectura

Quickstart local

Instalación mínima reproducible, objetivo de T29 y requisitos para levantar el MVP.

Ver quickstart

Consultas operativas

SQL útil para revisar últimos eventos, actividad externa y resúmenes por IP/servicio.

Ver consultas

Notas de seguridad

Límites técnicos, hardening actual, datos capturados y checklist antes de exponer a clientes.

Ver notas
Consulta operativa

SQL útil para revisar últimos eventos

SELECT
  occurred_at,
  service,
  src_ip,
  src_port,
  severity,
  attempt_count,
  raw_event->'evidence'->>'http_path' AS http_path,
  raw_event->'evidence'->>'http_user_agent' AS http_user_agent,
  raw_event->'evidence'->>'username' AS ssh_username,
  raw_event->'evidence'->>'ssh_auth_method' AS ssh_auth_method
FROM events
ORDER BY occurred_at DESC
LIMIT 30;
Seguridad y límites

Landing honesta: fortalezas y pendientes del MVP

Esta parte es importante para credibilidad técnica y para que la página no sobreprometa.

Hardening actual

Lo que ya está implementado

  • JWT para usuarios y RBAC por tenant.
  • sensor_token y tokens de enrolamiento almacenados como hash.
  • Contraseñas verificadas con Argon2.
  • Validación estricta de EventV1.
  • Webhook deliveries con reintentos e historial.
  • Captura mínima: IP, puerto, método/path HTTP o username/auth method SSH.
Pendientes del MVP

Lo que todavía no conviene maquillar

  • Todavía no hay mTLS real por sensor.
  • No existe retención automática por tenant.
  • No hay rotación formal de tokens.
  • No hay endpoint /metrics.
  • El modo local/dev acepta http://; producción debe ir detrás de HTTPS real.
  • No conviene presentarlo todavía como plataforma completamente endurecida para producción.
FAQ

Preguntas clave para visitantes y evaluadores técnicos

¿Qué detecta hoy Deception Mesh?

Detecta actividad temprana sobre servicios señuelo HTTP y SSH, como rutas trampa, intentos de autenticación y patrones repetidos que luego clasifica por severidad.

¿Se puede desplegar sin una infraestructura compleja?

Sí. El repositorio ya trae quickstart local, scripts de demo, Docker Compose y un flujo recomendado para VPS.

¿Ya está listo para venderlo como plataforma fully hardened?

No todavía. El proyecto deja abiertos temas como mTLS por sensor, rotación de tokens, retención automática y endurecimiento adicional.

¿Es ofensivo o sirve para contraataque?

No. Está planteado como tecnología defensiva y observacional: observar, registrar, priorizar y alertar.

Siguiente paso

Usa esta URL como ficha pública y documentación base

Puedes mandar tráfico a esta landing, dejar GitHub como respaldo técnico y crecer desde aquí con tutoriales y casos de uso.

Abrir GitHub Ir a contacto