[TUTO] Sécuriser les accès à son nas - DSM 6.x

[.Shad.]

Il y aurait trop à dire, je sais pas quelle est la logique derrière, mais le principe du pare-feu est simple. Tu repars des règles de base du tutoriel. Pour requête donnée, tant qu'une règle ne remplit pas les conditions elle continue à parcourir la liste. A la fin tu as la règle de refus général.

Je serais toi j'efface tout, et j'ajoute juste l'accès depuis le LAN et après je liste tout ce dont j'ai besoin et je vérifie si c'est déjà géré par une règle existante.

Modifié le 15 mai 2021 par .Shad.

[MilesTEG1]

@.Shad. J'avais prévenu que ce serait pas terrible 😉

Je sais que j'ai un certains nombre de règles redondantes au niveau du LAN, ce sont celles-là que je vais devoir virer.
Après le reste me semble plutôt propre...

[MilesTEG1]

Voilà, j'ai viré plein de trucs qui ne servait pas 🙂

Les 3 premières règles sont pour les différents réseaux LAN.

Je garde la possibilité d'ouvrir les ports 80 et 443 au monde complet quand je renouvellerais les certificats.
Jusqu'à ce que je décide de passer sur SWAG 🙂 

[Einsteinium]

Tu vas me détester mais… déjà on règle par interfaces et non pas toutes les interfaces.

la règle 172… inutile, c’est du localhost pour le nas.

la règle 10… vis à vis de quoi ? Vpn ?

la 192… utile d’ouvrir la totalité des ports aux appareils locales alors que tu en utilises même pas une dizaine ?

Tu as encore du nettoyage à faire, @Pascalou59 tu en penses quoi après notre session quand tu vois cela ?

Pour finir, si tu as ton domaine chez ovh, utilises mon tutoriel docker, plus de port à ouvrir, plus rien à faire pour le renouvellement 😉

[.Shad.]

Il y a 6 heures, Einsteinium a dit :

la règle 172… inutile, c’est du localhost pour le nas.

S'il ne met pas cette règle, il aura des problèmes, par exemple faire un poll SNMP du NAS depuis Telegraf en bridge.
172.16.0.0/12 ce n'est pas localhost, c'est un réseau privé comme les autres de la RFC1918.

@MilesTEG1 Pourquoi ouvrir Synology Assistant à la France ? (et peut-être d'autres services, on ne voit que les premiers dans l'avant-dernière règle).

Modifié le 16 mai 2021 par .Shad.

[MilesTEG1]

Il y a 6 heures, Einsteinium a dit :

Tu vas me détester mais… déjà on règle par interfaces et non pas toutes les interfaces.

Non je déteste personne, enfin presque 😛
J'ai juste suivi les recommendations du tuto :

Le 01/12/2016 à 19:33, Fenrir a dit :

Dans un premier temps, je vous recommande vivement de configurer votre pare feu avec les 4 règles ci-dessous, à l'identique !!

nb :

• dans les 3 premières règles, il faut bien choisir "Sous-réseau" et pas "Hôte unique" ni "Plage d'IP"
• ici j'utilise uniquement la table "Toutes les interfaces" car c'est plus simple à gérer et suffisant pour la plupart des besoins, si vous souhaitez utiliser les règles par interfaces, lisez ceci

Et c'est aussi quand même plus pratique à gérer ainsi. Déjà que c'est pas super ergonomique d'accès...

 

Il y a 6 heures, Einsteinium a dit :

la règle 172… inutile, c’est du localhost pour le nas.

Voir réponse de @.Shad.

 

Il y a 6 heures, Einsteinium a dit :

la règle 10… vis à vis de quoi ? Vpn ?

Oui, je crois, mais surtout elle est présente dans le tuto (cf. citation précédente).

 

Il y a 6 heures, Einsteinium a dit :

la 192… utile d’ouvrir la totalité des ports aux appareils locales alors que tu en utilises même pas une dizaine ?

Là comme ça, effectivement, ça ne sert pas à grand chose... Mais c'est une règles présente dans le tuto.
Mais ça ne craint pas vraiment ça, ce ne sont que des IP locales, non ?

Il y a 6 heures, Einsteinium a dit :

Pour finir, si tu as ton domaine chez ovh, utilises mon tutoriel docker, plus de port à ouvrir, plus rien à faire pour le renouvellement 😉

OK j'irais voir en détail plus tard (j'ai un test badblocks en cours, je voudrais pas que ça le stoppe...).
Mais j'ai vu que ta méthode utilisait l'API OVH, comme SWAG, et ça permet de ne pas avoir besoin de valider via les ports HTTP & S, c'est bien ça ?

 

Par contre, y a moyen de garder un nom de domaine synology et donc un certificat LE pour certains services ? En plus de mon nom de domaine OVH pour d'autres services ?

