Synology Débloquer le pare-feu pour le renouvellement du certificat SSL
- Auteur du sujet cricribibi
- Date de début
c'est ce que j'ai fait, j'ai ouvert que le 443 
merci en tous cas à tous les 2 !
(oui je sais que je suis en apprentissage et c'est pour ça que je demande conseil)
merci en tous cas à tous les 2 !
(oui je sais que je suis en apprentissage et c'est pour ça que je demande conseil
)
Dernière édition:
Bonjour,
Avant tout, je précise que je suis nouveau sur ce forum et néophyte en configuration de Nas le mien, un DS923+, a été mis en service depuis 2 semaines et donc, je n'ai pas encore pu tester le renouvellement des certificats Let's Encrypt, qui ont une durée de vie de 90 jours.
J'ai beau lire et relire tout ce qui s'est dit ici sur ce sujet, autant je comprend la nécessité d'ouvrir le port 80 pour permettre un renouvellement des certificats, autant j'avoue ne pas tout comprendre concernant la nécessité de "forcer" le renouvellement des certificats Let's Encrypt par une tâche planifiée :
D'après ce qui est dit sur le centre de connaissance Synology
Certificat | DSM - Synology Centre de connaissances
Le Centre de connaissances de Synology offre une assistance complète, fournit des réponses aux questions fréquemment posées, des étapes de dépannage, des tutoriels logiciels et toute la documentation technique dont vous avez besoin.
kb.synology.com
Quelqu'un pourrait-il éclairer ma lanterne ?
Idem je n’ai jamais forcé un renouvellement et dans mon parefeu je n’ai que le port 443 d’ouvert et restriction uniquement pour la france.Bonjour,
Avant tout, je précise que je suis nouveau sur ce forum et néophyte en configuration de Nas le mien, un DS923+, a été mis en service depuis 2 semaines et donc, je n'ai pas encore pu tester le renouvellement des certificats Let's Encrypt, qui ont une durée de vie de 90 jours.
J'ai beau lire et relire tout ce qui s'est dit ici sur ce sujet, autant je comprend la nécessité d'ouvrir le port 80 pour permettre un renouvellement des certificats, autant j'avoue ne pas tout comprendre concernant la nécessité de "forcer" le renouvellement des certificats Let's Encrypt par une tâche planifiée :
D'après ce qui est dit sur le centre de connaissance Synology
il semblerait que le DSM se charge du renouvellement automatique des certificats Let's Encrypt, pour peu que le port 80 soit ouvert...Certificat | DSM - Synology Centre de connaissances
Le Centre de connaissances de Synology offre une assistance complète, fournit des réponses aux questions fréquemment posées, des étapes de dépannage, des tutoriels logiciels et toute la documentation technique dont vous avez besoin.
Voir la pièce jointe 10860
Quelqu'un pourrait-il éclairer ma lanterne ?
Si tu fermes le port 80, ton renouvellement ne pourra pas se faire. Donc tu dois ouvrir le port 80 au moment où il se fait. Étant donné que tu ne sais pas quand et à quelle heure ton certificat va se renouveller, la seule méthode possible pour ouvrir le portail 80 au bon moment est de forcer le renouvellement en même temps où tu ouvres le port.
Soit tu maîtrises tout ouverture de port ET le renouvellement de ton certificat, soit tu laisses ton port 80 toujours ouvert open bar.
Simple à comprendre non? ^^
Soit tu maîtrises tout ouverture de port ET le renouvellement de ton certificat, soit tu laisses ton port 80 toujours ouvert open bar.
Simple à comprendre non? ^^
Pas forcément simple à comprendre de prime abord, compte tenu de la façon dont le sujet est traité :
Connaitre le code et entrer directement dedans, qui certes fonctionne selon toutes vraisemblances, c'est bien mais...
Fournir quelques explications "de base", tel que tu l'as fait ici, c'est beaucoup mieux, dans la mesure où cela permet à l'utilisateur novice de comprendre et surtout de s'approprier les différents processus possibles puis de faire ses choix en étant pleinement informé.
Bien souvent, l'utilisateur novice tâtonne et teste, du style "ça marche, oui/non" sans pour autant comprendre exactement ce qu'il fait ni connaitre les conséquences, bonnes, mauvaises ou risquées, de ses choix.
Se montrer "radin" en explications, est sans doute un signe des temps et/ou inhérent aux mondes Linux et Open Source, mais dis toi que c'est un "port ouvert" aux interprétations erronées, aux mauvaises compréhensions, aux erreurs, au temps perdu, etc.
Il y a pourtant beaucoup de fils de discussion concernant let's encrypt et son fonctionnement sur ce forum et sur d'autres où trouver réponse avec un peu de recherche.
LOL !
C'est bien ça le problème, il y a un peu de tout partout ! Mais rarement les sujets sont traités de façon claire, précise et concise, dit autrement, de sorte que lorsque tu as fini de lire les explications, le sujet est bien compris, c'est clair dans ta tête et tu peux faire tes propres choix en pleine conscience.
Entre les vidéos à rallonge, mal préparées, où un gars te montre ce qu'il a fait du style "c'est comme ça qu'il faut faire" ou tu te demandes si c'est vraiment "la bonne méthode" vu la qualité de ses explications, celles où un professionnel explique généralement plutôt très bien certains sujets, mais malheureusement pas toujours celui que tu recherches, celles des "influenceurs en herbe" à la recherche de notoriété, les forums où tu passes des heures à décrypter des tonnes de messages rédigés en langage sms avant de trouver une une simple bribe d'information, les blogs où les gars style "développeurs fous" commencent par te montrer des lignes de code qu'il suffit de copier/coller, il y a (un peu) de quoi s'agacer.
Que ce soit en vidéo ou sous forme écrite, il ne faut jamais perdre de de vue que les lecteurs n'ont pas forcément ton niveau d'expertise, que si "tu te comprends", d'autres lecteurs ne comprendront pas forcément la même chose...
2 exemples de "galères"...
- Concernant l'auto-hébergement, la seule explication correcte que j'ai trouvé était celle-ci : https://www.cachem.fr/auto-hebergement-heberger-nom-domaine-nas/
- Concernant l'installation de SearXNG sous Docker, comme pour la plupart des installations sous Docker, c'est la croix et la bannière pour trouver quelque chose de correct ! Après 3 ou 4 jours de tentatives infructueuses d'installations diverses et de plantages, des heures et des heures de recherches, j'ai fini par trouver : https://mariushosting.com/how-to-install-searxng-on-your-synology-nas/
Que dois-je conclure ? A ce stade, je me pose les questions suivantes :
1°) Vu le manque de standardisation concernant les installations sous Docker et surtout le manque de tutos corrects sur ces installations, bien que Docker offre des perspectives incroyables, je préfère laisser tomber... Vu les galères pour installer la moindre application, ça ne laisse rien augurer de bon concernant le suivi et la maintenance future de ces applications. Dommage, ça limite les possibilités, mais je me contenterai des paquets que propose Synology.
2°) Si à chaque fois que je veux "ouvrir sur le monde" mon nas, je butte sur problèmes tels que l'auto-hebergement ou le renouvellement des certificats Let's Encrypt, autant fermer tous les ports sur la box sauf celui du VPN et se contenter d'une simple utilisation en réseau local tout en conservant un accès VPN (au cas où).
3°) Ce qui m'amène à une 3ième réflexion : vu le prix d'un nas et le temps perdu en pêche aux renseignements pour effectuer la moindre installation, réglage ou modification, pourquoi ne pas se contenter d'un simple cloud google ou microsoft qui sera sécurisé et accessible partout dans le monde, si ce n'est que mes fichiers n'ont rien à faire chez google ou microsoft ? C'est d'ailleurs la solution que m'avait préconisé un spécialiste réseau qui a plus de 40 ans de métier...
Vaste débat !
Hello @jcfiguet et bienvenu !
Utiliser un Nas requiert malheureusement son administration et donc tout un pan lié à l'infrastructure réseau, gestion des services, et sécurisation. Le conseil donné par le spécialiste réseau n'est pas aberrant si l'on ne veut pas "perdre son temps"
En ce qui concerne le renouvellement du ou des certificats Lets Encrypt, le standard ACME HTTP-01 requiert l'utilisation du port TCP/80. C'est ainsi.
Deux solutions :
Comme tu débutes, n'ouvre que le strict minimum en terme de services réseau pour l'instant et au fur et à mesure que tu apprends l'administration, tu évolues.
Tu soulignes la profusion et confusion qu'amène les pas-à-pas trouvés sur le net (blogs, vidéos, etc.) . Ils peuvent aiguiller que si l'on a déjà des bases selon moi, auquel cas ils frustrent plus qu'autre chose car l'on ne comprend pas ce que l'on fait et les incidences qui en découlent.
C'est à ce moment-là que les forums prennent le pas où tu peux poser des questions et trouver des réponses
Utiliser un Nas requiert malheureusement son administration et donc tout un pan lié à l'infrastructure réseau, gestion des services, et sécurisation. Le conseil donné par le spécialiste réseau n'est pas aberrant si l'on ne veut pas "perdre son temps"
En ce qui concerne le renouvellement du ou des certificats Lets Encrypt, le standard ACME HTTP-01 requiert l'utilisation du port TCP/80. C'est ainsi.
Deux solutions :
- Si on ne veut pas s'embêter, on ouvre et laisse ouvert le port TCP/80 (que soit depuis le routeur et/ou le pare-feu du Nas ou du LAN) pour permettre l'échange du jeton nécessaire au renouvellement (l'impact sur la sécurité est faible mais existe et peut être mitigé avec des connaissances);
- Si l'aspect sécuritaire prime, n'ouvrir le port TCP/80 que lorsque cela est nécessaire.
Comme tu débutes, n'ouvre que le strict minimum en terme de services réseau pour l'instant et au fur et à mesure que tu apprends l'administration, tu évolues.
Tu soulignes la profusion et confusion qu'amène les pas-à-pas trouvés sur le net (blogs, vidéos, etc.) . Ils peuvent aiguiller que si l'on a déjà des bases selon moi, auquel cas ils frustrent plus qu'autre chose car l'on ne comprend pas ce que l'on fait et les incidences qui en découlent.
C'est à ce moment-là que les forums prennent le pas où tu peux poser des questions et trouver des réponses
@jcfiguet
Je vais répondre à ta question sur docker, tu peux standardiser tes containers en procédant:
/docker/tonnomdeprogramme.
Tu te fais des sous dossiers l’un pour la data, config,…
Et tu modifies les volumes (dossier) de tes docker-compose.
Tu changes ton port par exemple 80:80 en 4000:80 et tu reverseproxy de http://localhost:4000 vers https://tonnomdeprogramme.synology.me (443)
Et tu testes en accédant avec ton navigateur.
Après si tu as des soucis c’est surement du à des problèmes de droit sur tes dossiers (data,config,…) et ne pas oublier d’aller checker les wiki de tes programmes que tu veux tester.
Tu as souvent les réponses là-bas.
J’ai fait quelques tutoriels sur forum-nas tu peux les tester si tu veux.
Avoir un nas c’est enrichissant tu contrôles tes données et je préfère de très loin être propriétaire de mes données et pas les entreposer chez les autres.
Je vais répondre à ta question sur docker, tu peux standardiser tes containers en procédant:
/docker/tonnomdeprogramme.
Tu te fais des sous dossiers l’un pour la data, config,…
Et tu modifies les volumes (dossier) de tes docker-compose.
Tu changes ton port par exemple 80:80 en 4000:80 et tu reverseproxy de http://localhost:4000 vers https://tonnomdeprogramme.synology.me (443)
Et tu testes en accédant avec ton navigateur.
Après si tu as des soucis c’est surement du à des problèmes de droit sur tes dossiers (data,config,…) et ne pas oublier d’aller checker les wiki de tes programmes que tu veux tester.
Tu as souvent les réponses là-bas.
J’ai fait quelques tutoriels sur forum-nas tu peux les tester si tu veux.
Avoir un nas c’est enrichissant tu contrôles tes données et je préfère de très loin être propriétaire de mes données et pas les entreposer chez les autres.
Merci !Hello @jcfiguet et bienvenu !
Utiliser un Nas requiert malheureusement son administration et donc tout un pan lié à l'infrastructure réseau, gestion des services, et sécurisation. Le conseil donné par le spécialiste réseau n'est pas aberrant si l'on ne veut pas "perdre son temps"
En ce qui concerne le renouvellement du ou des certificats Lets Encrypt, le standard ACME HTTP-01 requiert l'utilisation du port TCP/80. C'est ainsi.
Deux solutions :
- Si on ne veut pas s'embêter, on ouvre et laisse ouvert le port TCP/80 (que soit depuis le routeur et/ou le pare-feu du Nas ou du LAN) pour permettre l'échange du jeton nécessaire au renouvellement (l'impact sur la sécurité est faible mais existe et peut être mitigé avec des connaissances);
- Si l'aspect sécuritaire prime, n'ouvrir le port TCP/80 que lorsque cela est nécessaire.
Comme tu débutes, n'ouvre que le strict minimum en terme de services réseau pour l'instant et au fur et à mesure que tu apprends l'administration, tu évolues.
Tu soulignes la profusion et confusion qu'amène les pas-à-pas trouvés sur le net (blogs, vidéos, etc.) . Ils peuvent aiguiller que si l'on a déjà des bases selon moi, auquel cas ils frustrent plus qu'autre chose car l'on ne comprend pas ce que l'on fait et les incidences qui en découlent.
C'est à ce moment-là que les forums prennent le pas où tu peux poser des questions et trouver des réponses
Je râle un peu, désolé.
Ce que je reproche, c'est surtout le manque de documentation fiable, ça finit par devenir décourageant, d'où mon coup de gueule.
Un nas n'est pas une simple lampe de bureau que l'on se contente de brancher et d'allumer avec un interrupteur, c'est un peu plus compliqué que ça...
A titre de comparaison, par le passé et dans une vie antérieure, j'ai eu l'occasion de monter plusieurs réseaux Novell. A cette époque tu recevais 1 CD et 1 bouquin de 3000 pages écrit en 5 langues... De plus tu avais droit à une hot-line en cas de difficulté. C'était du robuste : tu ne n'éteignais la machine que lorsque tu la changeais (en moyenne tous les 5 ans en entreprise)... Force est de constater que les temps ont bien changé !
Dernière édition:
Concernant l'installation des applis Docker, c'est un peu ce que je pensais globalement, sauf que ça ce n'est pas toujours ainsi que l'installation se fait :
Si tu compares AdGuard et SearXNG, les 2 installations n'ont rien de commun :
Pour Adguard, il faut effectivement 2 dossiers \docker\adguard\config et \docker\adguard\data, puis tu complètes ces 2 dossiers dans l'applicatif d'installation ensuite tous les autres réglages se font dans l'applicatif une fois installé, pas besoin de reverse-proxi.
Pour SearXNG, 1 seul dossier \docker\searxng, puis passage d'un script où tu peux modifier les ports (l'interface d'installation de SearXNG étant buguée à ce niveau), ensuite tu crées une entrée reverse proxi.
Le problème, c'est la documentation : elle est quasi inexistante, ou mal ficelée...
L'idée de de distribuer des applis sous Docker est géniale, c'est léger, peu consommateur de ressources, etc. Mais quelle galère pour l'utilisateur final !
C'est typique des développements produits par les "développeurs fous" : l'idée est super, le produit (bien que souvent minimaliste) rend de réels services, mais bien peu l'utilisent faute de pouvoir l'installer.
Puis un jour, Microsoft, Google ou d'autres, volent l'idée et le code, l'améliorent, soignent l'esthétique, rendent le produit accessible et facile à installer "chez tout le monde" et s'arrangent à le vendre sous une forme ou une autre. Les "développeurs fous" sont souvent géniaux, mais n'ont que très peu d'avenir dans les entreprises bien structurées...
A défaut d'être très intuitif, tout développement informatique se doit d'être accompagné d'une documentation aussi complète que possible, faute de quoi, le produit, aussi génial soit-il, sera boudé par une majorité d'utilisateurs... Je n'invente rien, je ne fais qu'énoncer une règle de base en vigueur chez tout éditeur de produits informatiques.
A titre personnel, j'ai installé 2 applis Docker, étant séduit par les pubs que l'on trouve un peu partout sur le net, mais c'est fini il n'y en aura pas de 3ième.
J'abandonne donc Docker et désormais je considèrerai les applis Docker comme des miroirs aux alouettes vantées par des influenceurs sur Youtube, en oubliant au passage de préciser les galères d'installation, la non garantie de maintenance et d'évolution, etc. Ces applis sont donc de mon point de vue vouées à terme à l'échec, du moins sous leurs formes actuelles.
J'attendrai donc que des éditeurs lambda plus sérieux proposent les mêmes produits, certes payants, mais installables sans difficultés, maintenables et évoluables dans le temps.
Le monde de l'Open Source n'est décidément pas fait pour moi, une fois de plus j'ai voulu tester (je teste en moyenne tous les 10 ans, histoire de voir l'évolution !), une fois de plus je suis déçu : l'Open Source reste fidèle à lui-même : toujours formidable, génial et gratuit pour quelques "initiés" mais malheureusement, toujours aussi difficile d'accès et opaque pour la majorité des particuliers et au final toujours fait de bric, de broc et de bidouilles.
Pas de soucis, ça se comprend
Opérateur système depuis pas mal d'années, j'ai également connu les documentations papiers qui étaient longues comme un jour sans pain mais où tout y était expliqué de façon claire. Malheureusement avec l'avènement du net, tout est maintenant éparse mais heureusement les bases restent les mêmes.
Même si les Nas et autres périphériques informatiques sont accessibles et configurables facilement, le modus operandi pour les sécuriser reste le même pour des périphériques réseau.
Prends ton temps pour assimiler son utilisation, une chose à la fois et ça ira tout seul
Un truc simple pour y voir plus clair et définir les priorités de configuration : une feuille de papier où un schéma de ton réseau est représenté, avec les étapes pour sécuriser toute la chaîne.
Je suis un ancien développeur sur ERP, mais en retraite depuis peu... Fort heureusement que les bases restent les mêmes, sinon ce serait la fin des haricots (ou des carottes, c'est selon)! Donc autant te dire que si je possède quelques notions réseau, ce n'était pas le cœur de mon métier, même si j'ai monté des réseaux Novell il y a très longtemps (fallait bien vivre en période de vaches maigres).Pas de soucis, ça se comprend
Opérateur système depuis pas mal d'années, j'ai également connu les documentations papiers qui étaient longues comme un jour sans pain mais où tout y était expliqué de façon claire. Malheureusement avec l'avènement du net, tout est maintenant éparse mais heureusement les bases restent les mêmes.
Même si les Nas et autres périphériques informatiques sont accessibles et configurables facilement, le modus operandi pour les sécuriser reste le même pour des périphériques réseau.
Prends ton temps pour assimiler son utilisation, une chose à la fois et ça ira tout seul
Un truc simple pour y voir plus clair et définir les priorités de configuration : une feuille de papier où un schéma de ton réseau est représenté, avec les étapes pour sécuriser toute la chaîne.
Pour la petite histoire et tu vas te marrer, lors de l'installation du nas, je l'avais mis en DMZ sur la box, histoire de me faciliter la vie, le temps de contrôler si ce que je faisait fonctionnait ou non en accès extérieur... Quelle ne fut pas ma surprise, si à peine 1 h plus tard, j'étais victime de 450 tentatives d'intrusions en moins de 10 minutes, provenant de Chine, Corée, Russie, Canada et USA ! Fort heureusement, il n'y avait aucune données perso de stockées et après 3 tentatives toutes les IP des pirates se sont faites éjectées. Mais ça donne à réfléchir !
Néanmoins, si les docs papier ont disparu au profit des docs en ligne, ces dernières sont tout de même moins détaillées et moins fouillées qu'autrefois... Je me souviens encore du temps pas très lointain (10 ans) où l'admin DB2 recevait une alerte (bénigne) sur son PC "Error 4586321", il se levait alors de sa chaise, ouvrait le placard et sortait le classeur "Erreur 4000000 à 4999999" (environ 5 kg), cherchait l'erreur 4586321, il avait immédiatement sous les yeux la gravité, la cause, les contrôles à effectuer et le remède à appliquer ! C'était "le bon temps" !!!
Coté Synology et ses paquets, généralement, je m'en sors assez bien, il y a une doc en ligne peu détaillée et juste suffisante pour d'en sortir, pour plus de détails, il y a la recherche sur le net. En revanche, coté Docker, il faut avouer que c'est un souk sans nom ! Si j'avais développé des programmes comme ceux proposés par Docker, c'est à dire sans fournir de doc claire et détaillée (dans le monde des ERP, par sécurité, ce ne sont jamais les développeurs qui procèdent aux installations ni aux configurations de leurs programmes en production, mais des admins que personne ne connait), je me serait "fait jeté" au bout de 2 jours !
Bref, pour être parfaitement clair, c'est après plusieurs jours de galères avec des installations Docker que je suis tombé par hasard sur ce post et que je me suis dit "j'ai du faire une connerie ou oublié quelque chose", après avoir consulté la doc Syno, je ne voyais pas vraiment l'intérêt d'ajouter ce bout de code en cron task, vue que mon port 80 était déjà ouvert... La fatigue aidant, je suis un peu monté dans les tours !
Encore désolé.
Concernant les ouvertures de ports et la sécurité, il n'y a que 3 solutions à ma connaissance :
1°) on ferme tous les port et on n'utilise le nas qu'en local, mais le pirate peut alors toujours passer par un PC (rarement bien sécurisé) pour atteindre le nas...
2°) on ouvre quelques ports pour un accès externe, mais même en les modifiant (ex de 5001 à 35001), le nas reste exposé...
3°) on ferme tous les port sauf un et on n'utilise un VPN sur le seul port ouvert pour atteindre le nas, dans ce cas le pirate peut encore s'attaquer au seul port ouvert par le VPN...
Dans tous les cas, le nas est exposé (plus ou moins) aux pirates... Je ne crois pas vraiment à l'efficacité de la mesure consistant à modifier le numéro de port par défaut, n'importe quelle "moulinette" est capable de balayer 65000 ports en un temps record, en trouver un d'ouvert puis lancer une 2ème "moulinette à login + mots de passe", si de plus le pirate peu lancer une "moulinette d'adresses IP d'attaque" en amont des 2 moulinettes précédentes, c'est "Byzance" ! Perso c'est ainsi que je procèderais si j'étais un pirate ! En revanche, je crois plus en l'efficacité d'un mot de passe long et complexe, à la double authentification (bien que contraignante) et au blocage de l'IP pirate après 2 ou 3 échecs d'authentification.
D'ici pas longtemps, le piratage risque de s'accentuer chez les particuliers avec la délinquance grandissante pour "se faire du fric facilement et sans risque", il faudra donc prévoir assez rapidement d'autres protections plus efficaces, peut être physique sous forme de dongle ou carte à puce, sous forme biométrique (reconnaissance faciale ou autre), pour autoriser l'accès à son nas...
Si tu as des idées, je suis preneur !
Bonjour,
Je lis vos échanges et ce que j'en retiens surtout c'est que si on ne s’intéresse pas à un sujet, il est inutile d'aller plus loin.
Docker n'est pas une niche réservé à certains utilisateurs, c'est comme tout, ça s'apprend mais ça ne s'apprend pas du jour au lendemain.
J'ai mon nas depuis presque 3 ans, je suis parti de rien niveau connaissance (pour moi, "python" c'était juste un serpent et "apache", un indien. Même ouvrir un port sur une box était complexe) puis j'ai regardé des tutos (comment sécurisé son nas en 1er lieu), je me suis familiarisé tout doucement avec les fonctions de base puis j'ai ratissé de plus en plus large. Je n'ai pas non plus hésité à demander de l'aide sur des problèmes spécifiques (merci encore au forum).
Aujourd'hui, même si c'est loin d'être parfait, voici comment j'ai sécurisé celui-ci ainsi que mes "conteneurs" :
-double authentification sur le nas.
-blocage permanent en cas de 3 échecs sous 15 mn
-faire du reverse proxy "443" sur toutes les apps.
-ouvrir uniquement les ports essentiels sur sa box et son nas. Pour ma part, le VPN (seulement pour le france), le 443 (seulement pour la france) et le 32400 pour plex.
-tous les conteneurs sur reverse proxy sont donc limités à la région "France" et, en plus, sous un profil limité à quelques IP (domicile, taff, etc...).
Pour les plus prudents, il existe aussi des surcouches de protection comme "Authelia" qui rajoute une double authentification.
Tout dépend également de son utilisation et des données qui s'y trouvent. Si c'est pour uniquement du stockage sans se prendre la tête, oui, l'option google ou microsoft n'est pas vide de sens.
Perso, j'ai commencé l'aventure pour remplacer une seedbox donc mes données, pour la plupart, ne sont pas très importantes. Seules mes photos le sont et elles sont également synchronisées sur un autre support mais il existe également, depuis DSM 7.2, les "snapshots immuables" qui te protège des ransomwares (en gros, ça protège tes données sensibles contre l'édition/effacement, même si la demande provient d'un profil admin. C'est basé sur une période de rétention que tu détermines à la création de celui-ci).
Bref, rien n'est parfait et tout peut arriver dès que c'est ouvert. C'est à nous d'être prudent pour limiter le risque mais les possibilités qu'offre un nas par rapport à d'autres services sont, pour moi, sans comparaison.
Grace au site de Marius, j'ai découvert beaucoup de conteneurs intéressant et facile à mettre en place grâce à ses tutos "étape par étape" très bien illustrés.
Il faut être intéressé par le sujet et avoir un peu de temps. Si c'est le cas, tu peux aussi commencer dans une machine virtuelle pour limiter les risques et te faire la main.
Sinon, jamais eu besoin d'ouvrir le port 80 pour que mon certificat se renouvelle de lui-même.
Bonne journée.
Cordialement.
Je lis vos échanges et ce que j'en retiens surtout c'est que si on ne s’intéresse pas à un sujet, il est inutile d'aller plus loin.
Docker n'est pas une niche réservé à certains utilisateurs, c'est comme tout, ça s'apprend mais ça ne s'apprend pas du jour au lendemain.
J'ai mon nas depuis presque 3 ans, je suis parti de rien niveau connaissance (pour moi, "python" c'était juste un serpent et "apache", un indien. Même ouvrir un port sur une box était complexe) puis j'ai regardé des tutos (comment sécurisé son nas en 1er lieu), je me suis familiarisé tout doucement avec les fonctions de base puis j'ai ratissé de plus en plus large. Je n'ai pas non plus hésité à demander de l'aide sur des problèmes spécifiques (merci encore au forum).
Aujourd'hui, même si c'est loin d'être parfait, voici comment j'ai sécurisé celui-ci ainsi que mes "conteneurs" :
-double authentification sur le nas.
-blocage permanent en cas de 3 échecs sous 15 mn
-faire du reverse proxy "443" sur toutes les apps.
-ouvrir uniquement les ports essentiels sur sa box et son nas. Pour ma part, le VPN (seulement pour le france), le 443 (seulement pour la france) et le 32400 pour plex.
-tous les conteneurs sur reverse proxy sont donc limités à la région "France" et, en plus, sous un profil limité à quelques IP (domicile, taff, etc...).
Pour les plus prudents, il existe aussi des surcouches de protection comme "Authelia" qui rajoute une double authentification.
Tout dépend également de son utilisation et des données qui s'y trouvent. Si c'est pour uniquement du stockage sans se prendre la tête, oui, l'option google ou microsoft n'est pas vide de sens.
Perso, j'ai commencé l'aventure pour remplacer une seedbox donc mes données, pour la plupart, ne sont pas très importantes. Seules mes photos le sont et elles sont également synchronisées sur un autre support mais il existe également, depuis DSM 7.2, les "snapshots immuables" qui te protège des ransomwares (en gros, ça protège tes données sensibles contre l'édition/effacement, même si la demande provient d'un profil admin. C'est basé sur une période de rétention que tu détermines à la création de celui-ci).
Bref, rien n'est parfait et tout peut arriver dès que c'est ouvert. C'est à nous d'être prudent pour limiter le risque mais les possibilités qu'offre un nas par rapport à d'autres services sont, pour moi, sans comparaison.
Grace au site de Marius, j'ai découvert beaucoup de conteneurs intéressant et facile à mettre en place grâce à ses tutos "étape par étape" très bien illustrés.
Il faut être intéressé par le sujet et avoir un peu de temps. Si c'est le cas, tu peux aussi commencer dans une machine virtuelle pour limiter les risques et te faire la main.
Sinon, jamais eu besoin d'ouvrir le port 80 pour que mon certificat se renouvelle de lui-même.
Bonne journée.
Cordialement.
Bonjour,
Je lis vos échanges et ce que j'en retiens surtout c'est que si on ne s’intéresse pas à un sujet, il est inutile d'aller plus loin.
Docker n'est pas une niche réservé à certains utilisateurs, c'est comme tout, ça s'apprend mais ça ne s'apprend pas du jour au lendemain.
J'ai mon nas depuis presque 3 ans, je suis parti de rien niveau connaissance (pour moi, "python" c'était juste un serpent et "apache", un indien. Même ouvrir un port sur une box était complexe) puis j'ai regardé des tutos (comment sécurisé son nas en 1er lieu), je me suis familiarisé tout doucement avec les fonctions de base puis j'ai ratissé de plus en plus large. Je n'ai pas non plus hésité à demander de l'aide sur des problèmes spécifiques (merci encore au forum).
Aujourd'hui, même si c'est loin d'être parfait, voici comment j'ai sécurisé celui-ci ainsi que mes "conteneurs" :
-double authentification sur le nas.
-blocage permanent en cas de 3 échecs sous 15 mn
-faire du reverse proxy "443" sur toutes les apps.
-ouvrir uniquement les ports essentiels sur sa box et son nas. Pour ma part, le VPN (seulement pour le france), le 443 (seulement pour la france) et le 32400 pour plex.
-tous les conteneurs sur reverse proxy sont donc limités à la région "France" et, en plus, sous un profil limité à quelques IP (domicile, taff, etc...).
Pour les plus prudents, il existe aussi des surcouches de protection comme "Authelia" qui rajoute une double authentification.
Tout dépend également de son utilisation et des données qui s'y trouvent. Si c'est pour uniquement du stockage sans se prendre la tête, oui, l'option google ou microsoft n'est pas vide de sens.
Perso, j'ai commencé l'aventure pour remplacer une seedbox donc mes données, pour la plupart, ne sont pas très importantes. Seules mes photos le sont et elles sont également synchronisées sur un autre support mais il existe également, depuis DSM 7.2, les "snapshots immuables" qui te protège des ransomwares (en gros, ça protège tes données sensibles contre l'édition/effacement, même si la demande provient d'un profil admin. C'est basé sur une période de rétention que tu détermines à la création de celui-ci).
Bref, rien n'est parfait et tout peut arriver dès que c'est ouvert. C'est à nous d'être prudent pour limiter le risque mais les possibilités qu'offre un nas par rapport à d'autres services sont, pour moi, sans comparaison.
Grace au site de Marius, j'ai découvert beaucoup de conteneurs intéressant et facile à mettre en place grâce à ses tutos "étape par étape" très bien illustrés.
Il faut être intéressé par le sujet et avoir un peu de temps. Si c'est le cas, tu peux aussi commencer dans une machine virtuelle pour limiter les risques et te faire la main.
Sinon, jamais eu besoin d'ouvrir le port 80 pour que mon certificat se renouvelle de lui-même.
Bonne journée.
Cordialement.
@Ochidoris
Je suis globalement d'accord avec ce que tu dis, il faut apprendre le Python pour espérer pouvoir programmer dans ce langage et à minima "apprivoiser" Apache pour pouvoir utiliser ce serveur HTTP. Fort heureusement, il existe des manuels et des tonnes de publications concernant ces 2 outils informatiques, de plus ils sont même enseignés dans les écoles professionnelles...
Concernant la sécurité et les ouvertures de ports sur l'extérieur, si l'on veut pouvoir accéder à son Nas de partout dans le monde avec un minimum de sécurité et, tant qu'à faire, le plus "confortablement" possible, dans l'état actuel des choses, ta configuration me semble bonne.
Je ne connais pas encore Authelia, mais d'après le peu de ce que j'ai lu sur le sujet, cette solution me semble plus sécuritaire, tout en étant plus contraignante.
A titre perso, je préfèrerai soit un système à reconnaissance faciale (du style de celle mise en place nativement sur windows 11), soit, à défaut, un système par clé physique (comme Yubikey), sachant que la reconnaissance faciale est certainement ce qui se fait de mieux actuellement en terme de sécurité.
Mes besoins sont les suivants : pouvoir accéder à tous mes fichiers depuis n'importe quel PC (en principe le mien perso) et pouvoir administrer mon Nas (au cas où) partout dans le monde. De plus, sans être "reporter de guerre", je veux pouvoir stocker mes photos dès la prise de vue, ainsi si on casse, si on me vole ou si je me fais confisquer mon appareil photo, la ou les photos sont sauvées. Ce type de situation peut arriver dans n'importe quel coin chaud ou plus ou moins dangereux, même en France. Bon, pour ça, j'ai trouvé les applications (propriétaires aux marques d'appareils photos, telles Sony, Nikon, Canon, etc) qui vont bien, il suffit d'avoir un smartphone à portée pour les transferts.
Pour ce qui est des applis Docker, j'avoue y être devenu allergique !
- Contrairement aux "paquets" proposés par Synology, le registre du Container te propose une foule d'applications dont tu n'as aucune idée par avance des fonctionnalités proposées sans faire de recherches souvent lourdes et fastidieuses.
- Aucune véritable documentation "officielle" : le développeur a créé une application et à toi de savoir :
- Ce que tu dois en attendre (quelles sont les principales fonctionnalités de l'application proposée)
- Comment ça s'installe
- Les "astuces" pour que ça fonctionne
- etc.
Tout ça, c'est typique du travail d'un "développeur fou et j'm'en foutiste" qui ne resterait pas plus de 2 jours chez Google, Microsoft, Oracle, Sage, SAP ou autres entreprise correctement structurée. Chez SAP ou Oracle, entreprises que je connais bien, je crois que ce développeur serait viré au bout de 10 mn !
Pour parvenir à installer et utiliser ce type d'application, il faut trouver des tutos "bien faits" comme ceux de Cachem ou Marius, ceux que tu sembles d'ailleurs toi-même utiliser... Malheureusement, sur des centaines d'applis proposées dans le registre du Container, seules quelques dizaines font l'objet d'un tuto réellement exploitable. Plutôt dommage, non ? Au final, des centaines d'applis accessibles, mais dont on ne sait ni ce qu'elles font et encore moins comment les installer et les paramétrer...
Bref, c'est le retour à l'état d'esprit du "monde Linux" des années 80 : il y a "ceux qui savent" et "les autres", ceux qui ont "les clés" et ceux qui ne les ont pas, c'est ce que j'appelle "des outils réservés à quelques utilisateurs initiés". Non seulement, c'est déplorable, c'est contre productif mais de plus ça finit par faire douter l'utilisateur potentiel quant au sérieux du suivi et la maintenance des applis proposées sous Docker.
Ma conclusion sur Docker : Autant je considère les paquets Synology comme des outils "de confiance", autant ma confiance demeure plus que limitée concernant les applications sous Docker.
Bonne soirée.
J'imagine oui
Cependant avoir le Nas dans la DMZ n'est pas inutile si sa vocation est d'être un serveur dit "bare metal" (serveur dédié destiné à ne servir que des données à des hôtes distants).
A partir de là, la sécurisation est plus drastique (pas de PAT/NAT pouvant quelque peu mitiger des attaques ciblées ou automatisées (les fameux botnets) et sa capacité à traiter les requêtes IP par son pare-feu directement inhérente à son CPU et la quantité de RAM nécessaire pour ne pas être saturé.
Je te rejoins et a aussi connu cette époque où tout était plus transparent dans la résolution de problèmes rencontrés.
Hélas elle est révolue quelque peu.
T'en fais pas, ça arrive
Tout à fait. Pour s'en prémunir, identifier les vecteurs d'attaques est primordial (courriels HTML qui peuvent contenir des pièces-jointes malicieuses, malwares installés à l'insu de l'utilisateur sur une machine du (W)LAN).
Il faut prendre du recul car lorsque l'on veut pouvoir accéder au Nas/LAN à distance il n'y a photo : on doit exposer les services requis.
Pour cela, veiller à utiliser un pare-feu (global au LAN ou à défaut celui d'une machine ou du Nas), et mettre en place un accès géographique ciblé réduisant la surface d'attaque d'attaques automatisées provenant d'ASN douteux.
Le changement des ports standards IANA par d'autres est une des mesure de mitigation même si ce n'est pas la panacée; elle reste de mise et permet d'éluder les petits "script kiddies".
Les attaques automatisées contre un VPN sont heureusement rares car demande une intervention humaine pour passer les couches successives de sécurisation utilisées par les protocoles VPN (outre PPTP et dans une moindre mesure L2TP sans IPSec).
Des attaques ciblées restent en revanche possibles si le ou les crackers (et oui j'utilise encore ce terme né à l'époque des cypherpunks qui distingue spécifiquement un hacker (celui qui bidouille sans mauvaise intention, pour la beauté du geste dirons-nous , de celui faisant cela à dessein malveillant)) pense(nt) que le jeu en vaut la chandelle.
Alors oui des scanners de port peuvent largement déterminer quel(s) port(s) est/sont ouvert(s) (notamment
nmap en faisant du "host sweep" intelligemment) mais un pare-feu performant bloquant les paquets fragmentés et/ou avec un délai entre chaque envoi et étant dit "stateful" contrecarre facilement tout ça.Malheureusement DSM qui repose sur le pare-feu "stateless"
iptables n'inclut pas de mode dit "stateful" (ce type de pare-feu permet de créer des règles d'autorisations de façon dynamique en inspectant chaque en-tête des paquets IP) et réserve ce type de pare-feu à son système SRM de ses routeurs.Donc si l'on veut vraiment se protéger de ces scans de ports évolués, on inclut un pare-feu "stateful".
Selon moi :
- l'authentification 2FA (doubles facteurs) est déjà une bonne chose et doit être utilisée;
- l'adjonction d'un pare-feu "stateful" global au LAN pour se protéger efficacement contre les différentes attaques automatisées ou non;
- établir un blocage géographique avec le pare-feu global ou celui du Nas pour envoyer balader les ASN douteux et utilisés par les botnets;
- utiliser le "Conseiller en sécurité" de DSM pour obtenir des rapports détaillés sur l'activité du Nas;
- avoir des règles du pare-feu (global ou Nas) pour les machines du LAN qui peuvent être sujettes à une infection virale/malwares;
- séquestrer les terminaux IoT dans un VLAN.
@cooper
Merci pour toutes ces explications très détaillées !
Bon, pour l'instant, je ne vois pas encore comment ajouter un pare-feu "stateful" à mon Synology, ni comment séquestrer mes terminaux loT dans un VLAN, d'ailleurs est-ce vraiment faisable ?
Nos Nas sont déjà bien évolutifs et déjà pourvus de beaucoup de possibilités, compte tenu de leurs prix d'achat, mais ils restent avant-tout des Nas "grand-public" ou "semi-pro" (selon le cas), rien à voir avec la sécurité des serveurs tels que ceux utilisés par Google ou IBM, sans parler de la redondance de leurs serveurs en cas de panne... Dit autrement, comparativement nous leur arrivons pas à la cheville !
D'où mon idée, peut être saugrenue, de l'utilisation d'une clé physique du style Yubikey, d'une carte à puce + code (comme pour certaines banques) ou d'un outil logiciel à reconnaissance faciale.
Je crois savoir que l'implémentation de la clé Yubikey est assez simple à mettre en œuvre, pour les autres systèmes, je n'ai pas encore trouvé d'infos...
Si ça marche vraiment comme je l'imagine (et là rien n'est moins sûr), seul celui qui possède la clé, ou la puce + le code ou dont le visage correspond peut "entrer", les autres "restent à la porte".
Malheureusement, mes connaissances en réseaux et en sécurité réseaux ne sont pas assez pointues pour être certain du niveau d'efficacité de ce type de dispositifs.
Merci pour toutes ces explications très détaillées !
Bon, pour l'instant, je ne vois pas encore comment ajouter un pare-feu "stateful" à mon Synology, ni comment séquestrer mes terminaux loT dans un VLAN, d'ailleurs est-ce vraiment faisable ?
Nos Nas sont déjà bien évolutifs et déjà pourvus de beaucoup de possibilités, compte tenu de leurs prix d'achat, mais ils restent avant-tout des Nas "grand-public" ou "semi-pro" (selon le cas), rien à voir avec la sécurité des serveurs tels que ceux utilisés par Google ou IBM, sans parler de la redondance de leurs serveurs en cas de panne... Dit autrement, comparativement nous leur arrivons pas à la cheville !
D'où mon idée, peut être saugrenue, de l'utilisation d'une clé physique du style Yubikey, d'une carte à puce + code (comme pour certaines banques) ou d'un outil logiciel à reconnaissance faciale.
Je crois savoir que l'implémentation de la clé Yubikey est assez simple à mettre en œuvre, pour les autres systèmes, je n'ai pas encore trouvé d'infos...
Si ça marche vraiment comme je l'imagine (et là rien n'est moins sûr), seul celui qui possède la clé, ou la puce + le code ou dont le visage correspond peut "entrer", les autres "restent à la porte".
Malheureusement, mes connaissances en réseaux et en sécurité réseaux ne sont pas assez pointues pour être certain du niveau d'efficacité de ce type de dispositifs.
Je t'en prie.
Faisable ? Bien sûr mais pas avec DSM.
C'est clair. Raison pour laquelle tout mon réseau est géré par une autre machine.
Cependant ces petites machines sont parfaites pour servir des données avec un contrôle suffisant.
Le cas du 2FA est vraiment inhérent aux connexions aux services.
Une "cold key" est bien sûr idéale mais la 2FA proposée par DSM est bien fichue et légèrement suffisante
cooper dit : Faisable ? Bien sûr mais pas avec DSM.
LOL ! Ca, j'avais cru comprendre... Peux-tu nous en dire un peu plus sur le sujet ?
Ou du moins (car je me doute qu'un tuto complet serait sans doute énorme et chronophage), nous fournir les grandes ligne du sujet et/ou les liens "qui vont bien" ? Au mieux, je me lancerai, au pire je serai moins idiot demain !
cooper dit : Le cas du 2FA est vraiment inhérent aux connexions aux services.
Une "cold key" est bien sûr idéale mais la 2FA proposée par DSM est bien fichue et légèrement suffisante
Oui, la 2FA proposée par DSM est plutôt bien fichue et suffisante, c'est d'ailleurs la méthode que des sites tels que Google, Ebay, ou d'autres nous incitent à utiliser... Mais je trouve cette méthode plutôt contraignante et pas très confortable.
Je préfèrerai utiliser un système de reconnaissance faciale, comme le fait Windows actuellement, mais je n'ai rien encore trouvé sur le sujet.
A défaut, je m'orienterai certainement vers la clé type Yubikey...