Aller au contenu

Messages recommandés

Posté(e)

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.

Posté(e)

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.

Posté(e)

Oui en effet, merci de la précision, je l'ajouterai au tutoriel.
Tu es un des rares (peut-être le seul) à avoir suivi le tutoriel, si tu as un feedback sur ce qui pourrait être amélioré n'hésite pas.

Posté(e) (modifié)

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
Posté(e) (modifié)

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.
Posté(e)

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.

  • 1 mois après...
Posté(e)

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)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Posté(e)

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...

Posté(e)
il y a 30 minutes, MilesTEG1 a dit :

Est-ce que parmi vous il y aurait des utilisateurs de Vaultwarden ?

Image 1.22.2. Pas de soucis chez moi je viens de le tester.

Posté(e)
il y a 22 minutes, Jeff777 a dit :

Image 1.22.2. Pas de soucis chez moi je viens de le tester.

Faut que je vérifie quelle version j’ai , mais normalement c’est la dernière hi que j’ai watchtower qui tourne .

Posté(e)
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 😉

Posté(e)

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...

Posté(e)

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...

Posté(e)
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🙄

Posté(e)

@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.

Posté(e)

Merci pour ta réponse .Shad.

mon problème devait venir de mon API OVH incomplète.

j'ai refait l'API puis en console j'ai fait un certbot renew et j'ai obtenu un nouveau certificat.

Posté(e)

Peut-être que tu n'avais pas mis un accès illimité pour l'API. Mais je pense que tu aurais eu un 503 Forbidden plutôt qu'un 504 Timeout.

Bref si c'est rentré dans l'ordre, tant mieux !

Posté(e)

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

 

Posté(e) (modifié)

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.
  • 4 semaines après...
Posté(e)

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 ?

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.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.