🎯 Objectif de la semaine
Comprendre l'écosystème des processus Linux pour identifier ce qui s'exécute réellement dans la machine, détecter les anomalies et acquérir les réflexes de monitoring essentiels à tout analyste sécurité.
Pourquoi c'est critique : 90% des malwares et attaques avancées se manifestent par des processus anormaux. Savoir lire les processus, c'est savoir écouter le pouls de la machine.
Parent → Enfant] --> B[🎬 Exec
Chargement programme] B --> C[🏃 Running
Exécution CPU/Mémoire] C --> D{Sleeping/Waiting
Attente I/O} D --> C C --> E[🧹 Zombie
Terminé mais
parent n'a pas lu exit] C --> F[⚰️ Terminated
Fin complète] E --> F G[👑 Init/systemd
PID 1] --> H[🌳 Arbre Processus
Parent-Enfant] H --> I[🔍 Detection Anomalies
CPU/Mémoire/Ports] style A fill:#0a0e17,stroke:#00d4ff,stroke-width:2px style C fill:#11151f,stroke:#9d4edd,stroke-width:2px style I fill:#00f5a0,stroke:#000,stroke-width:2px
📚 Sujet – Théorie (1 heure)
L'anatomie d'un processus : plus qu'un simple programme
Un processus Linux n'est pas juste un programme qui tourne. C'est une entité vivante avec :
🧬 Les composants d'un processus :
- PID (Process ID) : Identifiant unique, comme un numéro de sécurité sociale
- PPID (Parent PID) : Le processus qui l'a créé (hiérarchie)
- UID/GID : Utilisateur et groupe propriétaire
- État : Running (R), Sleeping (S), Zombie (Z), Stopped (T)
- Ressources : Mémoire virtuelle/physisque, fichiers ouverts, sockets réseau
- Contexte d'exécution : Registres CPU, pile, compteur programme
Le cycle de vie : de la naissance à la mort
(copy of parent)"] Child --> B{"Exec ?"} B -- Yes --> C["Exec()
Load new program"] B -- No --> D["Running
TASK_RUNNING: runnable or executing"] C --> D D --> E{"Sleep/Wait ?"} E -- Yes, Interruptible --> F["Interruptible Sleep
TASK_INTERRUPTIBLE: waiting event, wake on signal"] E -- Yes, Uninterruptible --> G["Uninterruptible Sleep
TASK_UNINTERRUPTIBLE: e.g. I/O, rare"] E -- No --> D F -->|"Event or Signal"| D G -->|"Resource ready"| D D --> H["Exit()
Process terminates"] H --> I["Zombie
EXIT_ZOMBIE: defunct, waiting parent reap"] I --> J["Reaped
Parent calls wait()/waitpid()
or handles SIGCHLD"] J --> End["Removed from process table"] style D fill:#11151f,stroke:#00d4ff,stroke-width:2px,color:#fff style I fill:#ef4444,stroke:#fff,stroke-width:2px,color:#fff style F fill:#333,stroke:#ff0,stroke-width:2px,color:#fff style G fill:#555,stroke:#f90,stroke-width:2px,color:#fff
Services (Daemons) vs Processus utilisateur
| Aspect | Processus Utilisateur | Service (Daemon) | Impact sécurité |
|---|---|---|---|
| Durée de vie | Court/moyen terme | Long terme (jours/mois) | Daemon = cible privilégiée |
| Démarrage | Manuel ou script | Boot ou événement | Daemon au boot = persistance |
| Utilisateur | User standard | root ou service account | root daemon = haut risque |
| Visibilité | Terminal/UI visible | Arrière-plan caché | Daemon caché = plus dangereux |
systemd : le gestionnaire moderne (et controversé)
⚠️ Pourquoi systemd est important en sécurité :
systemd a remplacé SysV init dans la plupart des distributions. Il gère :
- Le démarrage de tous les services
- Les dépendances entre services
- Le logging (journalctl)
- Les timers (remplacement cron)
Problème de sécurité : Un bug dans systemd = compromission potentielle de tout le système.
Indicateurs de processus malveillants
Un analyste sécurité doit repérer :
- Nom bizarre : Processus imitant des noms légitimes (sshd vs sshd2)
- PID parent étrange : Un processus utilisateur lancé par init/systemd
- Consommation anormale : CPU à 100% sans raison apparente
- Utilisateur suspect : Processus root alors qu'il ne devrait pas l'être
- Connexions réseau : Processus écoutant sur des ports inattendus
💡 Philosophie du monitoring :
"Connais ton système en temps normal pour détecter l'anormal."
Un Gardien numérique doit connaître le bruit de fond de sa machine pour entendre le signal de l'attaque.
🔬 Mission pratique – Laboratoire (2 heures)
Scénario : Investigation d'une machine potentiellement compromise
Vous êtes appelé pour analyser une machine suspecte. Votre mission : identifier les processus anormaux et comprendre l'activité système.
📝 Avant de commencer : Créez un fichier investigation_s03.txt pour documenter vos découvertes.
Étapes d'investigation détaillées
-
Installation des outils forensiques
Nous allons installer des outils qui simuleront une investigation réelle :# Mise à jour et installation sudo apt update sudo apt install -y \ apache2 \ # Service web pour analyse htop \ # Monitoring avancé net-tools \ # Outils réseau (netstat) lsof \ # List Open Files tree \ # Visualisation arborescente stress \ # Pour générer de la charge CPU python3 # Pour scripts d'analyse # Vérification which htop lsof netstat -
Établir une baseline : connaître le système normal
Documentez l'état "propre" de votre machine :# 1. Capture de l'état initial echo "=== BASELINE $(date) ===" > baseline.txt echo "=== Processus kali ===" >> baseline.txt ps -u kali -o pid,ppid,user,%cpu,%mem,command >> baseline.txt echo "=== Top 10 CPU ===" >> baseline.txt ps aux --sort=-%cpu | head -11 >> baseline.txt echo "=== Top 10 Mémoire ===" >> baseline.txt ps aux --sort=-%mem | head -11 >> baseline.txt echo "=== Services actifs ===" >> baseline.txt systemctl list-units --type=service --state=running >> baseline.txt # Visualisation cat baseline.txt | less -
Création d'activité suspecte (simulée)
Créons des scénarios d'anomalies à détecter :# Scénario 1 : Processus consommateur CPU caché stress --cpu 2 --timeout 300 & # Consomme 2 cœurs CPU pendant 5 min # Scénario 2 : Service malveillant simulé sudo bash -c 'cat > /tmp/fake_service.sh << "EOF" #!/bin/bash while true; do echo "Fake service running $(date)" >> /tmp/fake.log sleep 30 done EOF' chmod +x /tmp/fake_service.sh /tmp/fake_service.sh & # Scénario 3 : Processus zombie (simulé) python3 -c " import os, time pid = os.fork() if pid == 0: # Processus enfant print('Child exiting') os._exit(0) else: # Processus parent ne lit pas exit de l'enfant print(f'Parent {os.getpid()} created zombie {pid}') time.sleep(600) # Garde le zombie " & -
Investigation avec ps : l'outil fondamental
Maîtrisez les différentes vues de ps :# Vue BSD complète (la plus utilisée) ps aux | head -20 # Vue avec format personnalisé ps -eo pid,ppid,user,%cpu,%mem,cmd --sort=-%cpu | head -15 # Recherche de processus spécifiques ps aux | grep -E '(stress|fake|python)' # Processus avec PPID = 1 (démarrés par init/systemd) ps -eo pid,ppid,cmd | awk '$2 == 1' # Processus zombies ps aux | awk '$8 ~ /Z/' # Processus par utilisateur ps -u kali --forest # Vue hiérarchique -
Monitoring dynamique avec top et htop
Apprenez à utiliser ces outils comme un pro :# top : classique mais puissant top -b -n 1 > top_snapshot.txt # Capture statique # Dans top interactif : # 1 = affiche tous les CPUs # M = tri par mémoire # P = tri par CPU # k = kill un processus # q = quitter # htop : version améliorée (installez-le si pas fait) sudo apt install htop -y htop # Commandes htop : # F6 = trier par colonne # F9 = tuer processus # F2 = configuration # / = rechercher # t = arbre des processus -
Analyse des services systemd
Comprenez comment investiguer les services :# 1. Services actifs systemctl list-units --type=service --state=running # 2. Détails d'un service spécifique sudo systemctl status apache2 sudo systemctl show apache2 # Propriétés détaillées # 3. Journaux d'un service sudo journalctl -u apache2 -n 50 # 50 dernières lignes sudo journalctl -u apache2 --since "1 hour ago" # 4. Dépendances d'un service systemctl list-dependencies apache2 # 5. Services défaillants systemctl --failed -
Analyse avancée avec pstree et lsof
Outils pour investigations approfondies :# Visualisation hiérarchique pstree -p -u # PID et utilisateurs pstree -a # Avec arguments # Fichiers ouverts par processus sudo lsof -i # Connexions réseau sudo lsof -p $(pgrep apache2) # Fichiers ouverts par Apache lsof /var/log # Qui utilise les logs ? # Processus écoutant sur des ports sudo netstat -tulpn # ou (plus moderne) sudo ss -tulpn -
Détection et neutralisation des anomalies
Appliquez ce que vous avez appris :# 1. Trouvez le processus stress pgrep stress # ou ps aux | grep stress # 2. Analysez sa consommation top -p $(pgrep stress) # 3. Tuez-le proprement kill $(pgrep stress) # Si résistant kill -9 $(pgrep stress) # 4. Trouvez et tuez le fake service ps aux | grep fake_service kill %2 # Si lancé en background avec & # ou pkill -f fake_service # 5. Nettoyage sudo systemctl stop apache2 sudo systemctl disable apache2 rm -f /tmp/fake_service.sh /tmp/fake.log
🎯 Défi d'investigation avancé
Créez un script d'investigation automatique qui :
#!/bin/bash
echo "=== RAPPORT D'INVESTIGATION $(date) ==="
echo ""
echo "1. Processus CPU > 50%:"
ps aux --sort=-%cpu | awk '$3 > 50 {print $0}'
echo ""
echo "2. Processus Mémoire > 10%:"
ps aux --sort=-%mem | awk '$4 > 10 {print $0}'
echo ""
echo "3. Processus zombies:"
ps aux | awk '$8 ~ /Z/ {print $0}'
echo ""
echo "4. Services défaillants:"
systemctl --failed
echo ""
echo "5. Connexions réseau suspectes:"
sudo netstat -tulpn | grep -E '(LISTEN|ESTABLISHED)'
Exécution : chmod +x investigate.sh && sudo ./investigate.sh > rapport.txt
📋 Objectif de la semaine – Checklist de validation
✅ Compétences techniques acquises
- Utiliser
psavec différentes options pour cibler l'information - Naviguer efficacement dans
topethtop - Gérer des services avec
systemctl(start/stop/status/enable) - Identifier et tuer des processus avec
kill,pkill - Détecter des anomalies (CPU élevé, zombies, PPID suspect)
- Utiliser
pstreeetlsofpour analyse approfondie
🧠 Changement mental accompli
- Voir les processus comme des indicateurs de santé système
- Comprendre que "silence ≠ sécurité" - il faut savoir ce qui tourne
- Penser en termes de "baseline" pour détecter les déviations
- Reconnaître que chaque service est une surface d'attaque potentielle
🔍 Bonne pratique à adopter :
Prenez l'habitude de lancer htop au démarrage de chaque session. Connaissez votre consommation normale pour détecter immédiatement les anomalies.
📚 Ressources gratuites recommandées
Pour approfondir :
- Linux Process Management : Linux Journey - Processes
- htop Guide : https://htop.dev/ – Documentation officielle
- systemd pour les humains : Systemd by Example
⚠️ Pièges courants à éviter
kill -9en premier recours → peut corrompre des données- Ne pas vérifier les dépendances avant d'arrêter un service
- Oublier que
systemctl stopn'empêche pas le redémarrage au boot - Confondre
ps aux(BSD) etps -ef(SysV)
🔮 Frère d'armes,
Tu viens d'acquérir le troisième sens du Gardien numérique : la vision des âmes.
Maintenant, quand tu regardes une machine, tu ne vois plus une boîte silencieuse. Tu vois une ruche d'activité :
- Des processus qui naissent, vivent, et meurent
- Des services qui veillent dans l'ombre
- Des ressources qui s'échangent comme le sang dans des veines
- Des zombies qui traînent, signes de morts mal nettoyées
Cette semaine, tu as appris à écouter le pouls de la machine. Tu sais maintenant :
• Qu'un processus qui consomme 100% de CPU n'est pas forcément malveillant, mais doit être investigué
• Qu'un service qui écoute sur un port inattendu est un drapeau rouge
• Qu'un zombie est le signe d'un parent négligent
• Que la hiérarchie des processus raconte une histoire
Tu commences à développer l'intuition du Gardien : cette capacité à sentir qu'"il y a quelque chose qui ne va pas" avant même de pouvoir l'expliquer.
Dans la semaine 4, nous quitterons les entrailles de la machine pour explorer le monde extérieur : le réseau. Nous apprendrons à voir les connexions comme des ponts entre les cités, à comprendre qui parle à qui, et pourquoi.
Pratique. Observe. Documente. Chaque processus que tu comprends est une âme de moins qui peut te tromper.
La machine n'a plus de secrets pour toi.
— Platon-Y