Fork Bomb (Bombe à Fourche) : Analyse Technique d'une Attaque par Déni de Service Classique

NIVEAU : Intermédiaire 12 mars 2026 SafeITExperts ~12 min

#Linux #Sécurité #DoS #systemd #cgroups

user@safeitexperts:~/forkbomb

$:(){ :|:& };:

📌 En bref

Attaque DoS

La fork bomb sature la table des processus, rendant le système inutilisable.

Croissance exponentielle

fork() → 2ⁿ processus en quelques millisecondes.

COW

Copy-on-Write : empreinte mémoire initiale très faible, saturation rapide.

Protection

TasksMax (cgroups) + limits.conf (PAM).

> 1. Introduction : La "Bombe" qui Exploite `fork()`

Dans notre restaurant, le chef cuisinier (CPU/processus) exécute une recette (programme) dans la cuisine (RAM). La fork bomb exploite l'appel système fork() pour saturer la table de réservation du maître d'hôtel (noyau), rendant le système inutilisable. Comprendre cette attaque, c'est saisir un maillon essentiel des politiques de disponibilité (NIST SP 800-34, ANSSI RGS).

Fork bomb Linux — terminal en état de saturation, erreur bash fork retry Resource temporarily unavailable — bash: fork: retry: Resource temporarily unavailable — saturation de la table des processus

🍳 2. Pédagogie : L'Analogie du "Chef Cuisinier"

La recette diabolique

:()

Définition de la recette nommée ":"

{ :|:& }

Création de deux nouveaux chefs (processus) en arrière-plan

;

Séparateur : fin de définition

Appel initial → explosion exponentielle (2ⁿ)

Le chaos culinaire : Le chef crée deux chefs. Chacun en crée deux autres. La progression est exponentielle (2ⁿ). La cuisine est vite submergée. Le maître d'hôtel (noyau) est dépassé.

