Merci d'avoir pris le temps de lire ceci ! Nous ne sommes pas des experts en matière de réseaux Tor, mais nous nous y connaissons.
Si l'un des éléments décrits ici vous semble logique et/ou si vous avez des doutes sur ce qui se passe, nous vous remercions de nous faire part de vos commentaires !
1. Que se passe-t-il ?
Notre service fonctionnait bien et était stable depuis longtemps. Soudain, il a connu des problèmes de performance d'abord légers, puis graves, avant de devenir complètement inaccessible.
Il ne semble pas s'agir d'une attaque DDoS "normale". Il semble qu'il s'agisse d'une attaque DoS, mais pas comme ce qui est connu, puisqu'il semble s'agir d'une attaque sur le daemon Tor uniquement. Toutes les contre-mesures que nous avons essayées jusqu'à présent ont échoué. Il n'y a pas d'attaque perceptible sur les services en cours d'exécution (http, ssh, ftp, mail, etc.) mais seulement sur la connexion Tor elle-même.
Même si nous avons fait des recherches approfondies, l'événement semble être au-delà de notre compréhension. Les documentations sur les attaques antérieures contre les services cachés de Tor sont rares et n'ont aucun sens par rapport à ce que nous vivons.
Nous refusons de croire qu'il existe un scénario d'attaque inconnu et qui ne peut être contré car il rendrait chaque service caché Tor vulnérable, les adversaires étant capables de mettre hors ligne n'importe quel service caché Tor en quelques minutes et pour une durée indéterminée. L'impact sur la communauté Tor serait sans commune mesure.
Nous espérons que quelqu'un ayant les connaissances et l'expertise nécessaires pourra au moins nous donner un indice sur ce qui se passe exactement et nous orienter dans la bonne direction pour trouver une solution pour mettre fin à cette attaque ou réduire son impact sur nos systèmes et pour empêcher de telles attaques à l'avenir. Cela aiderait à protéger les services cachés de Tor dans le monde entier contre de futures attaques comme celle que nous subissons.
2. Quelle est la configuration ?
- Le système fonctionne sur un serveur linux (amd64) actuel et toujours à jour.
- Tout le trafic passe par Tor via Tor transport sur le port 9040, les requêtes DNS sont également résolues via Tor.
- Le service caché Tor est v3
- Tor est la version 0.4.7.8 fonctionnant avec Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 et Glibc 2.31 comme libc
- Tor compilé avec GCC version 10.2.1. Vanguards 0.3.1 est également installé.
- Tor fonctionne en tant que service systemd
- Vanguards fonctionne en tant que service systemd
Configuration de torrc :
CookieAuthentication 1
HashedControlPassword 16:<hash> (mot de passe haché)
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Quels sont les symptômes ?
- Moins d'une minute après le démarrage de Tor avec le service caché activé, le CPU atteint 100%, la mémoire ne semble pas affectée.
- La bande passante utilisée augmente d'environ 100kb/s
- Le descripteur du service caché est inaccessible.
- Le système peut toujours résoudre les adresses clearnet et Tor
- Le système peut toujours se connecter à des services sortants (ex. curl vers un site web)
- Le système est inondé de paquets tcp entrants sur l'interface loopback
- Lorsque Tor est redémarré, l'inondation s'arrête pendant quelques secondes, puis reprend.
- Lorsque Tor est démarré sans que le service caché soit activé, il ne semble pas y avoir de problème.
- Lorsque Tor est démarré avec un second service caché activé, les deux descripteurs de service caché restent inaccessibles :
Tor Browser on Primary HS :
Onionsite s'est déconnecté
La cause la plus probable est que l'onionsite est hors ligne. Contactez l'administrateur de l'onionsite.
Détails : 0xF2 - L'introduction a échoué, ce qui signifie que le descripteur a été trouvé mais que le service n'est plus connecté au point d'introduction. Il est probable que le service ait changé de descripteur ou qu'il ne soit pas en cours d'exécution.
ou
La connexion a expiré
Le serveur de (attacked hidden service descriptor).onion met trop de temps à répondre.
Le site peut être temporairement indisponible ou trop occupé. Réessayez dans quelques instants.
Tor Browser sur Seconday HS :
Impossible de se connecter
Firefox ne peut pas établir de connexion avec le serveur à (descripteur de service caché secondaire).onion.
Le site peut être temporairement indisponible ou trop occupé. Réessayez dans quelques instants.
- Lorsque Tor est démarré avec un second service caché activé qui est protégé par OnionAuthentication, le descripteur du service caché primaire reste inaccessible,
le descripteur du service caché secondaire (protégé) est accessible.
- Lorsque Tor est démarré avec seulement le second service caché activé (avec ou sans OnionAuthentication), il ne semble pas y avoir de problème.
- Lorsque Tor est démarré avec le service caché principal protégé par OnionAuthentication, le descripteur de service caché est accessible.
- Lorsqu'il est attaqué, ces entrées apparaissent dans le fichier journal de Tor :
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done) : Fait
Aug 24 19:42:34.000 [notice] Votre vitesse de connexion au réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 388 buildtimes.
Aug 24 19:42:39.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 240 buildtimes.
Aug 24 19:42:53.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 489 temps d'attente.
Aug 24 19:43:11.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 659 temps d'exécution.
...
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:46:09.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 114 buildtimes.
Aug 24 19:46:15.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 125 temps d'attente.
...
Aug 24 19:47:08.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:13.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:14.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 495 buildtimes.
Aug 24 19:47:18.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 124 buildtimes.
Aug 24 19:47:21.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:23.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
...
Aug 24 19:47:55.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 1000 buildtimes.
Aug 24 19:47:59.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 117 temps d'attente.
...
Aug 24 19:52:43.000 [notice] Valeur étrange pour le temps de construction du circuit : 121581msec. Suppose un saut d'horloge. Objectif 14 (Mesurer le temps d'attente du circuit)
Aug 24 19:52:43.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 120000ms après 18 timeouts et 57 buildtimes.
Aug 24 19:52:53.000 [notice] Interrupt : exiting cleanly.
4. Qu'a-t-on essayé de faire pour résoudre le problème ?
- Nous avons configuré un tout nouveau serveur à partir de zéro, en utilisant uniquement le système d'exploitation de base ainsi que tor et vanguards dans la configuration standard, afin d'exclure la possibilité d'une mauvaise configuration sur notre serveur affecté. Dès que tor a été démarré avec le descripteur attaqué, les mêmes choses se sont produites.
- Nous avons essayé de répartir la charge sur notre serveur via OnionBalance dans cette configuration :
Serveur 1 : Exécute Onionbalance pour le descripteur de service caché principal.
Serveur 2/3/4 : Exécute le service caché sur des descripteurs de service caché nouveaux et différents.
- Cela ne ramène pas le descripteur de service caché d'origine à la vie.
- Les descripteurs de service sur les serveurs 2/3/4 sont accessibles lorsqu'ils sont ouverts directement, mais pas via le descripteur primaire désormais équilibré.
- Le CPU des serveurs 2/3/4 passe à 100 % tant que l'attaque a lieu, tandis que le CPU du serveur 1 (équilibreur) reste normal.
- L'ajout d'autres serveurs backend à l'équilibreur n'a pas fait de différence non plus.
- Nous avons ajouté ces directives au bloc des services cachés dans torrc et essayé différents paramètres :
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testé avec différentes valeurs>
HiddenServiceEnableIntroDoSRatePerSec <testé avec différentes valeurs>
Cela a permis de réduire considérablement la charge du processeur sur les serveurs 2/3/4, mais le descripteur de service équilibré reste inaccessible.
- Nous avons essayé de modifier divers paramètres dans vanguards.conf, sans succès.
- Nous avons essayé d'identifier les paquets tcp attaquants et de les bloquer via iptables, sans succès.
Notre expertise n'est pas suffisante pour se faire une idée de ce qui se passe exactement en inspectant le contenu de ces paquets tcp qui ressemblent à ceci :
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712 : Flags [P.], cksum 0x0df9 (incorrect -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attaque du descripteur de service caché)---------| TIME_CREATED=2022-08-24T19 :45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19 :45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attaque du descripteur de service caché)---------| TIME_CREATED=2022-08-24T19 :45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attaque du descripteur de service caché)---------| TIME_CREATED=2022-08-24T19 :45:25.10
Ceci est réalisé avec Tor fonctionnant sur un seul serveur. Lorsqu'il est équilibré, |---------(attacked hidden service descriptor)---------| est remplacé par les descripteurs de service des backends des serveurs 2/3/4.
Nous pouvons mettre à disposition un extrait de tcpdump plus important, si nécessaire.
5. Conclusions
Nous pensons qu'un adversaire a la capacité d'"interrompre" un descripteur de service caché (et donc le service caché lui-même) en inondant le démon Tor d'un nombre incalculable de paquets tcp, demandant à construire des circuits. C'est ce qui provoque la charge du processeur et rend finalement le descripteur de service caché inutilisable.
Quelqu'un peut-il le confirmer ?
Puisque des directives comme HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec et HiddenServiceEnableIntroDoSRatePerSec semblent être destinées à se défendre contre ce type d'attaques, tout comme les avant-gardes devraient le faire, nous ne pouvons pas expliquer pourquoi elles restent inefficaces. Peut-être que des paramètres très spécialisés de ces valeurs sont nécessaires pour les rendre efficaces. Malheureusement, ces directives (ainsi que les paramètres du fichier vanguards.config) ne sont décrites que de manière vague.
Quelqu'un sait-il comment ces directives doivent être réglées correctement pour être efficaces ?
A ce stade, nous avons épuisé toutes les références sur tor et la configuration de vanguards que nous avons pu trouver en ligne.
Encore une fois, toute aide ou information sur ce sujet serait grandement appréciée ! Nous ne pensons pas qu'il n'y ait pas de solution à ce problème.
Si l'un des éléments décrits ici vous semble logique et/ou si vous avez des doutes sur ce qui se passe, nous vous remercions de nous faire part de vos commentaires !
1. Que se passe-t-il ?
Notre service fonctionnait bien et était stable depuis longtemps. Soudain, il a connu des problèmes de performance d'abord légers, puis graves, avant de devenir complètement inaccessible.
Il ne semble pas s'agir d'une attaque DDoS "normale". Il semble qu'il s'agisse d'une attaque DoS, mais pas comme ce qui est connu, puisqu'il semble s'agir d'une attaque sur le daemon Tor uniquement. Toutes les contre-mesures que nous avons essayées jusqu'à présent ont échoué. Il n'y a pas d'attaque perceptible sur les services en cours d'exécution (http, ssh, ftp, mail, etc.) mais seulement sur la connexion Tor elle-même.
Même si nous avons fait des recherches approfondies, l'événement semble être au-delà de notre compréhension. Les documentations sur les attaques antérieures contre les services cachés de Tor sont rares et n'ont aucun sens par rapport à ce que nous vivons.
Nous refusons de croire qu'il existe un scénario d'attaque inconnu et qui ne peut être contré car il rendrait chaque service caché Tor vulnérable, les adversaires étant capables de mettre hors ligne n'importe quel service caché Tor en quelques minutes et pour une durée indéterminée. L'impact sur la communauté Tor serait sans commune mesure.
Nous espérons que quelqu'un ayant les connaissances et l'expertise nécessaires pourra au moins nous donner un indice sur ce qui se passe exactement et nous orienter dans la bonne direction pour trouver une solution pour mettre fin à cette attaque ou réduire son impact sur nos systèmes et pour empêcher de telles attaques à l'avenir. Cela aiderait à protéger les services cachés de Tor dans le monde entier contre de futures attaques comme celle que nous subissons.
2. Quelle est la configuration ?
- Le système fonctionne sur un serveur linux (amd64) actuel et toujours à jour.
- Tout le trafic passe par Tor via Tor transport sur le port 9040, les requêtes DNS sont également résolues via Tor.
- Le service caché Tor est v3
- Tor est la version 0.4.7.8 fonctionnant avec Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 et Glibc 2.31 comme libc
- Tor compilé avec GCC version 10.2.1. Vanguards 0.3.1 est également installé.
- Tor fonctionne en tant que service systemd
- Vanguards fonctionne en tant que service systemd
Configuration de torrc :
CookieAuthentication 1
HashedControlPassword 16:<hash> (mot de passe haché)
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Quels sont les symptômes ?
- Moins d'une minute après le démarrage de Tor avec le service caché activé, le CPU atteint 100%, la mémoire ne semble pas affectée.
- La bande passante utilisée augmente d'environ 100kb/s
- Le descripteur du service caché est inaccessible.
- Le système peut toujours résoudre les adresses clearnet et Tor
- Le système peut toujours se connecter à des services sortants (ex. curl vers un site web)
- Le système est inondé de paquets tcp entrants sur l'interface loopback
- Lorsque Tor est redémarré, l'inondation s'arrête pendant quelques secondes, puis reprend.
- Lorsque Tor est démarré sans que le service caché soit activé, il ne semble pas y avoir de problème.
- Lorsque Tor est démarré avec un second service caché activé, les deux descripteurs de service caché restent inaccessibles :
Tor Browser on Primary HS :
Onionsite s'est déconnecté
La cause la plus probable est que l'onionsite est hors ligne. Contactez l'administrateur de l'onionsite.
Détails : 0xF2 - L'introduction a échoué, ce qui signifie que le descripteur a été trouvé mais que le service n'est plus connecté au point d'introduction. Il est probable que le service ait changé de descripteur ou qu'il ne soit pas en cours d'exécution.
ou
La connexion a expiré
Le serveur de (attacked hidden service descriptor).onion met trop de temps à répondre.
Le site peut être temporairement indisponible ou trop occupé. Réessayez dans quelques instants.
Tor Browser sur Seconday HS :
Impossible de se connecter
Firefox ne peut pas établir de connexion avec le serveur à (descripteur de service caché secondaire).onion.
Le site peut être temporairement indisponible ou trop occupé. Réessayez dans quelques instants.
- Lorsque Tor est démarré avec un second service caché activé qui est protégé par OnionAuthentication, le descripteur du service caché primaire reste inaccessible,
le descripteur du service caché secondaire (protégé) est accessible.
- Lorsque Tor est démarré avec seulement le second service caché activé (avec ou sans OnionAuthentication), il ne semble pas y avoir de problème.
- Lorsque Tor est démarré avec le service caché principal protégé par OnionAuthentication, le descripteur de service caché est accessible.
- Lorsqu'il est attaqué, ces entrées apparaissent dans le fichier journal de Tor :
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done) : Fait
Aug 24 19:42:34.000 [notice] Votre vitesse de connexion au réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 388 buildtimes.
Aug 24 19:42:39.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 240 buildtimes.
Aug 24 19:42:53.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 489 temps d'attente.
Aug 24 19:43:11.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 659 temps d'exécution.
...
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:46:09.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 114 buildtimes.
Aug 24 19:46:15.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 125 temps d'attente.
...
Aug 24 19:47:08.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:13.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:14.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 495 buildtimes.
Aug 24 19:47:18.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 124 buildtimes.
Aug 24 19:47:21.000 [notice] Extremely large value for circuit build timeout : 122s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
Aug 24 19:47:23.000 [notice] Extremely large value for circuit build timeout : 123s. Suppose un saut d'horloge. Objectif 14 (Mesure du délai d'attente du circuit)
...
Aug 24 19:47:55.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 60000ms après 18 timeouts et 1000 buildtimes.
Aug 24 19:47:59.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du délai d'attente à 60000ms après 18 délais d'attente et 117 temps d'attente.
...
Aug 24 19:52:43.000 [notice] Valeur étrange pour le temps de construction du circuit : 121581msec. Suppose un saut d'horloge. Objectif 14 (Mesurer le temps d'attente du circuit)
Aug 24 19:52:43.000 [notice] La vitesse de votre connexion réseau semble avoir changé. Réinitialisation du timeout à 120000ms après 18 timeouts et 57 buildtimes.
Aug 24 19:52:53.000 [notice] Interrupt : exiting cleanly.
4. Qu'a-t-on essayé de faire pour résoudre le problème ?
- Nous avons configuré un tout nouveau serveur à partir de zéro, en utilisant uniquement le système d'exploitation de base ainsi que tor et vanguards dans la configuration standard, afin d'exclure la possibilité d'une mauvaise configuration sur notre serveur affecté. Dès que tor a été démarré avec le descripteur attaqué, les mêmes choses se sont produites.
- Nous avons essayé de répartir la charge sur notre serveur via OnionBalance dans cette configuration :
Serveur 1 : Exécute Onionbalance pour le descripteur de service caché principal.
Serveur 2/3/4 : Exécute le service caché sur des descripteurs de service caché nouveaux et différents.
- Cela ne ramène pas le descripteur de service caché d'origine à la vie.
- Les descripteurs de service sur les serveurs 2/3/4 sont accessibles lorsqu'ils sont ouverts directement, mais pas via le descripteur primaire désormais équilibré.
- Le CPU des serveurs 2/3/4 passe à 100 % tant que l'attaque a lieu, tandis que le CPU du serveur 1 (équilibreur) reste normal.
- L'ajout d'autres serveurs backend à l'équilibreur n'a pas fait de différence non plus.
- Nous avons ajouté ces directives au bloc des services cachés dans torrc et essayé différents paramètres :
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testé avec différentes valeurs>
HiddenServiceEnableIntroDoSRatePerSec <testé avec différentes valeurs>
Cela a permis de réduire considérablement la charge du processeur sur les serveurs 2/3/4, mais le descripteur de service équilibré reste inaccessible.
- Nous avons essayé de modifier divers paramètres dans vanguards.conf, sans succès.
- Nous avons essayé d'identifier les paquets tcp attaquants et de les bloquer via iptables, sans succès.
Notre expertise n'est pas suffisante pour se faire une idée de ce qui se passe exactement en inspectant le contenu de ces paquets tcp qui ressemblent à ceci :
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712 : Flags [P.], cksum 0x0df9 (incorrect -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attaque du descripteur de service caché)---------| TIME_CREATED=2022-08-24T19 :45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19 :45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attaque du descripteur de service caché)---------| TIME_CREATED=2022-08-24T19 :45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attaque du descripteur de service caché)---------| TIME_CREATED=2022-08-24T19 :45:25.10
Ceci est réalisé avec Tor fonctionnant sur un seul serveur. Lorsqu'il est équilibré, |---------(attacked hidden service descriptor)---------| est remplacé par les descripteurs de service des backends des serveurs 2/3/4.
Nous pouvons mettre à disposition un extrait de tcpdump plus important, si nécessaire.
5. Conclusions
Nous pensons qu'un adversaire a la capacité d'"interrompre" un descripteur de service caché (et donc le service caché lui-même) en inondant le démon Tor d'un nombre incalculable de paquets tcp, demandant à construire des circuits. C'est ce qui provoque la charge du processeur et rend finalement le descripteur de service caché inutilisable.
Quelqu'un peut-il le confirmer ?
Puisque des directives comme HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec et HiddenServiceEnableIntroDoSRatePerSec semblent être destinées à se défendre contre ce type d'attaques, tout comme les avant-gardes devraient le faire, nous ne pouvons pas expliquer pourquoi elles restent inefficaces. Peut-être que des paramètres très spécialisés de ces valeurs sont nécessaires pour les rendre efficaces. Malheureusement, ces directives (ainsi que les paramètres du fichier vanguards.config) ne sont décrites que de manière vague.
Quelqu'un sait-il comment ces directives doivent être réglées correctement pour être efficaces ?
A ce stade, nous avons épuisé toutes les références sur tor et la configuration de vanguards que nous avons pu trouver en ligne.
Encore une fois, toute aide ou information sur ce sujet serait grandement appréciée ! Nous ne pensons pas qu'il n'y ait pas de solution à ce problème.
Last edited:
