Overkilled

Synology Assistant n'utilise pas les ports par défaut pour détecter la présence ou non d'un NAS sur le réseau local. Il analyse plutôt les adresses matérielles MAC pour les repérer, au moins dans un premier temps. Ensuite, quels ports sont exploités pour établir la connexion à l'accueil de gestion, c'est dans le secret de Synology. On peut juste supposer qu'ils utilisent des bibliothèques telles que celles utilisées par les logiciels d'inspection du réseau tels que (gros trou de mémoire soudain) et identifier dans les paquets Ethernet le contenu des en-têtes (possiblement pas uniquement les en-têtes Ethernet ou IP, mais les tout premiers octets des données), pour y repérer des sortes de "watermark" définis par Synology. Faute de pouvoir consulter les sources, je spécule, mais c'est ainsi que je m'y prendrai si j'avais à développer un tel outil ou à en faire les spécifications. À partir de là, le port alloué par l'administrateur Synology fini par être reconnu et c'est pourquoi ça fonctionne même si ce n'est pas le port par défaut. Oui, c'est potentiellement une faille de sécurité. Et c'est sans doute pourquoi Synology déconseille fortement d'avoir son NAS directement exposé à Internet. Au minimum, il faut avoir déjà un routeur d'intercalé avec un firewall (intégré ou non) permettant de filtrer parmi les connexions entrantes, celles qui peuvent ou non référencer tel ou tel nœud du réseau ou (mieux encore) du sous-réseau local. À ce propos, attention à ceux qui utilisent IPv6. Il faut ne pas oublier qu'il n'y a pas dans ce cas la "barrière" du NAT IPv4. Ce qui veut dire qu'en plus des adresses Ipv6 locales de base, chaque nœud IPv6 a également une adresse globale accessible par Internet (en l'absence de firewall efficace correctement configuré). Après, il y a les adresses IPv6 globales dynamiques (le choix par défaut fait par Windows) mais possiblement des statiques, que ce soit voulu ou non. En résumé, en IPv6 il faut être bien plus prudent qu'en IPv4 (en dehors du fait que toutes les tentatives majeures d'intrusion se font massivement toujours en IPv4, parce que c'est plus simple et que la botte de foin où peut se cacher un de vos nœuds et bien plus petite en IPv4 (32 bits d'adressage) que celle de l'Ipv6 (132 bits d'adressage dont généralement 64 à la disposition de l'utilisateur final).

N'ayant pas ce besoin, je n'ai pas de solution toute faite, mais quelques suggestions de pistes à explorer. De manière générale, dans la configuration d'un VPN de type OpenVPN, avoir accès aux machines (PC, imprimante, etc.) du réseau local usuel (autre que le serveur VPN) est une option à mettre en place. De même, pour avoir accès aux autres services du serveur VPN (autre que le service VPN lui-même) il faut que les règles globales ou spécifiques VPN du firewall permette les accès en question. Parce que de manière générale, la règle de l'art veut que les règles des accès via notre serveur VPN dédié (celui que nous gérons) soit distinctes de celles qui arrivent d'Internet sans passer par notre VPN. Les règles Internet étant normalement plus restrictives en accès permis que quand on passe par le VPN (la fourniture d'un nom d'utilisateur, d'un mot de passe et d'un certificat valide établissant une "relation de confiance"). En résumé : Passer en revue les options activées/désactivées du serveur VPN Passer en revue les accès autorisés globalement par le firewall et celles que le VPN autorise en plus. Oublier les protocoles VPN qui ne s'appuient que sur des mots de passe. Je suis largement incompétent en ActiveDiretcory et plus largement les solutions spécifiques Microsoft. De manière générale, je fuis les solutions propriétaires, notamment quand elles sortent des normes peu ou prou.

