[Tuto] Reverse Proxy

[.Shad.]

Salut @Pinpon_112,

Tu as bien autorisé les règles pour Bond 1, en revanche rien pour l'IPv6 en local ? Ou alors tu as désactivé le protocole ? Au besoin, dans le nouveau tutoriel de sécurisation tu trouveras la règle à ajouter pour l'IPv6.

Et tu as bien pensé à refuser l'accès pour le reste, donc hormis sur les règles en elles-même qui je l'imagine répondent à un besoin réel et ma remarque précédente concernant l'accessibilité en IPv6, ça me semble ok.

[Pinpon_112]

Hello @.Shad.,

Merci pour le retour.  L'IPv6 est désactivé.

[mick45000]

Bonjour,en  créant  un reverse proxy  (https://audio.ndd.fr) pour l'application audio j'ai la page suivante qui s'affiche

SYNOLOGY

Désolé, la page que vous recherchez est introuvable.

ça marche très bien avec https://ndd.fr/audio

J'ai oublié  un paramétrage quelconque?

[CMDC]

Le reverse proxy c'est fait pour "mettre en relation" des noms externes et des port externes ( 443 ou 80 ) (ex http[s]://ndd.fr:[80|443]) avec des nom internes et des port internes (ex: http[s]://localhost:xxxx ou http[s]://192.x.y.z:xxxx)  .

Mais pas des url compliquées (!) ex https://ndd.fr/xxxx ...
Ce que tu cherches à faire s'appelle une "redirection web" généralement faite chez ton hébergeur de domaine  : https://audio.ndd.fr -> https://ndd.fr/audio/ (301 ou 302) 

EDIT > Naturellement audio.ndd.fr doit être aussi déclarée dans ton DNS comme un enregistrement CNAME 

Modifié le 1 janvier par CMDC

[CyberFr]

Il y a 17 heures, mick45000 a dit :

J'ai oublié  un paramétrage quelconque?

 

Il y a 14 heures, CMDC a dit :

EDIT > Naturellement audio.ndd.fr doit être aussi déclarée dans ton DNS comme un enregistrement CNAME 

Ce n'est pas nécessaire pour les applications comme Synology Photos, File Station ou Audio Station qui figurent dans le Portail de connexion dans l'onglet Applications.

[mick45000]

Bonsoir,

C'est bon ça marche merci, à part dans destination je passe en https car en http cela me marque :

400 Bad Request

The plain HTTP request was sent to HTTPS port

[Mic13710]

Il y a 2 heures, mick45000 a dit :

à part dans destination je passe en https car en http

Parce que vous avez validé le transfert http vers https. Et ça, le reverse proxy n'aime pas.Je vous conseille de désactiver cette fonctionnalité et de mettre en place un .htaccess qui se chargera de faire cette opération. Vous trouverez comment en feuilletant ce tuto et le forum.

[mick45000]

il y a 2 minutes, Mic13710 a dit :

Parce que vous avez validé le transfert http vers https. Et ça, le reverse proxy n'aime pas.Je vous conseille de désactiver cette fonctionnalité et de mettre en place un .htaccess qui se chargera de faire cette opération. Vous trouverez comment en feuilletant ce tuto et le forum.

Effectivement je mettais arrêter là dans le tuto faute de temps .

Merci je vais reprendre.

[Alm]

Le 20/02/2018 à 9:11 AM, Kawamashi a dit :

L'option de redirection présente dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM n'est pas envisageable car elle casse le mécanisme du reverse proxy.

Merci Kawamashi!! Je ne comprenais pas pourquoi je n'avais plus accès à mes applications... il m'a suffit de revenir sur ton tutoriel, de revenir directement sur la partie certificat et cette phrase m'a permis de régler mon problème en quelques secondes !!

Visiblement, dans un moment de fatigue et de bonnes intentions, j'avais coché la fameuse case en me disant que ce serait mieux ainsi... sauf que j'avais complètement oublié ce petit clic la fois où j'ai voulu accéder à une application (!).

Bref, super tuto... et merci encore!

[Madi]

Bonjour,

J'ai utilisé OVH pour le NDD

J'ai déclaré A mon NDD --> mon Ip Fixe v4 (checker en SSH sur le NAS)

AAAA mon NDD --> mon Ip Fixe v6

CNAME audio.mon NDD --> mon NDD

CNAME video.mon NDD --> mon NDD

J'ai vérifié sur : https://www.whatsmydns.net/#A/ Tout est UP

J'ai autorisé dans le firewall de la freebox pro toutes les IP sur port 80,443 vers l'IP Fixe de mon NAS 80,443

J'ai activé le firewall du NAS et laisse tout passer en entrant

J'ai défini des ports customs dans la partie Application pour Audio Statio et Video Station

J'ai rentré les règles proxy reverse, j'ai décoché (mais après) la redirection HTTP vers HTTPS

J'ai rajouté le fichier .htaccess avec le bout de code

Rien n'y fait Let's Encrypt me dit toujours qu'il ne peut pas valider le nom de domaine et impossible d'obtenir ce foutu certificat.

J'ai oublié quelque chose ?

 

EDIT : Apres m'etre cassé la tête, voici mes propres solutions.

Dans l'interface Firewall de ma Freepro je n'avais pas bien mis en place les règles de NAT vers mon NAS.

En effet, il ne faut pas renseigner les ports SOURCE, mais seulement DESTINATION et Redirection de port.

Enfin, n'ayant pas réussi à créer de record CNAME www.mon NDD --> mon NDD il m'est impossible de le mettre comme sous domaine dans la demande de certifcat car n'étant pas reconnu, Let's Encrypt rejette la demande.

Modifié le 8 avril par Madi

[Nicolas Morel]

Bonjour,

Petit souci lorsque je configure le reverse proxy le Synology m'indique que le nom de domaine existe déjà et m'oriente à prendre un autre...

Hors je ne vois aucune trace de ce NDD dans n'importe quel configuration du Synology, si vous avez une idée ?

Merci par avance.

Bien à vous.

Modifié le 9 avril par Nicolas Morel

[CyberFr]

il y a 43 minutes, Nicolas Morel a dit :

Petit souci lorsque je configure le reverse proxy le Synology m'indique que le nom de domaine existe déjà et m'oriente à prendre un autre...

Si ton nom de domaine est ndd.fr le nom d'hôte doit être par exemple music.ndd.fr.

[Jeff777]

Il y a 1 heure, Nicolas Morel a dit :

Hors je ne vois aucune trace de ce NDD dans n'importe quel configuration du Synology

Regarde dans ton certificat les noms de domaine affectés (panneau de confi/sécurité/certificat et double clic sur le certificat.)

[RealJesus]

Le 09/04/2024 à 4:17 PM, Nicolas Morel a dit :

Bonjour,

Petit souci lorsque je configure le reverse proxy le Synology m'indique que le nom de domaine existe déjà et m'oriente à prendre un autre...

Hors je ne vois aucune trace de ce NDD dans n'importe quel configuration du Synology, si vous avez une idée ?

Merci par avance.

Bien à vous.

Hello,

est-ce que tu as déjà utilisé ce ndd via webstation pour un portail web basé sur le nom ?

si oui, c'est là qu'il est déjà utilisé.

[Flamby55]

Bonjour,

J'ai le même souci que @Nicolas Morel, et comme je vois pas la solution je reposte avec mes détails : 

J'ai bien un ndd.synology.me qui fonctionne (statut "normal" dans le menu correspondant, créé il y a quelques jours en suivant le tuto sur la sécurisation, et testé en local via une application mobile).

J'ai créé dans Système/Portail de connexion/Applications un alias (pour l'exemple : drive), port (par ex. 7000) et domaine (drive.ndd.synology.me).

