Questions d'entretien Linux Internals

Non. Toute la plage 127.0.0.0/8 est réservée au bouclage, donc 127.0.0.2, 127.1.1.1, et ainsi de suite résolvent toutes vers l'hôte local. C'est crucial pour le SSRF et le contournement de listes d'autorisation — un attaquant peut utiliser 127.0.0.2 ou d'autres encodages pour esquiver un contrôle naïf « bloquer 127.0.0.1 » — et pour lier plusieurs services locaux. (En IPv6, le bouclage est l'unique adresse ::1.)

Un vide dans les journaux locaux pendant un incident peut signifier des journaux effacés ou falsifiés, une étape anti-forensique courante, donc ne traitez pas l'absence de journaux comme une absence d'activité. Recoupez avec des journaux centralisés/transférés, l'EDR et les données réseau que l'attaquant n'a probablement pas pu altérer, et consignez le vide d'intégrité comme un constat. Supposer que le serveur était inactif fait confiance à des preuves que l'attaquant contrôle peut-être, traiter le vide comme une preuve que rien ne s'est passé est exactement la conclusion qu'il veut, et supprimer d'autres journaux détruit ce qui reste. Corroborez plutôt avec une télémétrie indépendante.

La persistance Linux se cache dans les chemins d'exécution planifiée et de démarrage : cron et timers/unités systemd, clés ajoutées dans authorized_keys SSH, fichiers rc du shell et scripts de profil modifiés, et binaires de service ou bibliothèques préchargées trojanisés. Examinez-les systématiquement. L'historique du navigateur et les réglages du fond d'écran ne sont pas des mécanismes de persistance, et redémarrer ne supprimera rien qui se rétablit au démarrage — cela ne fait que le relancer. Tout l'intérêt de la persistance est de survivre aux redémarrages, donc un redémarrage ne prouve rien.

Un binaire SUID-root s'exécute avec les privilèges de root, et s'il est accessible en écriture par tous, un attaquant peut le remplacer ou le modifier pour exécuter du code arbitraire en tant que root — une voie classique d'élévation de privilèges locale. Retirez le bit SUID, corrigez le propriétaire et les permissions, et enquêtez sur l'origine de cette mauvaise configuration, car elle peut indiquer une compromission. Chiffrer le fichier laisse intact le chemin exécutable, et le renommer ne fait que déplacer le problème sans supprimer l'élévation. Aucune de ces options ne traite la cause racine.

L'ordre de volatilité classe les preuves selon leur vitesse de disparition, pour collecter les plus fragiles en premier. Grosso modo : registres/cache CPU, puis RAM et état d'exécution (processus, connexions réseau, ARP), puis fichiers temporaires/swap, puis disque, puis journalisation et données de supervision distantes, et enfin supports d'archivage et sauvegardes. On travaille aussi sur des copies forensiques, on les hashe, et on maintient une chaîne de possession pour que la preuve reste recevable.

Sous Windows, les hashes des comptes locaux (NTLM) résident dans la ruche SAM sous C:\Windows\System32\config\SAM, protégée tant que l'OS tourne ; les identifiants vivants se trouvent dans la mémoire de LSASS, et les hashes de domaine sont dans NTDS.dit sur un contrôleur de domaine. Sous Linux, les hashes sont dans /etc/shadow (lisible uniquement par root), tandis que /etc/passwd contient les métadonnées de compte. Les attaquants les volent pour casser les mots de passe hors ligne ou faire du pass-the-hash.

On commence par un scan complet des ports TCP, puis on énumère en profondeur chaque service ouvert — bannières, versions, identifiants par défaut, accès anonyme et contenu web — avant de toucher au moindre exploit. La plupart des machines tombent grâce à une énumération minutieuse, pas à des exploits astucieux, ce qui est le cœur de l'état d'esprit « try harder ».

Énumérez méthodiquement : vérifiez sudo -l, les binaires SUID/SGID, les tâches cron, la version du noyau et de l'OS, les fichiers inscriptibles dans des chemins privilégiés, les capabilities et les identifiants stockés. Des outils comme LinPEAS automatisent le balayage, mais vous vérifiez chaque découverte avec GTFOBins ou une technique connue.

Identifiez le service et la version exacts, cherchez sur Exploit-DB ou searchsploit un PoC correspondant, puis lisez le code ligne par ligne avant de l'exécuter — corrigez l'IP cible, le port et l'adresse du reverse shell, régénérez tout shellcode, et comprenez ce qu'il fait pour qu'il ne se retourne pas contre vous.

On lance un pseudo-terminal (généralement python -c 'import pty; pty.spawn("/bin/bash")'), on le met en arrière-plan avec Ctrl-Z, on exécute stty raw -echo côté local, on le remet au premier plan, puis on réinitialise TERM et le nombre de lignes/colonnes. On obtient un TTY complet avec contrôle des tâches, complétion par tabulation et éditeurs fonctionnels.

Énumérez d'abord : privilèges actuels, droits sudo, binaires SUID/SGID, tâches cron, fichiers inscriptibles dans le PATH, version du noyau et identifiants stockés. Puis exploitez le chemin le plus simple et fiable — souvent une règle sudo mal configurée ou un GTFOBin SUID — avant de recourir à un exploit du noyau.

Un bind shell ouvre un port d'écoute sur la cible et attend que vous vous y connectiez. Un reverse shell fait que la cible se connecte en sortie vers un écouteur que vous contrôlez. Les reverse shells l'emportent généralement car le trafic sortant contourne les règles de pare-feu entrantes et le NAT.

Réduire la surface d'attaque (supprimer paquets et services inutilisés), imposer SSH par clé uniquement sans connexion root, maintenir le système à jour, exécuter un pare-feu en deny-par-défaut n'exposant que les ports nécessaires, appliquer le moindre privilège via sudo et les permissions de fichiers, activer auditd et la journalisation centralisée, et ajouter la surveillance d'intégrité ainsi qu'un MAC comme SELinux ou AppArmor.