Introduction largement inspirée du livre de S.Borderes:
http://www.eyrolles.com/Informatique/Livre/authentification-reseau-avec-radius-9782212120073
Le protocole Radius répond au Modele AAA:
Il établit une couche applicative au-dessus de la couche de transport UDP, sur les ports 1812 pour les 2 premiers A et 1813 pour l'Accounting. Le protocole est basé sur des echanges requetes/réponse entre le poste client (terminal) et le client Radius: un NAS ⇒ Network Access Server (switch, borne wifi etc …). Il n'y a jamais de communication directe entre le poste de travail et le serveur Radius .
Radius est fondés sur l'échange d'attributs et valeurs associés. Il en existe beaucoup (cf http://freeradius.org/rfc/attributes.html), on s’intéressera particulièrement à ceux-ci:
cinematique:
Aucun logiciel propre a radius n'est nécessaire sur le poste client
Là un logiciel “supplicant” est nécessaire sur le poste client terminal, car c'est lui qui va fournir au serveur radius, via le NAS, l'identité et le credential de l'utilisateur. Les échanges se font toujours via l’intermédiaire du NAS, et dans un premier temps, comme il n'y a pas encore d'acces réseau complet, seul le protocole d'authentification sera autorisé a circuler. Il s'agit du protocole EAP (Extensible Authentication Protocol).
cinematique:
il faut noter que les communications entre le poste terminal client et le NAS ne sont pas des communications IP, mais ethernet de bas niveau, ce sont des paquets EAP, EAP over LAN (EAPOL) en fillaire et EAPOW (Over Wan) pour le sans fil. Ensuite entre le NAS et le serveur Radius , ce sont des paquets radius transportés en UDP.
802.1X est la norme qui definit le fonctionnement “port controlé/port non controlé” (EAP seulement ou tout le reste) du NAS .
EAP est le protocole dedié au port non controlé (pas encore ouvert au trafic utile) EAP est un protocole de transport de protocoles d'authentification (TLS, TTLS, PEAP …), ce sont ces derniers qui definiront le type d'authentification et la maniere de la faire. Seuls le supplicant et le serveur Radius ont connaissance du protocole d'authentification
authentification mutuelle entre le client et le serveur, mais asymetrique, le client authentifie le serveur sur la base du certificat serveur, le serveur authentifie le client sur la base d'un login/password . Le supplicant devra donc contenir une identité externe, une identité interne (au tunnel chiffré)existant dans la base d'authentification et son mot de passe associé.
meme principe, authentification mutuelle et asymetrique (afin d'eviter de disposer d'une PKI ⇒ cas de EAP/TLS !) . TTLS interviens dans l'etape “3” d'EAP (Protocole Transporté) et se distingue de PEAP notament par l'insertion d'un serveur TTLS entre le NAS et le serveur Radius . De meme que PEAP, il y a une phase TLS handshake pour établir un tunnel chiffré et une phase TLS Record pour y faire passer un protocole d'authentification par mot de passe , mais ensuite ce sera dans des paquets TTLS qu circuleront les paquets du protocole d'authentification, paquets formés de couples Attribut/Valeur compatibles avec ceux de Radius.
Le securisation de la liaison radio entre le client terminal et le NAS est primordiale. Les faiblesses de WEP (Wired Equivalent Privacy) ne sont plus a démontrer. WPA (Wifi Protected Access) en attendant la norme 802.11i puis WPA2 quand la norme est sortie en 2004, ont nettement ameliorés la securité du lien radio . Un changement périodique des clés de chiffrement a lieu, TKIP (Temporal Key Integrity Protocol) pour WPA, mais basé sur l'algo de chiffrement RC4, WPA2 est basé sur un meilleur algo; AES.
deux étapes, autorisation puis authentification ! curieux de prime abord mais cela fonctionne comme ça . Freeradius prepare le terrain en établissant la liste des autorisations qui sera envoyée au NAS quand l'authentification sera positive .
Pour ce faire radius s'appuie sur une base d'autorisation (fichier users) dont le point d'entré est l'identifiant radius (champ User-Name) suivit de trois catégorie d'attributs
simplement pour verifier le mot de passe de l'identifiant, souvent une base de compte externe (ldap, windows, sql fichier a plat etc …) , ou la meme base que la base d'autorisation dans le cadre du simple fichier users.
[root@radiustux2 /etc/raddb] $ rpm -qa | grep freeradius freeradius-2.1.3-2.el5 freeradius-utils-2.1.3-2.el5 freeradius-mysql-2.1.3-2.el5 freeradius-libs-2.1.3-2.el5 freeradius-ldap-2.1.3-2.el5 freeradius-perl-2.1.3-2.el5
Depuis les versions 1.x des changements de parametrages ont eu lieu dans les fichiers de configuration .
###################################################################### # As of 2.0.0, the "authorize", "authenticate", etc. sections # are in separate configuration files, per virtual host. # .... # See "sites-enabled/default" for some additional documentation. # .... # In 1.x, the "authorize", etc. sections were global in # radiusd.conf. As of 2.0, they SHOULD be in a server section. # # The server section with no virtual server name is the "default" # section. It is used when no server name is specified. ######################################################################
En effet
[root@radiustux2 /etc/raddb]
$ cat radiusd.conf | egrep -v -e '[[:blank:]]*#|^$' | grep \$INCLUDE
$INCLUDE proxy.conf
$INCLUDE clients.conf
$INCLUDE ${confdir}/modules/
$INCLUDE eap.conf
$INCLUDE policy.conf
$INCLUDE sites-enabled/
[root@radiustux2 /etc/raddb] $ ls -l sites-enabled/ total 0 lrwxrwxrwx 1 root radiusd 33 avr 20 17:13 control-socket -> ../sites-available/control-socket lrwxrwxrwx 1 root radiusd 26 avr 20 17:13 default -> ../sites-available/default lrwxrwxrwx 1 root radiusd 31 avr 20 17:13 inner-tunnel -> ../sites-available/inner-tunnel
[root@radiustux2 /etc/raddb]
$ tail -8 clients.conf
client 157.159.17.19 {
secret = secret
shortname = c3550-7.19
}
client 157.159.17.138 {
secret = secret
shortname = HPswc01
}
Un simple example en mac-based, declaration d'un PC par son adresse MAC et mot de passe = @MAC .
[root@radiustux2 /etc/raddb]
$ cat users
...
#PC PAT 4031
005004B7252E Auth-Type := Local, Cleartext-Password := "005004B7252E"
Tunnel-type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = 15
...
Lancement du serveur radius en mode debug (-X)
[root@radiustux2 /etc/raddb]
$ /usr/sbin/radiusd -X
FreeRADIUS Version 2.1.3, for host i686-redhat-linux-gnu, built on Apr 20 2009 at 16:54:11
...
Module: Linked to module rlm_files
Module: Instantiating files
files {
usersfile = "/etc/raddb/users"
...
Listening on authentication address * port 1812
...
Ready to process requests.
[root@radiustux2 /]
$ radtest 005004B7252E 005004B7252E 157.159.10.55 16 secret
Sending Access-Request of id 169 to 157.159.10.55 port 1812
User-Name = "005004B7252E"
User-Password = "005004B7252E"
NAS-IP-Address = 157.159.10.55
NAS-Port = 16
rad_recv: Access-Accept packet from host 157.159.10.55 port 1812, id=169, length=36
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "15"
Log coté radiusd -X au meme instant:
rad_recv: Access-Request packet from host 157.159.10.55 port 32769, id=81, length=64
User-Name = "005004B7252E"
User-Password = "005004B7252E"
NAS-IP-Address = 157.159.10.55
NAS-Port = 16
+- entering group authorize {...}
++[preprocess] returns ok
[auth_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/157.159.10.55/auth-detail-20090429
[auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/157.159.10.55/auth-detail-20090429
[auth_log] expand: %t -> Wed Apr 29 17:26:48 2009
++[auth_log] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "005004B7252E", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
[files] users: Matched entry 005004B7252E at line 204
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Found existing Auth-Type, not changing it.
++[pap] returns noop
Found Auth-Type = Local
WARNING: Please update your configuration, and remove 'Auth-Type = Local'
WARNING: Use the PAP or CHAP modules instead.
User-Password in the request is correct.
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 81 to 157.159.10.55 port 32769
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "15"
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Exmple d'une simple demande d'authentification basée sur l'adresse MAC
fichier de configuration *users* de freeradius
[root@radiustux2 /etc/raddb]
$ more users
#PC PAT 4031
#005004B7252E Auth-Type := Local, Cleartext-Password := "005004B7252E"
005004B7252E Cleartext-Password := "005004B7252E"
Tunnel-type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = 15
attention a l'odre des entrées dans ce fichier, j'ai eu pas mal de soucis tout simplement parce que j'avais ajouté cette entré d'exemple en fin de fichier et que des directives par defaut invalidaient mon test , j'ai resolu mes pb en remontant en debut de fichier cette declaration d'adresse MAC ! cf thrad : http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg54148.html
Dépilement de la reponse freeradius (radiusd -X )
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on command file /var/run/radiusd/radiusd.sock
Listening on proxy address * port 1814
Ready to process requests.
rad_recv: Access-Request packet from host 157.159.7.138 port 1025, id=13, length=195
Framed-MTU = 1480
NAS-IP-Address = 157.159.7.138
NAS-Identifier = "Sw-C01"
User-Name = "005004B7252E"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 20
NAS-Port-Type = Ethernet
NAS-Port-Id = "20"
Called-Station-Id = "00-1c-2e-b4-f2-6c"
Calling-Station-Id = "00-50-04-b7-25-2e"
Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
CHAP-Password = 0x007095bd0c5363d28dbf8b72533936e2ed
Message-Authenticator = 0x24ce3e78be79f6c62a8be0f7161f7492
+- entering group authorize {...}
++[preprocess] returns ok
[suffix] No '@' in User-Name = "005004B7252E", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry 005004B7252E at line 3
++[files] returns ok
[pap] No clear-text password in the request. Not performing PAP.
++[pap] returns noop
WARNING: Please update your configuration, and remove 'Auth-Type = Local'
WARNING: Use the PAP or CHAP modules instead.
CHAP-Password is correct.
+- entering group post-auth {...}
[echo] expand: %{NAS-Identifier} -> Sw-C01
[echo] expand: %{NAS-Port} -> 20
Exec-Program output:
Exec-Program: returned: 0
++[echo] returns ok
Sending Access-Accept of id 13 to 157.159.7.138 port 1025
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "15"
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Accounting-Request packet from host 157.159.7.138 port 1031, id=14, length=111
Acct-Session-Id = "001300000015"
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Acct-Delay-Time = 0
NAS-Port = 20
Calling-Station-Id = "00-50-04-B7-25-2E"
Service-Type = Framed-User
NAS-IP-Address = 157.159.7.138
NAS-Identifier = "Sw-C01"
User-Name = "005004B7252E"
+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] Hashing 'NAS-Port = 20,Client-IP-Address = 157.159.7.138,NAS-IP-Address = 157.159.7.138,Acct-Session-Id = "001300000015",User-Name = "005004B7252E"'
[acct_unique] Acct-Unique-Session-ID = "6a012a76d447c0ad".
++[acct_unique] returns ok
++[files] returns noop
+- entering group accounting {...}
[detail] expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/157.159.7.138/detail-20090506
[detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/157.159.7.138/detail-20090506
[detail] expand: %t -> Wed May 6 16:56:26 2009
++[detail] returns ok
++[unix] returns ok
[radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp
[radutmp] expand: %{User-Name} -> 005004B7252E
++[radutmp] returns ok
[attr_filter.accounting_response] expand: %{User-Name} -> 005004B7252E
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 14 to 157.159.7.138 port 1031
Finished request 1.
Cleaning up request 1 ID 14 with timestamp +48
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 13 with timestamp +48
Ready to process requests.
Le client reçoit bien une adresse dans le VLAN15 (157.159.15.X)
[root@elgringo ~]# /etc/init.d/network restart
[root@elgringo ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:04:B7:25:2E
inet adr:157.159.15.64 Bcast:157.159.15.255 Masque:255.255.255.0
cinematique pour EAP, qui est la methode par defaut , à partir des fichiers de configuration
contient la liste des NAS avec leur credential , donc la liste des “clients” radius qui ont le droit de communiquer avec le serveur .
[root@radius raddb]# vim users
sallestp Auth-Type:= EAP
Reply-Message = "t es bien une bonne machine",
Tunnel-Type := VLAN,
Tunnel-Medium-Type := IEEE-802,
Tunnel-Private-Group-Id = 15,
Fall-Through = No
# default et check que NAS == Chillispot (patan), alors authZ de type ldap-chilli a suivre dans sites-enabled/default
DEFAULT NAS-Identifier == "Chillispot", Autz-Type := ldap-chilli
#On finis toujours ici, car "Fall-Through = Yes" (continue) ci-dessus
#Affectation du Vlan poubelle 955 si aucune autre valeure (phase EAP)
# ne viens l'ecraser, ce qui devrait etre le cas pour les auth positive
DEFAULT
Tunnel-Type:1 = VLAN,
Tunnel-Medium-Type:1 = IEEE-802,
Tunnel-Private-Group-ID = 955,
Fall-Through = no
sites-enabled/default
[root@radius raddb]# vim sites-enabled/default
# Authorization. First preprocess (hints and huntgroups files),
# then realms, and finally look in the "users" file.
#
# The order of the realm modules will determine the order that
# we try to find a matching realm.
authorize {
...
# As of 2.0, the EAP module returns "ok" in the authorize stage
# for TTLS and PEAP. In 1.x, it never returned "ok" here, so
# this change is compatible with older configurations.
# The example below uses module failover to avoid querying all
# of the following modules if the EAP module returns "ok".
# Therefore, your LDAP and/or SQL servers will not be queried
# for the many packets that go back and forth to set up TTLS
# or PEAP. The load on those servers will therefore be reduced.
#
eap {
ok = return
}
# Read the 'users' file
# autz-type ldap-cilli = definition appeler dans files, donc definie avant !
# files users : DEFAULT NAS-Identifier == "Chillispot", Autz-Type := ldap-chilli
Autz-Type ldap-chilli {
redundant-load-balance {
ldap1
ldap2
ldap3
ldap4
}
chilli
pap
}
files
expiration
logintime
....
authenticate {
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
# password can be clear-text, or encrypted.
Auth-Type PAP {
pap
}
...
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
...
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password.
# valable pour le chilli
Auth-Type LDAP {
group {
redundant-load-balance {
ldap1
ldap2
ldap3
ldap4
}
ok=return
}
chilli
}
#
# Allow EAP authentication.
eap
[root@radius raddb]# vim eap.conf
eap {
# Invoke the default supported EAP type when
# EAP-Identity response is received.
...
# If the EAP-Type attribute is set by another module,
# then that EAP type takes precedence over the
# default type configured here.
#
default_eap_type = peap
..
## EAP-TLS
# Note that you should NOT use a globally known CA here!
# e.g. using a Verisign cert as a "known CA" means that
# ANYONE who has a certificate signed by them can
# authenticate via EAP-TLS! This is likey not what you want.
tls {
#
# These is used to simplify later configurations.
#
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = radius
private_key_file = ${certdir}/radius_1347_pass.key
# If CA_file (below) is not used, then the
# certificate_file below MUST include not
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
#certificate_file = ${certdir}/cert-1347-radius.it-sudparis.eu.pem
certificate_file = ${certdir}/radius-chain.pem
#certificate_file = ${certdir}/chain-1347-radius.it-sudparis.eu.pem
# This parameter is used only for EAP-TLS,
# when you issue client certificates. If you do
# not use client certificates, and you do not want
# to permit EAP-TLS authentication, then delete
# this configuration item.
CA_file = ${cadir}/ca-bundle.crt
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
check_cert_cn = %{User-Name}
ttls {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# TTLS tunnel, we recommend using EAP-MD5.
default_eap_type = md5
# The tunneled authentication request does
# not usually contain useful attributes
# like 'Calling-Station-Id', etc. These
# attributes are outside of the tunnel,
# and normally unavailable to the tunneled
# authentication request.
#
# By setting this configuration entry to
# 'yes', any attribute which NOT in the
# tunneled authentication request, but
# which IS available outside of the tunnel,
# is copied to the tunneled request.
#
# allowed values: {no, yes}
copy_request_to_tunnel = yes
# The reply attributes sent to the NAS are
# usually based on the name of the user
# 'outside' of the tunnel (usually
# 'anonymous'). If you want to send the
# reply attributes based on the user name
# inside of the tunnel, then set this
# configuration entry to 'yes', and the reply
# to the NAS will be taken from the reply to
# the tunneled request.
#
# allowed values: {no, yes}
use_tunneled_reply = yes
The inner tunneled request can be sent
# through a virtual server constructed
# specifically for this purpose.
#
# If this entry is commented out, the inner
# tunneled request will be sent through
# the virtual server that processed the
# outer requests.
#
virtual_server = "inner-tunnel"
# The PEAP module needs the TLS module to be installed
# and configured, in order to use the TLS tunnel
# inside of the EAP packet. You will still need to
# configure the TLS module, even if you do not want
# to deploy EAP-TLS in your network. Users will not
# be able to request EAP-TLS, as it requires them to
# have a client certificate. EAP-PEAP does not
# require a client certificate.
peap {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
default_eap_type = mschapv2
# the PEAP module also has these configuration
# items, which are the same as for TTLS.
copy_request_to_tunnel = yes
use_tunneled_reply = yes
# The inner tunneled request can be sent
# through a virtual server constructed
# specifically for this purpose.
#
# If this entry is commented out, the inner
# tunneled request will be sent through
# the virtual server that processed the
# outer requests.
#
virtual_server = "inner-tunnel"
}
[root@radius raddb]# vim sites-enabled/inner-tunnel