Introdução
O site de suporte da Northstar oferece páginas de ajuda e downloads autorizados. Um download incomum de um arquivo empacotado sugere que um backup interno foi armazenado por engano junto aos arquivos públicos. Você é o engenheiro de plantão com acesso de manutenção ao site.
Você rastreará a requisição, relacionará sua URL a um arquivo no servidor web, moverá o backup para um armazenamento privado e verificará se o site de suporte continua funcionando. Basta ter familiaridade básica com o terminal; os códigos de status HTTP e o mapeamento da raiz web são apresentados aqui. Todos os registros e todo o tráfego são sintéticos.
Investigue o download suspeito
Nesta etapa, você rastreará um download suspeito, obterá o arquivo empacotado e verificará se ele contém dados internos.
Seu ambiente está pronto. Workstation é o terminal cliente, já no diretório /home/labex/project. Web Server é um terminal de manutenção já conectado ao servidor do site. Alterne entre essas abas conforme as instruções. Topology mostra a relação entre eles e a acessibilidade atual do site.
Abra Topology para localizar o cliente e o servidor e volte para Workstation. O status mostra se a página inicial responde; ele não indica se os arquivos privados estão protegidos.
Confirme o acesso normal
Use Workstation. curl envia uma requisição HTTP e imprime sua resposta. -sS oculta o progresso, mas ainda mostra erros de conexão. O endereço 127.0.0.1:8081 é o endpoint do site acessível a partir de Workstation. 127.0.0.1 significa a máquina local: em Web Server, o mesmo endereço se refere ao próprio servidor, e não a Workstation.
curl -sS http://127.0.0.1:8081/
A resposta contém Northstar Support e links para a ajuda e o guia do produto. Um diretório público, ou raiz web, é o diretório do sistema de arquivos cujo conteúdo o servidor disponibiliza por meio de URLs.
O guia do produto é intencionalmente público. Obtenha-o antes de alterar qualquer coisa:
curl -sS http://127.0.0.1:8081/downloads/product-guide.txt
A primeira linha é Northstar Product Guide. O exemplo autorizado em /downloads/public-examples.tar também é público e deve continuar disponível, mesmo que seu nome indique um arquivo empacotado.
Rastreie o download
Alterne para Web Server. cat imprime um arquivo de texto:
cat /var/log/nginx/site-access.log
Nginx é o servidor web que atende a essas requisições. Cada linha do log de acesso registra um endereço de cliente, horário, requisição, código de status, tamanho da resposta em bytes e agente de usuário. GET solicita um recurso; o agente de usuário identifica o software que fez a requisição. 200 significa que o servidor retornou uma resposta bem-sucedida; 404 significa que o recurso solicitado não foi encontrado. O encaminhamento de rede pode afetar o endereço de cliente registrado, então não presuma que ele identifica uma pessoa. As entradas TopologyHealth/1.0 são verificações de integridade da própria visualização do ambiente.
Procure requisições com falha, como /admin, seguidas de uma requisição bem-sucedida para /backups/support-backup.tar. Para filtrar o log, use grep, que imprime as linhas correspondentes ao texto informado:
grep 'support-backup.tar' /var/log/nginx/site-access.log
A linha correspondente deve incluir GET /backups/support-backup.tar e o status 200. Isso sugere um download, mas é necessário examinar a resposta antes de concluir que dados internos foram expostos. Por exemplo, os campos estáveis da linha relevante são assim:
... "GET /backups/support-backup.tar HTTP/1.1" 200 10240 ... "ExternalClient/1.0"
O endereço e o horário variarão. O caminho, a resposta bem-sucedida e o conteúdo do arquivo são as pistas úteis.
Confirme a exposição do backup
Volte para Workstation. -o grava a resposta no arquivo indicado em vez de imprimi-la:
curl -sS -o /home/labex/project/support-backup.tar http://127.0.0.1:8081/backups/support-backup.tar
tar lê arquivos empacotados. -t lista seus membros e -f seleciona o arquivo:
tar -tf /home/labex/project/support-backup.tar
Você deve ver internal-customers.txt. -x extrai um membro; -O envia seu conteúdo ao terminal sem gravar arquivos extraídos:
tar -xOf /home/labex/project/support-backup.tar internal-customers.txt
O conteúdo começa com INTERNAL ONLY e descreve registros sintéticos de clientes. Isso confirma que a resposta bem-sucedida continha dados internos, e não um arquivo público autorizado.
Mova o backup para um armazenamento privado
Nesta etapa, você removerá o backup interno do site público, preservando seu conteúdo para manutenção. Use Web Server para localizar o arquivo público e aplicar a correção.
Localize o arquivo público
Alterne para Web Server e leia a configuração do site:
cat /etc/nginx/conf.d/default.conf
root /srv/site; mapeia /backups/support-backup.tar para /srv/site/backups/support-backup.tar. autoindex off; desativa a listagem de diretórios, mas não bloqueia o acesso direto a um nome de arquivo conhecido. Arquivos sem links não são necessariamente privados.
A opção -l mostra uma listagem detalhada com tamanho, proprietário e permissões de acesso. Use-a para inspecionar o arquivo público:
ls -l /srv/site/backups/support-backup.tar
O caminho exibido confirma que o arquivo está dentro da raiz web configurada.
Preserve o backup fora do site
O diretório privado /srv/private-backups já existe fora de /srv/site. Você tem privilégios de manutenção dentro deste contêiner de destino. mv move um arquivo mantendo seu conteúdo:
mv /srv/site/backups/support-backup.tar /srv/private-backups/support-backup.tar
O site não consegue servir esse arquivo pelo mapeamento normal do diretório público. Isso também preserva o backup para manutenção autorizada, em vez de excluí-lo. Não é necessário recarregar o Nginx, pois apenas a localização do arquivo mudou, não a configuração do servidor.
Confirme em Web Server que a cópia privada ainda pode ser lida:
tar -xOf /srv/private-backups/support-backup.tar internal-customers.txt
Você deve ver os mesmos registros internos de teste.
Verifique a confidencialidade e a disponibilidade do site
Nesta etapa, você testará o limite de acesso final e confirmará que os recursos públicos autorizados continuam funcionando.
Volte para Workstation. -o /dev/null descarta o corpo da resposta, e -w imprime as informações de resposta solicitadas. %{http_code} seleciona o status HTTP; \n adiciona uma quebra de linha:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/backups/support-backup.tar
O resultado esperado é 404. Esse comando curl ainda termina com sucesso: uma resposta de erro HTTP é diferente de uma falha de conexão. Parar o servidor faria as verificações de disponibilidade do curso falharem.
Verifique as páginas normais e os downloads autorizados com o mesmo método:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/help.html
curl -sS http://127.0.0.1:8081/downloads/product-guide.txt
curl -sS -o /home/labex/project/public-examples.tar http://127.0.0.1:8081/downloads/public-examples.tar
tar -xOf /home/labex/project/public-examples.tar example.txt
As páginas retornam 200. O guia começa com Northstar Product Guide, e o membro do arquivo de exemplo contém Public support examples. Em Topology, Website reachable confirma que a página inicial responde, não que o vazamento foi corrigido. As verificações finais testam confidencialidade e disponibilidade separadamente.
Resumo
Você rastreou um download público até seu arquivo no servidor, moveu os dados internos para fora da raiz web e verificou que os downloads privados falham enquanto os serviços públicos continuam funcionando.
