Evidência, Diagnóstico e Operação em Redes

O objetivo aqui é mostrar, na prática, a diferença entre "abrir uma conexão" e "falar um protocolo de aplicação". Ao conectar manualmente à porta 80 com telnet, você demonstra que o transporte TCP está funcional. Ao digitar uma requisição HTTP mínima com linha GET, header Host e linha em branco final, você prova que o servidor não apenas aceitou a conexão, mas recebeu bytes interpretáveis como HTTP e respondeu com status e headers.

A evidência essencial deve conter três partes: sinal de conexão estabelecida, requisição enviada corretamente e resposta recebida. Se a conexão não abre, o problema tende a estar em rota, firewall ou porta. Se a conexão abre, mas a resposta é erro ou redirecionamento, o transporte funcionou e a análise passa a ser de aplicação.

Neste exercício, o foco sai do terminal como tela momentânea e entra no território dos artefatos auditáveis. O parâmetro --trace-ascii permite registrar em arquivo o que o cliente enviou e recebeu, tornando o experimento reproduzível. A ideia não é copiar o trace inteiro, mas extrair sinais curtos: request line, alguns headers, status code e headers de resposta.

O valor técnico aparece quando você repete o teste com uma pequena mudança, como seguir redirects com -L. Nesse momento, o trace deixa de ser apenas registro e vira instrumento comparativo. Você passa a mostrar, com prova, que o comportamento do cliente mudou e que essa mudança alterou o destino ou o status final da interação.

SSH não deve ser tratado como "programa para login", mas como serviço crítico de operação. Por isso, o exercício exige três verificações complementares: o processo está ativo, a configuração relevante está coerente e a execução remota realmente funciona. Esse trio evita confundir presença do cliente ssh com disponibilidade real do servidor sshd.

A leitura da configuração pode ser feita diretamente no arquivo, mas a forma mais robusta é consultar a configuração efetiva. Em seguida, a execução de um comando remoto em localhost fecha o ciclo: o serviço está ativo, configurado e operacional. É o tipo de validação mínima que reduz improviso em ambiente real.

Aqui você aprende a olhar o host como um ponto de escuta e trânsito de conexões, não como uma caixa-preta. Portas em LISTEN indicam processos aguardando conexão. Entradas ESTABLISHED indicam sessões ativas. Endereços locais e remotos mostram quem fala com quem. E a separação entre IPv4 e IPv6 permite responder uma pergunta operacional concreta: o serviço está exposto em qual pilha de rede.

O ganho pedagógico está menos em "listar portas" e mais em interpretar estados e escopo de exposição. Um operador de verdade não para no número da porta; ele lê estado, endereço, família de protocolo e dono do socket, e transforma isso em conclusão operacional.

Saber que uma porta está aberta é útil. Saber quem a abriu é decisivo. O lsof transforma a observação de socket em evidência acionável: ele mostra processo, PID, usuário e porta. Essa correlação é o que impede que você mexa no serviço errado, reinicie o que não deveria ou perca tempo caçando um problema fantasma.

Em cenários reais, essa habilidade economiza minutos preciosos em incidentes. Em laboratório, ela ensina a substituir suposição por autoria comprovada: a porta não "está aberta"; ela está aberta porque um processo específico a mantém em LISTEN sob um determinado usuário.

Este é o coração do laboratório: criar um cenário mínimo sob seu controle. Com netcat, você monta um listener TCP simples em uma porta alta e depois conecta um cliente local para enviar uma mensagem. Isso elimina variáveis externas e cria um ambiente de teste limpo, pequeno e repetível.

A força didática do exercício está em provar cada etapa: a porta em LISTEN, a conexão realizada e a mensagem recebida. É assim que se começa a pensar como alguém que trabalha com sistemas distribuídos: controlar variáveis, observar sinais e repetir o experimento sem depender de infraestrutura alheia.