⚡ 3. Vue Bas niveau (Appels Système, COW et Récupération d'Urgence)

3.1. Mécanisme fork()

Chaque chef se clone via fork() en deux nouveaux chefs. Le nombre de chefs suit 2ⁿ, saturant la table des processus.

2ⁿ

3.2. Copy-on-Write (COW) : mémoire virtuelle vs RAM physique

Espace d'adressage virtuel

Au moment du fork(), le noyau alloue un espace d'adressage virtuel complet pour chaque processus enfant : tas, pile, segments de code et de données. Cet espace est significatif.

RAM physique minime

Aucune copie physique des pages mémoire n'a lieu tant qu'elles ne sont pas modifiées. Les pages sont partagées entre parent et enfant. La consommation de RAM physique reste donc très faible au moment du fork.

Efficacité de la bombe

C'est cette faible consommation de RAM physique qui permet à la bombe de créer des milliers de processus en quelques millisecondes, avant même que la mémoire ne devienne un obstacle.

La vraie ressource saturée

La ressource réellement épuisée est la table des processus (kernel.pid_max), bien avant que la RAM physique n'atteigne sa limite. C'est ce qui rend le système inutilisable.

3.3. Survivre à l'attaque

Consoles root préexistantes : exec() (contrairement à fork()) ne crée pas de nouveau processus — /sbin/login peut encore lancer un shell si une session est déjà ouverte.
Magic SysRq : voir l'Annexe pour les touches détaillées.

→ Pas de redémarrage à froid systématique : si le système répond encore à SysRq, un arrêt propre (REISUB) évite les journaux non flushés, les vérifications fsck forcées et les risques de corruption de données.

📖 Définitions clés

Programme qui se réplique sans limite en créant des processus via fork(), saturant la table des processus et provoquant un déni de service local.

Technique du noyau où les pages mémoire sont partagées entre parent et enfant après fork, dupliquées seulement en cas d'écriture.

Control groups : mécanisme du noyau pour limiter, isoler et mesurer l'utilisation des ressources (CPU, mémoire, processus) par groupe de processus.

Paramètre systemd définissant le nombre maximal de tâches (processus + threads) autorisé dans une slice ou un service (via le contrôleur pids).

Combinaisons de touches spéciales permettant d'envoyer des commandes directement au noyau en cas de blocage (Alt+SysRq+...).

Pluggable Authentication Modules : framework d'authentification modulaire. Le module pam_limits applique les limites de ressources (nproc) aux sessions interactives uniquement.

🔐 4. Mitigations et Durcissement

Deux approches complémentaires couvrent des périmètres distincts et doivent être combinées pour une protection complète.

⚠️ Périmètres distincts — pourquoi combiner les deux : pam_limits.so ne s'applique qu'aux sessions interactives (SSH, login TTY, su). Les services systemd (nginx, sshd via socket, timers, scripts…) ne sont pas soumis à limits.conf. C'est précisément la raison pour laquelle TasksMax (cgroups) est indispensable en complément : il couvre ce que PAM ne voit pas.

4.1. Configuration ulimit (PAM)

/etc/security/limits.conf : règlement intérieur pour chaque utilisateur en session interactive.

Paramètre	Rôle
`nproc`	Nombre max de processus par utilisateur

📄 /etc/security/limits.conf

$* soft nproc 512

$* hard nproc 1024

$root soft nproc unlimited

⚠️ Prérequis : Le module pam_limits.so doit être chargé dans PAM (/etc/pam.d/login, sshd, etc.). Sans lui, limits.conf est silencieusement ignoré.

ℹ️ Root : root soft nproc unlimited est volontaire (root doit pouvoir intervenir en cas d'attaque), mais le rend vulnérable si une bombe est lancée avec ses privilèges.

4.2. Procédure cgroups / systemd (observer → analyser → modifier → tester → surveiller)

TasksMax agit via le contrôleur pids de cgroups v2. Il compte processus + threads, couvre les services systemd, et persiste après daemon-reload sans redémarrage.

ℹ️ Portée globale système : Pour modifier la valeur par défaut appliquée à toutes les slices, éditer DefaultTasksMax= dans /etc/systemd/system.conf. Nécessite un redémarrage complet (contrairement aux overrides de slice qui prennent effet après daemon-reload).

Étape 1 : Observer

Vérifier la limite actuelle

Étape 2 : Analyser

Compter les tâches

Étape 3 : Modifier

Appliquer une nouvelle limite

Étape 4 : Tester

Générer une charge

Étape 5 : Surveiller

Voir les logs

🔍 Étape 1 : Observer

systemctl

$systemctl show user-$(id -u).slice | grep TasksMax

Valeur typique : 4915 (15% de 32768, valeur de kernel.pid_max par défaut).

📊 Étape 2 : Analyser

$ps -L -u $(whoami) --no-headers | wc -l

Compte les threads également (cohérent avec ce que TasksMax mesure).

⚙️ Étape 3 : Modifier

Trois niveaux de granularité disponibles.

🌍 Slice globale (tous les utilisateurs)

user.slice.d/limits.conf

$sudo mkdir -p /etc/systemd/system/user.slice.d

$sudo tee /etc/systemd/system/user.slice.d/limits.conf <<EOF

>[Slice]

>TasksMax=400

>EOF

$sudo systemctl daemon-reload

👤 Utilisateur spécifique (UID 1000)

user-1000.slice.d/limits.conf

$sudo mkdir -p /etc/systemd/system/user-1000.slice.d

$sudo tee /etc/systemd/system/user-1000.slice.d/limits.conf <<EOF

>[Slice]

>TasksMax=600

>EOF

$sudo systemctl daemon-reload

⚙️ Service individuel (exemple : nginx)

nginx.service (override)

$sudo systemctl edit nginx

>[Service]

>TasksMax=200

🧪 Étape 4 : Tester

ℹ️ Distinction des commandes : La boucle sleep crée 250 processus suspendus — c'est elle qui déclenche réellement la limite TasksMax. Les commandes stress testent la charge CPU/mémoire : utiles pour le monitoring, elles ne déclenchent pas nécessairement la limite de tâches si celle-ci est haute.

stress & boucle

$for i in {1..250}; do (sleep 3600 &); done

$stress --cpu 250 --timeout 5s

$stress --cpu 1 --io 1 --vm 1 --vm-bytes 128M --timeout 10s

📈 Étape 5 : Surveiller

logs & cgtop

$journalctl --since today | grep -i "fork: retry: resource temporarily unavailable"

$systemd-cgtop

🚨 Annexe : Dernier Recours (Magic SysRq)

Activation : sysctl kernel.sysrq=1 (ou echo 1 > /proc/sys/kernel/sysrq). Pour persister au reboot : ajouter kernel.sysrq = 1 dans /etc/sysctl.d/99-sysrq.conf.

Touches utiles :

F : OOM Killer — force le noyau à tuer un processus pour libérer de la mémoire
K : SAK (Secure Attention Key) — tue tous les programmes sur la console courante
REISUB : redémarrage propre séquencé — R (passer en raw), E (SIGTERM), I (SIGKILL), S (sync disques), U (remonter en lecture seule), B (reboot)

→ Toujours préférer REISUB à un redémarrage à froid : les disques sont synchronisés, réduisant le risque de corruption de journaux ou de nécessité de fsck au prochain démarrage.

Synthèse des protections

Méthode	Portée	Limite	Persistance	Niveau
ulimit (PAM)	Sessions interactives uniquement	nproc (processus)	Session (nécessite pam_limits.so actif)	⭐⭐
TasksMax (cgroups)	Cgroups v2 — slices et services	tâches (processus + threads)	Permanent après daemon-reload	⭐⭐⭐
Magic SysRq	Noyau (dernier recours)	Urgence — pas préventif	Temporaire (sauf /etc/sysctl.d)	⭐ (dernier recours)

🌐 5. Portabilité de l'Attaque

La fork bomb est souvent présentée comme une attaque Linux. C'est inexact : la vulnérabilité de fond est inhérente à tout OS qui expose la création de processus sans limite par défaut. Windows et macOS sont concernés, avec des mécanismes et des niveaux de protection différents.

5.1 Windows

Windows n'implémente pas fork(), mais CreateProcess() et CreateThread() produisent le même effet de saturation lorsqu'ils sont appelés en boucle récursive.

Mécanisme d'attaque

Un script PowerShell ou un binaire C récursif suffit. L'équivalent de la fork bomb en PowerShell crée des processus enfants jusqu'à saturation de la table des handles du noyau NT.

Protection native

Job Objects : conteneurs qui limitent le nombre de processus/threads par application. Disponibles depuis Windows 2000, rarement configurés par défaut sur les postes de travail. Moins granulaires que cgroups — pas d'équivalent de TasksMax par service.

PowerShell — équivalent fork bomb (illustration)

PS>function b { Start-Process powershell -ArgumentList '-Command b' -NoNewWindow; b }

PS>b

⚠️ Ne pas exécuter sur un système sans limite de processus configurée. Les valeurs par défaut Windows sont généreuses et aucun mécanisme équivalent à TasksMax n'est actif par défaut.

5.2 macOS

macOS est fondé sur XNU (noyau hybride Mach/BSD) et expose nativement fork(). La bombe Bash :(){ :|:& };: fonctionne de manière identique à Linux sans modification.

Mécanisme d'attaque

Même syntaxe Bash, même appel fork() via le noyau XNU. Sur Apple Silicon, le kernel enforcer est plus agressif sur la gestion mémoire — il peut ralentir l'explosion, sans l'empêcher.

Protection native

launchd (équivalent de systemd) supporte HardResourceLimits dans les plists de services. SIP (System Integrity Protection) protège les processus système mais ne limite pas les processus utilisateur contre ce type d'attaque.

launchd plist — HardResourceLimits (extrait)

><key>HardResourceLimits</key>

><dict>

> <key>NumberOfProcesses</key>

> <integer>256</integer>

></dict>

Tableau comparatif

OS	Mécanisme d'attaque	Protection principale	Active par défaut	Granularité
Linux	`fork()`	cgroups v2 / TasksMax	Partielle (15% pid_max)	⭐⭐⭐
Windows	`CreateProcess()` / `CreateThread()`	Job Objects	Non	⭐⭐
macOS	`fork()`	launchd HardResourceLimits	Non	⭐⭐

Linux est le seul des trois systèmes à proposer une protection active par défaut (TasksMax à 15% de kernel.pid_max) et une granularité par service. La vulnérabilité est universelle — la maturité des outils de mitigation ne l'est pas.

✔ 6. Conclusion

Une vulnérabilité universelle

La fork bomb n'est pas une spécificité Linux. Tout OS exposant la création de processus sans limite — via fork(), CreateProcess() ou CreateThread() — est potentiellement vulnérable. La différence tient à la maturité des protections par défaut, pas au mécanisme d'attaque.

Toute ressource non bornée est un vecteur DoS

Processus, descripteurs de fichiers, connexions réseau, espace disque — aucune ressource non limitée n'est anodine. Le durcissement d'un système commence par cet exercice : identifier chaque ressource non bornée et y appliquer une contrainte cohérente avec le contexte d'exploitation.

Linux — Défense en profondeur

limits.conf pour les sessions interactives, TasksMax par service pour les démons, alertes journald ou Prometheus pour détecter l'anomalie avant la crise. Magic SysRq en dernier recours. La protection la plus granulaire des trois systèmes.

Windows — Job Objects

La protection existe via les Job Objects mais n'est pas active par défaut. Aucun équivalent de TasksMax par service n'est appliqué nativement. Sur un parc Windows de production, la limitation doit être configurée explicitement par application ou conteneur.

macOS — launchd HardResourceLimits

fork() fonctionne identiquement à Linux via XNU — la bombe Bash s'exécute sans modification. SIP protège les processus système mais pas les processus utilisateur. La limitation via HardResourceLimits dans les plists launchd n'est pas configurée par défaut.

Principe opérationnel

Quel que soit l'OS : ne pas attendre l'incident pour configurer les limites de ressources. Appliquer le principe du moindre privilège à chaque service, tester les limites avant la mise en production, et maintenir un accès de récupération hors bande.

📚 Sources Vérifiées

Les affirmations techniques de cet article reposent sur les références primaires suivantes.

Linux Kernel — cgroup v2 (Documentation officielle)

Documentation de référence du noyau Linux sur le contrôleur pids, le comptage des tâches (processus + threads) et les hiérarchies de cgroups v2. Source primaire pour le comportement réel de TasksMax.

systemd — systemd.resource-control (man page officielle)

Documentation officielle de la directive TasksMax=, de son interaction avec le contrôleur pids de cgroups v2, et des niveaux de granularité (slice, service, scope). Référence pour DefaultTasksMax et les valeurs par défaut.

Linux Kernel — Magic SysRq key (Documentation officielle)

Référence complète des combinaisons Magic SysRq, de leur activation via sysctl kernel.sysrq et de la séquence REISUB. Source primaire pour la section récupération d'urgence.

PAM — limits.conf (man page)

Documentation du module pam_limits et du fichier /etc/security/limits.conf : paramètres nproc, distinction soft/hard, et portée aux sessions interactives uniquement.

🔗 Lectures Recommandées SafeITExperts

Pour approfondir les thématiques abordées dans cet article.

Noyaux Linux 2025 : Nouveautés, Sécurité & Recommandations

Analyse complète des versions 6.14 à 6.19 : nouvelles primitives de sécurité, évolutions de cgroups, performances et recommandations de mise à jour pour les environnements de production.

Europe vs GAFAM : Régulations et Souveraineté Numérique en 2026

État des lieux du DMA et du DSA deux ans après leur entrée en application : impacts concrets sur les grandes plateformes, enjeux de souveraineté des données et alternatives européennes.

L'Asie au cœur de l'écosystème numérique mondial

Analyse du rôle stratégique de l'Asie dans les chaînes de valeur numériques mondiales : semi-conducteurs, infrastructures cloud, normes de cybersécurité et influence géopolitique sur les standards technologiques.

Guide d'Achat 2026 : PC Portables pour Linux et la Sécurité

Sélection et analyse critique de portables certifiés Linux en 2026 : compatibilité matérielle, Secure Boot, TPM, BIOS ouvert et critères de sécurité pour les professionnels et les usages sensibles.

À propos de l'auteur

L'équipe SafeITExperts est composée d'experts en cybersécurité, Linux et souveraineté numérique. Nous publions des analyses techniques sourcées, alignées sur les standards NIST et ANSSI.

Fork Bomb Linux Guide Sécurité Durcissement 2026

~/toc $

Fork Bomb (Bombe à Fourche) : Analyse Technique d'une Attaque par Déni de Service Classique

📌 En bref

> 1. Introduction : La "Bombe" qui Exploite `fork()`