Claude Code para herramientas de seguridad con Odin v1

La mayoría de los equipos de seguridad arrastran un montón de scripts pequeños: un parser para un formato de log raro, un conversor entre las salidas de dos escáneres, un entorno que ejecuta reglas contra archivos de prueba. Claude Code escribe muy bien justo este tipo de herramientas y, con InterOdin, puede funcionar sobre Odin v1, que no rechaza el trabajo de seguridad legítimo. En este artículo verás la configuración, cómo mantenerla segura y tres herramientas que vale la pena construir: un parser de logs, un normalizador de datos de reconocimiento para un encargo autorizado y un entorno de pruebas para YARA.

Por qué un comando claudeodin separado

El script de configuración de InterOdin no modifica tu Claude Code habitual. Añade un segundo comando, claudeodin, que ejecuta el mismo Claude Code sobre los modelos Odin con su propia carpeta de configuración, ~/.claude-odin.

Esa separación importa en la práctica:

• Tu comando claude de siempre conserva tu cuenta de Claude, la configuración, las sesiones y el historial. No se sobrescribe nada.
• claudeodin tiene su propio historial, así que las sesiones de seguridad con datos de muestras y notas de encargos quedan fuera de tus sesiones del día a día.
• Puedes cambiar según la tarea. Usa claude para el trabajo general y claudeodin cuando toque triage de malware, contenido de detección o herramientas para un pentest.

Configuración

Necesitas Node.js 18 o superior, Claude Code ya instalado y una clave de API de InterOdin (empieza por io-sk-) obtenida en la consola.

curl -fsSL https://docs.interodin.com/claude-code-setup.mjs -o claude-code-setup.mjsnode claude-code-setup.mjsclaudeodin

El script te pide la clave sin mostrarla en pantalla y escribe la configuración en ~/.claude-odin. Es corto y no tiene dependencias, así que léelo antes de ejecutarlo. Dentro de una sesión, /status muestra qué URL base está activa.

Para deshacerlo todo más adelante:

node claude-code-setup.mjs delete

Esto elimina el lanzador y la configuración que añadió el script. La guía completa, con una configuración manual incluida, está en Claude Code on InterOdin.

Elegir modelo con /model

Dentro de claudeodin, el menú /model muestra Odin v1 y Odin Flash.

• Odin v1 (odin-v1): el modelo más capaz, con una ventana de contexto de 1.000.000 tokens y el razonamiento (thinking) activado por defecto. Úsalo para diseñar una herramienta, leer una base de código grande o depurar un parser contra un formato real y desordenado.
• Odin Flash (odin-flash): más rápido y más barato, con un contexto de 262.144 tokens. Va bien para ediciones pequeñas, renombrados, escribir tests y cambios repetitivos.

Un ritmo habitual: planifica y construye la primera versión con Odin v1 y pasa después a Odin Flash para el trabajo de limpieza.

Un límite que conviene conocer: los modelos son solo de texto. Si pegas una captura de pantalla de un visor de logs, falla. Pega las líneas del log.

Pon un límite de gasto mensual a la clave

Una sesión de agente no es una sola petición. Cada llamada a una herramienta, cada lectura de archivo y cada reintento es su propia llamada a la API, y una sesión larga suma. Crea una clave de API aparte solo para Claude Code y ponle un límite de gasto mensual en la consola. Si una sesión se queda en bucle toda la noche con un test que falla, el límite acota el daño. La facturación es con créditos prepago en EUR o USD, sin suscripción; consulta los precios para ver las tarifas actuales.

Ejecútalo en un contenedor o una VM cuando lance comandos

Claude Code puede ejecutar comandos de shell y editar archivos. Por defecto pregunta antes de cada uno. Mucha gente desactiva esas confirmaciones cuando ya confía en un flujo de trabajo, y es justo entonces cuando el aislamiento importa.

Odin v1 responde directamente, así que hay menos freno en el lado del modelo. Pon el freno en el entorno:

• Ejecuta claudeodin en un contenedor o una VM desechable con solo la carpeta del proyecto montada.
• Deja fuera de ese entorno las credenciales, las claves SSH y los datos de clientes que la herramienta no necesite.
• No dejes nunca que ejecute muestras de malware. Cualquier trabajo con muestras va en una VM de análisis dedicada y aislada, y el entorno de pruebas solo debe leer archivos, nunca ejecutarlos.
• Para las herramientas de reconocimiento, asegúrate de que el entorno no pueda alcanzar objetivos reales salvo que estén dentro de tu alcance por escrito.

Un contenedor mínimo para un proyecto de herramientas tiene este aspecto:

docker run --rm -it \  -v "$PWD":/work -w /work \  -e INTERODIN_API_KEY \  python:3.12 bash

Instala Node.js y Claude Code dentro, ejecuta ahí el script de configuración y la sesión solo podrá tocar /work.

Herramienta 1: un parser de logs

Empieza por algo de bajo riesgo. Imagina que tu proxy escribe en un formato propio que tu SIEM no sabe parsear. Dale a Claude Code una muestra de líneas reales (anonimizadas) y un objetivo claro:

Write parse_proxy.py. Input: lines like the ones in samples/proxy.log.Output: one JSON object per line with timestamp (ISO 8601 UTC), src_ip,user, method, url, status, bytes, user_agent. Lines that do not match goto stderr with the line number. Add pytest tests using the sample lines,including the two malformed ones at the end.

