[TUTO] Certificat SSL & reverse proxy via Docker

[.Shad.]

Le 30/10/2023 à 3:44 PM, Dino Rayn a dit :

En faisant pointer 80/443 directement sur l'ip de swag, tous mes anciens services ne sont plus accessibles.

Généralement on n'utilise qu'un seul proxy inversé à la fois. Ce que DSM fait, SWAG peut le faire. Acme gère ton domaine principal c'est ça ? Qu'est-ce qui t'empêche de le basculer sur SWAG ? Si tu as un cas concret à présenter pour voir ce qui pose problème.

Si le but est de laisser le proxy inversé sur le NAS, SWAG n'a aucun intérêt. Acme est plus indiqué.

Concernant l'erreur du script, après plusieurs essais on avait remarqué que si tu écris .210/29 tu tronques certaines IP. Si tu vas sur le calculateur de jodies, tu dois indiquer ce qui est noté dans "network" : https://jodies.de/ipcalc?host=192.168.0.210&mask1=29&mask2=

Modifié le 5 novembre 2023 par .Shad.

[Dino Rayn]

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

Généralement on n'utilise qu'un seul proxy inversé à la fois. Ce que DSM fait, SWAG peut le faire. Acme gère ton domaine principal c'est ça ? Qu'est-ce qui t'empêche de le basculer sur SWAG ? Si tu as un cas concret à présenter pour voir ce qui pose problème.

Si le but est de laisser le proxy inversé sur le NAS, SWAG n'a aucun intérêt. Acme est plus indiqué.

Concernant l'erreur du script, après plusieurs essais on avait remarqué que si tu écris .210/29 tu tronques certaines IP. Si tu vas sur le calculateur de jodies, tu dois indiquer ce qui est noté dans "network" : https://jodies.de/ipcalc?host=192.168.0.210&mask1=29&mask2=

Merci beaucoup pour ton retour, je vais donc désactiver acme.sh qui ne me sert plus. 

A part ça, tout fonctionne correctement avec notamment Authelia, fail2ban, crowdsec etc... C'est vraiment le top merci pour tes tutoriels.

Est-il possible de désactiver l'accès aux services par le biais de l'ip de mon NAS ? Étant donné que j'ai SWAG qui fait office de revers proxy avec l'ip 192.168.50.200. Il n'y a pas de grand intérêt à faire cela, mais c'est plus pour ma culture.

[.Shad.]

En jouant sur le pare-feu tu pourrais oui, mais pour peu que ton conteneur SWAG ou Docker déconnerait, tu perdrais l'accès à ton NAS. Je n'y vois pas un grand intérêt à titre personnel.

[MilesTEG1]

Hello 👋🏻 

Dîtes, avez vous des soucis avec le bouncer de Crowdsec qui ne veut pas être télécharger dans l’image swag ?!

chez moi ça me fait une erreur (je n’ai plus le terme exact et je suis sûr mobile…) « … mismatch … », et nginx redémarre sans avoir fini son démarrage.

Dès lors que j’enlève le mod Crowdsec du docker compose , nginx fini son démarrage.

je posterais plus de précision quand j’aurais le pc sous la main.

[.Shad.]

@MilesTEG1 Désolé oublié de te répondre. Oui ça m'arrive parfois.
Pour finir je n'utilise plus Crowdsec, beaucoup de faux positifs via les logs nginx, ça va mieux quand il y a des collections adaptées (emby par exemple). Mais même comme ça, j'ai voulu mettre en place le deban par recaptcha, j'ai tout configuré comme il fallait, mais il y a des bugs, que j'ai remontés sur Github mais rien n'évolue.

Donc exit pour ma part, retour à fail2ban.

[MilesTEG1]

@.Shad.F2B et Crowdsec ne sont pas exclusifs ^^

J'ai les 2 en fonctionnement.

Mais oui, j'ai parfois l'impression qu'il y a des faux positifs via les logs nginx pour Crowdsec.
Il faut préférer passer les logs des applications directement avec une collection dédiée pour être à peu près tranquille.

Mais ce n'est pas toujours possible : par exemple, j'ai un serveur Home Assistant dans une VM, et je ne peux pas partager comme ça ses logs dans SWAG (pour F2B ou Crowdsec).

[.Shad.]

@MilesTEG1 Je pense que c'est ce que tu cherches : syslog-ng - LinuxServer.io

[MilesTEG1]

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

@MilesTEG1 Je pense que c'est ce que tu cherches : syslog-ng - LinuxServer.io

Oh my !
Mais oui !

