Classement

Bonjour, Quelqu'un aurait-il un lien pour télécharger un fichier host (download station) pour le site Updloady.io s'il vous plait ? Ou un tuto sur comment en créer un ? J'ai vu sur Google qu'il y avait un topic à ce sujet sur le forum mais je n'y ai pas accès : https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.nas-forum.com/forum/topic/81968-fichier-host-pour-uploadyio/%3Fdo%3DfindComment%26comment%3D1319513384&ved=2ahUKEwiKuK_mrpWLAxXZ3AIHHQ3lJ0gQFnoECAcQAQ&usg=AOvVaw1KQ-cOebOdNKcHwwUFaVT8 Merci d'avance

Les termes utilisés adresses des points différents. La tendance marketing actuelle est d'utiliser le (nouveau) terme Immuable comme équivalent au terme (historique) WORM. Mais il s'agit de deux capacités différentes. En dehors de faire plus moderne te plus compréhensif que Write Once et Read Many, je crois que cela vient de la traduction du terme anglais qui, une fois traduit en français, laisse penser à un comportement supposé... L'immuabilité assure que les datas ne peuvent être altérées par un malveillant externe. Mais dans les faits cela n'interdit pas (nécessairement) une modification ou suppression si l'opération s’exécute avec les bons droits. Dans le langage courant, le WORM est une forme d'immuabilité (en français), mais sans possibilité réelle de modification ou de suppression, même avec les bons droits et même avec une backdoor éventuelle du fournisseur (matériel ou logiciel). Le WORM est une écriture dans le marbre :) donc définitive. Historiquement, cela permet d'accéder à un niveau d'enregistrement dit réglementaire ou légal (par abus de langage). La donnée enregistrée en mode WORM (avec la méta-data qui va bien) peut faire office de preuve juridique = la nature de la donnée à sécuriser peut donc influer le choix. Dans le cas d'une sauvegarde pour se prémunir d'un malware, l'immutabilité peut suffire, mais attention un Snapshot n'est pas une sauvegarde. Mais simplement une prise de pointeurs à un instant sur une source. Cela ne garantit pas une complète sécurité contre la malveillance (principalement en cas de vol d'identité). Alors que le WORM garantie, que même en cas de vol d'identité (donc avec des droits de Super Super User) il ne doit pas être possible d'altérer la donnée. Donc dans ce cas, mettre sous WORM une donnée avec une rétention de 1 an doit signifier qu'il sera impossible (sauf casser la machine🔥) de supprimer ou modifier la data ou tout autre infos associées comme la date de rétention - une malveillance avec les bons droits peut juste être une modification de la durée de conservation (...) pour une suppression automatisée ☹️ S3 n'est pas du WORM ou de l'immuabilité, c'est juste un formalisme de communication pour envoyer des data (put) et en récupérer (get) via le protocole HTTP/HTTPs. Il est le plus pratique (et aussi le plus utilisé comme standard de faite) pour des envoies vers un service Cloud. Mais une réplication pourrait aussi bien faire l'affaire (un bon rsync 🤔). Une fois ce blabla partagé, le choix du mode de la sauvegarde dépend du coût (besoin pro ou perso), de la perf attendue (bien valider le temps sur la restitution souhaitée en cas de perte de la source, mais 500GB ce n'est pas énorme) et de l'objectif de sécurisation à atteindre (vrai WORM ou juste une copie sécurisée). Bref, un bon stockage S3 dans le Cloud (ou équivalent) peut faire l'affaire : à voir les conditions du fournisseur en garantie de conservation réelle (certains proposent de la multi copies = le site du fournisseur peut aussi flamber...), en coût de conservation et en restitution (glacier implique un délai non immédiat). Il y a même des fournisseurs avec une offre de vérification du contenu de la donnée (détection d'une malveillance lors des dépôts). Il serait dommage d'archiver un malveillant 😮et de le réintroduire en pensant faire une restitution propre. Pour ordonnancer le transfert tous les mois, ce n'est qu'une opération de sauvegarde (certains vont dire d'archivage) vers une destination externe (préférable) ou interne à l'entreprise. Cette destination sera alors WORM (plu sécure) ou immuable (plus pratique pour des changements souhaités) dans notre cas. Pour finir, je viens de lire cet article au sujet Restic. Je ne l'ai pas utilisé donc pas d'expérience à partager, mais il me semble être un bon soft pour envoyer vos données vers un Cloud S3 de votre choix : https://blog.stephane-robert.info/docs/cloud/outils/restic/

