Remarque :

Utiliser OCI Network Firewall pour le proxy de transfert SSL et l'inspection entrante à l'aide de la règle de décryptage

Introduction

Le service Oracle Cloud Infrastructure (OCI) Network Firewall est une solution de pare-feu gérée basée sur le cloud qui utilise la technologie de pare-feu de nouvelle génération (NGFW) de Palo Alto Networks. Grâce à ses fonctionnalités de pare-feu de pointe basées sur le machine learning, le service OCI Network Firewall fournit une protection de premier ordre pour vos charges de travail OCI, tout en étant facile à utiliser dans l'écosystème OCI.

Le pare-feu OCI Network Firewall inspecte toutes les demandes, y compris le trafic crypté TLS (Transport Layer Security), lorsqu'il passe par le pare-feu. En fonction de vos règles de stratégie de pare-feu définies par l'utilisateur, le service peut effectuer diverses actions, notamment autoriser, rejeter, supprimer, détecter les intrusions ou prévenir. Grâce à ces fonctionnalités robustes, OCI Network Firewall est un outil puissant pour protéger vos charges de travail OCI contre toute une variété de menaces de sécurité.

Objectifs

L'objectif de ce tutoriel est de fournir un guide complet pour l'implémentation du proxy de transfert SSL et de l'inspection entrante à l'aide de règles de décryptage dans le pare-feu de nouvelle génération dans OCI Cloud.

En suivant ce tutoriel, vous aurez une bonne compréhension du proxy de transfert SSL et de l'inspection entrante à l'aide de règles de décryptage, et pourrez appliquer ces connaissances pour sécuriser votre infrastructure réseau dans OCI Cloud.

Prérequis

Remarque : il est recommandé de configurer un environnement de test dans OCI pour tester les configurations de pare-feu et les règles de décryptage avant de les implémenter dans un environnement de production.

Architecture

Architecture

La stratégie de pare-feu OCI Network se compose de listes qui incluent :

Test

Pour ce tutoriel, nous avons créé une connexion SSH à l'ordinateur Linux (dans Sous-réseau public : 129.146.201.118) sur Internet en appliquant une règle de sécurité à la stratégie de pare-feu.

Vous avez maintenant une idée de la façon dont les listes peuvent être utilisées pour créer des règles de sécurité pour votre pare-feu. En utilisant cette règle, nous avons effectué un accès SSH à l'ordinateur Linux.

Comprendre la technologie de cryptage TLS/SSL

Remarque :

TLS est un protocole cryptographique qui fournit une sécurité de bout en bout pour toutes les données envoyées entre les applications sur Internet. La plupart des scénarios courants concernent la navigation sécurisée sur le Web. Toutefois, il peut et doit également être utilisé pour d'autres applications telles que les e-mails, les transferts de fichiers, la vidéoconférence/audioconférence, la messagerie instantanée et la voix sur IP, etc.

Il est important de comprendre que TLS ne sécurise pas les données sur les systèmes finaux. Il assure la transmission sécurisée des données sur Internet, en évitant d'éventuels écoutes et/ou altérations du contenu envoyé (en transit). TLS est normalement implémenté sur TCP afin de chiffrer des protocoles de couche d'application tels que HTTP, FTP, SMTP et IMAP, bien qu'il puisse également être implémenté sur UDP, DCCP et SCTP.

Pour protéger les données, TLS s'appuie sur la technologie de cryptographie afin de chiffrer/déchiffrer les données en transit envoyées sur Internet. Nous aborderons des termes et des concepts tels que la cryptographie symétrique et asymétrique, l'infrastructure à clé publique (PKI) et les certificats numériques X.509.

Pour configurer, configurer et appliquer le pare-feu de nouvelle génération à votre réseau, vous devez comprendre le fonctionnement des connexions TLS (comme https), y compris la configuration et le déploiement des certificats numériques X.509.

Chiffrement et types

L'idée derrière le chiffrement est précisément de dissimuler ou de cacher (chiffrer) les informations que nous voulons envoyer de A à B dans un " canal non sécurisé ". Un canal non sécurisé est un canal ou un chemin où nous ne pouvons garantir que personne n'interceptera, ne volera ou ne modifiera (conserve) les informations transmises de A à B et l'autre sens.

