Implantação e Recuperação de Desastres de Servidor Web

Operar um servidor web envolve mais do que servir uma página: é preciso controlar a porta de escuta, proteger o acesso administrativo, investigar o tráfego e provar que dados importantes podem ser restaurados. Este projeto baseado em desafios conecta essas responsabilidades em quatro cenários Linux com estado final verificado.

Você provisionará Nginx em uma porta personalizada, instalará uma chave pública SSH, auditará sockets em escuta, identificará o cliente mais ativo em um log e fará um teste destrutivo de restauração a partir de um arquivo compactado. As tarefas fornecem requisitos e dicas, mas você escolhe os comandos e o fluxo de verificação.

O que você aprenderá

• Instalar Nginx, alterar sua escuta padrão para a porta 8080, implantar o conteúdo solicitado e reiniciar o serviço
• Gerar um par de chaves SSH RSA, autorizar a chave pública e aplicar permissões 700 e 600 aos caminhos SSH
• Listar numericamente sockets TCP em escuta e confirmar que a porta SSH 22 está exposta
• Construir um pipeline de texto que conta requisições por IP de origem e extrai o cliente mais ativo
• Arquivar /var/www/html e /var/log/nginx em um tar compactado com gzip e inspecionar seu conteúdo
• Simular a perda da raiz web, extrair o arquivo em / e verificar o retorno do conteúdo crítico

Para quem é este curso

Este projeto é indicado para estudantes de Linux e DevOps prontos para aplicar habilidades de serviço web, SSH, processamento de logs e backup sem comandos passo a passo.

Pré-requisitos: Familiaridade com pacotes e serviços, edição de texto, pipelines shell, arquivos SSH, permissões, inspeção de sockets e tar; é um projeto de avaliação.

Ambiente de aprendizagem: Um host Ubuntu acessível pelo navegador com sudo, APT, Nginx, ferramentas OpenSSH, Zsh, utilitários GNU/Linux e dados web e de logs preparados; não requer nuvem nem servidor remoto.

Perguntas frequentes

O desafio SSH desativa completamente a autenticação por senha?

Não. Ele gera /home/labex/.ssh/id_rsa, adiciona a chave pública a authorized_keys e corrige permissões. Não altera sshd_config, desativa senhas nem testa login remoto.

Vou fechar portas de rede inesperadas?

Não. Você usa ss ou netstat para listar numericamente portas TCP em escuta e confirmar a porta 22; firewall e serviços não são alterados.

Como o cliente mais ativo é identificado?

Você agrupa, conta e ordena o primeiro campo de /var/log/nginx/access.log e salva apenas 203.0.113.42 em /home/labex/attacker_ip.txt.

O que é realmente excluído e restaurado no teste?

O arquivo inclui a raiz web e logs do Nginx, mas a simulação exclui /var/www/html. Você extrai na raiz e confirma o retorno de index.html com Critical Web Content.