Exploiter un serveur web ne consiste pas seulement à servir une page : il faut contrôler son écoute, sécuriser l'accès administratif, analyser le trafic et prouver que les données importantes peuvent être restaurées. Ce projet fondé sur des défis relie ces responsabilités dans quatre scénarios Linux dont l'état final est vérifié.
Vous provisionnerez Nginx sur un port personnalisé, installerez une clé publique SSH, auditerez les sockets en écoute, réduirez un journal d'accès à son client le plus actif et réaliserez un test destructif de restauration depuis une archive compressée. Les tâches donnent exigences et indices, mais vous laissent choisir les commandes et la méthode de vérification.
Ce que vous apprendrez
- Installer Nginx, déplacer son écoute par défaut vers le port
8080, déployer le contenu demandé et redémarrer le service - Générer une paire de clés SSH RSA, autoriser la clé publique et imposer les permissions
700et600aux chemins SSH - Lister numériquement les sockets TCP en écoute et confirmer que le port SSH
22est exposé - Construire un pipeline de traitement de texte qui compte les requêtes par IP source et extrait le client le plus actif
- Archiver
/var/www/htmlet/var/log/nginxdans un tar compressé avec gzip et inspecter son contenu - Simuler la perte de la racine web, extraire l'archive dans
/et vérifier le retour du contenu critique
À qui s’adresse ce cours
Ce projet s'adresse aux personnes apprenant Linux et le DevOps prêtes à appliquer leurs compétences en service web, SSH, traitement des logs et sauvegarde sans commandes pas à pas.
Prérequis : Connaître la gestion des paquets et services, l'édition de texte, les pipelines shell, les fichiers SSH, les permissions, l'inspection des sockets et tar ; il s'agit d'un projet d'évaluation.
Environnement d’apprentissage : Un hôte Ubuntu accessible dans le navigateur avec sudo, APT, Nginx, les outils OpenSSH, Zsh, les utilitaires GNU/Linux standard et des données web et de logs préparées ; aucun cloud ni serveur distant n'est requis.
Questions fréquentes
Le défi SSH désactive-t-il complètement l'authentification par mot de passe ?
Non. Il génère /home/labex/.ssh/id_rsa, ajoute la clé publique à authorized_keys et corrige les permissions. Il ne modifie pas sshd_config, ne désactive pas les mots de passe et ne teste pas de connexion distante.
Vais-je fermer les ports réseau inattendus ?
Non. Vous utilisez ss ou netstat pour lister numériquement les ports TCP en écoute et confirmer le port 22 ; aucune règle de pare-feu ni aucun service n'est modifié.
Comment le client le plus actif est-il identifié ?
Vous analysez le premier champ de /var/log/nginx/access.log, regroupez et comptez les IP, triez par fréquence et enregistrez uniquement la première, 203.0.113.42, dans /home/labex/attacker_ip.txt.
Qu'est-ce qui est réellement supprimé et restauré pendant le test ?
L'archive contient la racine web et les logs Nginx, mais la perte simulée supprime /var/www/html. Vous extrayez l'archive à la racine et vérifiez le retour de index.html contenant Critical Web Content.
