Votre avis sur la probabilité d'occurence d'une faille de sécurité

[declencher]

Salut la communauté !

Depuis mes débuts sur les NAS (presque 10 ans), je n'ai jamais exposé mon NAS sur internet, me contentant d'un usage local classique pour du stockage de fichiers et un peu de domotique perso (pas de docker, pas de virtualisation sur mon ancien NAS).

Pour le plaisir de découvrir des technos, parce que j'étais à cours d'espace disque (et les HDD étaient vieux dont 1 qui a laché), et parce que mon vieux NAS n'allait pas supporter DSM 7, j'ai investi dans un DS920+.

Ma première envie a été de tester Bitwarden : je découvre alors que ce coquin ne fonctionne qu'en HTTPS, et en cas d'utilisation de l'app mobile en mode déconnecté, le trousseau de mots de passe ne sera accessible qu'en lecture seul sur mon mobile (merci @.Shad.). Je réouvre donc le vieux sujet qui est pour moi une arlésienne : ouvrir certains service du NAS sur internet avec un maximum de sécurité.

Avec l'excellent tuto de @Fenrir, toutes les bases sont posées pour bien faire. Mais je m'interroge encore.

Je ne veux pas ouvrir DSM sur internet, mais peut être installer un CRM ou un CMS pour le travail (éventuellement), ou encore Matomo pour le perso. Quelle est la probabilité qu'une de ces applications puissent provoquer un accès à l'ensemble de mes données privées (photos et vidéos de famille) : si ces app sont dans un conteneur (comme Bitwarden), si elles sont dans une machine virtuelle (domotique), ou si elles sont installées via DSM (Moment, Video Station...), ou Webstation (CMS, CRM...) ?

Une fois rassuré, je serai plus à l'aise à l'idée de partager un accès à Moment ou DS Video avec les grands parents (distance géographique, confinement, petits enfants... la recette explosive pour le moral des anciens 😉 ) Sauf si vous me déconseillez totalement certaines pratiques ! J'en profiterai aussi pour ouvrir ma box domotique sur internet...

Ce que j'ai retenu de toutes mes lectures, c'est tuto de Fenrir + reverse proxy avec TLS + DSM non exposé sur internet + 2FA partout où c'est possible.

Qu'en pensez vous ? On ne mettra jamais totalement de côté les risques de failles applicatives, mais la question est de réduire la surface d'attaque et de réduire le risque de contagion...

 

[.Shad.]

A partir du moment où les règles de pare-feu sont réduites à ton besoin uniquement, que les données sont chiffrées (ce qui est le cas avec ton proxy inversé et un certificat valide), que les droits des utilisateurs se cantonnent aux applications et dossiers auxquels ils doivent avoir accès, et surtout que les mots de passe sont suffisamment forts, je considère qu'exposer les services non critiques sur Internet ne représente pas un danger disproportionné.

Pour tout ce qui concerne la sécurité, donc DSM ou Bitwarden, il faut au choix des couches de sécurité supplémentaires ou un VPN.
Pour DSM par exemple, à moins de devoir administrer ton NAS à distance, je ne vois pas l'intérêt de l'exposer, un accès par VPN me semble plus adapté.
Pour Bitwarden, pour les raisons qu'on a évoquées l'autre jour, il faut idéalement ajouter fail2ban, mais ça demande un peu de chipotage, voir la remarque de @MilesTEG1 dans ce sujet. Et mettre en place la 2FA, qui est elle directement intégrée à Bitwarden.

La réduction de surface d'attaque est grandement impactée par le géoblocage dans le pare-feu de DSM.

Selon moi il faut être beaucoup plus attentif aux montages SMB, AFP, etc... qu'on fait depuis nos machines vers le NAS. D'où l'importance de définir étroitement les droits des utilisateurs et groupes, quitte à créer des utilisateurs spécifiques pour l'accès aux données du NAS via la réseau local. Eviter à tout prix de monter des dossiers distants avec un utilisateur admin par exemple.

