APRENDER. PRATICAR. EVOLUIR.Um contrato de acesso verificável
Descreve o contrato antes de testar: que conta, protocolo, servidor, partilha, caminho e operações são necessários? Uma aplicação de fundos pode criar um temporário, escrever conteúdo, publicar um nome final e esperar que outro consumidor leia o resultado. Uma listagem bem-sucedida cobre apenas parte desse percurso. Prepara uma matriz com operação, identidade, resultado esperado e evidência observada. Acrescenta testes negativos relevantes, como impedir escrita onde só deve existir leitura. A conectividade TCP é uma condição inicial, não a conclusão. No ensaio desta oficina, o cliente fixa e confirma SMB 2.0.2, usa uma conta fictícia e acede apenas a partilhas descartáveis em loopback. O relatório identifica essas condições para tornar a conclusão auditável.
Autenticação e negociação observadas
O primeiro grupo inicia um servidor Impacket 0.13.1 restrito a 127.0.0.1 numa porta efémera. Uma password fictícia errada devolve STATUS_LOGON_FAILURE; a credencial definida para o laboratório é aceite. Dois clientes usam depois sessões próprias com o dialeto observado. Não há domínio empresarial neste ensaio. A distinção importa numa investigação: autenticação válida não prova que a conta corresponde ao utilizador de produção, que Kerberos funciona ou que uma política de cifragem foi cumprida. Regista o mecanismo e as propriedades efetivamente avaliadas. Para a entrada em produção, prepara testes com os clientes e identidades previstos e confirma a política de segurança aplicável ao caminho real.
Ler e escrever são decisões diferentes
No segundo grupo, a partilha RO permite listar e ler reference.txt. Criar attempt.txt devolve STATUS_ACCESS_DENIED e o ficheiro não aparece. Este resultado demonstra a regra de leitura da partilha nessa implementação, sem testar ACLs do host. Num serviço real, a identidade efetiva, a configuração da partilha e as permissões do caminho precisam de ser consideradas. Em NFS AUTH_SYS, um nome igual nos clientes pode esconder identificadores numéricos diferentes; root_squash pode alterar a identidade usada pelo servidor. Não resolvas a primeira recusa com privilégios amplos. Localiza o controlo responsável, define o acesso mínimo necessário e repete a operação funcional com a conta prevista.
Executar a cadeia de operações
O terceiro grupo carrega draft.tmp com BATCH-READY-17, lê-o através do segundo cliente, renomeia para ready.dat, volta a ler e remove o ficheiro. O nome antigo deixa de estar disponível após a mudança. A sequência testa os bytes e as operações exigidas pelo pequeno fluxo, não o processamento de uma instrução financeira. Também não corta energia nem prova durabilidade após crash. Usa esta distinção ao construir critérios de aceitação: a entrega técnica pode passar e o consumidor ainda falhar a validação do conteúdo. Se o batch escreve numa pasta local porque a montagem esperada não existe, o seu sucesso também pode não representar entrega remota. Confirma sempre o destino efetivo.
Interpretar a etapa da falha
O quarto grupo tenta ligar à partilha ABSENT e ler absent.txt numa partilha válida. Nesta versão Impacket, o primeiro pedido devolve 0xc000003a e o segundo 0xc000000f. A expectativa inicial para a partilha era diferente; a leitura do código smb2TreeConnect confirmou o resultado observado e permitiu corrigir a expectativa. A lição é usar documentação e implementação relevantes, em vez de impor um código memorizado a todos os servidores. Uma resposta de erro também indica que algum componente respondeu; não é equivalente a timeout de transporte. Num incidente, junta etapa, identidade, alvo, operação e resposta para orientar a equipa certa, preservando o contexto que permite reproduzir o problema.
Oficina: decidir a prontidão
Prepara uma tabela de aceitação para uma conta que consegue ler mas não publicar ficheiros. Explica ao sponsor qual a etapa validada, qual a etapa recusada e que evidência permitiria avançar. Inclui confidencialidade como requisito separado: assinatura SMB não equivale por si a cifragem. Um parser como testparm também não executa o fluxo do batch. O exercício local disponibiliza evidência de sete grupos SMB e um modelo de nomes, mas não executa Samba, Windows, ONTAP ou NFS. O facilitador pode avaliar clareza, proporcionalidade da correção e critérios de reteste. O guião foi criado para prática; nenhuma sessão humana foi realizada. Resume relacionando autorização, operação e resultado do consumidor.
python3 -m venv /tmp/dr-nas-lab
/tmp/dr-nas-lab/bin/python -m pip install -r content/labs/nas-evidence/requirements.txt
/tmp/dr-nas-lab/bin/python content/labs/nas-evidence/run.py
# Only 127.0.0.1, temporary shares, fictional local credentials
# Recorded implementation: Impacket 0.13.1; negotiated SMB 2.0.2Num serviço fictício de fundos, a listagem da partilha funciona mas a conta do batch não consegue criar o ficheiro que deve entregar.
Armadilhas comuns
Usar ping como prova de acesso, listagem como permissão de escrita, administrador como conta de teste e assinatura como cifragem.
Tópicos relacionados: Storage · Suporte à produção L3 · Gestão de Releases
Aceita o fluxo que a aplicação precisa de executar, mantendo separadas as etapas e os limites da evidência.
Referência: Impacket 0.13.1 SMB server implementation · DR NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior