Verificar uma atualização conforme o plano de mudanças de rede

NmapBeginner
Pratique Agora

Introdução

A Willow Makers aprovou mover as inscrições para uma nova porta. Seu catálogo e serviço de status devem permanecer disponíveis, e o serviço de depuração deve continuar ausente. Sua tarefa é analisar as mudanças de rede resultantes e entregar uma revisão precisa da entrega, incluindo qualquer impedimento à aceitação.

O ambiente coletou uma varredura de referência real e depois executou um cenário de manutenção local. Isso é preparação de treinamento, não uma afirmação sobre o histórico de produção da noite anterior. Todos os registros são sintéticos; os serviços HTTP reais compartilham um contêiner. Use Terminal durante todo o laboratório. Somente 127.0.0.4 e as portas TCP 8410,8420,8430,8440,8450 estão no escopo. Preserve referência, plano, código dos serviços, dados e processos atuais originais. Você cria varreduras, downloads e uma análise; não repara este cenário de observação.

Bastam entrada básica no terminal e caminhos. Os conceitos necessários de Nmap, Ndiff, HTTP e a sintaxe do shell são explicados. Finding the Live Workshop Service é uma preparação útil; não é necessário programar.

Ler o plano e um serviço funcional

Primeiro estabeleça o que foi aprovado e veja uma resposta normal antes de interpretar mudanças. Comece em Terminal. cd muda o diretório de trabalho deste shell; os nomes relativos seguintes usam esse diretório como referência. Repita o comando se abrir outro terminal.

cd /home/labex/project/nmap-change

cat mostra um arquivo de texto. Leia o plano aprovado:

cat plan.csv

CSV significa valores separados por vírgulas: a primeira linha nomeia as colunas e cada linha posterior é um registro. old_port e new_port descrevem a relação do serviço, não a ordem da varredura. As linhas aprovam mover inscrições de 8410 para 8420, manter catálogo na 8430 e status na 8440 e manter depuração ausente na 8450. Portanto, uma nova porta de inscrições aberta é uma mudança esperada; qualquer outra abertura não é automaticamente aprovada.

O before.xml preparado é XML Nmap autêntico de antes desta atualização de treinamento. before-business.csv contém a resposta completa de inscrições obtida naquela ocasião. Leia a amostra normal de negócio:

cat before-business.csv

Espere três registros registration de MAKERS-DAY: R01/Clay session, R02/Print session e R03/Wood session. Você exigirá o mesmo negócio completo após a migração.

HTTP é o protocolo de requisição/resposta destes serviços. curl obtém uma URL. As opções combinadas -fsS falham em um erro HTTP, ocultam o progresso e ainda mostram erros; -o salva a resposta no arquivo seguinte. O endereço escolhe o destino, a porta após os dois-pontos escolhe o ponto de escuta e /manifest.csv o recurso. Baixe o serviço de status que não mudou:

curl -fsS -o status.csv http://127.0.0.4:8440/manifest.csv
cat status.csv

Espere status/MAKERS-DAY/S01/Ready abaixo do cabeçalho. Esta resposta bem-sucedida é seu controle, não prova de que todos os serviços previstos sobreviveram. Se digitar um nome de arquivo incorretamente, leia o erro, use pwd para mostrar o diretório atual e repita o cd inicial antes de tentar o comando corrigido. Não edite os arquivos nem os servidores preparados.

Coletar uma varredura atual comparável

Examine o mesmo alvo e o conjunto completo de portas da referência. Continue em Terminal, em /home/labex/project/nmap-change. Portas TCP identificam pontos de escuta. open significa que uma conexão foi aceita; closed significa que a varredura recebeu uma rejeição. Uma observação pertence a esta origem, alvo, protocolo e momento.

O Nmap descobre e examina serviços de rede. Seu conjunto padrão de portas não é este plano aprovado. -sT escolhe TCP connect sem privilégios para pacotes brutos; -Pn pula a decisão preliminar de descoberta do host para examinar cada porta selecionada. Isso não prova por si só que o alvo está ativo. -n pula a resolução reversa de nomes, -p seleciona as portas permitidas e -oX escreve XML estruturado além da saída normal. Omitir uma porta torna a comparação incompleta, não prova que seu serviço desapareceu.

O Nmap Scripting Engine, NSE, pode fazer requisições de aplicação focadas. Primeiro leia a ajuda do script escolhido com --script-help:

nmap --script-help http-title

http-title lê um título HTML. Todos os candidatos deste cenário local estão declarados como endpoints HTTP. O + inicial executa explicitamente este único script mesmo que o banco de portas não reconheça um candidato; é apropriado neste escopo HTTP conhecido, não justifica forçar scripts arbitrários em serviços não relacionados. --script-args passa seu argumento nomeado e http-title.url=/about escolhe a página descritiva.

nmap -sT -Pn -n --script=+http-title --script-args=http-title.url=/about -p 8410,8420,8430,8440,8450 -oX after.xml 127.0.0.4

