Remarques :

• Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction à Oracle Cloud Infrastructure Free Tier.
• Il utilise des exemples de valeurs pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. Lorsque vous terminez votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Ajout de la sécurité à l'architecture du système de noms de domaine à l'aide du pare-feu pfSense

Introduction

OraStage est une entreprise leader dans le secteur de l'énergie, spécialisée dans les solutions d'énergies renouvelables et les technologies énergétiques innovantes, elle a annoncé une décision stratégique de migrer ses workloads vers Oracle Cloud Infrastructure (OCI) pour améliorer les performances, l'évolutivité et la sécurité.

Compte tenu des besoins et des conditions spécifiques décrits par OraStage, l'entreprise a besoin d'une solution hybride de système de noms de domaine (DNS) dans le cloud, et par voie hybride ici signifie : utiliser leur propre système DNS de domaine de noms Internet Berkeley version 9 (BIND9) en plus du service DNS OCI, où l'architecture finale qu'ils cherchent à créer est présentée dans l'image suivante.

OraStage Exigences relatives au DNS :

• L'entreprise dispose de plusieurs domaines et sous-domaines internes, qui doivent tous être résolus par leur DNS BIND9 dans OCI, où OraStage gérera toutes les zones et tous les enregistrements associés. L'un de ces domaines est orastage.com que nous allons utiliser dans ce tutoriel. Par conséquent, toute requête vers orastage.com doit être transmise à son répertoire BIND9.

• Ils doivent encore résoudre les domaines natifs OCI (oraclevcn.com, oraclecloud.com, etc.) dans certains cas, ce qui sera fait à l'aide des composants DNS privés OCI : vues privées, transmission des adresses et des règles, et adresses d'écoute.

• Toutes les requêtes doivent être inspectées par une instance de pare-feu pfSense.

• Pour éviter un point d'échec unique, OraStage prévoit d'utiliser un autre serveur DNS et d'utiliser OCI Load Balancer pour distribuer les requêtes entre le DNS principal et le DNS secondaire.

Cette série de tutoriels vous guidera pas à pas pour répondre aux exigences décrites ci-dessus et créer la solution complète à partir de zéro. Vous pouvez facilement accéder à chaque tutoriel à partir de la liste ci-dessous :

• Tutoriel 1 : Configuration du DNS BIND9 dans OCI. Découvrez comment installer et configurer BIND9 sur une instance de calcul, ce qui en fait le serveur DNS local pour deux environnements de test dans OCI. Ces environnements seront composés de serveurs "Frontend" et "Backend", chacun hébergé dans un réseau satellite distinct. Le serveur BIND9 traitera toutes les requêtes DNS dirigées vers orastage.com.

• Tutoriel 2 : Implémentation de la haute disponibilité sur le scénario DNS BIND9 dans OCI. Ce tutoriel se concentre sur l'ajout d'un serveur BIND9 secondaire et la configuration d'un équilibreur de charge réseau (NLB) pour distribuer le trafic DNS entre les deux serveurs. Les requêtes DNS vers orastage.com seront dirigées vers l'adresse IP de l'équilibreur de charge réseau, qui équilibrera la charge entre les serveurs BIND9 principal et secondaire. Si un serveur devient indisponible, la résolution DNS se poursuit sans interruption de service.

• Tutoriel 3 : Utilisation d'OCI DNS pour résoudre des domaines natifs. Se concentrer uniquement sur un cas d'emploi spécifique, dans lequel nous utilisons des composants DNS natifs dans OCI, au cas où il serait nécessaire de résoudre des domaines natifs tels que oraclevcn.com et oraclecloud.com. BIND9 DNS n'est pas utilisé dans ce tutoriel.

• Tutoriel 4 : Ajout de la sécurité à l'architecture DNS à l'aide du pare-feu pfSense. Se concentrer sur l'installation d'un pare-feu pfSense dans le VCN hub dans OCI et effectuer la configuration réseau requise pour acheminer tout le trafic Est-Ouest, y compris les requêtes DNS (effectuées dans les tutoriels précédents) via le pare-feu à inspecter.

Présentation

Dans ce tutoriel, nous allons explorer comment améliorer la sécurité de notre architecture DNS en tirant parti de pfSense, un pare-feu open source et une plate-forme de routeur.

Le DNS est un composant essentiel de l'infrastructure réseau, mais il est souvent vulnérable aux attaques telles que l'usurpation de données DNS, l'empoisonnement du cache et le déni de service distribué (DDoS). En intégrant pfSense aux mesures de sécurité DNS, vous pouvez ajouter une couche de protection robuste, garantissant ainsi la sécurité et la résilience du trafic DNS de votre réseau. Il est donc recommandé de configurer votre pare-feu de manière à filtrer les requêtes DNS, à bloquer les domaines malveillants et à renforcer l'intégrité globale du DNS.

Quel est l'avantage supplémentaire de placer un pare-feu pfSense devant un serveur DNS ?

• Filtrage du trafic et contrôle d'accès

  • Le pare-feu peut restreindre l'accès à votre serveur DNS, autorisant uniquement les adresses IP autorisées ou des réseaux spécifiques à envoyer des requêtes DNS. Cela empêche les utilisateurs ou systèmes non autorisés d'interroger ou d'exploiter le serveur.

  • Il peut appliquer des stratégies de contrôle d'accès pour garantir que seul le trafic DNS légitime atteint le serveur, bloquant ainsi le trafic potentiellement dangereux ou indésirable.

• Protection contre les attaques basées sur DNS

  • Prévention des attaques d'amplification/réflexion DNS : les pare-feu peuvent détecter et atténuer les attaques d'amplification DNS, où les attaquants envoient des demandes usurpées pour submerger le serveur. En limitant ou en limitant le trafic des requêtes DNS, le pare-feu minimise l'impact de ces attaques.

  • Prévention de l'usurpation de DNS : les pare-feu peuvent bloquer les réponses DNS malveillantes ou malveillantes, qui sont utilisées dans les attaques d'usurpation de DNS ou d'empoisonnement pour rediriger les utilisateurs vers des sites Web frauduleux.

  • DDoS Atténuation : les pare-feu fournissent des mécanismes de défense contre les attaques par déni de service distribué (DDoS) en surveillant et en ralentissant les volumes de trafic DNS anormaux, empêchant les attaquants de surcharger votre infrastructure DNS.

• Inspection et journalisation des requêtes DNS

  • Le pare-feu peut inspecter les requêtes DNS à la recherche de modèles suspects, tels que les requêtes pour les domaines malveillants connus. Il peut bloquer ces requêtes avant qu'elles n'atteignent le serveur DNS, ce qui contribue à empêcher l'accès à des sites dangereux.
  • Les journaux de requêtes DNS peuvent être enregistrés à des fins d'audit, ce qui vous permet de détecter les comportements anormaux ou d'enquêter plus efficacement sur les incidents de sécurité potentiels.

• Prévention des tunnels DNS

  • Le tunneling DNS est une technique utilisée par les attaquants pour exfiltrer les données ou communiquer avec des systèmes compromis via des requêtes DNS. Un pare-feu peut détecter et bloquer les activités de tunnel DNS, fermant ainsi un vecteur important de fuite de données.

• Limitation de débit et protection des ressources

  • Le pare-feu peut limiter le nombre de demandes DNS provenant d'une source unique (limitation du débit), empêchant ainsi la surcharge du serveur DNS. Cela permet de se protéger contre la force brute ou les attaques de requêtes DNS excessives qui pourraient dégrader les performances ou la disponibilité du serveur.

• Segmentation réseau

  • En plaçant le serveur DNS derrière un pare-feu, vous pouvez l'isoler dans un segment de réseau protégé (par exemple, DMZ), en vous assurant que même si le serveur DNS est compromis, l'accès de l'attaquant au reste de votre réseau est restreint.

• Prise en charge des protocoles DNS sécurisés

  • Les pare-feu peuvent appliquer des protocoles DNS sécurisés tels que DNS via HTTPS (DoH) ou DNS via TLS (DoT), garantissant ainsi le cryptage du trafic DNS. Cela empêche l'écoute ou l'altération des requêtes et réponses DNS, protégeant les utilisateurs contre les attaques man-in-the-middle.

• Réduire la surface d'attaque

  • En masquant l'adresse IP réelle du serveur DNS derrière le pare-feu, vous réduisez son exposition aux pirates potentiels. Le pare-feu agit comme un intermédiaire, présentant une couche de défense entre l'Internet public et votre infrastructure DNS.

Dans l'ensemble, le fait de placer un pare-feu devant votre serveur DNS améliore la sécurité, les performances et la résilience du serveur en empêchant les accès non autorisés, en détectant le trafic malveillant et en offrant une protection robuste contre un large éventail de menaces liées au DNS.

Objectifs

• L'objectif principal de ce tutoriel est d'acheminer tout le trafic Est-Ouest, y compris les requêtes DNS, via un pare-feu pfSense à inspecter. En outre, nous surveillerons certaines demandes à l'aide de la fonctionnalité de capture de paquets du pare-feu.

• Nous allons également déployer un serveur de saut Windows public, qui servira de point d'accès pour la gestion d'autres instances privées dans les réseaux cloud virtuels OCI, en particulier le pare-feu pfSense.

• À la fin de ce tutoriel, notre objectif est d'établir un modèle d'architecture réseau hub & spoke. Cette configuration améliorera la sécurité, rationalisera la gestion du réseau pour OraStage en centralisant le contrôle du routage entre les réseaux via le hub et augmentera l'évolutivité, permettant à l'entreprise d'ajouter de nouveaux réseaux au hub existant à tout moment.

Remarque :

• Ce tutoriel ne couvre pas les capacités de protection contre les attaques spécifiques au DNS. Au lieu de cela, notre objectif est de déployer le pare-feu pfSense et de l'intégrer à l'environnement existant pour acheminer tout le trafic via celui-ci (par exemple, FE-VM vers BE-VM, FE-VM vers DNS-NLB, etc.). Nous allons également montrer comment configurer des règles de contrôle d'accès de base sur le pare-feu.

• Vous pouvez toujours suivre ce tutoriel même si vous disposez déjà d'un autre type de solution de pare-feu en place, comme OCI Network Firewall ou un pare-feu réseau Marketplace comme Palo Alto ou FortiGate, entre autres.

Architecture finale

Prérequis

• Accès à une location OCI et droits d'accès permettant de gérer les services de réseau, de calcul et de stockage d'objets requis.

• Compréhension de base du routage et de la sécurité du réseau OCI et de leurs fonctionnalités : réseau cloud virtuel (VCN), table de routage, passerelle de routage dynamique (DRG), liste de sécurité, bastion et équilibreur de charge réseau OCI.

• Compréhension de base du DNS en général.

• Veillez à réaliser les tutoriels suivants :

  1. Configurez le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure.
  2. Implémentez la haute disponibilité sur le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure.
  3. Utilisation d'Oracle Cloud Infrastructure DNS pour résoudre des domaines natifs.

• Un VCN est requis, assurez-vous de le créer avec l'assistant afin que vous obteniez tous les composants par défaut nécessaires au sein du VCN et que vous le joigniez au DRG. Pour plus d'informations, reportez-vous à Tâche 1.3 : attacher des réseaux cloud virtuels au DRG.

  • Hub-VCN : le sous-réseau public hébergera le serveur Jump et le sous-réseau privé hébergera le pare-feu pfSense.

• En fonction des prérequis ci-dessus, vous devez avoir déjà créé l'architecture suivante.

Tâche 1 : configurer les composants réseau de routage et de sécurité

Tâche 1.1 : création d'un réseau cloud virtuel (Hub-VCN)

Assurez-vous que le Hub-VCN (10.4.0.0/16) est déjà créé, contenant le Hub-Private-Subnet (10.4.0.0/24) et le Hub-Public-Subnet (10.4.1.0/24).

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Fonctions de réseau.
  2. Cliquez sur Réseaux cloud virtuels.

  

• Nous pouvons voir le VCN en place, comme mentionné, assurez-vous de le créer à l'aide de l'assistant, de sorte que vous obtiendrez les composants suivants par défaut : trois passerelles, un sous-réseau public avec une table de routage et une liste de sécurité attachée à elle, et un sous-réseau privé avec une table de routage et une liste de sécurité attachée à elle.

Remarque :

• Désormais, au sein de certaines parties de la configuration des tables de routage et des listes de sécurité, nous allons regrouper tous les réseaux : DNS-VCN (10.0.0.0/16), Frontend-VCN (10.1.0.0/16), Backend-VCN (10.2.0.0/16), LSN-VCN (10.3.0.0/16), Hub-VCN (10.4.0.0/16), en un seul bloc d'adresses (10.0.0.0/8), juste pour faciliter la gestion, car cela réduira le nombre de règles.

• Dans certains scénarios, au sein d'une topologie hub et spoke, les réseaux spoke peuvent avoir besoin d'obtenir un accès Internet à partir du réseau hub, afin que le trafic passe par le pare-feu pour une meilleure sécurité. C'est pourquoi, au niveau des sous-réseaux spoke, nous allons acheminer tout le trafic vers le DRG. Cependant, dans ce tutoriel, nous ne montrons pas de scénarios d'accès à Internet.

Tâche 1.2 : configuration du routage et de la sécurité pour Hub-VCN

• Cette opération doit être effectuée sur chacun des deux sous-réseaux. Accédez à la page des réseaux cloud virtuels et cliquez sur Hub-VCN.

  

• Nous allons commencer par le sous-réseau public, cliquez dessus.

  

• Cliquez sur Table de routage, qui est une table de routage affectée.

• Ajoutez la règle suivante.

  • 0.0.0.0/0 - Passerelle Internet : permet d'avoir un accès bidirectionnel à Internet. Nous en avons besoin pour accéder au serveur Jump avec son adresse IP publique.

  

• Assurons la sécurité du sous-réseau public. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.

• Autoriser le trafic entrant : trafic RDP (TCP/port 3389) depuis n'importe où.

  

• Autorisez tout le trafic sortant.

  

• Revenez à la page VCN et cliquez sur le sous-réseau privé.

  

• Cliquez sur Table de routage, qui est une table de routage affectée.

• Ajoutez les règles suivantes.

  • 0.0.0.0/0 - Passerelle NAT : pour disposer d'un accès unidirectionnel à Internet, pour installer des packages ou des patches si nécessaire. Ce n'est pas un composant essentiel à avoir dans ce tutoriel, mais il est bon de l'avoir si pfSense a besoin d'un accès Internet.

  • 10.0.0.0/8 - DRG : acheminez le trafic destiné à Frontend-VCN, Backend-VCN, DNS-VCN ou LSN-VCN vers le DRG, car lorsque le pare-feu est terminé avec l'inspection du trafic, il transmet le trafic autorisé, qui utilise cette table de routage et l'envoie au DRG.

  

• Assurons la sécurité du sous-réseau privé. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.

  

• Autoriser le trafic entrant : tous les types de trafic provenant de Frontend-VCN, Backend-VCN, DNS-VCN et LSN-VCN.

  

• Autorisez tout le trafic sortant.

  

Tâche 1.3 : configuration du routage et de la sécurité pour LSN-VCN

• Cette opération doit être effectuée au niveau du sous-réseau. Accédez à la page des réseaux cloud virtuels et cliquez sur LSN-VCN.

  

• Cliquez sur le sous-réseau privé.

  

• Cliquez sur Table de routage, qui est une table de routage affectée.

  

• Nous supprimerons toutes les règles.

  

• Nous remplacerons toutes les règles suivantes par une seule règle.

  • 0.0.0.0/0 - DRG : acheminez tout le trafic vers le DRG, y compris le trafic vers l'un des autres réseaux cloud virtuels et le trafic vers Internet.

  

• Faisons la sécurité maintenant. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.

  

• Nous supprimerons toutes les règles entrantes qui autorisent le trafic DNS.

  

• Nous remplacerons les règles suivantes par ces deux seules règles.

  

  Remarque : ne modifiez rien dans les règles sortantes.

Tâche 1.4 : configuration du routage et de la sécurité pour DNS-VCN

• Cette opération doit être effectuée au niveau du sous-réseau. Accédez à la page des réseaux cloud virtuels et cliquez sur DNS-VCN.

  

• Cliquez sur le sous-réseau privé.

  

• Cliquez sur Table de routage, qui est une table de routage affectée.

  

• Nous supprimerons toutes les règles suivantes.

  

• Nous remplacerons les règles suivantes par une seule règle.

  • 0.0.0.0/0 - DRG : acheminez tout le trafic vers le DRG, y compris le trafic vers l'un des autres réseaux cloud virtuels et le trafic vers Internet.

  

• Faisons la sécurité maintenant. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.

  

• Nous supprimerons toutes les règles entrantes qui autorisent le trafic DNS.

  

• Nous remplacerons les règles suivantes par ces deux seules règles.

  

  Remarque : ne modifiez rien dans les règles sortantes.

Tâche 1.5 : configuration du routage et de la sécurité pour le VCN frontal

• Cette opération doit être effectuée au niveau du sous-réseau. Accédez à la page des réseaux cloud virtuels et cliquez sur Frontend-VCN.

  

• Cliquez sur le sous-réseau privé.

  

• Cliquez sur Table de routage, qui est une table de routage affectée.

  

• Nous supprimerons toutes les règles suivantes.

  

• Nous remplacerons les règles suivantes par ces deux règles.

  • 0.0.0.0/0 - DRG : acheminez tout le trafic vers le DRG, y compris le trafic vers l'un des autres réseaux cloud virtuels et le trafic vers Internet.

  • Tous les services LIN dans Oracle Services Network - Passerelle de service : pour fournir l'accès aux services Oracle dans la région de Milan, cela est nécessaire pour conserver la connectivité avec le service OCI Bastion, si vous ne le faites pas Ici, vous disposez d'une règle permettant d'accéder aux services Internet ou Oracle. Vous serez alors confronté à une erreur avec le module d'extension de bastion, dans lequel vous ne pourrez pas utiliser le bastion pour accéder à FE-VM.

  

  Remarque : ne modifiez rien dans les règles entrantes et sortantes.

Tâche 1.6 : configuration du routage et de la sécurité pour le back-end VCN

• Cette opération doit être effectuée au niveau du sous-réseau. Accédez à la page des réseaux cloud virtuels et cliquez sur VCN de back-end.

  

• Cliquez sur le sous-réseau privé.

  

• Cliquez sur Table de routage, qui est une table de routage affectée.

  

• Nous supprimerons toutes les règles suivantes.

  

• Nous remplacerons les règles suivantes par ces deux règles.

  • 0.0.0.0/0 - DRG : acheminez tout le trafic vers le DRG, y compris le trafic vers l'un des autres réseaux cloud virtuels et le trafic vers Internet.

  • Tous les services LIN dans Oracle Services Network - Passerelle de service : pour fournir l'accès aux services Oracle dans la région de Milan, cela est nécessaire pour conserver la connectivité avec le service OCI Bastion, si vous ne le faites pas Ici, vous disposez d'une règle permettant d'accéder aux services Internet ou Oracle. Vous serez alors confronté à une erreur avec le module d'extension de bastion, dans lequel vous ne pourrez pas utiliser le bastion pour accéder à BE-VM.

  

