[TUTO] Certificat SSL & reverse proxy via Docker

[.Shad.]

Pas de souci, voir ce post pour le lien avec ton erreur je pense : https://github.com/larsks/blog.oddbit.com/issues/3#issuecomment-612187561

[MilesTEG1]

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

Pas de souci, voir ce post pour le lien avec ton erreur je pense : https://github.com/larsks/blog.oddbit.com/issues/3#issuecomment-612187561

Oui ça ressemble à ce que j'avais.
J'essayais avec 192.168.2.210/28, je pense comme tu le dis qu'il fallait faire avec 192.168.2.208/28
Je prendrais le .209 pour swag et le .210 pour adguardhome.

Je vais essayer ça de ce pas.

[MilesTEG1]

@.Shad.  (après recréation du network macvlan)
Je pense que ça fonctionne 😄 

Bon avant j'ai fait les "anticommandes" pour supprimer le travail fait par le script au démarrage du NAS :

J'espère que c'était suffisant 😉

Je vais rebooter le NAS pour en être sur, et je pourrais relancer AdGuardHome. Et continuer SWAG 🙂 

Du coup, avec tes explications de la page 2, je me suis rendu compte que j'avais mal compris l'histoire d'IP virtuelle et d'interface virtuelle.
Maintenant, c'est bien plus clair ^^
J'ai modifié mes scripts en tenant compte de ça 😉

 

TIens, @.Shad., petite question : est-ce toujours utile de retarder l'exécution du script bridge-macvlan.sh au démarrage du NAS ?
Actuellement c'est 60s.

[.Shad.]

@MilesTEG1 Moi je l'ai laissé, mais tu peux sûrement réduire, c'est histoire d'être sûr que l'interface physique est opérationnelle. Tu n'as qu'à faire l'essai sans la temporisation voir si ça pose problème ou non.

[MilesTEG1]

@.Shad.
Hmm, je joue la carte de la précaution, je laisse la temporisation 😉 Je suis pas à une minute près, enfin le NAS ne l'est pas ^^ puisque ce script est pour lui 😄 

Sinon, peux-tu me confirmer que dès lors qu'une solution macvlan a déjà été mise en place, on peut passer les étapes n° (mince tu numérotes pas tes § 😅) :
Création du réseau macvlan
Création de l'interface virtuelle

Et que du coup, on n'a plus qu'à passer à l'étape : Création du conteneur

 

Et dernière question (pour le moment), un certificat wildcards permet de ne plus voir tous les domaines concernés par un certificat ?
Car actuellement, sur les domaines que je partage à des tiers, j'ai créé un certificat dédié.
Genre drive.mon-nas.mon-ndd.ovh.
Pour d'autres, c'est service1.mon-nas.mon-ndd.ovh , service2.mon-nas.mon-ndd.ovh etc... ils apparaissent tous dans le détail du certificat.
Avec un wildcards, on ne voit plus tout ça, et donc OSEF de faire des certifs sur un seul domaine ?

 

Et sinon par rapport à ce que tu as dit dans l'introduction du sujet :

Le 14/07/2020 à 10:23, .Shad. a dit :

Pour ma part je ne m'embête pas, j'utilise l'interface DSM pour obtenir un certificat wildcard avec le nom de domaine Synology qui se renouvelle tout seul tous les 2 mois.
Ainsi, j'utilise le nom de domaine Synology pour les services comme Hyper Backup, Drive, etc... tout ce qui est intrinsèquement lié à DSM et qui n'est pas gérable au travers d'un proxy inversé.
Tout le reste passe par le certificat OVH que ce conteneur va générer.

Quelles sont les raisons qui te font utiliser un nom de domaine synology ?
Y-a-t-il des avantages ? 
Faut-il que je change ma manière de faire pour utiliser un ndd synology ?

[MilesTEG1]

Bon ben décidément, il me faut sans cesse apprendre de nouvelles choses ^^ en posant des questions...
J'en ai une autre, qui vient au fil de ma lecture. @.Shad.

Citation

La validation par DNS-01 implique votre certificat sera validé via votre nom de domaine et non plus par votre NAS.
C'est la méthode obligatoire en cas d'utilisation d'un certificat wildcard.
Si vous souhaitez utiliser la méthode HTTP-01, il faudra prévoir une redirection (NAT) du port 80 de votre box vers l'IP du conteneur.

Vu que je ne connais pas grand chose à ce niveau-là, et que je te fais confiance quand à la mise en place de la validation DNS, j'aimerais toutefois savoir s'il y a un avantage autre que de ne pas rediriger le port 80 vers le conteneur à passer par la validation DNS-01 ?