Aguarde Nmap done. As portas 8420, 8440 e 8450 devem estar abertas; 8410 e 8430 fechadas. Leia os títulos reais: inscrições migrou, status permanece e depuração está acessível. Um nome convencional em SERVICE não identifica o negócio por si só. Não se exige versão exata do produto.

Se interrompeu a varredura ou usou o escopo errado, repita o comando completo corrigido para substituir after.xml. Renomear texto simples como XML não cria evidências estruturadas.

Separar diferenças de erros de execução

Use Ndiff para ler mudanças sem tratar toda diferença como falha. Continue em Terminal. Ndiff compara dois arquivos XML do Nmap; não conhece seu plano aprovado.

Um comando shell retorna um status de saída numérico. $? se refere ao comando imediatamente anterior e echo o imprime. Execute juntas as duas linhas de cada comparação para que outro comando não substitua o status. Primeiro compare a referência com ela mesma:

ndiff before.xml before.xml
echo $?

Espere 0: nenhuma diferença significativa. Ndiff ignora mudanças apenas no horário da varredura. Agora compare antes e depois. > substitui o arquivo indicado pela saída padrão do comando; use apenas o destino editável changes.txt:

ndiff before.xml after.xml > changes.txt
echo $?

Espere 1, indicando diferenças encontradas. É um status não zero intencional, não uma comparação que falhou. Uma entrada ausente ou ilegível produz status 2, um erro de execução; corrija o caminho e repita, sem interpretar um relatório ausente como ausência de mudanças.

cat changes.txt

Uma linha - descreve a observação anterior e uma + a posterior. Leia estes pares:

-8410/tcp open
+8410/tcp closed
-8420/tcp closed
+8420/tcp open
-8430/tcp open
+8430/tcp closed
-8450/tcp closed
+8450/tcp open

A saída real também inclui cabeçalhos, nomes de serviços e títulos. Status na 8440 não mudou e normalmente é omitido da visão padrão de diferenças. Você ainda precisa analisar seu requisito de preservação. O par de portas antiga/nova de inscrições pode ser aprovado enquanto a perda do catálogo e a exposição de depuração bloqueiam a entrega.

Entregar a análise de negócio e mudanças

Confirme o negócio realmente migrado e entregue uma análise completa. Continue em Terminal. Um título ou porta aberta não comprova que os registros originais sobreviveram. Baixe a resposta completa do novo endpoint:

curl -fsS -o current-business.csv http://127.0.0.4:8420/manifest.csv
cat current-business.csv

cmp compara dois arquivos byte a byte. Não imprime nada e retorna zero quando coincidem:

cmp before-business.csv current-business.csv

Você deve ver os três registros originais de inscrições MAKERS-DAY e uma comparação bem-sucedida. Se digitou a URL incorretamente, corrija e repita o download. Não edite registros para passar na comparação. Uma diferença real de negócio seria um problema de entrega mesmo com títulos de página iguais.

O CSV de análise tem quatro colunas: service, o estado atual na porta antiga, o estado atual na nova porta e a decisão. Quando um item usa uma porta fixa, inclusive requisitos keep ou absent, suas portas antiga e nova são iguais e os estados atuais se repetem. Use - somente quando não havia porta antiga; nunca significa porta fechada. As decisões distinguem approved-move, approved-addition, kept, unexpected-loss e unexpected-open. Uma migração cuja relação antiga/nova é incompleta seria migration-incomplete; uma adição aprovada ausente seria missing-addition, e um endpoint proibido que permanece fechado é kept-absent.

Um here-document com aspas passa as linhas literais seguintes para cat. > substitui apenas seu arquivo de análise; o CSV final deve ficar sozinho na linha. Escreva os quatro itens do plano:

cat > change-review.csv <<'CSV'
service,old_port_now,new_port_now,decision
registration,closed,open,approved-move
catalog,closed,closed,unexpected-loss
status,open,open,kept
debug,open,open,unexpected-open
CSV
cat change-review.csv

Esta análise indica adiar a entrega: a migração aprovada funciona, mas falta o catálogo obrigatório e depuração está exposta inesperadamente. A análise está completa mesmo que o responsável precise reparar o cenário depois. Preserve as evidências; não pare depuração nem restaure o catálogo nesta tarefa.

Por fim, use novamente o serviço de status original:

curl -fsS -o status.csv http://127.0.0.4:8440/manifest.csv

Ele deve continuar fornecendo o mesmo registro Ready. Mantenha before.xml, before-business.csv, plan.csv e todos os serviços atuais originais inalterados.

Resumo

Você coletou evidências Nmap comparáveis, interpretou status de saída do Ndiff, confirmou todo o negócio migrado e analisou cada relação de aprovação. Diferenças aprovadas, aberturas inesperadas e perdas de serviços obrigatórios são descobertas distintas. Uma análise precisa pode exigir adiar a entrega enquanto preserva o cenário original.