GuiGui's Show

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

« Une universitaire britannique, maître de conférences en psychologie, estime que les normes sociales vont fortement évoluer dans les prochaines décennies, à tel point que l'amour et le sexe avec les robots se généraliseront vers 2070, du fait des progrès en robotique et en réalité virtuelle. »

Haha. Espoir pour tous et toutes ou future désillusion en mode « Même un robot fabriqué juste pour t'aimer ne peut pas t'aimer. » (un humanoïde, à Selma, dans l'épisode 9 de la saison 23 des Simpson) ? :D

Je n'ai pas encore testé Docker mais j'ai lu un peu la doc' et j'ai assisté à une soirée qui proposait une conférence magistrale puis un retour d'expérience à partir d'un usage concret. Voici l'avis que je me suis construit à partir de tout ça.

    * Packaging sous forme de briques, logiciel par logiciel pour construire, par assemblage, une plate-forme complète répondant au besoin ;

    * La garantie d'une cohérence entre l'environnement de dev' et l'environnement de prod', dans le temps. Je ne suis pas convaincu. Rien que le fait de générer l'image à partir d'un même dockerfile peut produire des différences (des versions plus récentes des logiciels peuvent être installées durant la création de l'image, même sur un système hôte identique, simplement parce que mises à jour de sécurité) avec donc un applicatif cassé car ses dépendances (libs,...) peuvent être cassées. Pour éviter cela, on peut livrer des images complètes en plus du dockerfile (exemple : une image monentreprise-map + le docker file pour installer l'appli web). Les dépendances seront alors toujours satisfaites mais alors, qui fait les màj de sécu ? ;

    * Àmha, l'usage le plus intéressant de Docker, c'est le SaaS. Si le dev' d'un logiciel fournit un dockerfile avec les sources, alors il est possible de tester son logiciel en toute simplicité. Docker permet de monter des infra SaaS, par nature ;

    * Docker hub pour récupérer des images clés en main et pousser ses propres images. Comme des images de VM quoi. Il est bien sûr possible de créer son propre dépôt ;

    * Docker est disponible sous Mac et winwin grâce à une sorte de VM minimaliste. Le support winwin n'est pas encore mâture. Docker est même disponible sur Azur, le cloud de Microsoft. OVH est sur le coup avec SailAbove ;

    * Malgrè ce qu'on entend souvent, il y a plusieurs modes pour le raccordement d'un conteneur Docker au réseau et pas juste un mapping port par port avec l'hôte. On retrouver les modes bridges / routed habituels ;

    * De nombreuses API et briques sont déjà disponibles autour de Docker : docker-swarm pour la gestion d'un cluster de dockers, Cadvisor pour le monitoring de l'usage des ressources,... ;

    * Il paraît que Docker est monolithique : un seul binaire pour tout faire : build d'une image, récupération d'une image dans un dépôt, construction du système de fichiers, isolation réseau/processus... Rocket, un fork, se veut modulaire pour répondre à cette problématique ;

Le 19 janvier 2015, j'étais présent dans le public de la Conférence sur la réponse aux incidents & l’investigation numérique (http://www.cecyf.fr/activites/recherche-et-developpement/coriin/) organisée par le Cecyf. Voici les notes que j'avais prises ce jour-là.


Mot d'accueil par Éric Freyssinet : le but est de rassembler les enquêteurs, les entreprises, les académiques. En France, on manque de formation concernant les enquêtes numériques. Appel à forker Cecyl.


Présentation du référentiel d’exigences applicables aux prestataires de réponse aux incidents de sécurité, Yann Tourdot et Arnaud Pilon (ANSSI) :
    * Roue de Daming : PASSI (audit), PDIS (détection d'incidents de sécu), PRIS (réponse aux incidents)

    * PRIS :
        * Un prestataire qualifié = un prestataire qui suit l'ANSSI au doigt et à l'œil
       
        * Nivellement (par le bas) du référentiel au niveau des compétences en France. Sérieusement...
       
        * Vu sur twitter : "Dans l'audit, on est 2 (auditeur et audité), dans la réponse à incidents, on est 3 (avec l'attaquant, qui peut être root)" #CoRIIN
       
        * PRIS est itératif, incrémental : toujours faire des analyses post-mortem pour pas que ça se reproduise, pas juste se dire "ho j'ai un virus je le vire et basta".

        * Une action judiciaire peut être engagée avant, pendant ou après donc il faut faire attention lors de l'analyse à suivre les prérequis pour que, si l'on va en justice, la demande soit recevable (conservation des preuves, journal des actions effectuées, datation, ...)

        * Référenciel de détection établi avec des prestas (oui oui, ceux qui doivent être évalués via ce référentiel) et par des comanditeurs comme les OIV.

        * Garantie de confidentialité des analyses par les prestas et si jamais une fuite apparaît -> moyen de poser une réclamation auprès de l'ANSSI pouvant conduire au retrait de l'accréditation ANSSI.

        * Accréditation bullshit et sans valeur sauf si le commanditaire suit les recommandations de l'ANSSI de choisir un presta qualifié, ce qui arrivera sur les marchés publics...

    * Bilan : ça me semble être un label bullshit... L'ANSSI préfère avoir beaucoup de prestas que des prestas réellement qualifiés. Garantir la confidentialité des audits par retrait du label... Sérieusement, quoi. L'ennui c'est que l'accréditation a un coût qu'il faudra reporter sur le client. Elle sera requise d'abord pour les marchés publics, ce qui aura une influence sur le reste du marché...


CERTitude : ou comment simplifier les campagnes de recherche d’IOC, Vincent Nguyen et Jean Marsault (CERT-Solucom) :
C'est un soft qui se connecte à des postes compromis pour remonter les IOC (Indicator of compromise) en laissant le moins de traces que possible. Je ne comprends pas : rien que l'ouverture des connexions laisse des traces. Avantage : un tool python + une remontée via le réseau ira plus vite que la lib winwin de base. :D


D&D de malwares avec des C&C exotiques, Paul Rascagnères et Eric Leblond :
    * Fun fact : un botnet dont les zombies reçoivent les ordres du C&C via une boîte mail yahoo \o/

    * Exfiltration de données via des requêtes DNS

    * Fun fact #2 : "ils font 3 XOR, bon ok, ça revient au même que 1 XOR mais ils devaient pas le savoir [...] rigolez pas, j'ai déjà vu des attaquants faire du double riot13"

    * Les IDS c'est bien mais il faut les mettre au bon endroit : pas qu'en bordure, sinon on néglige les échanges internes

    * Les "langages" des IDS sont limités. Pas de boucle, par exemple. D'où une extensibilité avec des scripts (Lua par exemple) est souhaitable

    * Pas d'appliance magique. Même si leur usage ne nécessite pas 15 personnes en astreinte de nuit pour écrire les regex. #troll. :D

    * Les créateurs de malwares avancés suivent ce qui se dit de leur code sur le net et s'adaptent donc les règles IDS peuvent vite être contournées si tu fais pas attention.

    * Regex, ça a les mêmes limites que les antivirus : on peut faire du proactif, voire détecter des comportements anormaux donc suspects mais ça a des limites. Si tu ne sais pas ce que tu cherches -> tu ne trouveras pas, comme d'hab.


Mimikatz et la mémoire de Windows, Benjamin Delpy :
    * Bon à rappeler : les attaquants sont des bourrins, ils font des trucs qui marchent, pas des trucs compliqués.

    * Fun fact : pour tricher au démineur sous winwin, il suffit d'utiliser deux fonctions de l'API winwin : create process, read process. Pas besoin de droits admins vu que c'est ton démineur. :D

    * L'ennemi, c'pas forcément la NSA mais les anciens employés toujours dans le domaine car gestion du domaine sous-traitée donc travail pas fait.

    * La fonctionnalité minidump (dump de la mémoire lors d'un crash) est super pratique car pas besoin d'installer un code sur le poste ciblé donc discrétion. Pas besoin de droits admin, même pour dumper le processus d'un autre utilisateur : il faut "juste" faire planter le processus visé. L'API winwin permet même de demander un dump sur un processus ciblé.

    * Implémentation Kerberos de winwin + minidump = combo : les dumps mémoires du processus LSASS contiennent les mots de passe et les tickets Kerberos.

    * Fun fact #2 : Bitlocker ne marche pas avec les disquettes :D

    * Fun fact #3 : l'API winwin prévoit l'enregistrement d'une DLL qui sera appelée lorsqu'un mdp est changé.

    * Le tout permet donc de récupérer des accès.

    * Winwin 10 ne sera pas vulnérable à tout ce qui a été exposé.


Investigation dans le DNS, pièges et solutions, Stéphane Bortzmeyer (AFNIC) :
    * But de la présentation : comment trouver une info sur un nom de domaine, pièges et limites

    * Un nom de domaine a un nombre quelconque de composants. Plus spécifique à gauche, plus global à droite ("."). En voyant un nom, on ne sait pas où se trouve les cut de délégation (exemple : gouv.fr. n'est pas délégué, co.uk si) : il faut utiliser une résolution DNS pour le savoir.

    * Plusieurs acteurs dont au moins le titulaire d'un nom (celui qui l'a choisi et réservé) et le registre (l'organisme qui enregistre le nom). Dans la vraie vie, on a un 3e acteur : le bureau d'enregistrement qui s'occupe de la partie business. Modèle RRR (register, registry, registrar). On peut avoir des acteurs supplémentaires : agence de création web qui a acheté le nom ou hébergeur DNS différent du bureau d'enregistrement.

    * Deux sortes de registres : mince ou épais. Registre épais : la base de données contenant les informations "sociales" (nom du titulaire, adresse, mail,...) sont stockées chez le registre. Registre mince : ces informations sont stockées chez le bureau d'enregistrement. Exemples de registre mince : com. , net. Registre épais : fr.. Org était épais mais est devenu mince. C'est ça qui explique les redirections que l'on voit dans whois.

    * Quels sont les inconvénients à utiliser whois de manière déportée (cloud, site web,...) ?
        * Base possiblement pas à jour ;

        * On n'a pas la source de l'information (son authenticité est donc à questionner) ;

        * Le tiers voit ce que vous faites, ce qui pose de gros problèmes de confidentialité dans le cas d'une enquête judiciaire ;

        * Risque de sécurité : des malins enregistrent des noms avec des informations (nom, adresse) avec des bouts de JS/XSS.

    * Même si l'ICANN impose que les titulaires de noms communiquent des informations exactes, c'est rarement le cas et pas souvent vérifier : pour quelques euros par an, un humain ne peut pas faire de vérifications poussées.

    * Tous les clients whois ne sont pas optimaux parfois même entre systèmes GNU/Linux car les options de compilation sont différentes...

    * DNS : pas forcément de coïncidence entre whois et DNS, c'est des acteurs différents.

    * DNS et caches : attention au fast-forward (nom pour contacter le C&C change rapidement).

    * nslookup sous winwin c'est naze : incomplet, pas d'horodatage, il fait des requêtes qu'on ne lui demande pas (reverse IP, serveur de nom)

    * Mes questions :
        * Pourquoi BDDs passives DNS pas publiques compte tenu du caractère public des infos DNS (cf RFC DNSSEC) ? Sociétés commerciales derrière donc business.
       
        * Tu pourrais nous dire deux mots sur les looking glasses DNS ? C'est bien pour voir la censure et ce genre de choses. Stéphane utilise RIPE Atlas mais on a toujours les limites présentées au début de l'exposé : intervention d'un tier d'où problème habituel de confiance


Internet Explorer 10 et 11: un nouveau format de données pour de nouveaux défis, Jean Philippe Noat et Bruno Valentin :
    * Aucune logique dans le nommage des fichiers caches d'IE : webCacheV01, V16 et V24, pas les autres ... pas de logs tournants so wtf ? l'orateur n'a pas la réponse

    * Cache pas optimisé : plusieurs tables peuvent servir au même usage, semble utiliser un parcours itératif/index chelou.

    * Dans la inforensic, on cherche à savoir si un téléchargement a eu lieu suite à une action de l'utilisateur ou si prefetch ou cache : le stockage de cette info par IE est prévu.

    * Ces fichiers d'index du cache sont "sales", pas mis à jour, résiste mal à un arrêt brutal de la machine (ce qui arrive lors de perquisitions) donc beaucoup d'infos manquent à l'appel.

    * Fun fact : les applis sur FB et co échappent au cache IE au sens premier. :D

    * Fun fact #2 : le cache IE tourne toujours en navigation privée ;)

    * Fun fact #3 : l'épinglage/dé-épinglage d'une app est stocké dans une base de données sqlite. Dé-éplinger une app ne fait pas disparaitre les infos dans la base mais un re-épinglage fait disparaître les infos précédentes


FastResponder: Nouvel outil open source pour détecter et comprendre des compromissions de grande ampleur, Sébastien Larinier (CERT Sekoia) :
    * Lors d'une compromission, il faut faire une collecte rapide du SI et analyser les infos collectées rapidement pour agir vite et répondre vite à l'incident de sécurité.

    * Analyse à la mano / à la papa : chiant, coûteux et lent. Genre on trouve encore des analyses forensic faites sous Excel.

    * Il faut utiliser du matos simple à déployer et des outils de data-visualisation comme Kibana.

    * L'intérêt du live forensic (exemple : analyse RAM in-situ) se justifie avec l'augmentation de la quantité de RAM dans les serveurs (64G+ ce n'est plus rare). Je ne suis pas convaincu puisque Zythom, sur son blog, nous parle de dumps de disques durs de plusieurs tera, même pendant une perquisition...

Dans le cadre de la lutte contre la loi Renseignement, j'ai participé à une séance d'appels téléphoniques de nos élus à Brest. Une sorte de centre d'appel (call center), mais pas vraiment. J'vais faire un petit feedback sur les choses à faire / ne pas faire selon moi, en plus des conseils donnés par la Quadrature (https://wiki.laquadrature.net/Comment_contacter_un_d%C3%A9put%C3%A9_europ%C3%A9en).

    * Téléphoner seul depuis chez soi ou en groupe, ça n'est pas du tout comparable ! Seul, c'est juste chiant et on abandonne assez vite après les premiers écueils / les premières réponses bullshit de nos élus. En groupe, il y a toujours quelqu'un pour être le premier à téléphoner et initier ainsi la chaîne. Il y a toujours quelqu'un pour rire avec vous. Il y a toujours quelqu'un pour rire de la réponse stupide, antidémocratique, liberticide, bref, merdique de l'élu que vous venez d'appeler. C'est ça un callcenter : des gens très différents avec une lutte commune qui se retrouvent pour se marrer. Se marrer des guignols qui sont censés les représenter. On nomme ça : le lulz. Et ça permet de tenir contre tous et contre tout le bullshit qui sort de la bouche de nos élus. N'hésitez jamais à rejoindre un callcenter citoyen.


    * Prévoir un lieu dans lequel il y a un réseau WiFi de qualité voire, mieux, des accès à Internet filaires. C'est toujours mieux pour utiliser le PiPhone et pour faire des recherches. Lors d'un call-center, on a toujours besoin de faire des recherches... Un numéro de téléphone, une information sur le projet de loi auquel on s'oppose,... Une mauvaise connexion c'est du stress, un manque d'efficacité, de la colère,...


    * Le PiPhone de la Quadrature du Net, c'est génial, sauf que ça téléphone toujours dans le bureau de l'élu à l'Assemblée ou au Sénat. Il faut préférer chercher le numéro de la permanence en province et téléphoner à ce numéro là. Il y aura toujours un(e) assistant(e) parlementaire pour répondre, comme à Paris mais au moins, ça sent moins la campagne d'appel orchestrée par LQDN donc ça augmente votre crédibilité. C'est une vraie galère de trouver les numéros en province mais ça me semble plus efficace.


    * N'hésitez pas à contacter en priorité des élus avec qui vous vous êtes déjà entretenus, en bien comme en mal sur n'importe quel sujet (même si c'est pas du tout le même domaine entre le dernier appel et votre appel du jour). N'hésitez pas à mentionner le texte de loi qui faisait l'objet de votre dernier appel et votre position en quelques mots. Ça permet de créer un certain lien, de vous rappeler à la mémoire de l'assistant(e) parlementaire. Évidemment, si c'est votre premier callcenter, ce point ne s'applique pas immédiatement mais vous construisez les liens futurs. :)


    * Ne suivez aucun script. Ni ceux de la Quadrature, ni ceux que l'on peut trouver sur le web à l'occasion des campagnes d'appels ! Préparez-vous, avec vos propres mots, une fiche avec ce que vous voulez dire, le déroulé de la conversation, vos principaux arguments. Ça viendra de vous, ça sera plus gratifiant pour vous et plus crédible pour votre interlocuteur.

        Pire, avec du pré-maché, vous ne savez pas de quoi vous parlez. Un exemple concret : le script de la Quadrature que plusieurs personnes avaient lors de notre callcenter sur le projet de loi renseignement au Sénat parlait de l'article 851-3. Une des participantes s'est fait recaler par une assistante parlementaire : « il n'y a pas 851 articles dans ce projet de loi ». La participante enchaîne « ha ? ... bah ... peut-être un amendement alors mais l'important c'est que... ». Erreur sanctionnée immédiatement « il n'y a pas 851 amendements déposés à l'heure actuelle, madame ». À ce moment, vous êtes fini : quel que soit la qualité de votre argumentaire, votre interlocuteur ignorera vos propos. Ce n'est pas juste ni un comportement responsable mais c'est un fait. De votre côté, vous êtes déstabilisé, plus convaincu du tout du but de votre appel et ça s'entendra d'autant plus. En fait, le script parlait du futur article L851-3 que l'article 2 de la loi Renseignement ajoute au code de la sécurité intérieure. ;)

        Préparez vos appels : de quelle circonscription est l'élu à qui vous allez téléphoner ? Dans quelle ville est sa permanence ? A-t-il déjà pris des positions sur des projets de loi similaires dans le passé ? De quel parti politique est-il ? Quel métier (réel ou inventé) exercez-vous ? Où habitez-vous (réel ou inventé (attention aux petits villages dans lesquels tout le monde connaît tout le monde ;) )) ?

        Bref, préparez vos appels. Ça prend seulement quelques recherches sur le web. :)


    * N'ayez pas peur de participer ! Vous allez vous viander les premières fois, c'est une certitude ! Ça, c'est dit. Tout le monde s'est viandé. TOUT LE MONDE. L'important c'est d'apprendre de ses erreurs et de corriger les problèmes : qu'est-ce que vous avez mal fait ? Que faire pour corriger le tir ? Et par incréments successifs, vous vous améliorerez, c'est une évidence ! Ce paragraphe semble être du bullshit habituel mais je vous conjure qu'il n'en est rien et d'essayer. Personne n'est mauvais. Au contraire : vous aurez peut-être un angle d'attaque, une sympathie, que sais-je, différent qui convaincra votre interlocuteur/trice.

        J'ajoute que si vraiment vraiment vraiment vous ne voulez pas téléphoner ou que vous avez essayé mais que ce n'est vraiment pas votre truc, vous pouvez toujours participer. Il n'y a pas que les appels dans un callcenter mais l'humour, la joie de se regrouper (oui, même avec des inconnus), la logistique (organiser, accueillir les nouveaux arrivants, ramener des rafraîchissements, prendre des notes des élus contactés et de leur position, prendre des photos, rédiger un compte rendu du callcenter,...). Je suis sûr que vous pouvez apporter votre pierre à l'édifice. Personne n'est inutile ni mauvais en tout. Et c'est pas du "taff de merde dégradant", ho que non, c'est au contraire plus utile et important que les appels aux élus eux-mêmes !


    * Faites un suivi post-callcenter : l'élu a-t-il pris position au Parlement ? Son speech allait-il dans le bon sens ? Qu'a-t-il voté au final ? Est-ce conforme à ce qu'il vous avait annoncé au téléphone ? Dans tous les cas, n'hésitez pas à envoyer un petit mail argumenté, même pour dire uniquement des choses positives. Ça montre que vous êtes impliqué et que votre appel n'était pas qu'une affaire de campagne d'appels. C'est un travail pénible de longue haleine mais c'est ça qui permet à nos idées d'avancer.

Tout ça est derrière nous mais je me mets quand même ça de côté pour une sorte de mémoire politique.

Les sénateurs/sénatrices ont fait du cosmétique, pas du travail de fond :
     * Réintroduction des IMSI catcher (les fausses antennes de téléphonie mobile qui capturent appels, SMS et surf sur le net en mobilité) ;

    * Une pseudo évaluation de l'efficacité de la loi... Aucun rapport avec la choucroute : je peux faire une loi efficace et liberticide, c'pas contradictoire... De plus, si ça démontre une inefficacité, la conclusion sera oubliée, comme celle sur le crédit impôt recherche (http://shaarli.guiguishow.info/?PSBXUw), par exemple, un classique quoi. Même pas sûr que cette évaluation ait lieu, comme avec la LSQ (http://shaarli.guiguishow.info/?ztARDA)... ;

    * On joue sur les mots et sur les chiffres : nombre de personnes dans la CNCTR, on change intérêt majeur, menace imminente, on bidouille les finalités,... Tantôt en faveur des citoyens, tantôt en leur défaveur. Rien de bien constructif ;

    * Le seul truc positif c'est d'avoir resserré un peu la durée des écoutes administratives... Pas de bol : elles sont reconductibles ad vitam aeternam sans formalités (enfin pas plus que pour obtenir la première quoi).

    * Contrairement à ce qu'aiment dire les sénateurs : ils n'ont pas ajoutés de garde-fous supplémentaires, stop l'auto-congratulation ! Quand je les vois se prendre pour des sages qui étudient en profondeur les dossiers, posés en dehors du temps de la vie politique et de l'actualité (http://rue89.nouvelobs.com/2015/05/20/loi-renseignement-si-senat-sauvait-259286), ça me fait juste bien rigoler.

Par Benjamin Bayart. C'est dépassé puisque la loi est passée et les décrets signés mais ça reste intéressant.