Home Assistant & SSL

Maintenant que votre serveur Home Assistant est en place, il va falloir le faire communiquer avec l'extérieur de la façon la plus sécurisée possible. Sur le principe on ouvre le port (TCP/8123 en général) sur le routeur et on redirige le flux vers le serveur local. Je ne vais pas vous faire un dessin, d'autres l'ont fait. Ensuite il va falloir d'occuper de la mise en place du certificat SSL

Pour faire court deux cas de figure se présentent.

Soit votre fournisseur d'accès vous met à disposition une IP fixe, soit non, et c’est hélas le cas de beaucoup. Certains comme Free fournissent maintenant une IP fixe partagée, dans ce cas il faut demander via l'interface une IP full range. Si vous disposez de votre propre nom de domaine, et ce n'est absolument pas obligatoire pour ce genre de site, par essence privé, on va privilégier Let's Encrypt.

  • IP Fixe + Nom de domaine : Add-on Let'sEncrypt.
  • IP Dhcp avec ou sans nom de domaine : Add-on DuckDNS

L'add-on Let's Encrypt

Il s'installe depuis le superviseur et peut s’appuyer sur les API d'OVH, Gandi et CloudFlare (et bien d'autres). Si tout est bien renseigné comme ci dessous par exemple, en quelques minutes vous obtenez votre certificat et le tour est joué.

email: [email protected]  # Pour Let's Encrypt
domains:
  - ha.domain.tld  #  Domaine don le DNS est chez CloudFlare
certfile: fullchain.pem
keyfile: privkey.pem
challenge: dns
dns:
  provider: dns-cloudflare
  cloudflare_email: [email protected]  # Votre compte Cloudflare
  cloudflare_api_token: vYffF-LzhdhdhdgfhjhjjFGJFDGJJGsfgFGJSgjf

L'add-on DuckDNS

Il s'installe depuis le superviseur et nécessitera la création d'un compte sur www.duckdns.org afin de préparer la configuration. L'avantage de cet add-on c'est qu'il va tenir informé DuckDNS de vos changements d'IP.

lets_encrypt:
  accept_terms: true
  certfile: fullchain.pem
  keyfile: privkey.pem
token: 952ddsfsdf5-b1sfse-43gfsdgsdfg81-10sgsgdsg2e
domains:
  - ha.domain.tld  # Le domaine choisit lors de la création du compte.
aliases: []
seconds: 300

Alternatives

Pourquoi se compliquer la vie ? Il y a qui aiment ça... Vous pouvez donc utiliser un autre service tout autant gratuit, par exemple...

  • La passerelle SSL d'OVH qui va jouer un rôle de reverse proxy également (à condition d'avoir une IP fixe,). Dans ce cas on a la choix localement d'utiliser un certificat auto signé soit pas de SSL.
  • L'intégration CloudFlare qui semble utilisable sans IP fixe. Voir également ici pour utiliser un certificat CloudFlare.

Reverse Proxy

Se protéger avec une reverse proxy est une très bonne idée. On peut bien sur installer en local NGINX (et le configurer...) ou utiliser un reverse proxy existant dans votre infrastructure (Synology, ou HA Proxy dans pfSense par exemple), mais le plus simple est de déléguer la chose à un reverse proxy CDN, je pense bien sur à CloudFlare, en utilisant ou pas leur certificats. Attention toutefois, CloudFlare n'autorise pas tous les ports, et notamment pas le 8123, il va donc falloir ruser, soit utiliser un port externe et un port interne, soit changer le port de Home Assistant.

Que vous utilisiez ou pas un reverse proxy, il faudra vous arranger pour localement outrepasser le reverse ou le port externe de votre routeur. Inutile en effet d'aller faire un tour sur Internet pour utiliser une requête locale. En plus en cas de panne internet ça ne marcherait plus. Pour ça il faut un DNS menteur local, ça peut être un fichier host sur un PC, un DNS local sous Linux ou Windows, mais je vous conseille plutôt d’installer l'excellent add-on AdGuard qui en plus de dépolluer vos pages web fera également ce travail grâce à sa fonction de réécriture DNS. Bien sur dans ce cas il faudra que votre DHCP local pointe sur ce DNS...

Exemple

Ici j'ai configuré de façon à se que l'accès externe passe par le reverse proxy de CloudFlare (sur le port 2096), ce qui protège mes IP, j'ai fait une redirection DNS locale via AdGuard et j'utilise une URL interne sur mon mobile ou mon accès local sur PC.

URL Home Assistant : https://ha.domain.tld:2096 (pour CloudFlare par exemple).

SSID : Mon SSID (c'est sert au client mobile à savoir s'il faut appeler l'URL interne).

URL Interne : https://ha.domain.tld:8123  (ce sera également l'url local depuis un PC.)

N'hésitez pas à commenter si vous avez des questions.

Exception d'un chemin http dans HA Proxy sous pfSense

J'utilise HAProxy sous pfSense pour publier divers sites. Outre l'économie d'adresses IP, j'augmente la sécurité, je peux faire de la répartition de charge et je profite des certificats Let's Encrypt via le plugin Acme.

Tout fonctionne très bien, sauf sur un site ou pour lequel une URL en http a été codée en dur dans un logiciel distribué aux quatre coins du monde, logiciel que les utilisateurs rechignent à mettre à jour. Ce process http fait du GET et du POST et après avoir testé une redirection http vers https de type 308 au lieu de 301 sans grand succès, je me suis dit que la seule solution consisterait à contourner le problème... en faisant une exception pour l'url du formulaire.

Explications (en partant du principe que le lecteur connait un peu le couple pfSense / HAProxy)

  1. Je crée un SharedFrontEnd HTTPS sur une IP publique de type http / https (OffLoading) en SSL OffLoading sur le port 443
  2. Je crée un premier FrontEnd qui s'appuie sur le SharedFrontEnd HTTPS avec le certificat qui va bien, cela qui va faire transiter le flux HTTPS vers mon BackEnd. On vérifie le bon fonctionnement depuis un navigateur avec https://www.domain.tld. OK.
  3. Je crée un SharedFrontEnd HTTP sur la même IP publique de type http / https (OffLoading) sans SSL OffLoading sur le port 80
  4. Je crée un second FrontEnd qui s'appuie sur le SharedFrontEnd HTTP qui lui va faire transiter en HTTP mon exception via deux ACL (hostname + path) vers mon Backend avec ces deux conditions (au sens HAProxy) et redirigera tout le reste vers le premier FrontEnd en HTTPS grâce à une règle qui exclut mon exception.

 

Voici le règle de redirection que l'on peut également placer en custom rule.

http-request redirect code 301 location https://%[hdr(host)]%[path] unless REG_PATH

J'avoue que j'en ai un peu bavé (avec l'aide de Victor), mais ça prouve une fois de plus qu'il y a peu de choses en la matière que l'on ne peut faire avec le couple pfSense / HAProxy. D'ailleurs, je ne vais pas l'expliquer ici car je n'ai fait que suivre un bon tuto, mais il est parfaitement possible de publier ainsi un serveur Exchange avec répartition de charge et éviter de coûteux répartiteurs de charge.

Sources :

 

SSL mi amor… & pfSense

On ne vantera jamais assez les mérites d’un reverse proxy en termes de sécurité. Mais au-delà de la sécurité, un reverse proxy peut aussi nous faciliter la vie pour la publication de services web en mode sécurisé, et donc la gestion des certificats.

Si selon le niveau de protection et d’assurance il faudra continuer à acheter des certificats hors de prix, dont la sécurité a parfois été corrompue même chez les soi-disant plus sérieux fournisseurs, pour bien des services l’utilisation de certificats Let’s Encrypt fera parfaitement l’affaire.

Au passage vous noterez que si j’étais fan de Sophos XG, je suis en train de m’orienter vers pfSense que je trouve bien plus simple et mieux documenté par la communauté.

Il y a plusieurs façons d’utiliser Let’s Encrypt :

  • Via un script ou un logiciel installé sur le backend (le serveur web) qui génère le certificat, il faudra ensuite l’exporter manuellement ou via un script vers le reverse proxy si on en utilise un en frontal, mais on peu aussi passer en direct, en NAT ou une simple redirection de ports.
  • Via un script géré par le firewall / reverse proxy. C’est ce que je vais décrire ici en utilisant pfSense ou j’installerais les paquets Acme et HAProxy.

Acme

Automated Certificate Management Environment, for automated use of LetsEncrypt certificates.

Cette implémentation très complète va nous permettre de générer et renouveler automatiquement des certificats Lets’s Encrypt (Standard, Wilcard ou San) et de les installer dans pfSense. Cette implémentation sait s’appuyer sur les API des principaux DNS, ce qui nous évitera d’avoir à ouvrir un port 80 comme cela était nécessaire auparavant. Le plus simple sera de générer un wilcard : *.domaine.tld.

Il sera également possible d’exporter ces certificats, manuellement, ou via un script vers un serveur web si nécessaire (par exemple, un script PowerShell sur un serveur Exchange pour récupérer les certificats, les installer et les activer).

Dans notre exemple on n’exporte rien car on va se servir de HA Proxy comme Frontend, c’est à lui qu’incombera la gestion du SSL (le SSL Offloading consiste à déporter la gestion du SSL sur le reverse proxy / load balancer, et donc sur le serveur web on ne laisse que le service HTTP, les sessions HTTPS n'étant cryptées qu'entre l'internaute et le reverse proxy qui peut également jouer un rôle d’équilibreur de charge si nécessaire).

HA Proxy

The Reliable, High Performance TCP/HTTP(S) Load Balancer.

Il s’agit ici d’un reverse proxy moderne qui permet également d’équilibrer la charge vers plusieurs Backends.

On aurait pu utiliser le paquet Squid, mais je lui reproche de ne pas gérer SNI (à vérifier) et donc de ne pouvoir servir plusieurs domaines en SSL. Squid est toutefois plus simple et fera l’affaire pour une installation simple ou domestique. A noter également que tant HA Proxy que Squid permettent de publier un serveur Exchange, et donc de remplacer avantageusement de vieux ISA ou TMG que Microsoft nous a tant vanté avant de les oublier…

Je ne vais pas reprendre un fastidieux steep by steep de publication il y en a de très bien faits… mais juste résumer :

  1. Installation de pfSense (il y a des VM toutes prêtes) avec un lien WAN et un lien LAN. On peut éventuellement ajouter des IP virtuelles (VIP) coté WAN si on en dispose.
  2. On crée une règle sur le firewall ou on autorise le port 443 (HTTPS) en entrant sur le WAN.
  3. Sur HA Proxy on crée un Backend avec l’IP interne sur le port 80 (ou autre) et sans SSL (sans car on pourrait également sécuriser le flux interne). Dans les options de LoadBalancing on choisit None si on a qu’un Backend, et dans ce cas on n’oublie pas de choisir également None au niveau Health checking. Et c’est tout, le reste si on ne sait pas, on ne touche pas.
  4. Sur HA Proxy on crée un Frontend qui écoute sur le port WAN (ou VIP), on coche SSL Offloading et plus bas dans SSL Offloading on choisit le certificat lié au domaine que l’on va utiliser (une règle Frontend par domaine géré). Dans Default backend, access control lists and actions on va gérer nos serveurs en utilisant l’expression Host Matches et la valeur, par exemple canaletto.fr que l’on nomme www (inutile si on n’a qu’un seul serveur à sécuriser). Ensuite plus bas dans Actions on va dire que la condition www est redirigée vers le Backend idoine. Ici aussi, c’est tout, le reste si on ne sait pas, on ne touche pas, car comme vous pourrez l’observer HA Proxy dispose d’une multitude d’options qui ne seront utiles que dans certains cas.

Test

Pour tester ce genre de configuration l’idéal est de disposer une machine connectée sur l’internet en dehors de votre réseau. La machine d’un ami en remote (TS, TeamViewer, NoMachine ou AnyDesk) ou encore une machine connectée en 4G.

Comme à ce stade on n’a probablement pas encore renseigné le DNS public, le plus simple est de créer une entrée dans le fichier hosts (sous Windows le plus simple est d’utiliser HostMan). 

Ensuite on lance une session dans le navigateur et on vérifie que c’est vert et que le certificat est valide et correspond bien à celui utilisé. Si c’est le cas il n’y a plus qu’à s’occuper du DNS public.

Info

Vous imaginez bien que je n’ai pas creusé ce sujet uniquement pour publier un Jeedom. Au départ il s’agissait de publier des serveurs Microsoft Exchange avec des certificats SAN classiques et couteux, et quand on publie de l’Exchange on peut faire à peu près tout. Ensuite j’ai trouvé la gestion Let’s Encrypt tellement simple dans pfSense que je me suis dit que finalement cet outil embarqué dans une VM ou un petit Appliance pouvait d’adapter à toutes les situations, même les plus simples. Du coup je vais probablement remplacer Sophos XG et pourquoi pas également chez moi à la place ou à côté de l’USG qui est très bien pour le trafic sortant mais n’évolue pas trop et ne permet pas de faire du reverse proxy.

Sources

https://pixelabs.fr/installation-configuration-pfsense-virtualbox/https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html

https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://pixelabs.fr/installation-role-transport-edge-2016-partie-2/
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://www.supinfo.com/articles/single/6326-mise-place-serveurs-web-haute-disponibilite-avec-haproxy-pfsense
https://www.itwriting.com/blog/9592-publishing-exchange-with-pfsense.html
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://forum.netgate.com/topic/99804/squid-reverse-proxy-for-multiple-internal-hosts
https://tecattack.ch/index.php/2018/12/10/pfsense-2-4-4-haproxy-reverse-proxy-multiple-http-server-ubuntu-16-04/
https://all-it-network.com/pfsense-reverse-https/
https://blog.devita.co/pfsense-to-proxy-traffic-for-websites-using-pfsense/

Jeedom : SSL avec Cloudflare

Pour sécuriser un site en SSL il y a plusieurs façons de faire, comme je l’avais expliqué ici. Si on passe outre les modèles payants, Let’s Encrypt qui impose l’ouverture du port 80 pour son renouvellement, il nous reste la passerelle OVH qui ne permet pas facilement une sécurisation de bout en bout. On va voir aujourd’hui comment utiliser l'alternative Cloudflare pour sécuriser de bout en bout en utilisant le certificat qu’ils fournissent gratuitement et qui ont la bonne idée d’avoir une durée de vie très longue (auto-renouvellement pendant 15 ans). Ce tuto est fait pour Jeedom sur Debian, mais on peut tout à fait utiliser cette technique sur un autre serveur, IIS sur Windows par exemple.

L’utilisation de Cloudflare sous-entend que le DNS du domaine soit géré par le Cloudflare. Ça peut paraître gênant mais au final c’est pas mal du tout car leurs DNS sont pratique et des plus rapides, notamment en réplication. Quand on va créer un domaine sur Cloudflare, celui-ci va aspirer notre ancienne configuration DNS et en créer une copie. Il n’y aura plus ensuite qu’à se laisser guider pour changer les serveurs de nom sur son registrar (Gandi, OVH, etc…), ce qui peut prendre un peu de temps avant d’être activé.

Une fois le domaine géré par Cloudflare il y a deux onglets qui nous intéressent ici, DNS et Crypto (allez fouiller car il y a plein d’autres choses intéressantes à explorer).

Sur DNS on va créer un enregistrement A (et AAAA si on veut être compatible IPV6) qui va pointer sur l’IP publique de notre serveur (ou un CName vers un DynDNS, je n’ai pas testé mais ça peut marcher, auquel cas ça deviendrait intéressant pour ceux qui n’ont pas d’IP fixe).

Ensuite on passe sur Crypto et on va créer un certificat que l’on prendra soin de récupérer (attention à bien stocker également la clé privée en .key). Voilà, pas besoin de CSR, le certificat est un willcard, ce qu’il veut dire qu’il pourra être utilisé pour d’autres sous-domaines (jeddom.domaine.tld, cam.domaine.tld …). C’est possible car son usage est conditionné par le transit via Cloudflare qui joue un rôle de reverse proxy. Donc ce certificat n’est pas utilisable (quoique...) sans Cloudflare et il ne sert qu’à sécuriser le flux entre Cloudflare et votre serveur.

Il suffira alors d’installer le certificat, facile sous IIS après une conversion en PFX, là c’est mon monde et j’ai l’habitude. Sous Jeedom, donc le couple Linux et Apache, j’ai un peu plus tâtonné car je ne suis pas dans mon domaine de compétence, mais Google est mon ami et j’ai fini par trouver en compilant plusieurs sources.

Activer SSL et installer le certificat sur le serveur Jeedom

Il va falloir se connecter en « root » sur le serveur Jeedom. Pour y parvenir il faut commencer par autoriser le SSH sur le user « root ». J’utilise BitWise SSH Client, mais on trouve d’autres alternatives et ce n’est pas très important. 

  • Login en SSH avec l’utilisateur « pi » + le mot de passe « raspberry » que vous avez j’espère changé au début de l’installation..
  • Edition du fichier de configuration avec la commande « sudo nano /etc/ssh/sshd_config.
  • Ici on change la ligne #PermitRootLogin without-password (ou un autre attribut) en en PermitRootLogin yes.
  • On ferme (ctrl + X) et on sauvegarde (Y) + validation.
  • Enfin on active avec sudo /etc/init.d/ssh restart.

On en profite pour changer le mot de passe « root » avec sudo passwd root (idem pour le user « pi » si on ne l’a pas fait).

On se déconnecte et on se reconnecte avec le user « root ».

A l’aide du gestionnaire de fichiers on va copier le certificat et sa clé privée quelque part (dans /etc/apache2 pour cet exemple).

Ensuite on va aller ajouter un serveur virtuel et dire à apache ou sont les certificats en ajoutant une section <VirualHost * :443> dans le fichier /etc/apache2/sites-enabled.conf (possible également depuis le gestionnaire de fichiers si on n'est pas fan de Nano).

<VirtualHost *:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog /var/www/html/log/http.error
SSLEngine      on
SSLCertificateFile        /etc/apache2/domain.tld.pem
SSLCertificateKeyFile     /etc/apache2/domain.tld.key
</VirtualHost>

On sauvegarde et on active le SSL avec un sudo a2enmod ssl. On peut aussi faire un apachectl configtest. En l’état ça ne doit nous retourner que l’erreur AH00558, ce qui veut juste dire qu’on n’a pas renseigné le bon hostname et qu’on l’attaque en local. Pas important dans notre usage.

On relance Apache avec systemctl reload apache2.

On se connecte pour tester depuis le PC avec « https://ip-du-pi » et on by-pass l’erreur qui est normale car un certificat est toujours lié à un domaine et non une iP. A ce stade on va renseigner nos infos dans Jeedom sur l’onglet « réseaux ». Mais là ça ne sert que d’information à Jeedom, par exemple pour appliquer la bonne config au client mobile.

Sur le routeur, le firewall ou là box on crée une règle qui va accepter une connexion externe sur le port 2053 et la renvoyer sur le port 443 de l’ip du Pi. Pourquoi 2053, simplement parce que Cloudflare n’accepte pas toutes les ports et qu’on va éviter d’utiliser le 443 (mais c’est possible).

Maintenant on va tester depuis l’extérieur (un mobile en 4G par exemple) et vérifier que la connexion est bien SSL de bout en bout.

That’s all folks !

Utiliser un certificat Cloudflare en local

Peut-on utiliser les certificats Cloudflare en dehors de leur DNS ? Par exemple pour l’installer sur des équipements locaux qui ne sont accessibles qu’en HTTPS (routeurs par exemple) et ne plus avoir les erreurs de sécurité des navigateurs. En fait la réponse est oui, mais il va falloir tricher un peu.

D’abord le certificat est lié au domaine, donc il ne fait plus appeler l’équipement par son IP mais par une url https://routeur.mondomain.tld . Pour y parvenir il faudra soit avoir un DNS interne et tricher en donnant à Cloudflare un CNAME local monrouteur.domain.local mais c’est contraignant), soit tricher avec le fichier HOSTS (et là je vous conseille cette petite merveille, Hostmanager), c’est parfait car en général cette utilisation ne concernera qu’une seule machine qui sert à l’administration.

Ensuite il faudra aussi truster le certificat RSA de Cloudflare que l’on trouvera ici. Sous Windows, par exemple, il faut le convertir en PKCS#7 (on peu aussi le faire en local avec OpenSSL) avant de l’importer dans les autorités trustées (On peut utiliser MMC + certificats, ou l'outil Digicert, ou encore Keystore Explorer qui fonctionne sur toutes les plateformes..

Et le tour est joué !

Sources :

 

SSL mi amor...

Au-delà des sites qu’il faut absolument protéger dès lors qu’il y a des transactions, bientôt les sites non SSL seront tous pointés du doigt.

Pour passer un site en SSL il y a plusieurs options plus ou moins complexes. Si le site est protégé par un firewall il faudra généralement exporter le certificat vers celui-ci ou simplement l’installer sur le firewall si l’on considère que le trafic entre le firewall / reverse proxy et le serveur n’a pas à être protégé.

On trouve des certificats plus ou moins couteux selon les garanties offertes, mais pour protéger un simple site un certificat à une dizaine d’euros sera suffisant car il s’agit de sécuriser la transaction et non de valider l’origine du site. (GoGetSSL par exemple ou même Gandi)

Let's Encrypt est une solution gratuite avec ses limitations et contraintes. Les certificats sont ici valables que 3 mois et les maintenir à jour est fastidieux. En gros c'est parfait s'il s'agit d'un Synology, par exemple, ou la gestion du renouvèlement est intégrée (elle impose tout de même l'ouverture du port 80), mais moins pratique sur certains serveurs ou équipements s’il faut faire les mises à jours manuellement. Sur IIS (et ailleurs) des solutions permettent cette automatisation, comme Certify the web ou Lets’Encrypt Win Simple.

Attention, si les versions récentes de IIS supportent plusieurs sites en SSL via SNI, il n’en est pas de même pour des versions plus anciennes.

Enfin, pour les fainéants comme moi il y a SSL Gateway d’OVH. C'est basé sur du Let’s Encrypt et gratuit. En gros OVH fait le boulot et ça permet de passer en SSL n'importe quel site ou équipement. Il n’y a rien à faire sur le serveur à protéger. On redirige l’enregistrement DNS du serveur vers le serveur d'OVH et ensuite sur le serveur protégé on n'accepte que les requêtes en provenance de la passerelle d'OVH. Attention les statistiques peuvent êtres faussées, mais c’est prévu et il y a bien une astuce pour ça. Vous trouvez un pas à pas ici.

La solution d’OVH à ses limites et dans certains cas cette passerelle ne fera pas l’affaire. Le certificat est sur la passerelle et le trafic entre la passerelle et le serveur passe en clair. Ça peut être satisfaisant d’un point de vue sécurité car on aura pris soin de n’accepter que les requêtes de la passerelle OVH, mais le serveur à protéger sera en HTTP et non HTTPS. Dans certains cas l’url vue par le serveur est importante, notamment en .net ou le serveur va retourner http://serveur et non https://serveur et créer des dysfonctionnements avec du code imbriqué qui s’appuie sur cette url, sur ce site par exemple avec Disqus. Alors bien sûr on pourrait aller tripatouiller le code mais ce ne serait qu’une rustine. Pour bien faire il faudrait qu’OVH fournisse un certificat que l’on installerait sur le serveur et ainsi on serait en SSL de bout en bout.

Alors en cherchant un peu on trouve la solution Cloudflare qui va faire la même chose en mieux et pour pas un sous tant qu’il s’agit d’un trafic raisonnable. Cloudflare fourni un certificat que l’on pourra aisément installer sur le serveur à protéger et le cas échéant sur le firewall intermédiaire. Les explications sont ici. Même si on peut le contourner, la solution la plus simple consiste à rediriger ses DNS vers ceux de Cloudflare.

Sophos XG Firewall Home Edition

On parle souvent de PF Sense et d’autres firewalls plus ou moins gratuits, moi je vais vous parler de Sophos XG dont la version Home est une version logicielle gratuite qui est parfaite pour un environnement de test ou un home lab. C'est le même logiciel que l'on retrouve sur les appliances du constructeur à ceci près qu'il faudra le faire tourner sur une petite machine ou une VM.

Il offre une protection complète de votre réseau, notamment anti-malware, filtrage Web et sécurité Web, contrôle des applications, IPS, gestion du trafic, VPN, rapports et surveillance, et bien plus encore. Le pare-feu Sophos XG Free Home Use contient son propre système d'exploitation, par conséquent, un ordinateur dédié distinct est nécessaire, qui deviendra une Appliance de sécurité entièrement fonctionnelle. Parfait pour un NUC ou une VM. Si Sophos est utilisable pour protéger les services entrants (mail, web) en direct ou en reverse proxy, il prend en compte très finement le trafic sortant afin de lisser et hiérarchiser le trafic des applications sur votre connexion Internet et même vous abonner à plusieurs FAI pour obtenir davantage de bande passante ou de résilience en cas de panne de l'un d'eux. Il est possible de surveiller et contrôler la navigation web, d'utiliser le filtrage Web pour empêcher les sites de vous infecter de virus et de logiciels espions, empêchez vos enfants de surfer sur des sites malveillants et d'obtenir un rapport complet sur l'activité de votre maison. On peut également configurez des horaires d’accès ou des quotas d’utilisation pour les membres de la famille qui perdent peut-être trop de temps en ligne. C'est également un serveur VPN pour accéder à votre réseau à distance depuis n'importe où dans le monde. Sophos étant également un fournisseur notoire d'antivirus, cette fonctionnalité est intégrée. Les moteurs d'analyse Dual AV bloquent les virus dans les téléchargements de fichiers, les pièces jointes aux e-mails et les sites web malveillants. Sophos les stoppe sur la passerelle avant qu'ils ne puissent attaquer vos ordinateurs. Et bien plus encore ...

Ce dont vous avez besoin,  simplement un ordinateur compatible Intel avec deux interfaces réseau ou une VM. (Tout système d'exploitation précédent ou tous les fichiers présents sur l'ordinateur seront écrasés lors de l'installation de XG Firewall Home Edition.) L'édition familiale et gratuite est limitée à 4 cœurs et à 6 Go de RAM. L'ordinateur peut en avoir plus que cela, mais XG Firewall Home Edition ne pourra pas l'utiliser. Mais c'est déjà largement suffisant dans bien des cas d'exploitation.

Ah si, j'oubliais, dans le cadre d'un usage familial il vaut mieux que l'un des membres de la famille soit un bon geek, car ne nous y trompons pas, Sophos XG est un vrai produit d'entreprise qui ne s'installe pas en un clic...