Nessus através de VPN: onde colocar o scanner antes da primeira análise

Um ícone de VPN junto ao navegador não diz nada sobre o processo que envia os pacotes de análise. Se a consola e o scanner forem executados em anfitriões diferentes, o túnel do navegador é um caminho e a origem da análise é outro. Comece pelo ponto de execução e avance para fora: a rota, a autorização e as credenciais. Essa distinção é o primeiro item da lista por uma razão.

Esta é uma lista de verificação prévia ao lançamento, não um tutorial de análise. Cada passo produz um facto que pode registar no processo do trabalho antes de qualquer pacote sair do scanner.

Ponto um: localizar o processo que envia as sondas

Desenhe as três funções de forma explícita: o navegador no portátil A, a consola de análise no anfitrião B e o alvo privado C. Se B também executar o motor de análise, o navegador só precisa de um caminho para B. Se o trabalho for feito por um equipamento de análise separado, esse equipamento precisa do caminho para C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Um navegador ligado à VPN pode alcançar a consola enquanto o scanner por trás dele continua sem rota para C. O inverso também é possível: o scanner está dentro da rede privada e a consola é remota. Descubra qual é a disposição que realmente executa antes de alterar qualquer controlo de rede. Nomeie o equipamento na configuração da análise antes de culpar a rede.

Se o scanner for executado em A, o anfitrião do navegador e o scanner partilham um contexto, mas apenas enquanto esse processo mantiver o mesmo espaço de nomes e a mesma tabela de rotas. Um contentor ou uma conta de serviço podem não herdar o que o navegador interativo vê. A consola é uma superfície de gestão, não o motor de análise.

Ponto dois: provar a rota e o DNS do scanner

Execute a verificação de rota no anfitrião do scanner, não no portátil. Pergunte ao núcleo qual a interface e o gateway que usaria para o endereço do alvo e repita para o nome do anfitrião do alvo. Uma rota que existe para o IP e um nome que resolve para outro endereço são duas falhas diferentes.

Confirme o endereço de origem que aparecerá no alvo. Um cliente VPN pode atribuir um endereço diferente do que a firewall do alvo espera, e um dispositivo NAT pode reescrevê-lo novamente. O proprietário do alvo precisa da origem observada, não do endereço impresso no perfil da VPN.

Verifique também o caminho de retorno. Um scanner que alcança o alvo mas não recebe respostas tem um problema de encaminhamento ou de firewall no regresso, e isso parece exatamente igual a um alvo em baixo.

Ponto três: obter autorização para o âmbito e o ponto de vista

Peça ao proprietário do alvo que indique por escrito os sistemas, serviços, ambiente, origem e janela temporal. Decida qual ponto de vista a avaliação representa: um utilizador de VPN externo, um cliente interno admitido ou um segmento de scanner específico.

Uma rota privada não é autorização para testar redes adjacentes. Mantenha a lista de alvos restrita, enumere os sistemas excluídos e acorde condições de paragem e um contacto que possa interromper a execução. O scanner sonda de bom grado tudo o que consegue alcançar, e é precisamente por isso que o âmbito tem de ser explícito.

Registe a origem aprovada no mesmo documento. Se a origem observada pelo scanner diferir da aprovada, a execução não representa o ponto de vista acordado, mesmo que a lista de alvos esteja correta.

Ponto quatro: ajustar as credenciais à profundidade da avaliação

Uma verificação de acessibilidade e uma avaliação autenticada são testes diferentes. Uma resposta de porta prova que algo respondeu; não prova que foram executadas verificações com credenciais nem que a aplicação autorizou a conta.

Utilize credenciais dedicadas apenas quando o âmbito acordado exigir verificações autenticadas. Confirme as permissões e a política de bloqueio da conta e decida como os resultados serão armazenados e partilhados antes de a análise os produzir.

Se as credenciais falharem, não passe em silêncio para uma execução não autenticada nem rotule o relatório como a avaliação planeada. O resultado é um teste diferente com um significado diferente, e essa diferença pertence ao relatório.

Ponto cinco: guardar o plano e lançar com deliberação

No fluxo de trabalho de análise do Nessus, escolher um modelo, configurar as definições e guardar ou lançar a análise são passos separados. Aproveite essa separação para rever a lista de alvos, a origem e o agendamento antes de começar qualquer tráfego.

Antes de autorizar o lançamento, verifique que origem a VPN permite, que tráfego transporta e como recupera de um túnel caído. Não alargue o acesso da firewall só porque uma ligação preliminar falhou; encontre a camada que a recusou e corrija essa camada.

Depois da execução, registe o anfitrião do scanner, a origem observada, a lista de alvos e todas as verificações que não foi possível concluir. Um relatório produzido a partir de outra origem ou sem as credenciais previstas não representa o plano original, e dizê-lo faz parte do entregável.

Retire os acessos do trabalho e trate os resultados conservados segundo o processo acordado. A lista de verificação só está concluída quando as provas correspondem ao caminho que aprovou, não quando a análise se limitou a devolver resultados.