Dans notre quotidien, il est devenu difficile de se passer de la communication à Internet, y compris lorsque l'on quitte son domicile, on a toujours une bonne raison de prendre son smartphone pour rechercher une information. Avoir un smartphone n’est plus une option, il s’agit d’une nécessité pour garder le contact avec nos proches, nos collègues, nos collaborateurs, etc. Cependant, avec la multitude des offres sur le marché, on peut bien se perdre et ne pas savoir le meilleur forfait à choisir. Ici, vous trouverez quelques éléments qui vous dirigeront vers le meilleur forfait mobile selon votre cas.
Quel est votre profil?
Avant de vous aventurer vers une quelconque offre sur le marché, il est nécessaire de connaître votre profil. Il s’agit de définir vos besoins de communication et de les prioriser pour mieux vous adapter aux différents réseaux mobiles existants.
Alors, êtes-vous un simple utilisateur de smartphone qui désire rester en contact avec vos amis qu'ils soient en France ou à l'autre bout du monde ? Ou êtes-vous plutôt un chef d’entreprise qui doit rester en contact avec ses salariés et clients ? À moins que vous soyez plutôt accro aux réseaux sociaux et aux séries sur Netflix ? Prenez donc le temps de véritablement déterminer votre profil ainsi que l’usage que vous faites des données mobiles. En fonction des usages, le bon forfait mobile ne sera pas le même, car vos besoins en Giga-octets seront différents.
Plusieurs offres vous sont offertes d’où la nécessité de vous positionner dans un profil donné afin de faire correspondre à vos besoins votre budget et trouver le meilleur forfait mobile. Les fournisseurs, que ce soit Orange, Bouygues, SFR, Free, etc... proposent tous une gamme de forfaits captivants, autant les uns que les autres dans lesquels vous pouvez vous perdre facilement lorsque vous n’êtes pas avisés. Le prix n'est pas le seul critère à prendre en compte.
Un forfait avec engagement
Certains opérateurs de téléphonie proposent des offres pour vous faciliter l’achat des nouveaux smartphones disponibles sur le marché. Il s’agit en effet, des forfaits à des prix élevés avec un engagement qui vous liera sur une période allant de 1 à 2 ans.
Avec cette option, vous aurez certainement votre nouveau smartphone à un prix assez attractif, avec des mensualités que devrez payer tous les mois, sur la durée que couvre l’engagement. Ce n’est pas une solution très prudente, en cas de désir de résiliation de l’engagement, des frais de résiliation seront à payer. Cependant, si votre budget vous le permet, il est mieux de prendre ce genre de forfait pour vous faciliter l’achat du nouveau smartphone (à vous de faire le calcul).
Un forfait sans engagement
Il existe aussi des forfaits auxquels vous pouvez souscrire sans aucun engagement au préalable et que vous pouvez résilier à tout moment. Cette offre est bonne pour toute personne qui prévoit changer de fournisseur mobile dans l’année ; elle sera donc libre de se désabonner sans frais supplémentaires. Un forfait sans engagement, c'est la liberté de changer quand on le souhaite.
Un forfait bloqué
C’est une offre de souscription qui vous permet d’évaluer et de contrôler votre consommation en communication mobile. Il est souvent indiqué pour les adolescents et permet aux parents d’avoir un œil sur leurs activités, évitant ainsi des factures élevées la fin du mois. Ce type de forfait est aussi recommandé pour toute personne ayant un besoin de communication bas pour lui permettre de faire des économies sur ses factures.
Un forfait illimité
Il correspond aux personnes ayant un besoin très élevé de communication et aux gros consommateurs d’internet, car durant le mois, vous avez droit à un volume de data allant certaines fois jusqu’à 50 ou 100 Go selon le forfait activé. Par ailleurs, vous disposez aussi d’un usage illimité des SMS, MMS et appels téléphoniques.
Un forfait haut débit
Avec la pandémie que connaît le monde actuellement, internet devient de plus en plus sollicité pour l’accomplissement des différentes tâches à distance. Ainsi se multiplient les visioconférences pour les réunions entre collaborateurs. Avoir une connexion haut débit est donc un indispensable pour garder activement le contact avec les autres. Vous pouvez opter pour un forfait 4G auprès d'un opérateur, la couverture 5G est toutefois pour le moment inégale en France, vous devez donc vérifier si vous pouvez l’utiliser.
Puisque la communication est incontournable de nos jours, nous vous conseillons de bien définir votre profil avant de vous ruer vers n’importe quelle offre de forfait mobile. En fonction de l'endroit où vous habitez et où vous travaillez, la qualité de la couverture n'est pas homogène entre les opérateurs alors pensez à vérifier cette information sur le site Mon Réseau Mobile de l'ARCEP.
Si vous utilisez ProtonMail en version gratuite, alors cette nouvelle devrait vous faire plaisir ! Le stockage de la version gratuite passe de 500 Mo à 1 Go, mais pour en profiter il y a quelques étapes à suivre.
Pour attirer de nouveaux utilisateurs, mais aussi faire plaisir aux utilisateurs actuels (dont je fais partie), ProtonMail a décidé de doubler la capacité de stockage de l'offre gratuite. Pour en profiter, il y a plusieurs actions à réaliser, voici la liste :
Importer vos contacts de messagerie au sein de ProtonMail
Envoyer un premier e-mail via ProtonMail
Configurer une méthode de récupération
Installer ProtonMail sur mobile (Android ou iOS)
Après avoir accompli votre mission avec succès, un icône en forme de cadeau devrait s'afficher à côté de la capacité de stockage (en bas à gauche) afin de vous permettre de passer à 1 Go. Attention, pour les nouveaux comptes il y a un délai de 30 jours pour réaliser ces actions.
Si vous avez déjà un compte, attendez un peu avant de réaliser les actions, car visiblement le bonus est en cours de déploiement.
Avec cette offre, peut-être que ProtonMail cherche à redoré son image, car le service de messagerie chiffré a fait l'objet d'une polémique en septembre dernier. En effet, dans le cadre d'une enquête, la police a demandé à ProtonMail de lui transmettre les adresses IP utilisées par les activistes du collectif "Youth for Climate" pour se connecter à leur messagerie. Cela n'avait pas plu compte tenu du fait que ProtonMail met en avant la protection de la vie privée. Néanmoins, les e-mails chiffrés n'ont pas pu être consultés : il ne faut pas confondre vie privée et anonymat. ProtonMail reste un service sûr et recommandable pour bénéficier d'une messagerie sécurisée.
Dans ce tutoriel, nous allons voir comment mettre en place un serveur proxy transparent avec Squid sur un pare-feu PfSense, avec la prise en charge du HTTPS.
L'objectif de la mise en place de ce proxy transparent, c'est de permettre l'accélération de la navigation Internet grâce à la mise en cache, mais aussi le filtrage des sites Internet, sans aucune configuration sur les postes clients. Pour suivre ce tutoriel, vous avez besoin d'un accès à Internet, d'un serveur PfSense avec deux interfaces réseau (LAN et WAN), et au minimum un poste client connecté au LAN afin de tester le proxy transparent.
Dans cette configuration, le proxy transparent (192.168.100.1/24) fait office de passerelle pour les machines du réseau local.
Note : lors de la mise en place d'un serveur proxy, qu'il soit transparent ou non, pensez à le préciser dans la charte informatique de votre entreprise, notamment pour l'aspect filtrage.
Il s'agit d'un premier tutoriel sur Squid en mode proxy transparent. Un second tutoriel, qui est une suite de celui-ci, concernera la configuration de Squid Guard pour aller plus loin dans le filtrage.
Connectez-vous sur l'interface d'administration de PfSense afin d'installer le paquet "squid". Pour cela, sous "System", cliquez sur "Package Manager" et ensuite sur l'onglet "Available Packages".
System > Package Manager > Available Packages
Recherchez "squid" et cliquez sur le bouton "Install" à droite, au niveau de la ligne correspondante.
À la fin de l'installation, le message "pfSense-pkg-squid installation successfully completed" doit s'afficher.
Le paquet étant installé, on peut passer à la configuration.
III. Configurer Squid (Proxy) sur PfSense
La configuration de Squid s'effectue via le menu "Services" :
Services > Squid Proxy Server
La configuration est découpée en plusieurs onglets. Afin de pouvoir activer Squid, il faut configurer le cache local sinon le démarrage du processus Squid échouera. Cliquez sur l'onglet "Local Cache". Comme pour chaque section, nous retrouvons de nombreux paramètres... Pour le cache, j'attire votre attention sur ces options :
Hard Disk Cache Size : par défaut sur "100" pour 100 Mo, cette valeur correspond à la taille maximale du cache sur l'espace disque. Vous pouvez augmenter cette valeur à 1024 Mo pour avoir 1 Go de cache.
Hard Disk Cache Location : l'emplacement du cache, à savoir par défaut "/var/squid/cache".
Que vous décidiez de modifier ou non l'un des paramètres de la section "Local Cache", vous devez cliquer sur le bouton "Save" en bas de la page.
Ensuite, cliquez sur l'onglet "General". Là encore, il y a de nombreuses options. Voici ce qu'il faut configurer à minima :
Enable Squid Proxy : cochez la case pour activer Squid sur le pare-feu, ce qui signifie qu'il va démarrer
[facultatif]Listen IP Version : écouter en IPv4, en IPv6 ou les deux
Proxy interface(s) : sur quelle interface souhaitez-vous activer le proxy ? Ici, ce sera seulement sur l'interface "LAN" donc je la sélectionne. Vous pouvez en sélectionner plusieurs si besoin, mais dans tous les cas le "WAN" ne sera pas sélectionné.
Proxy Port : on laisse le port par défaut, à savoir 3128, mais il ne devra pas être déclaré sur les postes clients puisque l'on va configurer Squid en mode proxy transparent.
Allow Users on interface : cochez cette case pour autoriser implicitement les utilisateurs connectés sur le réseau "LAN" à utiliser le proxy. Cela évite de déclarer le réseau dans un second temps.
Descendez dans la page... et cochez l'option "Transparent HTTP Proxy" pour activer le mode proxy transparent pour le protocole HTTP. Pour l'activer pour le protocole HTTPS, il faudra cocher une autre option (nous en parlerons par la suite).
Dans le même esprit qu'au début de la configuration, sélectionnez "LAN" pour l'option "Transparent Proxy Interface(s)".
En configurant l'option "Bypass Proxy for these Source IPs", vous avez la possibilité de déclarer des adresses IP sources (ou un sous-réseau source) qui peuvent passer outre le proxy et accéder en direct à Internet. Dans le même esprit, l'option "Bypass Proxy for these Destination IPs" permet d'outrepasser le proxy pour certaines destinations.
Pour le moment, laissez l'option "Enable SSL filtering" décochée.
Continuez de descendre dans la page... Activez les journaux comme ceci :
Enable Access Logging : cochez l'option pour activer les journaux, ce qui va permettre de savoir qui fait quoi sur Internet.
Rotate Logs : pendant combien de jours souhaitez-vous conserver les logs ? Pour les établissements scolaires, c'est pendant 365 jours qu'il faut conserver les logs (sauf erreur de ma part).
Ensuite, la section "Headers Handling, Language and Other Customizations" permet de configurer les messages Squid. Le champ "Visible Hostname" correspond au nom d'hôte qui peut s'afficher côté client, notamment sur les pages de blocage Squid, tout comme l'e-mail spécifié pour l'option "Administrator's Email". Pour les messages d'erreurs justement, précisez la langue française au niveau de l'option "Error Language".
Pour des raisons de sécurité, on va masquer les informations sur Squid, notamment la version, en cochant l'option "Suppress Squid Version". Ce qui donne :
Voilà, on est arrivé au bout de la page de configuration ! Cliquez sur "Save" pour appliquer cette nouvelle configuration.
IV. Tester le proxy transparent Squid
Pour tester le bon fonctionnement de notre proxy transparent HTTP, on peut tout simplement s'amuser à naviguer sur Internet. Pour que ce soit plus parlant, on va bloquer un nom de domaine.
Cliquez sur l'onglet "ACLs", toujours dans la configuration de Squid. C'est ici que vous pouvez déclarer les sous-réseaux autorisés à utiliser le proxy (Allowed Subnets) mais pour nous c'est implicite (souvenez-nous de l'option cochée précédemment). Pour autoriser une ou plusieurs adresses IP (ou sous-réseau) à passer outre les restrictions, renseignez l'option "Unrestricted IPs".
Ce qui m'intéresse pour ce test, c'est l'option "Blacklist" puisqu'elle permet d'indiquer un ou plusieurs domaines à bloquer. Pour ce test, il nous faut un site en HTTP (ce qui est de plus en plus "rare", enfin surtout au niveau des sites connus). J'ai pris le site "horizons21.fr", au hasard, et je l'ai ajouté comme ceci :
Ensuite, on sauvegarde la configuration... Puis, à partir d'un poste de travail situé sur le réseau local, on tente d'accéder au site horizons21.fr. Et là, on peut voir que ça ne fonctionne pas ! On peut voir qu'une page "Accès interdit" renvoyée par Squid s'affiche !
On peut aussi suivre les logs en temps réel côté Squid, via l'onglet "Real Time". On voit très bien nos requêtes à destination du site "horizons21.fr" depuis l'hôte 192.168.100.11 : c'est la preuve irréfutable que notre PC passe bien par le proxy transparent !
V. Configurer Squid en proxy transparent HTTPS (SSL Inspection)
C'est bien beau notre configuration, mais notre proxy transparent fonctionne seulement sur le protocole HTTP. Depuis quelques années maintenant, la tendance est au HTTPS (et on va pas s'en plaindre) alors c'est indispensable que l'on permette à notre proxy transparent de travailler le HTTPS.
Cela est un peu plus complexe qu'une simple case à cocher dans les options du proxy, car il faut faire ce que l'on appelle du SSL Inspection. Puisqu'un flux HTTPS est chiffré, le proxy ne peut pas seulement regarder les trames passer. En effet, pour chaque connexion, il doit déchiffrer le flux, l'inspecter puis le chiffrer à nouveau afin de l'acheminer : une tâche d'envergure et gourmande en ressources.
A. Créer l'autorité de certification PfSense
Pour commencer, il faut créer une autorité de certification sur notre pare-feu PfSense. Rendez-vous dans le menu "System" puis "Cert. Manager" et dans l'onglet "CAs". Cliquez sur "Add" et renseignez les différents champs : c'est tout simple.
Note : si vous avez une autorité de certification Active Directory, il doit être possible d'ajouter un certificat existant directement.
Vous obtenez une autorité de certification, comme la mienne nommée "CA-ITCONNECT" et qui existait déjà sur mon pare-feu, car je l'utilise pour le VPN client-to-site.
B. SSL Inspection avec Squid
Retournez dans la configuration de Squid, via le menu "Services". Cochez l'option "Resolve DNS IPv4 First" pour activer la résolution DNS en amont du filtrage, ce qui est recommandé lorsque l'on filtre le HTTPS (ce que l'on s'apprête à faire).
Ensuite, activez l'option "Enable SSL filtering". Pour le mode "SSL/MITM Mode", choisissez le mode "Splice All" : c'est le mode le moins contraignant à mettre en œuvre, car il ne nécessite pas de déployer le certificat de l'autorité de certification sur l'ensemble des postes clients. C'est aussi le mode recommandé lorsque l'on prévoit de déployer Squid Guard, ce qui sera le cas dans la seconde partie de ce tutoriel.
Remarque : si vous prenez l'autre mode, il faut exporter le certificat de la CA créée précédemment et le déployer sur toutes les machines qui vont passer par le proxy transparent.
Sélectionnez l'autorité de certification créée précédemment au niveau de l'option "CA".
Sauvegardez via le bouton en bas de page.
C. Tester l'accès à Internet
Maintenant, retournez sur votre poste de travail qui passe par le proxy puis tentez de naviguer sur un site en HTTPS. Vous allez très probablement obtenir le message d'erreur "SSL_ERROR_RX_RECORD_TOO_LONG". Pour résoudre cette erreur, il faut que l'on utilise notre proxy comme résolveur DNS (directement ou indirectement).
D. Ajuster les paramètres DNS
Pour ajuster les paramètres DNS et faire fonctionner le proxy transparent, il y a deux options :
Définir l'adresse IP du proxy comme DNS sur le poste de travail (manuellement ou via DHCP)
Attention, si vous utilisez un domaine Active Directory, il faut créer une règle dans le résolveur DNS de PfSense pour renvoyer les requêtes liées à votre domaine vers le contrôleur de domaine.
Définir l'adresse IP du contrôleur de domaine comme DNS sur le poste de travail, comme c'est le cas actuellement
Sur le contrôleur de domaine, dans les options du serveur DNS, on va définir le serveur proxy (notre PfSense) comme redirecteur DNS. Cela signifie qu'il sera sollicité pour les requêtes correspondantes à des hôtes sur Internet (car non connu de notre DNS interne). Ce qui donne :
Une fois que la configuration est effectuée, on retourne sur l'interface de configuration Squid.
E. ACL : bloquer un site HTTPS dans Squid
Comme toute à l'heure, on va retourner dans l'onglet "ACLs" au niveau de la section "Blacklist". Cette fois-ci, on va bloquer un domaine où le site tourne en HTTPS : "facebook.com", à tout hasard. Ce qui donne :
On sauvegarde et on tente d'accéder à Facebook... Voici le message que l'on obtient :
Même si ce message n'est pas très esthétique et fait plutôt penser à une erreur, il empêche bien l'accès au site facebook.com. L'erreur de certificat qui s'affiche est liée à l'utilisation de notre certificat de CA locale pour filtrer facebook.com, alors forcément la correspondance entre les deux ne peut pas être effectuée.
Voilà, le proxy transparent HTTP/HTTPS avec Squid sur un pare-feu PfSense est en place ! Rendez-vous demain pour la suite : l'ajout du paquet Squid Guard pour aller plus loin dans le filtrage, notamment l'utilisation d'une blacklist par catégorie.
En attendant, vous pouvez explorer encore un peu plus la configuration de Squid. Il y a notamment l'onglet "Authentication" qui permet de soumettre l'utilisation du proxy à authentification via la base locale, un serveur Radius voire un annuaire Active Directory. Quant à l'onglet "Traffic Mgmt", il permet de brider le téléchargement de fichiers au travers du proxy.
La vulnérabilité Log4Shell au sein de la bibliothèque Log4j touche énormément de produits et de vendeurs différents, à tel point que l'on ne sait pas réellement qui est concerné.
Fort heureusement, un français surnommé SwitHak a eu l'excellente idée de créer une liste des produits et vendeurs concernés sur GitHub, avec un classement par ordre alphabétique. À chaque fois, le lien vers le bulletin de sécurité est ajouté.
La très très très longue liste est accessible via ce lien
N'hésitez pas à rechercher dans cette liste les produits que vous utilisez afin de vérifier leur présence ou non. En complément, et dans le cas où le fabricant/l'éditeur n'apparaît pas dans cette liste, vérifiez tout de même sur le site officiel.
Ne soyez pas surpris de retrouver les principaux vendeurs et éditeurs du marché... Voici quelques noms qui vont forcément vous parler : Cisco, Bitdefender, Docker, IBM, Jenkins, McAfee, Microsoft, NetApp, Nutanix, Oracle, Plesk, Puppet, Salesforce, Sophos, SonicWall, Synology, TP-Link, TrendMicro, Veeam, VMware, etc...
Pour rappel, la bibliothèque Log4j est touchée par une faille de sécurité critique qui a bénéficié d'un score de 10/10 et qui peut-être exploitée à distance, sans authentification, afin de permettre à l'attaquant d'exécuter du code malveillant sur le serveur cible.
Dans ce tutoriel, nous allons voir comment configurer un reverse proxy HTTPS avec HAProxy sur PfSense. Pour le certificat du site, on utilisera ACME pour générer (et renouveler) automatiquement le certificat SSL avec Let's Encrypt.
HAProxy est une solution très complète et incontournable lorsque envisage de mettre en place un reverse proxy. Lors de l'utilisation d'un pare-feu PfSense sur un réseau, on peut ajouter la brique HAProxy par l'installation d'un simple paquet qu'il faudra ensuite configurer.
Démonstration au format vidéo disponible ci-dessous, avec le reverse proxy et un pool de deux serveurs Web pour le même site.
Pour cet exemple, je vais utiliser un serveur PfSense déjà configuré avec 2 interfaces (WAN et LAN), un serveur Web qui sera derrière le reverse proxy et qui contient le site Web WordPress à publier sur Internet, et un poste de travail distant (client en provenance d'Internet) pour tester le reverse proxy.
Ce qui donne le schéma suivant pour le site Internet "it-connect.tech" :
Dans la pratique :
1 - Le client tente de se connecter au site Internet "it-connect.tech", en HTTPS, il tombe sur HAProxy (sans s'en rendre compte).
2 - Le reverse proxy HAProxy traite la requête, il voit que le client veut accéder au site "it-connect.tech" donc il interroge le bon serveur Web (192.168.100.121/24), sur le port 80, car le serveur Web écoute sur ce port (on pourrait en utiliser un autre).
3 - Le serveur Web traite la requête du client, relayée par le reverse proxy (c'est le reverse proxy qui communique avec le serveur Web) et lui retourne une réponse (par exemple : le code source de la page demandée).
4 - Le reverse proxy retourne la page Web demandée au client, au sein d'une connexion sécurisée HTTPS.
II. Gérer les certificats Let's Encrypt sur PfSense
La première étape consiste à gérer les certificats SSL Let's Encrypt directement sur notre pare-feu PfSense. L'idée étant de générer le certificat initial, mais aussi de le renouveler automatiquement. La question que l'on peut se poser, c'est "pourquoi gérer le certificat SSL au niveau du reverse proxy plutôt que sur le serveur Web, voire même les serveurs web ?".
Le reverse proxy HTTPS va répondre aux requêtes HTTPS (comme son nom l'indique), alors c'est lui qui doit être en mesure de présenter au client le certificat SSL correspondant au domaine du site visité. Cela signifie qu'il doit héberger le certificat SSL.
Pour cela, on peut importer un certificat SSL obtenu auprès d'une autorité de certification en ligne et qui est valide pour une durée limitée (1 an, 2 ans, etc.). Sinon, l'alternative consiste à utiliser Let's Encrypt pour utiliser un certificat SSL gratuit, valide 90 jours à chaque fois, mais que l'on peut renouveler automatiquement (c'est ce que nous allons faire).
Imaginons que l'on ait une ferme de 2, 5 ou 10 serveurs Web pour le même site, cela signifie que lorsqu'un nouveau certificat SSL doit être déployé, il faut répéter l'opération autant de fois qu'il y a de serveurs Web. En gérant le certificat au niveau du reverse proxy, on limite aussi la maintenance.
A. Installation du paquet ACME sur PfSense
La première étape consiste à installer le paquet ACME. Sous le menu "System", cliquez sur "Package Manager" puis via l'onglet "Available Packages", recherchez et installez le paquet "acme".
Une fois que c'est fait, sous le menu "Services", cliquez sur "Acme Certificates".
Passons à la configuration.
B. Générer les clés ACME
Il faut que l'on commence par demander une clé d'authentification auprès de Let's Encrypt pour être autorisé à demander les certificats par la suite. Pour cela, cliquez sur l'onglet "Account Keys" et cliquez sur le bouton "Add".
Commencez par nommez cette clé, par exemple "certs.it-connect.tech" (le nom DNS n'a pas besoin d'être résolvable) et choisissez "Let's Encrypt Production ACME v2" au niveau de l'option "ACME Server".
Cliquez sur le bouton "Create new account key" pour générer une clé d'authentification et cela va remplir le champ "Account key" juste au-dessus. Nous devons enregistrer cette clé, donc je vous invite à cliquer sur "Register ACME account key". Normalement, un petit icône validé doit venir s'afficher sur le bouton, comme ceci :
Cliquez sur "Save" et vous obtenez ceci dans "Account keys" :
C. Demander un certificat Let's Encrypt depuis PfSense
Basculez sur l'onglet "Certificates", car nous allons demander notre premier certificat SSL Let's Encrypt pour notre site "it-connect.tech". Cliquez sur le bouton "Add".
Donnez un nom à ce certificat : le nom de domaine est une bonne idée donc ce sera "it-connect.tech" pour ma part. Choisissez le compte ACME que l'on vient de créer au niveau de l'option "Acme Account".
Ensuite, pour l'option "Domain SAN list", ajoutez une nouvelle entrée et choisissez la méthode "DNS-Manual". De cette façon, on va créer un enregistrement DNS par la suite pour prouver que l'on est bien propriétaire du nom de domaine. Pensez à renseigner l'option "Domainname" pour préciser le nom de domaine : pour ma part "it-connect.tech", car c'est le nom de domaine pour lequel je veux obtenir un certificat SSL.
Note : par défaut, le certificat est configuré pour se renouveler automatiquement tous les 60 jours (voir option "Certificate renewal after" en bas de page), tout en sachant qu'il est valide 90 jours à chaque fois.
Une fois que c'est fait, validez. Dans l'onglet "Certificates", votre certificat doit s'afficher (attention, il n'est pas généré pour le moment). Cliquez sur le bouton "Issue".
Suite à cette action, on peut voir que l'ACME nous demande de créer un enregistrement DNS TXT avec le nom "_acme-challenge" et une valeur spécifique. Par exemple :
Sur l'interface où se situe la gestion de votre domaine, vous devez créer un nouvel enregistrement DNS de type "TXT" avec les valeurs fournies par ACME, notamment le nom "_acme-challenge". Voici un exemple chez OVH :
Une fois que c'est fait, vous devez cliquer sur le bouton "Renew" comme précisé dans la sortie de la commande précédente.
Vous devriez obtenir une réponse positive (attention, même si c'est vert, parfois il y a des erreurs alors prenez le temps de regarder) qui se caractérise par la présence des lignes "Cert success" et "BEGIN CERTIFICATE", puis tout ce qui suit.
Mon certificat SSL Let's Encrypt pour "it-connect.tech" a été généré avec succès et l'emplacement des fichiers est précisé dans les logs :
Your cert is in /tmp/acme/it-connect.tech//it-connect.tech/it-connect.tech.cer
Your cert key is in /tmp/acme/it-connect.tech//it-connect.tech/it-connect.tech.key
The intermediate CA cert is in /tmp/acme/it-connect.tech//it-connect.tech/ca.cer
And the full chain certs is there: /tmp/acme/it-connect.tech//it-connect.tech/fullchain.cer
Pour finir la partie certificat, cliquez sur l'onglet "General Settings" et cochez l'option "Cron Entry" pour activer la tâche planifiée (dans la crontab) afin de le renouveler automatiquement.
Ce certificat va pour voir être présenté au client qui voudront se connecter au site it-connect.tech, afin de sécuriser la connexion, et cela sera fait par HAProxy. En parlant d'HAProxy, passons à la configuration du reverse proxy.
III. Reverse proxy HTTPS HAProxy sur PfSense
A. Installation du paquet HAProxy sur PfSense
Sur le même principe que le paquet "acme", installez le paquet "haproxy" sur votre serveur PfSense.
B. Configuration générale de HAProxy
Commençons par l'onglet "Settings" de la configuration de HAProxy. Pour accéder à la configuration de HAProxy, sous le menu "Services", cliquez sur "HAProxy" tout simplement.
Ensuite, il faut renseigner le champ "Maximum connections", c'est-à-dire le nombre de connexions maximales par processus. Il faut ajuster ce paramètre en fonction du dimensionnement de votre serveur et de la fréquentation des ressources derrière le reverse proxy. On peut voir que 1 000 connexions consomment 48 Mo de mémoire, et en dessous on peut choisir le nom de processus à démarrer (1 par défaut / option "Number of processes to start").
Note : il n'est pas nécessaire de cocher l'option "Enable HAProxy" pour le moment, on va préparer la configuration avant.
Un peu plus bas dans la page, indiquez la taille 2048, car c'est une valeur recommandée pour l'option "Max SSL Diffie-Hellman size" (afin d'éviter d'avoir un avertissement dans les logs HAProxy).
C. Déclarer les serveurs backend
Lors de la configuration d'un reverse proxy, il faut configurer le Backend et le Frontend.
Le Backend, c'est ce qui se passe derrière le reverse proxy, cela correspond donc aux différents serveurs qui hébergent les ressources (par exemple, notre serveur Web avec le site it-connect.tech).
Le Frontend, c'est ce qui se passe en frontal sur le reverse proxy, c'est-à-dire de quelle façon le reverse proxy doit se présenter aux clients, et surtout comment il doit traiter les requêtes (par exemple, s'il reçoit une requête HTTPS à destination du domaine it-connect.tech, il doit savoir quoi en faire).
Commençons par le Backend. Cliquez sur l'onglet "Backend" puis sur le bouton "Add".
Cela va permettre de créer un pool de serveurs. Dans cet exemple, même si nous avons un seul serveur Web, on peut considérer que c'est notre pool pour le domaine it-connect.tech. D'ailleurs, on va utiliser ce nom pour notre pool (option "Name").
Ensuite, il faut renseigner l'option "Server list" : c'est là que l'on va déclarer les différents serveurs Web membre de ce pool, et donc qui héberge le site "it-connect.tech". Ajoutez un élément avec les options suivantes :
Mode : Active (c'est un serveur actif dans le pool)
Name : le nom de l'hôte serveur Web pour s'y retrouver, en l'occurrence "debian-11" pour ma part puisque c'est mon serveur Web (oui, je sais, le nom n'est pas très original)
Forwardto : "Address+Port" puisque l'on va interroger ce serveur Web via son adresse IP et un numéro de port spécifique
Address : l'adresse IP du serveur Web, pour ma part "192.168.100.121"
Port : le port sur lequel est en ligne le site sur le serveur Web, pour ma part "80", car mon site est en HTTP au niveau du serveur Web, mais rassurez-vous, le reverse proxy va s'occuper de chiffrer les communications avec les clients, via le protocole HTTPS et mon joli certificat SSL Let's Encrypt.
Ne cochez pas les options "Encrypt (SSL)" et tout ce qui s'en suit, sinon cela va nous créer des ennuis... Pour l'option "Client certificate", elle est utile seulement si le serveur Web est sur le port 443 en HTTPS, auquel cas il faut spécifier le certificat SSL, comme sur l'exemple ci-dessous. Dans cet exemple, ce n'est pas utile.
Descendez dans la page... Vous verrez qu'il y a énormément d'options. Par exemple, la partie "Loadbalancing Options" sert à définir comment le reverse proxy doit répartir les connexions entre les serveurs du pool actuel. Par défaut, c'est le mode classique appelé round-robin (c'est plus ou moins chacun son tour), mais il y a beaucoup d'autres modes. Ici, j'ai qu'un serveur Web donc la question ne se pose pas. Sinon, le reverse proxy joue le rôle de répartiteur de charge entre les serveurs.
Au sein de la section "Health checking", il est impératif de configurer l'option "Health check method". En fait, le reverse proxy va vérifier à intervalle régulier si notre serveur Web est opérationnel ou pas. Il faut lui indiquer comment effectuer cette vérification. Pour ma part, je choisis "HTTP" : cela implique que le serveur Web soit accessible en HTTP via son adresse IP afin que le reverse proxy puisse l'interroger.
Note : dans les logs du serveur Apache (access.log), vous allez voir une requête par seconde en provenance du reverse proxy, cela signifie qu'il vérifie l'état du serveur Web - Exemple : 192.168.100.1 - - [07/Dec/2021:17:47:54 +0100] "OPTIONS / HTTP/1.0" 200 110048"
Quel est l'intérêt de cette vérification ? Si un serveur Web de notre pool est hors ligne ou que le service Web est planté, le reverse proxy va en tenir compte et ne plus envoyer de requête à traiter à ce serveur Web, jusqu'à ce qu'il revienne à son état normal.
Continuez à descendre dans la page et cliquez sur "Save".
Au sein de la section "Backend", notre pool de serveurs apparaît. Cliquez sur "Apply Changes" pour appliquer la configuration.
Passons à la configuration du Frontend.
D. Déclarer le frontend dans HAProxy
Cliquez sur l'onglet "Frontend" puis sur le bouton "Add".
Nommez ce Frontend "it-connect.tech" puisque l'on va gérer les requêtes à destination de ce domaine. Veillez à ce que le statut ("Status") soit sur "Active".
Ensuite, il faut que l'on configure l'option "External address" de cette façon :
Listen address : choisissez "WAN address (IPv4)", car on va traiter les requêtes qui arrivent sur l'interface WAN du PfSense (ce sera cette adresse IP déclarée dans l'enregistrement DNS "A" du domaine it-connect.tech).
Port : indiquez "443", car on va publier notre site en HTTPS
SSL Offloading : cochez cette option, car cela correspond à notre architecture, c'est-à-dire du HTTPS entre le reverse proxy et les clients, et du HTTP entre le reverse proxy et les serveurs Web. Le SSL Offloading correspond à ce processus du transformation du flux.
Un peu plus bas, sélectionnez l'option "http / https (offloading)" pour la valeur "Type". Cela veut dire que le reverse proxy va travailler au niveau de la couche HTTP/HTTPS.
Remarque : une alternative consiste à utiliser le mode "ssl / https (tcp mode)", mais dans ce cas, le reverse proxy travaille au niveau de la couche connexion avec le protocole TCP. Ce cas est utile si vous souhaitez gérer le certificat SSL au niveau des serveurs Web directement, mais ne permet pas l'activation de l'en-tête HTTP "X-FORWARDED-FOR". C'est utile aussi si vous utilisez le reverse proxy pour autre chose qu'un site Web.
Passons à la section "Default backend, access control lists and actions". Cette section va permettre d'aiguillier les requêtes entre le Frontend et le Backend du reverse proxy. C'est ici que l'on va dire qu'une requête à destination du domaine "it-connect.tech" doit être redirigée vers notre Backend qui contient notre serveur Web.
Pour l'option "Access Control lists", ajoutez une ligne, c'est-à-dire une nouvelle règle (ACL). Comme ceci :
Name : nom de l'ACL, par exemple "AccesSite".
Expressions : on choisit "Host matches:", car on cherche à repérer la présence du nom de domaine dans l'URL / la requête
Value : on précise le nom de domaine du site, à savoir "it-connect.tech"
Pour définir ce que l'on doit faire lorsque cette règle matche, on va ajouter une action dans la section "Actions", comme ceci :
Action : on sélectionne "Use backend" et on choisit notre backend créé précédemment, cela permet d'utiliser notre Backend lorsque la requête va correspondre à l'ACL
Condition acl names : on spécifie "AccesSite", car c'est le nom de l'ACL que l'on vient de créer
Vous avez aussi la possibilité de définir un Backend qui sera sélectionné par défaut, sans tenir compte de vos ACLs, au niveau de l'option "Default Backend". Néanmoins, si la requête ne correspond pas à "it-connect.tech", il n'y a pas de raison qu'elle soit traitée par notre Backend : il vaut mieux que le reverse proxy refuse la requête.
Descendez dans la page. Cochez l'option "Use forwardfor option" pour ajouter le champ "X-Forwarded-For" à l'en-tête HTTP. Pour rappel, cela permettra au serveur Web de connaître l'adresse IP d'origine du client, et pas seulement l'adresse IP du serveur reverse proxy.
Note : pour que l'adresse IP du client d'origine soit visible dans les logs Apache 2.4, vous devez activer le module "remoteip" et adapter le format des logs.
Descendez encore un peu... jusqu'à la section "SSL Offloading" puisqu'il faut choisir le certificat SSL Let's Encrypt au niveau de l'option "Certificate".
Voilà, c'est terminé pour la configuration du Frontend. Cliquez sur "Save". On obtient ceci :
Retournez dans l'onglet "Settings" afin d'activer HAProxy en cochant l'option "Enable HAProxy" puisque notre configuration est prête. Sauvegardez et cliquez sur "Apply changes" avant de passer à la suite.
E. Modifier le port de l'interface de gestion PfSense
Pour que notre reverse proxy HAProxy traite les requêtes qui arrivent sur le port 443 de l'interface WAN de PfSense, il faut que l'on crée une règle de pare-feu. Le problème, c'est que par défaut le port 443 est utilisé par défaut pour l'interface d'administration. Afin d'éviter un conflit (et potentiellement d'exposer l'interface d'administration PfSense), on va modifier le port utilisé.
Sous le menu "System", cliquez sur "Advanced". Dans l'onglet "Admin Access", modifiez l'option "TCP port" pour définir un autre port. Par exemple, le port 8443. Validez et accédez de nouveau à votre PfSense en spécifiant le nouveau port à la fin de l'URL : https://<adresse-IP>:8443.
F. Créer la règle de pare-feu pour HAProxy
Venons-en à la création de la règle de pare-feu pour HAProxy, ce dernier doit être en mesure de recevoir les requêtes sur le port 443. Pour cela, sous le menu "Firewall", cliquez sur "Rules" puis choisissez la zone "WAN".
Créez une nouvelle règle en cliquant sur le bouton "Add" et autorisez les flux HTTPS (443) vers le pare-feu afin qu'ils soient gérés par HAProxy. Ce qui donne :
Remarque : pour que nos flux HTTPS soient traités par notre reverse proxy, je ne veux pas voir de règles de NAT pour rediriger le port 443 vers le serveur Web interne. - Sinon, cela permettrait de bypasser le reverse proxy est d'atteindre directement le serveur Web, ce qui n'est pas le but : nous n'avons pas fait tout ça pour rien !
G. Les statistiques dans HAProxy
En soit, le reverse proxy est prêt : il est configuré et il peut recevoir ses premières requêtes. Néanmoins, avant de tester, je vous invite à regarder la partie statistique de HAProxy. Pour cela, retournez dans la configuration de HAProxy est spécifiez un port pour accéder à l'interface de statistiques (option "Internal stats port") : l'accès s'effectue seulement en local, via l'interface du PfSense.
Validez et appliquez les changements. Ensuite, toujours dans HAProxy, cliquez sur l'onglet "Stats" dans le menu (le menu "Stats FS" est équivalent, mais en plein écran). L'interface suivante va s'afficher :
Vous pouvez obtenir de nombreuses statistiques, et notamment l'état des différents serveurs de vos Backend. Ci-dessus, on peut voir que le serveur "debian-11" est en ligne, car la ligne est verte, et on peut savoir également combien de sessions il gère, etc...
Lorsqu'un serveur est inaccessible (cela signifie que notre vérification HTTP a échoué), alors la ligne devient rouge. En sélectionnant l'hôte via la case à cocher à gauche, on peut effectuer différentes actions notamment forcer la vérification de l'état de cet hôte ou encore passer l'hôte en mode maintenance ("Set state to MAINT"), ce qui permet de l'exclure du pool de serveurs pendant une opération de maintenance.
Maintenant, il ne vous reste plus qu'à accéder à votre site Internet positionné derrière le reverse proxy pour voir s'il fonctionne bien ! Je vous invite à tester en profondeur le site, notamment le mode visiteur, mais aussi le mode authentifié, en fonction de votre type de site. Pour finir ce tutoriel, quelques mots sur WordPress et Apache...
IV. WordPress derrière HAProxy
Au moment de tester, vous allez peut-être rencontrer quelques problèmes... Sachez que le problème ne vient pas forcément de HAProxy, mais peut-être du serveur Web voire même de WordPress (si vous utilisez WordPress...).
Lorsque vous avez un site WordPress positionné derrière HAProxy, accessible via HTTP en local, mais via HTTPS en externe, comme dans le cadre de cette configuration, vous allez surement rencontrer l'erreur "ERR_TOO_MANY_REDIRECTS" au sein du navigateur.
Que se passe-t-il ? Si le site est configuré avec une URL "HTTPS" dans les paramètres de WordPress et que le reverse proxy lui envoie une requête HTTP, WordPress va vouloir rediriger la requête en HTTPS. Sauf qu'en faisant ça, il va repasser par le reverse proxy qui va lui renvoyer la requête HTTP, et donc lui va vouloir rediriger en HTTPS, ce qui crée une boucle infinie.
Pour contourner ce problème, il faut que l'on crée une règle dans le fichier "wp-config.php" du site pour écrire l'URL du site en HTTPS et faire croire à WordPress qu'il travaille déjà en HTTPS. En complément, on va forcer l'utilisation du SSL au niveau de l'interface d'administration de WordPress, sinon vous allez obtenir un message d'accès refusé si vous tentez d'accéder au backoffice ou à votre profil une fois authentifié sur le site.
Au début du fichier wp-config.php (c'est important que ce soit au début), ajoutez ces lignes (remplacez le nom de domaine par votre site) :
Sauvegardez et le tour est joué, votre site WordPress doit fonctionner derrière le reverse proxy ! Ce qui s'applique à WordPress ne s'applique peut-être pas forcément à d'autres applications Web, et certainement pas à un site statique tout simple, mais c'est à connaître.
Désormais, les visiteurs du site it-connect.tech accèdent au site en HTTPS par l'intermédiaire du serveur HAProxy : mission accomplie.
- Sinon, cela permettrait de bypasser le reverse proxy est d'atteindre directement le serveur Web, ce qui n'est pas le but : nous n'avons pas fait tout ça pour rien !
