Aloje su propio agente de IA con OpenClaw: instalación gratuita en un solo clic!

Cómo autoalojar la herramienta de pentesting con IA Strix en un VPS

Un pentest hecho a mano se lleva semanas. Strix hace una primera pasada contra una aplicación web en horas y entrega, por cada hallazgo, un exploit que de verdad funciona. En tu propio VPS conservas el control de los objetivos, los logs y las API keys en lugar de dejarlos en manos de una plataforma SaaS.

Esta guía te lleva del aprovisionamiento del servidor a la configuración con Docker, un objetivo de prueba aislado, el primer escaneo y la integración con CI/CD.

⚠️ Aviso de uso responsable

Prueba únicamente sistemas que sean tuyos o para los que tengas permiso explícito por escrito. Autoalojar Strix en un VPS no te da ningún derecho a escanear sitios web, APIs o redes de terceros. Correr escaneos no autorizados contra sistemas fuera de tu control puede violar las leyes de uso indebido de sistemas informáticos en la mayoría de las jurisdicciones, sin importar la intención ni la configuración. Antes de cualquier trabajo, confirma el alcance autorizado y, cuando sea posible, consigue permiso por escrito.

¿Qué es Strix?

Strix es un framework de pentesting con IA construido en torno a agentes autónomos que se comportan como atacantes reales en lugar de motores de reglas estáticas. Sus agentes ejecutan la aplicación objetivo de forma dinámica, prueban rutas de explotación reales y confirman cada hallazgo con una prueba de concepto que funciona antes de que llegue al reporte. La cobertura abarca el OWASP Top 10 y más allá: inyección SQL y NoSQL, control de acceso roto, SSRF, deserialización insegura, manipulación de JWT e inyección de plantillas del lado del servidor. El proyecto es de código abierto bajo la licencia Apache 2.0. Todas las acciones de los agentes corren dentro de sandboxes aisladas de Docker.

Requisitos

  • Contabo VPS 8 (8 vCores, 24 GB de RAM) sobre Ubuntu. Da margen de sobra para procesos de agentes concurrentes y contenedores de sandbox sin que se peleen por los recursos.
  • Docker y el plugin de Docker Compose instalados y en ejecución.
  • Un objetivo de prueba seguro y aislado que sea tuyo o para el que tengas autorización explícita. Nunca apuntes un escaneo a infraestructura en producción sin permiso por escrito.
  • Una API key de un proveedor de LLM compatible (OpenAI, Anthropic o Google) para el reconocimiento, la planificación de la explotación y la generación de reportes con IA.
  • Soltura básica con la línea de comandos de Linux. Todo el flujo de trabajo ocurre por SSH.

Paso 1: Aprovisionar el VPS e instalar Docker

  1. Pide un Contabo VPS 8 desde el Customer Control Panel y elige Ubuntu como sistema operativo durante la configuración.
  2. Conéctate por SSH con autenticación basada en llaves. Desactiva la autenticación por contraseña en /etc/ssh/sshd_config (pon PasswordAuthentication no) y reinicia el servicio SSH una vez que confirmes que el acceso por llave funciona.
  3. Configura UFW para limitar el tráfico entrante solo a SSH: corre ufw allow OpenSSH y luego ufw enable. Abre puertos adicionales de forma deliberada y solo cuando los necesites.
  4. Instala Docker y el plugin de Docker Compose. Comprueba con systemctl status docker que el daemon está activo y luego agrega tu usuario al grupo docker para gestionar contenedores sin sudo.

Paso 2: Desplegar Strix con Docker Compose

Corre el instalador oficial de Strix y luego define las variables de entorno de tu proveedor de LLM:

curl -sSL https://strix.ai/install | bash

export STRIX_LLM="anthropic/claude-sonnet-4-6"

export LLM_API_KEY="your-api-key"

Strix guarda esta configuración en ~/.strix/cli-config.json después de la primera ejecución. La primera invocación de la CLI también descarga la imagen de Docker de la sandbox que aísla del host toda la actividad de los agentes. Para usar un modelo local, apunta LLM_API_BASE a un endpoint autoalojado como Ollama o LMStudio. Aun así, los modelos hospedados suelen dar resultados más consistentes en cadenas de explotación complejas.

Paso 3: Configurar un objetivo de prueba

  1. Descarga y corre el contenedor de la Damn Vulnerable Web App (DVWA) en el mismo VPS:
docker run -d -p 8080:80 vulnerables/web-dvwa
  • Comprueba que DVWA responde: visita la dirección IP del VPS en el puerto 8080 desde un navegador y completa la pantalla inicial de configuración de la base de datos, que inicializa el backend vulnerable.
  • Anota la dirección del objetivo, por ejemplo http://127.0.0.1:8080 para pruebas locales. Ese es el valor que le pasas a Strix en el comando de escaneo.
  • De forma opcional, ajusta el nivel de seguridad integrado de DVWA para comparar qué tan a fondo trabaja Strix con vulnerabilidades parcialmente mitigadas frente a otras completamente abiertas.

Paso 4: Correr un escaneo y leer el reporte

Lanza un escaneo desde la CLI:

strix -n --target http://127.0.0.1:8080 \

  --instruction "Focus on DVWA's known vulnerability categories including SQL injection, XSS, and command injection"

El flag -n corre Strix en modo no interactivo, ideal para sesiones por SSH. Imprime los hallazgos en tiempo real y termina con un código de salida distinto de cero si confirma vulnerabilidades. Los resultados completos quedan en el servidor bajo strix_runs/<run-name>. Cada hallazgo incluye una puntuación CVSS, una prueba de concepto que funciona y una guía de mitigación en lenguaje claro. Prioriza primero por puntuación CVSS: los valores más altos apuntan a mayor impacto potencial (como ejecución remota de código sin autenticación o un bypass total de la autenticación), mientras que los valores más bajos suelen corresponder a hallazgos informativos que requieren condiciones inusuales para explotarse.

Paso 5: Integrar con CI/CD (opcional)

Agrega un workflow de GitHub Actions que corra un escaneo de Strix de forma automática en cada pull request y bloquee los merges cuando haya hallazgos críticos:

name: strix-penetration-test

on:

  pull_request:

jobs:

  security-scan:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v6

        with:

          fetch-depth: 0

      - name: Install Strix

        run: curl -sSL https://strix.ai/install | bash

      - name: Run Strix

        env:

          STRIX_LLM: ${{ secrets.STRIX_LLM }}

          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}

        run: strix -n -t ./ --scan-mode quick

El ajuste fetch-depth: 0 le da a Strix acceso al historial completo de git, de modo que los escaneos rápidos apuntan solo a los archivos que cambiaron en un pull request en lugar de volver a revisar todo el código. Como el workflow termina con un código distinto de cero cuando encuentra vulnerabilidades, puede impedir que un PR se fusione hasta que se resuelvan los hallazgos críticos.

FAQ: correr Strix en un VPS

¿Es legal usar Strix?

Strix en sí es software legal y de código abierto. La herramienta por sí sola no supone ningún riesgo legal. Lo que define la legalidad es hacia dónde y contra qué la apuntas. Correr un escaneo contra sistemas que son tuyos, o cubiertos por permiso explícito y por escrito del propietario, es práctica de seguridad habitual. Escanear sistemas fuera de ese alcance (sitios web de terceros, infraestructura de clientes sin un acuerdo firmado o entornos compartidos donde la autorización no está clara) puede violar las leyes de uso indebido de sistemas informáticos sin importar la herramienta ni la intención.

¿Qué encuentra la herramienta de pentesting Strix?

Strix identifica y comprueba vulnerabilidades del OWASP Top 10 y más allá: inyección SQL y NoSQL, server-side request forgery, deserialización insegura, ejecución remota de código, control de acceso roto (escalación de privilegios, referencias directas a objetos inseguras), fallas de autenticación y de sesión (ataques a JWT, fijación de sesión) y problemas de lógica de negocio como condiciones de carrera y manipulación de pagos. Cada hallazgo incluye una prueba de concepto que funciona y los pasos para reproducirla, no una alerta teórica que tengas que verificar a mano.

¿Cuánta RAM necesita Strix?

Strix no publica un requisito estricto de RAM mínima. En la práctica, correr sus cargas de agentes con IA con soltura pide memoria suficiente para levantar los contenedores de sandbox de Docker junto a los procesos de agentes guiados por LLM sin que compitan por los recursos, sobre todo cuando un escaneo se ramifica en tareas paralelas de reconocimiento y explotación. Un VPS en el rango de 8 a 24 GB de RAM, como el Contabo VPS 8 de esta guía, da margen cómodo para escaneos concurrentes contra objetivos más grandes y complejos.

¿Strix puede probar APIs, no solo aplicaciones web?

Sí. Strix soporta pentesting de APIs directamente y cubre autenticación rota, vulnerabilidades de mass assignment y bypass de rate limiting. Pasa un endpoint de API como objetivo del escaneo igual que lo harías con la URL de una aplicación web. Los agentes de reconocimiento de Strix mapean las rutas y los parámetros disponibles antes de pasar a los intentos de explotación.

Scroll al inicio