This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

[TUTO] Certificat SSL & reverse proxy via Docker


.Shad.

Messages recommandés

Bon j'ai lu plusieurs pages concernant ce problème, je t'invite à tester cette modification :

Tu édites le fichier /config/fail2ban/action.d/iptables-common.conf

Tu dois avoir deux lignes :

blocktype = REJECT --reject-with icmp-port-unreachable
blocktype = REJECT --reject-with icmp6-port-unreachable

Tu les commentes et tu mets à la place pour les deux lignes :

blocktype = DROP

Tu redémarres ensuite le conteneur et vérifies si tu as encore l'erreur.

Lien vers le commentaire
Partager sur d’autres sites

waooo merci !!!!!!!

Solution trouvée en deux temps trois mouvements

J'avais lu aussi que Synology ne supportait pas la commande REJECT mais DROP.

J'ai tenté différents .conf à ma sauce mais sans succès et avec tes instructions tout fonctionne bien.

Juste un détail, en éditant le iptables-common.conf au reboot du conteneur le .conf est remis par défaut.

Il faut copier le .conf en .local puis l'éditer.

Lien vers le commentaire
Partager sur d’autres sites

Difficile à améliorer, le tuto est très bien documenté et pour une fois il fonctionne du 1er coup sans de nombreuses bidouilles.

La complexité doit en rebuter plus d'un en comparaison de Nginx proxy manager avec son interface gui.

Swag par contre a beaucoup plus de fonctionnalités.

Reste à voir dans 2 mois le renouvellement automatique qui pour moi ne fonctionnait pas correctement avec Nginx proxy manager.

Modifié par April
Lien vers le commentaire
Partager sur d’autres sites

Yep, c'est vrai que c'est touffu.
Mais comme tu dis, ces fonctionnalités... j'utilise Authelia depuis plusieurs mois, le blocage GeoIP pour SWAG sur mon VPS (pas de pare-feu de routeur ou du NAS en amont forcément), j'en suis extrêmement satisfait. 🙂 

Tiens-nous au courant du renouvellement de ton certificat. 😉 

Modifié par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

après une semaine de test je dois avouer que Swag est vraiment très complet au niveau sécurité.

si l'on combine le blocage GeoIP (dans mon cas blocage Chine/Russie car je dois garder l'accès disponible à l'Europe et USA/canada, ces 2 pays bloqués doivent bien représenter +-80% des attaques)

avec un fail2ban réglé sur 3 essais et notification par Discord, je pense que la sécurité est maximal.

Merci à .Shad. pour cet excellent tuto.

Lien vers le commentaire
Partager sur d’autres sites

  • 1 mois après...

Bonjour .Shad.

snif mon renouvellement de certificat non fonctionne pas.
aurais tu une idée des pistes à suivre pour régler ce problème ?
le certificat est chez ZeroSSL je trouve que leur interface web est plus pratique.

log swag
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/monsite.ovh.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Failed to renew certificate monsite.ovh with error: <Response [504]>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/monsite.ovh/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Lien vers le commentaire
Partager sur d’autres sites

Hello par ici 🙂

J'ai constaté récemment que mon Fail2ban ne fonctionnait plus pour mon conteneur Vaultwarden, mais il fonctionne bien pour mon Gitea...
Est-ce que parmi vous il y aurait des utilisateurs de Vaultwarden ? Est-ce que le fail2ban de ce tuto fonctionne encore pour votre conteneur Vaultwarden ?

PS : j'ai l'impression que mon conteneur Vaultwarden n'écrit plus dans le log les tentatives de connexion échouées... de ce fait, fail2ban ne peut plus fonctionner...

Lien vers le commentaire
Partager sur d’autres sites

il y a 43 minutes, MilesTEG1 a dit :

j’ai watchtower qui tourne .

moi aussi, chaque semaine et c'est demain. Donc si c'est une version ultérieure qui bug merci de me le dire vite que je puisse bloquer l'update 😉

Lien vers le commentaire
Partager sur d’autres sites

Alors, comme je vais devoir refaire le conteneur pour réactiver la page admin, j'ai ça pour les logs dans mon docker-compose :
HcaK4k1.png

 

Et la version : 
XAEp2RA.png

 

J'ai donc bien la dernière version.

Vous avez quoi comme settings pour les logs ?

Logging · dani-garcia/vaultwarden Wiki (github.com)

Changing the log level
To reduce the amount of log messages, you can set the log level to 'warn' (default is 'info'). The Log level can be adjusted with the environment variable LOG_LEVEL while also setting EXTENDED_LOGGING=true. NOTE: Using the log level "warn" or "error" still allows Fail2Ban to work properly.

LOG_LEVEL options are: "trace", "debug", "info", "warn", "error" or "off".

Donc en warn ça devait passer...

Lien vers le commentaire
Partager sur d’autres sites

Bon j'ai renommé le fichier log, redémarré le conteneur, et retenté d'échouer à la connexion :

2021-09-13 21:11:06,454 fail2ban.filter         [1]: INFO    [vaultwarden] Found 111.111.111.111 - 2021-09-13 21:11:06
2021-09-13 21:11:10,113 fail2ban.filter         [1]: INFO    [vaultwarden] Found 111.111.111.111 - 2021-09-13 21:11:10
2021-09-13 21:12:16,717 fail2ban.filter         [1]: INFO    [vaultwarden-admin] Found 111.111.111.111 - 2021-09-13 21:12:16

Et j'ai enfin fail2ban qui détecte ce qui est enfin écrit dans le log !

 

Je ne sais pas vraiment pourquoi ça ne fonctionnait pas...

Pour le vaultwarden, faut mettre un @ dans le login, sinon ça fait rien...

Lien vers le commentaire
Partager sur d’autres sites

il y a 41 minutes, MilesTEG1 a dit :

Vous avez quoi comme settings pour les logs ?

la même chose que toi.

 

il y a 5 minutes, MilesTEG1 a dit :

Pour le vaultwarden, faut mettre un @ dans le login, sinon ça fait rien...

oui une adresse email est demandée

 

il y a 6 minutes, MilesTEG1 a dit :

Je ne sais pas vraiment pourquoi ça ne fonctionnait pas...

mystère de l'informatique🙄

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1 Le rapport entre ton problème de fail2ban et ce tutoriel est quand même très ténu. Je pense que c'est mieux de créer un post à part pour un cas comme ça.

@April Erreur 504 c'est un timeout, donc soit problème du côté d'OVH soit du côté de ZeroSSL. Retente dans les jours qui viennent pour voir si tu as toujours le problème.

Lien vers le commentaire
Partager sur d’autres sites

serait il possible de mettre à jour par une tache planifiée le certificat de DSM ?

après des recherches j'ai trouvé cette possibilité, un avis ?

 

rsync -avh "/volume1/docker/swag/config/etc/letsencrypt/live/monsite.ovh/cert.pem" "/usr/syno/etc/certificate/_archive/Random PATH/cert.pem"
rsync -avh "/volume1/docker/swag/config/etc/letsencrypt/live/monsite.ovh/privkey.pem" "/usr/syno/etc/certificate/_archive/Random PATH/privkey.pem"
rsync -avh "/volume1/docker/swag/config/etc/letsencrypt/live/monsite.ovh/fullchain.pem" "/usr/syno/etc/certificate/_archive/Random PATH/fullchain.pem"
rsync -avh "/volume1/docker/swag/config/etc/letsencrypt/live/monsite.ovh/chain.pem" "/usr/syno/etc/certificate/_archive/Random PATH/chain.pem"
/usr/syno/etc/rc.sysv/nginx.sh reload

 

Lien vers le commentaire
Partager sur d’autres sites

Ca ne suffirait pas, en tout cas sous DSM 6, car chaque dossier d'application DSM possède aussi le certificat.
Ils auraient pu utiliser un lien symbolique, mais non, il est c/c dans chaque dossier séparément.

Tu peux toujours tester cela dit.
Tu peux regarder du côté de acme.sh pour un déploiement automatisé de certificat dans DSM (Certbot et donc SWAG par définition ne gère pas le déploiement dans DSM) :

Modifié par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

  • 4 semaines après...

Hello @.Shad.

Je me dis que je risque en fait pas grand chose à essayer ton tuto ^^ Au pire si ça ne fonctionne pas, je pourrais toujours remettre la redirection du port 443 vers le NAS plutôt que vers le conteneur SWAG.

PréScriptum : Je n'ai pas encore lu tout le tuto, donc il se peut qu'une des questions qui suit aie une réponse dans le tuto ^^ J'espère que tu m'en voudras pas ^^

Peux-tu juste me confirmer que je n'ai pas besoin de supprimer toutes les entrées du reverse-proxy de DSM pour que celles de SWAG fonctionnent ?

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

ATTENTION : Cette image ne permet pas de déployer automatiquement le certificat obtenu dans DSM à la manière dont le fait acme.sh (voir tutoriel de @Einsteinium pour une utilisation via Docker ou le tutoriel de @oracle7 pour les NAS incompatibles).

À propos de ça, j'ai mis en place la méthode de @Einsteinium pour mon nom de domaine à moi. Est-ce que ça continuera de fonctionner avec SWAG ?

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.