GuiGui's Show

:)

« Au quartier général de la DGSE, boulevard Mortier à Paris, la décision du Conseil constitutionnel a eu, jeudi, l’effet d’une bombe. En déclarant "contraire à la Constitution" l’article de la loi sur le renseignement pudiquement appelé "mesures de surveillance internationale", les Sages ont tout simplement rendu illégales la quasi totalité des écoutes réalisées par le service secret français depuis 2008.

[...]

Comme l’Obs le révélait dans son édition du 2 juillet, Nicolas Sarkozy a, en janvier 2008, autorisé la DGSE à lancer un vaste plan d’espionnage des communications transitant par les câbles sous-marins (alors que jusque-là le service n’écoutait que les satellites). Pour ce faire, le service français d’espionnage a investi des centaines de millions d’euros dans la construction de stations clandestines d’interception à Marseille, Penmarch ou Saint-Valery-en-Caux, dans l’achat de plusieurs supercalculateurs Cray installés dans les sous-sols du boulevard Mortier et dans l’embauche de centaines d’ingénieurs. Le tout avec l’aide d’Orange, l’opérateur des câbles, et d’Alcatel-Lucent. Comme nous le révélions également, François Hollande a poursuivi cet effort en donnant son feu vert à un nouveau plan de "branchement" de câbles.

[...]

En gros, selon une loi votée dix-sept ans auparavant, en 1991, la DGSE devait demander l’aval d’une commission indépendante, la CNCIS, pour chaque écoute opérée sur un câble. Mais, à l’époque, le législateur n’avait en tête que les bons vieux téléphones fixes. Entre-temps, on a déposé au fond des mers des centaines de câbles en fibres optiques par lesquels transitent des millions de communications, d’emails, de SMS… Un flux gigantesque que la DGSE n’entendait pas espionner au compte-gouttes.

[...]

Pour satisfaire l’appétit du service secret, l’équipe Sarkozy a décidé de contourner la loi de 1991, sans le dire. Comment ? En adoptant un décret secret. Et en avril 2008, François Fillon signe en catimini un texte dont nous avons révélé l’existence et les grandes lignes dans le même numéro du 2 juillet. La disposition principale de ce décret "secret défense" stipule que, pour le câble, la CNCIS ne sera pas consultée écoute par écoute, mais seulement pays par pays. D’après nos informations, elle a, ces dernières années, donné son feu pour une quarantaine de pays, y compris les Etats-Unis.

