Source: https://www.ssi.gouv.fr/uploads/2012/09/NT_IPsec.pdf
Le document en question rédigé par l’ANSSI présente les « Recommandations de sécurité relatives à IPsec a pour la protection des flux réseau ». Il est téléchargeable sur le site www.ssi. gouv.fr/ipsec. Il constitue une production originale de l’ANSSI. Il est à ce titre placé sous le régime de la « Licence ouverte » publiée par la mission Etalab (www.etalab.gouv.fr). Il est par conséquent diffusable sans restriction. Ces recommandations sont livrées en l’état et adaptées aux menaces au jour de leur publication. Au regard de la diversité des systèmes d’information, l’ANSSI ne peut garantir que ces informations puissent être reprises sans adaptation sur les systèmes d’information cibles. Dans tous les cas, la pertinence de l’implémentation des éléments proposés par l’ANSSI doit être soumise, au préalable, à la validation de l’administrateur du système et/ou des personnes en charge de la sécurité des systèmes d’information.
Ce présent article n’est qu’un condensé technique des bonnes pratiques évoquées, et utilisant la convention Rx.
R1= Il est recommandé de recourir à la liste des produits suivantes [évalués par l’ANSSI] , en priorité à ceux qui sont qualifiés (ou sinon certifiés) dès lors qu’il existe un besoin de produits de confiance.
Disponible sur www.ssi.gouv.fr/fr/certification-qualification/
R2= [A choisir entre VPN SSL et VPN IPSEC, si priorité est donné à la sécurité] il est recommandé d’utiliser IPsec plutôt que TLS.
R3= L’emploi d’IPsec doit se faire avec le protocole ESP. Bien qu’il ne présente pas de risque de sécurité en soi, l’emploi d’AH est déconseillé
R7/R10= Il est préférable de fixer a priori les algorithmes et tailles de clés employés (ou de réduire le nombre de SA possible) et de n’utiliser IKE que pour l’échange de clés. On privilégiera la configuration statique des SP lorsque le cadre d’emploi le permet
R8 = Il est recommandé d’utiliser la version 2 d’IKE.
> Lorsque la présence de NAT peut aller aussi en faveur de IKE v2
> L’interopérabilité entre plusieurs éditeurs de sécurité est parfois meilleure sur IKEv1.
R9= Préférer une initialisation reposant sur une PKI (auth par certificat) plutot que via PSK (clé pré-partagée)
R12= Si possible, mettre en œuvre la propriété PFS en phase 2 « quick mode » l’échange de clé Diffie-Hellman éphémère classique ou sa variante sur courbes elliptiques.
R13= Si possible, il est recommandé de forcer le renouvellement périodique des clés, par exemple toutes les heures et tous les 100 Go de données, afin de limiter l’impact de la compromission d’une clé sur le trafic des données
R15= Il est déconseillé d’utiliser 3DES, SHA-1 ou ECDSA avec des clés de moins de 256 bits si des alternatives plus sécurisées telles qu’AES (AES-128 ou AES-256), SHA-2 (SHA224, SHA-256, SHA-384 ou SHA-512) ou ECDSA avec des clés d’au moins 256 bits sont disponibles.
R16= Ne plus utiliser les groupes Diffie-Hellman 1 et 2.
On privilégiera les groupes ayant des modules de taille plus importante (comme les groupes 14 et 15) voire (si possible) les groupes construits sur des courbes elliptiques d’au moins 256 bits (comme la courbe ecp256, aussi nommée groupe 19 ou encore la courbe ecp384bp, normalisée sous l’appellation groupe 29).
Spécificités FORTINET:
Au 1er Septembre 2020, FortiOS 6.2.4, la configuration par défaut issue du Wizard Fortinet utilise:
Phase1
IKE v1 – main mode
proposal: aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
dhgrp: 14 5
suiteb: disable
Phase2:
proposal: aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
PFS: enable
DH Group: 14 5
