0x77: Sec-Dashboard

52 herramientas, un puerto y cero nube

Correr un scan significa abrir diez pestañas, copiar salidas a una nota y perder la mitad en el camino.

Quería un panel local que corra las herramientas, guarde el historial y permita exportar los resultados.

Sec-Dashboard es eso: FastAPI + una página de JavaScript sin framework, todo en 127.0.0.1.

0x01 ¿Qué necesidad cubre y para quién?

Para el analista solo o el SOC pequeño que quiere hacer recon sin cuentas de nube ni API keys por todas partes. Antes eso significaba una herramienta en cada pestaña, la salida copiada a mano y el historial disperso en CSV que nadie vuelve a abrir.

Ahora hay un panel con las 52 herramientas, historial persistente y exportación a JSON, PDF o Splunk desde la misma página.

Con honestidad lo monté para mi propio SOC pero es perfectamente escalable.

El nicho soy yo y mi ecosistema, pero cualquier analista solo, puede usarlo igual porque no depende de nada que no esté en su máquina.

0x02 Qué aporta a un SOC (blue team)

• Superficie de exposición: recon de subdominios, DNS, correo (SPF/DKIM/DMARC) y TLS con análisis profundo del certificado. Es la parte de inventario que casi nunca está al día y sin inventario no hay detección fina.
• Triage con contexto: búsqueda y correlación de CVE, comprobación de explotabilidad (ExploitDB, Vulners) y clasificación del hallazgo con Jev que además lo explica en lenguaje plano y sirve para decidir qué se parchea primero sin abrir cinco webs.
• Alimenta al SIEM: auto-indexado en Splunk por REST (index sec_dashboard, con sourcetypes propios como powershell:audit y wifi:marauder). El resultado de un análisis pasa a ser evidencia consultable y correlacionable, no un PDF suelto en una carpeta.
• Evidencia para el informe: JSON, CSV, PDF y un PDF ejecutivo por pipeline. Del hallazgo al informe sin montar la plantilla a mano y con el mismo dato que se indexó.
• Endpoint y artefactos: auditoría de seguridad en Windows por PowerShell, análisis offline de capturas WiFi (.pcap) y de RF (.cff de HackRF). Nada de eso necesita subir el fichero a ningún sitio.
• Local-first, que en seguridad es una decisión: sin cuentas ni claves de API y los datos no salen de la máquina. Sirve en entornos restringidos o aislados y encaja mejor con RGPD.
• Historial y comparación: los targets y scans persisten, se comparan dos ejecuciones y se ve qué cambió entre ayer y hoy. Para seguimiento de un activo, que es el trabajo real del blue team.

En el día a día: entra un dominio nuevo, fast para tener el mapa, deep o nuclear si algo huele mal, Jev y su explicación, export e indexado en Splunk y todo queda en el historial para el informe.

0x03 El antes y el después

Montar el contexto de cada target a mano y con el historial repartido en CSVs era la parte lenta. Ahora el modo fast resuelve recon y puertos en torno a un minuto, el resultado queda en SQLite con su fecha, y el histórico se consulta con búsqueda. Lo que más tiempo ahorra no es la velocidad: es no volver a montar el contexto de un target ya visto.

0x04 ¿Cómo funciona?

1. Backend FastAPI y frontend SPA en vanilla JS: un único index.html, sin framework, sin build.
2. 52 herramientas en 7 categorías (Network Recon, Web Security, Vulnerability, System, OSINT, Email Security, RF Hardware). Trece son herramientas especiales que no piden objetivo: comprobador de hashes, auditoría de contraseñas, búsqueda de CVE e información del sistema.
3. Motor de flujos (pipelines) con cuatro modos: fast (~1 min), deep (~5), full_depth (~4) y nuclear (~7). Cada modo es una cadena de fases y cada fase une herramientas. Las actualizaciones llegan en vivo por WebSocket (/ws).
4. SQLite en data/sec.db: targets y scans persisten entre reinicios, con búsqueda y paginación en el historial.

5. Capa de IA (v2.0): Jev clasifica los hallazgos con preguntas estructuradas y un LLM local redacta la explicación en español. El módulo local_llm.py solo acepta URLs loopback: el modelo nunca sale de la máquina. 6. Corre 100% en local, sin nube ni cuentas. Proxy TOR/SOCKS5 opcional para las herramientas OSINT que lo necesiten.