Qu'apporterait celle HTTP-01 ? (est-ce celle utilisée par le NAS lorsqu'il fait les certificats LE ?)

 

Je viens de voir dans le fichier docker-compose l'option d'environement : 

Citation

- DHLEVEL=2048

En cherchant coté doc de swag, j'ai vu que c'était déprécié : linuxserver/letsencrypt - LinuxServer.io

Citation

Versions

• 28.07.20: - Start transition to new name, SWAG.

• 17.06.20: - Reformat ssl.conf. Pull in pre-generated dhparams.pem from DO Spaces. Deprecate DHLEVEL param.

Faut-il le laisser ? Y-a-t-il une alternative ?

Modifié le 25 mars 2021 par MilesTEG1

[MilesTEG1]

Citation

Notes :
 - Vous remarquerez que je ne translate aucun port entre le NAS et le conteneur, pourquoi ? N'oubliez pas que ce conteneur sera une machine à part entière sur le réseau physique, dès lors elle n'a pas "d'hôte" à proprement parler. J'aurai simplement mon routeur ou mon modem qui redirigera son port public 443 vers le port 443 de l'adresse IP physique du conteneur : 192.168.1.150 (Redirection du port 80 nécessaire également si on n'utilise pas un renouvellement DNS-01 mais HTTP-01 ou si on fait une redirection automatique HTTP -> HTTPS sur le proxy => remplace le fichier .htaccess dans Webstation).

@.Shad.Je compte bien utiliser swag en macvlan, pas de soucis.
Mais j'utilise la redirection HTTP -> HTTPS via le fichier .htaccess dans le dossier web du nas.
Faut que je fasse quelque chose en particulier ?
Les ports à rediriger vers le conteneurs sont bien : 443 & 80 ? (ce qui remplacera la redirection de ces mêmes ports sur le NAS, n'est-ce pas ?)

Modifié le 25 mars 2021 par MilesTEG1

[.Shad.]

Il y a 1 heure, MilesTEG1 a dit :

Sinon, peux-tu me confirmer que dès lors qu'une solution macvlan a déjà été mise en place, on peut passer les étapes n° [...]

Oui

Il y a 1 heure, MilesTEG1 a dit :

Et dernière question (pour le moment), un certificat wildcards permet de ne plus voir tous les domaines concernés par un certificat ?

Oui, après faut pas croire que ça apporte de la sécurité, personne ne t'attaquerait avec un nom de domaine. C'est l'IP qui intéresse les bots.

Il y a 1 heure, MilesTEG1 a dit :

Avec un wildcards, on ne voit plus tout ça, et donc OSEF de faire des certifs sur un seul domaine ?

Avec un certificat wildcard, tu valides ndd.tld et *.ndd.tld, donc si tu ajoutes un nouveau service pour lequel tu veux un accès par nom de domaine publique, tu n'as pas à recréer de certificats, il est déjà pris en charge par *.ndd.tld

Il y a 1 heure, MilesTEG1 a dit :

Quelles sont les raisons qui te font utiliser un nom de domaine synology ?
Y-a-t-il des avantages ? 
Faut-il que je change ma manière de faire pour utiliser un ndd synology ?

C'est un choix personnel, SWAG te permet d'obtenir un certificat que tu peux très bien exporter dans ton NAS et importer via l'interface DSM. Ce n'est pas comme acme.sh qui permet de faire le déploiement. Vu que certains services sont liés à DSM et ne peuvent pas passer par le proxy inversé (Synchro données port 6690 pour Drive, même chose pour Hyper Backup et Active Backup for Business), si je veux utiliser le même certificat que celui utilisé dans SWAG, je dois importer dans DSM ce certificat et configurer les services sus mentionnés pour qu'ils l'utilisent.

C'est fastidieux. Du coup, j'utilise l'interface DSM pour générer un certificat wildcard pour mon domaine gratuit Synology (DSM ne le permet que pour ses noms de domaine, d'où les tutos acme.sh pour les autres ndd), et je m'assure que les services Synology non déportables utilisent ce certificat :

Tu peux aussi utiliser acme.sh pour utiliser un certificat pour le même domaine et le déployer automatiquement dans DSM. C'est juste que ce seront deux certificats distincts, ça ne gêne en rien. 😉 

il y a une heure, MilesTEG1 a dit :

Vu que je ne connais pas grand chose à ce niveau-là, et que je te fais confiance quand à la mise en place de la validation DNS, j'aimerais toutefois savoir s'il y a un avantage autre que de ne pas rediriger le port 80 vers le conteneur à passer par la validation DNS-01 ?

Qu'apporterait celle HTTP-01 ? (est-ce celle utilisée par le NAS lorsqu'il fait les certificats LE ?)