Quand je vais dans le menu reverse proxy pour créer une règle , je saisi donc comme source (sur le protocole https) drive.ndd.synology.me et j'ai donc le message d'erreur comme quoi il est déjà utilisé...
Quelqu'un aurait une solution ou identifié quelque chose que je fais mal ?

J'en profite pour poser 2 questions :

• A quoi sert le Profil de contrôle d'accès ?
• Je n'ai pas la possibilité d'activer http/2, cette fonction n'apparait pas, est-ce important ? si oui comment faire ?

Merci d'avance !

[CoolRaoul]

Pour les applications natives (comme Drive ici) il suffit de déclarer comme tu l'as fait un alias dans le portail de connexion.
Le service sera accessible via l'URL https://ndd.myds.me/drive


Pas besoin de reverse proxy

[Flamby55]

Ok, merci pour ta réponse.

Qu'est-ce que tu appelles appli natives ? C'est tous les paquets officiels qu'on peut installer ? ou bien ceux qui sont installé à l'origine sur le NAS ?

Et est-ce que la mise en place de l'alias seul (sans donc suivre tout le tuto) permettra aussi le fonctionnement depuis l'extérieur ?

Car c'est un peu mon but, mettre en place le reverse proxy pour éviter de faire plusieurs redirections de port pour les appli que je veux pouvoir utiliser à distance (Drive, Photos, Surveillance Station, File) comme me l'a conseillé @.Shad. dans le tuto "sécurisation du NAS".

