limeyard

Laboratorio Docker deliberadamente vulnerable con un dominio DNS enrutable y claves de respuesta legibles por máquina por objetivo, que puntúa localmente la precisión, la exhaustividad y el alcance del escáner.

Por qué cambió

La flota antigua puntuaba 9 de 9, cero fallos, cero falsos positivos. Un benchmark que no puede fallar no puede detectar una regresión. Tres cosas estaban mal estructuralmente:

• Tres de cinco motores no tenían verdad de referencia. Cada aplicación era 127.0.0.1:70xx, así que la enumeración de subdominios no tenía nada que enumerar, el escaneo de puertos recibía su respuesta, y el fingerprinting de servicios nunca veía un demonio no HTTP.
• 11 de 101 plantillas de detección se habían activado alguna vez. Las otras 90 se enviaban sin ningún tipo de objetivo en vivo.
• Nada medía la precisión. Cada objetivo era genuinamente vulnerable, así que "cero falsos positivos" era infalsificable.

Inicio rápido

Necesitas Docker (con el plugin compose) y git. Nada más.

Eso clona el laboratorio en ./limeyard, escribe su .env con un token de API nuevo, construye e inicia el plano de control, y luego pregunta qué ejecutar. Antes de que empiece nada muestra cuánto cuesta la selección, medido en reposo en la máquina de referencia, frente a lo que tu máquina tiene libre:

No interactivo: curl ... | bash -s -- --light --yes (o --all, --none, --pick dvwa,juice-shop,estate). Coloca el checkout en otro lugar con LIMEYARD_DIR=/path.

El panel está entonces en http://127.0.0.1:7000, y las mismas cosas a mano:

A mano, sin el instalador:

Cada manifiesto lleva un bloque resources medido (contenedores, RAM en reposo, disco de imágenes, CPU en reposo). El asistente, la franja de selección del panel y la página de cada objetivo suman a partir de él, así que la estimación es la misma en todas partes.

Ramas

Dos, y solo dos.

• main es lo que clona el instalador y lo que obtienes si no haces nada. Se mueve por pull request, nunca por push directo.
• dev es la rama por defecto y donde aterriza el trabajo. Abre pull requests contra ella.

Conceptos

Kinds: web api bench cve service estate edge control mobile.

Estructura

Panel de control

docker compose up -d inicia dos contenedores y nada más: limeyard_control (el demonio limed, que sostiene el socket de Docker) y limeyard_ui (el panel SvelteKit). Ambos se enlazan solo a loopback. El panel está en http://127.0.0.1:7000 y la API cruda en http://127.0.0.1:7099. Ambos necesitan .env, y LIME_TOKEN en él es obligatorio: el panel sostiene el token del lado del servidor y el navegador nunca lo ve.

El panel se actualiza solo: limed transmite las transiciones de estado por SSE, así que un objetivo iniciado desde la CLI aparece sin refrescar. La cabecera lleva la CPU, RAM y disco libre del host desde el mismo stream, coloreados solo cuando merece la pena notarlos. Cada tabla se ordena haciendo clic en la cabecera de una columna; un segundo clic invierte la dirección.

Tras un cambio en el panel o el demonio, reconstruye el par:

Para trabajar en el panel contra un demonio en ejecución sin reconstruir la imagen:

API

Cada llamada excepto /api/health necesita X-Lime-Token.

Redes

Tres niveles, porque uno era el problema original.

• lime-web bridge. Objetivos web y API, publicados en 127.0.0.1:70xx.
• lime-lab bridge, 10.66.0.0/16, IPs estáticas, sin enlace al host. Un escáner se une a esta red como un contenedor y ve una subred real con hosts reales y puertos reales en lugar de una lista de puertos de loopback.
• lime-edge el nivel WAF, con el origen alcanzable pero ausente del DNS.

El DNS es BIND autoritativo en zonas .test (RFC 6761 la reserva). Los alias de red de Docker deliberadamente no son la fuente de verdad: nunca aparecen en una transferencia de zona, y harían que la topología discrepara con la clave de respuestas.

Puertos

Puntuación

Cada objetivo envía un truth.yml. El scorer convierte los hallazgos en precisión, recall y F1, por objetivo y por clase:

Se cuentan tres cosas, no una. Recall: encontramos lo que está ahí. Precision: evitamos reportar lo que no está, medido contra las entradas negative que lleva cada clave de respuestas. Scope: lo que correctamente no intentamos, registrado para que nadie lo re-litigue cada trimestre.

El objetivo mirage existe solo para lo segundo. Nada en él es vulnerable y todo en él parece que lo es, así que cualquier hallazgo contra él es un falso positivo por construcción.

Contribuir

CONTRIBUTING.md tiene todo: qué es normalmente una contribución, las invariantes que hace cumplir ./lime audit, y por qué una corrección a una clave de respuestas vale más aquí que una nueva funcionalidad. La versión corta de las reglas está abajo. Todos los que participan están sujetos al código de conducta.

Añadir un objetivo

Reglas que mantienen el laboratorio limpio:

• Enlaza solo el puerto del objetivo, a 127.0.0.1.
• Los objetivos de un solo contenedor se unen solo a [lime-web]. No añadas una red por proyecto: demasiadas redes y Docker se queda sin pool de direcciones.
• Los objetivos con una base de datos se unen a [default, lime-web] y ponen la base de datos en [default] solo. Cada objetivo obtiene su propio servicio de base de datos y volumen.
• Los objetivos que existen para ser descubiertos en lugar de navegados se unen a [lime-lab] con una IP estática y no publican ningún puerto de host.
• upstream es obligatorio. lime doctor falla un objetivo sin él y el manager se niega a registrar uno. Ver abajo.
• limeyard no incluye código fuente de terceros. Pon repo: y compose: en el manifiesto y la fuente se obtiene en tiempo de ejecución en <target>/src en su lugar.
• Registra lo que cuesta. Inícialo, deja que se asiente, y ./lime measure <slug> imprime el bloque resources para pegar. El instalador y el panel suman estos para advertir a alguien antes de que lo inicie, así que una suposición aquí es una mentira allí.

Confianza y aislamiento

Los objetivos son software deliberadamente vulnerable de otras personas, así que la procedencia se registra en lugar de asumirse, y el runtime se restringe en lugar de confiarse. SECURITY.md tiene el panorama completo; la versión corta:

• Cada imagen está fijada por digest, no una etiqueta flotante, al digest que se obtuvo y probó aquí. ./lime pin reporta la deriva.
• Los publicadores están documentados por imagen: Docker Official Images, cuentas de organización del proyecto (OWASP, ISC, Traefik, Prometheus), o el propio namespace del autor. Los dos eslabones más débiles, raesene/bwapp (archivado, última reconstrucción 2022, sin licencia) y delfer/alpine-ftp-server (un individuo), se nombran como tales.
• Cada servicio se ejecuta con no-new-privileges, cap_drop: ALL más un cap_add mínimo por imagen, un techo de pids y un techo de memoria. Los niveles de base de datos se sitúan en redes internal: true sin ruta de salida.
• limed sostiene el socket de Docker, que es root en el host, así que requiere un secreto compartido en cada llamada. Un objetivo comprometido puede alcanzarlo y no aprender nada.
• ./lime audit falla con privileged, networking de host, un montaje de socket en un objetivo, un enlace fuera de loopback, una imagen no fijada o un token ausente.

Nada aquí defiende contra un escape de contenedor a nivel de kernel. Para eso, usa una VM desechable.

Atribución

Casi todo aquí fue escrito por otra persona, y varios objetivos no declaran ninguna licencia. Así que acreditar al autor es una puerta dura, no una convención:

• target.yml lleva un bloque upstream obligatorio: autor, repo, licencia, y la fecha en que verificamos por última vez que construye. packager registra a la persona que containerizó algo cuando eso difiere de quien lo escribió.
• Cada tarjeta del dashboard muestra el autor bajo el nombre del objetivo, enlazado a la fuente, con la licencia al lado. Una licencia de none declared se renderiza como una advertencia, que es también la señal de no redistribuir.
• La vista de detalle de cada objetivo se abre con un bloque de crédito, por encima de la lista de vulnerabilidades, con nuestra clave de respuestas claramente separada de la documentación propia del upstream.
• /credits en la UI y ./lime credits listan cada objetivo, autor y licencia. ./lime credits --markdown regenera la sección de abajo.

Créditos

limeyard ejecuta el trabajo de otras personas. Cada objetivo y escenario de abajo fue construido por otra persona a menos que diga Clickswave.

api

bench

control

cve

edge

mobile

scenario

service

web