Quand tu crées un certificat wildcard Synology, donc identifiant.synology.me et *.identifiant.synology.me, la validation passe par la zone DNS de ton domaine hébergée par Synology, tu n'as besoin d'ouvrir aucun port, tu es juste le demandeur, tu n'es pas dans la boucle de vérification. Quand tu valides les domaines manuellement (ta méthode actuellement), LE vient vérifier un fichier à la racine de ton serveur web pour vérifier l'authenticité de la demande, il le fait par le port 80.

Si par exemple tu as juste une adresse associée à un domaine, pour un site web par exemple (donc généralement ndd.tld et www.ndd.tld), je ne vois pas spécialement l'intérêt d'avoir une validation par DNS. Le wildcard est intéressant si tu as plusieurs sous-domaines.

Pour que la validation DNS soit possible, il faut que l'hébergeur de ta zone DNS mette une API à disposition d'acme.sh (ou certbot par exemple dans le cas de SWAG), tous les hébergeurs ne le font pas, dans ce cas-là il faut soit ajouter les enregistrements acme-challenge manuellement, soit passer par une validation HTTP.

il y a une heure, MilesTEG1 a dit :

Faut-il le laisser ? Y-a-t-il une alternative ?

Tu peux l'enlever, je mettrai à jour le tutoriel. Note que ça n'empêchera pas le bon fonctionnement, ce sera justement sûrement plus pris en compte lors de la création du conteneur.

il y a 45 minutes, MilesTEG1 a dit :