Remarque : ne modifiez rien dans les règles entrantes et sortantes.

Tâche 1.7 : configurer le routage des réseaux cloud virtuels spoke sur DRG

Le but de cette tâche est de s'assurer que tout le trafic envoyé à partir de l'un des réseaux (DNS/LSN/Frontend/Backend) et reçu sur le DRG, soit acheminé vers le hub, où il sera inspecté par le pare-feu.

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Fonctions de réseau.
  2. Cliquez sur Passerelle de routage dynamique.

  

• Cliquez sur DRG.

  

  1. Cliquez sur Pièces jointes VCN. Une attachement VCN représente une liaison qui connecte le VCN au DRG pour permettre le trafic réseau entre le VCN et des réseaux externes ou d'autres réseaux cloud virtuels.
  2. Vous remarquerez que tous les réseaux cloud virtuels sont attachés.

  

  1. Cliquez sur Tables de routage DRG.
  2. Cliquez sur Créer une table de routage DRG.
  3. Entrez le nom de la table de routage.
  4. Ajouter une règle de routage : sélectionnez 0.0.0.0/0 et Attachement VCN du hub qui achemine tous les éléments vers l'attachement du hub.
  5. Cliquez sur Créer une table de routage DRG.
  6. La table de routage a été créée.

  

  

  

• Affectez la table de routage à toutes les pièces jointes du VCN spoke, en commençant par la pièce jointe du VCN back-end et en cliquant dessus.

  

  1. Cliquez sur Modifier.
  2. Cliquez sur Afficher les options avancées.
  3. Cliquez sur Table de routage DRG.
  4. Sélectionnez Spoke-DRG-RT.
  5. Cliquez sur Enregistrer les modifications.
  6. La table de routage DRG est affectée à l'attachement VCN de back-end. Désormais, tout le trafic sortant du back-end-VCN vers le DRG sera acheminé vers le Hub-VCN.

  

  

  

• Répétez les étapes 1 à 6 sur le reste des pièces jointes.

  

Tâche 2 : provisionnement d'un serveur Jump Windows

• Dans cette tâche, nous allons provisionner une nouvelle instance de calcul Windows et l'utiliser pour nous connecter à d'autres ressources privées. Les utilisations prévues sont les suivantes :

  • (Obligatoire) Permet d'accéder au pare-feu pfSense et de le gérer via le navigateur (HTTP/S).

  • (Facultatif) Pour accéder à l'instance FE-VM et effectuer le test. Vous pouvez utiliser le service OCI Bastion ou utiliser ce serveur comme nouvelle zone de saut.

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

• Cliquez sur Créer une instance.

  

• Saisissez un nom pour l'instance.

  

  1. Cliquez sur Modifier l'image.
  2. Sélectionnez Windows.
  3. Sélectionnez l'image Windows Server 2016 Standard.
  4. Sélectionnez cette option pour accepter les conditions d'utilisation.
  5. Cliquez sur Sélectionner une image.
  6. Le système d'exploitation de l'instance a été remplacé par Windows Server 2016 Standard.

  

  

  

• Dans la section Informations sur la carte d'interface réseau virtuelle principale, entrez les informations suivantes.

  1. Sélectionnez Hub-VCN.
  2. Sélectionnez le sous-réseau public de sorte qu'une adresse IP publique soit affectée à l'instance.
  3. Affectez à l'instance une adresse IP privée 10.4.1.5.

  

  

  1. Lors de la création de l'ordinateur Windows, vous verrez une note indiquant qu'un mot de passe initial sera généré après la création de l'instance. La différence est avec le système d'exploitation Linux, les clés SSH sont utilisées pour l'authentification.
  2. Cliquez sur Créer.

  

• L'instance de calcul Jump-Server a été créée. Notez les détails suivants. Vous les utiliserez lors de l'accès à l'instance.

  1. Adresse IP publique.
  2. Nom utilisateur.
  3. Mot de passe initial.

  

• Pour accéder au serveur de vidage à partir de votre ordinateur personnel Windows, ouvrez Connexion au bureau à distance, entrez l'adresse IP publique de l'instance et cliquez sur Connecter.

  

• Cliquez sur Oui.

  

• Entrez le mot de passe initial fourni sur la page de l'instance et cliquez sur Suivant.

  

• Vous devez modifier le mot de passe avant de vous connecter et de cliquer sur OK.

  

• Entrez votre nouveau mot de passe à deux reprises.

  

• Le mot de passe a été modifié. Cliquez sur OK pour continuer.

  

• Entrez votre nouveau mot de passe et cliquez sur Next.

  

• Vous êtes connecté au serveur de vidage.

  

• L'architecture doit se présenter comme indiqué dans l'image suivante.

  

Tâche 3 : installer et configurer le pare-feu pfSense

Remarque : si vous disposez déjà d'un autre type de solution de pare-feu, vous pouvez ignorer la tâche 3.1 à 3.7 et passer de la version 3.8.

Tâche 3.1 : télécharger l'image pfSense

• Téléchargez l'image pfSense sur le site Web de Netgate. Veillez à télécharger la version memstick-serial. Le nom de fichier de l'image que nous utilisons est pfSense-CE-memstick-serial-2.7.2-RELEASE-amd64.img.gz. Pour plus d'informations, reportez-vous à Netgate.

  

• Le fichier installé sera au format .gz. Après l'avoir extraite, vous remarquerez que le nom du fichier image est pfSense-CE-memstick-serial-2.7.2-RELEASE-amd64.img.

  

Tâche 3.2 : création d'un bucket OCI Object Storage

Dans cette tâche, nous allons créer un bucket OCI Object Storage qui sera utilisé pour télécharger l'image pfSense et utiliser cette image d'objet pour créer une image personnalisée dans OCI.

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Stockage.
  2. Cliquez sur Buckets.

  

  1. Cliquez sur Créer un bucket.
  2. Saisissez le nom de la catégorie.
  3. Sélectionnez Niveau de stockage standard comme Niveau de stockage par défaut.
  4. Cliquez sur Créer.

  

  

• Le bucket de stockage est créé.

  

Tâche 3.3 : téléchargement de l'image pfSense vers le bucket de stockage