De manière générale (je ne fais que la synthèse de ce qui a été dit par les intervenants) : Toujours avoir au moins une "roue de secours" en configuration 2FA : soit un gestionnaire adapté, soit des méthodes alternatives à l'usuelle (par mail, SMS ou autre alternative) Penser à désactiver le 2FA lors d'un changement de téléphone et avant ce changement (bref pas dans le cas où l'ancien est déjà KC) Éventuellement, avoir un compte de secours (avec le minimum de privilèges requis pour gérer les autres comptes, mais je crains qu'"administrateur" ne soit requis sur Synology, ce qui revient à avoir tous les privilèges) avec un nom et surtout un MDP hautement sécurisés (non 2FA), qui ne sera jamais utilisé sur Internet, mais uniquement pour solutionner les situations critiques, en local. Idéalement, ce compte ne pourrait être actif que par des connexions locales. Mais là, j'avoue ne pas savoir si c'est déjà prévu par DSM (j'en doute) ou s'il faut "hacker" son Synology pour y parvenir. Bien que l'idée soit intéressante, je me fais un peu vieux pour avoir eu l'idée de tenter la manip, je n'ai pas ce genre de besoin critique.

Juste une remarque de physique basique : si percer le meuble est une bonne idée pour bien aérer son NAS en vue de faciliter son refroidissement, comme le son se propage dans l'air, ça facilitera également la sortie du son et donc son audition, à moins de mettre en face des trous une surface atténuant les ondes sonores (je fais simple). Si on ne veut pas se louper, il faut un minimum prendre conseil auprès de quelqu'un qualifié en acoustique pour trouver une solution adaptée : Qui ne bride pas l'écoulement d'air nécessaire au refroidissement Mais qui atténue ou piège les ondes sonores (et dans ce second cas, le risque, c'est d'en faire un amplificateur, comme la caisse d'un violon, si on se plante dans la géométrie et nature physique du piège à son).

Je ne connais pas le tutoriel fenrir, mais ça importe peu. En DNS de base, sauf à vouloir répartir la charge sur différents serveurs offrant des services identiques communs, on n'assigne pas plusieurs adresses IP à un même nom de domaine. Quand les "vues" (views) n'existaient pas, la seule solution était d'utiliser des noms de domaines différents (1 pour chaque IP), par exemple "local.mondomaine.org" et "vpn.mondomaine.org". Avec les vues, on peut "partitionner" l'espace des adresses IP entrantes. Ce qui permet (par exemple) : De ne pas divulguer à l'Internet le nom toutes les machines de ton réseau et en particulier celles qui n'ont que des adresses locales (directes ou celles allouées par le VPN). D'utiliser le même nom de domaine pour différentes IP (une par vue). Mais la condition est que tu puisses mettre en place des règles sur les IP entrantes, pour faire une sorte d'aiguillage. Par exemple : Tout ce qui vient d'Internet ou d'un pays donné Tout ce qui vient du réseau local Tout ce qui vient du VPN que tu utilises Tout le reste. Par contre, je ne comprends pas bien le besoin d'avoir un nom de domaine pour ton adresse VPN autrement que pour la repérer dans les logs. Et puis, avec un NAS Synology, il me parait bien difficile (à moins d'être une sorte de geek) de mettre à jour dynamiquement (bah oui elle changera à chaque nouvelle connexion au serveur VPN) cette adresse IP allouée par le VPN. Parce que c'est une adresse locale (au VPN) qui est privée (le "P" de VPN) et qui n'est pas interrogeable sur Internet, donc. Bref, à moins de mettre les mains dans le cambouis technique (écrire un shell script à minima) et avoir bien lu le manuel de référence DNS, tu auras bien du mal à trouvé un outil, déjà tout fait, pour répondre à ton besoin.

Bonjour, Si ce n'est pas trop tard, voici ce qu'il faut commencer à faire et qui ne requiert aucune compétence technique particulière. Comme tu ne précises pas grand-chose, on peut déjà faire l'hypothèse que par défaut (si ce n'est pas le cas pour "homes", ce n'est pas malin quand on s'adresse au grand public) que la "Corbeille" était activée et qu'elle n'a pas été déjà vidée manuellement ou automatiquement par une tâche périodique (chez moi, je nettoie tous les jours durant la nuit). Bref, si tu retournes là où tu as fait la fausse manip (le gestionnaire de fichier "File Station", je suppose) alors si tu vas dans "homes". Si tu as de la chance, tu devrais y trouver un dossier "spécial" de nom "#recycle" (c'est la corbeille) et tu n'auras qu'à fouiller dedans pour y récupérer le dossier qui porte ton nom d'utilisateur pour le déplacer vers "homes". Si tu remarques également l'existence (ça dépend de ta config) d'un dossier "spécial" de nom "#snapshot" alors, dans le cas où la première manip ne peut pas être utilisée, il y aura une seconde chance éventuelle. Je n'explique pas d'avance. Autrement, il ne resterait plus que les sauvegardes. Sauf qu'il faut y avoir pensé avant la fausse manip. Après, c'est trop tard, sauf pour réduire le risque de perte malencontreuse, dans l'avenir. P.S. : Je n'ai pas fait l'hypothèse que tu avais déjà essayé ce que je viens de décrire, parce que récupérer des données effacées, il existe des outils pour ça, mais même si ce n'est pas sorcier, ce n'est tout de même pas à la portée de l'utilisateur qui ne s'intéresse pas à la technique informatique, ce qui semble être ton cas.

La première tentative aura été la bonne. J'ai juste un coup de vim sur le fichier <n>.json qui n'existait pas encore (mais dont le <n> est le successeur direct du <n> max d'avant sa création), copié/collé de tes données dans celui-ci, puis fermeture de vim (bien sûr) et ça aura suffi. J'ai précisé, pour ceux qui, moins expérimentés, rencontreraient le même problème et tomberaient sur ce fil, puisse sans sortir sans avoir besoin de plus d'aide. C'est pourquoi, je précise également que j'avais pris le soin de fermer complètement la fenêtre du "panneau de configuration" avant de modifier quoi que ce soit. En conclusion, je n'ai plus qu'à conserver précieusement une copie du profil que tu m'as fourni (ou une version encore plus expurgée) avant de reconfigurer un profil qui correspond à mes besoins. Et quand tout ça sera fait, en attendant que nouvelle version de DSM intègre des fonctions d'import/export de profils de firewall, je mettrai en place une tâche périodique de recopie (rsync ou shell script) du répertoire "/usr/syno/etc/firewall.d" vers un des répertoires que j'inclus dans mes sauvegardes usuelles. Encore un grand merci et je me tiens à la disposition de qui tomberait sur le même problème, mais aurait besoin d'un coup de pouce supplémentaire à la seule lecture de ce fil. Il va de soi (pour moi en tout cas) que si je peux te rendre service (même si j'imagine difficilement que cela pourrait devenir le cas), c'est avec plaisir que je le ferai. P.S. : Je suis novice du forum en tant que "rédacteur". Il serait certainement utile à tous de changer le titre du fil pour ajouter un joli [Résolu]. Si je n'arrive pas à le faire, ce serait bienvenu qu'un administrateur s'en charge.

Bon, je suis un peu rouillé par l'âge et ma santé, mais je ne devrais pas avoir à recréer le lien agrégé, il est toujours fonctionnel. C'est juste que j'ai perdu la possibilité de changer de profil, ni même d'en éditer un via DSM (interface graphique), d'où ma demande pour tenter de remettre les choses d'équerre en ligne de commande pour pouvoir le faire à nouveau via DSM. Mon unique fichier .json non vide est clairement tronqué et c'est pourquoi j'ai trouvé inutile d'en fournir une copie. Avec la copie expurgée que tu m'as fournie, j'en ai déjà un syntaxiquement correct. Si sémantiquement, il ne colle pas à ma configuration (pas encore testé) je devrais finir par y parvenir par essais successifs. Heureusement le firewall est toujours fonctionnel même si c'est une passoire, je peux au moins l'interroger, l'activer et le désactiver. Je devrais donc bien finir par glaner toutes les informations nécessaires à intégrer dans un .json minimaliste adapté à ma machine. Je ne devrais pas avoir besoin de modifier le fichier "firewall_settings.json", il pointe déjà (ou plutôt encore) sur le nom du profil qui m'était usuel, mais a disparu. Et c'est bien ça qui me préoccupe en tâche de fond. Je n'ai rien bidouillé depuis des mois, voire plus. Je n'ai pas eu d'arrêt anormal (onduleur) ni de redémarrage autre que d'appliquer la dernière version de DSM dès qu'elle avait été publiée. Je n'ai plus que l'hypothèse d'une intrusion qui aurait échappé à ma vigilance ou d'un bug de DSM plutôt rare (ce qui m'étonnerait déjà moins vu que j'ai toujours eu le chic de tomber sur ce genre de bugs). Par simple politesse, je te tiendrai au courant de la suite (j'y vais molo à mon âge). Et encore, chaleureusement merci, car si j'ai aimé dans ma vie professionnelle de pratiquement toujours partir de zéro ou presque, j'étais plus jeune et e, dehors de mon premier Windows 98, ce n'était pas chez moi. @+