Mais j'utilise la redirection HTTP -> HTTPS via le fichier .htaccess dans le dossier web du nas.
Faut que je fasse quelque chose en particulier ?
Les ports à rediriger vers le conteneurs sont bien : 443 & 80 ? (ce qui remplacera la redirection de ces mêmes ports sur le NAS, n'est-ce pas ?)

Tu ne t'en serviras plus, c'est Nginx dans SWAG qui gèrera ça (par défaut c'est activé, il y a moyen de le désactiver, mais pas vraiment de bonne raison de le faire).

Merci de te lancer en tout cas, ça va permettre de voir où les explications sont insuffisantes (je note le manque de numérotation des paragraphes 😛).

Modifié le 25 mars 2021 par .Shad.

[MilesTEG1]

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

Oui, après faut pas croire que ça apporte de la sécurité, personne ne t'attaquerait avec un nom de domaine. C'est l'IP qui intéresse les bots.

L'idée était plus que ceux qui ont l'adresse d'un service ne puisse trouver facilement l'adresse d'un autre service 😉 

Ok pour le wildcards, ça va bien faire ce que je souhaite 🙂

 

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

Vu que certains services sont liés à DSM et ne peuvent pas passer par le proxy inversé (Synchro données port 6690 pour Drive, même chose pour Hyper Backup et Active Backup for Business), si je veux utiliser le même certificat que celui utilisé dans SWAG, je dois importer dans DSM ce certificat et configurer les services sus mentionnés pour qu'ils l'utilisent.

Hmmm, là ça commence à compromettre ce que je veux faire là !
Car j'ai le drive.mon-nas.ndd.ovh qui est partagé avec d'autres, tout comme mon serveur Plex (ils ont chacun leur certificat).
Parce que du coup, si je passe tout sur le certificat généré par swag, faut que je me tape à la main l'importation de ce certificat dans DSM pour les quelques services qui y sont... (surveillance station, Drive, DSM).
Et ça j'ai moyen envie de le faire...

Est-ce que si je garde les certificats actuels de DSM (service1.mon-nas.ndd.ovh etc...), et que je mets en place swag pour les conteneurs avec *.mon-nas.ndd.ovh, ça va pas poser de soucis pour ceux déclarés en service1.mon-nas.ndd.ovh dans DSM  ?

Il n'y aurait pas une solution avec SWAG qui fait en sorte que tout soit automatique ? Le script acme.sh dont tu parles peut-il être utilisé en même temps ?

 

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

Tu ne t'en serviras plus, c'est Nginx dans SWAG qui gèrera ça (par défaut c'est activé, il y a moyen de le désactiver, mais pas vraiment de bonne raison de le faire).

Faut donc supprimer le .htaccess ? Car ce dernier me sert aussi à rediriger https://photos.mon-nas.ndd.ovh/ vers https://photos.mon-nas.ndd.ovh/photos/
Ce qui n'est pas possible autrement...
Y a moyen de palier ceci avec Swag ?

Après, Swag n'est peut-être pas la meilleure solution pour mon besoin... Je suis preneur de tout conseil 😄 

 

En tout cas merci pour ces réponses, j'apprends encore des choses ^^ (Je n'ai pas cité et repris tout ce que tu m'as dit, car pour ceci j'ai rien à ajouter, tes explications sont claires 🙂  )

Bonne soirée 😉

 

[.Shad.]

il y a 20 minutes, MilesTEG1 a dit :

Hmmm, là ça commence à compromettre ce que je veux faire là !
Car j'ai le drive.mon-nas.ndd.ovh qui est partagé avec d'autres, tout comme mon serveur Plex (ils ont chacun leur certificat).
Parce que du coup, si je passe tout sur le certificat généré par swag, faut que je me tape à la main l'importation de ce certificat dans DSM pour les quelques services qui y sont... (surveillance station, Drive, DSM).
Et ça j'ai moyen envie de le faire...

Bah euhhh... d'où l'utilisation du ndd Synology pour être tranquille. Au passage tu confonds synchronisation des données de Drive et interface de Drive. C'est comme confondre le port par lequel Download Station ferait du partage BitTorrent et l'interface de Download Station.

Plex et DSM sont reverse proxiables donc pris en charge par SWAG. Voir l'impression d'écran de mon certificat Synology pour les services intrinsèques à DSM pour lequel il faut un certificat dans DSM directement.

il y a 20 minutes, MilesTEG1 a dit :

Y a moyen de palier ceci avec Swag ?

Sûrement, faudra que tu cherches un peu, je laisse le /photos derrière personnellement car je m'en sers dans Authelia pour différencier l'accès à phpMyAdmin et Photo Station, tous les deux sur les ports 80/443 du NAS.

Modifié le 25 mars 2021 par .Shad.

[MilesTEG1]

Salut @.Shad.

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

Bah euhhh... d'où l'utilisation du ndd Synology pour être tranquille. Au passage tu confonds synchronisation des données de Drive et interface de Drive. C'est comme confondre le port par lequel Download Station ferait du partage BitTorrent et l'interface de Download Station.

Non non je ne confond pas les deux ^^
Pour la synchronisation des données, il faut ouvrir un port, donc pas besoin d'un ndd dédié.
Pour l'interface web Drive, là par contre il y a besoin d'un ndd, et je parlais bien de cela 😉

Du coup, est-ce que si j'accède à Drive via le ndd dont le certificat est un wildcards fait par swag, ça fonctionnera sans erreur ou avertissement ?

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

Plex et DSM sont reverse proxiables donc pris en charge par SWAG. Voir l'impression d'écran de mon certificat Synology pour les services intrinsèques à DSM pour lequel il faut un certificat dans DSM directement.

Ok, pour le VPN (et l'accès au routeur directement) je passe par celui du routeur qui a son propre nom de domaine genre mon-routeur.ndd.ovh.
Donc avec ta capture, le Drive Server, je sens que la réponse à ma question précédente sera négative...

Qu'en est-il de Surveillance Station ? FileStation ? Moments ? et PhotoStation ?

Par contre, perdre l'utilisation du .htaccess qui me redirige l'accès à Photostation ça m'embête beaucoup...
 

Plus j'avance dans la compréhension de l'outils, et des diverses autres choses, et plus je me dis que ce n'est peut-être pas vraiment ce qu'il me faut...

En tout cas, merci beaucoup pour tes réponses 

[.Shad.]

il y a 28 minutes, MilesTEG1 a dit :

Du coup, est-ce que si j'accède à Drive via le ndd dont le certificat est un wildcards fait par swag, ça fonctionnera sans erreur ou avertissement ?

Si tu accèdes à l'interface Drive, pas de problème évidemment tu passes par le proxy inversé de SWAG.
Pour la synchronisation des données via le client PC par exemple, il faudra utiliser un nom de domaine dont le certificat est dans DSM.

Je vois pas comment être plus clair, je ne sais plus comment le tourner. 😛 

Le "Synology Drive Server" que tu vois dans mon impression d'écran correspond au service de synchronisation de données, pas l'interface de Drive.

il y a 32 minutes, MilesTEG1 a dit :

Qu'en est-il de Surveillance Station ? FileStation ? Moments ? et PhotoStation ?

Les quatres sont "reverse proxiables", donc ça ne pose aucun problème...

il y a 34 minutes, MilesTEG1 a dit :

Par contre, perdre l'utilisation du .htaccess qui me redirige l'accès à Photostation ça m'embête beaucoup...

J'ai cherché cinq minutes sur Google : https://www.digitalocean.com/community/questions/nginx-seamless-redirect-subdomain-subfolder
Après si tu comptes utiliser Authelia, ta redirection t'embêtera plus qu'autre chose, mais tu fais comme tu veux.

[MilesTEG1]

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

Si tu accèdes à l'interface Drive, pas de problème évidemment tu passes par le proxy inversé de SWAG.
Pour la synchronisation des données via le client PC par exemple, il faudra utiliser un nom de domaine dont le certificat est dans DSM.

Ok, donc ça fonctionnera pour accéder à l'interface web de Drive, donc avec par exemple drive.mon-nas.mon-ndd.ovh. Sachant que SWAG me génère un certificat pour *.mon-nas.mon-ndd.ovh. (jusque là, je ne me trompe pas n'est-ce pas ?)
Question : est-ce que si je génère un certificat pour drive.mon-nas.mon-ndd.ovh depuis le NAS (comme c'est le cas actuellement), est-ce que le service de synchronisation fonctionnera correctement ?

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

Je vois pas comment être plus clair, je ne sais plus comment le tourner. 😛 

Là j'ai compris ce que tu disais 😁 Je comprends vite, mais il faut m'expliquer à peine longuement 😅).

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

Les quatres sont "reverse proxiables", donc ça ne pose aucun problème...

Ok, donc nickel là dessus.

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

J'ai cherché cinq minutes sur Google : https://www.digitalocean.com/community/questions/nginx-seamless-redirect-subdomain-subfolder
Après si tu comptes utiliser Authelia, ta redirection t'embêtera plus qu'autre chose, mais tu fais comme tu veux.

Hmmm, j'ai pas encore cherché (je l'aurais fait hein, quand je me serais décider à continuer les procédures ^^).
Ce qui est expliqué dans le lien que tu as donné, c'est que tout ce qui serait en photos.mon-nas.mon-ndd.ovh aboutirait sur photos.mon-nas.mon-ndd.ovh/photo mais sans changer l'URL qui resterait photos.mon-nas.mon-ndd.ovh. Ce n'est peut-être pas ce que je voulais...
Mais bon, au pire, tant pis, peu de personne utilise PhotoStation, je peux filer le lien avec le /photo en fin.

Pour ma culture, ça gênerait en quoi pour Authelia ? (ce service m'intéresse pas mal, pour stocker chez moi les codes 2FA 😉 en plus de mon gestionnaire de mot de passe).

J'ai une autre question : j'ai quelques scripts php, ce n'est pas à proprement parler un site web, mais ils continueraient à fonctionner ? J'y accède uniquement en LAN mais sont accessible aussi depuis internet si on connait précisément l'adresse.

 

J'ai aussi actuellement fait un nom de domaine de type routeur.mon-nas.mon-ndd.ovh pour accéder à mon routeur en passant par le reverse proxy. Ça continuera bien de fonctionner ainsi ?

[Einsteinium]

Au passage il faut savoir que le reverse proxy avec dsm 7 est complet et totalement fonctionnel.

[MilesTEG1]

@Einsteinium C'est-à-dire ? Peux-tu développer ? Et mettre quelques captures ?
(pour voir si je patiente une sortie de DSM7 prochaine... lointaine peut-être 😅)

[Jeff777]

il y a une heure, Einsteinium a dit :

Au passage il faut savoir que le reverse proxy avec dsm 7 est complet et totalement fonctionnel.

Mis à part que l'on y accède de façon différente que dans DSM6 je n'ai pas vu de différence. Il y a des fonctionnalités supplémentaires ?

[.Shad.]

Il y a 3 heures, MilesTEG1 a dit :

Ok, donc ça fonctionnera pour accéder à l'interface web de Drive, donc avec par exemple drive.mon-nas.mon-ndd.ovh. Sachant que SWAG me génère un certificat pour *.mon-nas.mon-ndd.ovh. (jusque là, je ne me trompe pas n'est-ce pas ?)

Sans problème.

Il y a 3 heures, MilesTEG1 a dit :

Hmmm, j'ai pas encore cherché (je l'aurais fait hein, quand je me serais décider à continuer les procédures ^^).
Ce qui est expliqué dans le lien que tu as donné, c'est que tout ce qui serait en photos.mon-nas.mon-ndd.ovh aboutirait sur photos.mon-nas.mon-ndd.ovh/photo mais sans changer l'URL qui resterait photos.mon-nas.mon-ndd.ovh. Ce n'est peut-être pas ce que je voulais...