PS : Mon avis concernant le VPN est assez minoritaire sur ce forum, beaucoup ne jurent que par ça. 😛 Je suis beaucoup plus nuancé au vu de la dépréciation de l'implémentation d'OpenVPN présente sur nos NAS. Et dans certains endroits il n'est pas possible de recourir à un VPN (à mon boulot par exemple).

[MilesTEG1]

Salut @.Shad. @declencher,
Il me faut encore vérifier que les applis mobiles puissent bien écrire les données dans bitwarden, mais je vois pas pourquoi ça ne passerait pas ^^

il y a 40 minutes, declencher a dit :

Quelle est la probabilité qu'une de ces applications puissent provoquer un accès à l'ensemble de mes données privées (photos et vidéos de famille) : si ces app sont dans un conteneur (comme Bitwarden), si elles sont dans une machine virtuelle (domotique), ou si elles sont installées via DSM (Moment, Video Station...), ou Webstation (CMS, CRM...) ?

Pour ta question citée là, je ne saurais te dire... Tout dépendra de(s) faille(s) de sécurité qui sont/seront trouvées...
J'ai quelques services ouverts sur internet, et je n'ai jamais eu de soucis.
J'ai bien eu quelques tentatives à une époque où j'avais ouvert le port 22 dans la box, mais depuis que j'ai changé le port, et que je ne l'ai plus ouvert ce port, et surtout que j'ai mis en place le parefeu correctement, plus aucune tentatives...

En parlant de ça, je viens d'aller vérifier sur le NAS distant (chez mes parents), et je vois que le port 22 est toujours ouvert 😮  mais ne sert à rien vu que le port est quand même changé sur le NAS... Hop, c'est supprimé ^^
Cela dit, j'ai quand même ouvert le port de connexion à DSM (qui est un port personnalisé, ce n'est pas celui par défaut) afin d'accéder au NAS si jamais le reverseproxy déconne... (faudrait que je supprime ça, car si le reverse déconne, je doute que le NAS soit accessible 😮 ).

Je pense qu'une fois le parefeu paramétré, et en passant par le reverse-proxy, tu n'as pas vraiment de soucis à te faire.
Tu n'auras pas d'attaques random.
Si attaque, ce sera ciblée, donc quelqu'un qui connait ton installation et veut vraiment y accéder.

[declencher]

Bonjour messieurs,

Merci pour vos réponses rapides et détaillées !

Je vais distinguer 3 sujets :

- Les users et leurs droits : je partage vos points de vue,il faut être strict là dessus, notamment en évitant d'utiliser au quotidien un user ayant des droits démesurés.

- Les applications/services : suite logique du premier point, je partage la nécessité de désactiver ce qui n'est pas utiliser et de restreindre le reste à des users précis.

- Les serveurs applicatifs (app web) : Je comprends que vous considérez impossible ou peu probable le fait qu'un CMS piraté (par exemple) puisse servir de porte d'entrée vers les autres partages de données du NAS (ou autres serveur). C'est bien ça ?

Si DSM assure une l'étanchéité entre docker, machine virtuel, et les dossiers partagés, alors je partage votre avis sur ce dernier point.

2 autres points :
- Est il possible d'implémenter fail2ban 1 seule fois pour tous les services (par exemple en tête de réseau) pour éviter de le faire sur chaque app web/docker/virtualmachine ?
- Je partage ton avis @.Shad.sur le VPN Syno "exposé" et DSM. Je n'ai pas la nécessité d'ouvrir DSM sur le net. Et je n'ai pas l'utilité du VPN du Syno, car j'ai un routeur ASUS proposant lui aussi de faire serveur VPN avec des mises à jour plus fréquentes du service (j'espère...).

[.Shad.]

il y a 40 minutes, declencher a dit :

