FRnOG 39 - François Courvoisier : La cybersécurité des infrastructures réseau - haute coûture vs. haute performance

Vidéos des réunions FRnOG

28/04/2024

Catégorie

🤖

Technologie

Transcription

Afficher la transcription complète de la vidéo

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)

Recommandations