• Accédez à la page Détails du bucket.

  1. Faites défiler la page Bucket vers le bas.
  2. Cliquez sur Charger.

  

• Sur la page Télécharger des objets, entrez les informations suivantes.

  1. Cliquez sur Sélectionner des fichiers et sélectionnez l'image pfSense.
  2. Cliquez sur Charger.

  

• Pendant le téléchargement de l'image pfSense dans le bucket de stockage, vous pouvez surveiller la progression.

  

  1. Lorsque l'image pfSense est entièrement téléchargée, le statut de progression est Terminé.
  2. Cliquez sur Fermer.

  

Tâche 3.4 : création d'une image personnalisée

Nous avons téléchargé l'image pfSense. Maintenant, nous devons créer une image personnalisée OCI à partir de celle-ci. Cette image personnalisée sera utilisée pour créer l'instance de pare-feu pfSense.

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Images personnalisées.

  

• Cliquez sur Importer l'image.

• Sur la page Importer une image, entrez les informations suivantes.

  1. Entrez un nom.
  2. Sélectionnez Generic Linux en tant que système d'exploitation.
  3. Sélectionnez Importer à partir d'un bucket Object Storage.
  4. Sélectionnez le bucket de stockage dans lequel vous avez téléchargé l'image.
  5. Dans Nom d'objet, sélectionnez l'objet que nous avons téléchargé vers le bucket (image pfSense).
  6. Sélectionnez VMDK comme type d'image.
  7. Sélectionnez Mode paravirtualisé.
  8. Cliquez sur Importer l'image.

  

  

• L'image personnalisée est IMPORTING.

  

• Au bout de quelques minutes, le statut est DISPONIBLE.

  

Tâche 3.5 : création d'une instance à l'aide de l'image pfSense personnalisée

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

• Cliquez sur Créer une instance.

  

• Entrez le nom de l'instance de pare-feu.

  

  1. Cliquez sur Modifier l'image.
  2. Sélectionnez Mes images.
  3. Cliquez sur Images personnalisées.
  4. Sélectionnez l'image personnalisée créée dans la tâche 3.4.
  5. Cliquez sur Sélectionner une image.
  6. L'image pfSense est sélectionnée.

  

  

  

• Dans la section Informations sur la carte d'interface réseau virtuelle principale, entrez les informations suivantes.

  1. Sélectionnez Hub-VCN.
  2. Sélectionnez le sous-réseau privé.
  3. Affectez à l'instance une adresse IP privée 10.4.0.5.

  

  

  1. Sélectionnez No SSH Keys.
  2. Cliquez sur Créer.

  

• L'instance de calcul de pare-feu pfSense a été créée.

  

Tâche 3.6 : installer pfSense sur l'instance

Nous devons effectuer l'installation initiale et configurer le pare-feu pfSense. Nous avons déjà l'instance en cours d'exécution.

• Pour installer le logiciel de pare-feu pfSense, nous devons créer une connexion à la console. Faites défiler la page de l'instance de pare-feu vers le bas.

  1. Cliquez sur Connexion à la console.
  2. Cliquez sur Lancer une connexion Cloud Shell.

  

• Quelques messages de démarrage apparaîtront. Appuyez sur Entrée.

  

• Lisez les messages de copyright, sélectionnez Accept et appuyez sur ENTER.

  

  1. Sélectionnez Installer pfSense.
  2. Sélectionnez OK et appuyez sur Entrée.

  

  1. Sélectionnez Configuration manuelle du disque (experts).
  2. Sélectionnez OK et appuyez sur Entrée.

  

  1. Sélectionnez da0 - 47 Go MBR.
  2. Sélectionnez Créer et appuyez sur Entrée.

  

  1. Dans Type, entrez freebsd.
  2. Dans Taille, entrez 46 Go.
  3. Entrez Mountpoint.
  4. Sélectionnez OK et appuyez sur Entrée.

  

  1. Dans da0s4, sélectionnez 46 Go BSD.
  2. Sélectionnez Créer et appuyez sur Entrée.

  

  1. Dans Type, entrez freebsd-ufs.
  2. Dans Taille, entrez 40 Go.
  3. Dans Point de montage, entrez /.
  4. Sélectionnez OK et appuyez sur Entrée.

  

  1. Le point de montage est créé pour /.
  2. Dans da0s4, entrez 46 Go BSD.
  3. Sélectionnez Créer et appuyez sur Entrée.

  

  1. Dans Type, entrez freebsd-swap.
  2. Dans Taille, entrez 5670 Mo.
  3. Entrez Mountpoint.
  4. Sélectionnez OK et appuyez sur Entrée.

  

  1. Notez que le point de montage est créé pour le swap.
  2. Sélectionnez Terminer et appuyez sur Entrée.

  

• Sélectionnez Valider et appuyez sur Entrée.

  

  

• Sélectionnez Redémarrer et appuyez sur Entrée.

  

• Après la première réinitialisation, vous obtiendrez quelques options de configuration pour configurer l'interface WAN. Pour Faut-il configurer VLANS, saisissez n et appuyez sur Entrée.

  

• Dans Entrez le nom de l'interface WAN ou 'a' pour la détection automatique (vtnet0 ou a), entrez vtnet0.

  

• Dans cette configuration, nous créons un pare-feu avec une seule interface. Nous ne configurerons donc pas l'interface LAN. Par conséquent, pour Saisir le nom de l'interface LAN ou 'a' pour la détection automatique, appuyez sur Entrée pour ignorer la configuration de cette interface.

  

  1. Vérifiez le nom de l'interface WAN.
  2. Pour Voulez-vous continuer, entrez y et appuyez sur Entrée.

  

• Notez certains messages et la configuration sera effectuée. L'O/S pfSense effectue une initialisation complète.

  1. Vous verrez que l'adresse IP sera configurée à l'aide de DHCP.
  2. Notez le menu pfSense pour effectuer une configuration de base supplémentaire.

  

• L'architecture doit se présenter comme indiqué dans l'image suivante.

  

Tâche 3.7 : connexion à l'interface utilisateur graphique Web (GUI) pfSense et exécution de la configuration initiale

L'installation est terminée, nous devons maintenant nous connecter à l'interface graphique Web du pare-feu pfSense. Mais avant cela, veillez à autoriser le trafic HTTP/HTTPS provenant de Hub-Public-Subnet, car nous allons nous connecter à l'interface graphique du pare-feu à partir du Jump-Server qui y est placé. Nous avons déjà autorisé tout le trafic de tous les réseaux cloud virtuels (10.0.0.0/8) à passer par le pare-feu dans la tâche 1.2.