La cryptographie nous permet de sécuriser les informations circulant via un canal non sécurisé, en chiffrant (cachant) les données d'origine vers leur destination. Une fois reçu par le récepteur, le récepteur pourra déchiffrer les données chiffrées reçues à leur valeur d'origine.

Il existe deux types de chiffrement : Symétrique et asymétrique.

Chiffrement symétrique

Afin de chiffrer/déchiffrer un bloc de données, les moteurs de chiffrement symétriques utilisent exactement la même clé pour chiffrer et déchiffrer les données. Il s'agit normalement de la clé maître ou de la clé secrète partagée.

Chiffrement de la clé maître

Bien que cela semble être un moyen facile de réaliser le chiffrement, le problème principal ici est de distribuer la clé principale entre les deux parties sur un canal non sécurisé. Ce processus d'échange de clés principales sera traité dans ce tutoriel à l'aide de différentes techniques, y compris une technique expliquée dans la section suivante : chiffrement asymétrique.

Voici quelques algorithmes de cryptage symétrique les plus courants : AES128, AES256, Serpent, Camelia, etc.

Chiffrement asymétrique

Le chiffrement/cryptographie asymétrique utilise une paire de clés associées avec une relation spéciale : toutes les données que vous chiffrez avec l'une des clés de paire peuvent être décryptées UNIQUEMENT PAR l'autre clé de paire et l'autre façon de contourner.

Chiffrement asymétrique

Normalement, nous faisons référence à ces clés de paire comme clé publique et clé privée. La clé publique peut être partagée avec tous, tandis que la clé privée doit être gardée secrète.

Le chiffrement asymétrique résout le problème de la distribution des clés en utilisant des clés publiques pour le chiffrement et des clés privées pour le déchiffrement (ou l'inverse). Cependant, le compromis est que les systèmes de chiffrement asymétriques sont très lents par rapport aux systèmes symétriques et nécessitent beaucoup plus de puissance de calcul en raison de leur longueur de clé considérablement plus longue.

Les algorithmes de chiffrement symétriques sont beaucoup plus rapides et nécessitent moins de puissance de calcul, mais leur principale faiblesse est la distribution des clés, car la même clé est utilisée pour chiffrer et déchiffrer les informations, cette clé doit être distribuée à tous ceux qui ont besoin d'accéder aux données.

TLS utilise un chiffrement asymétrique et symétrique, et non seulement pour chiffrer les données, mais aussi pour authentifier les parties impliquées dans la connexion. Voici où les certificats X.509 prennent des mesures.

Certificats X.509

Un certificat X.509 est un certificat numérique basé sur la norme X.509 (International Telecommunications Union) largement acceptée, qui définit le format des certificats d'infrastructure à clé publique (PKI). Un certificat X.509 est archivé à l'aide d'une paire de clés composée d'une clé publique et d'une clé privée associées. Comme nous l'avons mentionné ci-dessus, cette paire de clés est précisément la paire de clés utilisée dans le chiffrement asymétrique, où nous choisissons l'une comme étant publique et l'autre comme étant privée. N'oubliez pas que tout ce que vous chiffrez à l'aide de l'une des clés ne peut être déchiffré que par l'autre clé, et l'autre sens.

Comme vous pouvez l'imaginer, la partie publique de la paire de clés, comme son nom l'indique, est publique et peut être librement distribuée. La clé privée doit être kept secure et souvent chiffrée à l'aide d'une clé principale en mode de chiffrement symétrique, de sorte que personne ne peut l'utiliser même en cas de vol.

En plus de la clé publique, le certificat X.509 contient d'autres informations qui représentent une identité (un nom d'hôte, une organisation ou un individu), par conséquent le certificat x.509 lie cette identité à la clé publique contenue.

La structure d'un certificat numérique X.509 v3 est la suivante :

Certificat

Numéro de version

Numéro de série

ID algorithme de signature

Nom de l'émetteur

Période de validité

Avant

Pas après

Nom du sujet

Info clé publique sujet

Algorithme de clé publique

Clé publique sujet Il s'agit de la clé publique

Identificateur unique de l'émetteur (facultatif)

Identifiant unique du sujet (facultatif)

Extensions (facultatif)

…

algorithme de signature de certificat

Signature du certificat