Quand j'aurais fini le test badblocks, et que j'aurais créé un nouveau nom de domaine (je veux changer l'actuel), je verrais avec ton tuto qui me semble quand même plus simple que celui sur SWAG 😉 
Petite question toutefois, sans avoir lu très attentivement ton tuto, comment ça se passe quand on veut ajouter un nom de domaine ? Il est wildcard le certificat avec ta méthode ?
 

il y a 29 minutes, .Shad. a dit :

@MilesTEG1 Pourquoi ouvrir Synology Assistant à la France ? (et peut-être d'autres services, on ne voit que les premiers dans l'avant-dernière règle).

Haa oui, je ne me rappelle plus vraiment pourquoi j'avais ouvert ça... Peut-être un misclic... (le support Synology peut-il demander à ouvrir Synology Assistant ?)
Mais la suite était pour Drive Server... J'ai donc laissé que ce dernier dans la règle...

Par contre, c'est quoi ce sauvegarde réseau qui est avec Synology Assistant ?

 

Merci pour vos conseils 😉

 

[.Shad.]

il y a 36 minutes, MilesTEG1 a dit :

Déjà que c'est pas super ergonomique d'accès...

J'ai vu bien pire pour un pare-feu 😄 je trouve que celui du NAS est pas si mal (malgré quelques défauts comme impossibilité de différencier IPv4 et IPv6...).

il y a 40 minutes, MilesTEG1 a dit :

Oui, je crois, mais surtout elle est présente dans le tuto

Eh ! Tu as mis suffisamment de choses en place pour ne plus te permettre de répondre ce genre de chose ! 😄 
Faut que tu saches pourquoi tu l'autorises ou pas. 😉

il y a 41 minutes, MilesTEG1 a dit :

Mais j'ai vu que ta méthode utilisait l'API OVH, comme SWAG, et ça permet de ne pas avoir besoin de valider via les ports HTTP & S, c'est bien ça ?

Tu peux choisir une validation HTTP-01 qui passe par les ports du NAS, ou DNS-01 qui passe par l'hébergeur de la zone DNS. Comme sur DSM. Ou SWAG.

il y a 57 minutes, MilesTEG1 a dit :

Par contre, y a moyen de garder un nom de domaine synology et donc un certificat LE pour certains services ? En plus de mon nom de domaine OVH pour d'autres services ?

Si tu utilises acme.sh tu peux utiliser le même certificat et domaine pour tout. Vu qu'il y a un script de déploiement dans DSM qui facilite la chose, contrairement à Certbot (qui est utilisé dans SWAG).

[CyberFr]

Puisqu'il est question de pare-feu et d'IP locales, je constate qu'il y a une différence entre les règles locales du pare-feu définies dans le tuto Sécuriser les accès à son NAS et les IP locales acceptées pour activer les services de résolution dans le tuto DNS Server.

La règle 127.0.0.0 n'existe pas dans le pare-feu. Quelqu'un peut m'expliquer pourquoi ?

[Einsteinium]

il y a 59 minutes, MilesTEG1 a dit :

Voir réponse de @.Shad.

Tu casses donc l’isolation des dockers en fessant cela… bref c’est pour sa que je dis que c’est du localhost, dans la mesure où c’est un sous réseau privé du nas, à partir du moment où l’on a besoin que les docks communiquent en entrée/sortie, on fait de l’ouverture de port ou l’on met en host, on ouvre pas le sous réseau privé…

 

il y a 59 minutes, MilesTEG1 a dit :

Et c'est aussi quand même plus pratique à gérer ainsi. Déjà que c'est pas super ergonomique d'accès...

C’est ludique certes, mais cela amène à des bêtises :

il y a 59 minutes, MilesTEG1 a dit :

Oui, je crois, mais surtout elle est présente dans le tuto (cf. citation précédente).

Et donc ? On ne mets en application que ce qu’on utilise, on ne met pas tout comme ça pour rien.

 

il y a une heure, MilesTEG1 a dit :

Mais ça ne craint pas vraiment ça, ce ne sont que des IP locales, non ?

Moi je range mes ip locale par bloc et je n’ouvre au bloc que ce qu’il a besoin, inutile d’ouvrir 65k de port à tous le monde, routeur compris, cela ne craint pas tant que aucun de tes appareils locaux est sain, faut avoir bossé en entreprise pour comprendre.

 

il y a une heure, MilesTEG1 a dit :

Mais j'ai vu que ta méthode utilisait l'API OVH, comme SWAG, et ça permet de ne pas avoir besoin de valider via les ports HTTP & S, c'est bien ça ?

Voilà pas de port à ouvrir vers l’Irlande 🙂

 

Oui tu peux faire vivre ensemble plusieurs domaines ensembles, juste que celui par ma méthode sera marqué en défaut si import automatique après le renouvellement (donc attribué aux services qui ne seront pas attribués à celui synology), oui en wildcard pour la création dans le tutoriel, pour finir comme je l’ai déjà dit SWAG est intéressant sous dsm 6 ou moins, mais je ne lui trouve aucun intérêt sous dsm 7 😉

 

[.Shad.]

il y a 8 minutes, Einsteinium a dit :

Tu casses donc l’isolation des dockers en fessant cela… bref c’est pour sa que je dis que c’est du localhost, dans la mesure où c’est un sous réseau privé du nas, à partir du moment où l’on a besoin que les docks communiquent en entrée/sortie, on fait de l’ouverture de port ou l’on met en host, on ouvre pas le sous réseau privé…

Tu ne casses pas l'isolation des conteneurs entre eux, juste avec l'hôte.
Si tu veux vraiment isoler un conteneur tu ne l'ajoute à aucun réseau, et il ne sera accessible que par console depuis l'hôte.

Tu as déjà une limitation aux données auxquelles accède le NAS via le montage des volumes, et tu peux très bien voir dans le Dockerfile d'une application quels ports sont utilisés, si tu as peur d'une activité suspecte.

 

[MilesTEG1]

@.Shad. @Einsteinium

Merci pour vos précisions.
Je pense que quand mon badblocks sera temriné, je mettrais en place le tuto de @Einsteinium pour les certificats. en espérant ne pas avoir besoin de tout refaire quand DSM 7 fera son apparition en version finale...

Je viens de supprimer la règle concernant les IP 10.0.0.0 car effectivement je pense que en n'en ai pas besoin.

Pour le parefeu, étrangement je trouve celui du routeur mieux pensé, alors que SRM est basé sur un vieux DSM...

Il manque par contre des deux cotés, un moyen d'exporter et d'importer des règles.

il y a 39 minutes, Einsteinium a dit :

Moi je range mes ip locale par bloc et je n’ouvre au bloc que ce qu’il a besoin, inutile d’ouvrir 65k de port à tous le monde, routeur compris, cela ne craint pas tant que aucun de tes appareils locaux est sain, faut avoir bossé en entreprise pour comprendre.

Et donc tu ne mets de règles que pour les IP de ton LAN et aucune autres ?
 

 

Donc au-delà des IP LAN peut-être un peu large, je pense que mon parefeu est maintenant plutôt bien configuré ^^ 

 

Bonne journée à tous 🙂 

[CyberFr]

Il y a 2 heures, CyberFr a dit :

La règle 127.0.0.0 n'existe pas dans le pare-feu. Quelqu'un peut m'expliquer pourquoi ?

Je me réponds à moi-même. J'ai trouvé la réponse ici  : localhost

[Einsteinium]

Il y a 2 heures, MilesTEG1 a dit :

en espérant ne pas avoir besoin de tout refaire quand DSM 7 fera son apparition en version finale...

Non il n'y aura rien a faire suite à la migration, c'est l'avantage de la solution docker 🙂

 

[MilesTEG1]

il y a 45 minutes, Einsteinium a dit :

Non il n'y aura rien a faire suite à la migration, c'est l'avantage de la solution docker 🙂

 

Yes 😄 

 

[VooBo]

Dommage que les images de ce tuto ne soit plus disponibles !

[Jeff777]

il y a 13 minutes, VooBo a dit :

Dommage que les images de ce tuto ne soit plus disponibles !

Bonjour. Elles le sont, il suffit d'attendre un peu 😉

[PatrickBt]

Bonjour,

Il y a une une notion que j'ai dû mal à comprendre dans le tuto au niveau de la redirection : Fenrir écrit

Citation

Je ne redirige pas automatiquement les connexions HTTP vers HTTPS car je n'expose pas DSM directement sur Internet (il y a un serveur VPN pour ça), mais si vous le faites, activez la redirection.

Attention, j'ai pu constater qu'activer la redirection HTTP vers HTTPS cassait certains mécanismes, au moins le reverse proxy pour les applications de base (audio/download/file/surveillance/video - station). Si vous souhaitez profiter de la redirection sans casser le reverse proxy, le plus simple est de créer un petit fichier php à la racine de Webstation (/web/index.php) pour gérer cette redirection :

<?php
$http_host = $_SERVER['HTTP_HOST'];
// 307 Temporary Redirect
header("Location: https://$http_host",TRUE,307);
exit;
?>

Le script, c'est pour éviter de cocher la case "redirection HTTP vers HTTPS" ?

Si je coche la case de redirection, j'ai des problèmes d'accès avec des applications que je gère via le reverse proxy et me retrouve avec ce message "Cette page n’est pas disponible pour le moment"

Sans cocher la case de redirection HTTPS et en ayant créé ce fichier php à la racine de Webstation (/web/index.php) pour gérer cette redirection, lorsque je fais http://192.168.1.88:5000/, la page s'affiche en http. Pourquoi le script ne redirige pas en https sur le port 5001 ?

Par avance, merci

Patrick

[Jeff777]

Bonjour,

 

il y a 15 minutes, PatrickBt a dit :

Pourquoi le script ne redirige pas en https sur le port 5001 ?

La certificat est attaché à un nom de domaine et non à une adresse locale.

[PatrickBt]

il y a 15 minutes, Jeff777 a dit :

La certificat est attaché à un nom de domaine et non à une adresse locale.

Ok, c'est donc pour cela que le script ne fonctionne pas sur une adresse ip. Merci.

 

Mais si j'ouvre le port 443 sur le routeur et le pare feu du Nas, c'est risqué de ne pas cocher la case de redirection. Je serais bien tenté de dire non, car ce port ne peut pas être utilisé en http. Si j'ai bien compris ! Je préfère poser la question.

[Jeff777]

Si le port 80 est bloqué par le pare-feu du nas une requête de l'extérieur en http n'aboutira pas sans le fichier de redirection .php ou .htaccess. Avec l'un de ces fichiers elle aboutira en https pour peu que l'adresse utilisée corresponde à un proxy inverse existant tartanpion.ndd   et qu'un certificat soit attribué à ce domaine.

[PatrickBt]

Merci à toi pour ces explications. C'est parfait.

Le port 80 est ouvert sur le nas, mais il est bloqué sur le routeur. Donc pas soucis venant de l'extérieur sur ce port.

[TucBene]

Bonjour,

J'ai suivi partiellement le premier tuto pour débutant à savoir l'installation de dsm sur un nas ds220j.

Ensuite j'ai lu le 2ème tuto de Fenrir et je me heurte à un soucis. Il s'agit de créer un compte administrateur.

Avec le 1er tuto j'ai créé un compte. Et lorsque je vais dans les paramètres utilisateur je vois mon compte nouvellement créé et 2 autres désactivés par défaut à savoir "guest" et "admin". Je n'ai donc pas à créer un autre compte admin puisqu'il y en a déjà un de fait. Ou alors j'ai zappé quelque chose.

Si je pousse ma réflexion, le compte "admin" créé par défaut ne sert à rien. Et celui que j'ai créé à l'installation EST le compte administrateur ? et donc je dois le modifier ? ou alors je dois créer un autre compte admin en suivant les conseils de Fenrir ? Ou alors synology a eu la bonne idée de créer un compte admin désactivé par défaut depuis la dernière version dsm (6.2.4 ?)

[MilesTEG1]

il y a 9 minutes, TucBene a dit :

Si je pousse ma réflexion, le compte "admin" créé par défaut ne sert à rien. Et celui que j'ai créé à l'installation EST le compte administrateur ? et donc je dois le modifier ? ou alors je dois créer un autre compte admin en suivant les conseils de Fenrir ? Ou alors synology a eu la bonne idée de créer un compte admin désactivé par défaut depuis la dernière version dsm (6.2.4 ?)

le tuto mériterait d'être mis à jour, car lors d'une MAJ de DSM 6 (je sais plus laquelle), la procédure d'installation du NAS a changé, et d'office tu dois créer un compte à toi qui sera administrateur, ce qui désactive d'office le compte admin.

Donc normalement le compte que tu as et utilise actuellement, (donc pas le "admin") est un compte administrateur.
Il doit apparaitre en tant que tel dans les paramètres d'utilisateurs...

Donc je pense que tu n'as pas forcément besoin d'en recréer un nouveau.
Après tout dépend de tes besoins 😉 

[TucBene]

il y a 1 minute, MilesTEG1 a dit :

le tuto mériterait d'être mis à jour, car lors d'une MAJ de DSM 6 (je sais plus laquelle), la procédure d'installation du NAS a changé, et d'office tu dois créer un compte à toi qui sera administrateur, ce qui désactive d'office le compte admin.

Donc normalement le compte que tu as et utilise actuellement, (donc pas le "admin") est un compte administrateur.
Il doit apparaitre en tant que tel dans les paramètres d'utilisateurs...

Donc je pense que tu n'as pas forcément besoin d'en recréer un nouveau.
Après tout dépend de tes besoins 😉 

Merci de tes réponses MilesTEG1

Je n'ai donc à priori pas besoin de faire cette démarche. En effet je serai le seul à gérer et utiliser le nas.

De plus mes besoins sont assez simples pour commencer : - utiliser, dans la version 6.2.4, Moments pour sauvegarder et gérer les photos et - sauvegarder mon pc sous linux.

[Jeff777]

Si je ne dis pas de bêtise (les autres membres me corrigeront si c'est le cas), le but c'est surtout d'avoir un administrateur qui ne s'appelle pas "admin" afin de brouiller les pistes.