Orange répond sur le détournement de l’adresse 1.1.1.1 par la Livebox 4
We are number 1.1.1.1
Le 10 avril 2018 à 07h00
3 min
Internet
Internet
Les clients d'Orange disposant d'une Livebox 4 sont privés du nouveau résolveur DNS 1.1.1.1, monté par Cloudflare. L'explication ? Le routeur utilise cette adresse IP en interne, comme nous le confirme l'opérateur.
Les résolveurs DNS poussent comme des champignons. En 2009, Google lançait son 8.8.8.8, devenu un standard pour la vérification de problèmes liés au DNS, soit le lien entre un nom de domaine et le serveur d'un site. Sa référence est même devenue un symbole dans certains mouvements anti-censure, notamment lors du Printemps arabe.
En novembre 2017, Quad9 se lançait avec 9.9.9.9, promettant une meilleure vie privée. La semaine dernière, Cloudflare a suivi cette voie avec 1.1.1.1, qui mise également sur la sécurité et la vie privée.
En principe, utiliser un tel résolveur DNS est simple : il suffit de l'entrer dans les paramètres de son système d'exploitation, pour outrepasser celui fourni par son fournisseur d'accès. Pourtant, avec 1.1.1.1, des clients d'Orange ont eu une surprise. La consultation du site mène vers une erreur sur les Livebox 4.
« Une erreur involontaire d’attribution d’adresse »
Le 3 avril sur la liste de discussion NANOG, un responsable de Cloudflare confirme le problème, sans pour autant avoir d'explication précise. Aux abonnés gênés, l'opérateur historique recommande d'utiliser l'adresse 1.0.0.1, qui fait office d'IP de secours du résolveur DNS.
Pourquoi donc ce problème ? Contacté, l'opérateur plaide d'abord la bévue. « Suite à une erreur involontaire d’attribution d’adresse au détriment de Cloudflare, Orange est en contact et travaille en bonne entente avec cette dernière pour régler la situation dans les plus brefs délais » nous écrit-il.
La résolution du problème n'entrainera pas d'autre changement pour les clients selon la société, pour qui l'incident est bien isolé. Pourquoi donc cette adresse est-elle indisponible au départ ? « En fait, trois adresses publiques dont 1.1.1.1 sont utilisées par la Livebox 4 pour son fonctionnement interne, ce qui les rend injoignables » justifie l'entreprise.
D'autres fournisseurs d'accès seraient concernés
Elle nous assure que la question est limitée aux Livebox 4, sans lien avec le cœur de réseau ni d'épisode précédent. Selon un membre du forum LaFibre.info, le problème n'affecte effectivement pas la Livebox 3.
Pour l'ingénieur télécom Yan Grunenberger, sur Twitter, le problème viendrait du chipset Wi-Fi Quantenna. « Le bridge interne utilise 1.1.1.1 et 1.1.1.2 pour l’API entre les deux SoC. Tous les [fournisseurs d'accès Internet espagnols] ont le même souci » détaille le spécialiste.
Autrement dit, ces adresses IP sont préemptées par la Livebox pour les communications entre différents composants, alors qu'une telle adresse publique (destinée à être utilisée sur Internet) n'est en principe pas utilisable sur un réseau local, et encore moins par un appareil pour sa mécanique interne.
Selon l'un de nos lecteurs, le problème affecterait aussi des clients de SFR, que nous avons contacté pour en avoir confirmation.
Le 10 avril 2018 à 07h00
Commentaires (122)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/04/2018 à 07h07
#1
Depuis quelques jours, sur SFR THD (câble), le 1.1.1.1 remarche enfin.
Le 10/04/2018 à 07h12
#2
Pour moi ça fonctionne depuis 6 jours avec SFR coaxial.
Le 10/04/2018 à 07h15
#3
Autrement dit, ces adresses IP sont préemptées par la Livebox pour les communications entre différents composants, alors qu’une adresse publique (destinée à être utilisée sur Internet) n’est en principe pas utilisable sur un réseau local, et encore moins par un appareil pour sa mécanique interne.
C’était pas possible d’éviter ce genre de gag ? Peut-on faire communiquer les composants en interne d’une box, ou d’un appareil correspondant, sans prendre des adresses IP externe, voire des adresses IP tout court ?
C’est une question, le problème m’intéresse d’un point de vue technique. En plus, j’ai une LB 4…
Le 10/04/2018 à 07h18
#4
Quelqu’un pourrait m’expliquer le système économique des fournisseurs DNS de ce genre ? S’il n’y a aucune monétisation d’une partie des données, je ne vois pas comment le système peut vivre.
Merci " />
Le 10/04/2018 à 07h19
#5
Déjà si on pouvait changer le resolveur DNS de la livebox ça serait bien.
Là on est obligé de faire la manip sur chaque appareil.
Le 10/04/2018 à 07h20
#6
Je ne connais pas par cœur les différents normes ISO ou IEE, mais elles ne doivent pas être respectées avec ce mode de fonctionnement
Le 10/04/2018 à 07h24
#7
Je n’ai pas de solution toute faite, mais une raison importante pour Google et CloudFlare est le coût très faible quand on a déjà un réseau mondial, et l’intérêt très fort pour que le DNS fonctionne bien (en Afrique ou en Asie tous les opérateurs n’ont pas un résolveur DNS qui fonctionne bien ; et même en France, des installateurs de hotspots wifi utilisent le DNS Google par facilité)
Le 10/04/2018 à 07h25
#8
Heureusement que le fabricant n’a pas utilisé 8.8.8.8 !
Le 10/04/2018 à 07h28
#9
Le fournisseur gagne en visibilité par le simple fait qu’on en parle, et cela apporte de la clientèle pour les services existants.
Ou alors ils revendent toutes les données de connexion.
Le 10/04/2018 à 07h30
#10
C’est la bonne question !
Pourquoi utiliser des mécanismes de haut niveau (par rapport à du hardware / firmware) comme l’IP / ICMP / … ?
Pour moi, c’est un signe de « paresse intellectuelle » dans la conception des produits. Dans le monde logiciel, on parle de dévs avec les pieds.
Le 10/04/2018 à 07h34
#11
J’ai lu quelque part que ça faisait toujours une sonde de plus pour connaitre le trafic au niveau mondial.
Pas sur le contenu bien sur mais sur les noms les plus résolus, à quelle heure etc.
Pour un gestionnaire de réseau ou un CDN comme Cloudflare c’est plutôt sympa comme info.
Le 10/04/2018 à 07h37
#12
Ben j’imagine qu’il doit y avoir des plages réservées pour ce genre de choses ou au moins des conventions/normes pour empêcher ce genre de conflit, au même titre que sur internet un serveur n’aura jamais pour IP 192.168.0.1
Mais 1.1.1.1 ça sent le truc du développeur qui voulait pouvoir le taper rapidement. " />
Le 10/04/2018 à 07h42
#13
Le 10/04/2018 à 07h47
#14
C’est d’autant plus gag/grave que personne ne me fera croire que c’était TELLEMENT plus simple d’écrire 1.1.1.1 que d’écrire 10.0.0.0 qui lui est disponible en utilisation privée.
Le 10/04/2018 à 07h47
#15
en fait si: sur un système unix on peut utiliser des socket, du moment que les services sont sur le même système.
après, ça enlève peut-être un peu d’homogénéité dans le fonctionnement de l’appli si on utilise de l’IP partout ailleurs, mais ça reste plus propre que d’utiliser des adresses publiques!
source:https://en.wikipedia.org/wiki/Unix_domain_socket
Le 10/04/2018 à 07h50
#16
Pourquoi 1.1.1.1 ? parce que 1.3.3.7 était déjà utilisée ? par qui ? Tout ça n’est pas clair. " />
Le 10/04/2018 à 07h53
#17
Utiliser IP pour faire communiquer des processus sur un même système, ça marche.
(Si nécessaire, ce cher 127.0.0.1 doit pouvoir expliquer comment faire :))
Le 10/04/2018 à 07h58
#18
N’en demandons pas trop à Orange
Le 10/04/2018 à 07h59
#19
C’est ironique que Google lutte contre la censure, alors qu’ils sont eux mêmes les plus grands censeurs.
Le 10/04/2018 à 08h00
#20
Le 1.1.1.1 utilisé en interne c’est sale mais pas à 100% de leur faute, pendant très longtemps cette plage était expérimentale…
Le 10/04/2018 à 08h01
#21
Comme souvent, ça ignore les bonnes pratiques et après ça s’étonne que ça ne marche pas correctement.
Utiliser une IP publique pour faire communiquer 2 SOC, c’est fort!
Le 10/04/2018 à 08h13
#22
De ce que j’ai pu comprendre en cherchant et en m’aidant de google traduction puis directement sur le site du fabricant, le chipset wi-fi est en fait un ensemble intégré avec son processeur et son système d’exploitation (Linux). Il est connecté au routeur de la box par Ethernet. Voici un exemple de descriptif d’un de leur chipset, les interfaces RGMMI sont les interfaces Ethernet. Vu que les débits atteints sont en Gb/s cela n’est pas idiot. On voit même qu’ils ont prévu 2 liens Ethernet pour cela.
À partir de là, il est assez intuitif d’utiliser ce lien Ethernet pour communiquer et configurer le Wi-Fi.
Par contre, il devrait être proscrit d’utiliser des adresses IP routables comme 1.1.1.1 et 1.1.1.2.
Il faut utiliser des adresse IP privées, mais dans un routeur où l’on ne sait pas dans quel contexte il va être utilisé et quelle plage d’adresse privée va être utilisée avec lui. Il faut donc un système qui s’adapte pour ne pas utiliser celle choisie par l’utilisateur du router (ici, la livebox) et ça commence à être une usine à gaz…
Personnellement, j’aurais tapé dans la plage d’adresse IP auto-assignée en 169.254., cela a l’avantage que les appareils savent réagir s’ils se sont assignés la même adresse que celle du chipset Wi-Fi en s’en assignant une autre. Mais ce n’est pas génial non plus.
La faute initiale est celle du fabricant du chipset, le problème peut peut-être être résolu uniquement en travaillant sur les tables de routages interne de la box, mais j’ai un peu la flemme d’y réfléchir.
Le 10/04/2018 à 08h16
#23
Le 10/04/2018 à 08h18
#24
J’ai une Livebox 4 et le DNS 1.1.1.1 marche très bien, je ne comprends pas …
Le 10/04/2018 à 08h19
#25
Et tu interdis donc d’utiliser cette adresse sur le réseau privé derrière la Livebox : tu n’as fait que reporter le problème. Comme je le dis dans mon message précédent, il faut taper dans une plage d’adresses privées mais être capable d’en changer si celle-ci est utilisée, ce n’est pas si simple à mettre en place.
Le 10/04/2018 à 08h21
#26
Ce n’est justement pas des communications sur un même host, mais entre la Livebox (sa partie routeur) et le point d’accès Wi-Fi de cette même Livebox.
Le 10/04/2018 à 08h23
#27
Le 10/04/2018 à 08h24
#28
Le 10/04/2018 à 08h29
#29
Le problème aurait été le même en IP V6, même s’il y a plus d’adresses disponibles et en particulier plus d’adresse privées mais honnêtement, le réflexe IP V4 est assez naturel dans ce genre de cas : il y a quelques dizaines d’années d’habitudes.
Les traiter de cons, est un peu rapide, j’allais dire idiot. " />
Le 10/04/2018 à 08h38
#30
Je comprends pas, chez moi ça fonctionne " />
Le tracert me renvoie 10 sauts jusqu’à 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
Le 10/04/2018 à 08h42
#31
Le 10/04/2018 à 08h49
#32
J’ai l’impression que les adresses sont hardcodé dans le firmeware (en soit, ça évite des indirections à tout va). J’ai aussi l’impression que ces composants doivent être accessible de l’extérieur de ce réseau de composant (sinon, il n’aurait jamais eu d’accès à partir du réseau local et donc pas d’interférence).
Je voyais donc la possibilité que ces composant soient plutôt isolé dans un sous réseau local (avec leur propre baille d’IP) qui possède une IP dans le réseau local. Mais du coup, il faut un routeur pour géré le routeur… " /> mouai, on est pas sortie
Le 10/04/2018 à 08h50
#33
Le problème est peut-être déjà corrigé. Tu es le deuxième à dire que ça marche ou tu n’utilises peut-être pas le Wi-Fi.
Le 10/04/2018 à 08h51
#34
J’ai une Livebox mais je ne sais pas si c’est la “4”… Est-ce la blanche qui est fournie pour les offres fibre (Orange/Sosh) ?
Le 10/04/2018 à 08h53
#35
La 4, c’est celle là :https://assistance.orange.fr/medias/woopic/images/var/orange/storage/images/fron…
Le 10/04/2018 à 08h57
#36
Le 10/04/2018 à 08h58
#37
Le 10/04/2018 à 09h00
#38
hum pourquoi de pas mettre un genre de proxy devant comme ça il y a un réseau dédié pour les coms Wi-Fi et derrière tu rends l’interface Proxy réseau local configurable par l’utilisateur au besoin.
Après je n’ai pas étudié le problèmes réellement je me base simplement sur les commentaire, du coup il y a peu-être d’autres points bloquants.
Le 10/04/2018 à 09h03
#39
Ok merci, il va falloir que je vérifie, je ne suis pas sûr d’avoir ce modèle…
Le 10/04/2018 à 09h05
#40
Je ne comprends pas ta notion de proxy dans ce contexte. Lire mon premier commentaire sous cet article, j’explique un peu plus le contexte et les difficultés à résoudre.
Le 10/04/2018 à 09h10
#41
Le 10/04/2018 à 09h11
#42
Le 10/04/2018 à 09h15
#43
Ce n’est pas Orange qui a choisi ces 2 adresse IP mais leur fournisseur de chipset Wi-Fi : Quantenna.
Ils auraient pu faire comme cela avec des adresses IP à eux, j’y ai aussi pensé, mais rien n’empêche une ré-attribution d’adresses IP à quelqu’un d’autre a priori, donc cela aurait pu être problématique, même si moins probable.
Le 10/04/2018 à 09h16
#44
Le 10/04/2018 à 09h16
#45
Ils auraient du prendre des adresses IP 127.0.0.0/8 ou au moins non-routable " />
Le 10/04/2018 à 09h28
#46
Le 10/04/2018 à 09h32
#47
Tu aurais pu lire les commentaires précédents.
Le 10/04/2018 à 09h34
#48
Le 10/04/2018 à 09h38
#49
Le 10/04/2018 à 09h40
#50
" /> C’est la 3 que tu as, la Play, comme chez moi. Elle ne tombe pas en panne ici.
Le 10/04/2018 à 09h45
#51
Le 10/04/2018 à 09h48
#52
Je parlais de proxy dans le sens ou la config box -> Wi-fi ne peut pas être dynamique, la composante proxy permettrais de cloisonner ce réseaux fixe, et de rendre dynamique son accession grâce à la configuration de ce dit proxy.
C’était juste une réflexion sur les problématiques précédemment énoncées, et une potentielle résolution en fonction de ce que j’avais compris.
Mais c’est peu-être hors propos.
Le 10/04/2018 à 09h50
#53
Si elle pourrait éventuellement, mais il faudrait quand même que la partie routeur de la livebox la récupère pour la connaître et ça ferait une adresse de moins de disponible dans la plage. Il vaut donc mieux une plage d’adresse différente de la plage d’adresse réseau privé géré par la box. (Dans le cas auquel j’avais été confronté, cela n’était pas possible, c’était une émulation d’internet sur un lien USB.)
Le 10/04/2018 à 09h55
#54
Tu expliques “proxy” par “proxy”, je n’ai toujours rien compris. " />
C’est quoi un proxy pour toi dans ce contexte ?
Le 10/04/2018 à 10h18
#55
Si le fabricant de chipset donne la même adresse IP à tous ses composants, c’est bien qu’il s’attend à ce que cette adresse ne soit pas visible de l’extérieur. Donc, sans dédouaner totalement le fournisseur, Orange s’est planté en laissant fuiter cette adresse.
Le 10/04/2018 à 10h19
#56
Le coût de licence de VxWorks me parait incompatible avec la recherche d’économie dans tous les sens qui s’applique sur les box FAI
Le 10/04/2018 à 10h31
#57
Ce n’est pas qu’une question de coût, sur de gros volumes, ça pourrait beaucoup baisser.
C’est aussi que Linux sur ce genre de produits est nettement supérieur à la fois sur la qualité de la pile réseau et des softs disponibles. Ce n’est pas pour rien que Wind River a aussi une offre Linux pour couvrir cette part de marché.
En plus, on n’a pas besoin d’un “temps réel dur” sur ces produits.
Le 10/04/2018 à 10h38
#58
Il me semble que dans certaines entreprises ou hôtels, le portail captif pour les clients se trouve sur cette IP.
Le 10/04/2018 à 10h39
#59
Avec tout ça (et les autres lectures sur le sujet), je ne me suis toujours pas déterminé à utiliser ces DNS alternatifs..
Le 10/04/2018 à 10h44
#60
Hum désolé effectivement c’était pas très clair, j’entends par proxy dans ce cas une système qui va recevoir un flux qu’il va rediriger vers une destination différente et potentiellement sur un réseau différent (dans notre cas c’est donc un reverse proxy), mais ce n’est pas le rôle à la base d’un proxy ou reverse proxy en soit, c’est juste quelque chose que je connais pouvant s’en rapprocher, en soit un NAT pourrais aussi correspondre au besoin.
Le 10/04/2018 à 10h45
#61
En fait j’ai un boitier noir et un boitier blanc. J’ai un doute sur lequel est la Livebox 4 (vu la photo ça doit être le noir).
Le 10/04/2018 à 10h52
#62
Pour connaître le modèle de box, aller dans le menu assistance du site WEB de la box et choisir informations systèmes.
Chez moi, je vois :
modèle Livebox 3
Comme tu as un mélange de box noire et blanche, j’aurais tendance à dire que tu as aussi une Livebox 3.
Le 10/04/2018 à 11h02
#63
bah ?
et IPV6 ??
Le 10/04/2018 à 11h23
#64
Merci, je testerai ce soir " />
Le 10/04/2018 à 11h27
#65
Le 10/04/2018 à 11h45
#66
Pour obtenir une liaison avec des résolveurs DNS libres, réactifs (proches de chez soi) et non mouchards :
https://www.opennic.org/
Le 10/04/2018 à 11h49
#67
Le 10/04/2018 à 11h58
#68
Bonjour ,
Si le développement du système WiFi mis en cause est récent, ils auraient pu utiliser une plage en /30 dans 100.64.0.0/10 ( pour ceux qui ne connaissent pas du private network utilisé par les FAI).
cdlt,
Le 10/04/2018 à 12h25
#69
Ha yes je vois l’idée, merci pour vos réponses !
Le 10/04/2018 à 12h48
#70
ils utilisaient Linux + des logiciels libres, ça doit être toujours le cas et ils publient les sources ici:
https://opensource.orange.com/en/software/home-sofware/
Le 10/04/2018 à 12h48
#71
Dans le même ordre d’idée orange reroute systématiquement le port 21 vers leur serveur mail. Difficile d’auto-héberger à la maison son serveur d’email du coup…
Le 10/04/2018 à 12h54
#72
Tous les [fournisseurs d’accès Internet espagnols] ont le même souci » détaille le spécialiste. nop aucun soucis chez adamo.es
Le 10/04/2018 à 13h05
#73
Tu nous conseilles quel serveur pour la France ?
Le 10/04/2018 à 13h37
#74
Tu veux dire qu’on devrait utiliser un résolveur DNS contrôlé par des individus, qui n’y connaissent peut-être rien du tout à la sécurité ou pire qui sont malveillants et sur lesquels personne n’exerce le moindre contrôle ?
Le 10/04/2018 à 13h43
#75
+1.
Au pire le block 240.0.0.0/4 aurait été mieux qu’une adresse publique.
Le 10/04/2018 à 14h10
#76
Tu veux dire qu’ils ont enfin fait l’interception correcte des requêtes ? Non parce que sfr intercepte les requêtes vers opendns/google pour les timeout et/ou utiliser ses résultats…
Le 10/04/2018 à 14h27
#77
Jamais bon d’utiliser quelque chose de réservè pour usage futur.
À la limite 192.0.2.0/24 ou une des 2 autres plages réservées pour être utilisées en exemple dans les documentations.
Je viens de découvrir. Au moins, il y a peu de risque d’interférence.
Le 10/04/2018 à 14h28
#78
Je n’ai cité que le coût parce que ça me semblait l’argument le plus rapide.
À ce sujet, je ne crois pas que la baisse à l’unité liée à la montée en quantité soit suffisante, parce que j’ai vu des fabricants d’imprimantes laser envisager de renoncer à VxWork pour cette raison de coût.
Mais sinon, je suis d’accord sur les 2 autres arguments: La logithèque Linux imbattable, et une box ne nécessite pas de temps réel dur en dehors des traitements réseau, qui sont délégués aux bloc HW dédiés.
Le 10/04/2018 à 14h35
#79
Pour avoir vécu le passage d’un OS temps réel (autre que VxWorks) à Linux justement dans le domaine des imprimantes laser, je sais que le coût R&D de réécriture/portage est colossal et qu’il aurait permis de payer beaucoup de licences.
On l’avait fait pour les autres raisons.
Le 10/04/2018 à 14h48
#80
Pour bosser sur du VxWorks tous les jours (hélas), ce n’est pas le cout de la licence (15k€/an/poste) mais les royalties qui sont exorbitants !!! pour du projet militaire, on est sur du 2,5k€ par cible materiel, usage unique donc quand tu change de matos, tu repayes, tu veux changer par exemple le CPU, tu repayes, tu changes le code avec un nouvelle librairie, tu repayes, bref tu payes bcp.
Et autre chose, tu dois rendre des compte à Wind River tous les 3 mois sur les applications que tu développes même ceux que tu as livré chez ton client….bref si je pouvais tous passer par du linux…..
Le 10/04/2018 à 15h19
#81
Pour ma part j’utilise et utiliserai 9.9.9.9 parce que cloudflare a déjà trop d’importance et est devenu un point de vulnérabilité du web. C’est donc inutile, de mon point de vue, d’utiliser 1.1.1.1 surtout le souk que ça met sur les routeurs.
Donc bon courage à admin à qui on imposera le 1.1.1.1 comme résolveur " />
Le 10/04/2018 à 15h34
#82
My bad, c’est bien aux «royautés» que je pensais
Le 10/04/2018 à 15h52
#83
Le 10/04/2018 à 15h54
#84
Le 10/04/2018 à 16h01
#85
Le 10/04/2018 à 16h01
#86
Le 10/04/2018 à 16h08
#87
Le 10/04/2018 à 16h08
#88
Le 10/04/2018 à 16h11
#89
Yep d’autant plus que 1.1.1.1 ne propose rien de plus que propose 9.9.9.9 Donc inutile de mettre trop d’œufs dans le panier de cloudflare. Soyons raisonnables et dispatchons, ça délayera le risque.
Le 10/04/2018 à 16h30
#90
OK,
mais même en utilisant du lien Ethernet ils auraient pu utiliser autre chose que de l’IP quitte à mettre un protocole propriétaire puisque c’est de toute façon de la communication point à point en interne.
Le 10/04/2018 à 17h19
#91
Le 10/04/2018 à 17h19
#92
Le 10/04/2018 à 17h38
#93
Pour moi OpenNIC n’est pas assez fiable, au bout de quelques mois je devais souvent changer de DNS dans leur liste, pas très gérable.
Le 10/04/2018 à 19h45
#94
Les plages d’adresses IP réservées sont visibles sur cette page (en anglais).
Le 10/04/2018 à 19h55
#95
Et toute la plage 127.0.0.0/8 est dispo, la plupart des gens ne connaissent que 127.0.0.1.
Si ça se trouve ils ont plusieurs machines dans une livebox, ou ils utilisent des machines virtuelles (oups, c’est de l’embarqué). " />
Le 10/04/2018 à 19h58
#96
Faut bien augmenter son compteur de commentaire à un moment donné.
Le 10/04/2018 à 20h21
#97
Le 10/04/2018 à 22h38
#98
J’ai une Livebox 4 mais vu que j’utilise un VPN FDN sur mon routeur perso (la LB4 ne sert que de modem) je n’ai pas de problème.
Sinon, faut dire à Orange que les IP privé de classe A, B et C ça existe.
Le 11/04/2018 à 03h54
#99
Quand cloudflare parle de vie privé ou de liberté et que de l’autre coté on leur rapporte des site violant les loi de l’UE , du canada , des USA et j’en passe ,
Tel des site de vente de donnée personnel ou de faille de sécurité
Ou encore leur fameux cookie obligatoire pour supposément sépsré les bonne mahcine des mauvaise
J’ai un gros doute sur leur véritable but
J’ai du me battre pour faire retiré des donnée privé sur un siteweb et même ils disaient non responsable de ce que le site affichais même aprés trois plainte et le pire le site continu a opéré sur le service cloudflare
Je douterais même pas que cloudflare organise eux même des attaque ddos
Le 11/04/2018 à 06h05