La clé publique est liée à une identité représentée dans le nom du sujet qui est une chaîne au format suivant :

où, Objet : C = US, ST = Californie, L = Mountain View, O = Google LLC, CN = *.google.com

Cette identité appartient donc à Google, au pays des Etats-Unis, en Californie et à un nom courant *.google.com.

Nous pouvons utiliser ce certificat pour deux raisons : distribuer notre clé publique ET authentifier notre identité auprès d'autres. En gardant cela à l'esprit, tout ordinateur/mobile/appareil là-bas, lors de la réception de notre certificat, il possédera notre clé publique et notre identité. Par conséquent, il pourra envoyer des informations chiffrées à l'aide de la clé publique, et seulement nous pourrons le déchiffrer (avec la clé privée). De plus, le certificat a notre identité à l'intérieur, de sorte que l'appareil qui le reçoit pourra faire confiance à cette identité et s'assurer qu'il échange des informations avec la bonne identité.

Comme nous l'avons mentionné ci-dessus, le cryptage asymétrique via des clés publiques/privées est beaucoup plus lent que le cryptage symétrique (x4 ou plus) et n'est donc pas viable. De plus, nous n'avons pas expliqué comment l'appareil qui reçoit le certificat peut vraiment faire confiance à l'identité à l'intérieur du certificat. A la fin, le certificat X.509 n'est qu'un morceau de texte reçu sur un canal non sécurisé. Pour confirmer/authentifier un certificat reçu, nous avons besoin d'une autorité de certification, une organisation trusted pour signaler les certificats numériques. Une autorité de certification vérifie l'identité et la légitimité de la société ou de la personne qui a demandé un certificat et, si la vérification réussit, elle émet un certificat signé. Oracle, VeriSign, D-Trust et DigiCert sont des exemples d'organisations d'autorité de certification.

Alors, du point de vue de la cryptographie, comment fonctionne ce processus de signature ? Encore une fois, nous allons utiliser la puissance du chiffrement asymétrique pour cela, comme suit :

Donc, maintenant que nous avons notre certificat X.509 prêt à agir. Comment un ordinateur/mobile/appareil recevant ce certificat pendant une connexion TLS peut-il vérifier s'il s'agit d'un certificat X.509 valide ? Là encore, nous utiliserons la puissance du chiffrement asymétrique, comme suit :

Maintenant que nous savons que nous disposons d'un certificat valide qui inclut le nom de domaine auquel nous essayons de nous connecter, par exemple, www.mycompanycomain.com (inclus dans les champs de nom commun ou de nom alternatif de sujet du certificat), l'ordinateur/mobile/navigateur s'assurera que nous sommes effectivement connectés à ce nom de domaine DNS (www.mycompanycomain.com) et non à un autre. Il s'agit d'une validation obligatoire, car toute personne peut voler le certificat X.509 et essayer de l'utiliser à partir d'un autre serveur de domaine DNS (www.myfakecompany.com, etc.) et il transmettrait le processus de validation de signature CA.

Donc, maintenant tous les ordinateurs/mobiles/périphériques là-bas peuvent télécharger la clé publique de notre certificat et envoyer des données chiffrées afin que seulement nous puissions le déchiffrer. Le chiffrement asymétrique étant beaucoup plus lent que le chiffrement symétrique (x4 ou plus), il n'est pas viable. La solution consiste à utiliser les deux et c'est là que SSL/TLS est requis.

Principes de base de TLS

TLS est un protocole cryptographique qui assure la sécurité de bout en bout des données envoyées entre les applications sur Internet. Il est généralement familier aux utilisateurs par son utilisation dans la navigation Web sécurisée, et en particulier l'icône de cadenas qui apparaît dans les navigateurs Web lorsqu'une session sécurisée est établie.

TLS utilise une combinaison de cryptographie symétrique et asymétrique, car cela constitue un bon compromis entre les performances et la sécurité lors de la transmission sécurisée des données. Rappelez-vous que la cryptographie asymétrique nécessite une puissance de calcul 4x ou plus que la cryptographie symétrique. Cependant, la cryptographie symétrique nécessite la même clé maître des deux côtés de la communication pour pouvoir chiffrer/déchiffrer le message, de sorte que le but de l'utilisation du chiffrement symétrique est de pouvoir échanger le la clé maître (ou clé secrète partagée) entre les deux parties sur un canal non sécurisé d'abord, puis commencer à utiliser cette clé maître pour sécuriser la communication, chiffrer/déchiffrer chaque message envoyé/reçu à l'aide du moteur symétrique choisi.

