Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] La gestion des certificats pour les connexions OpenVPN

icon 17/09/2019 - 2 commentaires

Il existe plusieurs méthodes pour monter un tunnel VPN site-à-site avec OpenVPN. Les deux principales consistent en l'utilisation de clés partagées ou en l'utilisation de certificats (X.509).

Après notre premier article sur la configuration d'OpenVPN avec clé partagée, nous abordons ici sa configuration avec la gestion des certificats.

Article mis à jour le  : 17/09/2019

À noter : nous ne détaillons pas dans cet article tous les détails de configuration d'OpenVPN. Nous nous concentrons sur la création, l'utilisation et la révocation des certificats. Il existe déjà un article dédié à la configuration d'OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Le client et le serveur OpenVPN sont authentifiés à l'aide de certificats. Pour cela, ces certificats doivent être émis par une autorité de certification reconnue comme sûre aussi bien par le serveur que par le client.

Dans notre cas, nous créerons une autorité de certification (appelée "CA" pour Certificate Authority) sur le pfSense faisant office de serveur. Puis nous créerons deux certificats : un certificat client (qui sera utilisé côté Client) et un certificat serveur (qui sera utilisé côté Serveur). Ces deux certificats seront signés par l'autorité de certification que nous aurons créé précédemment.

Pour signer un certificat, il est nécessaire de disposer de la clé privée de l'autorité de certification.
Pour valider la signature d'un certificat, il est nécessaire de disposer de la clé publique de l'autorité de certification.



Création d'une autorité de certification - CA

Actions à effectuer coté serveur OpenVPN

Pour commencer, nous nous rendons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Les champs à renseigner sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
  • Method : 3 méthodes sont possibles :
  1. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  2. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  3. Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, côté serveur, nous créerons une nouvelle autorité de certification (Create an internal Certificate Authority). Côté client, nous importerons la clé publique de l'autorité de certification créée côté serveur (Import an existing Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
  • Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Autres champs : l'ensemble des champs suivants sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Ils peuvent être laissés vides ou complétés.

Exemple de résultat obtenu :

exemple création autorité de certification (CA) pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre autorité de certification est créée.



Création d'un certificat serveur

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 4 méthodes sont possibles :
  1. Create an internal Certificate : permet de créer une nouveau certificat
  2. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  3. Create a certificate Signing Request : permet de créer un fichier de requête qui pourra être envoyé à un CA tiers pour être signé. Cela peut être utile pour obtenir un certificat d'un CA root de confiance.
  4. Sign a Certificate Signing Request : permet de signer un fichier de requête
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
  • Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
  • Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
  • Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
  • Autres champs : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Ils peuvent être laissés vides ou complétés.
  • Certificate Type : le type de certificat. Il existe 2 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
Dans notre cas, nous choisissons "Server Certificate".

Exemple de résultat obtenu :

Exemple de configuration certificat serveur OpenVPN - pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre certificat pour le serveur OpenVPN est créé.



Création d'un certificat client

Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".

Exemple de résultat obtenu :

Exemple de configuration certificat client OpenVPN - pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre certificat pour le client OpenVPN est créé.



Configuration du serveur OpenVPN

Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Nous conseillons de la cocher. La clé TLS sera générée automatiquement. Il restera à la copier côté client.
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat serveur OpenVPN Provya (Server: Yes, CA: CA Provya)")
  • DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Exemple de configuration serveur OpenVPN avec certificat sur pfSense - Provya


La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.



Export des certificats

Nous devons exporter le certificat de l'autorité de certification (c'est-à-dire sa clé publique), ainsi que le certificat et la clé privée du client OpenVPN.

Pour cela, nous retournons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA" de l'autorité de certification que nous avons créée précédemment :

Export du certificat d'une autorité de certificat sous pfSense - Provya



Puis, dans l'onglet "Certificates", nous cliquons successivement sur les icônes "Export Certificate" et "Export Key" du certificat client que nous avons créé précédemment :

Export clé et certificat client pour OpenVPN - pfSense - Provya


La configuration côté serveur OpenVPN est terminée.

Maintenant, nous procédons à l'import des clés publiques/privées et à la configuration côté client OpenVPN.



Import de la clé publique du CA sur le pfSense client OpenVPN

Actions à effectuer coté client OpenVPN

Nous nous rendons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Nous allons importer la clé publique du CA que nous avons créé sur le serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("CA Provya")
  • Method : nous choisissons "Import an existing Certificate Authority"
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Certificate Private Key (optional) : si l'on souhaite importer la clé privée (.key), elle est à copier dans ce champ. Dans notre cas, nous le laissons vide. En effet, nous ne souhaitons pas signer de nouveaux certificats (nécessite la clé privée de l'autorité de certification), nous souhaitons seulement valider la signature du certificat qu'utilise le serveur OpenVPN (nécessite la clé publique de l'autorité de certification)
  • Serial for next certificate : ce champ est à remplir uniquement si l'on importe une clé privée. Dans ce cas, il est important que chaque certificat créé par un CA dispose d'un numéro de série unique (autrement, nous risquons de rencontrer des problèmes en cas de révocation de certificat). Il faut donc choisir une valeur suffisamment grande (supérieure au nombre de certificat déjà créé par ce CA) afin d'éviter toute collision.

