[Tuto] Reverse Proxy

[Invité]

Il y a 18 heures, JPnux a dit :

Avec le nom de domaine, on peut connaitre l'adresse IP de notre domicile du coup...

Tu peu passer par CloudFare*  pour résoudre ce "soucis"

 

* pour ne cité que le plus connu

[JPnux]

Il y a 23 heures, PiwiLAbruti a dit :

Il n'y a pas de risque particulier à découvrir un nom de domaine, ni les adresses IP vers lesquelles ses enregistrements peuvent pointer.

De quoi as-tu peur exactement ?

As-tu suivi le tutoriel sur la sécurité ?

oui pour le tuto de sécurité 🙂

Du moment où on est visible on peut etre une cible c'est tout.

Il y a 6 heures, Mic13710 a dit :

Bien sûr ! On ne prend pas d'abonnement internet, comme ça on n'a pas d'IP publique et, cerise sur le gâteau, on n'a pas besoin d'un nom de domaine 😉.

Trêve de plaisanterie, un nom de domaine est publique. S'il est bien paramétré dans sa zone DNS, il est propagé sur tous les serveurs DNS publiques around the world. Il peut donc être récupérable partout dans le monde. Ceci dit, si vous n'avez pas de site hébergé sur votre ndd et que vous ne le communiquez qu'aux personnes susceptibles de pouvoir l'utiliser, il y a peu de chance qu'il soit répertorié sur google ou autre et qu'il puisse intéresser un quelconque hacker.

Enfin, que votre ndd et votre IP publique puissent être connus n'a pas d'importance. Ce qui compte, ce sont les protections que vous mettez en place pour filtrer les connexions et ne laisser entrer que les ayants droits (tuto sur la sécurité).

Merci pour le 2nd paragraphe. Oui si pas de site hébergé ca limite l'exposition.

Il y a 6 heures, EVOTk a dit :

Tu peu passer par CloudFare*  pour résoudre ce "soucis"

* pour ne cité que le plus connu

C'est ce que je pensais oui, CloudFlare est une solution pour ca. Quelles sont les alternatives à CloudFlare d'ailleurs ? Y a t-il des équivalents européens ?

[PiwiLAbruti]

il y a 36 minutes, JPnux a dit :

Du moment où on est visible on peut etre une cible c'est tout.

Pas besoin d'un nom de domaine pour être une cible, une adresse IP suffit.

[JPnux]

Il y a 18 heures, PiwiLAbruti a dit :

Pas besoin d'un nom de domaine pour être une cible, une adresse IP suffit.

c'est certain. Après tout les pare feu sont là pour ca 😄

[JPnux]

Bonjour,

si on a déjà un domaine avec un certificat Let's Encrypt fourni par le fournisseur de nom de domaine, il faut en créer un autre pour le reverse proxy ?

[Mic13710]

Il faut importer le certificat dans le NAS ou en créé un. Pas de problème d'avoir plusieurs certificats pour un même ndd. C'est ensuite au niveau de l'application que le certificat à utiliser sera fait en fonction du paramétrage dans la page du certificat.

[JPnux]

j'ai du mal à comprend un truc... Si je veux utiliser DS Audio Android sur mon téléphone... en local il me suffit de l'adresse IP:5001 + nom d'utilisateur et mot de passe.

Si je veux maintenant y accéder depuis l'extérieur, il suffirait que je mette mon nom de domaine + le port 5001 (ouvert sur le routeur) non ?

Pas besoin de reverse proxy dans ce cas là ??

[MilesTEG1]

@JPnux
Oui tu peux faire comme ça.
Mais en procédant ainsi, tu dois ouvrir un port sur le routeur... Et donc augmenter les risques. Surtout si tu gardes le port par défaut.
Donc si tu ne souhaites pas utiliser le reverse proxy, met un autre port ouvert sur l'extérieur :
Genre 14200 --> 5001 NAS

Le reverse proxy te permettrais de ne pas avoir besoin de spécifier le port de connexion, juste ton nom de domaine. Ce que je trouve plus facile à retenir, surtout si tu as plein de services accessibles, donc plein de ports de connexion à ne pas avoir à mémoriser...

[JPnux]

merci pour ta réponse.

A retenir pas grand chose finalement car une fois que c'est configué dans les applis du téléphone c'est réglé.

Le reverse proxy trouve son utilité surtout pour un accès extérieur depuis un ordinateur exact ?

[MilesTEG1]

il y a 2 minutes, JPnux a dit :

Le reverse proxy trouve son utilité surtout pour un accès extérieur depuis un ordinateur exact ?

Depuis l'extérieur oui, peut importe le périphérique.
Mais ça peut permettre aussi d'avoir plusieurs serveurs utilisant le même port.
Exemple de plusieurs serveurs WEB, donc port 80 et 443.
Sans reverse proxy, c'est mort, un seul pourra fonctionner et être accessible depuis l'extérieur.

Autre raison pour moi : d'un point de vue sécurité, c'est mieux de ne pas ouvrir trop de ports sur l'extérieur, et de ne laisser ouvert que le 80 et le 443.

Je n'ai que ces deux ports ouvert et un de secours pour DSM c'est tout. (depuis que j'ai un routeur Synology, je n'ai même plus besoin d'ouvrir les ports pour mon serveur VPN ( OpenVPN et VPN L2TP ) vu qu'ils sont sur le routeur directement et plus sur le NAS.

Ha, je viens de vérifier, et je dois laisser ouvert aussi le port de CloudStation (même si c'est le client Drive que j'utilise)...
C'est d'ailleurs pas très normal...

[JPnux]

Dans mon cas aussi j'ai besoin uniquement d'ouvrir le 443 ?

 

[Juan luis]

il y a 7 minutes, MilesTEG1 a dit :

 

Je n'ai que ces deux ports ouvert et un de secours pour DSM c'est tout. (depuis que j'ai un routeur Synology, je n'ai même plus besoin d'ouvrir les ports pour mon serveur VPN ( OpenVPN et VPN L2TP ) vu qu'ils sont sur le routeur directement et plus sur le NAS.

 

Bonsoir,

Je me permet de vous demander une précision. Est ce que les ports du serveur VPN sont invisibles d'internet ? ou vous voulez dire qu'il ne sont pas ouverts vers le NAS ? Ce sujet m’intéresse car chez moi ces ports sont de temps en temps scannés . Du coup, je dois vérifier les logs de temps en temps  et bloquer les petits malins.

[MilesTEG1]

Et le 80 sinon tu pourras pas faire de certificat Let's Encrypt.

Mais en ce qui te concerne, si tu n'as qu'un seul service à ouvrir sur l'extérieur, peut-être juste une ouverture d'un port aléatoire > 20000 suffirait...

à l’instant, Juan luis a dit :

Bonsoir,

Je me permet de vous demander une précision. Est ce que les ports du serveur VPN sont invisibles d'internet ? ou vous voulez dire qu'il ne sont pas ouverts vers le NAS ? Ce sujet m’intéresse car chez moi ces ports sont de temps en temps scannés . Du coup, je dois vérifier les logs de temps en temps  et bloquer les petits malins.

Hmmmm, ce que vous dites m'inquiète...
Je n'ai pas ouvert ces ports du tout, mais ils sont accessibles puisque le routeur fait office de serveur VPN, donc il lui faut bien ces ports là.
Cependant, ils ne sont pas routés.

Vous regarder dans quels logs ces tentatives de connexion ?

[Juan luis]

il y a 21 minutes, MilesTEG1 a dit :

 

Hmmmm, ce que vous dites m'inquiète...
Je n'ai pas ouvert ces ports du tout, mais ils sont accessibles puisque le routeur fait office de serveur VPN, donc il lui faut bien ces ports là.
Cependant, ils ne sont pas routés.

Vous regarder dans quels logs ces tentatives de connexion ?

Comme , j'utilise un serveur VPN L2TP mais ce n'est pas un synology, un scan de ces ports se traduit par un début de tentative de connexion. De plus ces scans étant probablement programmés , ils se répètent . Bref , ça apparait dans la log avec l'IP source, et je les bloques . C'est souvent des IPs US et Russes.

 

 

Modifié le 6 février 2021 par Juan luis

[MilesTEG1]

il y a 12 minutes, Juan luis a dit :

Comme , j'utilise un serveur VPN L2TP mais ce n'est pas un synology, un scan de ces ports se traduit par un début de tentative de connexion. De plus ces scans étant probablement programmés , ils se répètent . Bref , ça apparait dans la log avec l'IP source, et je les bloques . C'est souvent des IPs US et Russes.

Je n'ai pas ces tentatives de connexions... 
Bon les IP russes et autres, sont interdites par le parefeu du routeur.

Bon du coup, pour le port 6690 pas le choix, obligé de le laisser ouvert sur l'extérieur dans le routeur, il n'est pas possible de le faire passer dans le reverse proxy avec un nom de domaine...

[oracle7]

@Juan luis

Bonjour,

Pour info, lors d'un scan externe, le malveillant recherche les ports connus d'une part mais aussi les ports ouverts derrière lesquels il y a un service/appareil de préférence actif qui va lui répondre. Si le service/appareil répond, de mémoire, il s'identifie et donc selon les failles connue pour ce service/appareil, le malveillant saura exploiter ces failles pour s'introduire dans le système. Dans le cas où le service ne répond pas ou qu'il n'y a pas de service derrière le port ouvert, alors le malveillant reçoit un message du type : "Reason: Connection refused". Normalement, le malveillant n'insiste pas et passe au port suivant par manque de temps pour creuser la chose.

Dans le cas ou le port est fermé le message renvoyé est du type  : "Reason: Connection timed out". Donc le malveillant normalement passe aussi son chemin (i.e. passe au port suivant) toujours par manque de temps.

Dans ton cas, les ports VPN sont donc ouverts et tu as un service derrière (le serveur VPN) qui répond. Mais heureusement, le système de blocage du NAS fait bien son travail de protection. Donc pas de soucis, sauf à s'inquiéter de la tentative d'accès. En bloquant en amont les @IP concernées, on ne fait que ne plus être avertit des tentatives liées à ces @IP.

Cordialement

oracle7😉

[JPnux]

Il y a 2 heures, MilesTEG1 a dit :

Mais en ce qui te concerne, si tu n'as qu'un seul service à ouvrir sur l'extérieur, peut-être juste une ouverture d'un port aléatoire > 20000 suffirait...

Oui alors je viens de tester, quand je rentre https://monip:port  ca fonctionne depuis l'extérieur. Je peux me connecter avec DS Audio par exemple. J'ai autorisé la connexion dans le pare feu du NAS d'ailleurs.

Mais ca ne marche pas avec https://ndd:port  ...  je ne comprends pas pourquoi ca ne marche pas avec le nom de domaine alors que ca marche avec mon IP (externe test depuis 4G)

Le nom de domaine me semble bien configuré pourtant avec le champ "A qui pointe vers mon IP..."

Modifié le 6 février 2021 par JPnux

[Juan luis]

il y a une heure, oracle7 a dit :

@Juan luis

Bonjour,

Pour info, lors d'un scan externe, le malveillant recherche les ports connus d'une part mais aussi les ports ouverts derrière lesquels il y a un service/appareil de préférence actif qui va lui répondre. Si le service/appareil répond, de mémoire, il s'identifie et donc selon les failles connue pour ce service/appareil, le malveillant saura exploiter ces failles pour s'introduire dans le système. Dans le cas où le service ne répond pas ou qu'il n'y a pas de service derrière le port ouvert, alors le malveillant reçoit un message du type : "Reason: Connection refused". Normalement, le malveillant n'insiste pas et passe au port suivant par manque de temps pour creuser la chose.

Dans le cas ou le port est fermé le message renvoyé est du type  : "Reason: Connection timed out". Donc le malveillant normalement passe aussi son chemin (i.e. passe au port suivant) toujours par manque de temps.

Dans ton cas, les ports VPN sont donc ouverts et tu as un service derrière (le serveur VPN) qui répond. Mais heureusement, le système de blocage du NAS fait bien son travail de protection. Donc pas de soucis, sauf à s'inquiéter de la tentative d'accès. En bloquant en amont les @IP concernées, on ne fait que ne plus être avertit des tentatives liées à ces @IP.

Cordialement

oracle7😉

 

 

Bonsoir  @oracle7,

Merci pour les infos.

Je n'ai que les ports VPN ouverts chez moi. Effectivement , pour rentrer , il faut trouver les différents passwords, la clé partagée...J'imagine que ça doit pas se faire en cinq minutes mais le fait est que tout ports ouvert est  détecté.

[MilesTEG1]

il y a 38 minutes, JPnux a dit :

Le nom de domaine me semble bien configuré pourtant avec le champ "A qui pointe vers mon IP..."

Alors, là je sais pas, j'ai jamais rien compris aux A AAAA, CNAME...
Moi j'ai configuré un DynHost qui est mis à jour sur le NAS car j'ai pas d'ip fixe, et qui concerne mon ndd principal, disons monNAS.ndd.tld

Mes autres domaines comme serv1.monNAS.ndd.tld sont des redirections CNAME vers monNAS.ndd.tld (me demande pas ce que c'est que CNAME, je sais pas 😅

 

[oracle7]

@MilesTEG1

Bonjour,

Un enregistrement CNAME en "language DNS" est un alias sur ton domaine ni plus ni moins.

Un enregistrement de type "A" sert à "relier" le domaine à une adresse IPv4. et un "AAAA" à une @IPv6.

Cordialement

oracle7😉

[dardevil91]

bonjour  , j'avoue être totalement perdu j'ai par défaut configurer depuis des années  mon nas avec un nom de domaine  .mais depuis un mois j'ai installé pour mon imprimante 3d  octoprint sur un raspberry et malheureusement celui-ci utilise aussi le port 80 .

Donc ma question est bien simple comment configurer  le port 80  pour que quand je tape  le bon nom de domaine j'arrive bien au bon endroit alors que les 2 utilises le port 80 ?

[MilesTEG1]

il y a 31 minutes, dardevil91 a dit :

bonjour  , j'avoue être totalement perdu j'ai par défaut configurer depuis des années  mon nas avec un nom de domaine  .mais depuis un mois j'ai installé pour mon imprimante 3d  octoprint sur un raspberry et malheureusement celui-ci utilise aussi le port 80 .

Donc ma question est bien simple comment configurer  le port 80  pour que quand je tape  le bon nom de domaine j'arrive bien au bon endroit alors que les 2 utilises le port 80 ?

Tu fais ça : 
 

[dardevil91]

merci beaucoup j'essaye de suite

[Diabolomagic]

Bonjour, j'ai mis en place grâce à ce tuto très bien fait le reverse proxy pour audio station, file station, surveillance station mais je n'ai aucune idée de comment faire pour avoir l'interface de DSM  ?

Quelques pistes seraient le bienvenue 🙂

 

[MilesTEG1]

@Diabolomagic C'est la même chose.
Tu rediriges vers le port de connexion à DSM, sur l'IP du NAS.
Il te faut un nom de domaine pour DSM. Et il faudra que tu crées un certificat LE pour ce nom de domaine.