- Les serveurs applicatifs (app web) : Je comprends que vous considérez impossible ou peu probable le fait qu'un CMS piraté (par exemple) puisse servir de porte d'entrée vers les autres partages de données du NAS (ou autres serveur). C'est bien ça ?

Si DSM assure une l'étanchéité entre docker, machine virtuel, et les dossiers partagés, alors je partage votre avis sur ce dernier point.

Un CMS doit être protégé au mieux. Car il renferme un accès admin à d'autres serveurs. Prévoir le maximum de sécurité pour ça.

il y a 43 minutes, declencher a dit :

Si DSM assure une l'étanchéité entre docker, machine virtuel, et les dossiers partagés, alors je partage votre avis sur ce dernier point.

Qu'entends-tu par là ? les deux premiers sont exécutés par l'utilisateur root, si une personne malveillante a un accès root elle fait ce qu'elle veut.
Un conteneur est par défaut exécuté par root, sauf si on demande à un utilisateur spécifique.
Généralement, il faut prendre le temps de regarder le Dockerfile d'une application, voir les commandes utilisées lors du build, et utiliser autant que faire se peut les promoteurs d'image connues (développeur officiel, Linuxserver, etc...).

Pour une VM, je pense que c'est par défaut mieux isolé, tout dépend des applications en question et du niveau de sécurité qu'elles exigent.

il y a 48 minutes, declencher a dit :

2 autres points :
- Est il possible d'implémenter fail2ban 1 seule fois pour tous les services (par exemple en tête de réseau) pour éviter de le faire sur chaque app web/docker/virtualmachine ?

Moi j'utilise le fail2ban intégré à l'image linuxserver/swag pour les applications sensibles, qui me sert de proxy inversé.
J'utilise de surcroît Authelia, intégré à la même image, qui permet d'ajouter du 2FA à la demande sur n'importe quelle application.
Synology, pour ses applications, embarque par défaut la 2FA à la demande et le fail2ban.

[declencher]

Il y a 4 heures, .Shad. a dit :

Un CMS doit être protégé au mieux. Car il renferme un accès admin à d'autres serveurs. Prévoir le maximum de sécurité pour ça.

Je différencie 2 users dans ce cas : le user côté système qui lance l'application et exécute les commandes, et le user applicatif (la bdd par exemple). Si le CMS ne permet pas d'exécution de commande avec élévation de privilège sur le système hote, alors il n'y a pas de risque. Reste alors le risque de corruption/vol de la bdd ou de défaçage du site. Tu es e phase ?

Il y a 4 heures, .Shad. a dit :

Qu'entends-tu par là ?

Je suis d'accord avec le user root du NAS. Dans le cas de la virtualisation, un OS complet est émulé, et ses users n'ont pas accès à l'hote si aucun partage n'est déclaré. Ce serveur virtuel peut faire l'objet d'une attaque mais le risque de contagion est limité du fait de l'absence de partage (si j'ai bien compris).
Dans le cas de docker, je ne sais pas à quel fonctionnalité ou données de l’hôte le conteneur peut accéder ??
Dans le cas de DSM, ça me semble inévitable : un user avec des privilèges peut tout faire...

Il y a 4 heures, .Shad. a dit :

Moi j'utilise le fail2ban intégré à l'image linuxserver/swag pour les applications sensibles, qui me sert de proxy inversé.
J'utilise de surcroît Authelia, intégré à la même image, qui permet d'ajouter du 2FA à la demande sur n'importe quelle application.
Synology, pour ses applications, embarque par défaut la 2FA à la demande et le fail2ban.

J'avais compris que Synology permettait de générer un certificat LE, mais le renouvellement devait être géré à la main. En contrepartie l'interface est simple d'usage, tout comme celle du reverse proxy. En alternative, on a ta solution qui consiste à utiliser un reverse proxy plus évolué avec notamment une intégration de fail2ban directement en tête de réseau, et la possibilité d'ajouter le 2FA à toutes app web. Cette alternative me semble super intéressante même si moins user friendly. Je suppose que cette image est plus souvent mise à jour que le reverse proxy Syno... J'ai bien compris ?

