Escolha o ponto de observação certo para uma análise de VPN no telemóvel

Uma avaliação autorizada de uma VPN alojada num telemóvel falha em silêncio quando o scanner está do lado errado do túnel. Obtêm-se resultados, parecem plausíveis e respondem a uma pergunta que ninguém fez. Percorra as cinco verificações abaixo por ordem. Cada uma tem uma condição de paragem, e parar cedo custa menos do que voltar a testar de zero depois de o relatório estar escrito.

Passo 1: nomeie a superfície que pretende alcançar

Três superfícies são habitualmente confundidas porque um único dispositivo as liga. Executam código e políticas diferentes, por isso registe qual está dentro do âmbito antes de começar seja o que for.

Se o âmbito aprovado não disser qual das três, pare e pergunte. Obter root no telemóvel não responde a esta pergunta e altera a coisa testada, não o ponto de observação.

Registe os alvos, os endereços de origem permitidos, a janela temporal e o limite de intensidade ao mesmo tempo. O túnel leva-o até esse âmbito; não o autoriza a sondar tudo o que consegue encaminhar.

Passo 2: escolha a origem que consegue ver essa superfície

Um scanner colocado dentro da VPN não consegue reproduzir um observador de internet não autenticado. Já tem rotas, credenciais e permissões de que o observador externo não dispõe, por isso os seus resultados descrevem a vista após a admissão, mesmo quando a superfície alvo é a mesma. O erro inverso é igualmente comum. Uma análise pública da porta VPN quase nada diz sobre um serviço privado atrás do início de sessão, e apresentá-la como se dissesse exagera a exposição numa direção e subestima-a na outra.

Pare se a origem que consegue obter não corresponder à superfície. Uma avaliação executada a partir de um par dentro do túnel não deve ser apresentada como resultado anterior à autenticação, e um teste que exige uma origem externa aprovada não deve ser deslocado em silêncio para dentro para evitar a papelada.

Passo 3: confirme a rota e o caminho de resposta através do telemóvel

Quando o dispositivo reencaminha para outra sub-rede, o scanner precisa de uma rota permitida e o alvo de um caminho de retorno que funcione. Confirme ambos em vez de presumir que uma resposta a ping significa que o caminho está completo.

ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8

O NAT de origem altera o que o serviço a jusante vê. Se o telemóvel traduzir o endereço do scanner, as regras de acesso e os registos no alvo aplicam-se ao endereço traduzido, por isso um serviço que parece aceitá-lo pode estar a aceitar o telemóvel e não o scanner.

Atente também numa sobreposição com a rede do próprio scanner. Se o telemóvel encaminhar 192.168.1.0/24 e o scanner estiver numa LAN numerada da mesma forma, as sondas atingem dispositivos locais e o relatório descreve-os como o alvo. Verifique a rota que o próprio scanner usaria antes de enviar um único pacote.

Analise o endereço real do alvo e conserve o nome de anfitrião de que a aplicação precisa para a identidade TLS e o alojamento virtual. Alcançar um gateway prova que o gateway responde; não testa o serviço por trás dele.

Passo 4: trate a descoberta como uma sonda com pressupostos

A descoberta de anfitriões é onde os resultados da avaliação falham mais vezes. A descoberta local por Ethernet não atravessa uma VPN encaminhada, por isso as sondas que funcionam numa LAN plana simplesmente não chegam. As sondas de descoberta bloqueadas fazem então com que um serviço acessível e autorizado pareça ausente.

Decida conscientemente se ignora a descoberta e analisa diretamente os endereços conhecidos, e diga-o no relatório. Uma porta que responde não é prova de que a autenticação VPN teve êxito, e uma resposta filtrada não é prova de que nada esteja à escuta. O ritmo faz parte do mesmo problema. Um telemóvel que limita ou descarta pacotes durante uma análise rápida produz estados filtrados que pertencem ao telemóvel e não ao serviço, por isso reduza a concorrência e volte a analisar antes de registar uma porta como fechada.

A condição de paragem aqui é de interpretação, não de técnica: se não conseguir dizer o que um estado significa para este caminho, o resultado pertence a um anexo e não às conclusões.

Passo 5: mantenha a janela e depois feche-a

Um telemóvel é um mau servidor porque foi concebido para dormir. A otimização da bateria, o doze e a gestão de energia Wi-Fi podem suspender a aplicação a meio da avaliação, e uma reconexão do túnel pode alterar o endereço usado pelo alvo. Uma execução que atravesse um desses eventos tem uma janela de resultados inválida.

Mantenha o papel de gateway no âmbito mais pequeno que a tarefa aprovada permite, observe o túnel enquanto a execução está ativa e registe o início e o fim de cada janela que reportar. Quando a avaliação terminar, remova o acesso temporário através do respetivo proprietário, conserve o registo de origem e rota e proteja a saída como qualquer outro artefacto de teste.

Se precisa de um ponto de observação repetível em vez de um sucesso pontual, é essa a entrega pela qual vale a pena argumentar.a referência sobre descoberta de anfitriões explica que sondas pressupõem um segmento local, e é esse detalhe que transforma um resultado vazio numa afirmação defensável.