Ca fait l'inverse.

Il y a 3 heures, MilesTEG1 a dit :

Pour ma culture, ça gênerait en quoi pour Authelia ? (ce service m'intéresse pas mal, pour stocker chez moi les codes 2FA 😉 en plus de mon gestionnaire de mot de passe).

Authelia te permet de différencier l'accès à une ressource en fonction du chemin après le domaine.
Chez moi, j'accède à phpMyAdmin par ds918-services.ndd.ovh/phpMyAdmin, et Authelia sait qu'il doit me demander une authentification 2FA pour l'autoriser, même en local (parce que je l'ai configuré ainsi), tandis que ds918-services.ndd.ovh/photo est accessible depuis n'importe quelle source, locale ou distante.

Sans rentrer dans les détails, si je faisais un rewrite de l'URL il serait plus difficile de différencier le comportement d'un service par rapport à l'autre.

Il y a 3 heures, MilesTEG1 a dit :

J'ai une autre question : j'ai quelques scripts php, ce n'est pas à proprement parler un site web, mais ils continueraient à fonctionner ? J'y accède uniquement en LAN mais sont accessible aussi depuis internet si on connait précisément l'adresse.

Ca je crois que tu devras essayer, c'est trop vague.

Il y a 3 heures, MilesTEG1 a dit :

