On 02/20/2012 02:21 PM, Stephane Bortzmeyer wrote:
Plus sérieusement, .fr est conçu pour résister à des attaques dDoS
jusqu'à une _certaine_ taille (merci à Fernand R. pour la
précision). Cette résistance a été vérifiée aussi bien par les
organismes nationaux (ANSSI) que par des trucs internationaux (ICANN,
pour les candidatures de l'AFNIC à la gestion de TLD). Donc, ne me
croyez pas sur parole, interrogez les gens qui ont vérifié de
l'extérieur.
ce rapport là:
http://www.ssi.gouv.fr/IMG/pdf/2012-02-10_CP_Piranet12.pdf
savez-vous ce que j'en ai pensé quand je l'ai vu ?
Un baba-cool qui revient d'un séminaire Haré Krishna écrit la même chose
à sa douce, "il a appris plein de trucs". (*)
Et puis après je me suis dit "humm, ce sont des militaires, des menteurs
professionnels (à nous les civils), ressaisis toi, ils jouent comme à
leurs habitudes, un coup de propagande".
Mais je doute quand même, tout simplement parce que "si vis pacem para
bellum" c'est une de leurs raisons d'être, la dissuasion. Ils ont
d'autres rôles, mais celui-ci est quand même important.
Mais est-ce que ce rapport dissuade un ennemi potentiel par un
inventaire impressionnant ?
A mon avis, ce rapport ne dissuade personne, parce qu'il y manque le
classique du défilé militaire démonstratif, l'inventaire de ce qui
attend l'ennemi s'il bouge le petit doigt.
Alors s'il satisfait tout le monde, moi non, j'aurais bien aimé savoir
ce qu'ils ont appris.
Quant aux Jupiter du code qui pondent des Stuxnet, ils se sentent
pousser des ailes avec un rapport comme celui-ci.
Un des élements clés de cette conception est l'utilisation de serveurs
anycastés (presque tous les serveurs de .fr, désormais), sur une
centaine de sites en tout.
L'anycast, ce n'est pas le Saint Graal. D'une point de vue logique,
quelle est la résultante d'une architecture anycast ?
Juste une agrégation de capacité réseau qui est distribuée sur un
territoire.
Quand on constate cela, on comprend tout de suite que l'anycast ne
change pas fondamentalement la situation par rapport à l'unicast, et que
le Saint Graal n'est pas si saint que cela. Cela peut quand même le
devenir, mais il y a des conditions ultra strictes à respecter, qui,
lorsqu'on dessert la totalité de l'Internet, ne pourront pas ou très
difficilement être réunies, à cause de son coût ou du fait que l'on vous
ferme le cœur des opérateurs qui peuvent agréger un énorme trafic
générateur.
Et je tiens à vous rappeler que vu de l’extérieur, l'anycast n'est
visible _que_ sur le rtt: 5ms depuis Los Angeles et 5ms depuis Paris,
c'est forcement une IP anycast. La physique interdit une telle
performance en unicast.
J'attire votre attention sur les pages 9, 10 et 15 du dernier rapport
d'activités
<http://www.afnic.fr/medias/documents/afnic-rapport-activite-2010.pdf>.
Désolé, vos pages ne comblent pas ma faim.
Voilà une question simple:
Combien de giga/s au total sur toutes vos cellules anycast s'il vous
plait ?
Une somme, ce n'est pas la mort à faire.
(mais cela peut être comme "la mort" de ne pas obéir au chef)
Il serait évidemment très imprudent de dire qu'on est
invulnérables. Disons simplement que le problème est connu et qu'on le
suit de près, de la conception des serveurs, jusqu'aux mesures
d'urgence (service d'astreinte, monitoring, etc). Nous maintenons une
veille active sur ces problèmes et testons régulièrement de nouveaux
joujous.
A l'armée, en médecine, en architecture (la vrai, les pont, immeubles)
en économie ... dans une multitude de domaines la vulnérabilité se
mesure, se quantifie. Alors, quelles sont, ou serait la ou les bonnes
mesures de la vulnérabilité d'un réseaux (anycast ou pas ) ?
A l'armée, ils mesurent des épaisseurs de blindage, la mobilité de leurs
armées etc etc .. en médecine, ce sont les tests biologiques anticorps,
des épreuves d’effort sur un vélo etc etc .. en structure se sont les
coefficients de marges prises sur les seuils de ruptures, la qualité des
matériaux, et en réseaux, et particulièrement pour un réseaux anycast,
qu'elle est cette mesure de vulnérabilité ?
Une mesure de vulnérabilité, au sens de "mesure physique", cela devrez
vous intéresser.
Quelle est cette métrique de vulnérabilité à l'Afnic ou à la racine ?
Parfois c'est compliqué, mais vous avez les maths qui peuvent venir à
votre secours, souvenez-vous des complexes (a+ib) ou des matrices, les
deux peuvent être utiles.
Est-ce que la volumétrie à ternir pour fr. est différente de la
racine selon vous ?
Les serveurs des TLD reçoivent souvent davantage de requêtes que la
racine puisque leur base est plus grosse (la racine est en entier dans
un cache une heure après son démarrage).
Veillez m'excusez pour mon orthographe lamentable, mais l'idée de ma
question était de savoir si selon vous, le risque encouru par la racine
ou le .fr ou n'importe quel autre TLD était plus petit ou plus grand. Un
ordonnancement des risques, simplement.
En théorie, le niveau de risque est exactement le même pour la racine,
le fr. ou n'importe quel domaine. La différence étant le poids des
conséquences.
La volumétrie de production est une donnée sans aucune importance pour
anticiper un DDOS parce qu'il sera multiplié par 1 000 ou 100 000.
Mais il ne faut pas se braquer sur le nombre de bits/seconde : deux
employés de l'AFNIC qui regardent YouTube au bureau font plus de
trafic que tous les serveurs DNS ensemble. Pour un serveur DNS, le
facteur limitant est plus souvent le nombre de paquets/seconde.
Dans une utilisation normale, c'est vrai, mais dans l'absolu, c'est
faux. Il suffit d'imaginer que toute cette bande passante consacrée à
Youtube soit détournée par un virus à l'insu de l’utilisateur à faire
des "dig DNSKEY ."
La force de Stuxnet a été son extrême discrétion associée à un assez
fort pouvoir de contagion.
Sur une interface symétrique de 10g, 10g de requêtes en entrée "dig
DNSKEY ." donne combien de giga en sortie ?
Wireshark donne 59 bytes de requête pour 483 bytes en réponse, soit un
rapport de 8.18, soit 82 giga en sortie pour 10g en entrée ... avec une
interface symétrique en capacité.
Quel est le facteur limitant dans cette situation ?
Les (p/s in ou out) ou le b/s symétrique de l'interface ?
Par contre, les p/s droppé en sortie par l'interface vous donnera une
approximation des requêtes qui obtiennent une réponse, et par là, la
bande passante effective, réellement utile de votre interface à 10g en
entré. En divisant cette bande passante effective en entré par le
nominal de votre interface, vous aurez l'atténuation de capacité à
servir vos clients. Et si dans ce qui reste de requêtes qui ont une
réponse en sorties de votre interface, et que vous avez seulement x% de
requêtes légitimes (en général pour un DDOS x voisine 1 ou 2), le reste
étant "des conneries de virus", vous vous ferez une idée de ce que
voient vos clients de votre service.
Considérer la p/s n'a d’intérêt que si le protocole est symétrique, tout
le temps. Dans ce cas p/s est égale à b/s à un facteur près.
Ou lorsqu'on regarde le p/s droppé sur l'interface, là c'est
intéressant, le "p/s droppé" pas le "p/s servi"
Le "p/s servi" c'est l'unité de charge du routeur ou de la machine, pas
pour les liens réseaux, pour une vue locale et pas globale sur
l'ensemble du réseau. Et c'est ce "p/s droppé" qui donne l'impact d'une
concentration de trafic sur un nœud du réseau, l'épaisseur des copeaux
du rabot "b/s".
Dans le cas d'un protocole asymétrique comme le DNS, la distribution
statistique de l’asymétrie par requête/réponse du trafic peut évoluer
vers le cas le plus défavorable.
Et honnêtement, je ne connais quasiment aucun protocole sur IP qui ne
soit pas dans un sens ou dans l'autre un amplificateur de trafic. La
symétrie protocolaire sur IP est une rareté. La VoIP est amha, une de
ces exceptions qui font la règle.
Si vous avez d'autres contre-exemples, allez-y, aucun autre ne me vient
en tête.
Vous vous sentez plus fort ou bien moins que la racine au nic.fr et
dans quel rapport ?
Du point de vue budget et ressources humaines, je pense (cette
information n'est pas publiée) que les serveurs racine, tous ensemble,
dépensent nettement plus que l'AFNIC.
Est-ce que la racine assiste autant le .fr. que les opérateurs
assistent la racine ?
Pas clair.
Des budgets différents, des ressources différentes alors que vous avez
chacun en face de vous le même Internet à servir, les mêmes sauvages
prêts à tout et n'importe quoi.
La logique aurait voulu que vous mutualisiez vos besoins, parce qu'on
est plus forts ensembles que tout seul et que vos intérêts convergent.
La logique aurait encore voulu que les opérateurs vous donnent la
capacité agrégée que leurs infrastructures peuvent vous envoyer sans
vous imposer à faire vous même et seul cette mesure.
Maintenant, que les opérateurs Internet n'informent pas les opérateurs
de la racine ou du .fr. de leurs capacités réelles à leur envoyer du
trafic et les laissent dans le brouillard, il y a peu de chance que leur
dimensionnement coïncide avec le besoin potentiel en cas d'attaque.
Qu'est-ce qui vous fait croire le contraire actuellement ?
Je trouve que refuser de mutualiser vos ressources entre la racine et
les TLD, pour ces services DNS aussi critiques, je trouve cela une
aberration.
http://fr.wikipedia.org/wiki/Mutualisme_en_France
Je trouve très triste que cet esprit ait totalement disparu du réseaux.
Non seulement l'AFNIC (et tous les autres NIC) a à débourser autant
d'argent que la racine pour atteindre son niveau de sécurité, mais si
vous atteigniez son niveau, on aura au final deux infrastructures en
parallèles équivalentes en performance qui si elles avaient été
mutualisées, offriraient un niveau de sécurité bien meilleur.
Franchement, je ne comprends pas, vous vous détestez entre vous ou quoi?
Moi, pas comprendre.
En fait depuis trois jours, je suis en train de me dire que si vous avez
cette assurance avec des conf si petites, c'est que vous comptez sur
l'IN (Intelligent Network) des opérateurs sur réseau fixe pour qu'ils
étranglent un DDOS à votre place. Le "truc" qui manque en ce moment chez
FreeMobile, le fair-use. Mais c'est de la mauvaise sécurité parce qu'il
ne faudra pas compter sur les chinois par exemple pour qu'ils se bougent
pour vous ou des opérateurs qui n'auront pas fait le choix d'en déployer.
---------------------------------------------------------------------
(*) Si je me moque d'eux en les traitant de "baba-cool", c'est que moi,
j'ai des munitions (réseaux) que eux n'ont pas, et que vous, à l'Afnic
et à la racine non plus.
J'ai lu à maintes reprises que les protocoles state-full ne peuvent pas
fonctionner _en_permanence_ sur un réseau anycast parce qu'un paquet
peut s'égarer, et arriver sur une autre entrée de l'AS pour toucher un
applicatif qui ne le connait pas et ensuite couper la connexion.
Ceux qui disent cela manquent sérieusement de bon sens, ils n'ont qu'à
se poser la question de ce qu'ils feront s'ils voient un enfant seul en
train pleurer dans la rue parce qu'il a perdu "sa mère".
La méthode pour ramener un paquet égaré sur une autre entrée de votre AS
à cause d'un "tremblement de BGP" est identique avec l'enfant qui
pleure. Il faut regarder la source adresse du paquet et de l'injecter
dans un VPN qui le rapatriera dare dare dans sa "bonne cellule".
Et appliquer cette règle après avoir créer une partition statique de
l'Internet, une partie par cellule anycast, _garantit_ la fermeture des
circuits.
Si vous avez N cellules, vous avez N-1 interfaces VPN à l'entrée de
votre cellule, avant de toucher l'IP, qui rejoignent vos N-1 autres
cellules. Si vous avez 10^5 cellules anycast, vous utilisez toujours une
partition statique de l'Internet mais avec un réseau de VPN en flocon de
neige dont le routing à l’intérieur n'est basé _que_ sur la source adresse.
Quand BGP (ou l'IGP) n'a pas la maladie de Parkinson par rapport à la
partition statique initiale, le réseau de VPN est vide de trafic. Il n'y
a que le PPLB qui peut le remplir.
Comme cela, _tous_ les circuits se ferment "de force" on leur demande
pas leur avis, ils ne font pas "ce qu'ils veulent", et les protocoles
state full TCP, SCTP ... marchent aussi sur une conf anycast.
Et cela marche aussi sur IGP. On se moque du protocole de routing
dynamique du coté des demi-circuits parce que de l'autre coté du
demi-circuit, on remet d'aplomb, en état de marche, ce que le dynamisme
d'un protocole de routing a changé, et on le remet d'aplomb
statiquement, la partition est figée une fois pour toute par rapport un
état admis comme stable. Si cela change trop, trop longtemps, il faut
réagir sur la partition et la revoir parce que la conf anycast n'est
plus optimale.
Et je le sais depuis septembre 2007 environ, parce que j'ai été
confronté à ce problème sur un LAN, et que quand j'ai trouvé la solution
sur le LAN, je me suis dit "c'est quoi la même chose sur L3 ?"
Et pour mon info, moi qui ne suis jamais cela, depuis quand sait-on
prendre une décision de routing sur la base de la source @ sur Linux,
BSD, Cisco, Juniper etc etc ... ?
Alors, qu'est-ce qu'il faut que j'en pense des gens qui gèrent des conf
anycast et disent que l'anycast peut casser les circuits state-full ?
Et ce VPN routé sur la source @ pour fermer les circuits, j'appelle ça
un "sismographe réseau" pour que cela donne des idées à certains. Cela
peut servir à autre chose qu'à fermer des circuits state-full.
Moi, je suis un baba-cool qui sort la grosse Berta et qui tire.
Cela aurait dû être le job de l'ANSSI, aligner les canons, comme
j'estime que c'est mon devoir de vous dire que RPKI, c'est de la came à
la NSA, avec ses faux-nez Verisign et sa honteuse RFC de multiple AS
pour un réseau anycast, son BBN Techn et sa sécurité à "100 balles"
parce qu'on a trouvé une vignette pédoporno sur site web.
L'ANSSI devrait vous interdire à tous de déployer ce truc. Si vous le
faites, vous serez les mêmes Autonomous Systems que les chats ou les
singes de vivisection dans lesquel on y a planté des électrodes dans le
cerveau, vous deviendrez des Handicapous Systems.
Et si j'ai un message à faire passer à ces "amateurs" de DDOS "pour x ou
y raisons", je les invite à réviser ce qu'est la "contre-réaction", par
exemple celle d'un ampli-op et d'imaginer ce qu'elle sera à plus ou
moins long terme vis à vis des DDOS sur l'Internet.
A mon avis, la contre-réaction sera que l'Inspecteur Harry sera apte à
taper des config BGP avec le canon de son 357, et qu'Eric Freyssinet
sera aussi aimable d'un gendarme qui exige les papiers de votre voiture,
mais se sera votre PC, ou qu'un douanier qui étale tout le contenu de
votre serveur pour voir s'il n'y a pas quelque chose d’illégal dedans,
ou que la PAF juge que votre place est en rétention dans une belle
cellule anycast bien fermée et pas dehors au grand air de l'Internet.
A chaque fois qu'il y en a un qui hurle ici ou ailleurs à cause d'un
DDOS, même petit, on fait un pas de plus vers ce nouvel État de
l'Internet. L'abus de la liberté d'exploiter les faiblesses
d'architectures des réseaux IP conduira à coup sûr à une absence totale
de liberté sur l'Internet. Et résultat, il n'y aura plus qu'en Afrique
ou dans les pays pauvres où l'Internet au niveau réseau sera encore libre.
Il suffit déjà de voire ce qui se passe sur le mobile pour comprendre ce
qui va arriver sur le fixe, les CPU sont là pour ça. Et si FreeMobile
sera "protocole agnostique", c'est certainement parce que cela coute
moins cher en IN, en DPI, mais promis juré qu'il ne sera jamais
"bytes/sec agnostique". S'ils le sont actuellement, c'est qu'ils sont en
retard sur leur dev, c'est tout, parce que pour lui, ce sera aussi une
question de vie ou de mort de ses services mobiles vue la contrainte des
antennes.
Et par exemple, je suis sur SFR, j'envoie 10 paquets ping au premier
routeur juste après mon IAD, par tranche de 10 secondes environ.
Souvent, j'en perds 9 sur 10 sur le _premier_ routeur à 40 ms de moi.
Et pas une fois de temps en temps, toutes les 3 ou 5 minutes.
Comment faut-il interpréter cela ? Ça fait a peu près 1 an environ que
çà dure. Avant c'était nickel. Une idée d’où vient ce problème ?
L'UBR ATM, je n'y crois pas, j'ai de gros soupçons, mais pas de preuve,
et j'ai vérifié chez une amie qui n'a pas le même type d'abonnement que
moi chez SFR, c'est pareil.
Chez SFR, pas besoin d'arriver en haut d'un arbre réseau pour se faire
raboter son trafic, ca rabote dès le bas de l'arbre, à petit débit.
Imaginez ce que cela donne sur l'interactif ... comme si je m'en étais
pas rendu compte.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
