-
Compteur de contenus
6648 -
Inscription
-
Dernière visite
-
Jours gagnés
150
Tout ce qui a été posté par .Shad.
-
Non tu dois créer une base de donnée Calibre au préalable. Soit avec une application desktop soit via l'image Calibre (pas Calibre-Web).
-
Alertes de connexions NAS SSH IP inconnues
.Shad. a répondu à un(e) sujet de foxhidden dans Terminal Telnet et SSH
Non, si tu désactives le service tu ne devrais plus être capable de te connecter. As-tu tenté de redémarrer le NAS ? Normalement il n'y a pas besoin, mais pour peu qu'il y ait un bug temporaire ça pourrait le résoudre. Rien à voir avec l'application dont tu parles. l'uPnP c'est la possibilité pour les périphériques de demander au routeur ou box en amont d'ouvrir des ports à la demande quand ils en ont besoin. Là où ça peut être pratique pour des jeux en ligne par exemple (même s'il est toujours préférable de faire des redirections statiques via NAT), ça peut être très dangereux s'il est activé sur le NAS. Car n'importe quel malware s'y trouvant pourrait ouvrir les portes de ton réseau. A défaut de le désactiver sur ta box, tu peux le faire sur ton NAS, il n'y a pas d'option à proprement parler, tu dois juste t'assurer que ce cadre est vide de toute règle : -
Alertes de connexions NAS SSH IP inconnues
.Shad. a répondu à un(e) sujet de foxhidden dans Terminal Telnet et SSH
C'était aussi pour ça que je te demandais de mette une impression d'écran du pare-feu. Je le doutais que c'était la Cour des Miracles. 😉 Assure-toi de ne translater que ce dont tu as besoin depuis la box, donc 500, 4500 et 1194 (pas 1701). Assure-toi également que l'uPnP est désactivé sur ton ?AS, ça peut être la cause de l'accessibilité du port SSH depuis l'extérieur. -
@MilesTEG1 Ok merci pour ton retour, je vais tester ça je te tiens au courant. 😉
-
Alertes de connexions NAS SSH IP inconnues
.Shad. a répondu à un(e) sujet de foxhidden dans Terminal Telnet et SSH
Tu peux mettre une impression d'écran des règles du pare-feu de ton NAS ? -
Bienvenue parmi nous !
-
1. Qu'est-ce qu'Authelia ? Authelia est un serveur d'authentification open-source proposant une authentification unique ou à deux facteurs à la demande. C'est donc un moyen de venir appliquer une couche de sécurité supplémentaire sur une application critique ou sur une application qui en serait dépourvue d'élément d'authentification. L'authentification deux facteurs peut se faire via : TOTP (Time-based One-Time Password) : l'authentification à deux facteurs telle que Synology la propose, un code valable x secondes à valider après la saisie du mot de passe. Notifications PUSH : via l'application DuoAPI, on va pouvoir recevoir des notifications push sur notre téléphone pour valider la connexion. Clés de sécurité avec jeton type Yubikey. OpenID Connect (en beta) : Vous vous servez de votre ID OpenID pour vous connecter à vos applications. Seuls les points 1 et 2 seront développés dans ce tutoriel. 2. Prérequis Difficulté : moyenne-avancé Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker Avoir mis en place SWAG (proxy inversé multi-fonctionnel) dont un tutoriel de mise en route est disponible sur ce forum : Disposer d'une instance MySQL (ou MariaDB) Savoir se connecter en SSH en root Savoir éditer les différents fichiers de configuration par la méthode de votre choix (nano, vim, WinSCP, File Station, etc...) Utiliser Docker-compose NOTE : Certaines notions sont longuement explicitées dans le tutoriel pour la mise en place de SWAG, une double astérisque ** sera présente à côté des points concernés. 3. Principe Lorsque Nginx reçoit une requête vers exemple.ndd.tld et que ce sous-domaine est l'objet d'une entrée de proxy inversé, il vérifie si un appel à Authelia est demandé. Si c'est le cas, la demande est transférée à ce dernier, qui va exiger une authentification (ou pas) afin de poursuivre. Suivant les ACL (Access Control Lists) qu'on aura défini dans sa configuration, l'accès peut être : refusé autorisé autorisé sous réserve d'authentification par login et mot de passe autorisé sous réserve d'authentification à deux facteurs On peut donc en résumer le principe suivant ce schéma (dans notre cas, nous détaillerons l'installation pour Nginx uniquement, mais Traefik et HAProxy sont également compatibles) : Authelia doit être vu comme un complément de Nginx, même si les deux permettent un filtrage par ACL (et Nginx un blocage GeoIP de surcroît, qu'Authelia n'intègre pas). Il utilise le port 9091, qui n'est pas un port utilisé par défaut par DSM, comme pouvaient l'être les ports 80 et 443, raison pour laquelle SWAG est déployé sur un réseau macvlan. Il sera donc déployé sur un réseau bridge. 4. Hypothèses Quelques conventions pour s'y retrouver par la suite : IP de l'hôte : 192.168.1.100 IP virtuelle de l'hôte : : 192.168.1.200 Réseau bridge personnalisé : 172.25.0.0 Les commandes via SSH sont exécutées en tant que root. 5. Création d'un réseau bridge personnalisé A priori, on pourrait utiliser le réseau bridge par défaut (172.17.0.0/16), néanmoins afin de garantir un minimum de changement au cas où vous souhaiteriez utiliser Redis (voir fonctionnalités avancées) en conjonction avec Authelia, on va créer un réseau bridge personnalisé qui facilitera la communication inter-conteneurs. mkdir -p /volume1/docker/networks && cd $_ nano net-db.sh On y insère le code suivant : docker network create -d bridge \ --subnet=172.25.0.0/16 \ --gateway=172.25.0.1 \ --opt "com.docker.network.bridge.name"="br_net-db" \ net-db On rend le script exécutable : chmod u+x net-db.sh On l'exécute : bash net-db.sh Si la commande se termine avec succès, un identifiant composé de lettres et de chiffres s'affiche à l'écran. 6. Installation 6-A. Fichier docker-compose Voici une proposition de fichier docker-compose adapté aux versions 2.x, libre à vous de vous inspirer de ce qui est recommandé dans la documentation d'Authelia : version: '2.1' services: authelia: image: authelia/authelia container_name: authelia networks: - net-db environment: - AUTHELIA_JWT_SECRET_FILE=/config/secrets/jwt - AUTHELIA_STORAGE_MYSQL_PASSWORD_FILE=/config/secrets/mysql - AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE=/config/secrets/smtp - AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE=/config/secrets/encryption - TZ=Europe/Brussels ports: - 9091:9091/tcp volumes: - /volume1/docker/authelia/config:/config restart: unless-stopped networks: net-db: external: true NOTE : Pour l'instant on ne crée pas le conteneur via la commande docker-compose, cela n'interviendra que bien plus tard. 6-B. Secrets Authelia ne permet pas de stocker des credentials (login et mot de passe) directement en clair dans les variables, ni même dans un fichier .env. On peut donc soit utiliser la fonctionnalité secrets de Docker (compatible sur les implémentations de Docker pour DSM 7 et +), soit définir les variables dans des fichiers et les monter au moyen de variables d'environnement, c'est cette seconde méthode que nous privilégierons (voir docker-compose ci-avant). On crée les dossiers où seront stockées nos données en s'y plaçant dans la foulée : mkdir -p /volume1/docker/authelia/config/secrets && cd $_ Puis on crée les fichiers contenant les mots de passe que le fichier de configuration d'Authelia utilisera. N'hésitez pas à utiliser des mots de passe longs (privilégiez la longueur du mot de passe sur la présence abusive de caractères spéciaux). 30 caractères par exemple est une valeur satisfaisante : echo 'MOT_DE_PASSE_1' > jwt echo 'MOT_DE_PASSE_2' > mysql ## Le mot de passe pour MySQL doit conteneur au moins 1 caractere special !! echo 'MDP_SMTP_MAIL' > smtp ## Correspond au mot de passe du serveur SMTP qu'Authelia utilisera echo 'MOT_DE_PASSE_3' > encryption ## Minimum 20 caracteres, idealement 64 On vérifie la présence de nos fichiers : ls -l Ce qui devrait vous donner ceci : total 12 -rwxr-xr-x+ 1 root root 31 Jul 25 00:15 jwt -rwxr-xr-x+ 1 root root 31 Jul 25 00:16 mysql -rwxr-xr-x+ 1 root root 14 Jul 26 00:09 smtp -rwxr-xr-x+ 1 root root 14 Jul 26 00:09 encryption Comme on peut le constater, malgré le fait que les fichiers appartiennent à l'utilisateur et au groupe root, DSM applique ses ACL (le "+" à la fin des permissions UNIX), ce qui fait que n'importe quel utilisateur possédant des droits de lecture et ou d'écriture dans le dossier partagé docker pourra consulter le contenu de ces fichiers. On sécurise donc les fichiers : chmod 660 ./* chown your-personal-user:root ./* NOTE : Il faut évidemment remplacer l'utilisateur your-personal-user par l'utilisateur dont vous souhaitez qu'il soit propriétaire des dits fichiers. 6-C. Configuration 6-C-1. Génération du fichier configuration.yml d'Authelia On va exécuter une première fois le conteneur, qui s'arrêtera aussitôt, mais dont l'exécution permettra de générer un fichier de configuration, il a l'avantage d'être entièrement commenté et vous sera d'une aide précieuse si vous souhaitez creuser plus amplement les possibilités d'Authelia. On exécute la commande suivante : docker run --rm -v /volume1/docker/authelia/config:/config authelia/authelia A la suite de quoi on a un fichier configuration.yml dans /volume1/docker/authelia/config 6-C-2. Préparation de SWAG Le cadre d'utilisation par défaut prévu pour SWAG est d'être dans le même réseau bridge personnalisé qu'Authelia, ce n'est pas le cas ici vu que SWAG est déployé sur un réseau macvlan. 6-C-2-a. Modification de la configuration serveur On va devoir éditer les fichiers de configuration pour Authelia dans SWAG, notamment le fichier authelia-server.conf : cd /volume1/docker/swag/config/nginx && nano authelia-server.conf Ce qui donne : ## Version 2021/05/28 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/authelia-server.conf # Make sure that your authelia container is in the same user defined bridge network and is named authelia location ^~ /authelia { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_authelia 192.168.1.200; ## On remplace "authelia" par l'IP virtuelle du NAS proxy_pass http://$upstream_authelia:9091; } location = /authelia/api/verify { internal; if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) { return 401; } include /config/nginx/resolver.conf; set $upstream_authelia 192.168.1.200; ## On remplace "authelia" par l'IP virtuelle du NAS proxy_pass_request_body off; proxy_pass http://$upstream_authelia:9091; proxy_set_header Content-Length ""; [...] } ATTENTION : Avec DSM 7, les appels API pour le bureau DSM comprennent des caractères normalement ignorés par Authelia (des accolades), il faut les ajouter dans la ligne : if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) { devient if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]\{\}]) { On valide les modifications. 6-C-2-b. Modification des entrées de proxy inversé** Pour que Nginx prenne Authelia en compte, il suffit d'éditer une entrée de proxy inversé existante, et de décommenter les deux lignes suivantes : #include /config/nginx/authelia-server.conf; [...] #include /config/nginx/authelia-location.conf; Il faudra ensuite que le domaine correspondant à cette entrée soit pris en charge dans les ACL d'Authelia (voir point 6-C-3-f.) 6-C-2-c. Création d'entrée pour Authelia** On va également en profiter pour créer une entrée de proxy inversé pour la page d'Authelia, dont on va se servir pour configurer nos accès : cd /volume1/docker/swag/config/nginx/proxy-confs cp authelia.subdomain.conf.sample authelia.subdomain.conf nano authelia.subdomain.conf Puis on adapte à notre besoin : ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. server { listen 443 ssl; listen [::]:443 ssl; server_name authelia.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.1.200; ## On utilise l'IP virtuelle du NAS set $upstream_port 9091; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } _______________________ Une fois ceci fait, on redémarre le conteneur SWAG, on n'aura plus besoin d'y toucher. docker restart swag 6-C-3. Personnalisation du fichier de configuration d'Authelia Le fichier regorge d'options, parcourons-le donc et voyons ce qu'il convient de faire au fur et à mesure. Les parties que je ne mentionne pas ne sont pas sensées être modifiées (du moins pour l'application qu'on en fera ici (voir la documentation pour une utilisation plus experte)) ou ont un intérêt évident/trivial (theme par exemple). 6-C-3-a. server # Configuration options specific to the internal http server server: [...] path: "authelia" Donner la valeur "authelia" à path est un prérequis du bon fonctionnement de l'application suivant la configuration embarquée dans SWAG. 6-C-3-b. log log: level: info [...] file_path: /config/logs/authelia.log keep_stdout: true Le niveau info est déjà suffisamment verbeux, n'utiliser debug ou trace qu'en cas de problème à résoudre. Pour file_path et keep_stdout : préférence personnelle, j'aime bien avoir un fichier log, et garder pour autant l'output sur les logs du conteneur. Faites comme il vous plaît. 6-C-3-c. jwt_secret jwt_secret: Il est important de noter que jwt_secret n'ait aucune valeur, afin que le secret défini dans le fichier jwt soit pris en compte. Si vous laissez la chaîne de caractères par défaut "a_very_important_secret", le contenu du fichier jwt ne sera pas utilisé. NOTE : Cette remarque est valable pour toutes les autres clés faisant appel au contenu des fichiers définis par avant (jwt, mysql, etc...). 6-C-3-d. default_redirection_url default_redirection_url: https://ndd.tld Authelia est directement accessible par proxy inversé, c'est un des templates de fichier conf de SWAG. Lorsque vous vous identifierez sur cette page, vous serez redirigé vers la page définie par default_redirection_url. 6-C-3-e. authentication_backend Deux possibilités existent : l'utilisation d'un annuaire LDAP ou un fichier d'utilisateurs défini localement. Nous utiliserons la seconde option. Il faut par conséquent commenter toutes les clés, listes, etc... liées à la configuration du serveur LDAP : ## ## LDAP (Authentication Provider) ## ## This is the recommended Authentication Provider in production ## because it allows Authelia to offload the stateful operations ## onto the LDAP service. # ldap: [...] # implementation: custom [...] # url: ldap://127.0.0.1 ## Use StartTLS with the LDAP connection. # start_tls: false # tls: [...] # skip_verify: false ## Minimum TLS version for either Secure LDAP or LDAP StartTLS. # minimum_version: TLS1.2 [...] # base_dn: dc=example,dc=com [...] # additional_users_dn: ou=users [...] # users_filter: (&({username_attribute}={input})(objectClass=person)) [...] # additional_groups_dn: ou=groups [...] # groups_filter: (&(member={dn})(objectclass=groupOfNames)) [...] ## The username and password of the admin user. # user: cn=admin,dc=example,dc=com # password: password Nous utiliserons la deuxième option disponible : la définition locale d'utilisateurs dans une liste, cela se fait au moyen d'un fichier users_database.yml. On utilise le modèle disponible sur GitHub : cd /volume1/docker/authelia/config wget https://raw.githubusercontent.com/authelia/authelia/master/examples/compose/local/authelia/users_database.yml Qu'on personnalisera de la sorte : --- ############################################################### # Users Database # ############################################################### # This file can be used if you do not have an LDAP set up. # List of users users: toto: displayname: "Thomas" password: "$argon2id$v=19$m=65536,t=1,p=8$VmFaM3FKckFRZVY5TUJ5eg$81mBJ3QSw8WQM2rm4yNJeS7j2YQMra183gHCxGALOAs" email: mail@ndd.tld groups: [] # - admins # - dev ... toto sera le nom d'utilisateur qui sera utilisé pour l'authentification simple ou double facteur. De préférence choisissez un nom d'utilisateur plus long et complexe. 🙂 Thomas sera le nom d'affichage. <PASSWORD> sera le mot de passe utilisé pour s'authentifier, mais il ne sera pas lisible en clair, Authelia utilise un algorithme de chiffrement en ce sens. On va utiliser la commande suivante : docker run --rm authelia/authelia:latest authelia hash-password 'MOT_DE_PASSE' Suivant votre modèle de NAS et la complexité de votre mot de passe, cette opération pourrait prendre un certain temps, mais à la fin de quoi vous devriez obtenir un renvoi de la sorte : $argon2id$v=19$m=65536,t=1,p=8$aC8raDhGRWh4eDlmRmp5aw$PsiuwaVbWsXkIThpLLeI3JZdT3NCe3CUeAXORQzsSpg C'est cette ligne qu'il vous faut mettre à la place de <PASSWORD>. Pour l'email, c'est l'adresse qui sera utilisée en cas de demande de renouvellement de mot de passe, etc..., à personnaliser. Pour les groupes, je conseille de ne pas vous en servir dans un premier temps, il vous suffit de modifier ainsi : groups: [] # - admins # - dev NOTE : Le fichier ne donnant pas d'information sensible, et afin de permettre aux différents utilisateurs de modifier éventuellement leur mot de passe, on peut laisser les permissions par défaut (celles de DSM avec les ACL). _______________________ On décommente la section file : authentication_backend: # Disable both the HTML element and the API for reset password functionality disable_reset_password: false [...] refresh_interval: 5m [...] file: path: /config/users_database.yml password: algorithm: argon2id iterations: 1 key_length: 32 salt_length: 16 memory: 1024 parallelism: 8 6-C-3-f. access_control Une des parties les plus importantes, elle concerne les contrôles d'accès et la manière dont Authelia va se comporter en fonction de l'IP d'origine et le domaine demandé lors de la requête. Pour plus d'information, la documentation est consultable à cette adresse. On va se placer dans le cas (pour exemple) où on autorise tous les accès en local et VPN, et on limite ensuite de façon granulaire au gré des sous-domaines : access_control: # Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'. # It is the policy applied to any resource if there is no policy to be applied # to the user. default_policy: deny networks: - name: local networks: # LAN network - 192.168.1.0/24 # Docker network - 172.16.0.0/12 - name: openvpn networks: # OpenVPN subnet - 10.0.8.0/24 rules: # Bypass 2FA when connected to VPN on pfSense or being connected to the LAN - domain: - ndd.tld - "*.ndd.tld" policy: bypass networks: - local - openvpn # Open public access - domain: - public.ndd.tld - public2.ndd.tld policy: bypass # Single authentication for applications lacking authentication system - domain: semi-private.ndd.tld policy: one_factor # 2FA for sensitive services - domain: private.ndd.tld policy: two_factor NOTES : Dans la partie networks, on définit des alias pour faciliter la définition des règles et rendre moins fastidieuse leur rédaction. Dans la partie rules, je définis les sites qui auront un accès publique (sans protection supplémentaire que celle dont ils disposent déjà), ceux qui devront faire l'objet d'une simple authentification, et ceux qui doivent être soumis à la 2FA. Si l'accès à un sous-domaine vous est refusé sans raison, c'est qu'aucune des règles définies ne répond à la situation présente, dans ce cas Authelia rejette la demande (par le paramètre default_policy: deny). Vous pouvez temporairement ne pas mettre "*.ndd.tld" dans les domaines by-passés, le temps de mettre en route Authelia. Ou alors faire le test d'authentification depuis une connexion 4G. 6-C-3-g. session session: ## The name of the session cookie. name: authelia_session [...] domain: ndd.tld On pensera à renseigner le domaine racine qu'on souhaite protéger dans la valeur de la clé domain. ATTENTION : Authelia ne peut pas protéger plusieurs domaines racines simultanément. La mise en place de Redis est détaillée dans la partie Fonctionnalités avancées, on va s'en passer pour notre cas d'utilisation et commenter les paramètres qui y ont trait : ## ## Redis Provider ## ## Important: Kubernetes (or HA) users must read https://www.authelia.com/docs/features/statelessness.html ## # redis: # host: 127.0.0.1 # port: 6379 ## Use a unix socket instead # host: /var/run/redis/redis.sock ## Username used for redis authentication. This is optional and a new feature in redis 6.0. # username: authelia ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html # password: authelia ## This is the Redis DB Index https://redis.io/commands/select (sometimes referred to as database number, DB, etc). # database_index: 0 ## The maximum number of concurrent active connections to Redis. # maximum_active_connections: 8 ## The target number of idle connections to have open ready for work. Useful when opening connections is slow. # minimum_idle_connections: 0 6-C-3-h. storage Depuis la version 4.33.0 d'Authelia, il est nécessaire de définir une clé de chiffrement (encryption key) pour éviter les corruptions de base de données. C'est la chaîne de caractères définie dans le fichier encryption créé plus tôt (voir les prérequis ici : https://www.authelia.com/configuration/storage/introduction/#encryption_key) storage: ## The encryption key that is used to encrypt sensitive information in the database. Must be a string with a minimum ## length of 20. Please see the docs if you configure this with an undesirable key and need to change it. encryption_key: ## ## MySQL / MariaDB (Storage Provider) ## mysql: host: 192.168.1.200 port: 3307 database: authelia username: authelia ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html password: Par défaut, Authelia suggère d'utiliser MySQL, ce que nous allons faire car le paquet MariaDB 10 est disponible dans le centre de paquets. On spécifie l'IP virtuelle du NAS, ainsi que le port de MariaDB (3307 pour MariaDB 10). On se connecte ensuite à phpMyAdmin (paquet) via le menu DSM avec le compte root, et on crée notre utilisateur : On choisit un nom d'utilisateur, on reprend le mot de passe défini dans le fichier mysql créé précédemment et on coche "Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base." On clique sur Exécuter en bas à droite de la page, si l'opération est un succès vous verrez le contenu de la requête affiché en vert dans le haut de la page. Notre base de données est maintenant prête à accueillir les données d'Authelia. 6-C-3-i. notifier notifier: ## You can disable the notifier startup check by setting this to true. disable_startup_check: false [...] smtp: username: mail@ndd.tld ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html password: host: ssl0.ovh.net port: 587 sender: mail@ndd.tld ## HELO/EHLO Identifier. Some SMTP Servers may reject the default of localhost. identifier: localhost ## Subject configuration of the emails sent. {title} is replaced by the text from the notifier. subject: "[Authelia] {title}" ## This address is used during the startup check to verify the email configuration is correct. ## It's not important what it is except if your email server only allows local delivery. startup_check_address: mail@ndd.tld disable_require_tls: false disable_html_emails: false [...] ## Sending an email using a Gmail account is as simple as the next section. ## You need to create an app password by following: https://support.google.com/accounts/answer/185833?hl=en # smtp: # username: myaccount@gmail.com # ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html # password: # sender: myaccount@gmail.com # host: smtp.gmail.com # port: 587 Authelia propose par défaut l'utilisation d'un SMTP externe (type OVH dans l'exemple ci-dessus) ou de passer par un compte Gmail. Dans ce dernier cas, pensez à autoriser les applications moins sécurisées dans les réglages de votre compte Google, sinon l'envoi de mails ne se fera pas. 7. Création et utilisation du code TOTP Le plus dur est fait, il reste maintenant à se logger avec le compte qu'on a créé, on va sur la page https://authelia.ndd.tld (on s'assurera que l'entrée DNS de type A ou CNAME existe déjà, en local ou/et publique) : On entre le nom de l'utilisateur, ici toto, et le mot de passe qu'on lui a attribué. On clique sur Sign In, on arrive sur la page suivante : En cliquant sur Not registered yet?, un email sera envoyé à l'adresse renseignée pour l'utilisateur toto dans le fichier users_database.yml. Dans ce mail, on clique sur l'hyperlien Register, qui nous amène à une page avec un QR-CODE. Si vous possédez déjà une application 2FA, il vous suffit de scanner le code. Sinon vous pouvez suivre les liens pour Play Store et iOS. A titre personnel, j'utilise andOTP sur Fdroid, le store alternatif pour Android. Une fois le code ajouté dans l'application, il suffit de cliquer sur Done et on peut se connecter : Si le code est bon, vous verrez le statut authentifié en vert, et vous serez redirigé vers la page que vous aviez précédemment définie dans default_redirection_url au point 6-C-3-d. Maintenant, vous pouvez accéder à toutes vos applications en choisissant vous-même le curseur de sécurité. 😉 8. Fonctionnalités avancées 8-A. Redis A venir... 8-B. DuoAPI A venir... 9. FAQ Q : J'ai perdu le mot de passe de mon utilisateur, comment retrouver l'accès à mes sous-domaines ? A : A l'écran de login, vous pouvez cliquer sur Reset password?. Q : J'ai perdu mon code accès TOTP, que faire ? A : Une fois loggé, vous pouvez cliquer sur Lost your device?. Vous recevrez alors un mail vous proposant un nouveau QR-CODE. Q : Puis-je désactiver la possibilité pour les utilisateurs de récupérer leur mot de passe ? A : Oui, il faut modifier la valeur de la clé disable_reset_password dans la section authentication_backend à true. Q : J'obtiens une erreur 502 en accédant à mes entrées de proxy inversé, pourquoi ? A : Il y a plusieurs raisons possibles, mais dans le cas présent il se peut que l'interface virtuelle du NAS ait disparu, suite à un arrêt, un redémarrage ou une mise à jour du paquet Docker. Vous avez normalement déjà mis en place un script qui permet de la recréer automatiquement au démarrage du NAS. Mais en cas de perte de l'interface il faudra simplement relancer la tâche manuellement depuis le planificateur de tâches. Màj : 07/08/2023
-
Bienvenue parmi nous !
-
Comme @oracle7 je n'irais pas monter la répertoire contenant la bdd calibre en lecture seule. A toi de faire des sauvegardes régulières et de restaurer au besoin. Pour Calibre-web, les informations liées fonctionnalités comme lu/non-lu, etc... sont stockées dans la base de données SQLite embarquée. Ca n'interfère en rien avec les fichiers créés par Calibre. Dernière chose, il y a moyen d'instaurer une synchronisation entre Calibre-Web et une Kobo ou une Kindle. J'ai l'ancienne Kobo de ma femme avec laquelle je dois essayer de le mettre en place, j'avais lu sur GitHub que c'était encore assez expérimental il y a quelques mois, il faudrait que je regarde de nouveau. Ca implique que tu désynchronises la liaison par contre avec le magasin Kobo (que j'imagine tu n'utilises pas des masses 😄).
-
J'avais testé cette fonctionnalité, je n'ai pas réussi à isoler les livres de ma femme des miens. Si tu y arrives il faudra m'expliquer. 😉 Pour le reste, voir la réponse de @oracle7
-
PLEX et PHOTO
.Shad. a répondu à un(e) sujet de _DR64_ dans Installation, Démarrage et Configuration
Perso je ne regarde jamais des photos sur la TV. Après il faudrait quand même qu'ils sortent l'application pour Android TV hein, mais c'est pas forcément l'utilisation la plus classique je pense. -
Bienvenue parmi nous, en espérant que tu trouves réponses à tes questions. 🙂
-
Je pense pas qu'on soit beaucoup à utiliser cette nouvelle fonctionnalité. Si tu n'es pas allergique à l'anglais je t'invite à regarder sur Reddit : https://www.reddit.com/r/synology/search/?q=signin&restrict_sr=1
-
Je n'ai pas vu de serveur mail embarqué, mais tu as ce mod qui a l'air bien foutu : https://github.com/linuxserver/docker-mods/tree/swag-f2bdiscord
-
PLEX et PHOTO
.Shad. a répondu à un(e) sujet de _DR64_ dans Installation, Démarrage et Configuration
Comme ça, je n'ai pas d'autre idée malheureusement. -
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. 😉
-
PLEX et PHOTO
.Shad. a répondu à un(e) sujet de _DR64_ dans Installation, Démarrage et Configuration
Donc c'est bien au niveau de Docker que ça coince et pas Plex. J'ai par le passé essayer de monter le dossier photo dans Emby via Docker et ça marchait très bien. Par défaut, ton utilisateur plex du NAS fait partie du groupe users, comme tous les utilisateurs, est-ce que tu n'as pas mis une interdiction sur ce dossier à ce groupe ? Parce que même si tu utilises un PUID et un PGID personnalisés, dont la combinaison assure l'accès au dossier photo, ton utilisateur fait que tu le veuilles ou non partie du groupe users, et toute interdiction au niveau de ce groupe entrainera ce type de disfonctionnement. -
[TUTO] Certificat Let's Encrypt avec acme.sh & api Ovh en Docker (DSM6/7) (Update 07/09/22)
.Shad. a répondu à un(e) sujet de Einsteinium dans Tutoriels
Ça explique peut-être pourquoi ces derniers jours je n'ai pas réussi à mettre en place un renouvellement de certificat pour un bureau distant. J'avais bien "the API call has not been granted". J'ai recommencé 3 fois les accès API pensant que je faisais des erreurs... Je vais suivre tout ça. -
Release candidate disponible \o/ Version: 7.0-41882
.Shad. a répondu à un(e) sujet de Einsteinium dans Firmwares
Le reset mode 2 supprime toute la configuration. Mais ne touche pas aux données des disques. En revanche il est toujours conseillé de faire une sauvegarde de tes données importantes avant d'y recourir. -
Release candidate disponible \o/ Version: 7.0-41882
.Shad. a répondu à un(e) sujet de Einsteinium dans Firmwares
C'est quand même très étrange car on est très nombreux à être passés sous DSM 7 sans problème de la sorte. Je pense que quand tu arriveras à passer en version finale, ça pourrait se débloquer. -
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.
-
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.
-
Release candidate disponible \o/ Version: 7.0-41882
.Shad. a répondu à un(e) sujet de Einsteinium dans Firmwares
Peut-être simplement désactiver et réactiver le service SMB via DSM ? Ca peut paraître trivial, mais parfois... -
PLEX et PHOTO
.Shad. a répondu à un(e) sujet de _DR64_ dans Installation, Démarrage et Configuration
En SSH sur le NAS : docker exec -it plex ls -l /data/photos plex étant le nom du conteneur. -
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 : 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.