TuringFan

@oracle7, Je viens d'essayer de recréer un certificat avec le code tappé sous WinSCP /root$ ACME_HOME="/usr/local/share/acme.sh" /root$ cd $ACME_HOME /usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld" /usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld" /usr/local/share/acme.sh$ export CERT_DNS="dns_ovh" /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" J'obtiens ensuite le log [Mon Dec 13 23:08:52 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory [Mon Dec 13 23:08:53 CET 2021] Create account key ok. [Mon Dec 13 23:08:53 CET 2021] Registering account: https://acme-v02.api.letsencrypt.org/directory [Mon Dec 13 23:08:54 CET 2021] Registered [Mon Dec 13 23:08:54 CET 2021] ACCOUNT_THUMBPRINT='***' [Mon Dec 13 23:08:54 CET 2021] Creating domain key [Mon Dec 13 23:08:57 CET 2021] The domain key is here: /root/.acme.sh/ndd.tld/ndd.tld [Mon Dec 13 23:08:57 CET 2021] Multi domain='DNS:ndd.tld,DNS:*.ndd.tld' [Mon Dec 13 23:08:57 CET 2021] Getting domain auth token for each domain [Mon Dec 13 23:08:59 CET 2021] Getting webroot for domain='ndd.tld' [Mon Dec 13 23:09:00 CET 2021] You don't specify OVH application key and application secret yet. [Mon Dec 13 23:09:00 CET 2021] Please create you key and try again. [Mon Dec 13 23:09:00 CET 2021] Getting webroot for domain='*.ndd.tld' [Mon Dec 13 23:09:00 CET 2021] Adding txt value: *** for domain: _acme-challenge.ndd.tld [Mon Dec 13 23:09:00 CET 2021] Error add txt for domain:_acme-challenge.ndd.tld [Mon Dec 13 23:09:00 CET 2021] Please add '--debug' or '--log' to check more details. [Mon Dec 13 23:09:00 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh Vois tu le problème ?

En fait ma première manip me sert à faire un "reset" pour partir d'une base propre avec des certificats qui tournent. Ensuite je force le renouvellement (pour anticiper ce qui se passera dans 3 mois) et pour vérifier que le process tourne correctement. In fine indépendamment des logs le certificat reste inchangé sur l'interface DSM ... Non pas encore passé sur DSM 7.0 : preneur d'ailleurs d'un lien pour les bonnes pratiques / pièges à éviter. Je me mets dans WinSCP en l'utilisant comme explorateur pour directement ouvrir le fichier que je vois bien dans le répertoire : c'est lors de l'ouverture que j'ai le message d'erreur. Comme ci le fichier était une coquille vide ... Oui, aucune ambiguïté la dessus : je voulais voir si j'avais un message d'erreur "exotique" ou si cela se comportait "comme avant". Cordialement,

@oracle7, Je viens de taper ACME_HOME="/usr/local/share/acme.sh" cd $ACME_HOME export CERT_DOMAIN="ndd.tld" export CERT_WDOMAIN="*.ndd.tld" export CERT_DNS="dns_ovh" ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt J'obtiens alors [Sun Dec 12 23:14:16 CET 2021] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory Je tape ensuite cd / volume1/Scripts python acme_renew.py -f ndd.tld J'obtiens un log qui termine par --- Le certificat n'a pas ete renouvele. --- => Consulter le log : /volume1/Certs/Acme_renew/acmelog Puis quand je vais ouvrir le fichier acmelog un message d'erreur m'indique que le fichier acmelog ne peut par être créé et il est précisé : Erreur système. Code : 123. La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte Que puis je faire ? A noter que j'ai essayé de renouveler le certificat en passant par le DSM mais en demandant un certificat pour "*.ndd.tld" un message d'erreur m'indique que les certificats génériques ne fonctionnent que pour les DDNS Synology. Preneur de tes lumières, je sèche ... PS : évidemment j'ai bien remplacé les "ndd.tld" par mon propre domaine à chaque fois.

Merci @oracle7, Pour le point 2 j'ai effectivement la ligne sur le defaut_acme-server sur mon fichier account. Voici ce que je tape : /volume1/Certs/Acme_renew$ cd $ACME_HOME /usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld" /usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld" /usr/local/share/acme.sh$ export CERT_DNS="dns_ovh" /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" Voici mon output [Sun Dec 12 21:19:46 CET 2021] Using CA: https://acme.zerossl.com/v2/DV90 [Sun Dec 12 21:19:46 CET 2021] Create account key ok. [Sun Dec 12 21:19:46 CET 2021] No EAB credentials found for ZeroSSL, let's get one [Sun Dec 12 21:19:46 CET 2021] acme.sh is using ZeroSSL as default CA now. [Sun Dec 12 21:19:46 CET 2021] Please update your account with an email address first. [Sun Dec 12 21:19:46 CET 2021] Please add '--debug' or '--log' to check more details. [Sun Dec 12 21:19:46 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh [Sun Dec 12 21:19:46 CET 2021] acme.sh --register-account -m my@example.com [Sun Dec 12 21:19:46 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA Où dois je m'inscrire ? Pas certain de suivre ce point. Merci d'avance as usual,

Merci @oracle7 pour la maintenance. J'ai "bêtement" ouvert mon SSH et tappé ces lignes de commande mais j'obtiens un message d'erreur ... /volume1/Scripts$ cd $ACME_HOME /root$ export CERT_DOMAIN="ndd.tld" /root$ export CERT_WDOMAIN="*.ndd.tld" /root$ export CERT_DNS="dns_ovh" /root$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt -ash: line 81: ./acme.sh: No such file or directory /root$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencryp -ash: line 83: ./acme.sh: No such file or directory Pourrais tu stp m'aider ? J'ai même un problème pout lire le fichier acmelog : un message d'erreur m'i,dique que le fichier ne peut être créé avec le message suivant : Erreur système. Code : 123. La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte Cordialement,

Lol je prends le point. Sinon @maxou56 m'a expliqué que dans ce cas besoin d'un couple identifiant / mdp d'un utilisateur admin ou des cles de chiffrement des dossiers (si migration, reset, etc.)

Très clair merci

J'utilise également pour des snapshot. je crois comprendre (sans maitriser) que les snapshots sont également sauvegardés lors des sauvegardes Hyper Backup. Merci encore oour tes réponses.

Sous l'hypothèse que le malfaiteur dispose d'un temps important sur le site, peut il opérer pour lire des données sans déconnecter le NAS de son alimentation ? C'est un cas bien plus théorique que réaliste je pense mais il me permet de parfaire mes connaissances NAS.

OK, merci. @maxou56 j'imagine que tu utilises Hyper Backup pour tes sauvegardes croisées ?

Ok merci @oracle7. A titre perso mon LAN est en 192. et mon VPN en 172. Impossible donc d'imposer au NAS des connexions physiques sur une classe spécifique comme on peut le faire ed faon analogue avec le DHCP ? C'est bien mon cas, un mdp de 114 bits. Merci @maxou56, Quid du cas des dossiers partagés chiffré mais montés au moment de l'attaque en physique ?

Ok merci,

Merci @maxou56 pour tes réponses, Ok donc en gros : Pour un NAS principal, chiffrer ses dossier partagés est une condition suffisante pour empêcher une lecture par un accès malveillant en physique ? M^mee si les dossiers partagés sont montés ? Pour un NAS secondaire (de sauvegarde), chiffrer la sauvegarde (mais pas les dossiers partagés) est une condition suffisante pour empêcher une lecture par un accès malveillant en physique ? Même si une sauvegarde : synchronisation est en cours ? Aucune règle spéciale pour des "IP physique" n'est utile pour le pare feu ? Pour le transfert quel est le plus intéressant en terme de sécurité / performance : le chiffrement hyper backup ou le VPN ? Un intérêt de cumulé les deux ?

Merci @oracle7 pour ta réponse, Je me demandais s'il y avait des choses à faire coté pare feu : les IPs LAN branchées en physique (ethernet / usb) ont-elles un format spécifique ? Rien de tel en dehors de ma recette du gâteau au chocolat lol. Je pensais par exemple à un accès root et/ou en utilisant les services de fichiers tels que SMB, CIFS, AFP, NFS, FTP, TFTP, rsync, etc. Ok, Merci

Merci @.Shad., c'est malheureusement explicite ... DSM 7 change -t-il quelque chose à cela ?

Bonjour à tous, Un upgrade vers DSM 7 change-t-il / simplifie-t-il l'implémentation d'une stratégie de sauvegarde double NAS telle que décrite dans premier post de ce fil ? Merci d'avance,

Bonjour à tous, J'ai deux questions : 1 - Quelle serait les capacités d'une personne malveillante si elle parvenait à se connecter physiquement (via un cable Ethernet ou USB) à un NAS (sans connaitre les logins) ? Comment se prémunir des éventuels risques liés à ce comportement ? J'ai posté ici à ce sujet. 2 - Y a t il des actions (en terme de sécurisation de son NAS) spécifiques à effectuer lors d'un upgrade vers DSM 7 si on a déjà suivi ce tuto sous DSM 6 ? Merci d'avance,

Bonjour @oracle7, J'ai cru comprendre que DSM 7.0 facilitait la gestion des certificats : un intérêt de migrer dans le cadre du sujet de ce fil ? Bonne journée,

Bonjour à tous, Ma configuration J'utilise File Station, Drive et Moment sans problème en passant systématiquement via des reverser proxy qui entrent par le port 443 et pointent ensuite vers des ports http. Je peux donc atteindre mes applications avec des adresses du type https://application.ndd.tld depuis des IP LAN, VPN et WAN (sauf pour File Station). Dans le menu avancé de la section accès externe du panneau de configuration j'ai : Nom de l’hôte : files.ndd.tld DSM (HTTP) : vide DSM (HTTPS) : 443 Comportement actuel Aujourd'hui lorsque je souhaite partager un fichier via un lien cela dépend de l'application. Via Drive (via navigateur ou application smartphone) Le lien généré est de la forme : https://drive.ndd.tld/x/y/123456789012345678 le partage peut se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée N'importe quel appareil en LAN, VPN ou WAN semble pouvoir accéder au fichier. Via Moment (via navigateur ou application smartphone) Le lien généré est de la forme : https://files.ndd.tld:X/mo/sharing/A2b4c5d6e7f9 [le nom de domaine correspond au paramétrage du nom d'hôte dans le menu accès interne (cf. précédemment) et X est le port HTTP vers lequel le reverse proxy de l'application moment pointe] le partage ne peut pas se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée En l'état aucun appareil en LAN, VPN ou WAN ne semble pouvoir accéder au fichier : il faut modifier le lien en remplaçant files.ndd.tld:X/ par photo.ndd.tld/ (ce qui correspond à l'adresse utilisée pour atteindre moment avec le reverse proxy). Avec cette modification qui doit être systématique et manuelle le fichier est accessible depuis un appareil en LAN, VPN ou WAN. Via File Station (uniquement via navigateur) Le lien généré est de la forme : https://files.ndd.tld/sharing/A2b4c5d6e7f9 [le nom de domaine correspond au paramétrage du nom d'hôte dans le menu accès interne (cf. précédemment)] le partage peut se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée un nombre limite d'accès peut être paramétré N'importe quel appareil en LAN, VPN ou WAN semble pouvoir accéder au fichier. Via File Station (uniquement via l'application smartphone) Le lien généré est de la forme : https://files.ndd.tld/sharing/A2b4c5d6e7f9 [le nom de domaine correspond au paramétrage du nom d'hôte dans le menu accès interne (cf. précédemment)] le partage peut se faire vers des users NAS seulement le partage peut être public le téléchargement est blocable un mot de passe peut être demandé une date d'expiration peut être ajoutée un nombre limite d'accès peut être paramétré N'importe quel appareil en LAN, VPN ou WAN semble pouvoir accéder au fichier. Mon besoin In fine je voudrais savoir comment avoir un comportement uniforme avec mes différentes applications (via application smartphone et/ou via navigateur) : notamment (i) ne pas avoir à manuellement modifier le lien généré par moment et (ii) permettre de gérer les droits associés au liens (utilisateurs NAS et/ou public, téléchargement blocable, mot de passe, date d'expiration, nombre limite d'accès, etc.). Savez-vous comment faire ? Peut-être utiliser les fonctions d'alias personnalisé et/ou de domaine personnalisé dans le portail des application ? Mais je reconnais volontiers que je ne comprend pas bien ces notions (surtout vs. un reverse proxy). Peut être sinon qu'une migration DSM 7.0 résoudra ce problème ? Mais j'appréhende un peu cette opération (peur que ce soit plus complexe qu'annoncé et/ou de perdre des fonctionnalités / applications) : je vais regarder les sujets des dockers avant (que je ne maitrise pas). Enfin c'est un autre sujet pour une prochaine fois. Merci d'avance pour votre aide,

@oracle7 et @Mic13710 merci je vais essayer dès que j'ai un peu de temps.

Merci @Mic13710, Concrètement dois-je reprendre la totalité du tuto ou y a t il que quelques manip à passer pour changer l'utilisateur ? Qu'est ce que le fail2ban ? Merci,

Bonjour @oracle7 et @bruno78, Ce tuto est toujours aussi utile et je l'utilise depuis plusieurs mois maintenant. Une seule chose qui semble un peu erratique : la durée de vie du DID (même en essayant de la paramétrer avec des extensions de navigateurs qui gèrent les cookies). Bref est un possible de dédier un utilisateur sans 2FA (probablement non admin) à l'exécution du script ? Si oui comment faire et avons nous un niveau de sécurité qui reste élevé ? C'est une vision long terme donc pas d'urgence sur la réponse. Merci d'avance,

Et pour l'histoire du bannissement de la cam ? Comment le faire proprement ?

@.Shad. merci pour ton retour, L'idée est la suivant. Imaginons un cambrioleur dérobant ou détruisant le NAS principal les vidéos de la surveillance deviendrait de facto non accessibles sauf pour celles déjà sauvegardées via Hyper Backup sur le NAS secondaire. Or la fréquence maximale de sauvegarde avec ce paquet est de 1h : il est donc fort probable que cela ne soit pas suffisant (NAS volé en moins de 1h). Le backup dans l'autre sens revient ensuite juste à dupliquer les vidéos dans le cadre d'une stratégie de sauvegarde standard. In fine le risque résiduel est donc : avoir un vol / une destruction du NAS principal et en même temps un vol / une défaillance du NAS secondaire. Je considère ce risque comme suffisamment faible. Voici ce que j'ai. Je pensais que le bannissement était bilatéral ... Comment banir proprement la cam dans les deux sens ? Merci encore,

Oui pardon, remarque bête. J'ai pour l'instant configuré par défaut un accès full depuis les IP LAN/VPN comme indiqué sur le tuto mais on peut au besoin affiner.