CoolRaoul

A mon avis tout semble indiquer que le problème est côté télé plutôt que côté NAS. As tu essayé de poser la question sur un forum dédié Samsung ? Il existe une communauté officielle : https://eu.community.samsung.com/t5/français/ct-p/fr

Ça vaut ce que ça vaut mais j'ai un tout petit site chez Online/Scaleway. C'est une vieille formule hébergement+nom de domaine, plus disponible au catalogue actuel, mais dont ils maintiennent le support pour les abonnés existants (ce qui est tout à leur honneur). Je me permets de témoigner pour signaler la réactivité impressionnante de leur support client (y compris le week-end et en dehors des horaires standard). J'ai eu à ouvrir quelques tickets, ces derniers mois notamment, et ai toujours été extrêmement satisfait, autant de la rapidité de prise en compte que de la qualité des échanges avec les intervenants. Et tout ça malgré la minuscule contribution annuelle que j'apporte à leur CA. Je ne connais pas le reste de leur offre mais j'imagine que la qualité du support ne peut qu'être au moins de même niveau. Je n'ai bien entendu aucune action chez eux.

@Flamby55 par curiosité j'ai essayé de configurer la synchro de l'agenda Synology avec mon smartphone (c'est un Android) De mon côté je suis parvenu à le faire fonctionner (via l'application "DavX5" qui est necessaire sur Android) Juste une différence avec toi sur l'url : de mon côté j'ai utilisé l'URL https://MONNDD.myds.me:5001/caldav.php et renseigné les champs user et password dans le formulaire de l'application ( à ce propos j'ai été surpris de ne pas me trouver bloqué sur le MFA qui est activé pourtant sur mon compte Et ça se synchronise bien et dans les deux sens **edit** Ah j'ai compris, l'URL est différente si on configure accès par alias dans le portail de connection. Avec le nom que j'ai choisi, "caldav", alors https://NDD.myds.me/caldav/ fonctionne pour moi (mais je n'ai pas le "/User" toutefois ni le port DSM 5001, ça passe par le port 443 SSL standard) Comme je suis sous Android et toi sur IOS je ne pourrais hélas sans doute pas t'aider plus avant

Il est important de comprendre que même en changeant le port il sera forcément necessaire d'ouvrir l'accès externe au NAS dans la BOX avec une redirection de port. Que ça soit le port par défaut ou un autre ne change rien (juste peut-être la moindre visibilité dans la mesure ou le port choisi est plus "exotique", les scans de ports utilisés par les pirates potentiels se limitent en général à un nombre restreint de ports connus, mais pas toujours)

Ah oui. Et en effet c'est bien ça quand je me connecte directement dans le navigateur. Par contre ce libellé "syn6-" étrange n'apparait que quand je passe par "DS Finder" => "DSM mobile". Ça doit mettre en place une espèce de proxy/tunnel transparent sans doute. Bof, ça n'empêchera pas de dormir.

Bonjour, Tout d'abord je m'excuse d'avance de poster ici, je n'ai pas trouvé de section appropriée pour "DSM Mobile" Je m'interroge sur la signification de ce libellé "syn6-" sous le nom d'utilisateur ici. C'est sans importance bien entendu 😔

Comme c'est pour partager avec un pote (en fait c'est plutôt lui qui me partage des contenus) je ne veux pas lui imposer un achat de licence donc je pense rester sur Jellyfin. Sinon, la licence c'est uniquement côté serveur ou client aussi ?

Bon et bien ça sera Jellyfin (que je ne connaissais pas) alors et ça m'a l'air vraiment bien fichu.

Voyant ça, en précision j'ai tenté de tester si Plex pouvait m'assurer les mêmes services. A priori pour un access à distance à mon NAS il est necessaire de payer un abonnement Il faut payer pour visionner *ses* videos ? Sans déconner ?

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

Et je vois en réponse qu'ils enfoncent le clou : Le mieux je pense est de ne pas chercher à argumenter, on est d'accord ?