Qué puedes esperar: un parser construido en torno a una expresión regular compilada o un pequeño tokenizador, conversión de timestamps con la zona horaria tratada de forma explícita, tests que cubren las líneas normales y las malformadas, y una nota sobre cualquier campo que haya tenido que suponer, por ejemplo si un - en la columna de usuario significa un valor vacío. Ejecuta tú mismo los tests antes de fiarte del resultado.

Herramienta 2: un normalizador de datos de recon para un encargo autorizado

En un pentest, los datos llegan de varias herramientas y en varios formatos. Un normalizador los une en un único inventario. La regla de diseño clave es que el alcance se aplica en el código, no de memoria.

Pon el alcance de tus reglas de enfrentamiento en un archivo, por ejemplo:

# scope.txt, from the signed rules of engagement192.0.2.0/24198.51.100.0/25

Y después pide:

Build normalize.py for an authorized external test. Inputs: nmap XMLfiles in raw/nmap/ and a CSV export from our web scanner in raw/web/.Output: inventory.json with one entry per host: ip, hostnames, open portswith service and version, and web findings. Load scope.txt and drop anyhost outside it, logging each dropped host to out_of_scope.log. The toolonly reads files; it must not send any network traffic.

Cuenta con un parser para cada entrada, un paso de fusión usando la dirección IP como clave, filtrado por alcance con el módulo ipaddress de Python y tests que incluyen un host fuera del rango para demostrar que se descarta. Ese log de hosts fuera de alcance es una evidencia útil más adelante: demuestra que los datos que no estabas autorizado a probar nunca entraron en el informe.

Una vez que tienes el inventario, la herramienta puede llamar directamente a la API para redactar notas del encargo. Odin Flash encaja bien en este tipo de resumen:

from openai import OpenAIimport jsonimport os
client = OpenAI(    base_url="https://api.interodin.com/v1",    api_key=os.environ["INTERODIN_API_KEY"],)
inventory = json.load(open("inventory.json", encoding="utf-8"))
resp = client.chat.completions.create(    model="odin-flash",    messages=[        {            "role": "system",            "content": "You help a penetration tester on an authorized engagement. "                       "Summarize the attack surface by host. Do not suggest "                       "testing anything outside the provided inventory.",        },        {"role": "user", "content": json.dumps(inventory, indent=2)},    ],)print(resp.choices[0].message.content)

Los prompts y las respuestas de la API nunca se almacenan, solo los metadatos de facturación. Aun así, elimina los nombres de clientes que no necesites. Para convertir estas notas en un entregable, consulta Redacción de informes de pentest con IA.

Herramienta 3: un entorno de pruebas para YARA

Las reglas valen lo que valen sus pruebas. Un entorno de pruebas ejecuta un conjunto de reglas contra dos carpetas, muestras conocidas y archivos benignos conocidos, e informa de los fallos de detección y los falsos positivos.

Write yara_harness.py using yara-python. Compile every .yar file inrules/. Scan positives/ (each file should match) and benign/ (nothingshould match). Never execute any file, only read it. Print a table ofrule, true positives, misses and false positives, and exit non-zero ifany rule has a false positive so CI can catch it.

El núcleo de lo que obtienes se parece a esto:

import pathlibimport yara
rules = yara.compile(filepaths={p.stem: str(p) for p in pathlib.Path("rules").glob("*.yar")})
def scan(folder):    results = {}    for path in pathlib.Path(folder).rglob("*"):        if path.is_file():            results[str(path)] = [m.rule for m in rules.match(str(path))]    return results

Mantén la carpeta de positivos dentro de tu VM de análisis aislada y llena la carpeta de benignos con un conjunto amplio de archivos limpios: instaladores, scripts y documentos de tu propio entorno. Para escribir las reglas en sí, consulta Reglas Sigma y YARA con IA. Para el triage que produce las cadenas en primer lugar, consulta Análisis de malware con Odin.

Revisa lo que construye

Una herramienta escrita por un agente sigue siendo tu herramienta, y en seguridad un bug silencioso puede significar una detección que se escapa o un host fuera de alcance en tu informe. Antes de depender de cualquiera de estas herramientas:

• Lee el diff. Busca rutas hardcodeadas, excepciones que se tragan en silencio y cualquier cosa que toque la red cuando no debería.
• Ejecuta tú mismo los tests y añade un caso en el que el agente no haya pensado, como un archivo vacío o una línea con una codificación inesperada.
• Dale una entrada conocida con una respuesta conocida. Un parser debería reproducir fielmente tus líneas de muestra, el normalizador debería descartar tu host de prueba fuera de alcance y el entorno de pruebas debería marcar un falso positivo deliberado.
• Guarda los prompts que usaste en el repositorio, junto al código, para que la siguiente persona vea qué se le pidió a la herramienta.

Empieza ya

Crea una clave de API en la consola con un límite de gasto mensual, ejecuta el script de configuración y sigue la guía de Claude Code. Para usar la API directamente, empieza por la guía de inicio rápido. Mantén cada herramienta y cada objetivo dentro de tu alcance autorizado y de la Política de Uso Aceptable.