CoolRaoul

La solution immédiate est donc de directement créer les partages nommés "multimédia" et "partages" (éviter "drive" qui pourrait devenir un jour un nom réservé) et affiner leurs droits d'accès selon les contraintes que tu souhaites leur imposer. (ou, comme dit @cadkey , un unique partage avec deux sous dossier, chacun avec des droits spécifique) mais il ne faudra pas oublier de donner au partage "maitre" un doit global (type lecture pour tout le monde, écriture désactivée) puis en dessous en ouvrant plus les droits. Et laisser "home" et "homes" avec leur configuration par défaut. Mais je persiste à m'étonner que tu indiques avoir créé *toi-même* "home" et "homes" alors qu'ils sont créés automatiquement par le système

C'est vraiment pas de chance : parmi les innombrables possibilités de choix de noms pour un dossier il a fallu tomber pile poil sur deux de ceux réservés par le système. C'est détaillé ici : https://kb.synology.com/fr-fr/DSM/help/DSM/AdminCenter/file_share_desc?version=6 Reste donc plus qu'à choisir autre chose. Au passage je me demande comment il à été possible en pratique de les *créer* alors que c'est fait automatiquement par la procédure d'installation. A noter aussi, pour lever toute ambiguïté, que "home" serait plutôt un dossier virtuel qui correspond dynamiquement au "$HOME" de l'utilisateur connecté (/home/<user>)

Ah en effet (et je le savait en plus) et j'ai zappé que @cadkey avait mentionné ce point important de contexte que c'est relatif uniquement aux certificats des noms fournis par le DDNS Synology. Mais le principal point de mon post était que je ne vois pas de risque supplémentaires face à des attaques externes à ouvrir le port 80 du moment que le port 443 est aussi (sous réserve de démonstration via un cas d'école).

Je n'ai pas compris la remarque 7 mais la 6 stipule le contraire il me semble : "Pour obtenir ou renouveler le certificat de votre domaine personnalisé, assurez-vous que le port 80 a été transmis à votre NAS. Cette limitation ne s'applique pas à Synology DDNS."

Quand je vois la pression qui est mise de plus en plus pour inciter à activer le 2FA sur nombre de services en ligne je suis inquiet d'une recrudescence de "nervouze breakdowns" lors de ce type de situations dans le grand public moins à l'aise avec la technique que nous.

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) non, j'ai testé comme je l'ai écrit : 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

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

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.

Celles pour lesquelles le portail de connexion permet se définir un alias. 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)

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

Ca fait partie des choses qui m'ont bien gavé ça ! J'avais jeté un oeuil sur le tuto mais j'ai trouvé ça un peut trop touffu pour mon besoin, j'ai eu la flemme d'aller plus avant. C'est ce que j'ai conseillé récemment à un pote que j'ai aidé à reconfigurer son NAS. On ne peut pas trouver plus simple en effet. Forcément ouvert chez moi, mais j'ai détaillé ailleurs mon avis sur le fait que ça ne change pas grand-chose au niveau sécurité à partir du moment où le 443 est ouvert aussi. Sinon pour les applis DSM en http j'utilise les alias ce qui m'évite d'avoir à ouvrir leur port. Et quant aux autres, elles écoutent uniquement en interne (sur localhost) et le reverse proxy se charge de donner accès depusi extérieur. Juste besoin des ports du VPN à ouvrir.

De mon côté, depuis que j'ai compris qu'ayant déclaré un nom en "synology.me" via DDNS on disposait d'un certificat SSL wildcard et automatiquement renouvelé je ne m'emmerde plus. Je réserve mon nom domaine aux usages "pro" et les quelques services hébergés par le NAS auxquels j'ai besoin d'avoir accès externe j'y accede en <nom>.synology.me via le reverse proxy (pas de port ouvert sur l'extérieur autre que le 443 et le 80). Et la conf firewall permet d'affiner les réglages.

Je confirme que c'est bien l'IP V4 par défaut des Freebox (en tout cas j'ai ça chez moi) Je suis surpris que ça ne se soit pas positionné automatiquement. C'est l'absence de l'option DHCP qui en est la cause ?

Je pensais surtout aux readme des applis distribuées en container qui décrivent des procédures plus ou moins lourdes. Exemple : https://registry.hub.docker.com/r/freshrss/freshrss/ (CF "how to update") Où on demande de créer un nouveau container après avoir renommé celui actif (et quid de la configuration qu'il faut transférer ?)

@CyberFr merci! C'est également ce qui me semblait raisonnable. Je vais arrêter de m'inquiéter