Or, par leur décision de jeudi, les Sages déclarent qu’un tel décret secret est anticonstitutionnel. Si bien que jusqu’à l’adoption d’un nouveau texte de loi qui agréera au Conseil, c’est la loi précédente, celle de 1991, qui s’applique. Autrement dit, depuis jeudi, la DGSE n’a pas le droit d’intercepter massivement les communications qui transitent par les câbles (c'est-à-dire plus de 90% d’entre elles) ; elle doit demander à Matignon et la CNCIS (rebaptisée CNCTR) l’autorisation pour chaque écoute réalisée sur un câble qui arrive en France. Le fait-elle ? Impossible de le savoir.

[...]

Ironie de l’histoire : c’est justement pour éviter un tel scénario-catastrophe que la DGSE a poussé le gouvernement Valls à légiférer sur les écoutes internationales et profiter de l’effet 11 janvier pour "légaliser" ses branchements de câbles. Le 24 mars, le patron du service, Bernard Bajolet, expliquait aux députés pourquoi, selon lui, il était urgent d’adopter une telle loi. Il faut, avait-il dit candidement, "combler le fossé qui s’est progressivement élargi entre les dispositions légales et l’évolution des techniques". Il ajoutait :
Nous sentions la nécessité de consolider le cadre [juridique], surtout depuis l’affaire Snowden."

Autrement dit, il redoutait publiquement qu’un lanceur d’alerte révèle à quel point les fondements juridiques des écoutes pratiquées par la DGSE étaient contestables. Ce que les Sages viennent de faire !

Que va-il se passer dans les mois qui viennent ? Il y a fort à parier que, dans le cadre de la lutte antiterroriste, l’Elysée et Matignon vont tout faire pour que la DGSE continue à "écouter" les câbles sous-marins. »

Via https://www.laquadrature.net/fr/nouvelobs-pourquoi-les-ecoutes-de-la-dgse-sont-illegales-depuis-sept-ans

« L’objectif du mouvement OpenPower est simple : dupliquer le succès des compatibles PC, centrés sur des puces x86, dans le monde des serveurs, mais en se basant cette fois-ci sur des puces Power. IBM croit au succès de cette approche. À un point tel que la société a purement et simplement abandonné le marché des serveurs x86 pour se concentrer uniquement sur ses offres Power.

[...]

Reste que ses partenaires se montrent pour leur part plus frileux, les produits alternatifs à ceux de Big Blue tardant à arriver sur le marché. Et pourtant, le mouvement OpenPower adopte une approche très intéressante. Les serveurs s’axent autour de Linux, avec un BIOS Open Source et un design ‘clonable’, de la carte mère en allant jusqu’au processeur. Nous sommes ici en plein dans la mouvance Open Hardware.

[...]

À ce jour, 147 sociétés sont membres de la Fondation OpenPower, indique Brad McCredie. Plus de 1600 applications Linux fonctionnent sur cette plate-forme.

[...]

Du côté du hardware, les clones des puces d’IBM restent encore à l’état de projet. C’est donc du côté des serveurs qu’il faut aller chercher les premiers produits. Un seul acteur travaille activement – quoique lentement – à la mise au point de telles offres : Tyan. »

Ce guide est excellent en ce qui concerne les définitions (ce qu'est un DDoS, les motivations, les sources/outils,...), j'en recommande la lecture. En revanche, ce guide est beaucoup plus léger sur la prévention et à la réponse aux incidents, beaucoup trop théorique et superficielle. j'veux dire qu'on est loin de l'excellent guide sur la sécurité de BGP.

« Une attaque par déni de service vise à rendre indisponible un ou plusieurs services. Un déni de service peut consister à exploiter, par exemple, une vulnérabilité logicielle ou matérielle. L’interruption de service peut également s’effectuer en empêchant l’accès à ce service, par exemple en saturant la bande passante du réseau : on parle alorsd’attaques volumétriques. Par ailleurs, une attaque peut solliciter, jusqu’à épuisement, une ou plusieurs ressources d’un service. Il peut s’agir, par exemple, de l’ouverture d’un grand nombre de nouvelles sessions TCP dans un intervalle de temps très court, ou encore d’un nombre trop important de traitements concurrents effectués par une base de données.

[...]

Toute entité dont l’activité dépend d’une infrastructure réseau connectée à Internet peut être la cible d’une attaque DDoS. Les motivations et objectifs des attaquants sont divers, allant des revendications idéologiques à la vengeance, en passant par les extorsions de fonds. Par ailleurs, certaines attaques semblent être menées afin de détourner l’attention, et de couvrir d’autres actions illégales, comme des transactions bancaires frauduleuses [1] [2].

[...]

Ainsi, en 2014, des opérateurs français ont constaté des attaques dont le volume était de l’ordre de la centaine de gigabits par seconde, et le débit, en nombre de paquets par seconde, de l’ordre de la dizaine de millions.

[...]

Au cours des années précédentes, les opérateurs français ont constaté que la plupart des attaques durent moins d’une demi-heure. Cependant, les attaques menées dans le but d’extorquer des fonds à une société durent souvent plusieurs jours.

[...]

De nombreux outils accessibles en ligne permettent d’exploiter des botnets [8] [9]. Au cours des dernières années, des services de DDoS en ligne, couramment appelés booter ou stresser, ont fait leur apparition [10]. Ces services proposent des tarifs autorisant leur usage par des particuliers, et permettent à un utilisateur de lancer des attaques contre la cible de son choix. Par ailleurs, certains booter proposent de tester le service gratuitement pendant quelques minutes.

[...]

Comment se protéger contre les DDoS ?

Les pare-feux et les répartiteurs de charge peuvent contribuer à absorber certaines attaques DDoS, mais ils ne constituent pas une protection suffisante contre ce type d’attaque d’une manière générale. Par ailleurs, les limites de ces équipements sont parfois exploitées pour rendre des services indisponibles. Cependant, il est parfois possible de modifier la configuration de ces équipements afin d’améliorer leur résistance face à ce dernier type d’attaque (par exemple, en augmentant la taille des tables d’état).

[...]

Certains équipements dédiés [ NDLR : des appliances clés en main ] offrent différentes contre-mesures spécifiques aux attaques DDoS. Leur mise en œuvre nécessite une prise en main préalable, et un paramétrage adapté au trafic de l’entité.

[...]

Les hébergeurs offrent parfois une protection contre les attaques DDoS. Les différentes options proposées peuvent constituer une solution pour les structures faisant appel à une société externe pour l’hébergement de leurs serveurs.

[...]

L’intervention de l’opérateur de transit est parfois nécessaire, en particulier lorsque le lien réseau mis à disposition du client est saturé. Les opérateurs permettent souvent d’effectuer du blackholing de trafic basé sur la destination. Il convient de noter que cette mesure, parfois nécessaire, rend le déni de service effectif. L’opérateur peut également offrir un service de filtrage de trafic. Dans le cas où ce service est opéré par le client, ce dernier doit s’assurer de maîtriser la configuration des différentes contre-mesures offertes par la plate-forme.

[...]

Les CDN permettent la répartition de ressources sur un grand nombre de ser-veurs, ce qui peut contribuer à améliorer la résistance aux attaques DDoS.

[...]

Il est nécessaire de prendre des précautions avant la mise en œuvre d’une protection contre les attaques DDoS basée sur la résolution de nom. Cette méthode a une limite importante : le trafic à destination de l’entité ainsi protégée ne transite pas forcément par le fournisseur de la protection. [...] En effet, pour rediriger le trafic vers le service de protection, cette méthode repose uniquement sur le mécanisme de résolution de nom fourni par le DNS. Si un attaquant connait l’adresse IP originelle (par exemple, 203.0.113.2 sur la figure 2.1), il peut accéder directement au serveur sans passer par le CDN.

[...]

Le déroutement de trafic [NDLR : via annonces BGP par le prestataire de protection + tunnel GRE ou interconnexion directe avec lui ] permet de faire transiter l’intégralité du trafic vers le fournisseur du service de protection. Cette solution offre un bien meilleur niveau de protection qu’une solution basée sur la résolution de nom. En revanche, la souscription à ce type de service est généralement plus onéreuse.

[...]

Il est impératif de disposer de contacts appropriés en interne, chez les opérateurs de transit, ainsi qu’auprès des fournisseurs d’un service de protection pour réagir efficacement en cas d’attaque.

[...]

En dehors des solutions de protection spécifiques, des bonnes pratiques peuvent contribuer à améliorer la résistance à une attaque par déni de service. Parmi celles-ci, on peut notamment citer :
    • la segmentation du réseau de l’entité de manière à faciliter le filtrage en cas d’attaque, et l’isolement éventuel de certains sous-réseaux ou de certains serveurs ;

    • la mise en œuvre d’un filtrage à la bordure du réseau de l’entité afin de n’autoriser que les flux nécessaires au fonctionnement de cette dernière. Ces pratiques contribuent également à limiter le risque de participation involontaire à une attaque en déni de service (voir chapitre 4). Par ailleurs, la mise en place d’un réseau d’administration dédié est nécessaire. En effet, une attaque peut affecter significativement l’infrastructure réseau d’une entité, et ainsi entraîner des difficultés d’accès aux équipements. Au minimum, le trafic d’administration doit être marqué comme prioritaire au moyen de la mise en place d’un marquage QoS (Quality of Service).

[...]

Une entité peut être touchée indirectement par une attaque DDoS : une attaque contre une société peut affecter d’autres entités partageant la même infrastructure réseau, ou bénéficiant d’un service fourni par la cible de l’attaque.Un exemple est celui de la société nord-américaine Neustar, qui a connu une attaque DDoS entre fin avril et début mai 2014 [29]. Cet incident a entraîné des perturbations du service DNS fourni à ses clients [30].

[...]

Il est important de ne pas oublier des services qui sont parfois considérés comme étant en marge du système d’information, à l’instar de la téléphonie. À titre d’exemple, une société nord-américaine fournissant un service de téléphonie sur IP a été victime d’une série d’attaques DDoS pendant plusieurs mois entre fin 2012 et début 2013 [31]. Ces attaques ont entraîné des interruptions du service, affectant des clients de la société.  

[...]

Comment réagir face à un DDoS ?

Il est nécessaire de disposer de moyens de supervision et d’alerte afin de dé-tecter un incident.

[...]

Avant de mettre en œuvre une contre-mesure, il est important d’identifier :
    • l’élément défaillant. S’agit-il d’une saturation des liens réseau, d’une surcharge au niveau d’un serveur ou plus précisément, d’une application ? L’attaque cible-t-elle un seul hôte, ou un bloc entier du réseau de l’entité ?      

    • le ou les protocoles utilisés. Dans le cas où le protocole de transport est UDP, il convient de prendre en compte le fait que ce protocole ne permet pas d’identifier les sources d’une attaque (possibilité d’usurpation de l’adresse IP source) ;

    • les sources de l’attaque : s’agit-il de paquets provenant d’un réseau interne à l’entité, ou de l’extérieur ? L’attaque est-elle générée par un nombre restreint de sources ? Le trafic lié à l’attaque transite-t-il par un seul opérateur ?

    • un ou plusieurs discriminants permettant de distinguer le trafic légitime du trafic généré par l’attaque (par exemple, des motifs récurrents dans le contenu des paquets, des valeurs remarquables dans les en-têtes HTTP).

[...]

En outre, un certain nombre de dispositions peuvent être prises au niveau de l’entité ciblée. Parmi celles-ci, on peut notamment citer :
    • le blocage des adresses IP sources identifiées comme étant à l’origine de l’attaque ;

    • le blocage du type de trafic impliqué dans l’attaque, et non nécessaire au bon fonctionnement de l’entité (filtrage sur le port destination, par exemple) ;

    • la limitation du nombre de connexions concurrentes par adresse IP source au niveau d’un pare-feu ;

    • la réduction des délais de garde des connexions TCP (par exemple sur des serveurs web ou SMTP) ;

    • le blocage du trafic à destination des cibles, en fonction de l’impact de l’attaque sur le reste de l’infrastructure réseau.

[...]

Déclaration d'incident

Les opérateurs de communications électroniques, en application du Code des Postes et des Communications Électroniques (CPCE, article D98-5) [36], ont l’obligation de déclarer les incidents qui ont un impact « significatif » sur la disponibilité des services auprès du Centre Opérationnel de Gestion Interministériel de Crise (COGIC) du ministère de l’Intérieur. Par ailleurs, dans le cas d’un incident significatif dû à une attaque informatique, à l’instar d’une attaque DDoS, les opérateurs doivent effectuer une déclaration auprès de l’ANSSI. Aujourd’hui, un incident est considéré comme significatif s’il affecte au minimum 100 000 abonnés. Il convient de noter que ce seuil est susceptible d’évoluer dans le futur.

[...]

Comment éviter de participer à un DDoS ?

[...]

Réduction de la surface dʼattaque

[...]

Désactivation des services inutiles

[...]

Durcissement des systèmes dʼexploitation

[...]

Durcissement des configurations des services

[...]

Un attaquant peut exploiter une inclusion dynamique de fichiers (Remote File Inclusion ou RFI) dans le code d’une application pour déposer des scripts qui lui permettront ensuite d’exécuter des commandes (par exemple, un shell PHP). Les RFI sont parfois utilisés pour créer des botnets. En 2012, une campagne d’attaques par déni de service contre des institutions financières nord-américaines a été menée à partir d’applications compromises via ce type de vulnérabilité

[...]

Filtrage du trafic
L’accès aux services d’une entité doit être restreint afin de n’autoriser que les réseaux internes à celle-ci. Par ailleurs, la mise en place de règles de ratelimiting peut réduire une éventuelle participation à une attaque par déni de service. Enfin, le trafic sortant de l’entité doit être filtré afin de bloquer l’envoi de trafic pour lequel les adresses IP sources sont usurpées. »

« Snoopy is a pretty cool piece of software that can log every exec(3) call to syslog. When it comes to security, that feature can be really handy. Yesterday (Dec. 5), I commited security/snoopy to pkgsrc. The package comes with GNU/Linux related scripts in order to modify /etc/ld.so.preload so libsnoopy is loaded before libc and achieve its role.

[...]

nce done, /var/log/authlog will be filled with lines like:

Dec  6 09:36:46 coruscant snoopy[19394]: [uid:1000 sid:4525 tty:(none) cwd:/home/imil filename:/sbin/sysctl]: sysctl vm.loadavg
Dec  6 09:36:46 coruscant snoopy[29510]: [uid:1000 sid:4525 tty:(none) cwd:/home/imil filename:/usr/bin/cut]: cut -f2-4 -d »

OYEAH \o/ Snoopy est dans les packages Debian et juste fonctionne. Il faut ouvrir un nouveau terminal pour que le chargement de la lib soit effectif.

« Le blog Netzpolitik, engagé dans la défense des libertés numériques, fait l’objet d’une enquête préliminaire après avoir publié en début d’année des documents présentés comme les projets de l’Office de protection de la Constitution (renseignement intérieur) pour surveiller Internet. Jeudi, le blog a révélé que M. Range avait lancé une enquête préliminaire pour « trahison » contre deux de ses journalistes, du jamais-vu depuis le début des années 60.

Ces révélations ont provoqué une vague de protestations en Allemagne, de la part des médias et de responsables politiques accusant la justice de volonté de censure. Le site a également reçu le soutien d’organisations de défense des libertés individuelles dans plusieurs pays. Vendredi, les poursuites pour « trahison » avaient finalement été suspendues, dans l’attente d’un examen plus complet des documents publiés pour déterminer s’ils relevaient bien du secret d’Etat.

Coup de théâtre, ce mardi matin : dans une déclaration extrêmement inhabituelle, par communiqué et devant les caméras, le procureur général Harald Range a accusé le ministre de la justice, Heiko Maas, d’« attaque intolérable contre l’indépendance de la justice ».

Dans sa contre-attaque, le procureur Range explique qu’un expert indépendant a jugé que les documents mis en ligne par le blog relevaient bien du secret d’Etat, comme l’affirmait le patron du renseignement intérieur, Hans-Georg Maassen, qui a porté plainte contre X.

[...]

Plus largement, il explique que « la liberté de la presse et d’expression est un bien de valeur. Mais cette liberté, y compris sur Internet, n’est pas illimitée. Elle n’exonère pas les journalistes du devoir de respecter la loi ». « Il est de la responsabilité de la justice de faire respecter la loi, écrit-il encore. Je ne peux accomplir cette tâche que libéré des influences politiques. »

[...]

Mardi soir, M. Range a été mis d’office à la retraite anticipée par le ministère de la justice, au motif que « la confiance [envers M. Range] a désormais disparu ». »

Mais, comme le note Ars Technica (http://arstechnica.com/tech-policy/2015/08/germanys-top-prosecutor-fired-over-netzpolitik-treason-probe/) : « Moreover, as the Netzpolitik.org journalists point out, Range may have gone, but the investigation into their publication has been suspended, not dropped. The treason affair is by no means over. » ;)

ÉDIT DU 10/08/2015 À 17H10 : Fin de l'histoire : http://www.lemonde.fr/pixels/article/2015/08/10/la-justice-allemande-renonce-a-poursuivre-deux-journalistes-pour-trahison_4719275_4408996.html ? FIN DE L'ÉDIT.

Quagga et BIRD sont tous deux d'excellentes suites de logiciels de routage (création automatique des tables de routage, utilisées pour transférer les paquets IP).

Les deux sont très bons pour faire des tests et des maquettes mais en production (route server, routeur d'un FAI associatif ou autre petite structure,...), certaines contraintes apparaissent. Actuellement, ma préférence va à BIRD (pour les raisons que je vais exposer ci-dessous) mais sur un même réseau, même associatif, on peut vouloir de la diversité du code pour éviter les embrouilles (exemple : attribut 99 - https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/). Mais la diversité a un coût en maintenance : il faut maintenir deux fichiers de conf', dans deux syntaxes différentes et trouver les équivalences entre les syntaxes.


Bien que j'ai utilisé BIRD et Quagga dans différents contextes (RPKI+ROA (http://www.guiguishow.info/2013/09/18/securiser-le-routage-sur-internet/), OSPF (http://www.guiguishow.info/2013/07/27/routeurs-logiciels-et-ospf/), route reflector BGP (http://www.guiguishow.info/2013/09/15/mettre-en-place-un-route-reflector-bgp-avec-quagga-pour-samuser/)), je parlerai uniquement de BGP dans la suite de ce shaarli.


Différences entre BIRD et Quagga :
    * Protocoles de routage supportés. BIRD : BGP, OSPF, BFD, RIP, static, RA. Quagga : BGP, OSPF, ISIS, RIP, static et, en dehors du package : OLSR et LDP.

    * De par sa popularité, c'est souvent dans Quagga que sont développés des fonctionnalités/protocoles (exemples : Babel fût un temps ; RPKI-RTR ; Graceful Router Updates for Link-State Protocols,...)

    * La modularité en démons (zebra, ospfd, bgpd,...) de Quagga semble mieux comprise que la modularité en protocoles de BIRD (kernel, ospf, bgp,...) alors qu'il s'agit de la même chose. Notons que l'un comme l'autre peut être compilé avec le support d'un nombre restreint de protocoles de routage (pour les adeptes du code minimal sur un router ;) ).

    * BIRD est à la fois plus brut de fonderie (la syntaxe de la configuration, les filtres, bref tout ressemble à un langage de programmation avec sa syntaxe propre) mais est aussi plus simple, plus concis et plus compréhensible que l'enchaînement des commandes IOS que l'on retrouve dans Quagga. Ça se vérifie particulièrement pour l'usage de sessions BGP over IPv6. BIRD : fichier de configuration séparé, CLI séparée,... Quagga : il faut penser à virer le support IPv4 over IPv6 (no neighbor 2001:db8::1 activate) pour ne pas avoir de préfixes IPv4 qui circulent sur la session IPv6 puis à activer la capability Multiprotocol Extensions pour IPv6 (address-family ipv6 + neighbor 2001:db8::1 activate) puis bien positionner les filtres et compagnie dans le bloc de la capability. En ce sens, Quagga est plus brut de fonderie, respecte l'aspect extensions de BGP et le format des paquets alors que BIRD offre une abstraction : je veux faire de l'échange de préfixes IPv6 sur une session BGP over IPv6, point, active les extensions kiVontBien tout seul.

    * BIRD supporte les tables de routage multiples (une par instance du protocole « kernel », directive « kernel table <table_ID> »). Quagga ne supporte pas les tables de routage multiples, seulement le changement de la table utilisée (directive « table » dans Zebra).

    * BIRD permet de spécifier l'adresse source à indiquer lors de l'export des routes vers le kernel. Cela permet de faire en sorte que le routeur lui-même (ça ne concerne pas les paquets qui transit par le routeur mais dont le routeur n'est pas l'émetteur) utilise cette adresse IP lorsqu'il sortira un paquet vers une destination donnée en utilisant la route injectée par BIRD. Très pratique pour que les messages ICMP soient émis avec une IP précise bien identifiée/identifiable. Cela permet donc de jouer sur l'algorithme de sélection de l'adresse source à utiliser. Puisque certains prestataires (transitaires IP) bloquent le trafic sur les IPs d'interconnexion, cette directive permet de spécifier une IP de votre propre allocation et permet donc au routeur d'émettre avec cette IP plutôt qu'avec l'IP d'interconnexion. Il s'agit de la directive « krt_prefsrc = <IP_à_utiliser> » à spécifier dans un export filter dans le protocole « kernel » sous BIRD. Sous Quagga, l'équivalent est d'utiliser, dans Zebra, la directive « ip protocol bgp route-map <nom_routemap> » ainsi qu'une route-map avec la directive « set src <IP_à_utiliser> ». Cette directive n'est pas disponible en IPv6 sous Quagga... Voir ci-desous pour un contournement.


Quelques petits trucs à connaître :
    * Lors de l'établissement d'une session iBGP directe (sans routeur intermédiaire), il faut ajouter la directive ... « direct » dans la configuration du protocole bgp de BIRD. Dans le cas contraire, BIRD s'attend à devoir utiliser une route existante pour transférer les paquets au next-hop indiqué dans les annonces BGP et, n'en trouvant pas, indique que toutes les routes échangées sont « unreachable ». Ce point ne concerne pas Quagga ;

    * Si la session BGP over IPv6 est montée sur un adressage link-local (fe80::/10), il faut spécifier l'interface : « neighbor fe80::1%eth0 as 65000 » pour BIRD, «
neighbor fe80::1%eth0 interface eth0 » pour Quagga. Les adresses link-local IPv4 (169.254.0.0/16) ne sont pas concernées car pas considérées comme de véritables link-local (regardez un output de ip a s, le scope sera bien global ;) ) ;

    * Pour reproduire le comportement de krt_prefsrc en IPv6 avec Quagga, il faut ruser : il faut utiliser une interface dummy avec l'IP globale à utiliser en « scope global » et indiquer un scope link pour toutes les autres interfaces réseau, même celles adressées avec des IPs globales. Ainsi, pour sortir, le noyau sera forcément obligé d'utiliser la seule IP dont la portée est globale, c'est-à-dire celle de la dummy. « ip a a <IP>/<netmask scope link dev eth0 » ou « scope link » dans /etc/network/interfaces pour rendre ça persistant. :)

    * Il est d'usage de laisser les démons de routage créer une route de blackhole correspondante à l'allocation qui sera annoncée en BGP. Cela permet au routeur de se débarrasser au plus tôt d'un paquet pour lequel il ne connaît aucune route pour joindre la destination (cas d'une IP ou d'un sous réseau, que vous n'avez pas encore attribué). Cela permet également que ces paquets ne soient pas renvoyés sur l'interface de transit si vous n'avez pas filtré votre allocation en input de votre BGP. ;)

        Sur BIRD, en IPv4, comme en IPv6 : « route <allocation> unreachable; » dans un protocole static.

        Sous Quagga :
            En IPv4 : « ip route <allocation> <netmask> Null0 » dans Zebra.

            En IPv6, la cible blackhole (traduction de Null0 sous Linux) n'existe pas dans les vieux kernel (3.2). Or, Quagga souhaite rester compatible. Il faut donc ruser et utiliser la cible lo + reject : « ipv6 route <allocation> ::1 reject ».

        Pour info, dans Linux : reject = unreachable = on rejette le paquet en envoyant un message ICMP à la source présumée du paquet ; drop = blackhole = on supprime le paquet sans rien dire. Blackhole et unreachable sont plus récents.


    * Soit l'interface tap d'une machine virtuelle configuée avec « ip a a 198.18.0.1/24 dev tap1 » et « ip r a 192.0.2.0/24 via 198.18.0.2 dev tap1 ». On sait que, lors de la destruction d'une interface, Linux nettoie les routes associées à cette interface. Que se passe-t-il à l'arrêt de la VM (ou sa migration à chaud avec Ganeti) ? BIRD : BIRD prend en compte la disparition de l'interface (protocole device) et fait aussi le ménage dans ses routes importées. Quagga : Quagga détecte bien la disparition de l'interface, vire la route associée (198.18.0.0/24 dans notre exemple) mais garde l'autre route (ici : 192.0.2.0/24) ... avec une interface inconnue (exemple : « 192.0.2.0/24, via unknown ») et continue à l'annoncer en iBGP ou en OSPF...

Ce que je retiens de Kafka : mécanisme de transmission de messages / queue , réparti, conserve l'ordre des messages, l'unité pour le passage à l'échelle est la partition.

Pour les cas d'utilisation possibles, voir : https://kafka.apache.org/documentation.html#uses. Je m'en sers pour injecter et conserver un flux Netflow (provenant d'un gros réseau), ce qui me permet d'alimenter un cluster Storm qui réalise un traitement sur ce Netflow (enrichissement + production de stats).

Notons que Kafka utilise Zookeeper pour stocker les membres du cluster, les partitions ainsi que les derniers offsets consommés par les clients dans chaque topic. Notons qu'un producteur n'a pas besoin d'aller chercher des infos dans Zookeeper : il contacte simplement un broker qui, via le protocole Kafka, lui indiquera les topics, les partitions et les replicats. Un consommateur a forcément besoin de s'enregistrer auprès de Zookeeper (dernier offset consommé). Pour ceux que ça intéresse : Zookeeper repose en partie sur les algorithmes de Lamport. ;)

Notons que si l'on a besoin d'avoir un cluster mi-privé (un cluster dans lesquels les membres doivent se parler via un réseau cloisonné adressé en RFC1918 mais où des clients externes doivent aussi joindre les Kafka, il y a une directive de configuration pour cela, « advertised.host.name » pour s'enregistrer différemment dans Zookeeper et fournir les bons noms dans les métas-données échangés avec un client. Sauf que ce n'est pas terriblement efficace et que je préfère traiter le problème via un mécanisme de nommage (DNS ou /etc/hosts) qui est fait pour ça. Voir : http://shaarli.guiguishow.info/?PazcBw

Comme dans tous les systèmes répartis, quand ça marche, ça juste marche bien et ça dépote mais quand ça chie, le debug est vraiment galère : identifier la partition qui pose problème dans les logs puis savoir quel logiciel produit et consomme dans cette partition puis... D'autant plus que les messages d'erreur de Kafka sont loin d'être explicites. Exemples :
    * Dans les logs d'un producteur : « Could not create kafka client : kafka server: Replica infomation not available, one or more brokers are down. » -> la machine leader pour une partition doit être en rade. Il faut arrêter les consommateurs Kafka, reboot la machine kafka en rade et fsck les partitions utilisées par Kafka. Refaire partir kafka. Les producteur devraient remonter.

    * Dans les logs d'un broker (server.log.<date>), Kafka se plaint d'index invalides lors d'une reprise après incident. Il faut stopper le broker et supprimer les fichiers d'index invalides dans le dossier data de Kafka (mv /kafka/<ID_partition>/*/*.index ~/backup/)

    * Dans les logs d'un broker (server.log.<date>), Kafka se plaint que les index demandés sont trop vieux : vos consommateurs sont à la traîne. Soit il y a un problème de leur côté, soit il faut augmenter la durée de conservation des données dans Kafka.

    * Le message le plus incompréhensible est celui d'un Kafka qui refuse de démarrer, prétextant un fichier d'index invalide alors qu'il n'y a aucun fichier dans le dossier de données ! Il faut vérifier à ce qu'il n'y ait aucun fichier caché, en fait. Cela arrive quand vous montez des partitions fraîchement créées dans le dossier de données (cas d'usage : plusieurs partitions sur plusieurs SSD dans l'optique de répartir la charge).

« A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time. [...] A time series of stock prices might be called a price curve. A time series of energy consumption might be called a load profile. A log of temperature values over time might be called a temperature trace.Despite the disparate names, many of the same mathematical operations, queries, or database transactions are useful for analysing all of them. The implementation of a database that can correctly, reliably, and efficiently implement these operations must be specialized for time-series data. [...]

A workable implementation of a time series database can be deployed in a conventional SQL-based relational database provided that the database software supports both binary large objects (BLOBs) and user-defined functions. SQL statements that operate on one or more time series quantities on the same row of a table or join can easily be written, as the user-defined time series functions operate comfortably inside of a SELECT statement. However, time series functionality such as a SUM function operating in the context of a GROUP BY clause cannot be easily achieved. »


OpenTSDB est quand même limité :
    * Problème d'optimisation dans le stockage hbase utilisé derrière ;
    * Au-delà de fonctions de base (sum, union, moyenne,...), rien n'est proposé par OpenTSDB, ce qui est extrêmement limitant ;


Pour les usages avancés, une société commerciale, Cityzen Data (http://www.cityzendata.com/), propose une infrastructure et un langage (Einstein) pour stocker et traiter les séries temporelles. Quelques points sur cette techno :
    * Ça marche et plutôt bien : je pousse environ 37000 métriques par minute, toutes les minutes de chaque jour et la plateforme les acquitte en 1-2 secondes (stockage sécurisé dans kafka et traitement au fil de l'eau) :D ;

    * La documentation (https://api0.cityzendata.net/doc/) est plutôt faible : un gros effort est fait mais il y a encore des fonctions non documentées. Exemples : FINDSTATS pour obtenir des informations sur vos séries (erreurs, nombre d'éléments stockés,...) ou '<votre_token>' AUTHENTICATE <nombre> LIMIT pour remonter (avec FETCH) plus de métriques que la limite pré-configurée,... De plus, la documentation existante n'est pas toujours complète... Comme la documentation officielle est encore la seule source d'information disponible, c'est parfois difficile de s'y retrouver ;

    * Système interopérable : les données se poussent sur la plateforme via une requête HTTP POST, elles se récupèrent au format JSON via une requête HTTP GET. Un mécanisme de push/pull via les websockets est aussi disponible. Les erreurs retournées sont claires et compréhensibles ;

    * Un langage de manipulation des séries est proposé : Einstein. Il est exécuté côté serveur donc on récupère uniquement les métriques qui nous intéressent, après traitement. C'est un langage à pile (exemple :  1 60 * 60 * 'noSecondesInOneHour' STORE) dont la gymnastique n'est pas celle naturelle à notre cerveau donc il faut de l'entraînement et de la persévérence ;

    * Peut être couplé avec Grafana (https://github.com/CityzenDataOSS/grafana-warp) pour produire facilement des visualisations graphiques ;

    * Limite : il manque encore des fonctions super utiles comme un TOP n sur les valeurs ou un SORT des séries sur leur valeur (pour les valeurs numériques, of course) :
        * Pour le SORT par valeur, on est obligé d'avoir recours à des macros et à une projection orthogonale (car les séries peuvent être triées sur leurs abscisses (timestamp en temps normal, sans projection) avec les fonctions SORT/RSORT) ;
        * Pour un TOP n, il faut se souvenir que la fonction SHRINK trie automatiquement la série (c'est dans la doc') par ordre croissant. Donc, si l'on veut récupérer les N plus grandes valeurs, il faut demander à SHRINK de prendre ces N valeurs à partir de la fin : « N -1 * SHRINK ». Petite subtilité : si N est pile le nombre d'éléments dans la GTS, SHRINK n'est pas exécutée et donc vos élements sont affichés sans être triés. Donc ceinture et bretelles : « (R)SORT N -1 * SHRINK ». :)


Une autre source d'information sur CZD : Domotique : Valoriser et exploiter les données chez GuiguiAbloc - http://blog.guiguiabloc.fr/?p=1700

« Peu connu du grand public, le mathématicien hongrois John von Neumann (1903-1957) a pourtant élaboré des théories qui ont définitivement changé le cours de l'humanité. Installé aux États-Unis à partir de 1930, il a contribué aux découvertes les plus fondamentales (théorie des jeux, intelligence artificielle, physique statistique, entre autres) du siècle dernier et a initié la révolution informatique. [...] Pionnier de l'informatique, il conçoit Maniac, un calculateur utile aux tests de la bombe H et ancêtre des premiers ordinateurs. »

ÈDIT DU 09/08/2015 À 18H : Vu.
    * 1903 - 1957. Haute bourgeoisie du début du 20e siècle par son père, banquier. Enfance à Budapest. Arrière-plan culturel juif ;

    * « Von Neumann » = titre de noblesse donné par l'empereur François-Joseph Ier d'Autriche à son père pour sa participation à l'effort de guerre ;

    * Théories : automates cellulaires, architecture des systèmes de traitement de l'information, similitudes entre cerveau humain et ordinateur, théorie du jeu, théorie de la destruction mutuelle assurée, fondement mathématique de la mécanique quantique, pseudo-hasard par utilisation de suites numériques,... ;

    * Intelligent et créatif (il trouvait des solutions originales selon ses comparses). Von Neumann ne découvre pas, il explique. Il n'approfondit pas, il laisse le soin à d'autres de développer ses idées ;

    * En 1919, révolution bolchevique -> esprit "mort aux banquiers" -> sa famille est menacée. Quelques mois après, c'est la montée d'un antisémitisme dans toute la société. Cela le marquera et sera déterminant dans beaucoup de choix (notamment le fait de conseiller une guerre préventive nucléaire contre l'URSS) ;

    * En 1930, l'Europe est instable, les USA prennent conscience de leur retard en mathématiques et vont chercher les meilleurs mathématiciens en EU. Sa nouvelle vie ? Consultant pour les armées britanniques et américaines : le calcul de trajectoire lui a plu dès son enfance. Il organisait chez lui de grandes réceptions où se retrouvait l'élite intellectuelle dans une ambiance conviviale, rappelant celles des cafés intellectuels de Berlin, par exemple ; Il aimait l'alcool fort et les blagues salaces ;

    * Pendant la seconde guerre mondiale, il participera à l'élaboration de la bombe atomique, au calcul de la hauteur optimale (car elle conditionne les dégâts) lors du largage sur Nagasaki, au choix des cibles (son choix ne sera pas retenu). Note : Hitler n'a pas compris la portée de l'arme nucléaire car il la considérait comme une « idée de savant juif » ;

    * Von Neumann était un grand pessimiste de la nature humaine : il pensait que la probabilité que l'humanité se détruise par un manque de contrôle des instruments qu'elle a créés était forte ;

    * 1945 : architecture Von Neumann des systèmes de traitement de l'information (une mémoire, un traitement central et une unité de traitement des données). Il écrit 3 pages de recommandations. Il veut améliorer l'ENIAC en ne faisait plus la différence entre le calcul (réalisé sur la machine) et la programmation (mains humaines, cartes perforées,...) -> MANIAC. Usage initial prévu : calculs pour la bombe H puis prévision à long terme du climat car il voyait sa maîtrise comme une arme encore plus forte que les armes nucléaires. Il établit que l'on peut fabriquer des ordinateurs fiables à partir de composants non fiables tant que le pourcentage de non fiable reste en dessous d'une limite ;

    * Il avait compris l'accélération constante du progrès technologique : la langue parlée a mis 100000 ans pour s'imposer, la langue écrite a mis 10000 ans, la presse a mis 400 ans, le téléphone 50 ans, le téléphone portable 7 ans, les réseaux sociaux et autres : 2 ans ;

    * Meurt d'un cancer qui a détruit ses facultés intellectuelles.
FIN DE L'ÉDIT