Pour réaliser notre devoir de bon consultant, nous sommes bien souvent en train de puiser via notre moteur de recherche préféré les bons liens pour rechercher les bonnes informations. Je vous propose un certains nombre de liens officiels, qui je suis sur, vous aiderons à votre quête d’informations.
Un petit article court pour expliquer aux amateurs de sécurité en herbe (perdus sur le plateau des Millevaches) comment installer le module modsecurity NGINX, par défaut dans la version payante NGINX+
La mise en conteneur d’environnement est classique de nos jours et est indiscutablement nécessaire.
Certains, se sont maintes fois heurtés à un mur sous formes d’insultes systèmes en installant le service de temps sous Linux; et notamment sous CentOS/RedHat.
VyOS est un système d’exploitation de routeur et firewall opensource. Vous trouverez leur site ici. On le retrouve dans les clouds AWS, Azure… et bien évidemment sur KVM. Très pratique, avec OpenVSwitch, il fait partie des petits blocs d’infra qui vous font économiser beaucoup d’heures de recherche et d’argent… Il s’interconnecte avec par exemple une “Azure VNet Gateway”, Wireguard, GRE, BGP over IKEv2/IPsec. L’OS consomme moins de 512M de RAM et prend quelques centaines de Mo de place en stockage.
Installation de l’OS
On va chercher la bonne image sur la bonne page du site de l’éditeur. Je suis sympa, je vous mets l’url. Dans mon infra de test KVM/libvirt, j’ai un switch virtuel (OpenVSwitch) sur une IP WAN (ext-br-network) et un réseau isolé (internal). On va créer une nouvelle VM dans libvirt :
virt-install -n vyos_r1 \
--ram 4096 \
--vcpus 2 \
--cdrom /var/lib/libvirt/images/vyos-1.3-rolling-202012041912-amd64.iso \
--os-type linux \
--os-variant debian10 \
--network network=ext-br-network,model=virtio \ # c'est un réseau sur mon OpenVSwitch sur le WAN
--network network=internal,model=virtio \ # c'est un réseau isolé
--graphics vnc,port=5999 \
--hvm \
--virt-type kvm \
--disk path=/var/lib/libvirt/images/vyos_r1.qcow2,bus=virtio,size=8 \
--noautoconsole
On entre dans l’OS, on change les locales et on installe l’OS (ou pas, dans ce cas il est chargé en ram et il faut créer une image avec les scripts de configuration)
configure
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth1 address '192.168.200.254/24'
set service ssh port '22' # à partir de là le routeur est accessible en ssh, donc la conf peut-être terminée via SSH, Ansible
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '192.168.200.0/24'
set nat source rule 100 translation address masquerade
commit
save
exit
show interface
ping 8.8.8.8 interface 192.168.1.80 (en fonction)
ping 8.8.8.8 interface 192.168.200.254
Configuration du DHCP si besoin
set service dhcp-server disabled 'false' # version <~ 1.1.8
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 default-router '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 dns-server '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 domain-name 'internal.domain.tld'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 start '192.168.200.10' stop '192.168.200.253' # version <~ 1.1.8
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 start '192.168.200.9'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 stop '192.168.200.253'
On configure le DNS forwarding
set service dns forwarding cache-size '0'
#set service dns forwarding listen-on 'eth1' # version <~ 1.1.8
set service dns forwarding listen-address '192.168.200.254'
set service dns forwarding allow-from '192.168.200.0/24'
set service dns forwarding name-server '8.8.8.8'
set service dns forwarding name-server '8.8.4.4'
Voilà, à ce niveau le routeur est fonctionnel !
Mise en place des firewalls
set firewall name OUTSIDE-IN default-action 'drop'
set firewall name OUTSIDE-IN rule 10 action 'accept'
set firewall name OUTSIDE-IN rule 10 state established 'enable'
set firewall name OUTSIDE-IN rule 10 state related 'enable'
set firewall name OUTSIDE-LOCAL default-action 'drop'
set firewall name OUTSIDE-LOCAL rule 10 action 'accept'
set firewall name OUTSIDE-LOCAL rule 10 state established 'enable'
set firewall name OUTSIDE-LOCAL rule 10 state related 'enable'
set firewall name OUTSIDE-LOCAL rule 20 action 'accept'
set firewall name OUTSIDE-LOCAL rule 20 icmp type-name 'echo-request'
set firewall name OUTSIDE-LOCAL rule 20 protocol 'icmp'
set firewall name OUTSIDE-LOCAL rule 20 state new 'enable'
set firewall name OUTSIDE-LOCAL rule 30 action 'drop'
set firewall name OUTSIDE-LOCAL rule 30 destination port '22'
set firewall name OUTSIDE-LOCAL rule 30 protocol 'tcp'
set firewall name OUTSIDE-LOCAL rule 30 recent count '4'
set firewall name OUTSIDE-LOCAL rule 30 recent time '60'
set firewall name OUTSIDE-LOCAL rule 30 state new 'enable'
set firewall name OUTSIDE-LOCAL rule 31 action 'accept'
set firewall name OUTSIDE-LOCAL rule 31 destination port '22'
set firewall name OUTSIDE-LOCAL rule 31 protocol 'tcp'
set firewall name OUTSIDE-LOCAL rule 31 state new 'enable'
et on applique la configuration à la carte réseau :
set interfaces ethernet eth0 firewall in name 'OUTSIDE-IN'
set interfaces ethernet eth0 firewall local name 'OUTSIDE-LOCAL'
Automatisation
On peut exécuter un script pour automatiser la configuration, il doit être appelé par le groupe vyattacfg avec la commande switch group sg, ce qui donne :
sg vyattacfg -c ./conf-network.sh
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth1 address '192.168.200.254/24'
set service ssh port '22'
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '192.168.200.0/24'
set nat source rule 100 translation address masquerade
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 default-router '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 dns-server '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 domain-name 'internal.domain.tld'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 start '192.168.200.9'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 stop '192.168.200.253'
set service dns forwarding cache-size '0'
set service dns forwarding listen-address '192.168.200.254'
set service dns forwarding allow-from '192.168.200.0/24'
set service dns forwarding name-server '8.8.8.8'
commit
save
exit
Autre solution “maison”, un vieux script des familles qui permet de tout faire depuis l’hyperviseur :
#!/bin/bash
name="vyos_r1"
user="vyos"
password="vyos"
dns_ip="192.168.1.34"
function main() {
launch
sleep 40
install
sleep 10
config
}
function launch() {
sudo virt-install -n $name \
--ram 4096 \
--vcpus 2 \
--cdrom /var/lib/libvirt/images/vyos-1.3-rolling-202012041912-amd64.iso \
--os-type linux \
--os-variant debian10 \
--network network=ext-br-network,model=virtio \
--network network=internal,model=virtio \
--graphics vnc,port=5999 \
--hvm \
--virt-type kvm \
--disk path=/var/lib/libvirt/images/$name.qcow2,bus=virtio,size=8 \
--noautoconsole
}
function install() {
sudo expect <<EOF
set timeout 600
spawn virsh console $name
expect "Escape character is ^] (Ctrl + ])" {send "\n"}
expect "vyos login:" {send "$user\r"}
expect "Password:" {send "$password\r"}
expect "vyos:~" {send "install image\r"} expect "Would you like to continue? (Yes/No): " {send "Yes\n"}
expect "Partition (Auto/Parted/Skip):" {send "Auto\n"} expect "Install the image on?:" {send "\n"}
expect "Continue? (Yes/No):" {send "Yes\n"} expect "How big of a root partition should I create? (2000MB - 8589MB):" {send "8589MB\n"}
expect "What would you like to name this image?:" {send "\n"} expect "Which one should I copy to vda?:" {send "\n"}
expect "Enter password for user 'vyos':" {send "$password\n"}
expect "Retype password for user 'vyos':" {send "$password\n"}
expect "Which drive should GRUB modify the boot partition on?:" {send "\n"} expect "vyos:~" {send "sudo reboot\r"}
expect "Are you sure you want to reboot this system?" {send "Yes\r"}
EOF
}
function config() {
sudo virsh start $name
sleep 50
sudo expect <<EOF
set timeout 600
spawn virsh console $name
expect "Escape character is ^] (Ctrl + ])" {send "\n"}
expect "vyos login:" {send "$user\r"}
expect "Password:" {send "$password\r"}
send "sudo loadkeys fr\r"
send "configure\r"
send "set interfaces ethernet eth0 address dhcp\r"
send "set interfaces ethernet eth1 address '192.168.200.254/24'\r"
send "set service ssh port '22'\r"
send "set nat source rule 100 outbound-interface 'eth0'\r"
send "set nat source rule 100 source address '192.168.200.0/24'\r"
send "set nat source rule 100 translation address masquerade\r"
send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 default-router '192.168.200.254'\r"
send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 dns-server '192.168.200.254'\r"
send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 domain-name 'internal.domain.tld'\r"
send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 lease '86400'\r"
send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 start '192.168.200.9'\r"
send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 stop '192.168.200.253'\r"
send "set service dns forwarding cache-size '0'\r"
send "set service dns forwarding listen-address '192.168.200.254'\r"
send "set service dns forwarding allow-from '192.168.200.0/24'\r"
send "set service dns forwarding name-server '$dns_ip'\r"
send "commit\r"
send "save\r"
send "exit\r"
EOF
}
main
exit 0
Et voilà, un routeur fonctionnel avec un seul script… Pensez à modifier ce script pour durcir la sécurité d’accès au routeur en changeant le second mot de passe et en modifiant la config ssh pour accepter les clés. Je mets le lien vers les blueprints de VyOS (notamment dans des environnements Cloud) :
Lors du dernier web-séminaire de RedHat, nous avons la confirmation du détail du cycle de vie des versions antérieures et actuelles de Linux RedHat. En résumé, et nous le savions déjà, la fin de support des versions antérieures à 8.0 depuis aout.
Version
General availability
Full support ends
Maintenance Support 1 ends
Maintenance Support 2 ends
9
A venir
A venir
8
07/05/2019
8.0 (se termine le 31/12/2021) 8.1 (se termine le 30 novembre 2021) 8.2 (se termine le 30 avril 2022) 8,4 (se termine le 30 mai 2023)
N/A
8.0 (se termine le 31/12/2021) 8.1 (se termine le 30 novembre 2021) 8.2 (se termine le 30 avril 2022) 8,4 (se termine le 30 mai 2023)
RedHat nous confirme les fins de supports niveau 2 pour ces mêmes versions pour mai 2021 concernant les architectures non Intel/AMD; et enfin juin 2024 pour Intel/ADM.
RedHat vend évidemment sa solution Ansible pour pouvoir effectuer les migrations rapidement des systèmes anciens ou en utilisant son outil facilitant cette dernière: LEAPP. LEAPP est bien prêt pour passer en version 8.0 les anciennes versions de RedHat EL.
Concernant le cursus de certification RedHat 8.0, il reste inchangé…
L’accès au support technique dépend du niveau de service inclus dans votre abonnement Red Hat Enterprise Linux.
Red Hat peut choisir, à titre de mesure temporaire, de résoudre ces problèmes catastrophiques ayant un impact significatif sur l’activité des clients avec un correctif pendant la création de l’avis d’errata de correction de bogues (RHBA).
L’activation matérielle native est fournie par le rétroportage des pilotes matériels, etc., vers la version appropriée de Red Hat Enterprise Linux. L’activation matérielle à l’aide de la virtualisation est obtenue en exécutant une version antérieure de Red Hat Enterprise Linux en tant qu’invité virtuel sur une version plus récente de Red Hat Enterprise Linux. Consultez la description de la virtualisation ci-dessous pour plus de détails. REMARQUE : la certification matérielle (y compris les limites matérielles associées) s’applique à la version de Red Hat Enterprise Linux utilisée comme hôte.
L’activation matérielle native dans la phase 1 du support de maintenance est limitée à l’activation matérielle qui ne nécessite pas de modifications logicielles substantielles. Consultez la description du support de maintenance 1 ci-dessous pour plus de détails.
Les améliorations logicielles sont des ajouts de nouvelles fonctionnalités au-delà de la correction de défauts ou de l’activation de fonctionnalités existantes sur une nouvelle génération de matériel.
Les versions majeures sont le principal vecteur d’améliorations logicielles importantes, bien que des améliorations logicielles à faible impact puissent également être fournies dans les versions mineures.
La prise en charge étendue des mises à jour (EUS) et la prise en charge du cycle de vie étendu (ELS) sont disponibles en tant que modules complémentaires facultatifs. Voir les descriptions EUS et ELS ci-dessous.
Pour les installations existantes uniquement. Voir les détails ci-dessous pour d’autres limitations.
Pour le fun, je mets le graph Terraform que l’on obtient avec la commande `terraform graph | dot -Tpng > graph.png` (la sortie peut également être en .svg) :
Comme vous l’avez compris, il y a maintenant cinq modules :
2 Mariadb Master / Slave servers,
2 Redis Master / Slave servers,
2 vms in GlusterFS Cluster,
Haproxy load-balancer,
2 Nextcloud serveurs avec Nginx ou Apache et php-fpm.
Avec cette version du code j’ai forcé l’installation de nginx : j’avais mis précédemment apache par défaut. C’est configurable via les variables d’Ansible. La base de donnée est répliquée sur le slave de mariadb, j’utiliserai prochainement galera. Le cache Redis est également configuré en Master/Slave, il n’y a pas (encore) de Redis-Sentinelle pour basculer le slave en master en cas de crash du master… Le cluster GlusterFS possède deux bricks répliquées en temps réel sur deux serveurs (replica). Les serveurs Nexcloud utilisent un répertoire /var/www/html/nextcloud commun pour l’application web ainsi qu’un répertoire /var/nc_data commun pour les données du cloud. Vous l’aurez compris lorsque haproxy vous redirige sur l’un ou l’autre des deux serveurs nexcloud, les données sont immédiatement visibles et accessibles sur les deux et répliquées. Par sécurité j’ai gardé SELinux en mode enforcing, mais vous avez la possibilité de basculer en permissive via une variable Ansible.
J’ai aussi intégré dans cette version le code du réseau. J’aurais pu créer des réseaux distincts avec des routes pour que les briques puissent communiquer, cela sera dans une prochaine version… pour l’instant tout est dans un réseau 10.17.3.0/26. De même je n’ai pas eu le temps de coder l’intégration avec les serveurs d’autorité DNS, pour l’instant ça reste un POC, mais ça aussi sera pour une version ultérieure avec noms de domaines, Let’s Encrypt et Terraform en mode multi providers : libvirt et sans doute OVH hein parce qu’on est frenchies.
Que vous soyez développeur ou que vous manipuliez du Docker voici un outil intéressant qui dépasse les 200 000 téléchargements à ce jour. Portainer.io est mise à disposition en version OpenSource est une boite à outils permettant la gestion de vos conteneurs Docker et ainsi de créer, gérer et réaliser la maintenance via une interface WebUI unique. Dans sa dernière version, Portanier supporte IPV6 et est actuellement en version 2.4.6 et s’interface avec Kubernetes.
Vous pouvez tester cet outil en démo sur le site de Portainer.
Portainer oui mais pour qui ?
Portainer est compatible avec les versions suivantes de Docker : Docker > 1.9 Cet outil peut être géré sur Docker Swarm, Docker Kubernetes, Docker sur Azur.
Architectures compatibles:
Portainer peut être déployé sur les plates-formes suivantes :
Linux plateforme amd64
Linux plateforme Arm
Linux plateforme arm64
Linux plateforme ppc64le
Linux plateforme s390x
Windows plateforme amd64
Darwin plateforme amd64 (MacOS)
Installation de Portainer à l’aide de Docker
L’ensemble du projet est disponible sur le Github du projet, mais n’est pas nécessaire.
Portainer est composé de deux éléments, le Portainer Server et le Portainer Agent. Les deux éléments fonctionnent comme des conteneurs pod Docker sur un moteur Docker ou dans un cluster Swarm, ou encore un Cluster K8s. Lié à Docker, il existe de nombreux scénarios de déploiement possibles. Le scénario présenté est celui le plus couramment utilisé. (si votre configuration n’est pas répertoriée, voir portainer.readthedocs.io pour des options supplémentaires).
Il faut notez que le mode de déploiement recommandé de l’outil est d’utiliser l’agent Portainer. Vous devez donc déployer Portainer Server sur un cluster swarm ou autonome, soit LINUX Docker host/single node ou Windows Docker Host fonctionnant en mode “Linux containers”).
Utilisez les commandes suivantes de Docker pour déployer le Portainer Server ; notez que l’agent n’est pas nécessaire sur les hôtes autonomes, mais qu’il offre des fonctionnalités supplémentaires s’il est utilisé (voir le scénario du portainer et de l’agent ci-dessous):
Il vous suffit ensuite, d’accéder au port 9000 du moteur Docker où fonctionne portainer à l’aide de votre navigateur préféré.
Remarques
Le port 9000 est le port général utilisé par Portainer pour l’accès à l’interface utilisateur. Le port 8000 est utilisé exclusivement par l’agent EDGE pour la fonction de tunnel inverse. Si vous ne prévoyez pas d’utiliser l’agent edge, vous n’avez pas besoin d’exposer le port 8000 vers votre réseau.
L’option -v /var/run/docker.sock:/var/run/docker.sock ne peut être utilisée que dans les environnements Linux. Vous pouvez déployer Portainer Server sur un Host Docker WINDOWS autonome (en exécutant des conteneurs Windows) mais attention il doit-être de version build Windows 1803 ou plus récent.
Il vous suffit ensuite, d’accéder au port 9000 du moteur Docker où fonctionne Portainer à l’aide de votre navigateur.
Remarque: l’option -v \.\pipe\docker_engine:\\\.\ peut être utilisée dans les environnements Windows 1803+ Container uniquement. Gérer un cluster LINUX Swarm avec Portainer Server et le Portainer Agent.
Pour déployer Portainer et un Portainer Agent pour gérer un cluster Swarm, vous pouvez directement déployer Portainer en tant que service dans votre cluster Docker. Il est à noter que cette méthode déploiera automatiquement une seule instance du serveur Portainer et l’agent Portainer comme un service global sur chaque nœud de votre cluster.
Il vous suffit ensuite et comme à l’habitude d’accéder au port 9000 du moteur Docker où fonctionne Portainer à l’aide de votre navigateur.
Gérer un cluster WINDOWS Swarm avec Portainer Server et l’agent Portainer
Pour déployer Portainer et l’agent Portainer pour gérer un cluster Swarm sous Windows 2016 (1803) ou Windows 2019 (10903), vous pouvez déployer Portainer directement en tant que service dans votre cluster Docker. Notez que cette méthode déploiera automatiquement une seule instance du serveur Portainer, et déploiera l’agent Portainer en tant que service global sur chaque nœud de votre cluster. A peu près à l’identique que sous Linux.
Il vous suffit d’accéder ensuite au port 9000 du moteur Docker où fonctionne portainer à l’aide de votre navigateur.
Il est important de noter qu’il faut s’assurer que les ports réseaux requis sont exposés sur les hôtes Docker dans votre cluster AVANT de déployer la pile (et redémarrez votre hôte après avoir ajouté les règles).
Pour déployez Portainer Agent sur un cluster LINUX Swarm distant en tant que service d’essaimage, exécutez cette commande sur un nœud de gestion dans le cluster distant.
Pour déployer l’agent Portainer sur un serveur docker SINGLE Windows Server 2016 ( ou ultérieur) fonctionnant comme un nœud Swarm (pour les déploiements multi-noeuds, veuillez consulter les configurations avancées)
Note : les options ci-dessus ne font que déployer l’agent, vous devez vous connecter à l’agent à partir d’une instance existante de Portainer Server. Pour d’autres scénarios de déploiement, et pour connaître les conseils et les techniques de déploiement avancées, consultez la documentation complète de Portainer.
Portainer est libre d’utilisation
… mais le support ne l’est pas, voici les modèles de supports facturables:
Nous utilisons des cookies sur notre site Web pour vous offrir l'expérience la plus pertinente en mémorisant vos préférences et des visites répétées. En cliquant sur «Accepter», vous consentez à l'utilisation de TOUS les cookies.
Ce site Web utilise des cookies pour améliorer votre expérience pendant que vous naviguez sur le site Web. Parmi ces cookies, les cookies classés comme nécessaires sont stockés sur votre navigateur car ils sont essentiels au fonctionnement des fonctionnalités de base du site Web. Nous utilisons également des cookies tiers qui nous aident à analyser et à comprendre comment vous utilisez ce site Web. Ces cookies ne seront stockés dans votre navigateur qu'avec votre consentement. Vous avez également la possibilité de désactiver ces cookies. Mais la désactivation de certains de ces cookies peut avoir un effet sur votre expérience de navigation.
Les cookies fonctionnels aident à exécuter certaines fonctionnalités telles que le partage du contenu du site Web sur les plates-formes de médias sociaux, la collecte de commentaires et d’autres fonctionnalités tierces.
Les cookies de performance sont utilisés pour comprendre et analyser les principaux indices de performance du site Web, ce qui contribue à offrir une meilleure expérience utilisateur aux visiteurs.
Cookie
Description
YSC
Ces cookies sont définis par Youtube et sont utilisés pour suivre les vues des vidéos intégrées.
Les cookies analytiques sont utilisés pour comprendre comment les visiteurs interagissent avec le site Web. Ces cookies aident à fournir des informations sur les mesures du nombre de visiteurs, du taux de rebond, de la source du trafic, etc.
Les cookies publicitaires sont utilisés pour fournir aux visiteurs des publicités et des campagnes marketing pertinentes. Ces cookies suivent les visiteurs sur les sites Web et collectent des informations pour fournir des publicités personnalisées.
Cookie
Type
Durée
Description
IDE
1 an et 24 jours
Utilisé par Google DoubleClick et stocke des informations sur la façon dont l'utilisateur utilise le site Web et toute autre publicité avant de visiter le site Web. Ceci est utilisé pour présenter aux utilisateurs des publicités qui les concernent en fonction du profil de l'utilisateur.
test_cookie
15 minutes
Ce cookie est défini par doubleclick.net. Le but du cookie est de déterminer si le navigateur de l'utilisateur prend en charge les cookies.
VISITOR_INFO1_LIVE
5 mois et 27 jours
Ce cookie est défini par Youtube. Utilisé pour suivre les informations des vidéos YouTube intégrées sur un site Web.
Les cookies nécessaires sont absolument essentiels au bon fonctionnement du site Web. Ces cookies assurent les fonctionnalités de base et les fonctions de sécurité du site Web, de manière anonyme.
Cookie
Type
Durée
Description
__cfduid
1 month
Le cookie est utilisé par les services cdn comme CloudFare pour identifier les clients individuels derrière une adresse IP partagée et appliquer les paramètres de sécurité par client. Il ne correspond à aucun identifiant d'utilisateur dans l'application Web et ne stocke aucune information personnellement identifiable.
cookielawinfo-checkbox-performance
1 an
Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour stocker le consentement de l'utilisateur pour les cookies dans la catégorie «Performance».