OPNsense

Les plus ou moins récentes évolutions de la version Community de pfsense m'ont conduit à expérimenter OPNsense. L'idée étant de tester la faisabilité de tout ce que je fais avec pfsense tout en améliorant le service produit.

A partir de l'ISO j'installe une VM sur un serveur VMWare ESXi, vu ce qui se passe chez VMWare je vais également tester sous Proxmox, mais le fond ne change pas.

Connectivité

Ce serveur étant hébergé chez Scaleway dans un Dédirack, je vais affecter sur le WAN une IPv4 et une IPv6 en mode statique et configurer les passerelles qui vont avec. S'agissant d'un firewall on disposera également d'une patte LAN afin de communiquer avec les autres VM qui ne sont pas exposées.

IP Virtuelles

Les certificats

ACME va nous permettre de générer des certificats Let's Encript.

On en profite pour désactiver la redirection HTTP/HTTPS de l'interface et de la basculer du port 443 à 8443.

Publication

Le premier usage de ce firewall est d'assurer la publication sécurisée :

Sites web : via le reverse proxy HAProxy.
Services IP : via le firewall en mode NAT. C'est suffisamment intuitif pour ne pas y revenir ici. OPNsense permet de créer et maintenir des alias de GeoIP afin de mieux sécuriser certains services en restreignant le périmètre d'accès.

HAProxy

HAProxy est bien plus qu'un simple reverse proxy, c'est un équilibreur de charge. L'approche sous OPNsense est assez différente de celle implémentée sous pfsense, j'ai donc un peu tâtonné mais au final je pense que c'est mieux. A ce stade je ne vais pas utiliser l'équilibreur de charge, mais le principe reste identique, sauf que dans un POOL de serveurs je n'en mettrais qu'un seul.

On crée deux règles sur le WAN du firewall afin d'ouvrir les ports 80 et 443 et les rediriger en local (This Firewall ou WAN adress)

Il nous faut donc (en anglais car la traduction de l'interface n'est pas toujours très heureuse) :

Real Servers

Il s'agit ici de renseigner les serveurs web via son IP interne ou DNS interne.

Un serveur web peut héberger plusieurs services web, mais on ne s'en occupe pas à ce stade.
A un serveur (au sens HAProxy) correspond un port. Ce port peut être ou pas en SSL et si oui on peut choisir de vérifier le certificat ou pas. Pour une sécurité maximale on préservera bien sur la chaine en SSL de bout en bout. Pour mon usage la majorité sont sans SSL sur le port 80 et d'autre en SSL avec un certificat périmé, donc je ne vérifier pas, pas plus que je teste le SNI.

Backend Pools

Lié à l'équilibrage de charge le Backend Pool interagit avec Health Monitor afin de répartir la charge entre les différents Real Servers. C'est une étape obligatoire, mais dans mon cas chaque Backend Pool ne contiendra qu'un seul Real Server.

Rules & Checks

On se s'occupe pas de Health Monitor mais de :

Conditions : ici on défini des conditions qui vont nous servir dans les règles ou l'on pourra utiliser plusieurs conditions. La condition la plus utilisée est Host matches : www.canaletto.fr mais on peut également travailler sur les chemin afin de traiter une URL (langue, sécurité, GeoIP...).
Rules : ici on défini une règle qui valide une ou plusieurs conditions (IF, AND, OR) et fonction de ces conditions on redirige vers un Backend Pool (on peut faire plein d'autres choses en fonction d'une condition, je vous laisse découvrir).

Public Service

C'est le FrontEnd qui va être exposé sur Internet via les ports que nous avons ouvert sur le firewall. C'est également ici que va se faire la sécurisation via le SSL Offloading, pour faire court la sécurisation et le SSL en utilisant un certificat lié au serveur web à publier (il est également possible de faire du SSL/HTTPS en mode TCP pour d'autres usages). On défini principalement :

L'adresse IP publique et le port sur lequel on écoute (il peut y en avoir plusieurs, identiques avec des ports différents, ou une adresse interne pour un usage sur un réseau d'entreprise par exemple).
Le certificat correspondant au site que l'on veut publier (ici aussi il peut y en avoir plusieurs, cela peut être utile par exemple dans le cas d'une société qui change de nom, ou d'une marque blanche qui exploite le même service sous plusieurs URL).
Toute les options le SSL, niveau TSL, restrictions, HTS, etc... (on est rapidement perdu et il vaut mieux s'appuyer sur des exemples car c'est plein de gros mots...).
Et enfin la sélection des règles correspondant aux services qui seront proposées par ce Front End. Par exemple, si je publie deux sites qui utilisent un même certificat, il y aura deux règles, bien que l'on puisse faire une règle OR qui propose les deux sites.

On voit ici que l'outil est très malléable et qu'il y a souvent plusieurs façons de procéder pour parvenir à la même fin.

HTTP to HTTPS

S'il y a bien une fonction que devrait se faire en un clic c'est bien la redirection des requêtes reçues sur le port 80 vers le HTTPS en port 443. Ici il va nous falloir :

Une condition pour indiquer que le trafic n'est pas du SSL.
Une règle qui s'appuie sur cette condition et fait un http-request-redirect avec scheme https code 301 en paramètres.
Un Front End (Public Service) qui :
écoute sur IP_Publique:80
fait du SSL Offloading
et utilise la règle crée.

Ainsi toutes les requetés non HTTPS qui arrivent naturellement sur le port 80 seront redirigées vers le port 443 de la même IP Publique. Simple !

TEST / Qualité

Afin de valider le résultat on va s'appuyer sur la page de test de Qualys SSL Labs (attention à bien cocher la petite case...). Et l'objectif est d'obtenir au minimum un A+, et même si vous n'en aviez jamais à l'école (comme moi), ici c'ets important !