Merci bien 😉

Va me falloir un peu potasser le truc, mais oui ^^

[.Shad.]

@MilesTEG1 L'autre solution, plus propre selon moi, c'est d'utiliser une instance déportée de Crowdsec dans ta VM HA, soit via docker, soit via une installation native (https://www.crowdsec.net/blog/multi-server-setup)

Ca a l'avantage que les logs restent analysés localement par Crowdsec (mais ça implique d'avoir une collection spécifique pour l'application que tu souhaites surveiller) et lorsqu'il y a blocage c'est renvoyé à l'instance maître, qui bloque au niveau de Nginx.

C'est la solution que j'utilise pour Emby qui est sur une machine déportée, je dis "utilise" car il y a apparemment du nouveau sur le bug du recaptcha, suffisait d'en discuter 😅 -> https://github.com/crowdsecurity/lua-cs-bouncer/issues/44#issue-1879105885

[MilesTEG1]

 

@.Shad. Salut 👋

Le 12/01/2024 à 11:05 PM, .Shad. a dit :

@MilesTEG1 L'autre solution, plus propre selon moi, c'est d'utiliser une instance déportée de Crowdsec dans ta VM HA, soit via docker, soit via une installation native (https://www.crowdsec.net/blog/multi-server-setup)

Ca a l'avantage que les logs restent analysés localement par Crowdsec (mais ça implique d'avoir une collection spécifique pour l'application que tu souhaites surveiller) et lorsqu'il y a blocage c'est renvoyé à l'instance maître, qui bloque au niveau de Nginx.

C'est la solution que j'utilise pour Emby qui est sur une machine déportée, je dis "utilise" car il y a apparemment du nouveau sur le bug du recaptcha, suffisait d'en discuter 😅 -> https://github.com/crowdsecurity/lua-cs-bouncer/issues/44#issue-1879105885

 

Je pense que je vais repartir sur cette idée, placer dans le Home Assistant une instance de Crowdsec.

 

 

Sinon, j'ai un petit souci avec Fail2Ban intégré de SWAG...
Impossible de lancer la commande habituelle : 

sudo docker exec -it swag fail2ban-client status

 

ALors que la même commande pour Crowdsec fonctionne bien : 

sudo docker exec -t crowdsec cscli

 

 

Je ne comprends pas, car quand je vais dans le conteneur avec :

sudo docker exec -t swag /bin/bash

je peux lancer la commande fail2ban-client sans soucis...

As-tu une idée ?

bon en fait ça chie aussi dans le conteneur :

root@Swag--DS920Plus:/# fail2ban-client restart
2024-01-24 08:36:23,444 fail2ban                [3615]: ERROR   Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?
2024-01-24 08:36:23,543 fail2ban                [3615]: ERROR   Fail2ban seems to be in unexpected state (not running but the socket exists)
root@Swag--DS920Plus:/#

 

root@Swag--DS920Plus:/# fail2ban-client reload
2024-01-24 08:38:25,419 fail2ban                [3891]: ERROR   Could not find server

 

La commande fail2ban-client fonctionne, mais pas quand je mets un argument derrière.

Je vais relancer le conteneur, mais je n'y crois pas, j'ai déjà fait ça tout à l'heure...

[MilesTEG1]

@.Shad.Hmmm, j'ai trouvé ce qui faisait foirer mon fail2ban...
C'étaient des commentaires dans la liste d'IP à ignorer... pffff...
Va savoir pourquoi ces commentaires bien mis avec # devant n'étaient pas pris en compte correctement...

Maintenant qu'ils sont supprimés, tout va bien 😅

[Sehoku]

Bonjour,

Ça fait un moment maintenant que mon NAS et les services associés tournent grâce à la configuration conseillée dans ce tutoriel. Et pour cela, merci.

Aujourd'hui, je poste parce que je rencontre des problèmes qui dépassent mes compétences réseau et ma compréhension du sujet.

Pour contextualiser, j'ai dû me mettre dans une configuration réseau un peu particulière pour le télétravail. Dans ce contexte, le routeur de mon FAI est resté en mode routeur, il fournit le réseau local (192.168.0.X) pour mes appareils tels que téléphone, ordinateur, etc. Pour segmenter le réseau (et ajouter de la difficulté...), j'ai activé une DMZ vers un routeur OpenWRT derrière lequel se trouve mon serveur NAS (192.168.10.X). Côté redirection de port, mon routeur OpenWRT redirige le port 80 et 443 vers le reverse proxy (192.168.10.145) et le port 6690 directement vers l'IP locale de mon NAS (192.168.10.5).

