.Shad.

Bienvenue parmi nous ! 🙂

@firlin Il existe bien des attaques de type ping flood : Attaque DDoS de type Ping (ICMP) flood | Cloudflare Maintenant, les chances que tu sois pris pour cible... ? Est-ce que ce réglage ne désactive pas également le ping en IPv6 ? qui lui participe à la bonne marche du transfert de données contrairement à l'IPv4.

Bienvenue parmi nous @zebulon60

En jouant sur le pare-feu tu pourrais oui, mais pour peu que ton conteneur SWAG ou Docker déconnerait, tu perdrais l'accès à ton NAS. Je n'y vois pas un grand intérêt à titre personnel.

Bienvenue parmi nous, c'est bien l'usage principal d'un NAS, jusque-là aucun problème 🙂, n'hésite pas à créer un fil dédié pour en discuter plus avant.

Bienvenue tu es au bon endroit !

@CyberFr Je vais essayer de tourner les explications de mes collègues différemment. C'est quoi un code TOTP ? C'est une clé qui, une fois entrée dans un logiciel d'authentification 2 facteurs (quelque soit la plateforme : PC, Android, iOS, Extension de navigateur, etc...) permet de générer un code à 6 chiffres, qui se renouvelle. On peut utiliser cette clé sur autant d'applications et périphériques qu'on veut. Le code généré sera le même et variera au même moment. Il est donc prudent d'avoir a minima deux sources d'authentification 2FA, dans mon cas j'utilise Aegis sur mon smartphone, et je l'ai aussi dans Bitwarden. Avantage de Bitwarden, c'est que même si le serveur est down, j'ai accès au cache du coffre depuis mes différents périphériques. Le code TOTP défini par DSM lorsqu'un utilisateur applique la 2FA à son compte n'est affiché qu'une seule fois. Il est donc important de : L'écrire manuellement sur papier et de le conserver en lieu sûr, sans indiquer ce que c'est, moi je le garde dans mon portefeuille. Configurer cet accès sur deux périphériques a minima. Secure Signin est une version intégrée à DSM, absolument pas obligatoire et plus contraignante selon moi, comme tu as pu le constater. J'ajouterai que les remarques de @Mic13710 sont pertinentes dans le sens où le plus important est d'avoir des credentials robustes conjointement avec les blocages correctement configurés sur le NAS. Le reste est intéressant mais dispensable.

@Patrix Merci du retour, je vais intégrer la remarque.

Généralement on n'utilise qu'un seul proxy inversé à la fois. Ce que DSM fait, SWAG peut le faire. Acme gère ton domaine principal c'est ça ? Qu'est-ce qui t'empêche de le basculer sur SWAG ? Si tu as un cas concret à présenter pour voir ce qui pose problème. Si le but est de laisser le proxy inversé sur le NAS, SWAG n'a aucun intérêt. Acme est plus indiqué. Concernant l'erreur du script, après plusieurs essais on avait remarqué que si tu écris .210/29 tu tronques certaines IP. Si tu vas sur le calculateur de jodies, tu dois indiquer ce qui est noté dans "network" : https://jodies.de/ipcalc?host=192.168.0.210&mask1=29&mask2=

Welcome !

@Dino Rayn Salut, j'ai bien parcouru ton post. Concernant les permissions il faudrait que je remette en oeuvre mon tutoriel, il a été rédigé il y a maintenant un certain temps, il se peut (c'est même sûr) que des étapes aient changé. Quoiqu'il en soit il est fort probable comme tu dis que les fichiers non visibles soient des liens symboliques. Il faut que je le confirme en reproduisant mon tutoriel. Pour le réseau macvlan et l'interface virtuelle, je note que tu as mis 192.168.50.210/29 dans une des déclarations et 192.168.50.208/29 dans l'autre, même si c'est censé couvrir la même plage autant spécifier des valeurs identiques. Concernant ton fichier conf pour Portainer il me semble ok. En revanche, si ton URL portainer.ndd.tld pointe vers Webstation, c'est que : - ta résolution DNS lui dit de le faire, donc vérifier si tu as un serveur DNS local et vérifier via un nslookup vers quoi pointe cette URL - tu n'as pas de résolution locale, en ce cas il est possible que la résolution soit publique, ce qui implique vu de l'extérieur, la redirection des ports 80 et 443 ne se fait pas vers SWAG mais vers le NAS - tu as potentiellement un cache persistant dans ton navigateur, supprimer donc les cookies liés à ton NDD ou faire un test en navigation privée. Dans ton cas, portainer.ndd.tld doit pointer vers l'IP de SWAG (.211) Je serais très étonné que tu puisses rediriger un même port vers plusieurs IP, sinon comment le routeur pourrait-il faire un choix ? le problème vient sûrement de là. Il faut effectivement que ces deux ports soient redirigés vers .211 Juste un peu de contexte, même si tu dois déjà le savoir. Par défaut, la meilleure manière de fonctionner pour SWAG est d'être dans un réseau bridge personnalisé. Ce qui se fait facilement quand les ports 80 et 443 de l'hôte sont libres, ce qui n'est pas le cas avec DSM. Dans ce contexte, tous les conteneurs qui ne nécessitent pas d'autre accès que via une GUI par exemple, n'ont aucune port exposé sur le NAS, ils sont simplement adjoints au réseau bridge de SWAG. Les fichiers de SWAG sont préconfigurés pour utiliser la résolution DNS interne de Docker, qui permet de joindre une application par le nom de son conteneur. Et dans ces conditions là uniquement, les fichiers conf sont utilisables sur le champ, si tu ajoutes le mod swag-auto-reload à ton instance, ça fait même en sorte que lorsqu'un fichier .conf.sample devient .conf, nginx est automatiquement rechargé pour en tenir compte. Ca c'est quand tu utilises SWAG sur un hôte libre, ou dans une VM. Dans notre cas, tu dois effectivement personnaliser l'upstream_app et l'upstream_port, mais rien de plus. Dans tous les cas, un fichier avec une extension autre que .conf ne sera pas actif.

