Accès Sécurisé HCL et HC2 avec Reverse Proxy

[MAM78 408]

il y a 1 minute, jojo a dit :

le loopback, me permet de tester des liens externes depuis mon LAN (jaccède à mon Syno depuis mon LAN, en entrant le lien externe, comme si j'étais à l'extérieur)

Ca s'active comment et ça s'utilise comment ?

[MAM78 408]

est-ce ça dont il s'agit ?

 

https://dpfpic.com/article32/utiliser-un-nas-synology-pour-contourner-l-absence-de-loopback-sur-livebox

[i-magin 864]

Lorsque j'avais encore mon routeur Linksys, la fonction loopback n'était pas prise en compte (contrairement à la Freebox). Une mise à jour du firmware avait apporté cette possibilité.

 

Avec ma gateway Ubiquiti USG, je peux depuis mon Lan sortir sur le Wan pour revenir sur ma box Jeedom via un port "forwardé" (loopback)

 

Par contre, j'ai constaté que cela ne fonctionnait pas avec le DNS dynamique (souscrit avec le pack Ultimate de Jeedom)

Evidemment, pas de souci lorsque je me connecte depuis l'extérieur

Mais si je veux faire des tests depuis mon Lan avec PC sous Windows 10 et quel que soit le navigateur (Chrome, edge ou Firefox), j'obtiens un time out

Ce qui est très curieux, c'est que je n'ai pas ce problème avec un iPhone ou iPad et Chrome

J'ai essayé de désactiver le firewall de mon PC sans succès

 

[Nico 2 155]

Moi je fais mes tests en me connectant au boulot, et donc je reviens bien par l'extérieur, et comme dit, c'est quelques secondes pour la prise en compte.

[Kana-chan 66]

Bonsoir,

 

La livebox v4 possède le loopback.

 

Voilà ...

 

[MAM78 408]

et la v3 ?

 

mais de toute façon ça n’a pas l’importance pour moi puisque je n’utilise pas le routeur orange j’utilise mon routeur Synology.

 

La solution passe donc par la mise en place d’un service DNS privé

[Kana-chan 66]

Bonjour,

 

Non ma v3 ne le permet pas.

 

Voilà ...

 

[Lazer 8 473]

Vous avez testé la sécurité du chiffrement de votre reverse proxy ?

 

De mon coté je me suis motivé pour mettre à jour mon reverse proxy avec HAProxy sous Debian.

Je suis passé à la dernière version 1.8.x, appliqué quelques paramètres pour optimiser tout cela, et je suis passé d'une note A sur https://www.ssllabs.com/ssltest/ à une note A+, donc la meilleure possible

 

Ce qui m'a motivé à la base, ce n'était pas tant la sécurité SSL, que l'amélioration des performances.

La version 1.8 apporte le support du protocole HTTP/2 qui va remplacer petit à petit le HTTP/1.1 historique.

Et je dois dire que je suis impressionné par les perfs, le gain le plus flagrant est avec l'application DS Cam sur mobile... A vue de nez je dirais que c'est 10 fois plus rapide qu'avant, la connexion et l'affichage du flux vidéo en direct sont quasi instantanés, aussi bien en Wi-Fi local qu'en 4G distante (la Fibre est exploitée à sa juste valeur)

 

Par contre, problème de login sur les pages des produits de chez GCE Electronics... Eco Devices et IPX800 v4.

J'ai réussi à trouver une solution de contournement pour l'Eco Devices (limitation à 1 connexion simultanée, ce qui fait perdre le bénéfice du HTTP/2), mais ça fonctionne. En revanche pour l'IPX800 v4, rien à faire, impossible de charger la page, pourtant j'ai passé un moment à tuner pas mal de paramètres. Je pense que ça me fait comme @BenjyNet. Dès que je désactive HTTP/2, l'IPX800 se charge parfaitement. Mais je préfère conserver HTTP/2 pour que tous les autres sites en bénéficient, tant pis pour l'IPX800, je n'ai pas besoin d'y accéder à distance.

[BenjyNet 1 200]

Yep, tout pareil, je suis A+ et HTTP/2 ! Bon je suis pas fou finalement :-)

Faudrait peut etre faire la demande à GCE de faire évoluer tout ça non ?

[Lazer 8 473]

J'y ai pensé, mais ils n'arrivent déjà pas à ajouter un truc aussi simple que la méthode PUT dans les requêtes PUSH (dont on a besoin pour l'API de la HC2), alors modifier la config du serveur Web, ça va être chaud.

Comme c'est de l'embarqué, ils n'utilisent pas un serveur Web standard (Apache, Nginx, Lighthttpd, etc), mais un truc "jesaispasquoi" allégé, qui doit avoir un support très limité du protocole HTTP (bien plus complexe qu'on ne le pense)

[Lazer 8 473]

Dites donc, pour ceux qui ont mis en place ce tutoriel, pouvez-vous, avec Firefox ou Chrome (ça ne fonctionne pas avec IE, mais peut-être que ça fonctionne aussi avec les autres navigateurs modernes), tenter d'ouvrir une page Web sur https://votre_ip_publique

 

Là normalement, vous n'aurez accès à rien, mais juste une erreur de certificat.

En cliquant sur le bouton pour voir les détails, le navigateur vous donne le domaine pour lequel le certificat par défaut a été signé... si c'est le cas, vous donnez au visiteur une porte d'entrée, car vous ne pouvez plus cacher vos sites internes derrière votre nom de domaine.

 

En tout cas c'est comme cela que ça fonctionne avec HAproxy. Comment le Synology gère la chose ?

 

Il y a 2 solutions :

- générer un certificat auto-signé avec un nom de domaine bidon (genre localhost)... mais il faut une autorité de certification

- générer un certificat signé par Let's Encrypt, en utilisant le reverse DNS associé à votre IP publique

Le certificat ainsi obtenu pourra être utilisé par défaut, losque le visiteur entre une URL non valide. De la sorte, il n'obtient aucune info sur ce qui est hébergé derrière.

[Nico 2 155]

Moi j'ai un HA Proxy sur Syno mais sans https, et je n'ai pas ce cas.

[Lazer 8 473]

Sans https, normal, puisqu'il n'y a pas de certificat par définition.

 

Là je parlais bien de https avec certificat signé

[Kana-chan 66]

Il y a 5 heures, Lazer a dit :

En cliquant sur le bouton pour voir les détails, le navigateur vous donne le domaine pour lequel le certificat par défaut a été signé... si c'est le cas, vous donnez au visiteur une porte d'entrée, car vous ne pouvez plus cacher vos sites internes derrière votre nom de domaine.

Bonsoir,

 

Je ne comprends pas cette phrase : cacher ses sites internes ?

Perso, si je mets l'adresse IP publique, j'arrive sur le même site web que j'ai que si j'utilise l'url avec le nom de domaine.

Seule, différence : il demande une exception pour le certificat car dans la signature il n'y a pas son adresse IP publique (normal, puisqu'elle change souvent dans mon cas).

Quand j'affiche les détails de mon certificat, celui-ci ne montre alors que l'url avec nom_de_domaine qui amène à ce site. Pas tous les autres sites accessibles avec xxx.nom_de_domaine.

 

Voilà ...

 

[minos 27]

Hello,

 

Pour ma part , je n'arrive pas à créer un certificat let's encrypt depuis le syno...

 

j 'ai un échec de l’opération ...

 

même en désactivant le pare-feu su syno , le port 80 est bien ouvert sur ma freebox à destination du syno ....

 

ben là je ne vois pas trop ...

 

ça m'énerve ....

 

 

 

 

[Lazer 8 473]

il y a 23 minutes, Kana-chan a dit :

Perso, si je mets l'adresse IP publique, j'arrive sur le même site web que j'ai que si j'utilise l'url avec le nom de domaine.

Alors là c'est pire que tout, et c'est bien là le problème, en gros ta porte d'entée est grande ouverte, le reverse proxy n'apporte pas de sécurité supplémentaire. Autant ne rien mettre, ça fait moins de travail.

 

On en avait discuté il y a quelques pages, le minimum vital c'est de configurer ton reverse proxy pour que le site par défaut soit une poubelle, mais surtout pas un vrai site interne.

 

Mais évidemment ça ne suffira pas, car comme je disais plus haut, si le certificat publique est exposé, n'importe quel visiteur "voit" le domaine, et il est assez facile de trouver les différents sous-domaines.

C'était l'objet de ma question initiale, j'aimerais bien connaitre le comportement de vos configs.

@MAM78, @BenjyNet, ... ?

 

EDIT : je pose la question par courtoisie et pour faire avancer le débat, car il m'est assez facile de trouver vos IP publiques et d'aller fouiner moi même.... mais ça n'est pas étique.

Modifié 29 avril 2018 par Lazer

[BenjyNet 1 200]

Bah fouine chez moi, ça me gène pas  Si tu trouves une faille, préviens juste

 

[jojo 2 612]

je ne suis pas sûr de comprendre tout ce que vous dites, alors si je dis une bêtises, soyez indulgent.

 

Si j'ai bien compris donc, si on affiche les détails du certif, il dit pour quel(s) sous-domaine(s) il a été généré,  d'où le problème.

La solution serait alors de générer un certif pour tous les sous-domaines.

J'ai trouvé ceci, mais pas encore lu ni essayé :http://www.nas-forum.com/forum/topic/59433-tuto-certificat-tlsssl-lets-encrypt-wildcard/

ne serait-ce pas la solution ?

 

[Kana-chan 66]

Il y a 10 heures, Lazer a dit :

On en avait discuté il y a quelques pages, le minimum vital c'est de configurer ton reverse proxy pour que le site par défaut soit une poubelle, mais surtout pas un vrai site interne.

 

Bonjour,

 

C'est justement un site poubelle qui est retourné.

 

Voilà ...

 

[Lazer 8 473]

OK donc si tu as un site poubelle, c'est déjà pas mal.

 

Je reprends mon explication afin d'essayer de me faire comprendre.

 

Je scanne Internet....soit avec un robot (99% des logs de vos firewalls viennent de robot, souvent en Russie/Chine), afin d'obtenir une liste d'IP avec des ports ouverts.

Alternative : je connais déjà votre IP parce que je vous cible particulièrement, donc je n'ai plus qu'à scanner vos ports ouverts (avec "nmap" ça prend quelques minutes)

Admettons que votre IP publique c'est 1.2.3.4

Si vous avez appliqué ce tuto, vous avez 2 ports ouverts : 80 (http) et 443 (https).

Je prend mon navigateur (Firefox parce que c'est mon préféré, mais ça peut aussi être Chrome ou encore un autre, bref, tout navigateur moderne sauf Internet Explorer).

J'ouvre une page Web sur http://1.2.3.4

Là je vois un site "poubelle" que le reverse proxy me renverra, par exemple une page blanche avec un code 403 (je vous laisser faire le test sur votre propre IP). Je ne peux pas aller plus loin.

 

Maintenant, avec le navigateur, j'ouvre une page sur https://1.2.3.4 (donc sur le port 443 que le navigateur va automatiquement sélectionné car je lui ai demandé du https sécurisé)

Première chose que je constate, un avertissement de sécurité, car le domaine de l'URL demandée (1.2.3.4) ne correspond pas au domaine pour lequel le certificat par défaut (*) a été signé. Supposons que votre domaine soit mondomaine.com, on est tous d'accord pour dire que mondomaine.com <> 1.2.3.4 (simple comparaison textuelle)

Là où ça devient intéressant, c'est que je clique sur le bouton pour voir les détails du message d'avertissement et du certificat... et on voit clairement apparaitre le nom du domaine "mondomaine.com" (je ne met pas de capture d'écran, faites le test avec votre IP publique)

 

Intéressant tout ça, ce nom de domaine me donne une piste.

• Premier cas, ce certificat par défaut (*) contient déjà un sous-domaine (exemple hc2.mondomaine.com). Bingo, j'ai juste à ouvrir une fenêtre sur https://hc2.mondomaine.com et là j'ai accès à votre HC2. Si celle-ci fonctionne sous une vieille version de Debian avec une vieille version de Apache et des pages web développées par un stagiaire (c'est une exemple fictif hein.... ou pas), il y a de bonnes chances de trouver des failles de sécurité et de les exploiter. Exemple, la faille permettant de rooter la HC2 via l'interface Web publiée en septembre dernier (et corrigée en vitesse par Fibaro, comme quoi quand ils veulent, ils peuvent). Une fois le serveur rooté, c'est la porte d'entrée à tout votre LAN... et là je ne parle pas que de domotique. Il devient très facile de rooter les caméras Hikvision non patchées, les TV connectées, accéder aux fichiers du NAS, etc.
   
• Second cas, soit parce que le certificat par défaut (*) ne m'a pas donné de sous-domaine, et/ou parce que j'ai envie de découvrir tous les autres sous-domaines liés à votre nom de domaine, il existe différentes méthodes pour parcourir les arborescences DNS et tenter de découvrir tous les sous-domaines.... ça ne fonctionne pas à tous les coups, mais on peut trouver des choses intéressantes. A ce moment là, tout les sous-domaines que je vais trouver vont me donner autant de points d'entrées que nécessaire pour me connecter à vos équipements internes au travers de votre reverse proxy, qui fera simple son job, rien de plus.

 

En bref, le Reverse Proxy vous permet de chiffrer la connexion https entre votre navigateur client et votre serveur à la maison, et c'est tout. Il est incapable de cacher les équipements internes sur votre réseau. En fin de compte, il n'apporte pas plus de sécurité que d'ouvrir un ensemble de ports sur votre routeur, face à un pirate qui veut pénétrer votre réseau.

 

 

(*) certificat par défaut : c'est bien là tout le problème. Votre reverse proxy a pris l'un de vos certificats (signé par Let's Encrypt dans les règles de l'art) et s'en est servit pour répondre à la requêtes générique https://1.2.3.4

Le choix du certificat ne se fait pas au hasard, avec HAproxy il prend le premier par ordre alphabétique parmi la liste des certificats que vous avez généré.

Prenons un exemple, j'ai fait signer 3 certificats :

- mondomaine.com (la racine de mon domaine)

- hc2.mondomaine.com (Fibaro)

- dsm.mondomaine.com (Synology)

Le premier par ordre alphabétique, c'est dsm.mondomaine.com !!! Il est critique celui-là en plus (par chance Synology met à jour régulièrement les failles de sécurité, mais on n'est jamais à l'abri)

Donc le visiteur verra immédiatement par quelle porte d'entrée passer pour avoir accès à un premier équipement, sans même avoir besoin de commencer une recherche DNS.

 

Est-ce bien clair maintenant ?

 

Pour répondre à Jojo, le fiat de faire signer un certificat Wildcard (valable pour *.mondomaine.com) ne change strictement rien au problème, votre domaine sera toujours visible dans le certificat par défaut présenté par le serveur Web lors d'une requête https.

 

On notera tout le comique de la situation, le port 80 non sécurisé ne donne aucune information, tandis que le port 443 sécurisé permet de récupérer des informations !!!

 

 

Donc maintenant la solution

 

Il faut se débrouiller pour que le reverse proxy présente un certificat différent, qui ne fasse pas du tout partie de votre domaine, lors d'une requête web générique (le fameux https://1.2.3.4)

Donc on va générer ce certificat.

Comme je le disais hier, je connais 2 méthodes :

• Générer son propre certificat auto-signé avec une autorité de certification maison. Cela se fait très bien sous Linux, mais nécessite quand même un certain nombre de manipulations, et d'avoir un Linux sous la main. Pour info on utilise les outils de la suite OpenSSL tout simplement (OpenSSL est utilisé sur la très grande majorité des systèmes Linux, notamment pour faire fonctionner SSH, et votre navigateur et serveur Web en https. Autant dire que n'importe quel Linux devrait pouvoir agir comme autorité de certification).
  Une fois qu'on a obtenu ce certificat, on modifie la configuration de notre Reverse Proxy pour lui dire de l'utiliser par défaut (ça se fait très bien avec HAproxy, je ne sais pas ce qu'il en est avec Synology DSM comme présenté dans ce tuto).
  En conséquence, quand le visiteur se pointe sur https://1.2.3.4, le reverse proxy lui présentera ce certificat auto-signé, il aura quand même un message d'avertissement signalant que le certificat n'est pas valide (puisqu'auto-signé et non signé par une autorité de certification reconnue telle que Let's Encrypt), mais ce n'est pas un souci... en regardant les détails du certificat, il ne verra qu'un nom de domaine bidon, celui que vous avez choisi au moment de la génération avec OpenSSL sous Linux. Donc il ne sera pas plus avancé.
  Bien sûr, si l'utilisateur est légitime (vous), et demande d'accéder à https://dsm.mondomaine.com, alors le reverse proxy lui présentera le certificat associé à ce domaine et correctement signé par Let's Encrypt, et tout fonctionnera normalement.
   
• Générer un certificat signé avec une autorité de certification reconnue telle que Let's Encrypt (de la même façon que vos certificats habituels pour mondomaine.com). L'astuce consiste ici à faire un reverse DNS lookup de votre IP publique (nslookup 1.2.3.4 sous Windows, ou dig -x 1.2.3.4 sous Linux). Le nom de domaine ainsi obtenu correspond à celui de vote opérateur, par exemple bidule.abo.wanadoo.fr. Il n'y a plus qu'à demander à Let's Encrypt de nous signer un certificat avec ce nom de domaine, elle sera en mesure de le signer car vous êtes bien propriétaire de l'IP associée à ce domaine (au moins pendant 24h si votre IP change tous les jours).
  Avantage, il n'y a pas besoin de taper la 10zaine de commande nécessaires pour générer un certificat auto-signé sous Linux, et ce certificat présenté par défaut au visiteur sur https://1.2.3.4 sera valide, donc la navigateur n'affichera même pas un message d'avertissement. Cela n'apporte par de sécurité supplémentaire par rapport au certificat auto-signé, mais c'est plus propre.
  Inconvénient, il faut régénérer ce certificat tous les 3 mois maximum (limitation Let's Encrypt), mais normalement vous avez déjà un script pour regénérer vos certificats légitimes mondomaine.com régulièrement, il suffit de l'utiliser.

 

[BenjyNet 1 200]

T'as testé chez moi @Lazer ? Me semble que j'ai aucun des 2 cas :-\

[Lazer 8 473]

Non pas encore

[Lazer 8 473]

Alors chez BenjyNet, c'est très bien, aucune information n'est divulguée

 

Le certificat présenté est un certificat auto-signé par Synology.

 

Donc ça répond parfaitement à mes interrogations.

Le Reverse Proxy ne présente pas l'un de vos certificats par défaut, mais le siens (auto-signé, d'où l'avertissement de sécurité), qui est générique et en donne aucune informations de domaine.

 

Bref, parfait

 

[BenjyNet 1 200]

Ah good :-) hehehe 

[Lazer 8 473]

Je précise, parce que la capture d'écran n'est pas claire (j'ai caché trop d'infos).

Les zones rouges barrées sont l'adresse IP publique, donc aucun nom de domaine n'apparait.