Dans cette page, nous présentons quelques moyens 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.
An overview of implemented defenses at the tor daemon is given in the Overview section from the Denial-of-service prevention mechanisms in Tor specification, and here we give some practical tips.
Limitation du taux 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 attaques DoS au niveau de chaque point d'entrée.
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'introduction de client 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'introduction 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.
For more information on how they work, check the tor(1) manpage and the Denial-of-Service defense extension (DOS_PARAMS) section of the Onion Services v3 specification.
Preuve de travail (PoW) avant d'établir des circuits de Rendezvous
La Preuve de Travail (PoW) d'un mécanisme de défense est détaillée dans la FAQ PoW et peut être paramétrée pour chaque Service Onion avec les options torrc suivantes :
HiddenServicePoWDefensesEnabled : Active l'atténuation des dénis de service basée sur la preuve de travail (PoW).
Lorsque cette option est activée, tor inclut les paramètres d'un puzzle client facultatif dans la partie chiffrée du descripteur de ce service caché.
Les demandes de rendezvous entrantes seront classées par ordre de priorité en fonction de l'effort qu'un client choisit de fournir pour trouver une solution au puzzle.
Le service mettra périodiquement à jour un effort suggéré, basé sur 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 Rendezvous à distribuer par seconde à partir de la file d'attente prioritaire.
HiddenServicePoWQueueBurst : La taille maximale de la rafale pour les demandes de Rendezvous traitées à partir de la file d'attente prioritaire en une seule fois.
L'option globale suivante s'applique à la fois aux services en onion et à leurs clients :
CompiledProofOfWorkHash : Lorsque la mitigation DoS de la preuve de travail est active, les services eux-mêmes et les clients qui se connectent utiliseront 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 Tor (mais peut être désactivé s'il 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 Tor.
En raison des conditions de licence, les bibliothèques PoW v1 client puzzle (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 Tor n'a pas la PoW activée ou n'est pas compilé avec le support 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 rendezvous :
HiddenServiceMaxStreams : Le nombre maximum de flux simultanés (connexions) par circuit de rendezvous.
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 le démantèlement du circuit de rendez-vous concerné, alors que les demandes de création de flux dépassant la limite seront silencieusement ignorées.
Onionbalance
Onionbalance permet aux opérateurs de services en onion d'atteindre la haute disponibilité en permettant à plusieurs machines de traiter les demandes d'un service en 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 les attaquants vous submergent de canaux 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 votre propre outil heuristique 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 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 backend, soit en mettant en place un proxy de mise en cache au niveau de l'application frontend.
Autorisation du client ou adresses multiples en onion pour compartimenter vos utilisateurs
Si vous avez des utilisateurs en qui vous avez confiance, donnez-leur des informations d'identification dédiées au service Onion et à l'autorisation du client afin qu'il soit toujours disponible.
Pour les utilisateurs en qui vous n'avez pas confiance, divisez-les en 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 autorisation client quand c'est possible.
Captchas et cookies
Si vous avez besoin de limiter davantage le nombre d'utilisateurs, divisez votre infrastructure en plusieurs couches et placez des Captchas près du frontend.
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 ces lettres d'entrée au serveur recaptcha pour les vérifier.
La réponse correcte du serveur recaptcha commence par "true...", sinon elle commence par "false...".
Ajouter le cookie sécurisé pour le bon client vérifié, rediriger 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 à mettre en place un test-cookie challenge.
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 à une attaque.