Toutes les discussions

Ok, merci, je ne savais pas ça (comme beaucoup d'autres choses que j'apprend par ce forum d'ailleurs et je vous en remercie !) Du coup, l'avertissement que j'ai sur l'appli mobile est normal ou pas (quand je suis sur un accès externe via drive.ndd.me:443 qui fait fonctionner mon reverse proxy) ? C'est que je voudrais être sûr d'être dans les clous niveau sécurité 😇

@Flamby55, une adresse IP ne peut pas avoir de certificat. Il est donc normal que votre navigateur vous indique que la connexion n'est pas sécurisée. Néanmoins, la connexion est bien chiffrée de bout en bout.

Me revoilà ! Alors j'ai mis en place le reverse Proxy et je me suis rendu compte d'un problème : En local, quand je me connecte à DSM, le https dans mon navigateur est barré, et il m'indique connexion non sécurisé : Je me suis rendu compte après avoir vu en testant la connexion à distance et donc le reverse proxy via l'application mobile Drive, car j'ai eu ici aussi un avertissement comme quoi la connexion n'était pas sécurisée... J'ai donc quelque chose de mal paramétré, mais j'ai beau relire le tuto, je ne vois pas. Si quelqu'un à un avis...

Que je choisis "Activer le mode HTTPS uniquement dans toutes les fenêtres", le paramètre dom.security.https_first reste à false 🤔 Bref, je n'utilise pas Firefox, et l'important est que ça fonctionne. ---- Pour ceux qui veulent en savoir plus, tout est expliqué ici : https://support.mozilla.org/fr/kb/mode-https-uniquement-dans-firefox Dommage que ce ne soit pas activé par défaut sur Firefox.

@Jeff777 si tu veux, je te donne le mien. Ce problème d'incompatibilité de cette option avec le reverse proxy existe depuis ... tout le temps et @.Shad. n'a fait que reprendre ce que Fenrir avait mentionné dans son tuto. De ce que je comprends, obliger le nas à basculer en https interfère avec les règles de transfert https vers le port correspondant de l'application en http. Par exemple, une entrée https://nas.ndd qui est transférée vers le localhost:5000 (DSM) est contrecarrée par l'obligation de passer en https (donc 5001). Le transfert ne peut pas aboutir. Ceci dit, il est possible que Syno aient revu leur copie et que ce dysfonctionnement ait été corrigé dans les dernières versions de DSM. Je n'ai pas essayé et je n'ai pas l'intention de le faire car je ne vois pas d'intérêt pour mon usage de forcer le https en interne (je n'ai pas de http ouvert vers internet).

Idem chez moi, j'ouvre le port 80 uniquement lors du renouvellement des certificats Let's Encrypt. Ou plus simplement de se rendre dans Préférences > Vie privée et sécurité et cocher mode "HTTPS uniquement". C'est moins geek mais tout aussi efficace 😀

Je serai curieux de connaître l'avis de @.Shad. qui a écrit dans son tuto sur la sécurité (DSM7), à propos de la redirection forcée http=>https dans l'interface DSM : REMARQUE : Ne pas activer cette option si vous utiliser un proxy inversé pour accéder à vos services DSM.

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.

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

Forcer le https protège d'une potentielle surveillance extérieure. 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. 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é.

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

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. A mon avis oui. Ce fichier permet de transformer toute reqête en http en https donc chiffrée 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.

L’avertissement indique que les fichiers vidéos sont trop volumineux pour être analysés. j’ai au final programmé une analyse hebdomadaire système et non complète.

Cela vient bien de l’antivirus ! j’ai programmé l’analyse hier pour qu’il la fasse le mardi à 1h du matin. Ça a pas loupé, ce matin dès 9h le NAS était injoignable. Quand je suis rentré chez moi, le NAS était tout en carafe et la led disk était en orange. j’ai donc forcé l’extinction en appuyant 10s sur le POWER et après redémarrage tout est rentré dans l’ordre comme d’habitude. En regardant l’historique de l’analyse antivirus, ça a bien démarré à 1h du mat mais à 9h47 il était toujours en train de la faire, avec un message à côté des fichiers qui indique « avertissement ». est ce qu’il y a une solution à ce problème ? J’ai l’impression que l’antivirus sur le NAS mange beaucoup de ressource. est ce que cela a un intérêt de l’utiliser sur un NAS ? Ou alors j’analyse que le SSD externe de sauvegarde qui est connecté sur le NAS. Il y a dans ce SSD les fichiers les plus importants. Dans le NAS, c’est que des séries et films, c’est moins grave. Et là on voit que l’antivirus dit qu’il ne peut pas analyser le dossier films et séries

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.

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.

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)

Déjà Bitwarden ! 😅 Sinon je stocke dans Ms Authenticator, Authy, Raivo, et Secure Signin de Synology. tous mes codes ne sont pas dans toutes les applications en fonction de quand j’ai commencé à les utiliser 😆

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".

@MilesTEG1Merci pour ton retour, quelle application utilises-tu ?

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

Bonjour à tous J'ai installé dans le docker l'utilitaire iVentoy par l'intermédiaire d'un fichier compose.yaml. Au départ il me sortait une erreur parce que le drivers_opts était sur eth. J'ai réglé le problème en le changeant par ovs_bond0 qui correspond à mon interface réseau. Le projet démarre bien mais je suis obligé de passé le port 69 TFTP sur un autre port parce qu'il me signal un conflit avec une autre application qui utilise le port 69. J'ai donc stoppé toutes les applis de docker pour trouver le coupable. Mais pas de chance, même tout arrêté, j'ai toujours le conflit. Si je tente de lancer une machine avec un boot PXE, alors le serveur iVentoy et DHCP sont reconnus par le client PXE (avec la première adresse attribué par le serveur DHCP de iventoy), mais rien ne se lance sur le client qui ne trouve pas de boot. Il bloque sur TFTp et par ARP Timeout. Je précise que j'ai provisionner les iso dans un dossier spécifique de iventoy. J'en déduit que le port 69 est en cause. Je me creuse la tête depuis une dizaine de jours mais je ne trouve pas la réponse. Alors merci pour un petit coup de main. Sur NAS DS920+

Bonjour à tous, Les réseau et la sécurité ne sont pas mon fort, c'est même du chinois pour moi, mais j'essaie je vous assure. En la matière je suis novice. Par avance merci de votre patience. Je débute avec mon NAS DS223j, utile pour synchroniser les données de ma famille avec notre ordinateur familial. Les tutos sont très utiles, mais je constate que ces petites merveilles sont plus complexes à paramétrer que je ne m'y attendais. Je rencontre ainsi plusieurs problèmes depuis son installation il y a 2 semaines. Le principal, la vitesse, bridée à 3,5 Mo/s en ascendant pour ma synchro avec Synology Drive client sur les gros fichiers, et encore bien moins pour les petits. Autant dire que la première synchronisation des mes données à 931 Go actuellement (car bien sûr ça n'est pas achevé) en cours depuis plusieurs jours est laborieuse... J'ai parcouru les différents posts de problèmes de vitesse et ne parviens pas à y trouver une solution applicable et suivie d'effets pour moi. Aussi je me tourne vers vous avec ce post. Mon ordinateur est connecté en LAN, câble cat 7 à mon routeur, auquel est connecté le NAS avec le câble d'origine. Initialement la carte réseau était paramétrée sur Négociation Auto. J'ai tenté de la paramétrer sur Full-Duplex sans plus de succès. A part un téléphone IP branché sur mon routeur/box par mon opérateur, il n'y a rien de plus de connecté. J'ai également essayé avec un cat. 6a sans plus de succès là non plus et toujours exactement les mêmes vitesses. Pas de VPN, pas de Tailscale. et sur mon routeur : Le pare-feu Windows Defender piloté par McAfee n'a pas de paramètre particulier pour mon NAS. Le pare-feu du NAS sous DSM 7.2 est le suivant (merci @Flamby55 pour le tuto !) : Les adresses IP sont distribuées en DHCP. --> devrais-je modifier l'adresse IP Source en 192.168.0.1 qui est celle de mon routeur/box ? J'ai essayé ma ça ne change rien. Synology Assistant me reporte une connexion OK : Auriez-vous une idée par où débuter ? Redirection de port ? C'est déjà un langage qui m'est compliqué. Et à ce que je vois ma box actuelle ne permet pas/plus le routage de ports. Enfin, si je tente de connecter mon NAS en direct à mon ordinateur par câble, quel qu’il soit, Synology Assistant ne le trouve même pas : Alors qu’il apparaît dans le réseau Windows sous l’adresse 169.254.167.169 mais n’y reste pas. Je peux par contre m’y connecter sans problème depuis mon navigateur. Il y a sans doute plus d’une chose que je fais fausse, mais lesquelles. Par avance merci de vos conseils et idées. Laurent DS223j + 2x HAT 3300 8 To en SHR | DSM 7.2 | 1x1 To + 1x2 To SSD Samsung EVO | 1x8 To + 1x16 To HDD WD HP OMEN i7-11700 | RTX-4090 | DSL 600/60 Mbps | Baie externe 8 HDD 48 To en SATA 3 + quelques centaines de To de sauvegardes manuelles sur HDD

Bonjour, merci pour les infos. j'ai une liste de ce que j'ai comme fichiers sur les disques. Si je pers les disques, c'est désolant mais pas dramatique car ce n'est que de la vidéo que l'on peut facilement télécharger de nouveau. Mais merci quand même pour l'info. Bonne soirée .

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 !