Vue d'ensemble #
RAYON or Service d'utilisateur à distance pour authentification à distance est un protocole réseau qui fournit une authentification, une autorisation et une comptabilité des utilisateurs et une gestion centralisée des appareils. Il est largement utilisé par les fournisseurs d'accès Internet et les entreprises pour contrôler l'accès à Internet, aux services locaux, aux réseaux sans fil via des points d'accès WiFi, etc.
Le protocole RADIUS est implémenté dans la couche application avec une architecture client-serveur pouvant utiliser TCP ou UDP comme couche de transport et étant communiquée avec une base de données d'utilisateurs telle que Le tiering Active Directory, Service LDAP or Système de comptabilité Linux. Les solutions RADIUS les plus populaires sont FreeRadius ou Microsoft NPS Radius Server.
Protocole de messagerie RADIUS #
La messagerie de protocole est basée sur la demande du client et la manière de réponse du serveur comme indiqué ci-dessous.
1. Le client envoie un Demande d'accès au serveur pour chaque utilisateur ou appareil à authentifier sur le port du serveur TCP / UDP 1812 (Les anciennes versions du serveur utiliseraient 1645 pour l'authentification aussi).
2. Le serveur répond conformément à la politique Accès-accepter si l'authentification est autorisée, Accès-Rejeter si l'accès n'est pas autorisé ou Accès-Challenge si le serveur nécessite plus d'informations pour déterminer l'accès (comme une seconde validation: code PIN, mot de passe, certificat, etc.)
Eventuellement, le client et le serveur pourraient échanger des messages de comptabilité tels que Demande de comptabilité et Comptabilité-Réponse afin de maintenir un identifiant de session unique.
3. Le client envoie un Demande de comptabilité au serveur via le port TCP / UDP 1813 pour la gestion des sessions de comptabilité (les anciennes versions du serveur utiliseraient 1646 pour l'authentification aussi).
4. Le serveur répond avec un Comptabilité-Réponse message afin de confirmer la nouvelle session.
Dans un environnement RADIUS, un service supplémentaire pour la gestion de la base de données des utilisateurs sera nécessaire et doit être pris en compte dans la haute disponibilité, ce qui sera traité dans un autre article spécifique.
Environnement de répartition de charge RADIUS et de haute disponibilité #
Le problème si un service RADIUS est en panne peut entraîner le risque que les utilisateurs ne puissent pas accéder à un réseau de serveurs, ou se connecter à une application, les utilisateurs ne peuvent pas ouvrir une session dans un appareil ou ne peuvent pas obtenir l'autorisation d'utiliser un droit dans un processus métier. Afin de résoudre ce genre de situations, le but de cet article est de configurer l'environnement ci-dessous.
RELIANOID partagera les messages du protocole RADIUS entre tous les serveurs RADIUS, qu'ils se trouvent sur des sites différents ou locaux. Dans les sections suivantes, nous expliquons la configuration de ce type d'environnements, les contrôles de santé avancés pour les services RADIUS et les défis de sécurité de ce protocole.
Configuration du service virtuel RADIUS #
La nature du protocole RADIUS étant basée sur les paquets UDP, la configuration d’un environnement RADIUS fiable est construite avec un LSLB ferme avec L4xNAT profil sur la couche 4, ports 1812 et 1813, type de protocole UDP et préféré DNAT afin d’avoir la transparence et d’obtenir l’IP du client à l’arrière (bien que NAT devrait fonctionner parfaitement aussi bien).
Dans l' Services, aucune persistance n'est nécessaire par défaut, sauf si une certaine rigidité entre le serveur client-radius est requise.
Si RADIUS est utilisé via TCP au lieu de UDP, il peut être modifié dans le champ Type de protocole. Il pourrait être réglé aussi bien TOUTES protocoles afin d’autoriser simultanément TCP et UDP à partir de la même adresse IP virtuelle.
Enfin, configurez les backends sans aucun port configuré (car il utilisera le port de destination de la connexion client) et testez la connexion. Une fois que le service virtuel RADIUS est configuré avec succès, nous pouvons définir la vérification d'état avancée pour ce service.
Configuration du bilan de santé avancé RADIUS #
Un contrôle avancé est inclus dans RELIANOID avec nom check_radius sous le dossier par défaut / usr / local / zenloadbalancer / app / libexec /.
L'aide de cette commande peut être listée:
root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help Teste pour voir si un serveur RADIUS accepte les connexions. Utilisation : check_radius -H hôte -F fichier_configuration -u nom d'utilisateur -p mot de passe [-P port] [-t délai d'attente] [-r nouvelles tentatives] [-e attente] [-n nas-id] [-N nas-ip-addr ] Options : -h, --help Imprimer l'écran d'aide détaillé -V, --version Imprimer les informations sur la version --extra-opts=[section][@file] Lire les options à partir d'un fichier ini. Voir https://www.monitoring-plugins.org/doc/extra-opts.html pour l'utilisation et des exemples. -H, --hostname=ADDRESS Nom d'hôte, adresse IP ou socket Unix (doit être un chemin absolu) -P, --port=INTEGER Numéro de port (par défaut : 1645) -u, --username=STRING L'utilisateur à authentifier -p, --password=STRING Mot de passe pour l'authentification (RISQUE DE SÉCURITÉ) -n, --nas-id=STRING Identifiant NAS -N, --nas-ip-address=STRING Adresse IP du NAS -F, --filename= STRING Fichier de configuration -e, --expect=STRING Chaîne de réponse à attendre du serveur -r, --retries=INTEGER Nombre de tentatives de nouvelle tentative en cas d'échec de connexion -t, --timeout=INTEGER Secondes avant l'expiration de la connexion (par défaut : 10) Ce plugin teste un serveur RADIUS pour voir s'il accepte les connexions. Le serveur à tester doit être spécifié dans l'invocation, ainsi qu'un nom d'utilisateur et un mot de passe. Un fichier de configuration peut également être présent. Le format du fichier de configuration est décrit dans les sources de la bibliothèque radiusclient. L'option de mot de passe présente un problème de sécurité important car le mot de passe peut éventuellement être déterminé en observant attentivement la ligne de commande dans une liste de processus. Ce risque est exacerbé car le plugin sera généralement exécuté à intervalles réguliers et prévisibles. Veuillez vous assurer que le mot de passe utilisé ne permet pas l'accès aux ressources système sensibles.
Tout d'abord, vérifions s'il fonctionne correctement en exécutant l'exemple de commande suivant (veuillez utiliser vos propres paramètres de configuration client radius de RELIANOID):
root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -P -u -p -F
Le test sera effectué à partir de RELIANOID appliance à un certain serveur RADIUS avec une validation utilisateur factice et, éventuellement, un fichier de configuration client pour des paramètres client spécifiques. Testons la commande, puis, lorsque nous obtenons le OK du serveur et du Analyse De Défaillance lorsqu'il est en panne, nous pouvons configurer la vérification de l'état avancée Services section de notre service virtuel vient de créer.
N'oubliez pas d'utiliser le HÔTE jeton lors de la configuration des vérifications de santé avancées dans RELIANOID comme ci-dessous.
check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg
Voir ci-dessous le Services configuration de la section.
Options de sécurité RADIUS #
Le protocole RADIUS a traditionnellement utilisé des algorithmes MD5 pour l'authentification par paquet et les contrôles d'intégrité sur UDP. Comme ces deux systèmes ne fournissent aucun cryptage et protection de sécurité, plusieurs approches ont été étudiées.
Déploiements de RADIUS sur IPsec or Internet Protocol Security ont été largement déployés, mais cette option présente certaines difficultés car la couche application n'est pas consciente des politiques de sécurité, car elles sont implicites dans la couche réseau. Pour utiliser cette approche avec RELIANOID cela nécessite une configuration manuelle car il n'est pas encore intégré.
La spécification de DTLS or Sécurité de la couche de transport de datagramme permet de chiffrer, de surveiller et de contrôler les politiques de sécurité de ce trafic.
Une autre option serait RADIUS over TLS qui fournit des capacités TCP de fiabilité et de couche de transport dans l’ordre.
Pour ce type d’approches, le IANA a créé une entrée officielle pour RadSec (RADIUS Security) pour utiliser UDP 2083 port pour RAYON / TLS mises en œuvre.
Une autre option consisterait à améliorer les couches digestion et autorisation avec EAP (Protocole d'authentification extensible) qui n’est pas utilisé dans la couche d’établissement de liaison mais au cours de la phase d’authentification de la connexion, évitant ainsi l’utilisation de digests faibles MD5.
De plus, avec RELIANOID, les services RADIUS peuvent être protégés avec le module IPDS contre les paquets et hôtes malveillants, les attaques DoS, les tentatives de force brute et bien plus encore.
Fonctions du proxy RADIUS #
Si plusieurs serveurs RADIUS sont déployés sur différents sites, il serait intéressant de rediriger la connexion client vers le site qui gère ses données d'authentification, d'autorisation et de comptabilité. Actuellement, RELIANOID ne prend pas en charge les fonctionnalités de proxy RADIUS, mais il est prévu de l'inclure prochainement. Attendez-vous à connaître les derniers développements !
Profitez de vos services d'accès réseau hautement disponibles et évolutifs!