Le code TOTP c'est le code qui permet de générer le jeton à 6 chiffres de la 2FA. C'est l'alternative au QR-Code, et même si tu as utilisé un QR-Code, tu peux sur n'importe quelle appli de 2FA accéder au code TOTP (qui peut être nommé clé secrète)

@CyberFr En plus des recommandations faites par @Mic13710 sous réserve que Vaultwarden intègre cette fonctionnalité de Bitwarden officiel, tu peux ajouter des codes TOTP dans tes entrées de coffre. Et l'extension pour navigateurs permet l'auto-complétion sur les sites pour lesquels tu as des entrées enregistrées. Hyper pratique.

Salut @Dino Rayn j'ai bien vu ton message, pas eu le temps de le lire je suis en déplacement je te réponds probablement ce soir ou demain. 😉

Bienvenue parmi nous !

Quand tu ajoutes des permissions dans Autoriser/Bloquer la liste dans Sécurité -> Protection -> Blocage auto, tu as "Adresse IP/Nom de domaine" et "Masque de sous-réseau/Longueur du préfixe", c'est dans ce dernier champ. Pour le VPN, essaie d'activer les passerelles multiples dans Réseau -> Général -> Paramètres avancés. Ca aide parfois à la résolution du problème. L'origine du problème est décrite ici : https://kb.synology.com/fr-fr/DSM/tutorial/Cannot_connect_Synology_NAS_using_VPN_via_DDNS Une solution aussi est que le fournisseur VPN mette à disposition une redirection de ports, ce qui de ce que j'ai compris n'est pas fréquent. @Eric1246 Salut, quel serveur SMTP utilises-tu ? Pour Gmail il faut maintenant créer un jeton d'accès dans leur API après avoir activé l'authentification à deux facteurs pour utiliser leurs services, voir la remarque tout à la fin de la page : https://kb.synology.com/en-nz/DSM/tutorial/How_to_use_Gmail_SMTP_server_to_send_emails_for_DSM Ou alors Outlook, ou un SMTP personnel ?

Oui c'est bien ça, tu mettrais donc 192.168.1.0 dans l'adresse IP et 24 dans le masque. Tu peux aussi décider de limiter à certaines IP spécifiques, par exemple le PC 1 et PC 2 uniquement ne peuvent être bannis lors de tentatives infructueuses de connexion. A toi de placer le curseur où tu le souhaites. Concernant la question sur le VPN, quelle IP as-tu tout simplement quand le NAS est connecté au VPN ? Si ça commence par 10, c'est une IP privée et ce serait étrange. Tu peux masquer C et D pour une IP de la forme A.B.C.D pour éviter de dévoiler ton IP publique ici. 😉

Oui car à la base j'avais laissé la règle pour le /16 (255.255.0.0) plutôt qu'un /24, mais effectivement tu peux limiter la plage à celle de ton réseau local. Je vais éditer pour être plus précis concernant les plages, merci de ton retour. 🙂 Concernant l'accessibilité de ton NAS lorsqu'il est connecté en tant que client VPN (si j'ai bien compris ?), quelle IP vois-tu ? l'IP publique fournie par ton fournisseur d'accès VPN ? @CMDC83 Merci de t'inquiéter pour ma conscience, c'est très aimable de ta part. Je n'ai rien de plus à ajouter que ce que j'ai dit dans le fil qui a été créé pour ne pas polluer ce sujet (tu as l'air de sous-entendre que tes messages ont été supprimés). Tu mélanges réseau local personnel et réseau "local" au niveau de ton FAI en CGNAT. Tu n'étayes en rien, nous si, mais merci de tes mises en garde.

Bienvenue dans la communauté. 😉

Oui ça fonctionnera. Le fait que Nextcloud permette d'être exposé de façon sécurisée nativement ne t'empêche pas d'utiliser le proxy inversé avec.

C'est le terme "réutiliser" qui me gêne. Ton proxy inversé peut être utilisé pour atteindre n'importe quel périphérique de ton réseau local. Tu l'utilises donc, le réutiliser sous-entend dans ma compréhension que tu veux récupérer le certificat, et l'utiliser pour des applis dédiées en HTTPS natif. Ce qui est tout à fait possible mais fastidieux et peu utile dans ton cas d'utilisation. La question m'interpelle quand même car au vu de ton impression d'écran tu fais déjà ce que tu demandes vers Nextcloud, Jeedom et ton nas de sauvegarde. Ca marchera tout aussi bien vers ton serveur Ubuntu avec Docker.

Bienvenue parmi nous 🙂

@firlin Tu ne t'embêtes pas à générer un certificat sur une machine pour l'utiliser sur l'autre. Chaque machine génére son certificat via validation DNS. Ca ne présente aucun avantage d'avoir un même certificat réparti sur plusieurs machines, à moins d'acheter ton certificat, ce qui n'est a priori pas ton cas.

Ceci à 1000%

Dans le tuto de sécurisation je couvre les étapes de mise en place d'un accès distant, après ça ne va pas droit au but. C'est vrai qu'un tutoriel dédié pourrait être intéressant. 👍🏼