introduction
Les pare-feu DigitalOcean Cloud offrent un service de pare-feu puissant au niveau du réseau, laissant ainsi vos serveurs libres de servir leurs applications et de stocker vos données. Dans ce didacticiel, nous allons adapter une configuration Wordpress et MySQL à deux serveurs pour utiliser Cloud Firewalls, et démontrer certains des avantages que ce service peut offrir. Si vous souhaitez plus d'informations sur ce service de pare-feu avant de commencer, veuillez lire notre tutorielIntroduction To DigitalOcean Cloud Firewalls.
Conditions préalables
Avant de commencer ce didacticiel, vous devez avoir créé l'infrastructure décrite dansHow To Set Up a Remote Database to Optimize Site Performance with MySQL on Ubuntu 16.04. Cela vous laissera avec deux serveurs, un serveur Web Nginx avec PHP et WordPress installés et un serveur MySQL autonome. Tout au long de ce tutoriel, nous appellerons respectivement ces serveursfrontend-01 etdatabase-01.
Notre situation actuelle du pare-feu
À l'heure actuelle, nos deux serveurs ont des pare-feu configurés à l'aide de l'utilitaireufw. ufw est un wrapper facile à utiliser autour du moteur de pare-feu iptables de Linux. Connectez-vous maintenant aux deux serveurs et vérifiez l’état de nos pare-feu:
Tout d'abord, sur le serveur Web,frontend-01:
sudo ufw status verboseOutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp (OpenSSH) ALLOW IN Anywhere
80,443/tcp (Nginx Full) ALLOW IN Anywhere
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)Dans la sortie, aprèsDefault:, on nous montre que le pare-feu refuse, par défaut, toutes les connexions entrantes et autorise toutes les connexions sortantes. De plus, nous avons quatre règles qui autorisent les connexions TCP IPv4 et IPv6 entrantes (ALLOW IN) aux ports 22 (SSH), 80 (HTTP) et 443 (HTTPS).
Faisons la même chose sur le serveur de base de données,database-01:
sudo ufw status verboseOutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp (OpenSSH) ALLOW IN Anywhere
3306 ALLOW IN Anywhere
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
3306 (v6) ALLOW IN Anywhere (v6)Cette sortie est similaire, sauf que nous avons échangé les deux ports Nginx contre le port 3306, qui est le port MySQL standard. Maintenant que nous connaissons notre configuration actuelle, planifions notre remplacement.
Notre plan de pare-feu cloud
Bien que nous puissions simplement créer deux pare-feu cloud, l'un adapté à chaque serveur spécifique, et appliquer l'un àfrontend-01 et l'autre àdatabase-01, nous allons adopter une approche plus flexible pour organiser nos règles. .
Premièrement, nous voulons nous préparer à un avenir dans lequel nous devrons peut-être ajouter un troisième type de service à ce système (peut-être un serveur de cache). Nous allons donc diviser nos règles de pare-feu en fonction des rôles et non par serveur physique. Nous pouvons appliquer plusieurs pare-feu Cloud à chaque Droplet, il n’est donc pas gênant de rendre ces pare-feu fins et modulaires.
[.note] #Note: Si vous souhaitez une exploration plus approfondie des meilleures pratiques concernant la structuration de vos pare-feu cloud, veuillez lireHow To Organize DigitalOcean Cloud Firewalls.
#
Si nous décomposons un peu les choses, nous remarquons que nos deux serveurs ont en réalité plusieurs fonctions. La fonction principale consiste à servir des pages Web ou des informations de base de données, ainsi qu’une fonction de gestion fournie par le service SSH. Il serait judicieux pour nous de créer un pare-feumanagement, un pare-feufrontend et un pare-feudatabase.
Pour gérer le scénario futur dans lequel nous adapterons nos services Web ou de base de données à plusieurs hôtes, nous utiliserons la fonctionnalité de marquage de DigitalOcean pour organiser nos droplets par rôle. Les étiquettes sont de simples étiquettes que nous pouvons appliquer aux gouttelettes pour les catégoriser et adresser des groupes entiers de serveurs à la fois. Le service Cloud Firewall peut appliquer des règles de pare-feu à tous les droplets d'une balise, ce qui facilite la mise en service de nouveaux droplets avec les règles de pare-feu appropriées déjà en place.
Un avantage supplémentaire - et ce qui serait difficile à faire de manière dynamique en utilisantufw - est que les pare-feu Cloud peuvent restreindre l'accès entrant en fonction de balises. Ainsi, par exemple, nos serveursdatabase ne doivent être accessibles que depuis nos serveursfrontend. La configuration actuelle deufw ouvre la base de données à quiconque sur le réseau. Nous verrons cela uniquement à nos Droplets tagués avecfrontend.
Résumons les trois pare-feu que nous devons mettre en place, en langage clair:
-
Management: autorise le trafic entrant vers le port TCP 22 depuis n'importe quel hôte
-
Frontend: autorise le trafic entrant vers les ports TCP 80 et 443 depuis n'importe quel hôte
-
Database: autorise le trafic entrant vers le port TCP 3306 uniquement à partir des serveurs balisésfrontend
Nous n'allons pas limiter le trafic sortant du tout dans ce tutoriel. Ce n’est pas une mauvaise idée, mais il faut faire attention à ne pas casser les mécanismes de mise à jour automatique et les autres fonctionnalités essentielles du système d’exploitation sous-jacent.
Maintenant que nous avons un plan pour nos nouveaux pare-feu, commençons.
[[step-1 -—- tagging-our-servers]] == Étape 1 - Balisage de nos serveurs
Premièrement, nous allons étiqueter nos gouttelettes par rôle, en préparation de nos règles de pare-feu. Accédez au panneau de configuration DigitalOcean. La vue par défaut est une liste de vos gouttelettes. Cliquez sur le boutonMore à droite de votre gouttefrontend-01 et sélectionnezAdd tags:
Une zone de texte apparaîtra dans laquelle vous pouvez entrer des balises pour cette Droplet. Entrezfrontend et cliquez sur le boutonAdd Tags:
Faites de même pour votre serveur de base de données, en lui attribuant une balisedatabase. Les balises apparaîtront dans votre liste Droplet:
Lors de la création de futures gouttelettes, vous pouvez appliquer ces balises lors du processus de provisionnement initial. Les gouttelettes hériteront alors automatiquement des règles de pare-feu correspondantes.
Nous établirons ces règles à l’étape suivante.
[[step-2 -—- creating-cloud-firewalls]] == Étape 2 - Création de pare-feu cloud
Nous allons maintenant configurer nos pare-feu Cloud. Nous allons d'abord faire le pare-feu defrontend, suivi dedatabase, puis demanagement. Cette commande ne devrait pas perturber le service des visiteurs de votre site Web, mais nous perdrons temporairement la possibilité d'établir de nouvelles connexions SSH. Cela n'affectera pas les connexions déjà établies.
Le service Firewalls est disponible dans la sectionNetworking du panneau de configuration DigitalOcean. Une fois là, cliquez sur l'ongletFirewalls, puis cliquez sur le boutonCreate Firewall pour commencer.
Création du pare-feu frontal
Sur la pageCreate Firewall, nous devons remplir unName, configurer nosInbound Rules et sélectionner les droplets auxquels appliquer le pare-feu. Nous laisserons la sectionOutbound Rules telle quelle.
Nous créons d'abord le pare-feu defrontend, donc mettezfrontend-fw dans le champName.
[.note] #Note: Nous ajouterons-fw à la fin de nos noms de pare-feu pour les dissiper. Bien que l'interface du Panneau de configuration utilise des icônes pour différencier les types de ressources, cela peut être déroutant si vous utilisez la ligne de commande ou l'API et que vous avez plusieurs élémentsfrontend, par exemple.
#
Ensuite, nous devons supprimer la règle SSH par défaut de la sectionInbound Rules. Nous allons briser cette règle dans le pare-feu demanagementpour plus de flexibilité. Utilisez le lienDelete sur le côté droit de la page pour supprimer la règle SSH maintenant.
Ensuite, cliquez sur le menu déroulantNew rule et sélectionnezHTTP. Cela remplira automatiquement le protocole (TCP) et le port (80) appropriés, et autorisera par défaut le trafic provenant de toutes les adresses IPv4 et IPv6. C'est ce que nous voulons.
Si HTTPS est activé, répétez le processus ci-dessus pour créer une deuxième règle, en sélectionnantHTTPS cette fois. Votre sectionInbound Rules se terminera comme ceci:
Enfin, dans le champApply to Droplets, commencez à taperfrontend puis sélectionnez la balisefrontend lorsqu'elle est suggérée automatiquement.
Cliquez sur le boutonCreate Firewall. Le nouveau pare-feu sera créé et appliqué à tout Droplet avec la balisefrontend. Vous serez redirigé vers une page de résumé du pare-feu mise à jour affichant votre nouveau pare-feu:
Nous allons maintenant créer le pare-feu dedatabase.
Création du pare-feu de la base de données
Sur la page Pare-feu, cliquez à nouveau surCreate Firewall. Le processus sera essentiellement le même que pour notre pare-feufrontend.
Tapezdatabase-fw dans le champName.
DansInbound Rules, supprimez la règle SSH par défaut. Ensuite, créez une nouvelle règle en utilisant la liste déroulante, en sélectionnantMySQL. Une règle MySQL par défaut sera créée, permettant l’accès au port 3306 à partir de toutes les adresses IP. SupprimezAll IPv4 etAll IPv6 du champSources. Nous voulons que seuls nos serveurs frontaux puissent accéder à la base de données. Commencez à taperfrontend dans la caseSources et sélectionnez la balisefrontend lorsqu'elle est suggérée automatiquement. Désormais, tout Droplet avec cette balise sera autorisé à accéder au serveur de base de données. Toutes les autres IP sont bloquées.
Laissez lesOutbound Rules tels quels. SousApply to Droplets, appliquez ce pare-feu à la balisedatabase, puis cliquez surCreate Firewall. Une fois encore, vous serez renvoyé à la page de résumé du pare-feu:
Notez que les deux pare-feu indiquent qu’ils sont appliqués à une gouttelette. Si vous chargez votre site Web, il devrait quand même se charger correctement. Laissons maintenant la gestion réactivée via SSH.
Création du pare-feu de gestion
Cliquez une dernière fois surCreate Firewall. Ajoutezmanagement-fw au champName.
La règle SSH par défaut est tout ce dont nous avons besoin pour ce pare-feu. Cela permettra à n’importe quelle adresse IP de se connecter au port 22.
Vous pouvez également remplacer le champSources de la règle SSH par une adresse IP spécifique à partir de laquelle vous vous connectez. Par exemple, si votre bureau a une adresse IP statique et que vous souhaitez restreindre l'accès SSH aux seules connexions du bureau, mettez cette IP dansSources, en remplaçantAll IPv4 etAll IPv6. Si votre adresse IP change un jour ou l'autre, il vous suffira de mettre à jour cette règle pour restaurer l'accès de gestion, ce qui constitue un autre avantage de la planification et de la modularité de nos règles.
SousApply to Droplets, ajoutez les balisesfrontend etdatabase, puis cliquez surCreate Firewall. Jetons un coup d’œil à notre dernier résumé du pare-feu:
À ce stade, notre pare-feu cloud devrait être entièrement fonctionnel, mais les pare-feuufwbasés sur l'hôte sont également actifs. Désactivons-les, puis testons nos connexions.
[[step-3 -—- drop-the-host-firewalls]] == Étape 3 - Suppression des pare-feu de l'hôte
Nous devons désactiver le pare-feu deufwur les deux hôtes. Tout d'abord, surfrontend-01:
sudo ufw disableOutputFirewall stopped and disabled on system startupPuis surdatabase-01:
sudo ufw disableOutputFirewall stopped and disabled on system startupCela arrête le pare-feu actuel, efface toutes les règles et empêche leur réactivation au démarrage.
À ce stade, toute notre connectivité doit être restaurée. Essayez de créer une nouvelle session SSH sur l’un de vos serveurs. Chargez ensuite votre site Web pour vérifier que le serveur Web se connecte toujours à la base de données et renvoie des pages Web au navigateur.
La possibilité de se connecter à tous nos services ne prouve pas pour autant qu'un pare-feu fonctionne. Faisons un peu plus de tests pour vérifier que nos pare-feu sont réellement en place.
[[step-4 -—- testing-our-firewalls]] == Étape 4 - Test de nos pare-feu
Pour tester nos pare-feu, nous allons nous connecter à un troisième serveur et utiliser un utilitaire appelénmap pour analyser nos serveurs Web et de base de données. nmap est un scanner de port qui analysera nos hôtes et nous indiquera quels ports sont ouverts, fermés ou filtrés.
Connectez-vous à un autre serveur Ubuntu 16.04 situé dans la même région que vos serveursfrontend-01 etdatabase-01. Puis installeznmap:
sudo apt-get update
sudo apt-get install nmapEnsuite, utiliseznmap pour analyser l'adresse IP publique du serveur Web:
nmap -Pn frontend-01_public_ipOutputStarting Nmap 7.01 ( https://nmap.org ) at 2017-06-05 17:08 UTC
Nmap scan report for 203.0.113.11
Host is up (0.0022s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 4.54 secondsNotez la sortie surfiltered ports. Si le pare-feu ne fonctionnait pas, ils s'afficheraient sous la formeclosed ports. Filtered signifie quenmap ne peut même pas se connecter pour déterminer si le port est ouvert ou fermé.
Notez également que nos ports SSH, HTTP et HTTPS sont ouverts, comme prévu.
Ensuite, nous analyserons le serveur de base de données. Assurez-vous d’utiliser l’adresse IP privée de Droplet si vous l’avez configurée de cette façon, car c’est ce que la base de données MySQL écoutera:
nmap -Pn database-01_private_ipOutputStarting Nmap 7.01 ( https://nmap.org ) at 2017-06-05 17:21 UTC
Nmap scan report for 198.51.100.20
Host is up (0.0024s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 8.17 secondsNous constatons que la plupart des ports sont filtrés, comme auparavant. Cependant, nous ne voyons que le port SSH ouvert, sans port MySQL disponible. Rappelez-vous que nous avons limité l'accès à la base de données aux seuls serveurs marqués avecfrontend. Revenez au panneau de configuration DigitalOcean et ajoutez la balisefrontend au serveur à partir duquel vous utiliseznmap. Relancez ensuite la commande:
nmap -Pn database-01_private_ipOutputStarting Nmap 7.01 ( https://nmap.org ) at 2017-06-05 17:22 UTC
Nmap scan report for 198.51.100.20
Host is up (0.0033s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
3306/tcp open mysql
Nmap done: 1 IP address (1 host up) scanned in 4.46 secondsLe port MySQL est maintenant ouvert. Nous avons vérifié que nos deux serveurs sont maintenant protégés par nos règles Cloud Firewall. Vous pouvez maintenant restaurer les paramètres de pare-feu d’origine de ce serveur de test en revenant au Panneau de configuration et en supprimant la balisefrontend du Droplet.
Conclusion
Dans ce didacticiel, nous avons remplacé une configuration de pare-feuufw par une configuration de pare-feu cloud flexible et puissante basée sur le réseau. Pour plus d'informations sur l'utilisation de Cloud Firewalls viadoctl ou l'API DigitalOcean, veuillez consulter les articles suivants: