[TUTO] Certificat SSL & reverse proxy via Docker

[.Shad.]

Oui, si on veut de la 2FA sur ses applications Synology, c'est proposé nativement dans DSM.

[.Shad.]

@Taribam Tu n'avais pas posté quelque chose ? Si c'est le cas, barre plutôt que supprimer. 😉 

[bruno78]

Bonjour,

j'ai mis en place une configuration Authelia / Swag (sur un RPI4) grace à ce tuto et celui sur Authelia. Très bien. Une fois que l'on ne se trompe pas dans les instructions ou les adaptations, tout va bien.

Ensuite, j'ai dû faire malencontreusement une mauvaise manip quelque part (mauvaise bidouille ! ), et je me retrouve coincé avec swag et le renouvellement automatique du certificat.

Je m'explique :

• la première mise en oeuvre et génération du premier certificat remonte au 14 novembre 2021, avec une validité jusqu'au 12 février 2022.
• lorsque je me connecte sur le domaine concerné, je vérifie le certificat et il me dit : expire au 12 février 2022. Ok c'est le premier certificat généré à la création.

Donc je commence à me préoccuper du renouvellement, et dans le log du docker swag il me dit qu'il n'y a pas de tentative de renouvellement car la date d'expiration est le 25 avril 2022 ... !! Cf. log ci-dessous (avec ndd.tld) :

root@298e520433a1:/var/log/letsencrypt# cat letsencrypt.log
2022-01-31 02:08:08,944:DEBUG:certbot._internal.main:certbot version: 1.22.0
2022-01-31 02:08:08,945:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot
2022-01-31 02:08:08,945:DEBUG:certbot._internal.main:Arguments: ['-n', '--post-hook', 'if ps aux | grep [n]ginx: > /dev/null; then s6-svc -h /var/run/s6/services/nginx; fi;     cd /config/keys/letsencrypt &&     openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: &&     sleep 1 &&     cat privkey.pem fullchain.pem > priv-fullchain-bundle.pem &&     chown -R abc:abc /config/etc/letsencrypt']
2022-01-31 02:08:08,946:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#certbot-dns-aliyun:dns-aliyun,PluginEntryPoint#certbot-dns-cpanel:cpanel,PluginEntryPoint#certbot-dns-desec:dns-desec,PluginEntryPoint#certbot-dns-directadmin:directadmin,PluginEntryPoint#certbot-dns-dnspod:dns-dnspod,PluginEntryPoint#certbot-dns-domeneshop:dns-domeneshop,PluginEntryPoint#certbot-dns-he:dns-he,PluginEntryPoint#certbot-dns-hetzner:dns-hetzner,PluginEntryPoint#certbot-dns-infomaniak:dns-infomaniak,PluginEntryPoint#certbot-dns-inwx:dns-inwx,PluginEntryPoint#certbot-dns-ionos:dns-ionos,PluginEntryPoint#certbot-dns-netcup:dns-netcup,PluginEntryPoint#certbot-dns-njalla:dns-njalla,PluginEntryPoint#certbot-dns-transip:dns-transip,PluginEntryPoint#certbot-dns-vultr:dns-vultr,PluginEntryPoint#certbot-plugin-gandi:dns,PluginEntryPoint#certbot-plugin-gandi:dns-gandi,PluginEntryPoint#certbot-route53:auth,PluginEntryPoint#cpanel,PluginEntryPoint#directadmin,PluginEntryPoint#dns,PluginEntryPoint#dns-aliyun,PluginEntryPoint#dns-cloudflare,PluginEntryPoint#dns-cloudxns,PluginEntryPoint#dns-desec,PluginEntryPoint#dns-digitalocean,PluginEntryPoint#dns-dnsimple,PluginEntryPoint#dns-dnsmadeeasy,PluginEntryPoint#dns-dnspod,PluginEntryPoint#dns-domeneshop,PluginEntryPoint#dns-gandi,PluginEntryPoint#dns-google,PluginEntryPoint#dns-he,PluginEntryPoint#dns-hetzner,PluginEntryPoint#dns-infomaniak,PluginEntryPoint#dns-inwx,PluginEntryPoint#dns-ionos,PluginEntryPoint#dns-linode,PluginEntryPoint#dns-luadns,PluginEntryPoint#dns-netcup,PluginEntryPoint#dns-njalla,PluginEntryPoint#dns-nsone,PluginEntryPoint#dns-ovh,PluginEntryPoint#dns-rfc2136,PluginEntryPoint#dns-route53,PluginEntryPoint#dns-transip,PluginEntryPoint#dns-vultr,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2022-01-31 02:08:09,082:DEBUG:certbot._internal.log:Root logging level set at 30
2022-01-31 02:08:09,087:DEBUG:certbot._internal.display.obj:Notifying user: Processing /etc/letsencrypt/renewal/ndd.tld-0001.conf
2022-01-31 02:08:10,178:DEBUG:certbot._internal.plugins.selection:Requested authenticator <certbot._internal.cli.cli_utils._Default object at 0x7fa4bc0d90> and installer <certbot._internal.cli.cli_utils._Default object at 0x7fa4bc0d90>
2022-01-31 02:08:10,179:DEBUG:certbot._internal.cli:Var post_hook=if ps aux | grep [n]ginx: > /dev/null; then s6-svc -h /var/run/s6/services/nginx; fi;     cd /config/keys/letsencrypt &&     openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: &&     sleep 1 &&     cat privkey.pem fullchain.pem > priv-fullchain-bundle.pem &&     chown -R abc:abc /config/etc/letsencrypt (set by user).
2022-01-31 02:08:11,154:DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): r3.o.lencr.org:80
2022-01-31 02:08:11,314:DEBUG:urllib3.connectionpool:http://r3.o.lencr.org:80 "POST / HTTP/1.1" 200 503
2022-01-31 02:08:11,318:DEBUG:certbot.ocsp:OCSP response for certificate /etc/letsencrypt/archive/ndd.tld-0001/cert3.pem is signed by the certificate's issuer.
2022-01-31 02:08:11,319:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/ndd.tld-0001/cert3.pem is: OCSPCertStatus.GOOD
2022-01-31 02:08:11,333:DEBUG:certbot._internal.display.obj:Notifying user: Certificate not yet due for renewal
2022-01-31 02:08:11,336:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-ovh and installer None
2022-01-31 02:08:11,336:DEBUG:certbot._internal.display.obj:Notifying user: Processing /etc/letsencrypt/renewal/ndd.tld.conf
2022-01-31 02:08:12,297:DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): r3.o.lencr.org:80
2022-01-31 02:08:12,307:DEBUG:urllib3.connectionpool:http://r3.o.lencr.org:80 "POST / HTTP/1.1" 200 503
2022-01-31 02:08:12,310:DEBUG:certbot.ocsp:OCSP response for certificate /etc/letsencrypt/archive/ndd.tld-0001/cert3.pem is signed by the certificate's issuer.
2022-01-31 02:08:12,312:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/ndd.tld-0001/cert3.pem is: OCSPCertStatus.GOOD
2022-01-31 02:08:12,315:DEBUG:certbot._internal.display.obj:Notifying user: Certificate not yet due for renewal
2022-01-31 02:08:12,317:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-ovh and installer None
2022-01-31 02:08:12,317:DEBUG:certbot._internal.display.obj:Notifying user:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2022-01-31 02:08:12,318:DEBUG:certbot._internal.display.obj:Notifying user: The following certificates are not due for renewal yet:
2022-01-31 02:08:12,318:DEBUG:certbot._internal.display.obj:Notifying user:   /etc/letsencrypt/live/ndd.tld-0001/fullchain.pem expires on 2022-04-25 (skipped)
  /etc/letsencrypt/live/ndd.tld-0001/fullchain.pem expires on 2022-04-25 (skipped)
2022-01-31 02:08:12,318:DEBUG:certbot._internal.display.obj:Notifying user: No renewals were attempted.
2022-01-31 02:08:12,319:DEBUG:certbot._internal.display.obj:Notifying user: No hooks were run.
2022-01-31 02:08:12,319:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2022-01-31 02:08:12,319:DEBUG:certbot._internal.renewal:no renewal failures
root@298e520433a1:/var/log/letsencrypt#

 

Donc quelque part le certificat a déjà été renouvellé, mais il n'est pas pris en compte.