J'ai aussi actuellement fait un nom de domaine de type routeur.mon-nas.mon-ndd.ovh pour accéder à mon routeur en passant par le reverse proxy. Ça continuera bien de fonctionner ainsi ?

SWAG est un proxy inversé comme un autre, pourquoi ça ne marcherait pas ? 😉 

Il y a 2 heures, Einsteinium a dit :

Au passage il faut savoir que le reverse proxy avec dsm 7 est complet et totalement fonctionnel.

SWAG ne vient en rien corriger des problèmes avec le proxy inversé de DSM, qui est très bien comme ça et pour 99% des utilisateurs, mais limité si on veut pousser un peu plus loin. SWAG est une solution complète autonome qui intègre la prise en charge de la 2FA à la demande pour les applications qu'on héberge, le fail2ban, et le redirection HTTP -> HTTPS via Nginx au lieu d'Apache (mais ça tu le sais déjà).

[Einsteinium]

@Jeff777 @MilesTEG1  Et bien dans le temps il fallait le lier avec le paquet dns server pour faire la liaison avec son domaine (j’avais testé sous dsm 5 à l’époque), avec dsm 7 il ne suffit plus que d’ouvrir les ports web et te faire pointer le domaine/joker vers l’ip, maintenant si c’est aussi le cas avec dsm 6, je ne savais pas. @unPixel Tu n’as pas migré vers dsm 7 pour cela ?

@.Shad. Et bien je trouve cela très configurable sous dsm 7, profil d’accès, HSTS, en tête personnalisé, page d’erreur, oauth 2.0, ... Bref sous dsm 7 je ne vois pas d’utilité de swag.

[.Shad.]

@Einsteinium Tout ce que tu cites là est déjà intégré à DSM 6, rien de nouveau sous le soleil et de toute évidence il donne entière satisfaction pour l'ultra majorité des utilisations. Nulle part j'ai décrié son fonctionnement, il est relativement complet et très stable/fiable.

Le seul reproche que je fais au proxy inversé de DSM c'est la difficulté de modifier la configuration d'Nginx, par exemple pour y intégrer la redirection HTTP vers HTTPS. Devoir passer par un script via Apache pour le faire est vraiment dommage.

Tu évoques le paquet oauth 2.0, as-tu pris le temps de lire ce que ça permettait de faire ? Ça n'a strictement rien à voir avec ce que propose Authelia. Oauth sur DSM permet d'utiliser son compte Synology pour accéder à certaines ressources comme Amazon Echo. Authelia permet d'activer la 2FA ou des notifications push sur smartphone pour te connecter sur n'importe quelle application que tu hébergerais. Tu peux ajouter et ajuster les couches de sécurité pour ton homelab à l'envi.

Et tu ne parles pas du fail2ban, disponible sur DSM que pour les applications natives.

Il n'y a aucun souci à préférer une autre solution, j'en propose juste une qui, après en avoir testé plusieurs autres (Haproxy, DSM, Traefik), me semble de loin la plus efficace et facile de configuration. 

[.Shad.]

Et si vraiment on veut se servir de l'oauth de Synology, c'est ultra pas intuitif, voir ici :

https://medium.com/@4c.dmnk/take-control-over-synologys-oauth-service-f96114be3707

Tu oublies les notifications Push ou SMS, et personnellement utiliser mon compte Synology pour me log ailleurs, ça me ferait peur.

[Einsteinium]

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

Tout ce que tu cites là est déjà intégré à DSM 6