Dans ce contexte, je rencontre deux problèmes liés au client Synology Drive :

1. Quand je tente de me connecter via le nom de domaine, je me retrouve avec une erreur de certificat SSL. Avez-vous une idée d'où cela pourrait venir ?
2. Je ne parviens pas à accéder au client Synology Drive via le nom de domaine depuis mon réseau LAN, mais c'est OK si je me connecte depuis un accès Internet. Auriez-vous des pistes ?

Pour rajouter des éléments quelque sorties telnet:
Depuis le LAN:

telnet drive.ndd.fr 80  
Trying IP_PUBLIC...
Connected to drive.ndd.fr.

telnet drive.ndd.fr 6690  
Trying IP_PUBLIC...
telnet: connect to address IP_PUBLIC: Operation timed out
telnet: Unable to connect to remote host     

telnet drive.ndd.fr 6691  
Trying IP_PUBLIC...
telnet: connect to address IP_PUBLIC: Connection refused
telnet: Unable to connect to remote host    

Depuis l'extérieur:

telnet drive.ndd.fr 80  
Trying IP_PUBLIC...
Connected to drive.ndd.fr.

telnet drive.ndd.fr 6690  
Trying IP_PUBLIC...
Connected to drive.ndd.fr.   

Modifié le 10 mars par Sehoku

[.Shad.]

Hello, content que ça réponde à ton besoin.

drive.ndd.fr pointe vers ton proxy ou ton NAS ? car le ndd doit pointer vers le NAS pour le trafic qui passe par le port 6690. Ce que tu peux faire passer par le proxy c'est l'interface d'accès à Drive.

[Sehoku]

Tu parles d'un point de vu parefeu du routeur openwrt? Si c'est le cas oui la règle niveau pare feu c'est:
Transfère le trafic IPV4 TCP entrant du WAN via le port 6690 vers le port 6690 du NAS en LAN dont l'ip est 192.168.10.5
 

Si je me met en partage de co depuis ma 5G pas de soucis par contre depuis mon wifi ça ne fonctionne pas 😕 

[.Shad.]

@Sehoku

Qu'as-tu mis dans ton client Synology, j'entends client desktop Windows ou Mac ? (pas Android ou iOS)

drive.ndd.fr pour l'adresse du NAS ?

En parallèle, peux-tu faire via le terminal :

nslookup drive.ndd.fr

Modifié le 11 mars par .Shad.

[Sehoku]

Dans le client Mac (et linux) je met drive.ndd.fr et la commande nslookup me donne:

nslookup drive.ndd.fr                      
Server:        <IP_de_mon_serveur_de_nom>
Address:    <IP_de_mon_serveur_de_nom>#53

Non-authoritative answer:
Name:    drive.ndd.fr
Address: <Mon_IP_Publique>

[.Shad.]

Donc déjà ça montre qu'il n'y a pas de résolution DNS locale dans ton réseau, à ce titre tu y gagnerais beaucoup en suivant ce tutoriel :

Dans ton cas, pour accéder d'un périphérique A à un périphérique B sur ton réseau local, l'IP publique de ta box est sollicitée. Car ne sachant pas vers quoi pointe localement drive.ndd.fr, ton périphérique A s'en remet aux serveurs publiques, qui lui disent que ça pointe chez toi 😄 

Le NAT Hair-pinning (appelé aussi parfois loopback), permet à une box de se rendre compte qu'une requête a priori publique provient en fait d'un réseau interne, pour atteindre un périphérique d'un réseau interne, la requête fait donc un "demi-tour" (d'où le terme d'épingle - hairpin) pour revenir au sein de ton réseau.

J'ai tendance à penser que la succession de routeurs au sein de ton réseau pourrait perturber ce procédé (pour autant que ta box en soit capable).

Lorsque tu es sur les data, ça se passe ainsi :

drive.ndd.fr -> résolution publique -> pointe vers l'IP publique :

* requête port 443 ? ==> reverse proxy -> interface web
* requête port 6690 ? ==> NAS -> transfert de données Drive 

En local :

drive.ndd.fr -> résolution publique (car pas de réso. locale) -> pointe vers l'IP publique -> ?

La méthode la plus simple pour moi :

1. Créer un certificat dédié via DSM (par exemple pour le ndd gratuit fourni par Synology) associé aux services Synology non proxiables (Hyperbackup, Drive (données), etc...) ==> nas.toto.synology.me
2. Modifier le fichier hosts de ton Windows (C:\Windows\System32\drivers\etc) et y inclure la ligne :