[CoolRaoul]

il y a une heure, Flamby55 a dit :

Qu'est-ce que tu appelles appli natives ?

Celles pour lesquelles le portail de connexion permet se définir un alias. 

il y a une heure, Flamby55 a dit :

Et est-ce que la mise en place de l'alias seul (sans donc suivre tout le tuto) permettra aussi le fonctionnement depuis l'extérieur ?

Tout à fait

Accéder à des applications par un alias (pour celles qui le permettent) c'est équivalent à mettre en place une déclaration reverse proxy pour celles qui n'ont oas cette option (que ca soit des applications Synology ou pas)

[Flamby55]

Ok, merci pour ces explications. 

Du coup la partie VII du tuto sur la création d'un fichier htaccess via le web station est-elle nécessaire ? Sachant que je vais quand même avoir besoin du reverse proxy pour la connexion à distance à mon système d'alarme qui ce fait via le port 443 uniquement.

[CoolRaoul]

il y a 7 minutes, Flamby55 a dit :

 la partie VII du tuto sur la création d'un fichier htaccess via le web station est-elle nécessaire ?

J'avoue ne pas avoir eu le courage de me palucher ce tuto. Je suis intervenu dans ce fil en voyant que ca parlait de reverse proxy et, comme je l'utilise, j'ai pensé pouvoir être utile et surtout expliquer là ou il n'est pas nécessaire (aliases).

Il est possible que ce htaccess ajoute des règles de sécurité/contrôle d'accès supplémentaires, où que ca s'applique à des applications spécifiques, mais je ne sais pas j'avoue.

[Jeff777]

Il y a 16 heures, Flamby55 a dit :

A quoi sert le Profil de contrôle d'accès ?

Bonjour,

Le contrôle d'accès permet de créer des règles autorisant la connexion en fonction de l'adresse IP de l'émetteur de la requète.

On peut créer différents profils de contrôle d'accès et sur chaque reverse-proxy attribuer un profil.

Personnellement j'ai créer un profil "local et VPN", ce qui me permet d'autoriser la connexion à certains reverse proxies sensibles (comme par exemple DSM) uniquement aux connexion sur le réseau local ou via VPN Serveur. Cela ajoute une sécurité au couple identifiants/mot-de-passe.

Il y a 12 heures, Flamby55 a dit :

Du coup la partie VII du tuto sur la création d'un fichier htaccess via le web station est-elle nécessaire ?

A mon avis oui. Ce fichier permet de transformer toute reqête en http en https donc chiffrée

 

Il y a 13 heures, CoolRaoul a dit :

Celles pour lesquelles le portail de connexion permet se définir un alias. 

C'est une affaire de goût mais je préfère utiliser le reverse-proxy avec contrôle d'accès pour l'ensemble des applis qu'elle soient natives ou non. Je n'ai que des accès au nas sous la forme service.ndd même pour mes sites web hébergés , mes dockers ou virtual hosts.

 

[CoolRaoul]

il y a 37 minutes, Jeff777 a dit :

A mon avis oui. Ce fichier permet de transformer toute reqête en http en https donc chiffrée

En effet, mais comme je l'ai mentionné antérieurement, je n'ai toujours pas compris en quoi forcer https pouvait contribuer à protéger le serveur. Un potentiel attaquant ne dispose d'aucun avantage du fait que les connexions entrantes en HTTP sont accessibles. Et les utilisateurs légitimes, si par mégarde ils forcent "http:" dans l'URL (dans quel but d'ailleurs ?) , seront prévenu par une alerte de "connexion non sécurisée" dans leur navigateur.

Mais *surtout*, la redirection forcée http=>https est déjà configurable dans l'interface DSM, dans la section portail de connexion : 

 

Et, même si le libellé parle de "DSM desktop", ça s'applique en pratique également aux services des applications accédées via des alias déclarés dans cette même section du panneau de configuration (je viens de vérifier).
De ce fait, je ne vois pas trop l'intérêt de se compliquer à la vie à le faire via un .htaccess

Modifié le 12 juin par CoolRaoul

[Jeff777]

il y a 13 minutes, CoolRaoul a dit :

En effet, mais comme je l'ai mentionné antérieurement, je n'ai toujours pas compris en quoi forcer https pouvait contribuer à protéger le serveur. Un potentiel attaquant ne dispose d'aucun avantage du fait que les connexions entrantes en HTTP sont accessibles. 

Forcer le https protège d'une potentielle surveillance extérieure.

il y a 17 minutes, CoolRaoul a dit :

Et les utilisateurs légitimes, si par mégarde ils forcent "http:" dans l'URL (dans quel but d'ailleurs ?) , seront prévenu par une alerte de "connexion non sécurisée" dans leur navigateur.