Quel serait le moyen de s'en sortir ?

Merci d'avance, Bruno78

 

[.Shad.]

Je te réponds demain, je dois regarder ce que j'ai de mon côté et je ne rentre que tard chez moi ce soir. 😉 
Visiblement il a bien renouvelé ton certificat au bout de 2 mois, mais il ne l'utilise pas, très étrange.

[Einsteinium]

@bruno78 Nginx doit être relancé après mise à jour du certificat, le plus simple est de relancé le docker (Que d'attaqué en ligne de commande, tu gagneras du temps)

[bruno78]

@.Shad.@Einsteinium merci pour vos retour,

j'avais "simplement" copié en dur les certificats d'origine lors de la mise au point de l'ensemble et je n'y avais plus pensé, et donc nginx ne prenait pas en compte les renouvellements à venir.

A présent on pointe bien sur le certificat renouvelé, donc plus de problème.

Merci, Bruno78

[April]

Bonjour

J'ai voulu activer le nouveau mod pour swag : dashboard.

si je fais dashboard.xxxxxxx.ovh j'ai une erreur 403, le problème peu venir du fait que j'ai une livebox 3 qui ne supporte pas le loopback, pourtant cette adresse est traitée en local.

j'ai essayé de modifier le fichier host du PC :   192.168.1.201 dashboard.xxxxxxx.ovh   mais pas de changement.

dans dashboard.subdomain.conf j'ai désactivé deny all; pour tester avec un VPN, j'accède à tout mes sous domaines xxxxxx.xxxxxxx.ovh sauf dashboard.xxxxxxx.ovh

le log de swag

Applied the SWAG dashboard mod

[cont-init.d] 98-dashboard-config: exited 0.

[cont-init.d] 99-custom-files: executing...

[custom-init] no custom files found exiting...

[cont-init.d] 99-custom-files: exited 0.

[cont-init.d] done.

[services.d] starting services

[services.d] done.

dans le docker compose j'ai cette ligne

      - DOCKER_MODS=linuxserver/mods:swag-f2bdiscord|linuxserver/mods:swag-dashboard (discord fonctionne bien)

auriez vous une idée pour accéder au dashboard ? merci

[.Shad.]

Hé ! Une UI ce serait génial pour SWAG 😎

Je ne savais même pas, je regarderai et te dirai si j'ai réussi à la mettre en place. 🙂

[.Shad.]

@April Alors chez moi ça marche bien. C'est une entrée de proxy inversé comme une autre. Est-ce que tu fais bien pointer dashboard.ndd.tld sur l'IP de SWAG ? Ne commente pas seulement le deny all mais tous les allow aussi. Les allow n'ont de sens que s'il y a un deny derrière.

Modifié le 12 mars 2022 par .Shad.

[April]

Merci pour ton aide mais je ne comprend pas trop, si c'est comme d'habitude je fais pointer comme ça dans xxxxxx.subdomain.conf

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.210;
        set $upstream_port 8089;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

dans dashboard.subdomain.conf :

        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi_params;

en supprimant les deny et allow je me connecte au travers d'un vpn, ça doit être la livebox qui n'a pas le loopback.

impossible en local, penses tu qu'il serait possible de se connecter avec l'adresse IP de swag + un port ?

 

------ Edit --------------

Problème résolu avec le fichier host de windows

Modifié le 12 mars 2022 par April

[.Shad.]

Le mod émet localement dans SWAG, et c'est SWAG qui gère un proxy interne au conteneur pour y accéder (vu que ça émet sur localhost:9000).

Il y a 21 heures, April a dit :

en supprimant les deny et allow je me connecte au travers d'un vpn, ça doit être la livebox qui n'a pas le loopback.

Pas de DNS local ? Tu utilises uniquement le loopback ?
Parce que même sans loopback, si Authelia est en place (je crois que c'était ton cas?), tu tombes dans les conditions d'un accès externe, à voir si tu as mis un bypass, un 1FA ou 2FA.

Pour ma part j'ai modifié le fichier dashboard.subdomain.conf pour réagir aux sous-domaines de type swag.* et pas dashboard.*
J'ai aussi activé Authelia tout en commentant les allow et deny, qui sont redondants avec la couche de sécurité amenée par Authelia.
C'est tout.

Essaie de voir quand même si tu arrives à te débarasser des etrées dans le fichier hosts, c'est très brut somme solution (mais a le mérite de fonc

Modifié le 13 mars 2022 par .Shad.

[Tex5]

@.Shad.

J'ai essayé de dérouler le tuto (très bien expliqué) mais je dois louper un truc

J'ai réussi a créer mon macvlan (déjà utilisé par mon docker Plex), ainsi que mon interface virtuelle

Par contre quand j'essaie de créer le container j'obtiens cela :

ERROR: In file './docker-compose.yml', network 'external' must be a mapping not a boolean.

c'est surement une erreur stupide de débutant mais j'ai beau recommencer depuis le début, rien n'y fait.

[.Shad.]

@Tex5 Le problème était dans le tutoriel, mauvaise indentation du paramètre external par rapport au reste (4 indentations dans la partie services entre les paramètres environment, volumes, etc... et les lignes commençant par un tiret, et 3 indentations dans le cas d'external).

J'ai corrigé ça, assure-toi que l'indentation est ok de ton côté et ça devrait rouler.

[Tex5]

@.Shad. merci Le script a focntionné

Modifié le 6 août 2022 par Tex5

[MilesTEG1]

@.Shad.
Je pense finalement me lancer dans l'aventure SWAG 🙂 avec Fail2ban et Authellia (voir aussi CrowdSec su j'arrive à comprendre comment l'installer et l'utiliser ^^)

J'ai une petite question (ou plusieurs 🤣) ^^

J'utilise actuellement ACME (tuto de Einsteinium) pour mon ndd OVH. N'y a-t-il pas moyen de récupérer les fichiers certificats qu'il génère pour SWAG ? (de manière automatique of course)

Autre question vis-à-vis de l'API OVH : est-il possible de générer un deuxième jeu ? un réservé à SWAG ? Afin de laisser celui de ACME à ACME ?

[.Shad.]

il y a 20 minutes, MilesTEG1 a dit :

J'utilise actuellement ACME (tuto de Einsteinium) pour mon ndd OVH. N'y a-t-il pas moyen de récupérer les fichiers certificats qu'il génère pour SWAG ? (de manière automatique of course)

Autre question vis-à-vis de l'API OVH : est-il possible de générer un deuxième jeu ? un réservé à SWAG ? Afin de laisser celui de ACME à ACME ?

Si, il y a moyen, mais pourquoi faire ?
SWAG gère le ou les certificats de façon autonome et transparente (il utilise certbot, alternative à acme).

La différence principale c'est que certbot ne permet pas de déployer le certificat dans DSM, ce dont on se fiche si c'est SWAG le proxy inversé.

Et oui, tu peux créer autant de tokens que tu veux, j'en ai 4 perso.

Modifié le 11 août 2022 par .Shad.
fautes d'orthographe

[MilesTEG1]

@.Shad.

Voilà, j'ai créé mon conteneur SWAG.
Il y a quelques erreurs dans le log (avec les grep), mais apparemment sans conséquence sur la création du certificat.
J'ai créé une nouvelle API avec tes permissions (qui sont différentes de celles que j'ai utilisé pour ACME mais tant que ça fonctionne 😉 )
Bon pour le moment j'ai pas redirigé le port 443 vers swag, je ferais ça plus tard, car va falloir configurer les entrées du reverse proxy...
j'ai regardé dans les fichiers de conf proposés, va falloir que j'adapte pas mal, notamment pour Vaultwarden... (je viendrais probablement te poser des questions quand je me lancerais ^^)

Questions pour Fail2Ban :

1. le conteneur SWAG possède une instance complète de F2B ? Je pourrais désinstaller complètement celle que j'avais mis en place avant ?
2. Est-ce que l'instance dans SWAG est peu ou prou identique au nouveau conteneur qu'ils ont publié récemment : https://github.com/linuxserver/docker-fail2ban.    (voir aussi les confs : https://github.com/linuxserver/fail2ban-confs )

Plus tard, je mettrais en place Authelia ^^ Et j'espère CrowdSec si j'y arrive 😉 

Voilà le log du conteneur :

Brought to you by linuxserver.io
-------------------------------------

To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    1010
User gid:    100
-------------------------------------

cont-init: info: /etc/cont-init.d/20-config exited 0
cont-init: info: running /etc/cont-init.d/30-keygen
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Generating a RSA private key
............................+++++
..+++++
writing new private key to '/config/keys/cert.key'
-----
cont-init: info: /etc/cont-init.d/30-keygen exited 0
cont-init: info: running /etc/cont-init.d/50-config
Variables set:
PUID=1010
PGID=100
TZ=Europe/Paris
URL=mon-ndd.ovh
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=mon-email@provider.com
STAGING=false

grep: /config/nginx/resolver.conf: No such file or directory
Setting resolver to  127.0.0.11
Setting worker_processes to 4
Created .donoteditthisfile.conf
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for mon-ndd.ovh will be requestedndd.ovh
E-mail address entered: mon-email@provider.com
dns validation via ovh plugin is selected
Generating new certificate
grep: /config/nginx/worker_processes.conf: No such file or directory
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account registered.
Requesting a certificate for *.mon-ndd.ovh and mon-ndd.ovh
Waiting 120 seconds for DNS changes to propagate

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/mon-ndd.ovh/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/mon-ndd.ovh/privkey.pem
This certificate expires on 2022-11-10.
These files will be updated when the certificate renews.
NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New certificate generated; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
cont-init: info: /etc/cont-init.d/50-config exited 0
cont-init: info: running /etc/cont-init.d/60-renew
cont-init: info: /etc/cont-init.d/60-renew exited 0
cont-init: info: running /etc/cont-init.d/70-templates
cont-init: info: /etc/cont-init.d/70-templates exited 0
cont-init: info: running /etc/cont-init.d/90-custom-folders
cont-init: info: /etc/cont-init.d/90-custom-folders exited 0
cont-init: info: running /etc/cont-init.d/99-custom-files
[custom-init] no custom files found exiting...
cont-init: info: /etc/cont-init.d/99-custom-files exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-mods: starting
s6-rc: info: service init-mods successfully started
s6-rc: info: service init-mods-package-install: starting
s6-rc: info: service init-mods-package-install successfully started
s6-rc: info: service init-mods-end: starting
s6-rc: info: service init-mods-end successfully started
s6-rc: info: service init-services: starting
s6-rc: info: service init-services successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun cron (no readiness notification)
services-up: info: copying legacy longrun fail2ban (no readiness notification)
services-up: info: copying legacy longrun nginx (no readiness notification)
services-up: info: copying legacy longrun php-fpm (no readiness notification)
s6-rc: info: service legacy-services successfully started
s6-rc: info: service 99-ci-service-check: starting
[ls.io-init] done.
s6-rc: info: service 99-ci-service-check successfully started
Server ready

 

[.Shad.]

@MilesTEG1 Pour les erreurs avec les logs, on dirait qu'il ne trouve pas les fichiers. Tu as regardé s'ils existaient bien ?

Il y a 7 heures, MilesTEG1 a dit :

Bon pour le moment j'ai pas redirigé le port 443 vers swag, je ferais ça plus tard, car va falloir configurer les entrées du reverse proxy...

Tu peux très bien ne rien toucher à ta config, il te suffit d'ajouter des entrées redondantes dans Adguard pour la résolution locale pointant sur SWAG au lieu du NAS et faire tous les tests dont tu as besoin. 😉

Il y a 7 heures, MilesTEG1 a dit :

j'ai regardé dans les fichiers de conf proposés, va falloir que j'adapte pas mal, notamment pour Vaultwarden... (je viendrais probablement te poser des questions quand je me lancerais ^^)

Normalement le fichier par défaut est adapté pour Vaultwarden et pas Bitwarden, sur Bitwarden tu n'as pas besoin de bloc location pour les notifications live, tout passe par un 2ème proxy inversé interne au conteneur. Si je me rappelle bien celui de SWAG prévoit un bloc pour les notifications.

Il y a 7 heures, MilesTEG1 a dit :

le conteneur SWAG possède une instance complète de F2B ? Je pourrais désinstaller complètement celle que j'avais mis en place avant ?

Ben le mieux est de la laisser, de la désactiver au besoin et de voir si SWAG prend le relais sur tous les points.
La seule différence notable c'est que vu qu'ils mettent f2b en host sur l'image dédiée, ça dépasse les limites du proxy inversé, comme un f2b habituellement. Dans SWAG, fail2ban ne s'applique qu'au proxy inversé. Car oui il peut potentiellement lire n'importe quel log, suffit de le monter, mais il ne pourra que jouer avec les iptables du conteneur, s'il est en bridge ou macvlan.

Alors dans mon cas je n'ai pas un seul service d'authentification qui ne passe par le proxy inversé, donc c'est égal, mais à voir dans ton cas. Et pour les services du NAS que j'expose localement en http, il y a le fail2ban du NAS qui prend le relais.

Regarde quand même pour les grep, c'est bizarre. Si les fichiers n'existent pas tu peux les wget depuis le dépôt GitHub de SWAG.

[MilesTEG1]

@.Shad. Pour les grep qui trouvent pas les fichiers, ils sont bien présents (ce matin en tout cas 😅) :

Du coup, je ne sais pas pourquoi hier soit ils n'y étaient pas soit le grep retourne qu'ils n'y sont pas...

 

Il y a 1 heure, .Shad. a dit :

Tu peux très bien ne rien toucher à ta config, il te suffit d'ajouter des entrées redondantes dans Adguard pour la résolution locale pointant sur SWAG au lieu du NAS et faire tous les tests dont tu as besoin. 😉

Tu veux dire que je remplace les réécritures dans AdGH pour qu'elles pointent vers l'adresse IP de SWAG ?
Si c'est ça, ça peut en effet se faire facilement pour tester ^^ (bon faudrait que je laisse certains services gérés par le NAS = Plex sinon ça va gueuler )

 

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

Normalement le fichier par défaut est adapté pour Vaultwarden et pas Bitwarden, sur Bitwarden tu n'as pas besoin de bloc location pour les notifications live, tout passe par un 2ème proxy inversé interne au conteneur. Si je me rappelle bien celui de SWAG prévoit un bloc pour les notifications.

J'utlise bien Vaultwarden et pas Bitwarden. Actuellement j'ai un script qui modifie le fichier de conf de nginx de DSM pour ajouter les blocs pour les websockets notifications.
Ce que je voulais dire par "modifier les fichiers de conf fournis par swag", c'est que mes conteneurs ne sont pas dans le réseau macvlan de SWAG, ils sont pour la plupart en bridge, et quelques un en HOST.

D'ailleurs, dans SWAG, c'est quelle adresse IP que je devrais mettre pour envoyer vault.mon-ndd.ovh vers la bonne adresse_IP:port ?
Je mets l'IP réelle du NAS ? Ou bien l'IP virtuelle ?

Je me rends compte que dans AdGuard Home (aussi en macvlan), la réécriture que j'ai paramètré est l'IP réelle du NAS... et ça fonctionne... Est-ce normal ?

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

Dans SWAG, fail2ban ne s'applique qu'au proxy inversé. Car oui il peut potentiellement lire n'importe quel log, suffit de le monter, mais il ne pourra que jouer avec les iptables du conteneur, s'il est en bridge ou macvlan.

Haaa OK ! Donc son domaine d'intervention est limité alors... il ne pourra pas joindre l'IPTABLE du NAS ?
Malgré le :

    cap_add:
      - NET_ADMIN

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

Alors dans mon cas je n'ai pas un seul service d'authentification qui ne passe par le proxy inversé, donc c'est égal, mais à voir dans ton cas.

Je n'ai pas bien saisi ce que tu veux dire... (trop de négation 🤪). Pourrais-tu reformuler ?

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

Et pour les services du NAS que j'expose localement en http, il y a le fail2ban du NAS qui prend le relais.

Ce que tu appelles le fail2ban du NAS, c'est ce qui est configurable via DSM n'est-ce pas ? (blocage auto)

Merci encore pour ton aide 🙂 

[MilesTEG1]

@.Shad. J'ai redémarré SWAG, et je n'ai plus les lignes d'erreur grep 🙂 

[.Shad.]

Il y a 3 heures, MilesTEG1 a dit :

Tu veux dire que je remplace les réécritures dans AdGH pour qu'elles pointent vers l'adresse IP de SWAG ?

Non justement, tu ne remplaces rien, tu en crées d'autres (genre dsm-test en plus de dsm, etc...) qui pointent vers l'IP de SWAG, comme ça tu peux faire tous les tests dont tu as besoin sans toucher à ton installation actuelle. Ca ne marchera que localement tant que tu ne changes par la redirection dans le routeur, mais j'imagine que c'est préférable ainsi pour la phase de test.

Il y a 3 heures, MilesTEG1 a dit :

Ce que je voulais dire par "modifier les fichiers de conf fournis par swag", c'est que mes conteneurs ne sont pas dans le réseau macvlan de SWAG, ils sont pour la plupart en bridge, et quelques un en HOST.

C'est normal, c'est pas gênant.
Chez moi SWAG est en bridge sur ma Debian, Jeedom en macvlan, et bien j'ai ajouté un enregistrement pour l'IP du conteneur Jeedom dans ma zone DNS (ou Adguard dans ton cas) :

ip-jeedom.xxx.ovh          192.168.100.164

Et dans le conf de Jeedom pour SWAG (il n'existe pas, j'ai copié celui de Heimdall que j'ai modifié) :

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name jeedom.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app ip-jeedom.xxx.ovh;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

Pour ce qui est en bridge sur le NAS, tu dois utiliser l'IP virtuelle du NAS oui. Pour ce qui est en host aussi.
Et pour tout ce qui est hébergé ailleurs que sur le NAS (VM de VMM ou autres périphériques), et bien tu utilises leur enregistrement A que tu as mis dans Adguard.

C'est le point 9-A-1 du tutoriel.

Il y a 3 heures, MilesTEG1 a dit :

Haaa OK ! Donc son domaine d'intervention est limité alors... il ne pourra pas joindre l'IPTABLE du NAS ?

C'est un test à faire, je pense que non (je n'ai jamais testé).

Il y a 3 heures, MilesTEG1 a dit :

Je n'ai pas bien saisi ce que tu veux dire... (trop de négation 🤪). Pourrais-tu reformuler ?

Ce qui ne passe par le proxy inversé, par exemple localement je pourrais atteindre mon NAS sur le port 5000, ça ne passe pas par SWAG, mais le NAS a f2b (Oui le blocage auto c'est juste une interface graphique pour fail2ban dans DSM).
Et si j'ai des applications accessibles localement en HTTP sans authentification, c'est qu'elles sont tout sauf critiques.

Du coup tu as parlé de Crowdsec je suis en train de le mettre en place, ça a l'air vraiment sympa et plus convivial que f2b. 🙂 

Modifié le 13 août 2022 par .Shad.

[MilesTEG1]

Merci pour ces infos.
J'essaye dès que je peux de créer une configuration pour une application.

Mais sinon, je vois un soucis avec le fail2ban intégré : je ne vois pas comment spécifier un mot de passe pour l'envoi de mail... ni de serveur SMTP... bref, on peut paramétrer l'adresse email dans le jail.local, mais pour les paramètres serveurs smtp, je ne vois pas ...
Comment fais-tu ?

[Einsteinium]

Je viens d’aller voir ce que je fessais avec mon vps à l’époque, directement en utilisant sendmail, il est pas inclus dans swag ?

[MilesTEG1]

Si, mais je le met où le serveur SMTP que je veux utiliser ainsi que mon mot de passe pour le serveur SMTP ?

 

Autre chose, pour la configuration de NGINX : je veux modifier le fichier ngonx/ssl.conf
Faut-il en faire un .local avec mes modifications ? Ou bien la modification du .conf est pérenne ? (genre après un reboot c'est pas remis à zéro)

[.Shad.]

@MilesTEG1 Il y a sendmail dans le conteneur. Moi j'utilise les notifications discord avec le module qui va bien : https://github.com/linuxserver/docker-mods/tree/swag-f2bdiscord

Tu peux faire toutes les modifs que tu veux elles persistent, et au lancement il te dira quand une config diffère de celle de base dans les logs, ça permet aussi de voir s'il y a eu des majs sur les fichiers embarqués.