Dans cette page, nous présentons quelques moyens actuels d’atténuer les attaques par déni de service. Toutes ces approches peuvent être combinées. Cependant, il n’existe pas pour l’instant de solution unique à ce problème. La défense d’un site attaqué exige de la créativité et une approche personnalisée.

Un aperçu des défenses implémentées dans le démon tor est donné dans la section Overview de la spécification Denial-of-service prevention mechanisms in Tor, et nous donnons ici quelques conseils pratiques.

Limitation du débit aux points d’introduction

Depuis que la Proposition 305 a été implémentée, certaines options torrc ont été ajoutées pour aider à atténuer les attaques DoS aux points d’introduction :

  • HiddenServiceEnableIntroDoSDefense : Activer la défense contre les DoS au niveau du point d’introduction. Lorsque cette option est activée, les paramètres de débit et de rafale sont envoyés au point d’introduction, qui les utilise pour appliquer une limitation de débit aux demandes d’introduction à ce service.

  • HiddenServiceEnableIntroDoSBurstPerSec : La rafale d’introductions de clients autorisée par seconde au point d’introduction. Si cette option est à 0, elle est considérée comme infinie et donc, si HiddenServiceEnableIntroDoSDefense est activée, elle désactive effectivement les défenses.

  • HiddenServiceEnableIntroDoSRatePerSec : Le taux d’introductions de clients autorisé par seconde au point d’introduction. Si cette option est à 0, elle est considérée comme infinie et donc, si HiddenServiceEnableIntroDoSDefense est activée, elle désactive effectivement les défenses.

Pour plus d’informations sur leur fonctionnement, consultez la page de manuel tor(1) et la section Denial-of-Service defense extension (DOS_PARAMS) de la spécification des services onion v3.

Preuve de travail (PoW) avant d’établir des circuits de Rendezvous

Un mécanisme de défense par preuve de travail (PoW) est expliqué en détail dans la FAQ PoW et peut être configuré pour chaque service onion avec les options torrc suivantes :

  • HiddenServicePoWDefensesEnabled : Activer l’atténuation des DoS du service par preuve de travail. Lorsque cette option est activée, tor inclut les paramètres d’un casse-tête client facultatif dans la partie chiffrée du descripteur de ce service caché. Les demandes de rendez-vous entrantes seront classées par ordre de priorité en fonction de l’effort qu’un client choisit de fournir pour calculer une solution au casse-tête. Le service mettra périodiquement à jour l’effort suggéré, en fonction de la charge d’attaque, et désactivera complètement le puzzle lorsque le service n’est pas surchargé.

  • HiddenServicePoWQueueRate : Le taux soutenu de demandes de rendez-vous à distribuer par seconde depuis la file d’attente prioritaire.

  • HiddenServicePoWQueueBurst : La taille maximale de rafale pour les demandes de rendez-vous traitées en une seule fois depuis la file d’attente prioritaire.

L’option globale suivante s’applique à la fois aux services onion et à leurs clients :

  • CompiledProofOfWorkHash : Lorsque l’atténuation des DoS par preuve de travail est active, les services eux-mêmes et les clients qui s’y connectent utilisent une fonction de hachage générée dynamiquement dans le cadre du calcul du puzzle.

PoW est activé par défaut sur les versions 0.4.8.1-alpha et suivantes de C Tor (mais peut être désactivé si Tor est compilé avec --disable-module-pow). La prise en charge de base du PoW peut être vérifiée en exécutant cette commande :

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

Si vous avez pow: yes, alors vous avez le mécanisme de défense PoW intégré dans C Tor.

En raison des conditions de licence, les bibliothèques de casse-tête client PoW v1 (Equi-X et HashX par tevador, toutes deux sous LGPL-3.0) ne sont activées que si tor est compilé avec --enable-gpl. Ceci peut être confirmé en exécutant la commande suivante :

tor --version
Tor version 0.4.8.3-rc.
Cette version de Tor est couverte par la licence publique générale GNU (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor fonctionne sous Linux avec Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A et Glibc 2.36 en tant que libc.
Tor compilé avec GCC version 12.2.0

Si votre C Tor installé n’a pas la PoW activée ou n’est pas compilé avec la prise en charge de la GNU GPL, vous devrez chercher d’autres paquets ou le compiler vous-même.

Limites des flux dans les circuits de Rendezvous établis

Les options de configuration suivantes peuvent être utilisées pour limiter les connexions dans les circuits de rendez-vous :

  • HiddenServiceMaxStreams : Le nombre maximal de flux simultanés (connexions) par circuit de rendez-vous. La valeur maximale autorisée est de 65535. (La valeur 0 permet un nombre illimité de flux simultanés)

  • HiddenServiceMaxStreamsCloseCircuit : S’il vaut 1, le dépassement de HiddenServiceMaxStreams entraînera la fermeture du circuit de rendez-vous fautif, au lieu d’ignorer silencieusement les demandes de création de flux qui dépassent la limite.

Onionbalance

Onionbalance permet aux opérateurs de services onion d’atteindre la haute disponibilité en permettant à plusieurs machines de traiter les requêtes d’un service onion. Vous pouvez utiliser Onionbalance pour mettre à l’échelle horizontalement. Plus vous augmentez votre taille, plus il est difficile pour les attaquants de vous submerger. Onionbalance est disponible pour les services onion v3.

Limitation du débit du serveur web

Si des attaquants vous submergent de circuits agressifs qui effectuent trop de requêtes, essayez de détecter cette surutilisation et de les tuer en utilisant l’option torrc HiddenServiceExportCircuitID. Vous pouvez utiliser vos propres heuristiques ou le module de limitation de débit de votre serveur web.

Les conseils ci-dessus devraient vous aider à rester à flot en période de turbulences. En même temps, nous travaillons sur des défenses plus avancées, de sorte que les opérateurs de services onion aient moins besoin de configuration manuelle et de bricolage.

Mise en cache

Un autre moyen de réduire la charge sur votre service est de mettre en place une mise en cache du contenu, soit directement au niveau de l’application dorsale, soit en installant un mandataire de mise en cache en frontal.

Autorisation des clients ou plusieurs adresses onion pour cloisonner vos utilisateurs

Si vous avez des utilisateurs de confiance, donnez-leur un service onion dédié et des identifiants d’autorisation client afin qu’il soit toujours disponible. Pour les utilisateurs en qui vous n’avez pas confiance, répartissez-les sur plusieurs adresses. Cela dit, avoir trop d’adresses onion est en fait mauvais pour votre sécurité (à cause de l’utilisation de nombreux nœuds de garde), alors essayez d’utiliser l’autorisation client quand c’est possible.

Captchas et cookies

Si vous devez limiter davantage le débit des utilisateurs, divisez votre infrastructure en couches et placez des Captchas près du frontal. Ainsi, les attaquants devront résoudre les Captchas avant de pouvoir pénétrer plus profondément dans votre infrastructure.

Les Captchas sont un moyen d’atténuer les attaques DDoS. Lorsqu’une requête provient d’un client, il vérifie si celui-ci contient le bon cookie sécurisé, sinon il redirige vers la page recaptcha. Le client saisit les lettres du captcha. Nginx envoie les lettres saisies au serveur recaptcha pour vérification.

La réponse correcte du serveur recaptcha commence par « true... », sinon elle commence par « false... ». Ajoutez le cookie sécurisé pour le client vérifié, puis redirigez le client vers la page qu’il souhaite consulter.

Il est possible d’implémenter des captchas directement sur votre serveur web avec Nginx et OpenResty en utilisant Lua pour générer et vérifier les images captcha. Cette implémentation n’est pas facile à configurer.

Une autre solution consisterait simplement à mettre en place un défi de type test-cookie. Sur votre serveur web, vérifiez que les clients peuvent définir des cookies valides, car les clients malveillants ne disposent souvent pas de cette fonction. Dans Nginx, Cloudflare fournit une bibliothèque pour interagir avec les cookies.

D’autres méthodes consistent à s’assurer que les clients qui se connectent à votre .onion ont un en-tête User-Agent valide et que l’en-tête Referer n’est pas défini sur une valeur que vous pouvez associer à l’attaque.