• Entrez l'adresse IP de pare-feu pfSense.

  1. Dans l'instance Windows, ouvrez un navigateur et accédez à l'adresse IP de pare-feu pfSense à l'aide de HTTPS.
  2. Cliquez sur Avancé.

  

• Cliquez sur Continuer.

  

  1. Entrez le nom utilisateur par défaut admin.
  2. Entrez le mot de passe par défaut pfsense.
  3. Cliquez sur Connexion.

  

• Cliquez sur Suivant.

  

• Cliquez sur Suivant.

  

  1. Entrez un nom d'hôte.
  2. Entrez un nom de domaine ou conservez le nom de domaine par défaut.
  3. Faites défiler vers le bas et cliquez sur Next.

  

• Cliquez sur Suivant.

  

  Remarque : dans ce cas particulier, Oracle réserve l'adresse IP statique dans son serveur DHCP et affecte cette adresse au pare-feu pfSense. Par conséquent, le pare-feu pfSense obtient toujours la même adresse IP, mais du point de vue OCI, il s'agit d'une adresse IP statique, et du point de vue pfSense, il s'agit d'une adresse DHCP.

  1. Dans la section Configurer l'interface WAN, sélectionnez DHCP.
  2. Faites défiler l'affichage vers le bas et conservez tout le reste comme valeur par défaut, puis cliquez sur Suivant.

  

  1. Entrez un nouveau mot de passe d'administrateur.
  2. Entrez Mot de passe d'administrateur à nouveau.
  3. Cliquez sur Suivant.

  

• Cliquez sur Recharger.

  

• La configuration de pare-feu pfSense est en cours de rechargement.

  

• Faites défiler vers le bas et cliquez sur Terminer.

  

• Cliquez sur accepter.

  

• Cliquez sur Fermer.

  

  Si le pare-feu pfSense ne parvient pas à atteindre Internet, le chargement de la page de tableau de bord prend un peu plus de temps. Toutefois, cela peut être corrigé en autorisant pfSense à accéder à Internet à l'aide de la passerelle NAT OCI, ce que nous avons déjà fait dans la tâche 1.2. Dans cette image, notez que pfSense est installé et que le tableau de bord est visible.

  

Tâche 3.8 : acheminer le trafic vers le pare-feu pfSense

Dans la tâche 1, nous avons configuré le routage sur nos réseaux cloud virtuels et DRG, de manière à forcer tout le trafic envoyé par les rayons à entrer dans le réseau hub (flèche verte). Cette tâche explique comment acheminer tout ce trafic vers le pare-feu pfSense (flèche rouge).

Pour ce faire, nous allons créer une table de routage entrante (table de routage de transit). Il s'agit essentiellement d'une table de routage que vous créez au niveau du VCN, mais que vous l'affectez dans le DRG, de sorte que le trafic entrant dans le hub sera acheminé vers une destination spécifique de votre choix (pare-feu pfSense dans notre scénario).

• Accédez à l'instance de pare-feu pfSense.

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

• Cliquez sur Pare-feu.

  

• Défiler vers le bas.

  1. Cliquez sur VNIC attachées.
  2. Cliquez sur les trois points.
  3. Cliquez sur Modifier la carte d'interface réseau virtuelle.
  4. Sélectionnez Ignorer la vérification de source/destination. Si vous avez manqué cette étape, vous rencontrerez un problème lors de la création de la règle de routage.
  5. Cliquez sur Enregistrer les modifications.

  

  

• Accédez à la page des réseaux cloud virtuels et entrez Hub-VCN.

  

• Défiler vers le bas.

  1. Cliquez sur Tables de routage.
  2. Cliquez sur Créer une table de routage.
  3. Entrez le nom de la table de routage.
  4. Cliquez sur Autre règle de routage.
  5. Sélectionnez Adresse IP privée dans Type de cible.
  6. Entrez 0.0.0.0/0 dans Bloc CIDR de destination.
  7. Entrez l'adresse IP privée de pfSense.
  8. Cliquez sur Créer.
  9. La table de routage a été créée. Nous devons maintenant l'affecter.

  

  

  

  

• Accédez à la page DRG et cliquez sur Pièce jointe VCN du hub.

  

• Cliquez sur Modifier.

  

• Cliquez sur Afficher les options avancées.

  

  1. Cliquez sur Table de routage VCN.
  2. Dans Associer la table de routage, sélectionnez Sélectionner une table de routage existante.
  3. Sélectionnez la table de routage que nous avons créée.
  4. Cliquez sur Enregistrer les modifications.

  

• La table de routage VCN a été affectée avec succès.

  

  Remarque : au niveau de la pièce jointe DRG, vous pouvez affecter deux types de table de routage :

  1. Table de routage DRG : celle que nous avons créée pour les attachements spoke dans la tâche 1.7. Cette table sera vérifiée à chaque fois que le trafic est envoyé en dehors de l'attachement VCN.
  2. Table de routage VCN : celle que nous avons créée dans cette tâche 3.8. Cette table sera vérifiée lors de la réception du trafic et de l'arrivée dans l'attachement VCN.

• À ce stade, nous avons terminé toutes les configurations liées à OCI, en nous assurant que le trafic entre deux ressources de cette architecture est acheminé via pfSense pour inspection en premier. Maintenant, et si nous faisions un test rapide en envoyant un ping à BE-VM à partir de FE-VM, cela devrait-il fonctionner ?

  

  Comme vous l'avez observé, pfSense bloquera tout le trafic entrant jusqu'à ce que vous l'autorisiez explicitement, ce que nous allons faire dans la tâche à venir.

Tâche 3.9 : autoriser le trafic à passer par pfSense

Dans ce tutoriel, nous allons tirer parti de deux fonctionnalités de pfSense.

• Règles d'accès : autorisez ou refusez le trafic en fonction du protocole, du numéro de port, de l'adresse source et de l'adresse de destination.

• Capture de paquet : appliquez un filtre basé sur les adresses IP, le type de paquet, le numéro de port, etc. pour analyser le trafic entrant et sortant au niveau du paquet que le pare-feu inspectera.

Gardez à l'esprit que vous pouvez faire beaucoup plus avec pfSense, mais notre objectif ici est davantage d'installer pfSense dans OCI et de l'intégrer à notre architecture réseau existante avec l'implémentation du routage et de la sécurité appropriés dans OCI.

• Dans cette tâche, nous allons autoriser le trafic qui sera nécessaire dans certains de nos scénarios. Etant donné que la concentration de cette série de tutoriels est sur le DNS, les règles que nous ajouterons concerneront spécifiquement le trafic DNS (basé sur Native et BIND9). Accédez à présent à l'interface de gestion Web pfSense.

  1. Cliquez sur Pare-feu.
  2. Cliquez sur Règles.

  

• Notez les règles par défaut du pare-feu pfSense.

  

Première règle (facultatif) :

• Détails de connexion.

  • Source : Jump-Server (10.4.1.5).
  • Destination : FE-VM (10.1.0.5).
  • Protocole : SSH.
  • Numéro de port : 22.
  • Action : passez.
  • Justification : nous voulons accéder à FE-VM à partir du serveur de vidage. Il s'agit d'une règle facultative, car vous pouvez toujours utiliser le bastion pour vous connecter.

• Cliquez sur Ajouter.

  

  1. Sélectionnez Action pour Transmettre.
  2. Sélectionnez Protocole sur TCP.
  3. Entrez Adresse source dans 10.4.1.5.
  4. Entrez Adresse de destination dans 10.1.0.5.
  5. Entrez Port de destination dans 22.
  6. Cliquez sur Enregistrer.
  7. Cliquez sur Appliquer les modifications.
  8. Un message apparaît pour indiquer que les modifications ont été appliquées avec succès.
  9. La règle est ajoutée.

  

  

  

  

Deuxième règle :

• Détails de connexion.

  • Source : FE-VM (10.1.0.5).
  • Destination : BE-VM (10.2.0.5).
  • Protocole : ICMP.
  • Action : passez.
  • Justification : à des fins de test, nous devons activer FE-VM pour envoyer la commande ping à BE-VM.

• Cliquez sur Ajouter.

  

  1. Sélectionnez Action pour Transmettre.
  2. Sélectionnez Protocole sur ICMP et Sous-type sur any.
  3. Entrez Adresse source dans 10.1.0.5.
  4. Entrez Adresse de destination dans 10.2.0.5.
  5. Cliquez sur Enregistrer.
  6. Cliquez sur Appliquer les modifications.
  7. Un message apparaît pour indiquer que les modifications ont été appliquées avec succès.
  8. La règle est ajoutée.

  

  

  

  

Troisième règle :

• Détails de connexion.

  • Source : avant de Frontend-VCN (10.1.0.6).
  • Destination : LSN (10.3.0.6).
  • Protocoles : TCP et UDP.
  • Numéro de port : 53.
  • Action : passez.
  • Justification : nous voulons que FE-VM puisse résoudre le problème BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com). Pour cela, l'avant de Frontend-VCN doit pouvoir interroger le processus d'écoute. Le trafic DNS doit donc être autorisé.

• Cliquez sur Ajouter.

  

  1. Sélectionnez Action pour Transmettre.
  2. Sélectionnez Protocole sur TCP/UDP.
  3. Entrez Adresse source dans 10.1.0.6.
  4. Entrez Adresse de destination dans 10.3.0.6.
  5. Entrez Port de destination dans 53.
  6. Cliquez sur Enregistrer.
  7. Cliquez sur Appliquer les modifications.
  8. Un message apparaît pour indiquer que les modifications ont été appliquées avec succès.
  9. La règle est ajoutée.

  

  

  

  

Quatrième règle :

• Détails de connexion.

  • Source : avant de Frontend-VCN (10.1.0.6).
  • Destination : DNS-NLB (10.0.0.110).
  • Protocoles : TCP et UDP.
  • Numéro de port : 53.
  • Action : passez.
  • Justification : nous voulons que FE-VM puisse résoudre le problème BE-VM (be.orastage.com). Pour cela, l'avant de Frontend-VCN doit pouvoir interroger le DNS-NLB qui enverra le trafic à l'un des serveurs DNS BIND9 back-end. Le trafic DNS doit donc être autorisé.

• Cliquez sur Ajouter.

  

  1. Sélectionnez Action pour Transmettre.
  2. Sélectionnez Protocole sur TCP/UDP.
  3. Entrez Adresse source dans 10.1.0.6.
  4. Entrez Adresse de destination dans 10.0.0.110.
  5. Entrez Port de destination dans 53.
  6. Cliquez sur Enregistrer.
  7. Cliquez sur Appliquer les modifications.
  8. Un message apparaît pour indiquer que les modifications ont été appliquées avec succès.
  9. La règle est ajoutée.

  

  

  

  

Cinquième règle :

• Détails de connexion.

  • Source : avant de Backend-VCN (10.2.0.6).
  • Destination : LSN (10.3.0.6).
  • Protocoles : TCP et UDP.
  • Numéro de port : 53.
  • Action : passez.
  • Justification : nous voulons que BE-VM puisse résoudre FE-VM (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com). Pour cela, l'avant de Backend-VCN doit pouvoir interroger le processus d'écoute. Le trafic DNS doit donc être autorisé.

  Remarque : répétez les étapes effectuées dans la troisième règle, mais cette fois, la source est différente, ce qui correspond à l'avance de Backend-VCN (10.2.0.6).

Sixième règle :

• Détails de connexion.

  • Source : avant de Backend-VCN (10.2.0.6).
  • Destination : DNS-NLB (10.0.0.110).
  • Protocoles : TCP et UDP.
  • Numéro de port : 53.
  • Action : passez.
  • Justification : nous voulons que BE-VM puisse résoudre FE-VM (fe.orastage.com). Pour cela, l'avant de Backend-VCN doit pouvoir interroger le DNS-NLB qui enverra le trafic à l'un des serveurs DNS BIND9 back-end. Le trafic DNS doit donc être autorisé.

  Remarque : répétez les étapes effectuées dans la quatrième règle, mais cette fois, la source est différente, ce qui correspond à l'avance de Backend-VCN (10.2.0.6).

Tâche 4 : tester et valider

• Nous effectuerons le test uniquement à partir de l'instance FE-VM.

  Remarque : (facultatif) nous allons utiliser le serveur de vidage Windows pour nous connecter à FE-VM, vous pouvez toujours vous connecter via le bastion si c'est ce que vous préférez.

  1. Copiez la clé privée que nous avons utilisée dans OCI Cloud Shell à partir des tutoriels précédents dans l'instance Windows.
  2. Installez OpenSSH sur le serveur. Pour plus d'informations, reportez-vous à Technique : installation de OpenSSH SFTP sur Windows Server 2016.
  3. Exécutez la commande SSH.
  4. Nous nous sommes connectés à l'instance FE-VM.

  

