Aller au contenu

TuringFan

Membres
  • Compteur de contenus

    385
  • Inscription

  • Dernière visite

  • Jours gagnés

    1

Tout ce qui a été posté par TuringFan

  1. Bonjours, Je suis en train de réfléchir à la stratégie de sauvegarde que je vais adopter (c'est après tout la meilleur des protections). Pour le moment j'envisage de (i) effectuer des snapshots de mon NAS et (ii) utiliser hyper backup pour effectuer des sauvegardes chiffrées vers un NAS secondaire sur un site distant. Ma première question est : comment est géré le chiffrage ? Mon NAS principal chiffre déjà ses dossiers partagés, dans ce contexte est-il utile d'utiliser un chiffrement du transfert hyper backup ou du backup en lui même voire même un chiffrement des dossiers partagés sur le NAS secondaire ? Si oui, quels clés utiliser pour lire les infos sauvegardées. Ma seconde question est : comment protéger l'accès physique à mon NAS secondaire ? J'aurai en effet peu de contrôle sur les accès physiques potentiels au NAS du second site (site de backup). Dans ce cas comment empêcher un accès à mon NAS secondaire par quelqu'un qui se "brancherait" directement dessus ou sur le même réseau (en RJ45 par exemple) ? Le fait de désactiver tous les services fichier et d'avoir un pare-feu est il suffisant ? Qu'en est il pour les services "Bonjour", SSDP, WS-Discovery (je ne maitrise pas leur utilisation) ? En gros, in fine, je voudrais être certain que si quelqu'un se branche sur le réseau / NAS ou parte avec il ne puisse rien faire et rien lire. Merci d'avance à tous ceux qui pourront m'aider.
  2. Merci, Je compte de toute façon appliquer ce tuto pour le NAS dont l'installation d'un pare feu sur un routeur et sur mon NAS mais je pensais justement que le fait d'être sur le même réseau permettait de rentrer de par tous les ports. Je vais créer un sujet.
  3. Oui, sauf erreur de ma part je pensais que les snapshots ne pouvaient être fait que en local mais qu'ils pouvaient ensuite être répliqués à distance (sans bien comprendre ce que cela signifie). PS : j'ai également complété par une question de sécurité sur les backups ici.
  4. Bonjour à tous, Ce fil est pour moi "la référence" pour sécuriser son NAS et je souhaiterais vous soumettre deux questions à ce sujet. Je suis en train de réfléchir à la stratégie de sauvegarde que je vais adopter (c'est après tout la meilleur des protections). Pour le moment j'envisage de (i) effectuer des snapshots de mon NAS et (ii) utiliser hyper backup pour effectuer des sauvegardes chiffrées vers un NAS secondaire sur un site distant. Ma première question est : comment est géré le chiffrage ? Mon NAS principal chiffre déjà ses dossiers partagés, dans ce contexte est-il utile d'utiliser un chiffrement du transfert hyper backup voire même un chiffrement des dossiers partagés sur le NAS secondaire ? Si oui, quels clés utiliser pour lire les infos sauvegardées. Ma seconde question est : comment protéger l'accès à mon NAS secondaire ? J'aurai en effet peu de contrôle sur les accès physiques potentiels au NAS du second site (site de backup). Dans ce cas comment empêcher un accès à mon NAS secondaire par quelqu'un qui se brancherait directement dessus ou sur le même réseau (en RJ45 par exemple) ? Le fait de désactiver tous les services fichier est il suffisant ? Qu'en est il pour les services "Bonjour", SSDP, WS-Discovery (je ne maitrise pas leur utilisation) ? Merci par avance,
  5. Merci @oracle7, Réponse très claire. Je pensais que les réplications pouvaient être faites à distance (DD, NAS secondaire, etc.) ? En ligne avec toi Ok, c'est un argument majeur à mes yeux pour ne pas utiliser cette stratégie Mais du coup en faisant des backups d'un NAS sur lequel il y a snapshot, réalisons nous aussi des backups des snapshots avec en cas de restauration d'un backup spécifique la possibilité de naviguer (comme sur le NAS d'origine) entre tous les points de restauration antérieurs ? - Merci encore
  6. Bonjour à tous @Juan luis, @.Shad., @bruno78 et @oracle7 Je suis encore preneur de vos lumières s'il vous plait : je lis ici et là que les snapshots ne sont pas des véritables sauvegardes. Pourquoi ? Toujours dans l'idée de faire des backups de mon NAS principal vers un second NAS sur un site distant j'ai du mal à arbitrer entre les différentes possibilités : Utiliser snapshot replication pour faire des snapshots et les répliquer sur le second NAS - fréquence maximale toute les 5 min Utiliser hyper backup et faire des backups sur le second NAS - fréquence maximale toutes les heures Utiliser un mixte de 1 et 2 Utiliser cloud sync et faire du backup en temps continu : impossible car disponible uniquement pour une destination dans un service cloud Enfin existe t il une méthode pour faire des backups en temps continu vers le second NAS ? D'une façon générale, les backups en temps continu, offrent ils le même niveau de protection que les backups en temps discret (avec versionning, etc.) ? Qu’arriverait il si des fichiers étaient corrompus (malware, ransomware, anomalies hardware, etc) : cette corruption serait elle immédiatement héritée à la sauvegarde en la transformant en un miroir strict (donc avec ces fichiers corrompus) du NAS principal ? Merci d'avance,
  7. Bonsoir @Juan luis, @.Shad., @bruno78 et @oracle7 Je lis des choses sur les sauvegardes en ce moment pour envisager la meilleur stratégie pour moi. Quelqu'un pourrait il svp m'expliquer la différence entre les sauvegardes hyperbackup et les réplications snapshots ? Je comprends en effet que le paquet Snapshots Replication propose deux choses : La réalisation de snapshots qui sont des instantanés incrémentaux des datas (pas d'instantané de la configuration et/ou des paquets). Le prérequis est d'avvoir un volume en Btfrs. Cette méthode semble donc s'approcher "d'une super corbeille" et/ou d'un outil de versionning. Les snapshots sont par défaut en local, sur le même stockage. Il est possible d'utiliser des fonctions avancées pour programmer la réalisation des snapshots et paramétrer leurs règles de conservations. Il est également possible de rendre les snapshots visibles pour y naviguer comme dans des fichiers. Il faut pour cela que l'utilisateur ait un droit de lecture du dossier au moment du snapshot et que le dossier partagé ne soit pas chiffré. La réplication des snapshots qui si je scomprends bien est une copie des données et de tous les snapshots. En cas de recovery on peut donc accéder aux données et à tous les snapshots enregistrés sur le stockage. La réplication utilise le port 5566 et ne peut se faire que vers un serveur distant (impossible par exemple d'utiliser en stockage de destination un disque dur externe monté sur le port USB du NAS). Lors de la réplication, les données peuvent être transmises de façon sécurisée. Je comprends par ailleurs que le paquet hyperbackup propose lui une nique chose : la réalisation de sauvegardes quotidiennes stockées à distance (NAS, DD en USB, cloud) des données, configurations et paquets (sous réserve que les paquets le proposent). Le transfert de données peut être chiffré si besoin. Enfin si l'on souhaite faire des sauvegardes dans le cloud, on peut aussi utiliser le paquet cloud sync. Est-ce bien cela ? Plusieurs questions complémentaires : Que se passe t il si les dossiers sont chiffrés : les snapshots et réplications sont ils également chiffrés ? Si oui, avec quelle clé les déchiffrer ? Que se passe t il si un snapshot est réalisé sur le dossier A (sur lequel l'utilisateur User1 à accès en lecture) et le dossier B (sur lequel l'utilisateur User1 n'a aucun accès en écriture et/ou lecture) : l'utilisateur User1 pourra t il quand même voir le snapshot ? Où trouver la liste des paquets et éléments de configurations sauvegardés dans le cadre d'un hyperbackup ? Si l'on considère la sauvegarde de donnée uniquement peut on finalement estimer qu'on arrive au même résultat de sauvegarde (en dehors de la fréquence de sauvegarde et des contraintes techniques des supports de backups) en utilisant (i) des snapshots + des réplications ou (ii) hyperbackup ? Que se passe t'il quand nos dossiers partagés sont chiffrés avec des clefs dans le magasin de clés ? Comment récupérer les données si le NAS principal et ses disques durs sont perdus et/ou définitivement endommagés et que nous avons fait des sauvegardes (i) via snaphots replications dans un premier cas et (ii) via hyperbackup dans un second cas ? Est-il utile de cumuler snapshots replications et hyperbackup ? Hyperbackup effectue t il également une sauvegarde des snapshots ? En gros je voudrais savoir si j'ai plutôt intérêt à faire des réplication de snapshots ou un backup ou les deux ? Edit : je comprends que Cloud Sync et Hyper Backup font la même chose sauf que (i) cloud station ne fait que de la sauvegarde à distance (vers cloud, serveurs, NAS, etc.) et non sur DD externe et que (ii) Cloud Sync fais des sauvegardes en temps continu vs. des sauvegardes ponctuelles avec Hyper Backup. D'un point de vue sécurité (ransomeware, virus, corruption de données, destruction NAS principal, etc.) y a t il un intérêt à utiliser de la sauvegarde en mode ponctuel vs. en temps continu ? Merci d'avance,
  8. Oui. Du coup je voulais savoir si je pouvais créer un sous domaine "backup.ndd.tld" avec son propre DDNS mais qui bénéficierait lui aussi de mon certificat wildcard en ndd.tld ?
  9. Parfait c'est ce que j'avais en tête. Si ça marche pas je créerais chez mon registrar un autre domaine du type "backup-ndd.tld.
  10. Merci pour vos réponses @.Shad., @bruno78 et @Juan luis En ligne mais en terme de sécurité je préfère être redondant en ajoutant aux bonnes pratiques des backups. De mon coté SMB (pour accès réseau via explorateur windows sur PC et accès utilisateurs non admin), SSH activés puis AFP, NFS, FTP, TFTP désactivés. Ok, bonne nouvelle car je prévoyais plutôt d'avoir un stockage supérieur sur le NAS backup que sur le NAS principal. Je suis chez Orange en IP dynamique et j'ai suivi le tuto de @oracle7, pour le moment ça fait le job. Je pensais notamment à d'éventuelles contraintes pour supporter les paquets utilisés pour le backup : hyperbackup, snapshot et éventuellement le paquet pour le serveur e-mail high-availability. Ok, merci. Ok, idem que sur mon NAS principal donc. Merci, c'est mon cas. En fait j'imaginais créer chez mon registrar un "sous domaine" du type "backup.ndd.tld" et ne maitrisant pas bien les sujets de certificats je voulais savoir si je pouvais inclure ce domaine dans mon wildcard de façon similaire à ce que je fais sur mon NAS principal : peut-être as tu une opinion là dessus @oracle7 ? C'est ce que je pensais faire en achetant un routeur pour le réseau du NAS backup (ne serait-ce que pour avoir un wifi invité dissocié du réseau du NAS backup) : cela est-il compatible les sujets de certificats et DDNS avec ma volonté d'avoir chez mon registrar un sous domaine du type "backup.ndd.tld" ? Qu'en penses tu @Juan luis ? Je pense que je vais aussi sérieusement songer au DD derrière mon NAS principal. En revanche @bruno78 petite question : avec le NAS de backup et les paquets associés (snapshot + hyperbackup) je comprends que seules les données sont sauvegardées mais pas les applications et les configurations, qu'en est il avec un DD ? Pour info je sauvegarde déjà à chaque gros changement mes fichiers de configurations routeur et NAS. Mon ideal in fine serait une solution "press bouton" où tout serait réinstallé à l'identique : configuration, applications et données. Une idée là dessus ? VPN ? --- Merci d'avance pour votre aide, en espérant que cela en aidera aussi d'autres.
  11. Je vais regarder ça dès que j'ai un peu de temps alors Pas besoin de toucher ce fichier de mon côté Complètement en ligne ! La seule amélioration que je vois et d’éventuellement un jour automatiser la diffusion du certificat au routeur.
  12. Très bon point @Juan luis Le NAS de backup sera dans un logement à plusieurs centaines de km sans maitrise des éventuels accès physiques par des tiers au NAS avec une connexion fibrée.
  13. Pardon @oracle7 je n'étais pas clair, voici ce que je fais : A chaque fois je me rends compte que mon certificat a expiré Je vais donc voir ce qui cloche sur le script en le forçant avec un "-f" Je constate ensuite toujours la même chose : un "check your username and password" dans les logs du script Je vais alors voir le fichier de config dans "/volume1/Certs/ndd.tld/ndd.tld.conf" et je constate alors que le DID est différent de celui que j'ai en checkant via Cookie Quick Manager Je fais donc la modification dans le fichier de configuration avec le nouveau DID et relance le script en "-f" et là ca fonctionne nickel !
  14. Bonjour à tous, De mon côté la méthode fonctionne très bien mais j'ai systématiquement un problème de DID qui me force à le mettre à jour puis à forcer l’exécution du script python3. Auriez-vous résolu ce problème ? Bonee soirée,
  15. Bonjour à tous, Je suis débutant et je possède un NAS à mon domicile sur lequel je stocke des données et héberge des services comme un serveur de messagerie, surveillance station, drive, etc. Mon NAS est monté derrière un Routeur Synology (lui même monté en DMZ de ma LiveBox en IP dynamique), je peux l'atteindre via un DDNS. Je souhaiterais aujourd'hui m'attaquer à la sauvegarde de mon NAS or il semble avoir de multiples solutions pour de multiples besoins comme illustré sur la page Synology dédiée au sujet. J'ai plusieurs souhaits (idéalement) : me protéger des randsomewares me protéger des atteintes à l'intégrité physique de mes disques durs ou de mon NAS (malveillance ou défaillance) stocker mes enregistrements surveillance station son mon NAS de backup (de sorte à les conserver et y avoir accès si je suis victime d'un cambriolage avec vol/casse de mon NAS) avoir un accès high availability à mes emails chiffrer les échanges entre mon NAS et mon NAS de backup chiffrer les backups sur le NAS de backup de sorte à ce que même si un tiers y accède il ne puisse récupérer aucune information accéder à mon NAS de backup à distance via un VPN et en utilisant un sous domaine du type backup1.ndd.tld J'ai donc plusieurs questions : J'imagine que ma première condition impose de faire un backup asynchrone ? Je crois savoir qu'il existe des systèmes de versionning "intelligents" qui fonctionnent en mode delta pour minimiser l'espace de backup nécessaire mais auriez-vous un ordre de grandeur sur le ratio à avoir entre la mémoire du NAS de backup et le NAS principal (x fois plus de mémoire sur le backup que sur le principal) ? Y a t il des contraintes hardware à avoir en tête ? Mon NAS principal est un DS418play et j'imaginais prendre un NAS de backup 2 baies en RAID1 monté derrière un routeur Synology : qu'en pensez vous ? Comment chiffrer les échanges entre les deux NAS ? Comment chiffrer les backups sur le NAS de backup ? Je pensais utiliser la combinaison du paquet snapshot et du paquet hyperbackup pour faire cela : est-ce la configuration optimale ? Comment gérer les sujets de certificats / domaine ? J'ai suivi ce tuto de @oracle7 sur les certificats wildcard. Y a t il d'autres sujets auquels je ne pense pas. Merci d'avance pour votre aide,
  16. @Funroc je me rends compte que je me suis très mal exprimé. J'avais initialement créé des règles uniquement dans la section "transmission de port" mais pas dans la section "sécurité" menu pare-feu. J'avais alors un problème de synchro du client Drive (port 6690) sur PC et de réception de mes e-mails sur mon serveur de messagerie (ports 25, 465, 587 et 993). J'ai ensuite doublé ces règles de transmission des ports de règles spécifiques dans le pare-feu du routeur avec pour destination l'IP locale du NAS : problèmes résolus. En bref je pensais que la création d'une règle dans le panneau de transmission de port était suffisant, vraisemblablement non il faut aussi créer une règle dans le pare-feu du routeur mais qui pointe vers le NAS.
  17. Effectivement bizarre cette asymétrie de comportement... Posté avec Tapatalk
  18. Après avoir essayé une douzaine de fois le bouton "réparer" cela a fonctionné ... Je suis en train de faire un reboot du NAS au cas où. C'est bon je crois que ça fonctionne ! Problème de débutant : j'avais bien fait un transfert de port depuis mon routeur mais il semblerait que pour que cela fonctionne il faille aussi ouvris les ports transférés sur le routeur (même s'ils sont à destination d'un usage sur le NAS) ! Solution apportée par @.Shad. dans le cadre d'un problème de synchro client drive ici sur lequel @oracle7 aidait aussi. Merci encore ! Edit : Je vais maintenant me lancer dans l'installation d'un serveur calendrier / contact, j'espère un peu naïvement que le travail fait avec le serveur de messagerie aidera. @oracle7 tu t'es lancé dans l'aventure ?
  19. Bonjour @oracle7, Cette erreur te parle t elle ? J'ai évidemment essayé de réparer sans succès ...
  20. TuringFan

    Gestion des liens partagés

    Ok c'est noté, merci @.Shad. et @Mic13710.
  21. TuringFan

    Gestion des liens partagés

    Mais tu as raison, effectivement je préférerais m'affranchir de cet onglet accès externe > avancé mais sans lui je ne parviens pas à avoir de liens de partages fonctionnels sur Files Station, même avec mes reverses proxy. Comment fais tu de ton côté ?
  22. TuringFan

    Gestion des liens partagés

    @.Shad. Merci pour ton retour. Mais justement j'ai déjà un reverse proxy pour le File Station en "file.ndd.tld" et un reverse proxy pour le Synology Drive en "drive.ndd.tld". Sans configuration spécifiques voici ce que j’observe : des liens de partage créés via File Station de la forme "https://ndd.tld/sharing/..." et créés via Synology Drive de la forme "hhtps://ndd.tld:5001/...". Aucun des deux n'est fonctionnel. En revanche en indiquant "files.ndd.tld" (comme mon reverse proxy) et le port 443 (port d'entrée de mon reverse proxy) dans panneau de configuration > accès externes > avancé les liens de partage créés par File Station sont désormais de la forme 'https://files.ndd.tld/sharing" et sont fonctionnels. Puis en allant dans la console d'administration de Synology Station > paramètres > autres > personnaliser un lien de partage et en indiquant un domaine personnalisé de la forme "https://drive.ndd.tld" (comme mon reverse proxy) j'ai ensuite bien des liens de partage fonctionnels de cette forme créés via Synology Drive. Bref avec des deux manip les liens de partage deviennent fonctionnels dans les deux applications sans retraitement du lien. J'espère que cela en aidera d'autre en revanche je ne maitrise pas bien ce que j'ai fait. @.Shad. preneur d'explication plus académiques si tu en as, vois tu un risque de sécurité spécifique lié à ces manips ? Quelques pistes ici. Bonne soirée,
  23. Oui c'est ce que j'ai en normatif mais pour mes test je mets une unique redirection vers OVH mais le comportement devrait être le même. Idem
  24. TuringFan

    Gestion des liens partagés

    Bonjour @Mic13710 et @unPixel, Je suis moi aussi en train d'investiguer sur les différentes méthodes de partages de fichiers depuis le NAS avec des "externes" ponctuels. Ma config : NAS derrière mon routeur lui même derrière ma LiveBox (en DMZ). Accès aux applications File Station et Drive via reverse proxy en 443 du du type "files.ndd.tld" et "drive.ndd.tld" qui pointent ensuite sur un localhost avec des ports http, pas de contrôle de profil, 443 et 80 ouverts sur le NAS et forwardé sur le routeur. Nom d'hôte statique : "files.ndd.tld" avec port https 443. Mes questions : J'ai indiqué ces valeurs pour le nom d’hôte statique et le port associé (grâce à mes différentes lectures sur le forum) mais je ne suis pas certain de comprendre à quoi cela correspond : pourriez-vous svp m'expliquer ? File Station et Synology Drive produisent désormais tous les deux des liens de partage en "https://files.ndd.tld" : accès sans problème au lien File Station en LAN/WAN en revanche impossible d'accéder au lien Drive en LAN/WAN (j'ai un message d'erreur du type "désolé, la page que vous cherchez est introuvable"). A noter que ce test a été fait pour le même fichier avec un utilisateur ayant accès aux deux applications (pas de problème de droit a priori donc). Pourquoi cette différence de comportement ? Merci d'avance,
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.