D'accord du coup j'ai du mal a comprendre l'usage dans le cas présent du coup (pour dsm 6)

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

Le seul reproche que je fais au proxy inversé de DSM c'est la difficulté de modifier la configuration d'Nginx, par exemple pour y intégrer la redirection HTTP vers HTTPS. Devoir passer par un script via Apache pour le faire est vraiment dommage.

HSTS dans le proxy inversé (sous dsm 7 du moins), pour ma part j'ai constaté au travers de mes vps, que 95% des attaques tombent sur le port http, je n'ouvre donc plus que le port https.

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

Authelia permet d'activer la 2FA ou des notifications push sur smartphone pour te connecter sur n'importe quelle application que tu hébergerais.

Non je n'ai pas regardé j'avoue, mais je sais que le oauth V2 prends en charge le 2fa, pour sa que je le cite, maintenant je n'ouvre sur le net que des applications qui tourne sous docker et qui ont une sécurité intégré (que sa soit 2fa, protection fail2ban...), s'il n'y en a pas, c'est à fuir comme la peste de mon point de vue, en 2021, devoir passé par d'autres applications pour rajouté une couche de sécurité à une application dépourvue, c'est un peu balo.

 

Après je dis pas, j'aurais été enthousiaste du temps de dsm 5 pour utilisé swag et comblé les lacunes du proxy inversé, mais à l'heure d'aujourd'hui, je n'en ai pas l'usage, n'y le besoin, j'ai même abandonné mon vps que j’utilisais du temps de la 4G suite au passage en fibre comme protection (type cloudflare), car devenu totalement inutile avec dsm 7, il ne manquerait plus que les wildcard lets encrypt en native pour que cela soit parfait dans dsm.

[.Shad.]

Perso si j'attendais qu'une application ait nativement f2b + 2fa avant de l'exposer, je ne pourrais pas me servir de grand chose hors de chez moi, et c'est surtout là que je trouve un intérêt à avoir un serveur à la maison.

Ou alors je devrais demander à toute ma famille d'avoir un VPN 😄 Difficile d'expliquer ça à mes parents. 🤔

Quoiqu'il en soit je t'ai dit je pense que DSM intègre un proxy inversé très satisfaisant out-of-the-box, si tu souhaites étendre les fonctionnalités disponibles pour les applications natives de DSM à d'autres applications via Docker ou VMM, tu es vite limité, d'où l'intérêt de SWAG.

Le tutoriel est là, les gens l'appliquent ou pas peu me chaut, je sais très bien qu'il répond à un besoin très spécifique (que DSM ne permet pas) et en conséquence j'aide @MilesTEG1

[April]

Merci beaucoup .Shad. pour cet excellent tuto très détaillé qui m'a permis d'installer Swag.
Le reverse proxy fonctionne très bien avec macvlan et transmet les IP externe ce que je n'arrivais pas à faire avec le bridge.
Par contre si vous pouvez vérifier vos logs fail2ban et voir s'il fonctionne correctement.

J’ai mis fail2ban sur 3 tentatives, il détecte bien les 3, il tente d'exécuter le ban mais il y a une erreur.
Le problème est aussi présent sur d'autres filtres que "nginx-botsearch"

fail2ban.filter         [470]: INFO    [nginx-botsearch] Found 164.132.48.179
fail2ban.filter         [470]: INFO    [nginx-botsearch] Found 164.132.48.179
fail2ban.filter         [470]: INFO    [nginx-botsearch] Found 164.132.48.179
fail2ban.actions        [470]: NOTICE  [nginx-botsearch] Ban 164.132.48.179
fail2ban.utils          [470]: ERROR   7f36e8eebdf0 -- exec: iptables -w -I f2b-nginx-botsearch 1 -s 164.132.48.179 -j REJECT --reject-with icmp-port-unreachable
fail2ban.utils          [470]: ERROR   7f36e8eebdf0 -- stderr: 'iptables v1.8.7 (legacy): unknown option "--reject-with"'
fail2ban.utils          [470]: ERROR   7f36e8eebdf0 -- stderr: "Try `iptables -h' or 'iptables --help' for more information."
fail2ban.utils          [470]: ERROR   7f36e8eebdf0 -- returned 2
fail2ban.actions        [470]: ERROR   Failed to execute ban jail 'nginx-botsearch' action 'iptables-allports' info 'ActionInfo({'ip': '164.132.48.179', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f36e8f31940>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f36e8f32040>})': Error banning 164.132.48.179

après des recherches il semble que la commande REJECT ne soit pas implantée sur Synology ?

Modifié le 21 juillet 2021 par April

[.Shad.]

Salut, cool si ça a pu t'aider !