Se o exercício anterior prova a troca de dados do ponto de vista da aplicação, este aqui prova do ponto de vista do tráfego. O tcpdump captura os pacotes reais e grava um arquivo .pcap, que funciona como artefato técnico verificável. Isso muda a natureza do diagnóstico: a rede deixa de ser hipótese e passa a ser evidência observável.

A captura precisa ser pequena e bem focada. Por isso, primeiro se identifica a interface correta e depois se filtra pela porta do experimento. O resultado desejado não é uma montanha de pacotes, mas um recorte preciso que mostre SYN, handshake ou payload trafegando, dependendo do momento coletado.

Até aqui, você olhou o sistema por dentro. Agora entra a perspectiva externa. O nmap permite verificar se a porta aparece como aberta para quem se conecta de fora, mesmo que o "fora" seja o próprio localhost em uma varredura local. Isso ensina uma disciplina importante: não confiar em uma única ferramenta nem em um único ângulo de observação.

Quando o nmap mostra a porta aberta e o lsof ou ss mostra quem a mantém em LISTEN, o circuito de validação se fecha. Você deixa de ter apenas uma porta aberta "aparente" e passa a ter uma cadeia causal verificável: serviço em escuta, visível externamente, associado a um processo específico.

Nem todo diagnóstico serve apenas para provar que algo funciona. Às vezes, ele serve para provar que algo perigoso não deveria estar exposto. É o caso de serviços legados em claro, como FTP e Telnet. O exercício pede verificação objetiva da presença ou ausência dessas portas e, em seguida, uma conclusão curta sobre risco e mitigação.

A maturidade aqui está em não dramatizar nem improvisar. Se a porta não está exposta, isso já é uma evidência válida. Se estiver, a análise deve apontar risco concreto: aumento de superfície de ataque e tráfego sem criptografia. Depois disso, entram medidas mínimas e plausíveis, como bloqueio por firewall, desativação do serviço ou segmentação de rede.

Formato de entrega: evidencia minima + recorte curto + conclusao em 2-4 linhas. Sem despejar output inteiro.

Este exercício introduz mentalidade de mudança controlada. Alterar SSH em produção sem backup, teste e rollback é um clássico convite ao desastre. Por isso, o fluxo correto começa com cópia de segurança do arquivo, passa por uma alteração mínima e termina com validação de sintaxe, reinício controlado, teste funcional e plano de desfazer.

Padrao do TP para mitigacao minima: usar apenas `PermitRootLogin no`. Assim, a entrega fica comparavel e evita armadilhas para quem ainda nao configurou autenticacao por chave.

A proposta aqui é fazer a ponte entre teoria e observação. Os conceitos clássicos de programação de rede - bind, listen, accept, send e recv - não ficam restritos a livros ou código-fonte; eles aparecem materializados em estados, processos e tráfego. Um socket associado a uma porta mostra bind. Um socket em LISTEN mostra listen. Uma conexão ativa em ESTABLISHED mostra accept já ocorrido. A mensagem entregue ou o pacote capturado fecha o ciclo com send e recv.

Esse tipo de mapeamento é importante porque reduz abstração solta. Você passa a ver que a API de sockets não é um "mundo teórico separado", mas um modo de organizar o que o sistema já torna visível com ss, lsof e tcpdump.

O fechamento do TP2 não pede mais comandos isolados, mas coerência entre evidências. A ideia é selecionar um cenário simples - por exemplo, o listener na porta 55555 - e produzir uma evidência curta por ferramenta. O ss mostra LISTEN e ESTABLISHED. O lsof mostra o processo dono. O nmap mostra que a porta aparece aberta externamente. O tcpdump mostra o tráfego real.

O valor aqui está na convergência. Um diagnóstico forte não depende de uma única saída vistosa. Ele nasce quando várias ferramentas, olhando o mesmo fenômeno por ângulos distintos, contam a mesma história. Quando isso acontece, a conclusão deixa de ser opinião e passa a ser defensável tecnicamente.