limeyard

Laboratório Docker deliberadamente vulnerável com um domínio DNS roteável e chaves de resposta legíveis por máquina por alvo, avaliando localmente a precisão, a revocação e o escopo do scanner.

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.

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:

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:

À mão, sem o instalador:

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

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

Estrutura

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ê.

O painel atualiza-se sozinho: o limed transmite transições de estado por SSE, por isso um alvo iniciado a partir da CLI aparece sem refresh. O cabeçalho transporta a CPU, RAM e disco livre do host a partir do mesmo stream, coloridos apenas quando vale a pena notar. Cada tabela ordena ao clicar no cabeçalho de uma coluna; um segundo clique inverte a direção.

Após uma alteração ao painel ou ao daemon, reconstrua o par:

Para trabalhar no painel contra um daemon em execução sem reconstruir a imagem:

API

Todas as chamadas exceto /api/health precisam de X-Lime-Token.

Redes

Três níveis, porque um era o problema original.

• lime-web bridge. Alvos web e API, publicados em 127.0.0.1:70xx.
• lime-lab bridge, 10.66.0.0/16, IPs estáticos, sem binding ao host. Um scanner junta-se a esta rede como contentor e vê uma sub-rede real com hosts reais e portas reais em vez de uma lista de portas de loopback.
• lime-edge o nível WAF, com a origem alcançável mas ausente do DNS.

O DNS é BIND autoritativo em zonas .test (a RFC 6761 reserva-o). Os aliases de rede Docker deliberadamente não são a fonte de verdade: nunca aparecem numa transferência de zona, e fariam a topologia discordar da chave de respostas.

Portas

Pontuação

Cada alvo inclui um truth.yml. O scorer transforma os findings em precisão, recall e F1, por alvo e por classe:

Três coisas são contadas, não uma. Recall: encontrámos o que lá está. Precisão: evitámos reportar o que não está, medido contra as entradas negative que cada chave de respostas carrega. Âmbito: o que corretamente não tentámos, registado para que ninguém o reabra a cada trimestre.

O alvo mirage existe apenas para o segundo. Nada nele é vulnerável e tudo nele parece que é, por isso qualquer finding contra ele é um falso positivo por construção.

Contribuir

O CONTRIBUTING.md tem tudo: o que uma contribuição normalmente é, os invariantes que ./lime audit impõe, e porque uma correção a uma chave de respostas vale mais aqui do que uma nova funcionalidade. A versão curta das regras está abaixo. Todos os que participam estão vinculados ao código de conduta.

Adicionar um alvo

Regras que mantêm o laboratório limpo:

• Ligar apenas a porta do alvo, a 127.0.0.1.
• Alvos de contentor único juntam-se apenas a [lime-web]. Não adicione uma rede por projeto: demasiadas redes e o Docker fica sem pool de endereços.
• Alvos com uma base de dados juntam-se a [default, lime-web] e colocam a base de dados em [default] apenas. Cada alvo tem o seu próprio serviço de base de dados e volume.
• Alvos que existem para ser descobertos em vez de navegados juntam-se a [lime-lab] com um IP estático e não publicam nenhuma porta de host.
• upstream é obrigatório. lime doctor falha um alvo sem ele e o gestor recusa registar um. Ver abaixo.
• O limeyard não inclui código-fonte de terceiros. Coloque repo: e compose: no manifesto e a fonte é obtida em runtime para <target>/src em vez disso.
• Registe quanto custa. Inicie-o, deixe-o estabilizar, e ./lime measure <slug> imprime o bloco resources para colar. O instalador e o painel somam estes para avisar alguém antes de o iniciar, por isso um palpite aqui é uma mentira ali.

Confiança e isolamento

Os alvos são software deliberadamente vulnerável de outras pessoas, por isso a proveniência é registada em vez de assumida, e o runtime é restringido em vez de confiado. O SECURITY.md tem o quadro completo; a versão curta:

• Cada imagem é fixada por digest, não uma tag flutuante, ao digest que foi obtido e testado aqui. ./lime pin reporta desvios.
• Os publishers estão documentados por imagem: Docker Official Images, contas de organizações de projetos (OWASP, ISC, Traefik, Prometheus), ou o namespace próprio do autor. Os dois elos mais fracos, raesene/bwapp (arquivado, último rebuild em 2022, sem licença) e delfer/alpine-ftp-server (um indivíduo), são nomeados como tal.
• Cada serviço corre com no-new-privileges, cap_drop: ALL mais um mínimo cap_add por imagem, um teto de pids e um teto de memória. Os níveis de base de dados ficam em redes internal: true sem rota para fora.
• O limed detém o socket Docker, que é root no host, por isso exige um segredo partilhado em cada chamada. Um alvo comprometido pode alcançá-lo e não aprender nada.
• ./lime audit falha em privileged, host networking, uma montagem de socket num alvo, um bind fora do loopback, uma imagem não fixada ou um token em falta.

Nada aqui defende contra uma fuga de contentor ao nível do kernel. Para isso, use uma VM descartável.

Atribuição

Quase tudo aqui foi escrito por outra pessoa, e vários alvos não declaram licença alguma. Por isso creditar o autor é um requisito obrigatório, não uma convenção:

• target.yml carrega um bloco upstream obrigatório: autor, repo, licença, e a data em que verificámos pela última vez que compila. packager regista a pessoa que containerizou algo quando isso difere de quem o escreveu.
• Cada cartão do dashboard mostra o autor sob o nome do alvo, ligado à fonte, com a licença ao lado. Uma licença de none declared é apresentada como um aviso, que é também o sinal de não-redistribuir.
• A vista de detalhe de cada alvo abre com um bloco de crédito, acima da lista de vulnerabilidades, com a nossa chave de respostas claramente separada da documentação do próprio upstream.
• /credits na UI e ./lime credits listam cada alvo, autor e licença. ./lime credits --markdown regenera a secção abaixo.

Créditos

O limeyard executa o trabalho de outras pessoas. Cada alvo e cenário abaixo foi construído por outra pessoa a menos que diga Clickswave.

api

bench

control

cve

edge

mobile

scenario

service

web