0x05 Cómo lo monto

git clone https://github.com/PoisonXploIT/sec-dashboard.git
cd sec-dashboard
python -m venv .venv
# Windows: .venv\Scripts\activate  |  Linux/macOS: source .venv/bin/activate
pip install -r requirements.txt
uvicorn backend.main:app --host 127.0.0.1 --port 8444

Abres http://127.0.0.1:8444 y ya está.

Dependencias mínimas: FastAPI, uvicorn, aiohttp, aiosqlite, dnspython, scapy, fpdf2 para los PDFs.

Tres piezas de código que vale la pena mirar

backend/config.py aquí viven las 52 herramientas (TOOLS) y los pipelines (PIPELINES).

Un pipeline es solo datos, fases con listas de tools.

"fast": {
    "name": "Fast Scan",
    "description": "Quick recon + port scan (~1 min)",
    "phases": [
        {"name": "Recon", "tools": ["whois_lookup", "dns_recon", "http_probe"]},
        {"name": "Scan", "tools": ["port_scanner"]},
    ],
},

**backend/validators.py — validate_target() es la protección SSRF

En modo remoto bloquea IPs privadas, loopback y endpoints de metadata (169.254.169.254), y loguea cada bloqueo como WARNING para que quede rastro.

backend/local_llm.py — explain_finding() pide al LLM local la explicación de un hallazgo en lenguaje plano y is_loopback_url() es la guarda que impide apuntar esa llamada a cualquier cosa que no sea localhost.

Y así se ve un pipeline corriendo, fase a fase, con las actualizaciones del WebSocket

0x06 ¿Cómo lo hice?

Construido con IA, herramienta por herramienta.

La idea, la arquitectura y lo que reviso son míos; a la IA se le pide cada tool como módulo separado y no la acepto hasta probarla en vivo contra un target real.

Las decisiones de seguridad no las dejo decidir

• La regla SSRF, el rate limiting y la doble capa de auth (Cloudflare Access + header X-API-Key) los definí yo y ella solo implementa.

• La historia del proyecto tiene tres saltos: v1.1 con 35 herramientas y 6 categorías; v2.0 con la capa AI (Jev + LLM local) y el estado actual, 52 herramientas y 7 categorías con RF Hardware (análisis offline de .cff de HackRF y pcaps WiFi).

• En Agosto hice una auditoría en serio con revisión estática de los 8.113 LOC más pruebas en vivo contra una segunda instancia con SEC_DASHBOARD_REMOTE=1 simulando el deploy público.

• Diez hallazgos, dos críticos, todos fixeados y verificados en esa misma instancia remota.

0x07 Decisiones y errores

• Vanilla JS en vez de React: la SPA entera vive en un index.html. Lo que gané (cero build, cero dependencias frontend) me lo cobra el crecimiento y la lógica de UI ya no cabe bien en un solo fichero.
• SQLite en vez de Postgres: cero configuración, y para una herramienta local era la decisión correcta. El coste es que no está pensado para varias instancias escribiendo a la vez.
• Error crítico: /api/tools/{id}/run aceptaba el target crudo sin validar. En modo remoto cualquiera podía usar el servidor como proxy de escaneo contra redes privadas y metadata cloud. Lo encontró la auditoría que le hice y el arreglo fue pasar cada herramienta con objetivo por validate_target().
• Error: la clave de API se filtró en los logs de uvicorn. Rotación y doble capa en el despliegue público (Cloudflare Access + API key) porque una sola capa me dejó demostrado que no basta.
• Descartado: VPS sin Cloudflare Access y lo descarté justo por el hallazgo C2 de la auditoría, API pública sin autenticación y sin esa capa no publicaba.

0x08 Qué mejoraría

• Partir la SPA en módulos ya que index.html creció más de lo sano para seguir manteniéndolo como un solo fichero.
• Extender la cobertura de Pytest a las herramientas RF Hardware (.cff y pcap offline) con fixtures que hoy son las menos probadas.

Enlaces

• Código: https://github.com/PoisonXploIT/sec-dashboard ·
• Pruebalá y me dices que útil es para tu trabajo y que se puede mejorar o cambiar.
• Demo local en 127.0.0.1:8444 (el despliegue público está detrás de Cloudflare Access a través de esta web).