Exemple de résultat obtenu :

Import du certificat d'une autorité de certification sous pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Import de la clé publique et de la clé privée du certificat client OpenVPN

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.

Nous allons importer la clé publique et la clé privée du certificat client que nous avons créé sur le pfSense serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Method : on choisit "Import an existing Certificate"
  • Descriptive name : le nom que l'on souhaite donner à notre certificat. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("Certificat client OpenVPN Provya")
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Private key data : on copie dans ce champ le contenu de la clé privée (.key)

Exemple de résultat obtenu :

Import d'un certificat client OpenVPN sous pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Configuration du client OpenVPN

Le détail de la configuration du client OpenVPN se trouve dans l'article [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Décocher la case "Automatically generate a TLS Key", et copier dans le champ "TLS Key" la clé TLS qui a été généré côte serveur OpenVPN.
  • Peer Certificate Authority : choisir l'autorité de certification importée précédemment ("CA Provya")
  • Client Certificate : choisir le certificat client importé précédemment ("Certificat client OpenVPN Provya")
  • DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Exemple de configuration client OpenVPN avec certificat sur pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Révocation de certificat

Le dernier élément, pour être complet sur la gestion des certificats, est la liste de révocation de certificats ou "Certificate Revocation Lists" (CRLs).

Cette liste de révocation contient les certificats qui ne doivent plus être considérés comme sûrs (car ils ont été compromis ou pour n'importe quelle autre raison).
Pour les connexions OpenVPN, la CRL peut être utilisée par le serveur pour vérifier les certificats utilisés par les clients OpenVPN.

Une CRL est signée par un CA. Ainsi, pour générer une CRL, il est nécessaire de disposer de la clé privée du CA.

Généralement, une seule CRL est maintenue par CA. Cependant, pfSense peut en maintenir davantage.
Néanmoins, une seule CRL pourra être sélectionnée par instance OpenVPN.
Ce fonctionnement permet, par exemple, d'empêcher un certificat de se connecter à une instance OpenVPN, mais de l'autoriser à se connecter à une autre instance.

Une CRL peut être soit créée, soit importée. La configuration se fait dans le menu System > Cert Manager depuis l'onglet "Certificate Revocation" (troisième onglet).

Pour ajouter une nouvelle CRL, nous cliquons sur le bouton "+ Add or import CRL" correspondant au CA qui signera cette CRL (dans notre cas, "CA Provya"). Les champs à renseigner sont les suivants :
  • Method : deux méthodes sont possibles :
  1. Create an internal Certificate Revocation List : permet de créer une nouvelle CRL (nécessite de disposer de la clé privée du CA)
  2. Import an existing Certificate Revocation List : permet d'importer une CRL générée depuis un serveur tiers (disposant de la clé privée du CA)
  • Descriptive name : le nom de notre CRL. On y inclut généralement une référence au nom du CA et/ou l'usage de cette CRL
  • Certificate Authority : le CA qui a signé ou va signer cette CRL
  • Lifetime : la durée de vie de la CRL (10 ans par défaut)
  • Serial : le numéro de série de la CRL (0 par défaut pour la première)

Exemple de résultat obtenu :

Création d'une CRL (Certificate Revocation Liste) sous pfSense - Provya


Notre CRL est créée. On peut maintenant lui ajouter les certificats à révoquer. Pour cela, cliquer sur l'icône "Edit CRL" :

Modifier CRL sous pfSense - Provya


Il reste à choisir le certificat à révoquer, la raison de la révocation (ce champ est purement informatif) et cliquer sur le bouton "ADD".

Enfin, dans la configuration de notre serveur OpenVPN, nous devons ajouter cette CRL (champ "Peer Certificate Revocation List").


Voilà ! Notre serveur OpenVPN est prêt à fonctionner avec des certificats.



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la gestion des interfaces réseaux

icon 03/09/2019 - 6 commentaires

La gestion des interfaces réseaux sous pfSense peut être quelque peu déroutante pour un débutant. Nous présentons ici les rappels de base et les cas d'utilisation de chaque type d'interface.

Article mis à jour le  : 03/09/2019


Il existe 3 types d'interfaces sous pfSense :

  • interface physique : correspond aux interfaces physiques réelles du serveur sur lequel tourne pfSense. Ces interfaces sont généralement nommées re0, re1 (pour des interfaces Realtek), igb0, igb1 (pour des interfaces Intel Gbps), etc.
  • interface virtuelle : ces interfaces sont automatiquement créées lors de la création d'un VLAN, d'un serveur OpenVPN, etc. Elles sont donc associées à un service.
  • interface logique : ce sont les interfaces que nous pouvons configurer (attribution d'adresse IP, règle de filtrage du firewall, etc.). Ces interfaces sont associées à une interface physique ou virtuelle.

Les deux premiers types d'interfaces (interface physique et interface virtuelle) sont appelés "ports réseaux".

Une interface logique doit être associée à un port réseau.

Un port réseau (c'est-à-dire une interface physique ou virtuelle) ne peut être associé qu'à une seule interface logique (c'est-à-dire configurable).



Interfaces physiques

Une interface physique correspond à une carte réseau du serveur pfSense.
Ces interfaces sont nommées en fonction de leur driver. Par exemple : re0, re1, igb0, igb1, ath0, etc. Elles sont identifiées par leur adresse MAC.

Lors de l'installation de pfSense, il est proposé de configurer les interfaces. Ce sont des interfaces logiques. Elles sont créées, configurées et associées aux interfaces physiques.
Ainsi, dans le cas d'un pfSense disposant de deux interfaces (une interface LAN et une interface WAN), on pourrait avoir l'association suivante :

WAN [interface logique] = igb0 [port réseau]
LAN [interface logique] = igb1 [port réseau]

Il est également possible de retrouver cette association depuis le menu Interfaces > Assignments :

menu Interfaces > Assignement - pfSense - Provya




Interfaces virtuelles

Ces interfaces sont créées lors de l'activation de certains services (VLAN, OpenVPN).

La configuration d'un serveur OpenVPN entraîne automatiquement la création d'une interface virtuelle associée à cette instance serveur OpenVPN. L'interface virtuelle sera nommée ovpns1, ovpns2, etc...

Cette interface n'est pas configurable en l'état : ce n'est qu'un port réseau. Il est nécessaire de l'associer à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.

Lorsque nous procédons à cette association, nous obtenons l'exemple suivant :

association interfaces réseau - pfSense - Provya


Dans la capture d'écran ci-dessus, nous voyons que l'interface logique "OPT2" est associée à l'interface virtuelle "ovpns1" qui a été créée lors de la configuration du serveur OpenVPN "VPN Provya".

De la même façon, la création d'un VLAN entraîne la création d'une interface virtuelle (qui sera nommée VLAN1, VLAN2, etc.).
Cette interface virtuelle devra être associée à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.



Interfaces logiques

Les interfaces logiques sont les interfaces configurables. Ce sont ces interfaces que nous allons pouvoir configurer : associer une adresse IP ; activer un serveur DHCP ; configurer des règles de firewall ou de NAT ; etc.

Ainsi, lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.

Les interfaces logiques les plus connues sont LAN et WAN.

Une interface logique est obligatoirement associée à un port réseau (c'est-à-dire à une interface physique ou virtuelle).



Groupe d'interfaces

Un groupe d'interfaces rassemble plusieurs interfaces logiques.
Ce groupe est donc un groupe logique auquel on peut appliquer des règles de firewall ou de NAT.

L'utilisation d'un groupe d'interfaces est utile si l'on dispose de plusieurs interfaces logiques sur lesquelles nous souhaitons appliquer exactement les mêmes règles.
Ainsi, les règles de firewall définies pour ce groupe s'appliqueront à toutes les interfaces du groupe.

La création de groupe d'interfaces se fait dans le menu Interfaces > Assignments, puis l'onglet "Interface Groups" :

menu Interface Groups - pfSense - Provya


L'ajout se fait en cliquant sur le bouton "+ Add".

Nous renseignons le nom du groupe d'interfaces, une description (facultative) et la liste des interfaces faisant partie du groupe :

création groupe interfaces - pfSense - Provya


Ce groupe d'interfaces sera visible dans les onglets du firewall :

règles de filtrage pour groupe interfaces - pfSense - Provya


Il est à noter qu'au niveau du firewall, ce sont les règles du groupe d'interfaces qui sont vérifiées, avant les règles de l'interface logique.

D'une façon générale, les règles de vérification du firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques



Cas particulier : OpenVPN

Lors de la création d'une instance serveur ou client OpenVPN, hormis les interfaces virtuelles (ovpns1 ou ovpnc1), un groupe d'interfaces nommé "OpenVPN" est automatiquement créé.

Les configurations réalisées sur ce groupe "OpenVPN" s'appliquent à l'ensemble des services OpenVPN (c'est-à-dire tous les serveurs ou tous les clients OpenVPN configurés).

Si nous souhaitons une granularité de configuration par instance OpenVPN, alors nous devons créer une interface logique pour chaque interface virtuelle OpenVPN existante.



Cas d'application

Lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.
Pour les services dont la configuration peut se faire pour plusieurs interfaces (une règle de firewall, par exemple), il sera également proposé les groupes d'interfaces.

Il existe deux cas particuliers à noter : la configuration des clients ou serveurs OpenVPN et IPsec.
Pour ces services, le choix de l'interface sera :
  1. les interfaces logiques
  2. les groupes de gateway
  3. les adresses VIP
  4. l'interface localhost
  5. toutes les interfaces logiques existantes (choix "any")
Les groupes d'interfaces ne seront pas proposés.


Nous voila maintenant armés pour bien comprendre et configurer correctement les services sur les bonnes interfaces réseau !



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Bien choisir et dimensionner son firewall


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :