Oeris

Shopping Cart: 0.00 0 items

Le blog

Les fondamentaux de Freeradius

Qu’est ce qu’un serveur Radius ?

Un serveur Radius (Remote Authentication Dial-In User Service), Freeradius en l’occurrence, met en œuvre les fonctions AAA (Authentication / Authorization / Accounting), fonctions qui sont très utilisées chez les opérateurs Telecom, mais aussi dès qu’un système informatique doit gérer des accès avec des droits.

  • L’authentification consiste à vérifier l’identité d’une personne ou d’un utilisateur afin de vérifier si celui peut accéder à une ressource. L’utilisateur doit fournir au systéme informatique des informations afin que celui ci puisse effectuer cette vérification. Ces informations peuvent être un nom d’utilisateur, un mot de passe, une clé, un certificat ….
  • L’authorization consiste à déterminer une fois un utilisateur authentifié, à quelle ressource celui ci peut accéder.
  • L’accounting permet principalement d’horodater quand l’utilisateur a été autorisé à accéder à un système, et quand il s’en est déconnecte ainsi que les ressources qu’il a utilisé lors de sa session.

En d’autres mots, plus austère un serveur Radius est un serveur capable de discuter avec un client Radius en utilisant le protocole Radius décrit dans les RFC 2865 et 2866. Les clients sont assez souvent implémentés sur des équipements réseaux, mais pas uniquement.

Généralités sur Freeradius

Les premières versions de Freeradius sont sorties peu après l’an 2000. Ses concurrents les plus connus sont GnuRadius / Radiator. Ce logiciel est fournie sous licence BSD, il fonctionne potentiellement sur tous les systèmes Unix. Aujourd’hui c’est probablement l’un des serveurs Radius les plus utilisé dans le monde pour les raisons (purement subjectives) suivantes :

  •  Ses performances : Ce logiciel avec des machines très peu puissante (Un raspberry par exemple) peut facilement monter à 500 requêtes par seconde en générant une charge machine faible.
  •  Sa modularité : On peut à peu près tout faire avec, utiliser des bases de données (mysql/oracle/postgre), émettre des ressources
  •  Son interopérabilité : C’est le principe et l’intérêt d’un protocole, mais il est notable que si un équipement ou un système informatique respecte les RFC listés ci dessus, celui ci fonctionnera avec FreeRadius
  • Son évolutivité : Depuis plus de 10 ans, Freeradius inclut tous les ans les nouveaux standards en terme de sécurité, par exemple les protocoles EAP ont été intégrés très rapidement après que ceux ci aient été définis.

Tous ces intérêts cumulés ont  un revers de la médaille, le paramétrage de ce logiciel est complexe. Quelques raisons toujours aussi subjectives  :

  • Il se fait uniquement via des fichiers de configuration en mode texte (point de jolie interface de paramétrage)
  • Les fichiers de configuration sont nombreux et variés et parfois pas forcément simple à identifier lorqu’on ne connait pas
  • La documentation « pointue » est disponible directement dans les fichiers de configuration en commentaire
  • Il y a plusieurs manières de réaliser une même action.

Voila avec ces bémols là, vous êtes prêt à rentrer dans les arcanes des fichiers de configuration.

Les fichiers de configuration (version 2.x.x)

Schéma listant les « familles » de fichier de configuration :

Général : radiusd.conf

Ce fichier de configuration précise toutes les informations génériques du serveur et donc entre autre :

  • Les répertoires utilisés
  • Les adresses IP et les ports d’écoute du serveur
  • La gestion des logs
  • Le paramètrage qui concerne la performance et la sécurité du serveur (définition de seuil sur le nombre de thread, nombre maximum d’attribut Radius reçu par exemple)
  • Les inclusions d’autres fichiers de configuration

Exemple :

prefix = /usr/local exec_prefix = ${prefix} sysconfdir = ${prefix}/etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = ${prefix}/var/log raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct

 

Général : clients.conf

Ce fichier de configuration indique quels sont les clients Radius qui peuvent discuter avec le serveur, et permet aussi d’effectuer des traitements différents en fonction du client . Le client est alors lié à un serveur virtuel qui permet d’effectuer ces traitement différents. Exemple classique : le client est défini par un nom, un mot de passe (secret) et une adresse IP (ou un bloc d’adresse IP), le serveur utilisé sera alors le serveur default situé dans le répertoire site-enabled

client 192.168.0.0/16 { secret          = testing123-2 shortname        = private-network-2 }

Exemple de serveur virtuel : Le serveur utilisé pour toute requête émanant de ce client sera alors le serveur specific situé dans le répertoire site-enabled

client 192.168.3.6 { secret          = testing123 shortname       = ap-netgear virtual_server = specific }

Cela permet  par exemple de décider pour un client X de gérer une authentification simple en PAP via un fichier texte, ou pour un autre client de s’appuyer sur une base de donnés ou un serveur LDAP tout en appuyant l’authentification sur de l’EAP.

Serveurs : les fichiers contenus dans les répertoires sites-enabled et sites-available

Sur la même logique que celle utilisée sur un serveur HTTP comme Apache ou Nginx, ces fichiers de configuration permettent de différencier le type de traitement du serveur en fonction d’un certain nombre de critère (par exemple l’adresse IP du client). Pour faire des analogies , on pourrait considérer que ces différents « serveurs virtuels »  ressemblent à des views pour un serveur DNS de type Bind, ou à des serveurs virtuels pour Apache. Ces fichiers listent les différents modules qui seront utilisés lors du traitement des requêtes. Ces modules sont classés par section. Il y a 8 sections utilisables :

  • Authorize
  • Authenticate
  • Preacct
  • Accounting
  • Session
  • Post-auth
  • Pre-proxy
  • Post-proxy

Ces sections sont appelées par Freeradius lors des traitements des requêtes de type Acces Request ou Accounting Request. Exemple : La section Authorize qui ne prend en compte que les modules auth_log (qui permet de logguer les Access Request), files (qui permet de vérifier l’existance du login/mot de passe contenu dans la requete dans un fichier texte), pap (qui prend en compte le codage PAP du mot de passe).

authorize { auth_log files pap }

 

Les modules :

Les modules sont appelés dans les différentes sections traitées par Freeradius pour chacun des serveurs. Ces modules permettent par exemple de spécifier dans quel backend doit « regarder » Freeradius afin de vérifier le mot de passe (phase d’authentification) , par exemple dans un fichier (files), dans une base de données (sql). Si ces modules sont appelés dans la phase d’accounting, par exemple, cela signifiera que Freeradius ecrira l’accounting, dans un fichier ou une base de données sql. Exemple de configuration du module files : Ce modules spécifie dans quel fichier Freeradius ira regarder en fonction de la section dans lequel le module files est appelé.

# -*- text -*- # #  $Id$# Livingston-style ‘users’ file # files { # The default key attribute to use for matches.  The content # of this attribute is used to match the « name » of the # entry. #key = « %{Stripped-User-Name:-%{User-Name}} »usersfile = ${confdir}/users acctusersfile = ${confdir}/acct_users preproxy_usersfile = ${confdir}/preproxy_users postproxy_usersfile = ${confdir}/postproxy_users postauth_usersfile = ${confdir}/postauth_users#  If you want to use the old Cistron ‘users’ file #  with FreeRADIUS, you should change the next line #  to ‘compat = cistron’.  You can the copy your ‘users’ #  file from Cistron. compat = no }

Les dictionnaires :

Un fichier de dictionnaire permet de préciser à Freeradius quels sont les différents attributs que va devoir comprendre Freeradius lorsqu’il recevra des requêtes venant d’un client. En terme d’organisation, Freeradius liste dans un fichier dictionary tous les dictionnaires inclus, puis dans chacun des dictionnaires les attributs spécifiques sont précisés. Extrait du fichier générique

# #       Include the RFC dictionaries next. # #       For a complete list of the standard attributes and values, #       see: #               http://www.iana.org/assignments/radius-types # $INCLUDE dictionary.rfc2865 $INCLUDE dictionary.rfc2866$INCLUDE dictionary.rfc2867 $INCLUDE dictionary.rfc2868$INCLUDE dictionary.rfc6911 $INCLUDE dictionary.rfc6930# #       Include vendor dictionaries after the standard ones. # $INCLUDE dictionary.3com $INCLUDE dictionary.3gpp $INCLUDE dictionary.3gpp2 $INCLUDE dictionary.acc

Extrait d’un fichier de dictionnaire Alcatel

VENDOR          Alcatel                         3041BEGIN-VENDOR    AlcatelATTRIBUTE       AAT-Client-Primary-DNS                  5       ipaddr ATTRIBUTE       AAT-Client-Primary-WINS-NBNS            6       ipaddr ATTRIBUTE       AAT-Client-Secondary-WINS-NBNS          7       ipaddr ATTRIBUTE       AAT-Client-Secondary-DNS                8       ipaddr ATTRIBUTE       AAT-PPP-Address                         9       ipaddr ATTRIBUTE       AAT-PPP-Netmask                         10      ipaddr

Tout nouvel équipementier qui souhaite mettre en place des attributs spécifiques fournit donc en général le dictionnaire, il est simple de l’intégrer à Freeradius, si cela n’est pas déjà le cas. Pour les adeptes du SNMP, je dirais que le dictionnaire est à Freeradius, ce que une MIB est à un agent SNMP.

Les chemins des fichiers de configuration

Le programme d’installation va créer un répertoire raddb, qui contient tous les fichiers de configuration. Ce répertoire sera crée généralement selon vos distributions Unix, soit dans /usr/local/etc soit dans /etc.

  • Tous les fichiers de configuration génériques (radiusd.conf, clients.conf, proxy.conf) vont se situer à la racine de cette arborescence (raddb/)
  • Toutes les configurations des serveurs virtuels vont se situer dans raddb/site-available de la même manière que sous Apache ou Nginx, si on souhaite rendre un serveur virtuel utilisable, il suffit de faire un lien symbolique du répertoire raddb/site-enabled vers le fichier qui va bien dans raddb/site-available
  • Toutes les configurations des modules sont dans raddb/modules
  • Les dictionnaires sortent un peu de cette structure et sont accessibles en général dans /usr/local/share/freeradius ou /usr/share/freeradius

Voila avec ce premier tutoriel, vous pouvez vous aventurez avec quelques bases dans les méandres de la configuration de Freeradius. Le deuxième tutoriel indiquera comment tester les configurations et vérifier pourquoi celles ci fonctionnent ou pas.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *