VPN Server Message "Risque probable de sécurité" lors de la connexion à DSM

[CyberFr]

Bonjour,

J'ouvre une connexion VPN et d'après ce que j'ai pu lire dans le tuto VPN Server (*), il faut se connecter aux équipements locaux en utilisant leur adresse locale. Mais lorsque je me connecte à DSM en utilisant une adresse de type "https://192.168.1.X:port à joindre" Firefox me signale un problème de sécurité puisque le certificat LE ne voit pas le nom de domaine. Si je passe en force, je risque de créer une exception de sécurité.

Par contre lorsque je me connecte avec le nom de domaine "https://ndd.fr:port à joindre", tout se passe normalement puisque le certificat reconnaît le nom de domaine. Puis-je choisir cette deuxième approche sachant que DNS Server est configuré sur le NAS et qu'il gère les adresses locales conformément au tuto DNS Server.

(*) Mais c'est confus car Fenrir indique qu'il utilise  systématiquement le nom de domaine, autant pour les connexions locales que pour les connexions distantes.

[Jeff777]

il y a 6 minutes, CyberFr a dit :

Puis-je choisir cette deuxième approche sachant que DNS Server est configuré sur le NAS

Bien sûr. Et avec le loopback tu n'as même pas besoin de mettre le port en utilisant les proxy-inverses.

[oracle7]

@CyberFr

Bonjour,

il y a 15 minutes, CyberFr a dit :

en utilisant une adresse de type "https://192.168.1.X:port à joindre" Firefox me signale un problème de sécurité puisque le certificat LE ne voit pas le nom de domaine

C'est normal ce message, un certificat est définit pour un nom de domaine et JAMAIS pour une @IP.

Et comme tu as installé DSN Serveur tu as donc une zone DNS locale qui résolvera tous tes domaines, en conséquence je dirais même que tu as même intérêt à utiliser ces derniers tout le temps en conjonction du Reverse Proxy comme te l'as dit justement @Jeff777.

Cordialement

oracle7😉

 

[CyberFr]

Merci pour vos réponses. Parce que le tuto VPN Server n'est pas vraiment clair sur le sujet, en tout cas pour moi.

À l'avenir j'utiliserai systématiquement le nom de domaine.

[CyberFr]

Je vais peut-être dire des bêtises - et n'hésitez pas à me corriger si je me trompe - mais ce qui me dérange avec le reverse proxy, c'est qu'il me semble diminuer la sécurité du NAS car tout passe par le port 443 qui est ouvert sur l'extérieur. Cela pose problème pour certains services sensibles.

Je m'explique. J'ai changé le port par défaut de DSM en HTTPS et il n'est accessible qu'en local. Le trafic sur le port HTTP de DSM n'est pas redirigé vers le NAS et n'est pas autorisé dans le pare-feu. Pour accéder au port HTTPS il faut donc être sur le réseau local ou passer par le VPN.

Si après la mise en place du reverse proxy un pirate tente nas.ndd.fr, syno.ndd.fr, ds220.ndd.fr etc et qu'il trouve la bonne porte d'entrée, il n'a pas besoin de connaître le port attribué à DSM puisque le reverse proxy redirige la requête vers le bon port, c'est déjà une faiblesse. Et comme le port 443 est ouvert sur l'extérieur, il suffit de trouver le bon mot de passe. Je trouve que c'est une vulnérabilité.

[.Shad.]

Tu as les profils de contrôle d'accès pour filtrer les IP que tu autorises à utiliser une entrée de proxy inversé en particulier.
Sinon les éventuels attaquants n'ont pas besoin de "trouver" les ports, ils font bêtement un "nmap" sur ton IP publique, et ils récupèrent tous les ports ouverts depuis leur IP.

[CyberFr]

Pour le coup, j'ai fait une recherche Startpage sur Nmap. Je progresse 🙂 Mais les attaquants, depuis leur IP peuvent-ils voir un port qui n'est accessible qu'en local ? Et même s'ils le voient et qu'ils tentent de passer par la, le pare-feu du NAS va leur barrer la route non ?

[oracle7]

@CyberFr

Bonjour,

Il y a 2 heures, CyberFr a dit :

Et comme le port 443 est ouvert sur l'extérieur, il suffit de trouver le bon mot de passe. Je trouve que c'est une vulnérabilité.

Et qu'en bien même le port 443 est ouvert sur l'extérieur :

• d'une part avec l'usage du Reverse Proxy, il est normalement le seul (sauf exceptions nécessaires à certaines applications) à être ouvert et il n'y passe que des flux cryptés HTTPS,
• d'autre part avec des identifiants à "100 lieues" des identifiants courants et des mots de passes d'au moins 12 caractères (plus est même encore mieux) constitués de caractères standards majuscules, minuscules et chiffres, ton malveillant, même avec de grosses ressources, risque fort de passer pas mal de temps (qu'il n'a sûrement pas) à décrypter ces mots de passes. Tout cela en conjonction du blocage d'@IP failban et du contrôle d'accès évoqué très justement par @.Shad., je crois sans trop m'avancer que tu es bien paré pour faire face à cette "vulnérabilité". Maintenant ce que j'en dis ...

Cordialement

oracle7😉

 

Modifié le 26 septembre 2021 par oracle7

[CyberFr]

Comme quoi ,lorsque je n'hésite pas à faire part de mes doutes, je progresse !