limeyard

Um laboratório de testes de segurança. Uma frota de alvos deliberadamente vulneráveis, uma infraestrutura de rede roteável com DNS autoritativo para descoberta de ativos a enumerar, uma chave de respostas legível por máquina por alvo, e um painel de controlo para gerir tudo.

Tudo aqui é deliberadamente vulnerável. Apenas para testes locais. Não o exponha à internet nem a uma rede não confiável. As portas publicadas ligam-se a 127.0.0.1; os alvos do laboratório não se ligam a nada.

O nosso próprio scanner obtém RCE dentro destes contentores de propósito, por isso o contentor é tratado como uma fronteira de segurança: cada imagem é fixada por digest, cada serviço remove todas as capabilities e adiciona de volta o mínimo, e ./lime audit impõe isso. Leia o SECURITY.md antes da primeira execução, incluindo a parte sobre o que o isolamento de contentores não cobre.

O painel de controlo em http://127.0.0.1:7000, mostrando o laboratório em execução.

O limeyard era vuln_apps. Foi renomeado porque deixou de ser uma pasta de aplicações: agora contém serviços simples, uma zona DNS, um par de WAFs, um alvo de precisão e fixtures de APK, nenhum dos quais são aplicações.

Porque mudou

A frota antiga pontuou 9 de 9, zero falhas, zero falsos positivos. Um benchmark que não pode falhar não consegue detetar uma regressão. Três coisas estavam estruturalmente erradas:

• Três de cinco motores não tinham ground truth. Cada aplicação era 127.0.0.1:70xx, por isso a enumeração de subdomínios não tinha nada para enumerar, o port scanning recebia a sua resposta, e a identificação de serviços nunca via um daemon não-HTTP.
• 11 de 101 templates de deteção alguma vez dispararam. Os outros 90 vinham sem qualquer tipo de alvo ativo.
• Nada media a precisão. Cada alvo era genuinamente vulnerável, por isso "zero falsos positivos" era infalsificável.

Início rápido

Precisa de Docker (com o plugin compose) e git. Nada mais.

curl -fsSL https://raw.githubusercontent.com/clickswave/limeyard/main/install.sh | bash

Isso clona o laboratório para ./limeyard, escreve o seu .env com um novo token de API, constrói e inicia o plano de controlo, e depois pergunta o que executar. Antes de qualquer coisa iniciar, mostra quanto custa a seleção, medido em idle na máquina de referência, em comparação com o que a sua máquina tem livre:

This selection, idle, on the box it was measured on:
  17 targets, 1 scenarios, 45 containers
  RAM  about 2.9 GB resident  (host has 22.4 GB available)
  disk about 11.0 GB of images to pull  (host has 111 GB free)
  CPU  near idle once up (3% of one core); pulling and first boots are the busy part
Start it? [y/N]

Não interativo: curl ... | bash -s -- --light --yes (ou --all, --none, --pick dvwa,juice-shop,estate). Coloque o checkout noutro sítio com LIMEYARD_DIR=/path.

O painel fica então em http://127.0.0.1:7000, e as mesmas coisas à mão:

./lime setup                  # o assistente outra vez, a qualquer momento
./lime start --all            # todos os alvos leves
./lime start crapi --heavy    # um pesado, explicitamente
./lime scenario-up estate     # a infraestrutura de rede: DNS, vhosts, serviços
./lime status                 # o que está ativo
./lime stop --all --heavy     # tudo desligado; imagens e volumes permanecem
./lime credits                # quem escreveu cada alvo, e sob que licença
./lime doctor                 # verificações de ambiente, atribuição e disco
./lime doctor --fix           # aplicar o remédio automático de cada verificação, depois reverificar
./lime audit                  # endurecimento de contentores + invariantes da cadeia de fornecimento
./lime pin                    # reportar desvio de imagens em relação ao registry

À mão, sem o instalador:

git clone https://github.com/clickswave/limeyard && cd limeyard
cp .env.example .env
echo "LIMEYARD_DIR=$PWD"                 >> .env
echo "LIME_TOKEN=$(openssl rand -hex 24)" >> .env   # obrigatório, ver SECURITY.md
docker compose up -d --build  # plano de controlo + UI em http://127.0.0.1:7000
./lime setup

Cada manifesto carrega um bloco resources medido (contentores, RAM em idle, disco de imagens, CPU em idle). O assistente, a faixa de seleção do painel e a página de cada alvo somam a partir dele, por isso a estimativa é a mesma em todo o lado.

Branches

Duas, e apenas duas.

• main é o que o instalador clona e o que obtém se não fizer nada. Move-se por pull request, nunca por push direto.
• dev é a branch predefinida e onde o trabalho aterra. Abra pull requests contra ela.

Conceitos

target	uma coisa sob teste, de um kind declarado. Possui um ficheiro compose, setup opcional, e a sua própria chave de respostas. Corre como o seu próprio projeto compose isolado, por isso dois alvos a usar Postgres nunca partilham um
scenario	vários alvos ligados numa topologia de rede com DNS autoritativo. Contra o que a descoberta de ativos é pontuada
truth	a chave de respostas legível por máquina. Ver truth/schema.md
doctor	uma lista de verificações com um veredicto cada: ambiente, atribuição, cadeia de fornecimento, endurecimento. Verificações com um remédio inequívoco têm um fix de um clique no painel (/doctor) e --fix na CLI: criar redes, recuperar disco, fixar imagens, obter fontes, reverificar alvos em execução, reescrever binds fora do loopback. Atribuição, conflitos de portas e endurecimento precisam de uma pessoa

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

Estrutura

targets/<kind>/<slug>/     target.yml, compose.yml, setup.sh, truth.yml
scenarios/<slug>/          scenario.yml, compose.yml, zones/
control/limed/             o daemon: CLI + HTTP API + scorer
control/ui/                o painel de controlo SvelteKit
truth/                     o contrato, e scorecards datados

Painel de controlo

docker compose up -d inicia dois contentores e nada mais: limeyard_control (o daemon limed, que detém o socket Docker) e limeyard_ui (o painel SvelteKit). Ambos ligam-se apenas ao loopback. O painel está em http://127.0.0.1:7000 e a API crua em http://127.0.0.1:7099. Ambos precisam de .env, e LIME_TOKEN nele é obrigatório: o painel detém o token do lado do servidor e o browser nunca o vê.

página	para que serve
Targets	cada alvo, filtrar por kind e estado, ordenar, multi-seleção com Start, Stop, Restart. Clique numa linha para o alvo
Target	factos (endereço, credenciais, stack, upstream, verificação, digests de imagens), o log em direto, e a chave de respostas com os seus negativos
Scenarios	a infraestrutura: resolver, zonas, sub-rede, e uma tabela de hosts com o estado por contentor. Levantar, baixar, reiniciar
Scorecard	a última execução com deltas, cobertura por classe e por alvo, ids falhados, um histórico que pode ver, e um diff de duas execuções
Ports	o que se liga em localhost, e o que só existe na bridge do laboratório
Doctor	uma lista de verificações com um veredicto cada. Fix e Fix all mostram primeiro os comandos exatos e edições de ficheiros, calculados a partir do laboratório tal como está, e executam-nos após confirmação. Um fix que deixa a sua verificação a falhar di-lo
Credits	quem escreveu cada alvo e sob que licença