Bon finalement j'ai pu tout récupérer depuis linux et j'ai retrouvé le fichier .pat...sur le NAS...quel boulet (j'étais jeune et bête)...C'est la version modifié du 1635 pour tourner sur un CS406, si qq1 est intéréssé un jour (avant que je le reperde)...il fait 153Mo

Le Reverse Proxy n'est pas un moyen de sécurisation. C'est un mode de connexion qui permet de s'affranchir des ouvertures de ports en utilisant qu'un seul port. C'est généralement le 443 qui est le port https par défaut, mais vous pouvez très bien prendre un autre port si vous voulez, avec la contrainte de devoir le renseigner dans l'url. Il est illusoire de croire que le changement de port constitue une protection efficace. Ca ne fait que retarder (un peu) les attaques. Il n'y a pas de connexion externe sans risque et le seul moyen efficace pour les éviter c'est de ne pas les autoriser, ce qui limite drastiquement l'usage d'un NAS. Sinon, c'est au parefeu qu'il revient le rôle de protection. C'est lui qu'il faut régler pour limiter l'exposition vers l'extérieur. Le reverse proxy permet toutefois un réglage plus fin grâce aux profils de connexion. On peut en définir plusieurs pour protéger chaque application de manière spécifique. Perso, je n'en utilise qu'un pour protéger les applications sensibles pour lesquelles je ne veux qu'une connexion locale ou via le VPN. L'accès à DSM par exemple n'est possible de l'extérieur que via le VPN et à quelques ip publiques fixes de confiance qui m'appartiennent et qui ne sont là juste en cas de dysfonctionnement du VPN. Je n'ai pas de problème d'identification avec mes applications nomades. Chacune d'elle se connecte avec un ndd spécifique pour chaque application et certaines avec des identifiants différents. Mais peut-être est-ce du au fait que les identifiants sont enregistrés dans mon smartphone. L'accès à toutes les applications sensibles sont protégées soit par biométrie, soit par code. Les autres utilisent un identifiant dont les droits sont réduits au strict minimum.

Comme je bosse sur un projet utilisant Tailscale, ton sujet m'a interpellé en ai discuté avec la LLM qui me donne la main et voilà ce qu'il en ai ressorti en espérant que cela puisse t'éclairer : Pourquoi NextDNS “voit” 4 IP mais seulement 3 Apple🔍 Ce qui se passe réellementApple Private Relay : intercepte une partie des requêtes DNS + HTTP(S) les fait sortir via des egress Apple (Cloudflare / Akamai / Apple) masque l’IP source réelle parfois split le trafic : une partie passe par le DNS “système” une autre ne passe PAS par ton NextDNS 👉 Résultat : NextDNS voit : des IP Apple relay parfois plusieurs IP pour un seul device Le message NextDNS est volontairement flou car Apple ne documente pas précisément le mapping 🧠 Conclusion ➡️ Les 4 IP ≠ 4 machines ➡️ Ce sont des sorties Apple Relay, pas des hôtes réels Pourquoi les NAS Synology n’apparaissent PASEt là on arrive au point clé 👇 ⚠️ Les NAS n’utilisent probablement PAS NextDNSCas les plus fréquents sur DSM : ❌ Le NAS utilise : le DNS du LAN ou /etc/resolv.conf généré par DSM ou un fallback IPv6 ❌ Le trafic DNS du NAS : passe en dehors de Tailscale ou passe par Tailscale mais ne fait aucune requête DNS observable (cache, peu d’activité) ❌ Tailscale DNS ≠ garantie d’usage réel 🧠 Point fondamental ➡️ Tailscale DNS est déclaratif, pas coercitif Réponse à la question centrale 👉 Réponse honnête : NON, il n’en a aucune certitudeEt actuellement : ❌ Apple = couverture partielle (Private Relay) ❌ NAS = probablement hors périmètre ❌ Tailscale = aucune visibilité par device 🧭 Recommandations claires (par ordre de maturité)🟢 OPTION 1 — Vérification factuelle (indispensable)Sur chaque NAS Synology : cat /etc/resolv.conf Puis : nslookup google.com ➡️ Vérifier vers quel DNS ça sort réellement 🟢 OPTION 2 — Désactiver Apple Private Relay (si objectif = contrôle DNS)Sur Apple : iCloud → Private Relay → OFF 💬 Sans ça : aucun DNS central ne peut être fiable NextDNS, Pi-hole, AdGuard = tous aveugles partiellement 🟡 OPTION 3 — Forcer NextDNS par appareil (recommandé)Au lieu de “DNS global Tailscale” : Installer NextDNS client : sur macOS sur iOS sur DSM (possible via script / container sidecar) ➡️ Là, NextDNS tagge chaque appareil ➡️ Plus de doute ➡️ Plus de mapping fantôme 🟡 OPTION 4 — Architecture propre (niveau Rahan 🧠) Tailscale : transport DNS : local-first Apple Private Relay : OFF sur machines de confiance 👉 Sinon : Il empile des couches qui s’aveuglent mutuellement 🧩 Synthèse ultra-courte à transmettre à ton ami