TLS, image de hacker

Afin d'échanger une clé maître sur un canal non sécurisé, TLS utilisera deux techniques différentes qui suivent le même objectif, à savoir l'échange sécurisé de la clé maître/clé secrète partagée dans un canal non sécurisé :

La méthodologie RSA s'appuie sur l'utilisation de la puissance du chiffrement asymétrique (clé privée et clé publique) pour échanger la clé maître sur un canal non sécurisé.

DHE/ECDHE s'appuie sur des calculs mathématiques pour générer la même clé principale entre deux parties sur un canal non sécurisé. Les deux parties échangeront certaines informations bénignes qui seront mélangées avec leurs informations privilégiées lorsqu'elles voyagent sur un canal non sécurisé et peuvent être capturées sans risque. A la fin de la négociation, les deux calculs mathématiques des deux parties finiront par la même clé secrète ou principale commune. Plus d'informations https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Ces deux méthodes d'échange clés ont lieu au cours d'un processus appelé établissement de liaison TLS.

Liaison TLS non masquée

Un établissement de liaison SSL/TLS est une négociation entre deux parties sur un réseau, comme un navigateur et un serveur Web, pour établir les détails de leur connexion. Au cours de cette négociation, les deux parties authentifient (à l'aide des certificats X509), accordent une suite de chiffrement (comment la clé maître sera échangée et quels moteurs de cryptographie seront utilisés, tels que AES256, 128, hachage) tels que SHA1, 2, etc.) et enfin, lorsque l'authentification se produit (certificat valide reçu) et qu'un accord sur la façon d'établir un canal sécurisé est fait, nous disposerons d'un canal sécurisé des deux parties. Voici les étapes réelles :

Liaison TLS

Dans le graphique ci-dessus, nous utilisons RSA (clé privée/publique) pour échanger la clé principale (ou clé secrète partagée) à utiliser dans le moteur de cryptage symétrique convenu (c'est-à-dire AES256) lors de la négociation du mécanisme de cryptage. Si DHE/ECDHE était utilisé, au lieu d'utiliser une clé publique et une clé privée pour échanger la clé principale, les deux parties utiliseraient les calculs DHE, en échangeant des matériaux bénins, pour finir par calculer le même résultat dans les deux parties. Ce résultat deviendra la clé maître (secret partagé) à utiliser pour le chiffrement symétrique.

Tâche 1 : utilisation d'OCI Network Firewall pour le proxy de transfert SSL et l'inspection entrante à l'aide de la règle de décryptage

  1. Créez deux certificats autosignés à l'aide d'Opensl pour le trafic sortant et l'inspection entrante à l'aide de Open SSL sur l'ordinateur Linux. Mettez à jour la machine Linux pour faire confiance au certificat.

    Création de certificats autosignés

  2. Créez un coffre dans OCI.

    Vault

  3. Une fois le coffre créé, créez une clé. Le contenu de la clé secrète doit être au format suivant.

    {

"caCertOrderedList":

[

"-----BEGIN CERTIFICATE

-----END CERTIFICATE-----\n"

],

"certKeyPair":

{

"cert" : "-----BEGIN CERTIFICATE

-----END CERTIFICATE----\n",

"key": "-----BEGIN RSA PRIVATE KEY

-----END RSA PRIVATE KEY----\n"

}

}

  4. Dans la stratégie de pare-feu réseau, ajoutez la clé secrète mappée.

    1. Choisissez le type de clé secrète mappée en tant que proxy de transfert SSL ou inspection entrante SSL.

    2. Choisissez le coffre créé.

    3. Choisissez la clé secrète.

    4. Ajoutez la clé secrète mise en correspondance.

      Clé secrète mise en correspondance

  5. Créez un profil de cryptage.

    1. Choisissez SSL Forward Proxy et vérifiez les options de vérification du certificat du serveur ou choisissez l'inspection entrante SSL et vérifiez les vérifications de mode non prises en charge requises pour votre trafic.

      transfert du profil de déchiffrement

      profil de déchiffrement entrant

    2. Ajoutez un profil de décryptage.

      Ajout d'un profil de déchiffrement

  6. Créez une règle de décryptage.

    1. Sélectionnez les adresses IP source dans la liste d'adresses IP que vous avez créée dans la stratégie ou choisissez-en une.

    2. Sélectionnez les adresses IP de destination dans la liste d'adresses IP que vous avez créée dans la stratégie ou choisissez-en une.

      Adresse IP de destination

    3. Sélectionnez Action pour décrypter le trafic avec le proxy de transfert SSL, SSL entrant ou sans décryptage.

    4. Choisissez le profil de décryptage et la clé secrète mise en correspondance.

      Choix du profil de cryptage

Une fois la stratégie mise à jour avec la règle de décryptage, elle peut être attachée au pare-feu.

Tâche 2 : attacher une stratégie au pare-feu

Lorsque vous créez le pare-feu réseau, vous pouvez choisir la stratégie à associer au pare-feu.

Pièce jointe NetworkFirewall

Nous avons créé une règle de décryptage pour décrypter le trafic via le proxy de transfert SSL et une autre pour l'inspection entrante SSL. Comme indiqué pour la connexion sortante SSL, tout le trafic provenant de notre sous-réseau public va vers OCI Network Firewall et via OCI Network Firewall, il prend un chemin de la passerelle Internet vers Internet.

Pour l'inspection entrante, elle passe par la passerelle Internet en prenant le HOP suivant comme pare-feu, puis en accédant à notre machine Linux dans le sous-réseau public.

Conformément à la règle de décryptage, pour l'adresse IP source que nous utilisons Hub-Linux-Machine et pour toute adresse IP de destination, le trafic doit être déchiffré par proxy de transfert SSL et pour les connexions entrantes pour la source comme n'importe quel et la destination comme Hub-Linux-Machine, il doit déchiffrer le trafic avec l'inspection entrante SSL.

Règles de cryptage

Remarque : pour tout trafic entrant dans le pare-feu, il vérifie d'abord les règles de décryptage, puis les règles de sécurité.

Question : comment savoir si la règle de décryptage est en place pour que le trafic atteigne le pare-feu ?

Réponse : Vous pouvez l'afficher sur les mesures dont le nom est Nombre d'accès réussis à la règle de décryptage attaché au pare-feu.

Chaque fois que la machine Linux tente d'accéder aux sites Web https sur Internet ou pour toute connexion entrante à la machine Linux sur https, le nombre de succès de la règle de décryptage augmente.

Mesure de pare-feu réseau

Tâche 3 : utiliser la règle de décryptage avec une règle de sécurité pour autoriser ou refuser le trafic

En ajoutant au cas d'emploi ci-dessus, voyons comment la règle de décryptage peut être utilisée avec une règle de sécurité pour autoriser ou refuser le trafic. Comme mentionné au début du scénario de test, nous pourrions utiliser des listes pour autoriser ou refuser le trafic.

Ici, nous avons déjà créé une règle de décryptage pour le proxy de transfert SSL et l'inspection SSL entrante. A des fins de test, nous avons créé une règle de sécurité pour les connexions sortantes de l'ordinateur Hub Linux vers Internet afin d'autoriser l'accès à *.oracle.com.

Remarque : par défaut, l'accès à l'ensemble du trafic est refusé sur le pare-feu OCI Network. Une règle doit être créée pour le trafic qui doit être autorisé.

Liste des URL :

Liste d'URL

Règle de sécurité :

Règle de sécurité

Que se passe-t-il maintenant lorsque la machine Linux tente d'accéder à *.oracle.com sur Internet via le pare-feu OCI Network Firewall.

Question : comment voir quelle règle a lieu pour le trafic ?

Réponse : Elle peut être consultée dans les journaux de pare-feu du réseau OCI.

Pour oracle.com

Journaux de pare-feu réseau 1

Pour toute autre URL :

Journaux de pare-feu réseau 2

Accusés de réception

Auteurs - Luis Catalán Hernández (Spécialiste du réseau OCI Cloud et Multi Cloud), Sachin Sharma (Spécialiste senior du cloud OCI)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenu de formation gratuit sur le canal Oracle Learning YouTube. En outre, accédez à education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation produit, consultez Oracle Help Center.