Scénario de test 1

• Testez les domaines natifs *.oraclevcn.com. La machine client FE-VM doit pouvoir résoudre be-vm.beprivatesubnet.backendvcn.oraclevcn.com. Nous avons déjà autorisé ce trafic dans pfSense. Dans ce test, nous allons utiliser la fonctionnalité Packet Capture dans pfSense pour nous assurer que le trafic y passe.

• Trafic aval :

  

• Trafic de réponse :

  

• Accédez à pfSense à partir de l'ordinateur Windows.

  1. Cliquez sur Diagnostics.
  2. Cliquez sur Capture de paquet.
  3. Renseignez l'adresse IP source (FWD - 10.1.0.6) et l'adresse IP de destination (LSN - 10.3.0.6).
  4. Entrez 53 en tant que numéro de port.
  5. Cliquez sur Démarrer.
  6. Vous pouvez surveiller le trafic DNS passant de FWD à LSN.

  

  

  

• A partir de FE-VM, envoyez une commande ping au domaine natif BE-VM be-vm.beprivatesubnet.backendvcn.oraclevcn.com.

  

• Dans Packet Capture, vous remarquerez à chaque fois que nous envoyons un ping à une requête.

  

• Modifiez le filtre pour surveiller le trafic ping.

• Trafic aval :

  

• Trafic de réponse :

  

  1. Renseignez l'adresse IP source (FE-VM - 10.1.0.5) et l'adresse IP de destination (BE-VM - 10.2.0.5).
  2. Entrez Protocol sous ICMPv4.
  3. Cliquez sur Démarrer.
  4. Vous pouvez surveiller le trafic ping passant de FE-VM à BE-VM.

  

  

• A partir de FE-VM, effectuez un autre ping vers BE-VM be-vm.beprivatesubnet.backendvcn.oraclevcn.com.

  

• Dans Packet Capture, vous remarquerez le trafic ping.

  

• Faites défiler vers le haut et cliquez sur Arrêter pour arrêter la capture de paquets lorsque vous avez terminé le test.

  

• Cliquez sur Effacer les captures pour lancer une autre capture.

  

  Remarque : vous pouvez suivre les mêmes étapes dans le test, mais dans le sens inverse, de BE-VM à FE-VM fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com. Le trafic est déjà autorisé pour ce scénario.

Scénario de test 2

• Testez le domaine géré BIND9 de la société *.orastage.com. La machine client FE-VM doit pouvoir résoudre be.orastage.com. Nous avons déjà autorisé ce trafic dans pfSense. Dans ce test, nous utiliserons la fonctionnalité de capture de paquets dans pfSense pour nous assurer que le trafic le traverse.

• Trafic aval :

  

• Trafic de réponse :

  

• Accédez à pfSense à partir du serveur Jump.

  1. Cliquez sur Diagnostics.
  2. Cliquez sur Capture de paquet.
  3. Renseignez l'adresse IP source (FWD - 10.1.0.6) et l'adresse IP de destination (DNS-NLB - 10.0.0.110).
  4. Entrez 53 en tant que numéro de port.
  5. Cliquez sur Démarrer.
  6. Vous pouvez surveiller le trafic DNS passant de FWD à DNS-NLB.

  

  

  

• A partir de FE-VM, envoyez une commande ping au domaine BE-VM be.orastage.com.

  

• Dans Packet Capture, vous remarquerez à chaque fois que nous envoyons un ping à une requête.

  

• Modifiez le filtre pour surveiller le trafic ping.

• Trafic aval :

  

• Trafic de réponse :

  

  1. Renseignez l'adresse IP source (FE-VM - 10.1.0.5) et l'adresse IP de destination (BE-VM - 10.2.0.5).
  2. Entrez Protocol sous ICMPv4.
  3. Cliquez sur Démarrer.
  4. Vous pouvez surveiller le trafic ping passant de FE-VM à BE-VM.

  

  

• A partir de FE-VM, effectuez un autre ping vers BE-VM be.orastage.com.

  

• Dans Packet Capture, vous remarquerez le trafic ping.

  

• Faites défiler vers le haut et cliquez sur Arrêter pour arrêter la capture de paquets lorsque vous avez terminé le test.

  

• Cliquez sur Effacer les captures une fois le test terminé.

  

  Remarque : vous pouvez suivre les mêmes étapes dans le test, mais dans le sens inverse, de BE-VM à FE-VM fe.orastage.com. Le trafic est déjà autorisé pour ce scénario.

Conclusion

Félicitations ! Nous sommes enfin arrivés à la fin de notre parcours DNS.

Dans ce tutoriel, nous avons mis l'accent sur l'amélioration de l'architecture DNS d'OraStage avec pfSense, qui fournit une couche cruciale de défense contre une variété d'attaques et de vulnérabilités basées sur DNS. En filtrant le trafic, en appliquant des protocoles DNS sécurisés et en bloquant les domaines malveillants, OraStage peut garantir que leurs serveurs DNS fonctionnent de manière sécurisée et efficace.

Tout au long de la série, vous avez acquis des compétences importantes dans OCI. Chaque tutoriel s'est construit sur le dernier, vous donnant une base solide dans OCI tout en vous appuyant sur une approche d'apprentissage progressive. Ces compétences vous aideront à gérer et optimiser efficacement votre infrastructure cloud :

• Configurez le routage et la sécurité du réseau cloud virtuel (VCN).
• Configurez une passerelle de routage dynamique (DRG).
• Configurez et utilisez OCI Bastion pour accéder aux instances privées.
• Configurer et utiliser un serveur Jump Windows pour accéder aux instances privées.
• Installez et configurez la solution DNS BIND9 dans OCI.
• Configurez et utilisez OCI Network Load Balancer pour la haute disponibilité.
• Configurez et utilisez les composants DNS privés OCI pour résoudre les domaines natifs.
• Installez et configurez le pare-feu pfSense dans OCI, en l'intégrant dans une architecture hub & spoke.

Remerciements

• Auteur : Anas abdallah (spécialiste du réseau cloud)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation produit, consultez le site Oracle Help Center.

---

Informations relatives au titre et au copyright

<

Adding Security to the Domain Name System Architecture using pfSense Firewall

G19397-02

Copyright ©2025, Oracle and/or its affiliates.