Contrôle d'accès IP sur Nginx Streaming : une solution légère en Docker
Salut à tous les passionnés de streaming et de Docker ! Aujourd’hui, je souhaite partager avec vous une solution que j’ai mise en place pour résoudre un problème auquel j’ai été confronté : l’utilisation des access lists sur les flux avec Nginx Proxy Manager. Si vous avez cherché une façon de contourner cette limitation, vous êtes au bon endroit ! J’ai développé une solution pratique et je suis ravi de la partager avec vous.
Use case
Imaginez que vous utilisez Nginx Proxy Manager pour gérer vos flux de streaming. C’est un outil fantastique qui facilite la configuration de serveurs reverse proxy et de redirections. Cependant, vous avez peut-être remarqué qu’il ne prend pas en charge les access lists sur les flux. Cela signifie que vous ne pouvez pas contrôler précisément quelles adresses IP sont autorisées ou refusées sur vos flux. C’est là que ma solution entre en jeu.
J’ai développé une image Docker qui vous permet de configurer un serveur de streaming Nginx avec un contrôle d’accès IP sur les flux. Grâce à cette image Docker, vous pouvez facilement gérer les adresses IP autorisées et bloquées pour garantir la sécurité de votre serveur de streaming. Voyons maintenant comment cela fonctionne.
Cas pratique
Supposons que vous souhaitiez autoriser uniquement deux adresses IP spécifiques (192.168.0.100 et 2001:0db8:85a3:0000:0000:8a2e:0370:7334) à accéder à votre flux de streaming. De plus, vous souhaitez rediriger ce flux vers un autre serveur situé à l’adresse 10.0.0.5:8000. Voici comment vous pouvez utiliser mon image Docker pour mettre cela en place :
docker run -d \
-p 8000:9000 \
-e ALLOWED_IPS="192.168.0.100,2001:0db8:85a3:0000:0000:8a2e:0370:7334" \
-e PROXY_PASS="10.0.0.5:8000" \
kevindesousa:net-stream-security:latest
Maintenant, seules les adresses IP autorisées pourront accéder à votre flux de streaming, et le trafic sera redirigé vers l’adresse spécifiée.
Conclusion
Grâce à cette image, vous pouvez facilement configurer un serveur de streaming Nginx avec un contrôle d’accès IP sur les flux. Vous avez maintenant le pouvoir de décider quelles adresses IP sont autorisées à accéder à votre flux de streaming, offrant ainsi une couche de sécurité supplémentaire. N’oubliez pas d’adapter les adresses IP et les ports selon vos besoins spécifiques.
J’espère que cette solution vous sera utile dans votre utilisation de Nginx Proxy Manager ou autre. Et maintenant, à vous de jouer !
Si vous souhaitez apporter des modifications ou faire des remarques, n’hésitez pas à le faire :
Utiliser sa clef FIDO2 pour sécuriser son accès SSH
Un grand merci à MaxBlog pour son article inspirant sur l’utilisation de YubiKey avec SSH. J’ai trouvé de précieuses informations et des conseils pratiques qui m’ont permis d’approfondir mes connaissances. Consultez l’article original de MaxBlog dont je me suis très grandement inspiré : https://blog.maxds.fr/ssh-with-yubikey/.
Merci à MaxBlog pour le partage de son savoir !
FIDOQWA ? 🤨
Salut à toi, passionné de technologie !
Aujourd’hui, je t’invite à découvrir une technologie fascinante qui pourrait bien changer la façon dont tu sécurises ton accès SSH : les clés FIDO2 (Fast Identity Online). Respectant les spécifications de pointe de la FIDO Alliance, ces petits bijoux offrent une sécurité avancée et une expérience utilisateur simplifiée.
Dans cet article, je vais te présenter les bases de cette technologie prometteuse. Imagine-toi te connecter sans te soucier des mots de passe complexes ! Je vais te montrer une méthode pratique pour déverrouiller ton accès SSH en toute sécurité, sans les tracas habituels.
Accompagne-moi dans cette exploration, et découvre comment les clés FIDO2 peuvent rendre ta vie technologique plus agréable et sécurisée. Je vais t’offrir un survol clair et accessible pour que tu puisses saisir les avantages de cette solution.
Alors, es-tu prêt à te plonger dans l’univers des clés FIDO2 ? Accroche-toi, car je vais t’accompagner dans cette aventure captivante !
En route vers une expérience de sécurité simplifiée et prometteuse ! 😄✨
Pourquoi je devrai utiliser une clef ?
Laisse-moi te convaincre de l’importance d’utiliser une clé pour l’accès SSH. Accroche-toi, car voici pourquoi ça va tout changer !
D’abord, l’ANSSI est catégorique : l’utilisation d’une paire de clés cryptographiques asymétriques est vivement recommandée. Ils savent de quoi ils parlent, ces experts de la sécurité ! Voici les méthodes de chiffrement, par ordre de préférence :
- Cryptographie asymétrique ECDSA : La crème de la crème, mon pote !
- Cryptographie asymétrique RSA : Une valeur sûre, indémodable.
- Cryptographie symétrique : Pour un équilibre parfait entre sécurité et performance.
- Utilisation d’un module tiers, comme PAM / BSD Auth : Pour ceux qui aiment sortir des sentiers battus.
- Mot de passe : Franchement, évite-le, surtout si tu as des privilèges élevés sur le système. C’est has-been !
📝 Une règle d’or à retenir : si tu as des privilèges élevés, oublie le mot de passe, c’est comme porter des chaussettes dans le sable !
Alors, dis adieu aux mots de passe laborieux et adopte la clé pour tes accès SSH ! Tu vas gagner en sécurité et en tranquillité d’esprit. Maintenant, attache ta ceinture, car on poursuit la lecture de cet article palpitant ! 😉🔒
💊 Rouge ou 💊 Bleue ?
Lorsque nous créons notre première clé SSH dans notre fidèle Yubikey, il est crucial de faire un choix : la 💊 rouge ou la 💊 bleue ? Suis-moi, je t’emmène dans le terrier du lapin blanc 🐰 pour découvrir les différences entre ces deux types de clés.
Clé résidente : Une clé dans la matrice
La clé résidente est stockée uniquement dans ta Yubikey. Ce type de clé est recommandé si tu veux pouvoir te connecter depuis n’importe quel ordinateur. La simple possession de ta Yubikey te permettra d’accéder à notre serveur SSH distant sans soucis.
Clé partagée : Une alliance puissante
La clé partagée est une combinaison entre ta Yubikey et un fichier stocké sur ton ordinateur. Ce fichier seul ne permet pas l’authentification auprès d’un serveur SSH. Il est considéré comme une clé privée enregistrée dans le répertoire ~/.ssh/
, mais protégée par une passphrase. Dans ce cas, la Yubikey joue le rôle de la “passphrase” (c’est une analogie, la réalité est un peu différente). Attention, la seule possession de la Yubikey ne sera pas suffisante pour s’authentifier auprès de notre serveur SSH distant.
Ce mode de connexion est le plus sécurisé, mais il est aussi plus restrictif. Il nécessite la présence des deux éléments : ta Yubikey et le fichier associé. Cela peut devenir un peu plus complexe lors de l’utilisation d’un nouvel ordinateur, par exemple.
Il est temps de faire ton choix entre la clé résidente et la clé partagée. 🗝️✨
Génération de la clé résidente : Faisons chauffer les claviers ! 💻
Pour créer une clé de type résidente, il te suffit de taper la commande suivante :
ssh-keygen -t ed25519-sk -O "resident" -O "application=ssh:principal" -N "" -f ~/.ssh/yubikey_01
Une fois cette commande exécutée, l’utilitaire te demandera ton code PIN. N’oublie pas de valider en appuyant sur la touche de ta Yubikey.
Voici ce que signifient les différents paramètres de la commande :
-t ed25519-sk
: indique le format de la clé basée sur les courbes elliptiques ed25519.-O resident
: cette option te permet de choisir le type de clé (résidente dans notre cas).-f ~/.ssh/yubikey_01
: définit le fichier descriptif associé à la clé résidente.-O application=ssh:<nom_application>
: il est possible d’enregistrer jusqu’à 25 clés résidentes dans ta clé physique. Cette option te permet de donner un nom à chacune d’entre elles.-N ""
: définit une passphrase vide, car la clé privée reste dans ta Yubikey.
🚨 Attention ! Si tu ne définis pas l’option application=ssh:<nom_application>
, tu risques de créer une clé qui portera simplement le nom “ssh:”. Dans ce cas, tu pourrais écraser par mégarde ta clé résidente si tu réexécutes la commande sans préciser le nom de l’application. Il est donc conseillé d’utiliser toujours un nom d’application qui a du sens. Par exemple : ssh:gitlab
, ssh:production
, ssh:crypto
.
Pour vérifier que la clé a été créée avec succès, utilise la commande suivante :
ykman fido credentials list
Tu devrais désormais voir une clé SSH présente dans ta Yubikey, du type :
ssh:principal 0000000000000000000000000000000000000000000000000000000000000000 openssh
C’est la preuve que ta clé résidente est prête à être utilisée pour tes connexions SSH sécurisées. 🚀💪
Laissez votre empreinte sur le serveur distant !
Maintenant que tu as généré votre clé, passons à l’étape suivante : copier le contenu de votre clé publique sur le serveur distant. Cette opération ne sera nécessaire qu’une seule fois. Tu as deux options :
[Recommandé] Si tu as un accès distant au serveur (connexion SSH avec mot de passe, fichier de clé existant, etc.), tu peux utiliser la commande suivante pour simplifier le processus. Cela écrira automatiquement votre clé publique dans le fichier ~/.ssh/authorized_keys de votre compte utilisateur sur le serveur distant.
ssh-copy-id -i ~/.ssh/yubikey_principale -p 22 <utilisateur_distant>@<serveur_distant>
Si tu as un accès local au serveur, tu peux éditer le fichier ~/.ssh/authorized_keys
directement sur le serveur (assurez-vous que les droits sont définis à 600), puis y ajouter manuellement le contenu de votre clé publique qui se trouve dans le fichier ~/.ssh/yubikey_01.pub
. Assurez-vous que le contenu commence par [email protected] AAAA...
suivi de l’empreinte de votre clé.
Maintenant, prenez une profonde inspiration, soufflez lentement et admirez votre clé publique résider fièrement sur le serveur distant. 🚀💥
Nouveau PC, nouvelle aventure : Génération du fichier descriptif !
Si tu te trouves sur un nouveau PC et que tu souhaites utiliser ta Yubikey pour les connexions SSH, pas de panique ! Tu peux facilement générer le fichier descriptif associé à ta Yubikey en suivant ces étapes :
Tout d’abord, ouvre ton terminal et assure-toi d’être dans le répertoire souhaité ~/.ssh
.
Ensuite, lance la commande suivante :
ssh-keygen -K
Cette commande va régénérer le fichier descriptif associé à votre Yubikey dans le répertoire ~/.ssh
. Il sera nommé id_ed25519_sk_rk_principale
, et la clé publique associée sera créée sous le nom id_ed25519_sk_rk_principale.pub
.
Pour plus de commodité, tu peux renommer ces fichiers selon tes préférences en utilisant la commande mv
. Par exemple, tu peux les renommer en yubikey_01
et yubikey_01.pub
:
mv id_ed25519_sk_rk_principale ~/.ssh/yubikey_01
mv id_ed25519_sk_rk_principale.pub ~/.ssh/yubikey_01.pub
Maintenant, tu disposes du fichier descriptif associé à votre Yubikey, prêt à être utilisé pour les connexions SSH sur ton nouveau PC. Tu es maintenant paré pour continuer ton périple sans souci de mot de passe et profiter de la sécurité renforcée offerte par ta clé résidente.
N’oublie pas de garder précieusement ta Yubikey à portée de main, car c’est ton sésame pour accéder à des connexions SSH sécurisées et sans tracas ! 🗝️🚀
Pour aller plus loin
Personnalisation de l’utilisateur
Lors de la génération de ta première clé, tu as obtenu un encodage hexadécimal de l’utilisateur, qui ressemble à ceci :
ssh:principal 0000000000000000000000000000000000000000000000000000000000000000 openssh
Malheureusement, cet encodage ne permet pas de visualiser directement le nom d’utilisateur de manière lisible. Mais ne t’inquiétes pas, tu peux ajouter des informations supplémentaires à votre clé en utilisant l’option user=
. Par exemple, si tu souhaites ajouter l’utilisateur foo
à cette clé, tu peux exécuter la commande suivante :
ssh-keygen -t ed25519-sk -O "resident" -O "application=ssh:principal" -N "" -f ~/.ssh/yubikey_01 -O user=foo
Maintenant, l’utilisateur foo
sera représenté par son encodage hexadécimal :
ssh:principal 666f6f0000000000000000000000000000000000000000000000000000000000 openssh
Suppression d’une clé résidente
Si tu souhaites supprimer une clé résidente, tu peux utiliser la commande suivante en spécifiant le nom de la clé ou son encodage hexadécimal, comme illustré ci-dessous :
ykman fido credentials delete "ssh:principal"
Si tu possédes plusieurs clés avec le même nom, il est nécessaire de spécifier un élément différenciant, tel que l’utilisateur encodé en hexadécimal :
ykman fido credentials delete "666f6f0000000000000000000000000000000000000000000000000000000000"
Suppression d’une clé spécifique
Supposons que tu as créé trois clés avec les noms ssh:
, ssh:principal
et ssh:secondaire
, et que tu souhaites supprimer uniquement la clé par défaut ssh:
tout en conservant les deux autres. Si tu rencontres l’erreur suivante lors de la suppression :
Error: Multiple matches, make the query more specific.
Ajoute simplement des guillemets doubles et un espace juste après le nom de la clé :
ykman fido credentials delete "ssh: "
Avec ces astuces supplémentaires, tu peux mieux gérer tes clés résidentes et personnaliser tes identifiants SSH pour une expérience plus adaptée à tes besoins. Continue à explorer les possibilités offertes par ta Yubikey et profite d’une sécurité renforcée dans tes connexions !
Plus de sécurité sur tes serveurs SSH
Une fois que tu as réussi à t’authentifier avec succès en utilisant la clé FIDO2, il est recommandé de désactiver complètement l’authentification par mot de passe sur tes serveurs SSH distant. Cette mesure renforcera la sécurité de votre machine distante et éliminera les risques liés aux attaques par dictionnaire. Cependant, assure-toi de mettre en place une méthode de connexion de secours au cas où tu perds ta clé matérielle.
Attention : Prend toutes les précautions nécessaires lors de cette procédure pour éviter de te bloquer totalement l’accès SSH.
Mise en place d’une connexion de secours
Voici quelques options possibles pour t’assurer une connexion de secours :
Accès physique ou connexion “serial” : Si possible, maintient un accès physique à la machine distante ou configure une connexion “serial” qui simule un clavier et un écran physiques. Cela vous permettra de vous reconnecter à distance en utilisant votre nom d’utilisateur et votre mot de passe.
Deuxième clé FIDO2 : Tu peux ajouter une deuxième clé FIDO2 et en conserver une en lieu sûr tandis que vous utilisez l’autre comme clé active.
Clé SSH traditionnelle : Tu as également la possibilité d’ajouter une clé SSH “traditionnelle” de type ed25519 pour disposer d’un accès de secours sécurisé. Assure-toi de conserver cette clé hors ligne, par exemple sur une clé USB ou dans un gestionnaire de mots de passe.
Désactiver l’authentification par mot de passe
Pour désactiver l’authentification par mot de passe sur tes serveurs SSH distant, suit les étapes ci-dessous :
Connecte-toi à ton serveur distant et ouvre le fichier /etc/ssh/sshd_config
.
Modifie les lignes suivantes comme suit :
#désactivation de l'utilisateur root
PermitRootLogin no
#désactivation de l'usage des mots de passe
PasswordAuthentication no
Si ton serveur distant est de type debian/ubuntu, redémarre le service sshd et vérifie que tu ne peux plus te connecter par mot de passe
sudo systemctl restart sshd
Débranche la Yubikey, et essayez de te connecter, tu devrais avoir le message suivant :
<utilisateur>@<serveur>: Permission denied (publickey).
Encore plus restrictif
Si tu choisis l’option d’avoir une seconde clef FIDO2, un paramètre supplémentaire te permet d’indiquer au serveur SSH d’autoriser uniquement les connexions du type FIDO2. Ainsi, même les clefs habituelles du type RSA, ed25519, etc.. ne seront pas acceptées !
Modifie/Ajoute la ligne suivante dans le fichier /etc/ssh/sshd_config
et redémarre le service sshd à nouveau.
# restriction des clefs SSH uniquement aux clefs matérielles du type FIDO2 U2F
PubkeyAcceptedKeyTypes [email protected],[email protected]
sudo systemctl restart sshd
Désormais seules les clefs FIDO2 U2F seront acceptées comme moyen d’authentification ! 🥳