Un utilisateur extérieur qui se connecte en http voit son adresse transformée en https. Sa connexion est sécurisée et il n'a aucune alerte.

il y a 18 minutes, CoolRaoul a dit :

Mais *surtout*, la redirection forcée http=>https est déjà configurable dans l'interface DSM, dans la section portail de connexion : 

Oui c'est vrai mais dans le passé, cocher ce paramètre pouvait créer un bug. Maintenant ça limite aux connexions DSM, c'est pour cette raison que je préfère .htaccess. 

De plus dans .htaccess j'ai également le HSTS préload de configuré.

[CoolRaoul]

il y a 1 minute, Jeff777 a dit :

Forcer le https protège d'une potentielle surveillance extérieure.

Je serai intéressé par un cas d'usage pratique alors.

Ce qui sera interceptible en clair par cette surveillance est uniquement le traffic des sessions venant d'utilisateurs assez stupides pour choisir explicitement de se connecter en http (car laisser la possibilité de se connecter en HTTP n'oblige personne à le faire). Les utilisateurs les plus lambda ne savent même pas de quoi il s'agit et donc utiliseront l'url (de type https donc) qu'on leur a communiquée. Et les autres n'ont aucune raison de le faire.

Sinon, reste aussi la solution radicale de fermer le port 80 (sauf que ça pose un problème avec le renouvellement des certificats SSL Lets Encrypt, mais je ne suis pas sûr que ça s'applique aux domaines synology.me, myds.me etc qui utilisent peut-être un autre mécanisme pour le renouvellement... ,à tester)

il y a 24 minutes, Jeff777 a dit :

Maintenant ça limite aux connexions DSM

non, j'ai testé comme je l'ai écrit : 

il y a 49 minutes, CoolRaoul a dit :

Et, même si le libellé parle de "DSM desktop", ça s'applique en pratique également aux services des applications accédées via des alias déclarés dans cette même section du panneau de configuration (je viens de vérifier).

 

il y a 6 minutes, CoolRaoul a dit :

Et, même si le libellé parle de "DSM desktop", ça s'applique en pratique également aux services des applications accédées via des alias déclarés dans cette même section du panneau de configuration (je viens de vérifier).

Alors j'avoue ne pas avoir suffisament testé
Ca fonctionne en effet pour une connexion via un navigateur, mais pas contre par dans par exemple l'appli mobile (DS File)

il y a 9 minutes, CoolRaoul a dit :

Alors j'avoue ne pas avoir suffisament testé
Ca fonctionne en effet pour une connexion via un navigateur, mais pas contre par dans par exemple l'appli mobile (DS File)

Ah ben non, pas si sur finalement : j'ai activé une capture (tcpdump) sur le port 80, forcé la connexion DS File en http, et il semble bien que ça bascule en https aussi

[PiwiLAbruti]

Il y a 14 heures, Flamby55 a dit :

Du coup la partie VII du tuto sur la création d'un fichier htaccess via le web station est-elle nécessaire ?

Oui et non, car les navigateurs internet finalisent la période de transition sur le choix de HTTP ou HTTPS par défaut.

Il y a peu encore, lorsqu'un utilisateur entrait le nom de domaine d'un site dans la barre d'adresse sans préciser le protocole à utiliser (par exemple nas-forum.com), le navigateur envoyait par défaut une requête HTTP (http://nas-forum.com). La redirection vers HTTPS devait alors être faite explicitement par le site lui-même comme le fait le fichier .htaccess de ce tutoriel.

Depuis quelques mois maintenant, la plupart des navigateurs effectuent directement une requête HTTPS par défaut (nas-forum.com > https://nas-forum.com). Si le site ne répond pas en HTTPS, le navigateur fait alors une deuxième tentative en HTTP.

Au final, selon le navigateur utilisé le .htaccess peut être nécessaire. Pour ma part, j'ai banni ce protocole et fermé le port tcp/80.

----

Je viens de voir que Firefox fait toujours ses requêtes en HTTP par défaut 🤦‍♂️. Il faut aller dans sur la page de configuration about:config et passer le paramètre dom.security.https_first à true pour que HTTPS soit utilisé par défaut.