Merci grandement. Je vais pouvoir plus assurément avoir une chance de détecter ce qui pourrait manquer ou avoir été corrompu et faire le nécessaire pour m'éviter la réinitialisation complète. Ce qui m'inquiète un peu, c'est que ça ressemble fichtrement à celui que j'ai sous le coude (je suis également en "bond") alors que DSM ne le prend pas en compte. Encore merci

Merci de ces premières informations. Pourrais-je avoir un exemple minimaliste (mais fonctionnel) du contenu d'un de ces fichiers (n).json ? C'est pour que je puisse identifier ce qui pourrait être corrompu de mon côté. En attendant, je vais jeter un coup d'œil sur le seul (sur deux) qu'il me reste de non-vide. Pour essayer de comprendre : 1) Pourquoi il ne me semble pas être pris en compte par DSM 2) En quoi DSM ne me permet ni de l'éditer, ni même de le cloner 3) Pourquoi (enfin) c'est bien mon profil principal ('"sécurisé") qui est listé, mais pourquoi je n'ai même pas la mention "(actif)" qui lui est associé (copie d'écran jointe).

Bonjour à tous. En voulant bloquer tout un bloc réseau qui tentait par force brute de hacker mon serveur mail (un message d'auto-blocage toutes les minutes), en ouvrant l'interface graphique du firewall, je constate que je ne peux plus modifier le profil courant (messages d'erreur) et que, par ailleurs, la liste des profils disponibles est totalement vide. J'ai donc contacté le support de Synology après avoir en vain cherché une solution dans la base de connaissances de Synology. La réponse su support est décevante (j'avais eu un bien meilleur retour lors de mon précédent et tout premier ticket) : réinitialiser (mode 2) mon DSM, au motif qu'ils ne font pas de support SSH et que j'aurais des paquets tiers, ce qui n'est pas faux, mais il s'agit uniquement de ceux proposés par Synology (Git, Apache, Python, Perl, etc.). Pour moi (ex-ingénieur système en retraite), c'est comme vouloir écraser une mouche avec un marteau-pilon. Je leur ai donc demandé s'il était possible d'avoir accès à la documentation décrivant le stockage des données du firewall gérables via l'IHM graphique de DSM. En utilisant la ligne de commande vis SSH, je n'ai pas réussi à trouver où DSM 7 stockait les profils de firewall de l'utilisateur et encore moins le fichier ou l'arborescence qui en donne la liste complète. Et comme c'est parti avec le support de Synology, je doute fort qu'ils me fournissent les informations qui me seraient utiles à restaurer le minimum nécessaire à la résolution du dysfonctionnement constaté. Je leur ai d'ailleurs fait remarquer que je ne comprenais pas pourquoi DSM ne fournissait pas de fonction export-import de profils de firewall alors qu'ils en fournissent pour de nombreux paquets ou fonctionnalités. Je me tourne donc vers ceux d'entre vous qui pourraient me fournir les informations utiles à réparer en ligne de commande la gestion DSM des profils de firewall. Merci d'avance