192.168.10.5       nas.toto.synology.me

et c'est le ndd que tu devras mettre dans ton client Synology Drive Windows

Quant à la meilleure méthode, elle consiste à mettre en place une zone DNS locale qui permette de faire du split DNS, en gros lorsque tu es en local tu résous localement (avec les IP privées) tes noms de domaine, et en dehors de ton réseau, les mêmes noms de domaine se résolvent publiquement.
Ça permet au final :

• d'avoir les mêmes noms de domaine où qu'on soit
• de ne pas devoir effectuer la modification sur chaque poste client
• d'être indépendant des serveurs de nom publiques

[Sehoku]

Merci beaucoup je pense effectivement que tu vois juste.

J'ai bien un serveur Bind DNS dans ma config dans mon réseau local mais il ne me sert qu'a avoir des raccourcis, je ne l'ai pas configuré pour qui fasse des redirections vers le nas.
Je vais voir si je peux le réutiliser pour ajouter cette règle et celles conseillé dans l'autre tuto. Dans le cas contraire je ferais une bascule vers la solution de DNS de synology.

Par contre si je comprend bien même si je fais ça je devrais utiliser nas.toto.synology.me plutôt que drive.ndd.fr pour le SSL?

Modifié le 12 mars par Sehoku

[.Shad.]

Si tu as un serveur Bind c'est parfait, DNS Server du NAS c'est Bind avec une interface en fait.
Il te faut juste créer une zone DNS avec ton ndd.fr, comme ça tu feras du split DNS.
Et tu pourras même ajouter des vues par après pour différencier le comportement lorsque tu es par exemple connecté en local ou en VPN (si tu as un serveur VPN).

Il y a 9 heures, Sehoku a dit :

Par contre si je comprend bien même si je fais ça je devrais utiliser nas.toto.synology.me plutôt que drive.ndd.fr pour le SSL?

Alors ça dépend, tu as plusieurs possibilités :

• importer le certificat généré par SWAG dans DSM, fastidieux car manuel
• créer un certificat pour ton domaine ndd.fr dans DSM, mais sans wildcard, pour avoir le même ndd utilisé, ça va coincer avec le NAT du port 80 déjà utilisé par SWAG normalement pour la redirection http -> https, cela dit si tu utilises HSTS tu peux te passer du port 80 sur SWAG
• mettre en place un conteneur acme.sh pour générer un certificat wildcard pour ndd.fr avec le déploiement automatisé du certificat dans DSM ==> la meilleure méthode selon moi
• utiliser le ndd Synology pour les services du NAS qui ne passent par le proxy inversé -> solution du fainéant que j'utilise 😄 

[Sehoku]

Top j'ai réussi la config tout est ok maintenant.
Merci énormément !

J'ai fait le choix de faire une zone drive.ndd.fr comme ça il n'y a que ce chemin qui est impacté le reste est résolu par les relais. Pour le ssl j'ai décidé de partir sur :

Le 12/03/2024 à 9:43 AM, .Shad. a dit :

mettre en place un conteneur acme.sh pour générer un certificat wildcard pour ndd.fr avec le déploiement automatisé du certificat dans DSM ==> la meilleure méthode selon moi

Par contre en faisant ça est-ce qu'il faut que je demande à swag d'arrêter de s'occuper du certificat?

[.Shad.]

@Sehoku Tu peux multiplier les certificats pour un même domaine, ça ne pose aucun problème. 😉 

[.Shad.]

Refonte du tutoriel prévue pour Pâques je pense, j'ai revu le compose et l'architecture pour faire quelque chose de beaucoup plus simple.

La nouvelle version sera plus directe, et à l'image de mon récent tutoriel de sécurisation pour DSM 7, j'intégrerai des balises spoilers pour ceux qui veulent plus de détails et remarques.

[MilesTEG1]

@.Shad.Tu vas abandonner le macvlan ?

En ce qui me concerne j'ai placé SWAG sur un NUC, donc plus besoin du macvlan.
Mais j'ai continué à utiliser ton travail sur SWAG ^^

[.Shad.]

@MilesTEG1, sisi je garde le macvlan, pas le choix sur DSM, mais j'intégre SWAG aussi dans un bridge personnalisé dans lequel se trouve Authelia, ainsi rien à changer dans les fichiers de configuration d'authelia, on peut continuer à utiliser le nom de conteneur.

[MilesTEG1]

@.Shad.haaa oui j’avais fait ça pour intégrer Crowdsec 😊

c’est une bonne idée 😊👍🏻