Note :
- Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Démarrer avec le niveau gratuit d'Oracle Cloud Infrastructure.
- Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments d'Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles qui sont propres à votre environnement en nuage.
Ajout de la sécurité à l'architecture du système de noms de domaine à l'aide du pare-feu pfSense
Présentation
OraStage est une entreprise leader dans le secteur de l'énergie, spécialisée dans les solutions d'énergie renouvelable et les technologies d'énergie innovantes, la société a annoncé une décision stratégique de migrer ses charges de travail vers Oracle Cloud Infrastructure (OCI) afin d'améliorer la performance, l'évolutivité et la sécurité.
Compte tenu des besoins et conditions spécifiques que OraStage a décrits, l'entreprise a besoin d'une solution hybride de système de noms de domaine (DNS) dans le nuage, et par hybride ici signifie : utiliser leur propre système DNS Berkeley Internet Name Domain version 9 (BIND9) en plus du service DNS OCI, où l'architecture finale qu'ils cherchent à créer est affichée dans l'image suivante.
OraStage Exigences relatives au DNS :
-
La société dispose de plusieurs domaines et sous-domaines internes. Tous doivent être résolus par leur DNS BIND9 dans OCI, où OraStage gérera toutes les zones et tous les enregistrements connexes. L'un de ces domaines est
orastage.com
que nous allons utiliser dans ce tutoriel. Ainsi, toute interrogation àorastage.com
doit être transmise à BIND9. -
Ils doivent toujours résoudre les domaines natifs OCI (
oraclevcn.com
,oraclecloud.com
, etc.) dans certains cas, et cela se fera à l'aide de composants DNS privés OCI : vues privées, transfert de points d'extrémité et de règles, et points d'extrémité d'écoute. -
Toutes les interrogations doivent être inspectées par une instance de pare-feu pfSense.
-
Pour éviter un point de défaillance unique, OraStage prévoit d'utiliser un autre serveur DNS et d'exploiter l'équilibreur de charge OCI pour répartir les interrogations entre le DNS principal et le DNS secondaire.
Cette série de tutoriels vous guidera étape par étape pour atteindre les exigences décrites ci-dessus, en construisant l'ensemble de la solution à partir de zéro. Vous pouvez facilement accéder à chaque tutoriel à partir de la liste ci-dessous :
-
Tutoriel 1 : Configurer le DNS BIND9 dans OCI. Voyez 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 constitués de serveurs "Frontend" et "Backend", chacun hébergé dans un réseau satellite distinct. Le serveur BIND9 traitera toutes les interrogations DNS dirigées vers
orastage.com
. -
Tutoriel 2 : Mettre en oeuvre la haute disponibilité dans le scénario DNS BIND9 dans OCI. Ce tutoriel porte sur l'ajout d'un serveur BIND9 secondaire et la configuration d'un équilibreur de charge de réseau (NLB) pour répartir le trafic DNS entre les deux serveurs. Les interrogations DNS vers
orastage.com
seront dirigées vers l'adresse IP de l'équilibreur de charge de réseau, qui permettra d'équilibrer la charge entre les serveurs BIND9 principal et secondaire. Si un serveur devient indisponible, la résolution DNS se poursuivra sans interruption de service. -
Tutoriel 3 : Utiliser le DNS OCI pour résoudre les domaines natifs. Se concentrant uniquement sur un cas d'utilisation spécifique, où 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
etoraclecloud.com
. Le DNS BIND9 n'est pas utilisé dans ce tutoriel. -
Tutoriel 4 : Ajout de la sécurité à l'architecture DNS à l'aide du pare-feu pfSense. Mettre l'accent sur l'installation d'un pare-feu pfSense dans le VCN central dans OCI et effectuer la configuration réseau requise pour acheminer tout le trafic Est-Ouest, y compris les interrogations DNS (effectuées dans les précédents tutoriels) au moyen du pare-feu à inspecter.
Aperçu
Dans ce tutoriel, nous allons explorer comment améliorer la sécurité de notre architecture DNS en tirant parti de pfSense, un pare-feu à code source libre et une plate-forme de routeur.
Le DNS est un composant essentiel de l'infrastructure de réseau, mais il est souvent vulnérable aux attaques telles que l'usurpation de DNS, l'empoisonnement de la mémoire 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 qui garantit 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 politiques de contrôle d'accès pour s'assurer que seul le trafic DNS légitime atteint le serveur, bloquant le trafic potentiellement nocif ou indésirable.
-
-
Protection contre les attaques basées sur DNS
-
Prévention des attaques d'amplification/réflexion du DNS : Les pare-feu peuvent détecter et atténuer les attaques d'amplification du DNS, où les attaquants envoient des demandes usurpées pour submerger le serveur. En limitant ou en limitant le trafic de requêtes DNS, le pare-feu minimise l'impact de telles attaques.
-
Prévention de l'usurpation du DNS : Les pare-feu peuvent bloquer les réponses DNS malveillantes ou malveillantes, qui sont utilisées dans les attaques d'usurpation ou d'empoisonnement du DNS pour détourner 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 limitant les volumes de trafic DNS anormaux, empêchant les attaquants de surcharger votre infrastructure DNS.
-
-
Inspection et journalisation des interrogations DNS
- Le pare-feu peut inspecter les interrogations DNS afin de détecter les modèles suspects, tels que les interrogations pour les domaines malveillants connus. Il peut bloquer ces requêtes avant qu'elles n'atteignent le serveur DNS, ce qui empêche 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 du réglage DNS
- Le tunnelling 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 tunnelling DNS, en fermant un vecteur important de fuite de données.
-
Limitation du 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 la surcharge du serveur DNS. Cela aide à se protéger contre la force brute ou les attaques de requête DNS excessives qui pourraient nuire aux performances ou à la disponibilité du serveur.
-
Segmentation du 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 sur HTTPS (DoH) ou DNS sur TLS (DoT), assurant ainsi le chiffrement du trafic DNS. Cela empêche l'écoute ou l'altération des interrogations et des réponses DNS, protégeant les utilisateurs contre les attaques de type "man-in-the-middle".
-
Réduction de la surface d'attaque
- En cachant l'adresse IP réelle du serveur DNS derrière le pare-feu, vous réduisez son exposition aux attaquants potentiels. Le pare-feu agit en tant qu'intermédiaire, présentant une couche de défense entre l'Internet public et votre infrastructure DNS.
Dans l'ensemble, 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 interrogations DNS, au moyen d'un pare-feu pfSense à inspecter. En outre, nous surveillerons certaines demandes à l'aide de la fonction de capture de paquets du pare-feu.
-
Nous déploierons également 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 en nuage virtuels OCI, en particulier le pare-feu pfSense.
-
À la fin de ce tutoriel, notre objectif est d'établir un modèle d'architecture de réseau en étoile. Cette configuration améliorera la sécurité, rationalisera la gestion du réseau pour OraStage en centralisant le contrôle de routage entre les réseaux via le concentrateur et augmentera l'évolutivité, permettant à l'entreprise d'ajouter de nouveaux réseaux au concentrateur existant à tout moment.
Note :
Ce tutoriel ne couvre pas les capacités de protection contre les attaques spécifiques à DNS. Nous nous concentrons plutôt sur le déploiement du pare-feu pfSense et son intégration à l'environnement existant pour acheminer tout le trafic à travers celui-ci (par exemple, FE-VM vers BE-VM, FE-VM vers DNS-NLB, etc.). Nous allons également montrer comment configurer les règles de contrôle d'accès de base sur le pare-feu.
Vous pouvez toujours suivre ce tutoriel même si vous avez déjà un autre type de solution de pare-feu en place, tel qu'OCI Network Firewall ou un pare-feu de réseau Marketplace comme Palo Alto ou FortiGate, entre autres.
Architecture finale
Préalables
-
Accès à une location OCI et autorisations pour gérer les services de réseau, de calcul et de stockage d'objets requis.
-
Comprendre de base le routage et la sécurité du réseau OCI et leurs fonctionnalités : réseau en nuage virtuel (VCN), table de routage, passerelle de routage dynamique (DRG), liste de sécurité, hôte bastion et équilibreur de charge de réseau OCI.
-
Connaissance de base du DNS en général.
-
Assurez-vous de suivre les tutoriels suivants :
-
Un VCN est requis. Assurez-vous de le créer à l'aide de l'assistant afin d'obtenir tous les composants par défaut requis dans le VCN et de l'attacher à la passerelle DRG. Pour plus d'informations, voir Tâche 1.3 : Attacher des réseaux en nuage virtuels à la passerelle DRG.
- Hub-VCN : Le sous-réseau public hébergera le serveur de saut et le sous-réseau privé hébergera le pare-feu pfSense.
-
Sur la base des préalables ci-dessus, vous avez déjà construit l'architecture suivante.
Tâche 1 : Configurer les composants de routage et de réseau de sécurité
Tâche 1.1 : Créer un réseau en nuage virtuel (Hub-VCN)
Assurez-vous que Hub-VCN (10.4.0.0/16
) est déjà créé, contenant Hub-Private-Subnet (10.4.0.0/24
) et Hub-Public-Subnet (10.4.1.0/24
).
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Réseau.
- Cliquez sur Réseaux en nuage virtuels.
-
Comme nous pouvons voir le VCN en place, assurez-vous de le créer à l'aide de l'assistant. Vous obtiendrez donc les composants suivants par défaut : trois passerelles, un sous-réseau public avec une table de routage et une liste de sécurité qui lui est associée, et un sous-réseau privé avec une table de routage et une liste de sécurité qui lui est associée.
Note :
Désormais, dans certaines parties de la configuration des tables de routage et des listes de sécurité, nous allons agréger 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
), car cela réduira le nombre de règles de gestion plus facile.Dans certains scénarios, dans une topologie en étoile ou en étoile, les réseaux satellites peuvent avoir besoin d'obtenir un accès Internet à partir du réseau central, pour que le trafic passe par le pare-feu pour une meilleure sécurité, c'est pourquoi au niveau des sous-réseaux satellites, nous allons acheminer tout le trafic vers la passerelle DRG. Cependant, dans ce tutoriel, nous ne présentons pas de scénarios d'accès à Internet.
Tâche 1.2 : Configurer le routage et la sécurité pour Hub-VCN
-
Cela doit être fait sur chacun des deux sous-réseaux. Naviguez jusqu'à la page Réseaux en nuage 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 : Pour avoir un accès bidirectionnel à Internet. Nous en avons besoin pour accéder au serveur de saut avec son adresse IP publique.
-
Faisons la sécurité du sous-réseau public. Allez à 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ù.
-
Autoriser 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 avoir un accès unidirectionnel à Internet, pour installer des ensembles ou des correctifs, si nécessaire. Ce n'est pas un composant essentiel à avoir dans ce tutoriel, mais bien de l'avoir si pfSense a besoin d'un accès Internet. -
10.0.0.0/8
- DRG : Achemine le trafic destiné à Frontend-VCN, Backend-VCN, DNS-VCN ou LSN-VCN vers la passerelle DRG, car lorsque le pare-feu est terminé avec l'inspection du trafic, il transmet le trafic autorisé, qui utilisera cette table de routage et l'enverra à la passerelle DRG.
-
-
Faisons la sécurité du sous-réseau privé. Allez à 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.
-
Autoriser tout le trafic sortant.
Tâche 1.3 : Configurer le routage et la sécurité pour LSN-VCN
-
Cela doit être fait au niveau du sous-réseau. Naviguez jusqu'à la page Réseaux en nuage 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
- Passerelle de routage dynamique : Achemine tout le trafic vers la passerelle de routage dynamique, notamment le trafic qui va vers l'un des autres réseaux en nuage virtuels et le trafic qui va vers Internet.
-
Faisons maintenant la sécurité. Allez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.
-
Nous supprimerons toutes les règles de trafic entrant qui autorisent le trafic DNS.
-
Nous remplacerons les règles suivantes uniquement par ces deux règles.
Note : Ne modifiez rien dans les règles de trafic sortant.
Tâche 1.4 : Configurer le routage et la sécurité pour le DNS-VCN
-
Cela doit être fait au niveau du sous-réseau. Naviguez jusqu'à la page Réseaux en nuage 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
- Passerelle de routage dynamique : Achemine tout le trafic vers la passerelle de routage dynamique, notamment le trafic qui va vers l'un des autres réseaux en nuage virtuels et le trafic qui va vers Internet.
-
Faisons maintenant la sécurité. Allez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.
-
Nous supprimerons toutes les règles de trafic entrant qui autorisent le trafic DNS.
-
Nous remplacerons les règles suivantes uniquement par ces deux règles.
Note : Ne modifiez rien dans les règles de trafic sortant.
Tâche 1.5 : Configurer le routage et la sécurité pour le VCN frontal
-
Cela doit être fait au niveau du sous-réseau. Naviguez jusqu'à la page Réseaux en nuage 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
- Passerelle de routage dynamique : Achemine tout le trafic vers la passerelle de routage dynamique, notamment le trafic qui va vers l'un des autres réseaux en nuage virtuels et le trafic qui va 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, cette opération est nécessaire pour conserver la connectivité au service d'hôte bastion OCI, si vous le faites n'ont pas de règle ici pour accéder à Internet ou aux services Oracle. Une erreur est alors survenue avec le plugiciel d'hôte bastion, où vous ne pourrez pas utiliser l'hôte bastion pour accéder à FE-VM.
Note : Ne modifiez rien dans les règles entrantes et sortantes.
-
Tâche 1.6 : Configurer le routage et la sécurité pour le VCN dorsal
-
Cela doit être fait au niveau du sous-réseau. Naviguez jusqu'à la page Réseaux en nuage virtuels et cliquez sur Backend-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
- Passerelle de routage dynamique : Achemine tout le trafic vers la passerelle de routage dynamique, notamment le trafic qui va vers l'un des autres réseaux en nuage virtuels et le trafic qui va 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, cette opération est nécessaire pour conserver la connectivité au service d'hôte bastion OCI, si vous le faites n'ont pas de règle ici pour accéder à Internet ou aux services Oracle. Vous rencontrerez alors une erreur avec le plugiciel d'hôte bastion où vous ne pourrez pas utiliser l'hôte bastion pour accéder à BE-VM.
-
Note : Ne modifiez rien dans les règles entrantes et sortantes.
Tâche 1.7 : Configurer le routage des réseaux en nuage virtuels satellite sur la passerelle 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 la passerelle DRG, soit acheminé vers le concentrateur, où il sera inspecté par le pare-feu.
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Réseau.
- Cliquez sur Passerelle de routage dynamique.
-
Cliquez sur Passerelle DRG.
- Cliquez sur Attachements de réseau VCN. Un attachement de VCN représente un lien qui connecte le VCN à la passerelle DRG pour permettre le trafic réseau entre le VCN et les réseaux externes ou d'autres réseaux en nuage virtuels.
- Vous remarquerez que tous les réseaux en nuage virtuels sont attachés.
- Cliquez sur Table de routage DRG.
- Cliquez sur Créer une table de routage DRG.
- Entrez un nom pour la table de routage.
- Ajouter une règle de routage : Sélectionnez
0.0.0.0/0
et Attachement de VCN central qui achemine tout vers l'attachement de concentrateur. - Cliquez sur Créer une table de routage DRG.
- La table de routage a été créée.
-
Affectez la table de routage à tous les attachements de VCN satellite, en commençant par l'attachement de VCN dorsal et cliquez dessus.
- Cliquez sur Modifier.
- Cliquez sur Voir les options avancées.
- Cliquez sur Table de routage DRG.
- Sélectionnez Spoke-DRG-RT.
- Cliquez sur enregistrer les modifications.
- La table de routage DRG est affectée à l'attachement de VCN dorsal. Maintenant, tout le trafic sortant du réseau dorsalVCN vers la passerelle DRG sera acheminé vers le réseau centralVCN.
-
Répétez les étapes 1 à 6 sur le reste des pièces jointes.
Tâche 2 : Provisionner un serveur de saut 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 à cet effet comprennent :
-
(Obligatoire) Pour accéder au pare-feu pfSense et le gérer au moyen du navigateur (HTTP/S).
-
(Facultatif) Pour accéder à l'instance FE-VM et effectuer le test. Vous pouvez utiliser le service d'hôte bastion OCI ou utiliser ce serveur comme nouvelle zone de saut.
-
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Calculer.
- Cliquez sur Instances.
-
Cliquez sur Créer une instance.
-
Entrez un nom pour l'instance.
- Cliquez sur Modifier l'image.
- Sélectionnez Windows.
- Sélectionnez l'image Windows Server 2016 Standard.
- Sélectionnez cette option pour accepter les conditions d'utilisation.
- Cliquez sur Sélectionner une image.
- Le système d'exploitation de l'instance a été remplacé par Windows Server 2016 Standard.
-
Dans la section Informations sur la carte VNIC principale, entrez les informations suivantes.
- Sélectionnez Hub-VCN.
- Sélectionnez le sous-réseau public afin qu'une adresse IP publique soit affectée à l'instance.
- Affectez à l'instance une adresse IP privée
10.4.1.5
.
- Vous remarquerez une note lors de la création de l'ordinateur Windows, 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.
- Cliquez sur Créer.
-
L'instance de calcul Jump-Server a été créée. Notez les détails suivants, que vous utiliserez lors de l'accès à l'instance.
- Adresse IP publique.
- Nom d'utilisateur.
- Mot de passe initial.
-
Pour accéder au serveur de saut à partir de votre ordinateur personnel Windows, ouvrez Connexion au bureau distant, entrez l'adresse IP publique de l'instance et cliquez sur Connexion.
-
Cliquez sur Oui.
-
Entrez le mot de passe initial fourni dans la page de l'instance et cliquez sur Suivant.
-
Vous devez modifier le mot de passe avant de vous connecter et 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 Suivant.
-
Vous êtes connecté au serveur de secours.
-
L'architecture doit se présenter comme indiqué dans l'image suivante.
Tâche 3 : Installer et configurer le pare-feu pfSense
Note : Si vous avez déjà un autre type de solution de pare-feu en place, vous pouvez ignorer les tâches 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 à partir du site Web Netgate. Assurez-vous de télécharger la version
memstick-serial
. Le nom de fichier de l'image que nous utilisons estpfSense-CE-memstick-serial-2.7.2-RELEASE-amd64.img.gz
. Pour plus d'informations, voir Netgate. -
Le fichier installé sera au format
.gz
. Après l'avoir extrait, vous remarquerez que le nom du fichier d'image estpfSense-CE-memstick-serial-2.7.2-RELEASE-amd64.img
.
Tâche 3.2 : Créer un seau de stockage d'objets OCI
Dans cette tâche, nous allons créer un seau de stockage d'objets OCI qui sera utilisé pour 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.
- Cliquez sur Service de stockage.
- Cliquez sur Seaux.
- Cliquez sur Créer un seau.
- Entrez un nom de seau.
- Sélectionnez Niveau de stockage standard comme Niveau de stockage par défaut.
- Cliquez sur Créer.
-
Notez que le seau de stockage est créé.
Tâche 3.3 : Charger l'image pfSense dans le seau de stockage
-
Allez à la page Détails.
- Dans la page bucket, faites défiler l'affichage vers le bas.
- Cliquez sur Charger.
-
Dans la page Charger les objets, entrez les informations suivantes.
- Cliquez sur sélectionner des fichiers et sélectionnez l'image pfSense.
- Cliquez sur Charger.
-
Pendant que l'image pfSense est en cours de chargement dans le seau de stockage, vous pouvez surveiller la progression.
- Lorsque l'image pfSense est entièrement chargée, le statut de progression est Terminé.
- Cliquez sur Fermer.
Tâche 3.4 : Créer une image personnalisée
Nous avons 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.
- Cliquez sur Calculer.
- Cliquez sur Images personnalisées.
-
Cliquez sur Importer l'image.
-
Dans la page Importer une image, entrez les informations suivantes.
- Entrez un nom.
- Sélectionnez Generic Linux comme système d'exploitation.
- Sélectionnez Importer à partir d'un seau de stockage d'objets.
- Sélectionnez le seau de stockage dans lequel vous avez chargé l'image.
- Dans Nom de l'objet, sélectionnez l'objet que nous avons chargé dans le seau (image pfSense).
- Sélectionnez VMDK comme type d'image.
- Sélectionnez Mode paravirtualisé.
- 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éer une instance avec l'image pfSense personnalisée
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Calculer.
- Cliquez sur Instances.
-
Cliquez sur Créer une instance.
-
Entrez un nom pour l'instance de pare-feu.
- Cliquez sur Modifier l'image.
- Sélectionnez Mes images.
- Cliquez sur Images personnalisées.
- Sélectionnez l'image personnalisée créée dans la tâche 3.4.
- Cliquez sur Sélectionner une image.
- Notez que l'image pfSense est sélectionnée.
-
Dans la section Informations sur la carte VNIC principale, entrez les informations suivantes.
- Sélectionnez Hub-VCN.
- Sélectionnez le sous-réseau privé.
- Affectez à l'instance une adresse IP privée
10.4.0.5
.
- Sélectionnez Aucune clé SSH.
- Cliquez sur Créer.
-
L'instance de calcul du pare-feu pfSense a été créée.
Tâche 3.6 : Installer pfSense sur l'instance
Nous devons procéder à l'installation initiale et à la configuration du 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. Dans la page de l'instance de pare-feu, faites défiler l'affichage vers le bas.
- Cliquez sur Connexion à la console.
- Cliquez sur Lancer la connexion Cloud Shell.
-
Quelques messages de démarrage apparaîtront. Appuyez sur ENTER.
-
Lisez les messages relatifs aux droits d'auteur et sélectionnez Accepter et appuyez sur ENTRER.
- Sélectionnez Installer pfSense.
- Sélectionnez OK et appuyez sur ENTRER.
- Sélectionnez Configuration manuelle du disque (experts).
- Sélectionnez OK et appuyez sur ENTRER.
- Sélectionnez da0 - 47 Go MBR.
- Sélectionnez Créer et appuyez sur ENTRER.
- Dans Type, entrez freebsd.
- Dans Taille, entrez 46 Go.
- Entrez un point de montage.
- Sélectionnez OK et appuyez sur ENTRER.
- Dans da0s4, sélectionnez 46 Go BSD.
- Sélectionnez Créer et appuyez sur ENTRER.
- Dans Type, entrez freebsd-ufs.
- Dans Taille, entrez 40 Go.
- Dans Point de montage, entrez /.
- Sélectionnez OK et appuyez sur ENTRER.
- Notez que le point de montage est créé pour
/
. - Dans da0s4, entrez 46 Go de BSD.
- Sélectionnez Créer et appuyez sur ENTRER.
- Dans Type, entrez freebsd-swap.
- Dans Taille, entrez 5670 Mo.
- Entrez un point de montage.
- Sélectionnez OK et appuyez sur ENTRER.
- Notez que le point de montage est créé pour le swap.
- Sélectionnez Terminer et appuyez sur Entrer.
-
Sélectionnez Valider et appuyez sur Entrer.
-
Sélectionnez Redémarrer et appuyez sur ENTRER.
-
Après le premier redémarrage, vous obtiendrez quelques options de configuration pour configurer l'interface WAN. Pour S'il faut configurer des VLANS, entrez n et appuyez sur ENTRER.
-
Pour 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, de sorte que nous ne configurerons pas l'interface LAN. Par conséquent, pour Entrer le nom de l'interface LAN ou 'a' pour la détection automatique, appuyez sur ENTRER pour ignorer cette configuration d'interface.
- Vérifiez le nom de l'interface WAN.
- Pour Voulez-vous continuer, entrez y et appuyez sur ENTRER.
-
Notez certains messages et la configuration sera effectuée. Le système d'exploitation pfSense effectuera un démarrage complet.
- Vous verrez que l'adresse IP sera configurée à l'aide de DHCP.
- 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 : Se connecter à l'interface utilisateur graphique Web pfSense et terminer la configuration initiale
L'installation est terminée, nous devons maintenant nous connecter à l'interface graphique Web du pare-feu pfSense. Mais avant cela, assurez-vous d'autoriser le trafic HTTP/HTTPS provenant de Hub-Public-Subnet, car nous allons nous connecter à l'interface graphique du pare-feu à partir du serveur de saut placé là-bas. Nous avons déjà autorisé tout le trafic de tous les réseaux en nuage virtuels (10.0.0.0/8
) à passer par le pare-feu dans la tâche 1.2.
-
Entrez l'adresse IP du pare-feu pfSense.
- Dans l'instance Windows, ouvrez un navigateur et naviguez jusqu'à l'adresse IP du pare-feu pfSense à l'aide de HTTPS.
- Cliquez sur Avancé.
-
Cliquez sur Continuer.
- Entrez le nom d'utilisateur par défaut
admin
. - Entrez le mot de passe par défaut
pfsense
. - Cliquez sur Connexion.
- Entrez le nom d'utilisateur par défaut
-
Cliquez sur Suivant.
-
Cliquez sur Suivant.
- Entrer un nom d'hôte.
- Entrez un nom de domaine ou conservez le nom de domaine par défaut.
- Faites défiler vers le bas et cliquez sur Suivant.
-
Cliquez sur Suivant.
Note : Dans ce cas particulier, Oracle réserve l'adresse IP statique dans son serveur DHCP et affecte cette adresse au pare-feu pfSense. Ainsi, le pare-feu pfSense obtiendra toujours la même adresse IP, mais du point de vue OCI, il s'agira d'une adresse IP statique, et du point de vue pfSense, il s'agira d'une adresse DHCP.
- Dans la section Configurer l'interface WAN, sélectionnez DHCP.
- Faites défiler l'affichage vers le bas et conservez tout le reste comme valeur par défaut, puis cliquez sur Suivant.
- Entrez un nouveau mot de passe d'administrateur.
- Entrez Mot de passe de l'administrateur encore.
- Cliquez sur Suivant.
-
Cliquez sur Recharger.
-
Notez que la configuration du 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 peut pas atteindre Internet, le chargement de la page de tableau de bord prend un peu plus de temps. Mais cela peut être corrigé en permettant à pfSense d'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 en nuage virtuels et DRG, de manière à forcer tout le trafic envoyé à partir des rayons, à entrer dans le réseau central (flèche verte). Cette tâche explique comment acheminer tout ce trafic vers le pare-feu pfSense (flèche rouge).
Pour ce faire, nous créerons une table de routage de trafic entrant (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 la passerelle DRG, afin que le trafic entrant dans le concentrateur soit acheminé vers une destination spécifique de votre choix (pare-feu pfSense dans notre scénario).
-
Naviguez jusqu'à l'instance de pare-feu pfSense.
- Cliquez sur Calculer.
- Cliquez sur Instances.
-
Cliquez sur Pare-feu.
-
Faire défiler vers le bas.
- Cliquez sur Cartes vNIC attachées.
- Cliquez sur les trois points.
- Cliquez sur Modifier la carte VNIC.
- Sélectionnez Ignorer la vérification de la source/destination. Si vous avez manqué cette étape, vous rencontrerez un problème lors de la création de la règle de routage.
- Cliquez sur enregistrer les modifications.
-
Naviguez jusqu'à la page Réseaux en nuage virtuels et entrez Hub-VCN.
-
Faire défiler vers le bas.
- Cliquez sur Tables de routage.
- Cliquez sur Créer une table de routage.
- Entrez un nom pour la table de routage.
- Cliquez sur Autre règle de routage.
- Sélectionnez Adresse IP privée comme type de cible.
- Entrez
0.0.0.0/0
dans Bloc CIDR de destination. - Entrez l'adresse IP privée de pfSense.
- Cliquez sur Créer.
- La table de routage a été créée. Nous devons maintenant l'affecter.
-
Naviguez jusqu'à la page DRG et cliquez sur Attachement de VCN central.
-
Cliquez sur Modifier.
-
Cliquez sur Voir les options avancées.
- Cliquez sur Table de routage de VCN.
- Dans Associer une table de routage, sélectionnez Sélectionner une table existante.
- Sélectionnez la table de routage que nous avons créée.
- Cliquez sur enregistrer les modifications.
-
La table de routage de VCN a été affectée.
Note : Dans l'attachement de passerelle DRG, vous pouvez affecter deux types de table de routage :
- Table de routage DRG : Celle que nous avons créée pour les attachements satellite dans la tâche 1.7. Cette table sera vérifiée chaque fois que le trafic est envoyé hors de l'attachement VCN.
- Table de routage de 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 du 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é par pfSense pour inspection en premier. Maintenant, que se passe-t-il si nous effectuons un test rapide en envoyant une commande ping BE-VM à partir de FE-VM?
Comme vous l'avez observé, pfSense bloquera tout le trafic qui passe 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 fonctions de pfSense.
-
Règles d'accès : Permettez ou refusez le trafic en fonction du protocole, du numéro de port, de l'adresse source et de l'adresse de destination.
-
Saisie de paquets : 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 la mise en œuvre 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. Comme la concentration de cette série de tutoriels est sur DNS, les règles que nous ajouterons seront spécifiquement liées au trafic DNS (basées sur Natif et BIND9). Maintenant, naviguez jusqu'à l'interface de gestion Web pfSense.
- Cliquez sur Pare-feu.
- Cliquez sur Règles.
-
Notez les règles par défaut du pare-feu pfSense.
Première règle (facultatif) :
-
Détails de la connexion.
- Source : Jump-Server (
10.4.1.5
). - Destination : FE-VM (
10.1.0.5
). - Protocole : SSH.
- Numéro de port :
22
. - Action : Transmettre.
- Justification : Nous voulons accéder à FE-VM à partir du serveur de secours. Il s'agit d'une règle facultative, car vous pouvez toujours utiliser l'hôte bastion pour vous connecter.
- Source : Jump-Server (
-
Cliquez sur Ajouter.
- Sélectionnez Action pour Réussir.
- Sélectionnez Protocole pour TCP.
- Entrez l'adresse source à
10.4.1.5
. - Entrez l'adresse de destination dans
10.1.0.5
. - Entrez Port de destination dans
22
. - Cliquez sur Enregistrer.
- Cliquez sur appliquer les modifications.
- Un message s'affiche pour indiquer que les modifications ont été appliquées.
- La règle est ajoutée.
Deuxième règle :
-
Détails de la connexion.
- Source : FE-VM (
10.1.0.5
). - Destination : BE-VM (
10.2.0.5
). - Protocole : ICMP.
- Action : Transmettre.
- Justification : À des fins de test, nous devons activer FE-VM pour effectuer une commande ping BE-VM.
- Source : FE-VM (
-
Cliquez sur Ajouter.
- Sélectionnez Action pour Réussir.
- Sélectionnez Protocole pour ICMP et Sous-type pour n'importe quel.
- Entrez l'adresse source à
10.1.0.5
. - Entrez l'adresse de destination dans
10.2.0.5
. - Cliquez sur Enregistrer.
- Cliquez sur appliquer les modifications.
- Un message s'affiche pour indiquer que les modifications ont été appliquées.
- La règle est ajoutée.
Troisième règle :
-
Détails de la connexion.
- Source : aval de Frontend-VCN (
10.1.0.6
). - Destination : LSN (
10.3.0.6
). - Protocoles : TCP et UDP.
- Numéro de port :
53
. - Action : Transmettre.
- Justification : Nous voulons que FE-VM puisse résoudre BE-VM (
be-vm.beprivatesubnet.backendvcn.oraclevcn.com
). Pour cela, FWD de Frontend-VCN doit pouvoir interroger le module d'écoute. Le trafic DNS doit donc être autorisé.
- Source : aval de Frontend-VCN (
-
Cliquez sur Ajouter.
- Sélectionnez Action pour Réussir.
- Sélectionnez Protocole pour TCP/UDP.
- Entrez l'adresse source à
10.1.0.6
. - Entrez l'adresse de destination dans
10.3.0.6
. - Entrez Port de destination dans
53
. - Cliquez sur Enregistrer.
- Cliquez sur appliquer les modifications.
- Un message s'affiche pour indiquer que les modifications ont été appliquées.
- La règle est ajoutée.
Quatrième règle :
-
Détails de la connexion.
- Source : aval de Frontend-VCN (
10.1.0.6
). - Destination : DNS-NLB (
10.0.0.110
). - Protocoles : TCP et UDP.
- Numéro de port :
53
. - Action : Transmettre.
- Justification : Nous voulons que FE-VM puisse résoudre BE-VM (
be.orastage.com
). Pour cela, FWD de Frontend-VCN doit pouvoir interroger DNS-NLB qui enverra le trafic à l'un des serveurs DNS BIND9 dorsaux. Le trafic DNS doit donc être autorisé.
- Source : aval de Frontend-VCN (
-
Cliquez sur Ajouter.
- Sélectionnez Action pour Réussir.
- Sélectionnez Protocole pour TCP/UDP.
- Entrez l'adresse source à
10.1.0.6
. - Entrez l'adresse de destination dans
10.0.0.110
. - Entrez Port de destination dans
53
. - Cliquez sur Enregistrer.
- Cliquez sur appliquer les modifications.
- Un message s'affiche pour indiquer que les modifications ont été appliquées.
- La règle est ajoutée.
Cinquième règle :
-
Détails de la connexion.
- Source : Transfert de Backend-VCN (
10.2.0.6
). - Destination : LSN (
10.3.0.6
). - Protocoles : TCP et UDP.
- Numéro de port :
53
. - Action : Transmettre.
- Justification : Nous voulons que BE-VM puisse résoudre FE-VM (
fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com
). Pour cela, FWD de Backend-VCN doit pouvoir interroger le module d'écoute. Le trafic DNS doit donc être autorisé.
Note : Répétez les étapes effectuées dans la troisième règle, mais cette fois, la source est différente, ce qui est en avant de Backend-VCN (
10.2.0.6
). - Source : Transfert de Backend-VCN (
Sixième règle :
-
Détails de la connexion.
- Source : Transfert de Backend-VCN (
10.2.0.6
). - Destination : DNS-NLB (
10.0.0.110
). - Protocoles : TCP et UDP.
- Numéro de port :
53
. - Action : Transmettre.
- Justification : Nous voulons que BE-VM puisse résoudre FE-VM (
fe.orastage.com
). Pour cela, Backend-VCN doit pouvoir interroger DNS-NLB qui enverra le trafic à l'un des serveurs DNS BIND9 dorsaux. Le trafic DNS doit donc être autorisé.
Note : Répétez les étapes effectuées dans la quatrième règle, mais cette fois, la source est différente, ce qui est en avant de Backend-VCN (
10.2.0.6
). - Source : Transfert de Backend-VCN (
Tâche 4 : Tester et valider
-
Nous effectuerons uniquement des tests à partir de l'instance FE-VM.
Note : (Facultatif) Nous allons utiliser le serveur de vidage Windows pour vous connecter à FE-VM, vous pouvez toujours vous connecter au moyen d'un hôte bastion si c'est ce que vous préférez.
- Copiez la clé privée que nous avons utilisée dans OCI Cloud Shell à partir des tutoriels précédents dans l'instance Windows.
- Installez OpenSSH sur le serveur. Pour plus d'informations, voir Technique : Installer OpenSSH SFTP sur Windows Server 2016.
- Exécutez la commande SSH.
- Nous nous sommes connectés à l'instance FE-VM.
Scénario de test 1
-
Tester les domaines natifs
*.oraclevcn.com
. L'ordinateur client FE-VM doit pouvoir résoudrebe-vm.beprivatesubnet.backendvcn.oraclevcn.com
. Nous avons déjà autorisé ce trafic dans pfSense. Dans ce test, nous utiliserons la fonction Saisie de paquets dans pfSense pour nous assurer que le trafic le traverse. -
Trafic en aval :
-
Trafic de réponse :
-
Accédez à pfSense à partir de l'ordinateur Windows.
- Cliquez sur Diagnostics.
- Cliquez sur Saisie de paquets.
- Remplissez l'adresse IP source (FWD - 10.1.0.6) et l'adresse IP de destination (LSN - 10.3.0.6).
- Entrez
53
comme numéro de port. - Cliquez sur Commencer.
- Vous pouvez surveiller le trafic DNS allant de FWD à LSN.
-
À partir de FE-VM, commande ping pour le domaine natif BE-VM
be-vm.beprivatesubnet.backendvcn.oraclevcn.com
. -
Dans Saisie de paquet, vous remarquerez que chaque fois que nous lui envoyons une commande ping, une interrogation est effectuée.
-
Modifiez le filtre pour surveiller le trafic ping.
-
Trafic en aval :
-
Trafic de réponse :
- Remplissez l'adresse IP source (FE-VM - 10.1.0.5) et l'adresse IP de destination (BE-VM - 10.2.0.5).
- Entrez Protocole comme ICMPv4.
- Cliquez sur Commencer.
- Vous pouvez surveiller le trafic ping allant de FE-VM à BE-VM.
-
À partir de FE-VM, effectuez une autre commande ping vers BE-VM
be-vm.beprivatesubnet.backendvcn.oraclevcn.com
. -
Dans Saisie de paquet, vous remarquerez le trafic ping.
-
Faites défiler l'affichage 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 saisies pour démarrer une autre saisie.
Note : Vous pouvez suivre les mêmes étapes lors du test, mais dans la direction opposée, 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
. L'ordinateur client FE-VM doit pouvoir résoudrebe.orastage.com
. Nous avons déjà autorisé ce trafic dans pfSense. Dans ce test, nous utiliserons la fonction Saisie de paquets dans pfSense pour nous assurer que le trafic le traverse. -
Trafic en aval :
-
Trafic de réponse :
-
Accédez à pfSense à partir du serveur de saut.
- Cliquez sur Diagnostics.
- Cliquez sur Saisie de paquets.
- Remplissez l'adresse IP source (FWD - 10.1.0.6) et l'adresse IP de destination (DNS-NLB - 10.0.0.110).
- Entrez
53
comme numéro de port. - Cliquez sur Commencer.
- Vous pouvez surveiller le trafic DNS allant de FWD à DNS-NLB.
-
À partir de FE-VM, commande ping pour le domaine BE-VM
be.orastage.com
. -
Dans Saisie de paquet, vous remarquerez que chaque fois que nous lui envoyons une commande ping, une interrogation est effectuée.
-
Modifiez le filtre pour surveiller le trafic ping.
-
Trafic en aval :
-
Trafic de réponse :
- Remplissez l'adresse IP source (FE-VM - 10.1.0.5) et l'adresse IP de destination (BE-VM - 10.2.0.5).
- Entrez Protocole comme ICMPv4.
- Cliquez sur Commencer.
- Vous pouvez surveiller le trafic ping allant de FE-VM à BE-VM.
-
À partir de FE-VM, effectuez une autre commande ping vers BE-VM
be.orastage.com
. -
Dans Saisie de paquet, vous remarquerez le trafic ping.
-
Faites défiler l'affichage 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 saisies, car nous avons terminé le test.
Note : Vous pouvez suivre les mêmes étapes lors du test, mais dans la direction opposée, 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 de défense cruciale 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 s'assurer que ses 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 appuyé sur le dernier, ce qui vous donne une base solide dans OCI tout en vous appuyant sur une approche d'apprentissage progressif. Ces compétences vous aideront à gérer et à optimiser votre infrastructure infonuagique efficacement :
- Configurer le routage et la sécurité du réseau en nuage virtuel (VCN).
- définition d'une passerelle de routage dynamique;
- Configurez et utilisez l'hôte bastion OCI pour accéder aux instances privées.
- Configurez et utilisez un serveur de saut Windows pour accéder aux instances privées.
- Installer et configurer la solution DNS BIND9 dans OCI.
- Configurer et utiliser l'équilibreur de charge de réseau OCI pour une haute disponibilité.
- Configurer et utiliser les composants DNS privés d'OCI pour résoudre les domaines natifs.
- Installez et configurez le pare-feu pfSense dans OCI, en l'intégrant dans une architecture en étoile.
Remerciements
- Auteur - Anas abdallah (spécialiste du réseau en nuage)
Autres ressources d'apprentissage
Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour obtenir la documentation sur le produit, visitez Oracle Help Center.
Adding Security to the Domain Name System Architecture using pfSense Firewall
G19396-02
Copyright ©2025, Oracle and/or its affiliates.