nemunaire/nemunai.re
1
0
Fork 0
Code Issues Pull requests 1 Releases Activity

Multilingual blog
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse source
This commit is contained in:
nemunaire 2023-05-14 12:19:04 +02:00
commit 9862b5aa22
19 changed files with 305 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

31
content/fr/about.md Normal file
View file

@ -0,0 +1,31 @@
---
title: "Pierre-Olivier `nemunaire`"
date: !!timestamp '2017-07-31T00:50:07+02:00'
update: !!timestamp '2021-07-24T00:00:00+01:00'
aliases:
- a-propos
---
{{<icon "fa fa-briefcase about-icon">}}
Aujourd'hui **entrepreneur** à la tête de différentes entreprises. J'ai travaillé avant comme **devops** pour [Novaquark](http://novaquark.com), avant d'être **ingénieur système/logiciel embarqué** chez [Qarnot computing](https://qarnot.com/), puis **responsable de la sécurité des systèmes d'information** and **architecte logiciel sénior** chez [Qarnot computing](https://qarnot.com/).
{{<icon "fa fa-graduation-cap about-icon">}}
Après 5 ans d'études à l'[Epita](http://epita.fr/), j'ai, en 2014, obtenu mon diplôme d'ingénieur ! J'ai suivi les enseignements de la majeure [***Systèmes, Réseaux et Sécurité***](https://srs.epita.fr/).
{{<br>}}
Durant mes études, j'étais *root* (responsable du parc informatique) du [laboratoire des assistants](https://assistants.epita.fr/) ainsi que du laboratoire *Systèmes, Réseaux et Sécurité*.
{{<icon "fa fa-terminal about-icon">}}
L'esprit toujours en ébulition, je travaille constamment sur de nombreux projets passionnants.
Je passe aussi beaucoup de temps à contribuer à des projets libres : généralement à améliorer le support, la documentation et faire la promotion des **ordinateurs à base de processeurs ARM**, et maintenant RISC-V.
{{<br>}}
Jetez un œil à mon [instance gitea](https://git.nemunai.re) ou à mon [compte GitHub](https://github.com/nemunaire).
{{<icon "far fa-thumbs-down about-icon">}}
Vous ne me trouverez pas sur les réseaux sociaux : je n'apprécie pas de gaspiller mon temps pour vendre ma vie privée gratuitement (d'ailleurs je lutte activement contre leur usage).
{{<icon "fa fa-heart about-icon">}}
Découvrir de nouvelles connaissances et techniques est quelque chose que j'apprécie particulièrement (surtout dans les domaines des sciences, de la typographie, des entreprises, de la faune et de la flore, ...).
Je recherche plus de libertés au sens large et d'indépendance.
{{<icon "fa fa-drum about-icon">}}
Sur mon temps libre, je joue de [la batterie](https://storage.nemunai.re/scores/_list.html) et [cuisine](https://food.p0m.fr/).

207
content/fr/post/post-mortem-cryptominer-on-CI-infrastructure.md Normal file
View file

@ -0,0 +1,207 @@
---
title: Post-mortem cryptominer on CI infrastructure
date: !!timestamp '2022-03-06 19:32:00'
tags:
- security
- cryptominer
- continuous integration
---
Après les [grandes plateformes de
cloud](https://stackoverflow.com/questions/63629722/gcp-has-suspended-my-machine-and-says-im-mining-cryptocurrency-how-do-i-fix-th),
puis [d'intégration
continue (CI)](https://therecord.media/github-investigating-crypto-mining-campaign-abusing-its-server-infrastructure/),
se plaignant des cryptomineurs, il semble que la course à leur
déploiement dans les petites installations de CI soit lancée.
Mon infrastructure a été la cible d'un hacker individuel hier, m'obligeant à
changer moi aussi quelques éléments de configuration pour m'adapter à ce
nouveau contexte.
<!-- more -->
# Une sacrée surprise pour démarrer un beau samedi
Dans ma quête de séparation des GAFAM et de contrôle de mes données
personnelles, j'héberge depuis de nombreuses années une forge qui
devient de plus en plus centrale pour mes projets.
Il y a quelques années, je lui ai notamment ajouté une plateforme
d'intégration continue : d'abord uniquement sur mon architecture de
prédilection : arm64, puis voyant tous les bienfaits de la CI, j'ai
ajouté une première machine amd64, pour les quelques déploiements que
j'avais besoin avec cette architecture. Ma principale utilisation est
la composition de documents avec `pandoc`, qui n'est pas disponible
sur d'autres architectures.
# Que s'est-il passé ?
Samedi matin, alors que je voulais lancer une tâche de composition de
document, via Drone, je constatais que la tâche ne se lançait
pas. Comme il s'agit d'un machine premier prix, elle a tendance à se mettre en défaut
facilement. Je me connecte donc dessus et constate qu'une tâche est en
cours, pourtant rien n'est affiché dans mon interface de DroneCI.
Je regarde directement les journaux du conteneur afin de déterminer de
quel projet il s'agit mais je ne le reconnais pas : il s'agit d'un
conteneur `ubuntu` (alors que la plupart de mes conteneurs utilisent
`alpine`), et la dernière commande ne log rien et utilise `tensorflow`.
Cela ne correspond vraiment à aucun des projets que j'héberge sur ma
forge.
Comme j'ai déjà été victime de bots de spam sur mon instance Gitea,
mon premier réflexe fut de consulter la liste des utilisateurs
nouvellement inscrits, pour voir s'il n'y avait pas quelqu'un que je
ne reconnaissais pas.
Sur la page listant les comptes utilisateurs, je constate la présence
d'un utilisateur fraîchement enregistré, j'apprends qu'il s'est
connecté via GitLab et qu'il s'est déjà créé un dépôt. En parcourant
son dépôt, je m'aperçois que c'est bien le dépôt qui est en cours
d'exécution.
# Ma première réaction
Maintenant que l'origine du problème était établie, j'ai commencé par
désactiver le compte de l'utilisateur puis j'ai stoppé brutalement son
conteneur, en utilisent `docker stop`.
Avant de désactiver le dépôt sur Drone, j'ai constaté que le pirate
avait mis en place une tâche `cron` chaque heure pour relancer sa tâche
de CI. Les tâches étant automatiquement arrêtées au bout de 60
minutes, il avait donc toujours une tâche en cours d'exécution sur
l'infrastructure.
# Mon analyse minutieuse de la situation
![Dyn repository](repository.png)
Une fois le calme revenu, vient l'analyse du code et du contexte. Le
code, qui est récupéré depuis un dépôt sur GitLab montre plusieurs
scripts shell obfusqués par un simple encodage base64. Une fois
décodé, on voit tout de suite que l'on a affaire à un cryptominer
basique. Il ne semble pas y avoir un groupe bien rodé derrière cette
intrusion, mais bien un individu qui explore les possibilités.
![Shell script](base64.png)
En remontant la piste jusqu'au portefeuille unique, on voit que les
sommes perçues sont de l'ordre de 25$ par semaine, et cela fait une
vingtaine de jours que notre protagoniste est actif.
Une rapide analyse des journaux a montré qu'il était arrivé sur mon
instance en recherchant précisément sur Google un fichier
`.drone.yml`. On le voit ensuite se connecter, via gitlab puis passer
l'étape de liaison à un éventuel compte existant protégée par un
captcha. Les temps entre chaque requête et les assets téléchargés
laissent supposer qu'il s'agit bien d'un humain et que l'on a donc pas
(encore) affaire à un script automatique.
Voici le cheminement exact :
1. arrivée sur git.nemunai.re depuis Google, sur un fichier `.drone.yml` ;
1. connexion via GitLab, via le lien OAuth2 disponible ;
1. création puis activation de son compte sur git.nemunai.re ;
1. recherche d'un dépôt sur la page d'accueil (mais apparemment j'en ai trop) ;
1. nouvelle arrivée depuis Google, sur un autre fichier `.drone.yml`, a priori le suivant dans la liste ;
1. passage sur la partie publique de DroneCI ;
1. connexion à Drone → création de l'utilisateur ;
1. retour sur Gitea pour créer le dépôt (il choisit la migration depuis GitLab) ;
1. synchronisation des dépôts sur Drone ;
1. activation de son dépôt ;
1. déclenchement manuel d'une synchronisation du dépôt afin de récupérer un nouveau commit, ce qui lance sa première tâche dans Drone ;
1. ajout de la tâche `cron` dans Drone pour relancer sa tâche chaque heure.
Tout cela s'est déroulé dans un intervalle de 6 minutes, ce n'était
donc pas un robot, mais bien un humain qui savait ce qu'il faisait.
---
Mon instance Gitea est reliée à un système de statistique de
fréquentation (Umami, qui me permet de ne pas avoir de bandeau
RGPD). Dessus, on voit effectivement la connexion depuis GitLab.com et
l'accès au dépôt déclencheur, malgré le fait que l'utilisateur et le
dépôt soient privés. D'après Umami, notre visiteur serait
[indonésien](https://ipinfo.io/AS7713). Une rapide recherche sur le nom du compte GitLab qui a
effectué la connexion montre également un profil LinkedIn indonésien
d'un Deep Learning Specialist, ayant fait ses premiers pas sur GitLab
il y a environ 2 semaines... Cependant le dépôt du crytominer n'est
pas hébergé par son compte. On peut donc se demander s'il s'agit de la
même personne ou si son compte GitLab a été compromis.
Dans le doute, j'ai fait un rapport d'abus sur GitLab pour cet utilisateur.
![Abuse filled to GitLab](abuse.png)
Je n'ai pas été contacté par GitLab suite à ce rapport, et je ne
pensais d'ailleurs pas qu'il serait traité le jour même, considérant
que d'une part il ne s'agit pas d'un problème critique comme de la
pédo-pornographie ou similaire, et que, d'autre part, cela nécessitait
sans doute de faire valider mon analyse par un ingénieur qualifié.
Toujours est-il que les deux comptes ont été bloqués dans les deux heures.
# Remédiation
Estimant que j'avais une suffisamment bonne vision sur la situation et son
contexte, je me suis enfin attelé à trouver les solutions pour remédier aux
différents problèmes.
Tout d'abord mon instance Gitea a pour vocation d'être accessible à tous, afin
que n'importe qui puisse facilement contribuer, notamment en faisant des
rapports de bug ou des pull-requests sur mes projets.
Considérant le faible taux de création de fork, face aux problèmes que
cela peut engendrer -- notamment via la création de pull-requests
indésirables qui, en remplaçant la logique du `.drone.yml`, pourrait
permettre de lancer un cryptominer jusqu'à l'expiration du délais
d'exécution de la tâche -- j'ai donc décidé de changer le nombre maximal
de dépôt que peut créer un nouvel utilisateur de 1 à 0. J'attendrai
désormais qu'un utilisateur me sollicite afin de lui augmenter sa
limite individuelle.
Concernant Drone, j'ai cherché une option permettant de limiter les
utilisateurs autorisés à en faire usage.
Il se trouve qu'il y a justement une option :
[`DRONE_USER_FILTER`](https://docs.drone.io/server/reference/drone-user-filter/)
qui permet de lister les groupes d'utilisateurs et/on les utilisateurs
individuels qui sont autorisés à se connecter.
Cette option répond exactement à mon besoin, je l'ai donc ajoutée aux options de
déploiement de mon instance de DroneCI.
Pour être exhaustif, c'est également à ce moment que j'ai désactivé le
dépôt du cryptominer et supprimé l'utilisateur malveillant de Drone,
car il aurait encore pu s'y connecter.
# Conclusion
J'ai été très agréablement surpris de la réactivité des équipes de
GitLab : pour avoir désactivé les comptes contrevenants, malgré le
fait que cela ne concernenait pas directement un abus des conditions
d'utilisation de leur plateforme.
Je ne sais pas s'ils sont allés jusqu'à contacter tous les comptes
pour lesquels l'utilisateur malveillant a fait usage de leur lien
OAuth 2. D'autres infrastructures sont, en effet, toujours utilisées
par ce hacker d'après les activités de son porte-feuille.
Une chose est sûre, plus que jamais, il faut bien faire attention aux
options que l'on choisit lorsque l'on souhaite exposer un service au
public, car on ne s'attend pas toujours à ce qui peut se passer. Et
bien que cet utilisateur ait été bloqué, rien ne l'empêche de
continuer de chercher de nouvelles forges à exploiter.
En complément, citons ce récent rapport [publié par le NCC
Group](https://research.nccgroup.com/2022/01/13/10-real-world-stories-of-how-weve-compromised-ci-cd-pipelines/)
à propos des principaux vecteurs de compromissions des environnements
d'intégration continue.
![Blocked users](blocked-users.png)

70
content/fr/post/use-additional-ipv6-blocks-from-isp.md Normal file
View file

@ -0,0 +1,70 @@
---
title: Utiliser les plages IPv6 supplémentaires du réseau Free et Orange
date: !!timestamp '2023-04-05 14:43:00'
tags:
- network
- ipv6
- freebox
---
Chez Free et Orange, lorsque l'on n'a pas désactivé l'IPv6 les Freebox (et certaines Livebox) mettent à disposition des équipements connectés une plage d'IPv6 /64.
Mais il se trouve en fait que c'est une plage /60 qui est mise à disposition et utilisable par chaque abonné.
Cela représente en tout 8 réseaux /64 adressables.
Voyons à quoi cela peut-il bien servir et comment les utiliser.
<!-- more -->
# Rappels IPv6
Contrairement à l'IPv4, avec des IPv6 on évite de faire du NAT, c'est-à-dire que l'on attribue à chaque machine sur le réseau une adresse IPv6 directement routable sur Internet.
Bien entendu il est toujours nécessaire de passer par le routeur (la box) qui sert alors de simple passerelle vers Internet.
En IPv6, les équipements sont capables de choisir eux-même leur IP, sans l'aide du protocole DHCP.
Cela est possible car le routeur émet régulièrement les informations du sous-réseau dans lequel on se trouve (il s'agit du [Router Advertisement (RA)](https://en.wikipedia.org/wiki/Router_advertisement)).
Pour notre expérience, prenons le lab suivant :
![L´infrastructure de base qui va nous servir à faire nos expérimentations](lab.png)
Nous avons tous nos équipements reliés à la box et une série de machines virtuelles hébergées sur l'une des machines du réseau.
À ce stade, si l'on veut que nos machines virtuelles soient joignables depuis Internet en IPv6, on est obligé de configurer le réseau de l'hyperviseur en mode *bridge*.\
En effet si le réseau de nos machines virtuelles est distinct du réseau de la box, celle-ci ne sera pas en mesure de communiquer avec nos machines virtuelles. En utilisant le mode *bridge*, on simule le fait que la machine virtuelle est directement reliée à la box, ou à un switch. En tous cas aucun équipement nécessitant de faire du routage.
Si nos machines virtuelles sont uniquement des clients IPv6 et n'ont pas vocation à servir directement du contenu sur Internet, cette solution est tout-à-fait acceptable. Mais si on veut servir du contenu, on pourrait vouloir segmenter notre réseau pour tenter d'isoler les équipements.
# Segmenter le réseau de la box
Du fait du très grand nombre d'adresses IPv6 publiques que nos opérateurs nous fournissent, on pourrait commencer par vouloir segmenter notre réseau entre nos serveurs virtuels et nos autres équipements : chacun serait dans un sous-réseau séparé.
L'intérêt principal de cette segmentation serait d'éviter que tout ce petit monde partage le même sous-réseau : comme ils peuvent tous communiquer directement entre-eux, il est plus compliqué de filtrer efficacement les échanges malveillant. Par exemple si l'une des machines virtuelles exposée sur Internet est compromise, elle peut accéder à tous nos équipements locaux (téléphones, objects connectés, ...) qui ne sont pas forcément sécurisés, ou inversement, un objet du réseau peut se mettre à intercepter tout le trafic des machines virtuelles en se faisant passer pour la box.
On pourrait donc vouloir segmenter son réseau comme cela :
![Exemple de segmentation par le partage du bloc /64 en deux blocs /65](lab-segmente.png)
On réserverait la moitié du bloc /64 aux équipements réels du réseau et on attribuerait l'autre moitié à nos machines virtuelles situées sur un serveur/Raspberry Pi.
Malgré le très grand nombre d'adresses IPv6 que l'on peut attribuer, il n'est pas évident de subdiviser notre /64 pour l'attribuer à un routeur secondaire ou un serveur de machines virtuelles. Cette segmentation n'est en effet pas possible sans changer la configuration de la box car celle-ci s'attend à pouvoir joindre nos machines virtuelles directement, sans passer par une machine/hôte/routeur intermédiaire.
Cependant nous avons accès aux paramètres de routage des 7 autres blocs /64 distribués par l'opérateur. Nous pouvons par exemple en attribuer un à l'hôte de nos machines virtuelles.
# Déléguer un préfixe IPv6 supplémentaire
Comme on le disait en introduction, certains opérateurs mettent à disposition de leur abonnés une plage d'adresses IPv6 bien plus grande que le bloc /64 du réseau principal.
Certaines box permettent en outre de tirer parti des blocs complémentaires en proposant de déléguer les autres blocs à des machines du réseau.
Concrètement, cela signifie que lorsque la box recevra un paquet à destination d'un des blocs délégués, elle ne le traitera pas elle-même, elle le transmettra à la machine désignée comme destinataire. En d'autres termes, elle routera le trafic de ce bloc vers le routeur désigné. Et ce n'est pas forcément compliqué !
# Différents cas d'usage
Maintenant que l'on a vu la théorie, voyons justement différents cas d'usage, pour ne pas nous limiter à nos machines virtuelles :
- Utiliser un bloc /64 pour donner de l'IPv6 à ses machines virtuelles
- [Utiliser un bloc /64 pour donner de l'IPv6 à ses conteneurs Docker]({{< relref "use-ipv6-in-docker.md" >}})
- Utiliser un bloc /64 pour avoir de l'IPv6 dans plusieurs sous-réseaux isolés
- Utiliser un bloc /64 pour avoir de l'IPv6 publique dans son tunnel Wireguard

138
content/fr/post/use-ipv6-in-docker.md Normal file
View file

@ -0,0 +1,138 @@
---
title: Donner une connectivité IPv6 à ses conteneurs Docker en utilisant un bloc d'IPv6 de son opérateur
date: !!timestamp '2023-05-04 15:10:00'
tags:
- network
- ipv6
- docker
---
Il peut paraître étonnant qu'un service moderne comme Docker n'offre pas d'IPv6 dans les conteneurs par défaut, en particulier lorsqu'on se trouve dans un réseau avec de l'IPv6.
En fait, pour la même raison que nous avons vu dans [l'article introductif]({{< relref "use-additional-ipv6-blocks-from-isp.md" >}}), étant donné que les conteneurs se trouvent dans un réseau virtuel, ils ne peuvent pas être joignables par la box/le routeur distribuant le sous-réseau IPv6.
<!-- more -->
On observe d'ailleurs le même phénomène avec l'IPv4 : chaque conteneur dispose d'une IPv4 dans un sous-réseau distinct de celui dans lequel se trouve notre machine hôte.
![Illustration d´un réseau domestique IPv4 classique](common-network-with-docker.png)
Pour que les conteneurs aient accès à Internet dans ces conditions, en IPv4 du NAT est mis en œuvre :
```
42sh$ iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 3 packets, 228 bytes)
pkts bytes target prot opt in out source destination
14713 978K MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0
```
Comme on ne fait généralement pas de NAT sur les IPv6, rien de similaire n'est fait par Docker dans ce sens.
# Docker comme routeur IPv6
Sans IPv6 dans un conteneur, il est impossible pour les conteneurs de s'adresser à d'autres services écoutant exclusivement en IPv6 sur Internet.
Afin que les programmes conteneurisés puissent se connecter à d'autres services en IPv6, il convient d'activer l'option *Enable IPv6* et de définir le préfixe à utiliser au travers de l'option *IPv6 Prefix*.
Attention, ce n'est pas tout de définir ces options, il faut aussi que la box route correctement les paquets à destinations des conteneurs vers votre machine.
C'est pour cela que nous avons besoin de tirer parti des autres blocs d'IPv6 fournis par notre opérateur. En indiquant à la box l'adresse de notre machine hébergeant nos conteneurs, elle y routera tous les paquets à destination des conteneurs sans poser de question.
Tout ne peut donc pas se faire exclusivement sur la machine, le réseau doit aussi être configuré. Commençons d'ailleurs par cela.
# Paramétrer la délégation de préfixe IPv6 sur la Freebox
La box va nous demander l'adresse (IPv6) vers laquelle elle devra router les paquets. On indique généralement une [IP de lien local](https://en.wikipedia.org/wiki/Link-local_address).
On commence donc par regarder quelle est notre IPv6 locale sur le lien sortant vers la box.
⚠️ Attention toutes les interfaces ont une adresse locale, elles commencent toutes par `fe80:`, elles ne sont valables que sur la carte réseau considérée. Si vous récupérez la mauvaise adresse, il ne se passera rien (cela ne cassera pas votre réseau pour autant).
Dans mon cas, c'est l'interface `eth0` qui est connectée à la box :
```
42sh$ ip address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether fd:54:01:98:cd:ba brd ff:ff:ff:ff:ff:ff
inet 192.168.0.42/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
valid_lft 35141sec preferred_lft 35141sec
inet6 2a01:...:2420:24ac:f101:c280:50c2/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::5a43:3580:173c:395e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
```
Mon IP locale est donc `fe80::5a43:3580:173c:395e`.
C'est cette IP que je vais indiquer dans la configuration de la box.
Sur les Freebox, la fenêtre de paramétrage des préfixes supplémentaires se trouve dans « Paramètres de la Freebox », « Configuration IPv6 », sous l'onglet « Général ». C'est le cadre « Délégation de préfixe » qui va nous intéresser.
Cela ressemble à ça :
![Fenêtre de paramétrage de la délégation de préfixe IPv6 de la Freebox](freebox-ipv6-prefix-delegation.png)
Laissez toujours le 1ᵉʳ champ vide, sans quoi la box ne vous proposera plus d'IPv6 sur le réseau principal.
Indiquez dans le 1ᵉʳ champ vide suivant (le deuxième a priori donc !) l'adresse locale récupérée plus tôt.
C'est tout ! Le plus dur est passé. Voyons maintenant la configuration de Docker.
# Paramétrer Docker pour l'IPv6
Nous n'allons pas utiliser la plage à laquelle notre machine est connectée. Nous allons utiliser toute une plage /64, celle pour laquelle on a donné l'IP locale de notre machine à la box.
![Notre délégation de préfixe correctement paramétrée sur la Freebox](freebox-ipv6-delegation-filled.png)
Selon la capture d'écran précédente, notre fichier de configuration `/etc/docker/daemon.json` devrait ressembler à :
```
{
"ipv6": true,
"fixed-cidr-v6": "2a01:1234:abcd:2421::/64"
}
```
On relance Docker et on peut tester :
```
42sh$ docker run -it alpine
/ # ip address show eth0
58: eth0@if59: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:09 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.9/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a01:1234:abcd:2421:0:242:ac11:9/64 scope global flags 02
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe11:9/64 scope link
valid_lft forever preferred_lft forever
```
Si vous avez une IPv6 en plus de l'IPv4 habituelle, c'est que Docker est correctement configuré. Pour savoir si la configuration côté box a réussi, lançons un `ping` dans le conteneur :
```
/ # ping ping6.online.net
PING ping6.online.net (2001:bc8:1::40): 56 data bytes
64 bytes from 2001:bc8:1::40: seq=0 ttl=52 time=11.008 ms
64 bytes from 2001:bc8:1::40: seq=1 ttl=52 time=8.822 ms
^C
--- ping6.online.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 8.822/9.915/11.008 ms
```
Si le ping répond, c'est tout bon : vos conteneurs auront désormais accès à et seront accessibles en IPv6.
# Autres cas d'usage
Ce billet fait partie d'une série de billets sur l'usage des plages d'IPv6 supplémentaires :
- [Introduction : Utiliser les plages IPv6 supplémentaires du réseau Free et Orange]({{< relref "use-additional-ipv6-blocks-from-isp.md" >}})
- Utiliser un bloc /64 pour donner de l'IPv6 à ses machines virtuelles
- Utiliser un bloc /64 pour donner de l'IPv6 à ses conteneurs Docker
- Utiliser un bloc /64 pour avoir de l'IPv6 dans plusieurs sous-réseaux isolés
- Utiliser un bloc /64 pour avoir de l'IPv6 publique dans son tunnel Wireguard

22
content/fr/talks.md Normal file
View file

@ -0,0 +1,22 @@
---
title: "Talks"
date: !!timestamp '2017-07-31T00:07:37+02:00'
aliases:
- conferences
---
Voici les supports des conférences que j'ai données :
* [[FR] L'authentification forte](2fa.pdf)
* [[FR] L'autohébergement](autohebergement.pdf)
* [[FR] Le DNS](QTechNote%20DNS.pdf)
* [[FR] Prise en main de Docker](QTechNote%20Docker.pdf)
* [[FR] Prise en main de gRPC/Protobuf](QTechNote%20%231.pdf)
## Enseignement
À l'[Epita](http://www.epita.fr/), j'enseigne l'usage des conteneurs et leur fonctionnement technique au sein du noyau Linux dans un cours de 24 heures nommé [*Virtualisation légère*](https://virli.nemunai.re/) ainsi que l'[*ADministration LINux avancée*](https://adlin.nemunai.re).
D'autre part, j'encadre le projet de fin d'études des étudiants de la majeure SRS pour lequel ils conçoivent un [challenge de forensic](https://fic.srs.epita.fr/) pour l'[European Cyber Cup](https://european-cybercup.com), présenté au [Forum International de la Cybersécurité](https://www.forum-fic.com/).
À ce titre, je maintiens et coordonne les développements de [la plateforme de validation](https://git.nemunai.re/fic/server).