Si oui, je vais me mettre à la recherche d'un tuto sur le sujet car c'est intéressant !

J'ignorais que Syno intégrait nativement fail2ban dans toutes ses app. Intéressant aussi comme sujet 🙂

[declencher]

Je me suis lancé dans le tuto "Sécurisation du NAS" avec succès. Je voulais me lancer dans le tuto "reverse proxy", et là je découvre que ma box SFR n'a plus une IPv4 full stack mais une IPv4 CGNAT. Et avec ça, plus aucune fonction d'ouverture de port sur la box.

J'ai ouvert un ticket chez SFR pour demander une IPv4 full stack (apparemment ils le feraient...).

Je pensais regarder le reverse proxy de Syno avant de migrer vers swag (autant y aller douvement, étape par étape 🙂 ), et je me suis interrogé sur le ndd à utiliser. Est il possible de générer un certificat LE avec Syno en ayant un NDD www actif sur un site hébergé chez OVH (donc https avec certificat LE), et un sous NDD qui pointerait sur le NAS. J'ai tenté, et Syno m'affiche pour l'instant une erreur : le port 443 étant fermé pour mon sous NDD (côté box), je me dis que c'est peut être à cause de ça ??

Message d'erreur : Echec de la connexion à LE. Assurez-vous que le NDD est valide.

[DaffY]

Bonjour,
Si le certificat n’est pas déjà créé chez ovh, oui
Pour la génération port 443 et 80 ouverts et routes vers NAS.
comme indiqué dans dans l’aide en ligne du NAS.

[PiwiLAbruti]

La base en sécurité est surtout de limiter la surface d'exposition sur internet au maximum. Il est inutile d'exposer une machine au monde entier si l'accès ne se fait que depuis des adresses IP connues (IP uniques, allocations opérateurs, pays, ...).

Si déjà le pare-feu limite les sources qui ont accès aux services exposés, les reste des dispositifs de sécurité sont beaucoup moins sollicités.

[declencher]

Salut !

il y a 59 minutes, DaffY a dit :

Si le certificat n’est pas déjà créé chez ovh, oui

Je pensais pouvoir m'appuyer sur le serveur web qui expose le port 80 chez OVH sachant que j'ai déjà un hébergement et un certificat LE chez OVH, et générer un certificat pour un sous domaine pour les domaines pointant vers l'IP de mon NAS.

Si je comprends, quand on a plusieurs sous domaines qui pointent vers plusieurs serveurs (un chez OVH, un autre chez AWS, etc), il faut obligatoirement générer les certificats à un seul endroit, puis déplacer les certificats ?

Si c'est ça, je vais me prendre un domaine dédié, ce sera pus simple (et pas le choix finalement)...

il y a 15 minutes, PiwiLAbruti a dit :

i déjà le pare-feu limite les sources qui ont accès aux services exposés, les reste des dispositifs de sécurité sont beaucoup moins sollicités.

C'est aussi ma conclusion, et après la sécurisation élémentaire du NAS, je vais me concentrer là dessus. Peut être un ajoutant un firewall type PFSENSE à terme...

[PiwiLAbruti]

il y a une heure, declencher a dit :

Peut être un ajoutant un firewall type PFSENSE à terme...

Le pare-feu du NAS suffit déjà à bien limiter la surface d'exposition. Un pfSense ne fera pas grand chose de mieux de ce côté là (à part la base geoip mieux maintenue).

[.Shad.]

Je confirme ce que dit @PiwiLAbruti, même pas sûr pour la base GeoIP que ce soit mieux maintenu. Plus de possibilités de configuration aussi par contre. Mais en effet en terme de gain de sécurité c'est marginal. C'est surtout dans la gestion interne de ton réseau local que pfSense (ou autre OPNSense, dd-wrt, Mikrotik, etc...) est intéressant.

[declencher]

Merci les gars !