FRnOG 39 - François Courvoisier : La cybersécurité des infrastructures réseau - haute coûture vs. haute performance
Category
🤖
TechnologieTranscription
00:00 Bonjour à tous, aujourd'hui je vais vous parler un petit peu de...
00:05 - Rapproche-toi du micro. - D'accord.
00:08 Je vais vous parler un petit peu de ce qu'on fait chez Nanocorp
00:11 et principalement des drivers de cartes réseau.
00:14 Je m'appelle François Courvoisier, je suis le CTO et cofondateur de Nanocorp.
00:18 Nano, c'est une société française qui est dite un NDR,
00:21 donc qui est un Network Detection and Response,
00:24 c'est-à-dire un logiciel de détection des attaques sur un réseau.
00:27 Nous, notre revendication, c'est de fournir l'outil le plus universel,
00:31 léger et efficace du marché.
00:33 Et pour vous montrer comment on y arrive aujourd'hui,
00:36 je vais vous ouvrir le capot et faire un petit zoom sur nos différentes technologies.
00:40 Alors, si vous suivez un petit peu la cyber,
00:43 et notamment que vous êtes la cible de son marketing,
00:46 vous avez l'habitude des flashs, des paillettes,
00:50 qui vous donnent l'impression d'être un petit peu dans le domaine de la haute couture,
00:54 plutôt que le domaine de la haute performance.
00:57 Mais nous, chez Nano, on a un passé très militaire,
01:01 sur les cinq cofondateurs, on est quatre anciens du MINDEF,
01:05 donc on est plutôt haute performance qu'haute couture, très clairement,
01:09 bien que certaines personnes ont le petit doigt sur la couture chez nous.
01:13 Qu'est-ce que je veux dire par haute couture dans la cyber ?
01:18 La cyber, c'est un petit peu une fashionista.
01:21 Elle adore la mode, elle adore avoir de nouvelles fringues,
01:25 mais surtout, elle adore en changer.
01:27 Ce qui nous amène, tous les gens, à refaire le cyber bullshit bingo de la cyber défense,
01:33 à savoir CSSPB, WAF, SAS, CENAP,
01:38 et d'autres acronymes encore plus abscons les uns que les autres.
01:42 Et en fait, toute l'industrie repose en partie sur la capacité à inventer des nouvelles peurs,
01:47 des nouveaux problèmes, pour vous donner envie d'acheter leurs nouveaux produits.
01:53 Mais, au-delà de tout ça, il y a quand même certains fondamentaux
01:58 qui résistent aux différents effets du temps.
02:01 Il y a notamment, que fait la machine A, et qu'a-t-elle envoyé à la machine B ?
02:06 Que fait la machine A en cyber ? C'est couvert notamment par les EDR,
02:10 les Endpoint Detection and Response, c'est les agents actifs sur les machines.
02:16 Et la question numéro 2, qu'a-t-elle envoyé à la machine B ?
02:19 C'est du domaine des NDR, Network Detection and Response,
02:23 ce que nous faisons chez Nano.
02:25 Et les deux, l'un avec l'autre, c'est un peu votre combo jean-t-shirt.
02:29 Ça marche tout le temps, ça passe partout, c'est nickel, ça fait le taf,
02:32 et c'est encore mieux s'il a un petit suite Nano avec vous.
02:36 Aujourd'hui, je vais vous parler principalement haute performance,
02:41 parce que chez Nano, on fait un NDR, mais un peu différent des autres.
02:46 On a déjà un mindset Zero Trust, on a pour ambition d'analyser tous les paquets,
02:52 sans sampling, c'est-à-dire que si vous nous donnez une 100G,
02:55 on va analyser une 100G, on ne va pas analyser un dixième de la 100G par exemple.
02:59 On analyse également tout le paquet, on ne fait pas confiance aux données du paquet en amont,
03:05 donc on va analyser les couches de A7, on va faire de la détection protocolaire
03:08 sur les couches de A7, on ne va pas faire de stripping par exemple, ni de slicing,
03:14 et on supporte énormément de protocoles, au jour d'aujourd'hui un peu plus de 120.
03:18 On fait ça sur tout type de réseau, de 1G à 100G,
03:22 ce qui veut dire pour information, à 100G, c'est jusqu'à environ 150 millions de paquets par seconde,
03:28 donc ça fait 6 nanosecondes pour traiter un paquet.
03:31 Donc le temps est court, disons-nous.
03:34 En plus de ça, on traite les réseaux OT et IT, et on fait ça sur tout type d'environnement,
03:41 donc des environnements physiques sur des machines en community hardware,
03:45 donc des machines sur étagère, sans FPGA ou sans ASIC,
03:49 mais on travaille également sur les machines virtuelles.
03:52 Pour vous donner une petite anecdote, là on a un de nos clients qui nous a demandé
03:56 de faire une pellicase pour envoyer la sonde sur des plateformes pétrolières en hélicoptère.
04:02 Du coup on ne peut pas lui envoyer un serveur, très clairement, sinon il va nous crier dessus.
04:06 Et donc pour toutes ces raisons, on a besoin de très haute performance.
04:10 Et comment on atteint ces performances ? C'est là que ça devient très intéressant.
04:14 Déjà, numéro 1, tout est fait en Rust.
04:16 Ce n'est pas JB qui va me contredire, le Rust c'est quand même très efficace,
04:21 et c'est bien pratique pour se concentrer sur le métier et l'optimisation, plutôt que le debug.
04:26 Ça nous permet d'avoir une grande sérénité quant à la qualité du code,
04:30 et nous on gère toute la stack logicielle chez Nano de l'analyse du paquet et des alertes.
04:37 C'est-à-dire qu'on va gérer la réception des paquets, au travers de différentes technologies,
04:42 l'analyse des protocoles, la détection des protocoles, l'extraction des métadonnées, la mise en base,
04:47 jusqu'à la génération des alertes et les visualisations.
04:50 Il y a juste les visuels, elles sont faites en JS, tout de même,
04:54 mais on pourrait peut-être les faire en Rust, qui sait ?
04:56 En fait, toute cette maîtrise de haut en bas, plus l'utilisation du Rust,
05:01 ça nous permet d'optimiser vraiment au maximum nos différents briques logicielles.
05:08 Maintenant, je vais rentrer dans le cœur du sujet,
05:11 et pourquoi je suis là aujourd'hui, c'est pour vous parler des technologies de réception de paquets.
05:17 Comme je vous ai dit avant, on a besoin de très haute performance,
05:20 et la première étape c'est la réception des paquets.
05:23 On a différents technos qui existent.
05:26 On a en premier la stack TCP/IP de Linux, c'est très stable,
05:31 ça supporte énormément de cartes réseau, c'est génial,
05:34 par contre les perfs, bon, elles ne sont pas terribles.
05:36 On va recevoir, si on utilise du paquet Themmap par exemple,
05:39 de l'ordre d'un million de paquets par seconde, par cœur,
05:41 ce qui, quand on a 6 nanosecondes, correspond à 1000 nanosecondes d'utilisées pour recevoir un paquet.
05:47 Ça fait un peu trop.
05:49 On a une autre techno qui existe, qui est le DPDK,
05:54 alors là c'est la Rolls-Royce des frameworks réseau,
05:59 à la base c'était fait par Intel et ça a été repris par une fondation open source.
06:04 Ils ont d'excellentes perfs, c'est de l'ordre de 20 à 50 millions de paquets par seconde,
06:09 ils supportent quand même pas mal de cartes réseau,
06:13 mais par contre c'est très compliqué à utiliser avec du Rust,
06:18 et c'est quand même assez compliqué à déployer et à packager.
06:23 Et enfin, il y a une dernière techno qui s'appelle l'FXDP,
06:26 alors là c'est le petit nouveau, c'est intégré à ce nouveau framework sur Linux,
06:32 qui permet de bypasser le kernel en utilisant les technologies eBPF et XDP.
06:38 Donc ça permet de très bonnes perfs, d'avoir 10 millions de paquets par seconde,
06:42 mais par contre c'est encore jeune, on a eu beaucoup de bugs avec,
06:45 jusqu'à même avoir des paniques kernel.
06:49 Du coup, on s'est dit, bon ok, les techno existantes,
06:55 elles ont leurs avantages, leurs inconvénients, mais il n'y a rien qui nous satisfaisait.
07:00 Et puis, petite anecdote, à notre premier FIC,
07:03 on a rencontré une personne, un mec d'In-Q-Tel, donc je ne sais pas si vous connaissez In-Q-Tel,
07:07 c'est le fonds d'investissement de la CIA, qui est venu nous parler.
07:12 Il s'est présenté, et en fait c'était l'un des inventeurs de la DPI aux US.
07:18 Et pendant la conversation, au bout d'un moment, il nous avait dit
07:22 qu'on serait très certainement amené à vérifier la qualité des drivers des cartes réseau,
07:28 voire même de les réécrire si vraiment on voulait obtenir un niveau de confiance très élevé.
07:33 Bon, à l'époque, vous vous doutez bien, j'avais tranquillement rigolé.
07:37 Bon, maintenant, je me rends compte qu'il avait raison.
07:41 Et donc, on s'est lancé dans l'écriture d'un driver 100G.
07:45 Et pour ça, le driver, comme tout le reste chez nous, est écrit en Rust.
07:51 On vise environ 30 millions de paquets par seconde par cœur.
07:56 Ça bypasse entièrement le kernel, c'est en Userland.
07:59 On n'a aucun module kernel à écrire, donc ça a un gros avantage,
08:03 c'est que c'est très simple à déployer et ça s'intègre parfaitement à nos codebase,
08:07 ce qui nous permet de faire de nombreuses optimisations, par exemple,
08:10 de pouvoir gérer presque l'analyse d'un paquet quasiment en full zéro copie,
08:15 de la réception du paquet à l'envoi des métadonnées.
08:20 Je vais vous parler plus en détail de la carte 100G sur laquelle on a développé nos drivers actuellement,
08:26 qui est à savoir la Intel E810.
08:29 Donc la Intel E810, c'est une carte 100G low cost, qui est très massivement déployée.
08:34 Il y a une énorme documentation en plus qui est fournie par Intel, donc c'est très agréable.
08:39 Et pourquoi on l'a choisi en plus de tout ça ?
08:42 C'est qu'on avait de l'expérience sur les cartes X710.
08:45 On avait déjà développé un driver en ROS sur les cartes X710,
08:48 donc on s'est dit que ça allait être assez simple, quelques mois tout au plus.
08:52 Bon, nous étions un peu trop confiants.
08:55 Pour développer un driver, en gros, on a quelques outils à notre disposition,
09:03 à savoir déjà le premier, c'est la communication avec le bus PCI Express.
09:07 Il faut pouvoir communiquer avec la carte,
09:09 donc pour ça, nous, on utilise le module VFIO PCI de Linux.
09:14 Ça nous permet d'interagir avec les registres de la carte
09:18 et également de faire les allocations DMA pour tout ce qui est allocation mémoire partagée
09:24 entre la carte et le CPU.
09:27 Après, sur ces cartes-là, comme elles sont très avancées en termes de configuration,
09:31 il y a d'autres façons de les configurer.
09:33 Il y a également ce qu'Intel appelle les admin queues.
09:36 Ce sont des queues de configuration qui permettent de faire des configurations de la carte un peu plus avancées.
09:41 Et au-delà de tout ça, il y a le Dynamic Device Personalization Package de chez Intel,
09:47 qui sont en fait des gros binaires qu'on upload sur la carte
09:51 pour faire une reconfiguration quasiment complète de la carte.
09:56 Du coup, sachant tout ça, on s'est lancé dans le développement du driver.
10:01 En gros, développer un driver, en soi, ce n'est pas très compliqué dans la philosophie.
10:06 Il faut remettre à zéro la carte.
10:09 Ça, ça se fait via le registre.
10:11 Après, on attaque la configuration généralement monoqueue, en réception.
10:15 Là, ça demande, dans le cas de celle-ci, une configuration des admin queues.
10:20 Derrière, une fois qu'on a les admin queues pour configurer le reste de la carte,
10:23 il faut configurer son switch interne, parce que oui, ces cartes-là ont des switches internes.
10:27 Et après, il suffit d'activer une queue et normalement, ça fonctionne.
10:33 En fait, si vous voulez, ça fonctionne de telle manière que les packs arrivent sur le port,
10:38 on les relie à un port virtuel du switch interne,
10:41 et on relie les différentes queues à un autre port virtuel du switch interne de la carte.
10:45 On fait tout ça, on est très content, on a mis un mois à faire ça, ça marche nickel.
10:50 On est plutôt confiant, on se dit "Ok, le mois prochain, on a le multi-queue,
10:54 on a le balancing et on va être heureux".
10:57 Donc on se lance dans le multi-queue.
10:59 Là, c'est aussi assez simple, en plus la doc nous dit qu'il y a quelques étapes à faire.
11:04 On les fait, on a plusieurs queues d'activées, on est très content, on teste,
11:10 et là, patatra, on reçoit tout sur la queue numéro 0.
11:15 On se dit "Bon, on est bon pour se lancer dans le débuggage à proprement parler".
11:24 Donc on relie la doc, pour vous dire, une doc de cartes réseau, c'est environ 3000 pages sur ces cartes-là.
11:29 Donc on relie toute la doc, on se fait plaisir, on lit le DPDK, on lit les drivers Linux.
11:37 On pleure, très clairement, on s'aperçoit que la doc est à moitié fausse,
11:43 qu'elle oublie tout un pan de la configuration de la carte.
11:47 Au final, on fait appel à Intel.
11:50 On a eu la chance d'avoir des contacts chez Intel,
11:53 notamment les personnes qui travaillent sur le DPDK et sur les drivers Linux.
11:56 Donc on a fait appel à Intel Dublin, Pékin et San Francisco de mémoire.
12:02 Un gros merci à eux, parce qu'ils nous ont bien aidés, contrairement à leur documentation.
12:09 Et donc, comment on a réussi à résoudre tout ça ?
12:14 D'après la documentation, activer l'AuthBalancing,
12:19 c'est-à-dire activer le RSS, les algorithmes de base de l'AuthBalancing des cartes réseau,
12:23 qui permettent d'envoyer tous les paquets d'une même session sur une même queue,
12:27 normalement c'est assez simple.
12:29 Ça prend quelques centaines de lignes de code à tout casser.
12:33 Et là, la doc nous disait que c'était toujours simple.
12:36 Mais en fait, on s'est aperçu en relisant les drivers, notamment du DPDK,
12:40 que c'était beaucoup plus compliqué que ça.
12:42 Il a fallu reconfigurer la carte, charger un package DDP,
12:46 alors que normalement il n'y avait pas besoin d'après la doc,
12:48 le reconfigurer derrière.
12:50 Ça aussi c'était très marrant, on s'est dit, on a un package DDP fait par Intel,
12:53 complet, qui est censé supporter le RSS sur les protos dont on a besoin.
12:59 Eh bien, bien sûr, ça ne le fait pas.
13:01 Donc il a fallu qu'on reconfigure le DDP derrière,
13:04 et après qu'on reconfigure encore plein d'autres petites choses.
13:06 Donc on a fait beaucoup de magie noire,
13:08 beaucoup de valeurs sorties du chou à peau magique,
13:11 comme ça on les a reprises des drivers,
13:13 et c'est les valeurs que nous ont donné nos contacts chez Intel.
13:18 Bon, on a croisé les doigts, fait deux, trois sacrifices,
13:21 tête et gorge et un poulet par-ci, par-là.
13:23 Mais finalement, on a réussi, victoire,
13:26 on a réussi à faire nos drivers sans G,
13:29 avec le RSS qui fonctionne.
13:31 Mais on n'est pas au bout de nos peines,
13:34 parce que maintenant on a besoin d'améliorer un petit peu la précision,
13:38 et donc de revoir certaines valeurs magiques dont je vous ai parlé juste avant,
13:43 notamment le support du VLAN, ou ce genre de choses
13:46 qui n'est pas supporté de base par le DDP.
13:50 Maintenant qu'on a un driver sans G, et donc un NDR à sans G,
13:57 quel est un peu le programme suivant ?
13:59 Parce que là c'était le programme de la saison actuelle,
14:01 la saison 2023-2024.
14:03 Mais qu'est-ce qui nous attend en 2024-2025 ?
14:07 Comme je vous l'ai dit précédemment,
14:09 on a notre solution qui tourne sur les réseaux virtuels.
14:16 Actuellement, elle fonctionne déjà sur les réseaux virtualisés,
14:19 on utilise la technologie PacketMap de la StackLinux
14:24 pour recevoir les paquets, donc c'est supporté partout.
14:28 Par contre, les débits atteignables sont quand même assez limités,
14:31 et les pertes ne sont pas terribles, ce qui coûte,
14:34 on le sait, sur GCP ou AWS, assez cher.
14:38 Du coup, c'est pour ça qu'on va se lancer dans le développement
14:41 de drivers virtuels pour les cartes Intel X710 et X810.
14:45 Ça a l'avantage d'avoir des performances qui sont ISO quasiment
14:49 avec les performances des drivers physiques.
14:51 Ça nécessite quand même un support de la part de l'hyperviseur,
14:55 des supports qui existent sur quasiment tous les hyperviseurs actuels,
15:00 donc VMware, Proxmox et tout le reste.
15:02 Je ne connais pas d'hyperviseurs qui ne supportent pas
15:05 les drivers de fonctions virtuelles.
15:08 Et donc, on va se lancer là-dedans en 2024-2025
15:11 pour avoir encore une meilleure solution à vous offrir
15:15 pour les réseaux virtuels, et peut-être que je vous en parlerai
15:19 plus en détail l'année prochaine pour le FRNC 40.
15:22 Merci à tous.
15:24 (Applaudissements)