PiwiLAbruti

Oui, mais c'est hors de ta portée (configuration de ton propre serveur DNS avec la zone publique pour ton domaine + règles de pare-feu). Ce n'est pas une sécurité en soi. Le plus important est de restreindre les accès au niveau du pare-feu du NAS.

S'il n'y a aucun port d'ouvert dans les règles NAT/PAT, je ne vois que deux possibilités : S'il y a une option UPnP sur la box SFR, désactive-la. Ce service permet à n'importe quelle application (programmes malveillants inclus) d'ouvrir automatiquement les ports dont elle a besoin sur le routeur. Les ports éventuellement ouverts par DSM apparaissent dans Panneau de configuration > Accès externe > Configuration du routeur (que tu sembles déjà avoir désactivé dans DSM, c'est une bonne chose). S'il y a une option DMZ sur la box SFR, vérifie qu'elle est bien désactivée (aucune destination). Si l'adresse IP du NAS y est renseignée, tous les ports (de 1 à 65535) sont redirigés vers lui.

Concernant l'inscription sur https://hstspreload.org/, il a des préalables à respecter dont : • The max-age must be at least 31536000 seconds (1 year). La valeur de max-age dans l'en-tête Strict-Transport-Security renvoyée par DSM est 15768000, soit 6 mois. On peut le voir dans les outils de développement du navigateur : onglet Network, cliquer sur le nom d'hôte de la page d'accueil de DSM (de type document), onglet Headers, section Response headers, en-tête Strict-Transport-Security. @Einsteinium Tu as eu un retour comme quoi ton domaine était validé ?

Concernant les règles de pare-feu, la colonne Source doit contenir les adresses IP des clients potentiels. Ton adresse IP publique n'a donc pas besoin d'y figurer. Pour le moment, tu peux limiter l'accès aux port tcp/80 et tcp/443 à la France comme tu l'as fait pour File Station avec les ports 7000 et 7001. D'ailleurs, as-tu besoin d'y accéder depuis la Guyanne ? Comme le VPN n'est pas configuré, tu peux désactiver les règles correspondantes. Pour les accès externes, il doit y avoir correspondance entre les ports ouverts sur ton routeur et ceux ouverts sur le pare-feu. Ce n'est pas le cas actuellement. Le port tcp/80 (non-chiffré) ne sert effectivement à rien dans la règle de pare-feu s'il n'est pas également redirigé dans le routeur. Je suppose que les ports tcp/9080 et tcp/9043 sont également déclarés sur le NAS comme pointant vers File Station ? Le certificat n'est valide que pour le(s) nom(s) d'hôte(s) qui y sont déclarés. Dans ton certificat on voit ****.synology.me, tu peux donc utiliser ce nom pour te connecter à ton NAS et ne plus avoir d'alerte de sécurité. Attention cependant, cela risque de ne marcher que depuis l'extérieur de ton réseau, ****.synology.me pointant vers ton adresse IP externe. On verra plus tard comment faire en sorte que le nom ****.synology.me pointe vers l'adresse IP privée du NAS (192.168.1.*) en local.

iperf3 est également disponible dans le paquet SynoCli Monitor Tools de SynoCommunity.

Attention aux protocoles utilisés (tcp ou udp). Le VPN sur les ports udp/500 et udp/4500 sont utilisés par le VPN L2TP/IPsec (d'ailleurs, retire le port udp/1701 qui ne doit pas être exposé sur internet). Le port udp/1194 est utilisé par OpenVPN. Utilises-tu ces deux protocoles VPN ? Tu peux n'ouvrir que le port tcp/443 (https) dont les communications sont chiffrées contrairement au tcp/80 (http). En l'état ouvrir le port tcp/443 ne pointera que vers Web Station si ce dernier est installé et que tu en as l'utilité. Ce port sera surtout utile une fois que tu auras ton nom de domaine puisqu'il te donnera accès à File Station (par exemple) avec une adresse conviviale du type https://filestation.domaine.ovh grâce au proxy inversé.

C'est quoi "ça" ? Le fait que nmap te liste des ports ouverts sur le NAS depuis le réseau local (192.168.1.0/24) est tout à fait normal. Tu dois avoir un équivalent de la Gestion des ports de la Freebox sur ton routeur Netgear. C'est là qu'il faudra ouvrir les ports des services à rendre accessibles depuis internet. Pour le reste de ta configuration (box en bridge, DHCP, ...), ne touche à rien c'est très bien ainsi. Peu importe les adresses IP distribuées, l'important est que les équipements vers lesquels des ports vont être redirigés depuis le routeur Netgear aient une adresse IP fixe (de préférence réservée dans la configuration DHCP par un bail statique).

Un fichier .lnk sous Windows est un raccourci. Il faut l'ouvrir sous Windows, regarder vers quel fichier il pointe, et remplacer ce raccourci par ce fichier.

Je recommanderais d'utiliser le VPN L2TP/IPsec via le paquet VPN Server pour sécuriser les échanges. Il y a cependant quelques réglages spécifiques à faire pour une transparence totale. Attends que d'autres membres apportent des solutions alternatives.

Avant d'utiliser un nom de domaine (dynamique ou non), il faut déjà que l'accès fonctionne avec l'adresse IP publique : https://a.b.c.d:5001/ Il faut que le port tcp/5001 soit ouvert sur ton routeur à destination de l'adresse IP privée du NAS. Si tu as également ouvert le port tcp/5000, ferme-le car les communications ne sont pas chiffrées sur ce port. Renseigne-toi auprès de ton opérateur pour savoir ce qu'il est possible de faire puisqu'il semble qu'il y ait une contrainte propre à ce dernier (très probablement du NAT).

@oracle7 Oui, ma remarque ne concerne qu'une poignée d'utilisateurs qui ont déclaré une ou plusieurs zones DNS publiques dans DNS Server sur leur NAS. Les serveurs Let's Encrypt vont alors communiquer directement avec le serveur DNS (paquet DNS Server) du NAS pour établir les certificats.

Petite précision pour ceux (une extrême minorité) qui hébergeraient leur propre serveur DNS sur leur NAS sans l'ouvrir au monde entier Les serveurs Let's Encrypt ont besoin de récupérer le(s) enregistrement(s) TXT pour générer les certificats. Il faut donc penser à les autoriser dans le pare-feu à accéder à votre serveur DNS : 66.133.109.36 (outbound1.letsencrypt.org) 64.78.149.164 (outbound2.letsencrypt.org) Pour la petite histoire, mon domaine domaint.tld est hébergé chez mon registrar et j'utilise des domaines pour chacun de mes NAS (nas1.domain.tld, nas2.domaint.tld, ...). Ces domaines sont hébergés respectivement sur chaque NAS et ne sont pas diffusés au monde entier mais uniquement dans les réseaux que j'utilise. Il m'a donc fallu autoriser les serveur de Let's Encrypt à accéder à ces serveurs DNS pour générer les certificats wildcard de chaque NAS (nas1.domain.tld et *.nas1.domain.tld, nas2.domain.tld et *.nas2.domain.tld, ...). Ayant validé la chose avec une capture tcpdump, j'ai pu aussi voir que Let's Encrypt utilise toute une ribambelle de serveurs chez Amazon qui requêtent également le serveur DNS. Ils sont parfaitement facultatifs puisque les certificats sont correctement générés avec les deux seuls serveurs historiques du service.

Bienvenue sur Internet 😊 Il n'y a rien d'alarmant dans ce qui est affiché dans les journaux de ton routeur. Ce sont souvent des machines zombies faisant partie d'un botnet dont le but est de détecter des ports ouverts et de faire des tentatives d'intrusion. Tu n'es pas particulièrement ciblée, c'est comme ça sur n'importe quelle connexion internet sauf que personne ne le voit. C'est là que la configuration des règles de pare-feu est très importante, la moindre porte ouverte est rapidement détectée et exploitée. Concernant la configuration actuelle de l'onduleur sur ton NAS, ce dernier s'éteindra au bout de 3 minutes lorsque l'onduleur passera sur batterie. C'est un choix. J'ai laissé cette case décochée pour que le NAS s'éteigne lorsque l'onduleur atteint un niveau de batterie faible. La case à cocher "Éteindre le NAS l'UPS lorsque le système passe en mode sécurité" n'a pas à être cochée, même si l'onduleur est censé se rallumer automatiquement lorsque le courant est rétabli.

Un problème d'alimentation se caractérise souvent par un NAS qui démarre bien sans les disques mais pas avec à cause du courant qui est plus important au démarrage. Tu peux toujours faire un test croisé si tu connais quelqu'un qui a le même bloc d'alimentation, mais il est fort possible que ça vienne de la carte du NAS. Pour savoir s'il est opportun de changer de NAS, il faut se référer aux notes de mises à jour de DSM. Lorsque DSM 6.2 este sorti en mai 2018, Synology a précisé qu'il s'agissait de la dernière version de mise à jour pour les NAS de la série '12. Sachant qu'une génération disparaît ainsi chaque année, et tenant compte du retard de DSM 7, la série '15 aurait ses dernières mises à jour en 2021 : For the following models, DSM 6.2 will be the last upgradable version. DSM 6.2 will continue to receive critical and security updates until June 2023 after the official release. Please refer to the DiskStation Manager Life Cycle section in Synology Security White Paper. XS Series : RS3412xs, RS3412RPxs, RS3411xs, RS3411RPxs, DS3612xs, DS3611xs Plus Series : RS2212+, RS2212RP+, RS2211+, RS2211RP+, RS812+, RS812RP+, DS2411+, DS1812+, DS1512+, DS1511+, DS712+, DS412+, DS411+II, DS411+, DS213+, DS212+, DS211+, DS112+ Value Series : RS812, RS212, RS411, DS413, DS411, DS213, DS212, DS211, DS112, DS111 J Series : DS413j, DS411j, DS411slim, DS213air, DS212j, DS211j, DS112j Others : DDSM

Pour coller au plus près de la réalité, le schéma actuel est plutôt : Internet -------- BOX (bridge) --------- 1.2.3.4 ROUTEUR 192.168.1.1 ----------Switch------------192.168.1.[2-254] Périphériques ( NAS, Caméras, Imprimantes, PC/Mac, etc) L'idéal à distance est de pouvoir également travailler en mode déconnecté. Synology Drive répond plutôt bien à ce besoin. Question piège : Comment sont sauvegardées les données du NAS actuellement ?

C'est un problème connu, je te laisse prendre connaissance du sujet :

@Fanny Mae Ne te lance pas déjà dans la configuration du VPN ou du DNS, ça ne correspond peut-être pas (déjà) à ton besoin. Ouvre un sujet en précisant ton besoin initial, tu seras mieux orientée que si tu tentes d'appliquer au hasard tous les tutoriels qui te passent sous les yeux.

Techniquement, les serveurs relais peuvent tout à fait déchiffrer le traffic. Est-ce qu'ils le font ? Seul Synology a la réponse.

Le problème de QuickConnect est que l'utilisateur ne sait à aucun moment laquelle des 5 méthodes est utilisée pour joindre son NAS : Accès direct (dans le cas où les ports sont ouverts sur le routeur et que les règles de pare-feu du NAS autorisent les serveurs QuickConnect à le joindre) Hole punching (les ports aléatoires de chaque client utilisés pour joindre le service QuickConnect sont utilisés pour les faire communiquer en direct) UPnP (à proscrire) Relais Portail web C'est plus un problème de confiance qu'un problème technique. Le but d'un NAS étant d'avoir son propre hébergement privé, l'utilisation d'un service tiers susceptible de relayer les échanges va à l'encontre de ce principe. Après ce n'est qu'une question de point de vue.

C'est quand même étrange que les disques soient totalement "invisibles". Tu constates des bruits mécaniques lorsque les disques défectueux sont alimentés ? (Il est écrit partout sur le forum que le RAID ne dispense pas de sauvegarder ses données. S'il fallait un exemple concret, le voici)

Intéressant comme échange 🤣 Je vous invite tous les deux à configurer QuickConnect, lancer une capture tcpdump sur le NAS, faire une copie de fichier (upload et download) via File Station, et partager vos résultats. Ça mettra tout le monde d'accord 😘

QuickConnect > 🗑️ La résolution de ton domaine en local doit retourner l'adresse IP privée du NAS et non l'adresse IP publique.

Ton besoin est donc de synchroniser des données entre plusieurs appareils. Syncthing va surtout t'apporter de la complexité, ça reste encore un produit peu accessible pour les masses de mon point de vue (même si la technologie utilisée est excellente). Si les outils de Synology répondent à ton besoin, il n'y a aucune raison de vouloir en changer.

@Kramlech Ce n'est pas forcément une question de sécurité, l'intérêt est surtout d'utiliser toujours la même adresse où que l'on soit.

J'autoriserais la plage IP correspondant à celles utilisées par NAS A dans le pare-feu de NAS B. Tu peux trouver cette plage avec un simple whois ou dans le registre du RIPE-NCC.