Pour ton problème, chez moi SWAG tourne en bridge mais sur une autre machine que le NAS.
Au niveau des logs, rien de semblable :

2021-07-19 02:00:22,456 fail2ban.filter         [523]: INFO    [bitwarden] Found 91.121.223.219 - 2021-07-19 02:00:22
2021-07-19 19:01:24,749 fail2ban.filter         [523]: INFO    [nginx-botsearch] Found 34.78.185.17 - 2021-07-19 19:01:24
2021-07-20 00:20:21,349 fail2ban.filter         [523]: INFO    [ssh] Found 82.64.46.144 - 2021-07-20 00:20:21
2021-07-20 00:20:21,954 fail2ban.filter         [523]: INFO    [ssh] Found 82.64.46.144 - 2021-07-20 00:20:21
2021-07-20 00:20:22,360 fail2ban.filter         [523]: INFO    [ssh] Found 82.64.46.144 - 2021-07-20 00:20:22
2021-07-20 02:00:42,855 fail2ban.filter         [523]: INFO    [bitwarden] Found 91.121.223.219 - 2021-07-20 02:00:42
2021-07-20 08:51:14,910 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 08:51:14
2021-07-20 08:52:13,586 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 08:52:13
2021-07-20 08:56:53,939 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 08:56:53
2021-07-20 08:56:54,140 fail2ban.actions        [523]: NOTICE  [bitwarden] Ban 172.23.0.12
2021-07-20 09:05:40,613 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 09:05:39
2021-07-20 09:06:53,098 fail2ban.actions        [523]: NOTICE  [bitwarden] Unban 172.23.0.12
2021-07-20 11:49:35,705 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 11:49:35
2021-07-20 12:58:47,180 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 12:58:47
2021-07-20 17:29:33,039 fail2ban.filter         [523]: INFO    [nginx-botsearch] Found 128.199.220.215 - 2021-07-20 17:29:32
2021-07-20 17:43:12,494 fail2ban.filter         [523]: INFO    [nginx-botsearch] Found 207.136.12.46 - 2021-07-20 17:43:12
2021-07-20 18:03:27,500 fail2ban.filter         [523]: INFO    [nginx-botsearch] Found 142.93.99.56 - 2021-07-20 18:03:27
2021-07-20 19:56:11,277 fail2ban.filter         [523]: INFO    [bitwarden] Found 172.23.0.12 - 2021-07-20 19:56:10
2021-07-21 02:00:32,371 fail2ban.filter         [523]: INFO    [bitwarden] Found 91.121.223.219 - 2021-07-21 02:00:32
2021-07-21 17:15:11,336 fail2ban.filter         [523]: INFO    [nginx-botsearch] Found 51.89.233.135 - 2021-07-21 17:15:11

En revanche ça me permet de voir qu'il a ban une IP privée 😄 Va falloir que j'investigue un peu.

La ligne qui m'interpelle dans tes logs c'est :

Il y a 7 heures, April a dit :

fail2ban.utils          [470]: ERROR   7f36e8eebdf0 -- stderr: 'iptables v1.8.7 (legacy): unknown option "--reject-with"'

Est-ce que tu as personnalisé ton fichier nginx-botsearch.conf dans SWAG ?
Ca pourrait valoir le coup de supprimer le fichier, et de relancer le conteneur, ça le recréera automatiquement.

[April]

Merci de répondre

je n'ai pas touché aucun .conf

j'ai aussi essayé avec Calibre-web, même erreur.

[calibre]

enabled  = true
filter   = calibre
port     = http,https
logpath  = /logcalibre/calibre-web.log

-----

fail2ban.utils          [475]: ERROR   7f304ba2a030 -- exec: iptables -w -I f2b-calibre 1 -s 54.37.73.135 -j REJECT --reject-with icmp-port-unreachable
fail2ban.utils          [475]: ERROR   7f304ba2a030 -- stderr: 'iptables v1.8.7 (legacy): unknown option "--reject-with"'
fail2ban.utils          [475]: ERROR   7f304ba2a030 -- stderr: "Try `iptables -h' or 'iptables --help' for more information."
fail2ban.utils          [475]: ERROR   7f304ba2a030 -- returned 2
fail2ban.actions        [475]: ERROR   Failed to execute ban jail 'calibre' action 'iptables-allports' info 'ActionInfo({'ip': '54.37.73.135', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f304bb718b0>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f304bb71f70>})': Error banning 54.37.73.135

la seule différence avec le tuto, j'ai laissé dans jail.local SSH=false. mais du ban sur SSH ne doit pas changer les choses

 

Modifié le 21 juillet 2021 par April