Proposition de sécurisation d`un réseau à l`aide des protocoles

Transcription

Lycée Suzanne Valadon
Proposition de sécurisation
d’un réseau à l’aide des
protocoles 802.1X, EAP-TLS et
d’un firewall pfSense
Loïc Laforet
Dernière modification : 25 juin 2014
Table des matières
I
Travaux pratiques
3
I
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
II
Préparation de nos environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
III Installation du service Freeradius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
IV Création d’un portail captif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V
9
Création des certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
VI Intégration de la méthode EAP-TLS dans Freeradius . . . . . . . . . . . . . . . . . . . . . . . . . .
16
VII Configuration du switch HP2626 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
VIII Déploiement du serveur Mysql, et configuration de Freeradius . . . . . . . . . . . . . . . . . . . .
23
IX Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2
Chapitre
I
Travaux pratiques
I
Introduction
Lorsque nous devons sécuriser un réseau informatique, nous avons tendance à se focaliser sur les outils
liés au firewalling afin de restreindre et définir explicitement les accès provenant de l’extérieur vers nos réseaux
et nos ressources internes. En dehors d’un usage familial, il est cependant impératif de prendre en compte la
sécurité des matériels, outils et usagers situés dans les réseaux internes, côté LAN.
Avec la prolifération des ordinateurs et médias personnels portables, le risque qu’un équipement inconnu
tente d’accéder aux ressources internes d’un réseau peut devenir important, et nous nous devons de mettre
en oeuvre les techniques, outils et procédures qui s’imposent pour tenter au maximum de réduire les risques
d’intrusion, de rebond, de pollution ...
Si, parmi ces ressources, nous disposons également d’un accès Wi-Fi, il convient égalment de s’assurer
que seules les personnes autorisées puissent s’y connecter.
Ce TP a pour but d’apporter des ébauches de solutions pour réduire ces risques. Nous verrons ainsi
comment authentifier de manière forte certains utilisateurs, tout en permettant aux autres un accès limité à
certaines ressources. Nous nous baserons sur le firewall pfSense, sur l’usage de vlan, sur une authentification
Radius par les protocoles d’authentification 802.1X et EAP-TLS.
1.
Ressources disponibles
Pour réaliser ce tp, votre binôme disposera des ressources suivantes :
— un firewall pfSense v-2.1.3 ;
— un serveur Debian 7.5, sur lequel nous allons déployer certains services comme Freeradius ;
— un switch niveau 3 (ou 2) avec 3 vlan ;
— un poste sous Windows 7 Pro pour l’administration ;
— un poste sous Windows 7 Pro pour les tests ;
3
II. Préparation de nos environnements
II
Préparation de nos environnements
Nous nous baserons sur l’architecture illustrée par la figure I.1. Chaque binôme disposera ainsi des
mêmes ressources pour lui permettre de déployer les différents éléments listés à la section 1.
Les ports des actifs dédiés par binôme vous seront communiqués le jour du TP.
Les deux machines virtuelles pfSense et Debian hébergeant le serveur d’authentification Freeradius seront déja déployées et configurées dans vos réseaux virtuels respectifs.
F IGURE I.1 – Principe général de l’environnement par binôme
III
Installation du service Freeradius
La première opération consiste à déployer le service Freeradius sur votre serveur Debian. Pour cela, nous
allons exploiter les dépôts mis à disposition par la communauté de cette distribution. Les étapes que nous
devrons respecter concernent :
— Accéder par le protocole SSH sur votre serveur Debian (putty, winscp, SSH Secure Shell ...) ;
— Passer en root ;
— Mettre à jour votre distribution à l’aide de la commande apt-get update ; apt-get dist-upgrade ;
— Installer le paquet freeradius à l’aide de la commande apt-get install ;
root@srvm-freeradius-02:~# apt-get update ; apt-get dist-upgrade
[...]
root@srvm-freeradius-02:~# apt-get install freeradius
Les paquets supplémentaires suivants seront installés :
freeradius-common freeradius-utils libdbi-perl libfreeradius2 libltdl7
libnet-daemon-perl libpcap0.8 libperl5.14 libplrpc-perl libpython2.7 ssl-cert
Paquets suggérés :
freeradius-ldap freeradius-postgresql freeradius-mysql freeradius-krb5
openssl-blacklist
4
III. Installation du service Freeradius
Les NOUVEAUX paquets suivants seront installés :
freeradius freeradius-common freeradius-utils libdbi-perl libfreeradius2 libltdl7
libnet-daemon-perl libpcap0.8 libperl5.14 libplrpc-perl libpython2.7 ssl-cert
0 mis à jour, 12 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 4 594 ko dans les archives.
Après cette opération, 11,1 Mo d’espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?O
Une fois cette installation réalisée, attardons nous sur l’arborescence de Freeradius, située dans /etc/freeradius :
root@srvm-freeradius-02:/etc/freeradius# ls -l
total 204
-rw-r----- 1 root
freerad
671 déc.
16
2012 acct_users
-rw-r----- 1 root
freerad
4174 déc.
16
2012 attrs
-rw-r----- 1 root
freerad
513 déc.
16
2012 attrs.access_challenge
-rw-r----- 1 root
freerad
481 déc.
16
2012 attrs.access_reject
-rw-r----- 1 root
freerad
437 déc.
16
2012 attrs.accounting_response
-rw-r----- 1 root
16
2012 attrs.pre-proxy
freerad
2022 déc.
drwxr-s--x 2 freerad freerad
4096 juin
-rw-r----- 1 root
freerad
6703 déc.
16
2012 clients.conf
-rw-r--r-- 1 root
freerad
1319 déc.
16
2012 dictionary
-rw-r----- 1 root
freerad 20634 juin
-rw-r----- 1 root
freerad 12949 déc.
16
2012 experimental.conf
freerad 27847 déc.
16
2012 radiusd.conf
6 11:43 certs
6 11:43 eap.conf
[...]
-rw-r----- 1 root
4096 juin
6 11:43 sites-available
4096 juin
6 11:43 sites-enabled
-rw-r----- 1 root
freerad
3042 déc.
16
2012 sql.conf
-rw-r--r-- 1 root
root
2475 déc.
16
2012 sqlippool.conf
-rw-r--r-- 1 root
root
3597 déc.
16
2012 templates.conf
-rw-r--r-- 1 root
root
6524 déc.
16
2012 users
root@srvm-freeradius-02:/etc/freeradius#
Les éléments importants sur lesquels nous interviendrons concernent :
— certs : répertoire contenant les certificats automatiquement générés lors de l’installation de Freeradius ;
— clients.conf : fichier de configuration permettant la déclaration des NAS (switch pour nous), seuls
équipements autorisés à effectuer des requêtes sur le serveur Freeradius ;
— eap.conf : fichier de configuration pour le protocole eap ;
— radiusd.conf : fichier de configuration générale de Freeradius ;
— sites-{available|enabled} : répertoires permettant de déclarer et d’activer les différentes instances (ou sites) de Freeradius ;
— sql.conf : fichier de configuration utilisé lorsque nous couplons Freeradius à un SGBD (MySQL,
POSTGRESQL) ;
— users : fichier de configuration utilisé pour déclarer les utilisateurs autorisés à s’authentifer sur Freeradius.
Pour valider l’efficience de notre serveur Freeradius et de sa configuration d’origine, nous allons tester
son fonctionnement. Pour cela, nous allons d’une part déclarer un NAS et un utilisateur autorisé à s’authentifier
5
dans les fichiers prévus à cet effet par Freeradius, puis d’autre part lancer notre serveur d’authentification en
mode debug.
Remarque : Par défaut, nous réaliserons une copie de sauvegarde de tous les fichiers de configuration que nous éditerons en fichier.ext.old.
1.
Déclaration d’un NAS
La déclaration d’un NAS doit impérativement respecter trois directives :
1. le nom du client sous la forme : client mon-nas-01
2. l’adresse ou le nom fqdn 1 associé au NAS : ipaddr = 10.12.14.15
3. le secret partagé entre le NAS et le serveur Freeradius : secret = mon-secret-partagé
Ces directives sont à définir dans le fichier /etc/freeradius/clients.conf :
root@srvm-freeradius-02:/etc/freeradius# nano clients.conf
client localhost {
ipaddr = 127.0.0.1
secret = test
}
Étant donné que nous allons tester notre configuration depuis le serveur Debian, nous spécifions l’adresse
de loopback (localhost ou 127.0.0.1) pour notre client. C’est donc la même machine qui réalisera les rôles d’authenticator
et de serveur d’authentification.
Passons à la définition de notre premier utilisateur nommé foobar.
2.
Déclaration d’un utilisateur
La déclaration d’un utilisateur simple avec un mot de passe en clair s’effectue par le biais du fichier
users :
root@srvm-freeradius-02:/etc/freeradius# nano users
foobar Cleartext-Password := "password"
Ces deux étapes réalisées, il ne nous reste plus qu’à lancer notre service Freeradius en mode debug et de
réaliser des tests d’authentification.
3.
Freeradius en mode debug
Nous arrêtons le démon freeradiusd pour le lancer en mode debug, afin de visualier les traitements
réalisés et les éventuelles erreurs détectées par Freeradius.
1. Full Qualified Domain Name
6
root@srvm-freeradius-02:/etc/freeradius# /etc/init.d/freeradius stop
Stopping FreeRADIUS daemon: freeradius.
root@srvm-freeradius-02:/etc/freeradius# freeradius -X
[...]
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.
La configuration par défaut de Freeradius est complexe. Le lancement du démon en mode debug nous
indique ici une partie des éléments de configuration et méthodes d’authentification qu’il prend charge dans
sa configuration par défaut. À la fin du TP, nous tenterons de réduire ces éléments de configuration pour ne
laisser que les indispensables à notre besoin.
En fin de chargement du mode debug, Freeradius nous indique les différents ports d’écoute, dédiés à
l’authentification, à l’accounting, et aux serveurs virtuels et proxy.
Laissons ce terminal ouvert, puis, depuis un autre terminal, testons une authentification de foobar à l’aide
du binaire radtest fourni par Freeradius (man radtest pour plus d’information...).
4.
Premiers tests avec radtest
root@srvm-freeradius-02:~# radtest foobar password localhost 0 test
Sending Access-Request of id 127 to 127.0.0.1 port 1812
User-Name = "foobar"
User-Password = "password"
NAS-IP-Address = 127.0.1.1
NAS-Port = 0
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=127, length=20
root@srvm-freeradius-02:~#
L’élément important ici est l’Access-Accept renvoyé par Freeradius. Le mode debug de Freeradius nous
indique un peu plus d’information :
rad_recv: Access-Request packet from host 127.0.0.1 port 60835, id=127, length=74
User-Name = "foobar"
User-Password = "password"
NAS-Port = 0
Message-Authenticator = 0x83ead3f682c403f65a628d19a4e4d945
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
7
[suffix] No ’@’ in User-Name = "foobar", 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 foobar at line 1
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "password"
[pap] Using clear text password "password"
[pap] User authenticated successfully
++[pap] returns ok
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 127 to 127.0.0.1 port 60835
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 127 with timestamp +268
En fonction de la configuration générale de Freeradius, ce dernier peut indiqué plus ou moins d’information, en fonction des différentes méthodes d’authentification paramétrées.
Nous repérons ici la méthode utilisée par Freeradius pour valider le processus d’authentification de foobar : PAP 2 .
Remarque : Pour la suite du TP, nous exploiterons ce second terminal pour réaliser les configurations et certains tests, tout en conservant le premier terminal pour visualiser le comportement
de notre service Freeradius en mode debug.
Passons sans plus attendre à notre firewall pfSense, afin de créer un portail captif en sous traitant son
authentifcation par notre Freeradius fraîchement installé.
2. Password Authenficiation Protocol transmet sur le réseau des mots de passe ASCII non chiffrés, méthode évidemment à bannir.
Il est utilisé en dernier recours dès lors qu’aucune méthode d’authentification forte n’est présente, comme CHAP ou EAP.
8
IV. Création d’un portail captif
IV
1.
Création d’un portail captif
Préambule
Un portail captif est un système permettant d’intercepter toutes les requêtes http et https d’un client. Le
but est d’authentifier les utilisateurs d’un réseau en les renvoyant vers une page prévue à cet effet - d’où le nom
portail captif. Ces services sont communément utilisés dans les hotspots, hotels ... Dans d’autres scénarios, les
portails captifs sont utilisés pour l’authentification des utilisateurs sur un réseau filaire ou pour forcer l’accord
d’un contrat ou charte d’usage du moyen mis à disposition.
Passons aux phases de création, puis de configuration en externalisant l’authentification de notre service
par notre serveur Freeradius.
2.
Configuration
Au cours de cette section, nous verrons comment configurer pfSense pour qu’il remplisse ce rôle avec
une authentification depuis notre serveur d’authentification Freeradius, limitant ainsi les utilisateurs depuis
notre zone Public. (Cf I.2, page 10).
1. Se rendre dans le menu Services | Portal captive ;
2. Ajouter une nouvelle zone ;
3. Cocher la case Enable captive portal ;
4. Sélectionner l’interface sur laquelle vous souhaitez que pfSense force l’interception des requêtes des
utilisateurs : Public pour l’exemple ;
5. Spécifier la directive Idle Timeout à 10 minutes ;
6. Spécifier la directive Hard Timeout à 60 minutes ;
7. Spécifier la directive Enable logout popup window pour que les utilsiateurs puissent se déconnecter
grâce à un popup lancé lors de l’identification validée d’un utilisateur ;
8. Activer l’authentification Radius de type PAP ;
9. Spécifier l’adresse IP de votre serveur Radius ;
10. Définir le secret partagé entre votre NAS (le pfSense) et le serveur Freeradius ;
11. Cocher l’option Sens RADIUS accountig packets pour activer le calcul des ressources consommées
par vos utilisateurs ;
12. Cocher l’option stop/start accounting ;
13. Valider enfin la configuration par le bouton Save.
Remarque 1 :
Activer puis paramétrer si besoin le service DHCP de votre pfSense sur votre Public.
9
F IGURE I.2 – Service Portal captive : création d’un portail captif
10
F IGURE I.3 – Service Portal captive : interception
Remarque 2 :
Dans l’exemple, nous ajoutons le service de portail captif sur l’interface Public, qui ne possède
pas encore de règle particulière. Ajoutez une règle permettant la sortie vers le HTTP(S) et le DNS
au minimum pour pouvoir convenablement tester le portail captif.
Si vous connectez un équipement sur le vlan Public et tentez de consulter un site internet, vous devriez
être intercepté par le portail captif de pfSense (Cf I.3). Cependant, toutes les tentatives d’authentification que
vous allez tenter ne pourront aboutir.
Complétez la configuration de Freeradius, arrêtez le mode debug puis relancez-le.
Adaptez les configurations de vos équipements pour réaliser une authentification de type CHAP. (Vérifiez la présence de cette méthode dans la section authenticate de Freeradius au besoin, puis validez le
fonctionnement.
Nous venons de déployer plusieurs éléments. Pour débuter, nous avons installé un serveur d’authentification AAA Freeradius, qui pour le moment ne possède pas de configuration d’authentification particulière,
par lequel nous avons déclaré des utilisateurs et des clients (authenticator). Nous avons ensuite créé un portail captif sur un VLAN dédié (Public) sous traitant l’authentification à notre serveur d’authentification. Enfin,
nous avons paramétré le port de notre actif pour qu’il fournisse le même VLAN à notre utilisateur afin d’être
intercepté puis authentifié à l’aide de son couple login / mot de passe.
Si vous le souhaitez, vous pouvez vous référer à la section 1..Autentification Radius-MAC, située à la
page 29, décrivant les différentes étapes pour configurer une authentification de type Radius-MAC.
Nous avons fini la première partie de ce TP. Passons maintenant aux choses sérieuses, en appliquant à
notre configuration une authentification forte des utilisateurs. Pour cela, nous allons ajouter à notre serveur
Freeradius la configuration nécessaire pour qu’il traite l’authentification EAP-TLS. Cette méthode, basée sur
les certificats, permettra une authentification mutuelle entre l’utilisateur et le serveur d’authentification, par le
biais d’un authenticator : le switch.
11
V. Création des certificats
V
Création des certificats
Comme évoqué en introduction de ce TP, nous allons mettre en oeuvre la méthode d’authentification
EAP-TLS, basée sur une authentification mutuelle par certificats. Pour générer les différents certificats que
nous utiliserons pour authentifier les clients et le serveur, nous allons exploiter les éléments mis à disposition
par Freeradius lors de l’installation. Nous devons disposer d’un certificat d’autorité, d’un certificat serveur associé à sa clé, puis des certificats liés mathématiquement pour chaque utilisateur autorisé à accéder à certaines
ressources ou sous réseaux.
— Se rendre dans l’arborescence /usr/share/doc/freeradius/examples/certs ;
— Modifier le fichier de configuration de l’autorité de certification ca.cnf :
[ req ]
prompt
= no
distinguished_name
= certificate_authority
default_bits
= 2048
input_password
= tpradius
output_password
= tpradius
x509_extensions
= v3_ca
[certificate_authority]
countryName
= FR
stateOrProvinceName
= Limousin
localityName
= Limoges
organizationName
= TP-Freeradius
emailAddress
= [email protected]
commonName
= "Certificat d’autorite"
— Modifier le fichier de configuration du certificat serveur serveur.cnf :
[ req ]
prompt
= no
distinguished_name
= server
default_bits
= 2048
input_password
= tpradius
output_password
= tpradius
[server]
countryName
= FR
stateOrProvinceName
= Limousin
localityName
= Limoges
organizationName
= TP-Freeradius
emailAddress
= [email protected]
commonName
= "Certificat serveur"
Remarque :
Il est possible que votre distribution ne possède pas le binaire make, nécessaire ici pour générer
les certificats serveurs, ca et clients. Installez le si besoin.
12
— Générer la clé et le certificat de l’autorité, puis le certificat pour Windows par les commandes suivantes ;
root@[...]:/usr/[...]certs# make ca.pem
openssl req -new -x509 -keyout ca.key -out ca.pem \
-days ‘grep default_days ca.cnf | sed ’s/.*=//;s/^ *//’‘
-config ./ca.cnf
Generating a 2048 bit RSA private key
................+++
....................................................................................
writing new private key to ’ca.key’
----root@[...]:/usr/[...]certs#
root@[...]:/usr/[...]certs# make ca.der
openssl x509 -inform PEM -outform DER -in ca.pem -out ca.der
root@[...]:/usr/[...]certs#
— Pour générer le certificat serveur, il est nécessaire de disposer d’un fichier serial contenant la chaîne de
caractère 01, puis d’un fichier index.txt vide. Générer le certificat par la commande :
root@[...]:/usr/[...]certs# touch index.txt
root@[...]:/usr/[...]certs# echo "01" > serial
root@[...]:/usr/[...]certs# make server.pem
openssl ca -batch -keyfile ca.key -cert ca.pem -in server.csr
-key ‘grep output_password ca.cnf | sed ’s/.*=//;s/^ *//’‘ -out server.crt
-extensions xpserver_ext -extfile xpextensions -config ./server.cnf
Using configuration from ./server.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Jun
6 12:28:23 2014 GMT
Not After : Jun
6 12:28:23 2015 GMT
Subject:
countryName
= FR
stateOrProvinceName
= Limousin
organizationName
= TP-Freeradius
commonName
= Certificat Serveur
emailAddress
= [email protected]
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication
Certificate is to be certified until Jun
6 12:28:23 2015 GMT (365 days)
Write out database with 1 new entries
Data Base Updated
openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12
-passin
pass:‘grep output_password
13
server.cnf | sed ’s/.*=//;s/^ *//’‘ -passout pass:‘grep
output_password server.cnf |
sed ’s/.*=//;s/^ *//’‘
openssl pkcs12 -in server.p12 -out server.pem -passin pass:‘grep output_password
server.cnf | sed ’s/.*=//;s/^ *//’‘
-passout pass:‘grep output_password server.cnf | sed ’s/.*=//;s/^ *//’‘
MAC verified OK
— Écraser si besoin les certificats déjà placés dans le répertoire certs de Freeradius, puis y copier les
certificats et la clé privée du serveur.
root@[...]:/usr/[...]certs# cp ca.pem server.key server.pem /etc/freeradius/certs/
— Créer un certificat pour un premier client, en modifiant le fichier client.cnf, puis en lançant la
commande make client.pem.
[client]
countryName
= FR
stateOrProvinceName
= Limousin
localityName
= Limoges
organizationName
= TP-Freeradius
emailAddress
= [email protected]
commonName
= [email protected]
root@[...]:/usr/[...]certs# make client.pem
openssl req -new
-out client.csr -keyout client.key -config ./client.cnf
Generating a 2048 bit RSA private key
.........+++
..+++
writing new private key to ’client.key’
----openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr
-key ‘grep
output_password ca.cnf | sed ’s/.*=//;s/^ *//’‘ -out client.crt -extensions
xpclient_ext -extfile xpextensions -config ./client.cnf
Using configuration from ./client.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Jun
6 12:42:37 2014 GMT
Not After : Jun
6 12:42:37 2015 GMT
Subject:
countryName
= FR
stateOrProvinceName
= Limousin
organizationName
= TP-Freeradius
commonName
= [email protected]
emailAddress
= [email protected]
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Client Authentication
14
Certificate is to be certified until Jun
6 12:42:37 2015 GMT (365 days)
Write out database with 1 new entries
Data Base Updated
openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12
-passin pass:‘grep output_password client.cnf | sed ’s/.*=//;s/^ *//’‘
-passout pass:‘grep output_password client.cnf | sed ’s/.*=//;s/^ *//’‘
openssl pkcs12 -in client.p12 -out client.pem -passin pass:‘grep output_password
client.cnf | sed ’s/.*=//;s/^ *//’‘ -passout pass:‘grep output_password
client.cnf | sed ’s/.*=//;s/^ *//’‘
MAC verified OK
cp client.pem ‘grep emailAddress client.cnf | grep ’@’ | sed ’s/.*=//;s/^ *//’‘.pem
Ces différentes étapes ont été rendues simples grâce aux éléments fournis par Freeradius. Le principe
reste le même si vous souhaitez utiliser directement les commandes fournies par OpenSSL. La méthode la
plus propre et la plus simple à exploiter reste néanmoins le déploiement d’une PKI 3 . Son déploiement reste
cependant fastidieux est complexe.
Cette partie étant terminée, adaptons la configuration de Freeradius pour qu’il traite l’authentification
EAP-TLS.
3. Public Key Infrastructure
15
VI. Intégration de la méthode EAP-TLS dans Freeradius
VI
Intégration de la méthode EAP-TLS dans Freeradius
Lors de nos premiers tests d’authentification d’un utilisateur sous Freeradius, nous nous sommes conten-
tés d’utiliser une méthode d’authentification simple basée sur un mot de passe (PAP et ou CHAP). Le but étant
de fournir une authentification forte à nos utilisateurs, nous devons forcer Freeradius à gérer l’authentification par le protocole EAP, décrit en introduction de ce document, en utilisant les certificats que nous venons de
générer à la section V.Création des certificats, page 12.
Pour effectuer cette opération, nous allons adapter le fichier /etc/freeradius/eap.conf.
Astuce :
Freeradius a la particularité comme beaucoup de fichier de configuration sous Linux à posséder
un nombre incalculabe de lignes et de directives, de commentaires, de sections ... Étant donné que
nous avons réalisé un .old de notre fichier eap.conf, vous pouvez exécuter la commande suivante
qui vous permettra de supprimer toutes les lignes en commentaires. Cette opération est ici réalisée
afin de faciliter la lisibilité des fichiers de configuration. Si vous devez déployer un tel service dans
un cadre professionnel ou d’étude de R&D, il est conseillé de garder le fichier d’origine ...
root@[...]# cat eap.conf | egrep -v "^[
]*#|^$" > eap.conf.tmp
root@[...]# mv eap.conf.tmp eap.conf
1.
Configuration de Freeradius
— Modifier les directives suivantes :
— default_eap_type = tls
— private_key_password = tpradius
— Commenter les sous-sections ttls, peap, mschapv2, méthodes non exploitées dans ce TP.
2.
Déclaration d’un utilisateur EAP-TLS
Maintenant que notre serveur d’authentification est configuré pour traiter des requêtes EAP-TLS, nous
devons lui déclarer un utilisateur EAP capable de s’authentifier. Pour cela, nous exploitons toujours le fichier
users de Freeradius.
Comme nous le verrons plus loin dans le chapitre VII, à la page 22, nous allons ici déclarer un attribut de
type autorisation permettant de forcer le VLAN de l’utilisateur une fois l’authentification TLS réussie.
[email protected] Auth-Type := EAP
Tunnel-Type = VLAN,
Tunnel-Medium-Type = 802,
Tunnel-Private-Group-ID = 2
Nous avons donc spécifié le protocole EAP, de type VLAN par le biais d’un média 802, et nous demandons
à Freeradius de spécifier le numéro de VLAN à l’authenticator une fois l’authentification réussie.
Redémarrer le serveur d’authentification pour prendre en compte ces modifications, puis passons à la
configuration de notre client Windows.
16
3.
Configuration d’un client sous Windows
La configuration d’un client sous Windows ou sous un autre système d’exploitation est très simple. Il
nous suffit d’installer les certificats ca.der et client.p12 que nous avons préalablement générés. Le premier sera
pour déclarer l’autorité de certification de confiance (le tiers) et le second concerne notre certificat client (.p12
pour Windows).
Dans l’ordre :
F IGURE I.4 – Autorité de certification - Installation
F IGURE I.5 – Autorité de certification - Choix du magasin
— Saisir le mot de passe paramétré lors de la génération du certificat d’autorité (Cf. figure I.9) ;
17
F IGURE I.6 – Autorité de certification - Avertissement
F IGURE I.7 – Autorité de certification - Confirmation
— Modifier la configuration d’authentification de votre carte réseau (Cf. figure I.10) ;
— Sélectionner l’autorité de confiance (Cf. figure I.11) ;
18
F IGURE I.8 – Certificat client - Installation
F IGURE I.9 – Certificat client - Mot de passe
19
F IGURE I.10 – Certificat client - Configuration de la carte réseau
F IGURE I.11 – Certificat client - Choix de l’autorité de confiance
20
F IGURE I.12 – Windows - Détection de l’authentification 802.1X
— Lorsque Windows détecte la nécessité de fournir une authentification basée sur le protocole 802.1X,
sélectionner le certificat client préalablement installé (Cf. figure I.13) ;
F IGURE I.13 – Windows - Choix du certificat client
Une fois la configuration du client terminée, nous devons prendre la main sur l’actif mis à votre disposition, afin d’activer la méthode d’authentification 802.1X (port-based) sur le port sur lequel votre client est
connecté.
21
VII. Configuration du switch HP2626
VII
Configuration du switch HP2626
Nous allons administrer en mode console (telnet port 23) le switch pour modifier d’une part les ports
sur lesquels seront connectés nos clients Windows, et d’autre part pour déclarer notre serveur Freeradius sur
lequel les requêtes d’authentification EAP s’effectueront.
— S’identifer par une session telnet sur l’actif ;
— Passer en mode de configuration ;
— Spécifier les paramètres suivant ;
— Activer l’authentification EAP
— Définir le temps pendant lequel le switch ne tentera pas d’interroger le serveur Radius si ce dernier
ne répond plus ;
— Définir le serveur Radius sur lequel le switch enverra les paramètres d’authentification des clients
avec le secret partagé ;
— Définir l’activation 802.1X sur un port de test ;
— Définir le VLAN attribué si le client échoue dans le processus d’authentification ;
— Définir l’activation de l’authentification 802.1X au niveau du switch.
aaa authentication port-access eap-radius
radius-server dead-time 10
radius-server host 192.168.2.100 key test123
aaa port-access authenticator 10
aaa port-access authenticator 10 unauth-vid 3
aaa port-access authenticator active
— Configurer le port du switch dans le VLAN LAN ;
HP ProCurve Switch 2626(config)# vlan 2
HP ProCurve Switch 2626(vlan-2)# untagged 10
Warning: Changes on 802.1x port(s) may be postponed.
HP ProCurve Switch 2626(vlan-2)#
Vous devriez désormais pouvoir vous authentifier sur le serveur Freeradius, par l’intermédiaire de votre
certificat client, en utilisant le protocole 802.1X et EAP-TLS depuis l’ordinateur client connecté sur le port du
switch.
Analysez les logs de Freeradius afin d’identifier les différents échanges entre le NAS et le serveur, puis
repérez l’Acces-Accept de la requête de l’utilisateur :
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = 802
Tunnel-Private-Group-Id:0 = "2"
MS-MPPE-Recv-Key = 0x35bf4c3f2776c4b1d2610c7ea9095efeaa39892037
MS-MPPE-Send-Key = 0x30d8a021633528dd2e8f6d6c5f7bf51b19b9c48acc
EAP-Message = 0x03070004
User-Name = "[email protected]"
Finished request 35.
22
VIII. Déploiement du serveur Mysql, et configuration de Freeradius
Si vous réitérez cette opération en annulant la sélection du certificat lorsque Windows vous demande de
fournir des éléments supplémentaires pour valider l’authentification (cf. figure I.13 21), vous devriez basculer
automatiquement dans le VLAN 3 Public, réseau public dans notre exemple.
Dans les prochains chapîtres, nous allons déployer un serveur de bases de données pour nous simplifier
l’exploitation de la gestion des utilisateurs et des NAS.
VIII
Déploiement du serveur Mysql, et configuration de Freeradius
Le but est de déployer les services MySQL, Apache2 et phpmyadmin pour administrer notre base de
données Radius, et le composant permettant a Freeradius d’interroger une base MySQL pour vérifier les
utilisateurs, leurs attributs et les NAS.
1.
Installation
Dans un premier temps, on installe les paquets nécessaires :
apt-get install freeradius-mysql php5 libapache2-mod-php5 php5-mysql mysql-server
apache2 phpmyadmin
Dans l’ordre, nous allons :
1. Créer une base de données pour Freeradius : radius ;
2. Créer un utilisateur pour cette base de données en lui donnant un privilège administrateur, en lui
définissant un mot de passe ;
3. Créer la structure des tables par défaut ;
4. Créer la structure de la table NAS ;
Remarque :
Le mot de passe de l’utilisateur root de MySQL est ici toor a .
a. Ce qui n’est pas bien ... du tout.
# echo "create database radius;" | mysql -u root -ptoor
# echo "grant all on radius.* to radius@’%’ identified by ’radius’;\
flush privileges;" | mysql -u root -ptoor
# mysql -uroot -ptoor radius < /etc/freeradius/sql/mysql/schema.sql
# mysql -uroot -ptoor radius < /etc/freeradius/sql/mysql/nas.sql
Soit par l’intermédiaire de l’application web phpmyadmin, soit directement par la console MySQL vérifiez la présence de la base et des tables dédiées à Freeradius.
Depuis le fichier de configuration général de Freeradius (radiusd.conf), on active les directives nécessaires pour MySQL. Ensuite, on édite le fichier de configuration de Freeradius définissant l’accès à la base de
données radius - (ajustez les directives en fonction des choix réalisés au dessus). Pensez à forcer Freeradius
à lire ses clients depuis la base par la table nas.
23
# nano /etc/freeradius/radiusd.conf
$INCLUDE sql.conf
$INCLUDE sql/mysql/counter.conf
# nano /etc/freeradius/sql.conf
sql {
database = "mysql"
driver = "rlm_sql_${database}"
server = "localhost"
login = "radius"
password = "radius"
radius_db = "radius"
acct_table1 = "radacct"
acct_table2 = "radacct"
postauth_table = "radpostauth"
authcheck_table = "radcheck"
authreply_table = "radreply"
groupcheck_table = "radgroupcheck"
groupreply_table = "radgroupreply"
usergroup_table = "radusergroup"
deletestalesessions = yes
sqltrace = no
sqltracefile = ${logdir}/sqltrace.sql
num_sql_socks = 5
connect_failure_retry_delay = 60
lifetime = 0
max_queries = 0
readclients = yes
nas_table = "nas"
$INCLUDE sql/${database}/dialup.conf
}
Nous allons maintenant modifier le fichier déclarant les requêtes réalisées par Freeradius pour interroger
la table MySQL. En effet, lors des tests réalisés dans la préparation de ce TP, il a été nécessaire de désactiver le
champ server, pour valider certaines opérations.
# nano /etc/freeradius/sql/mysql/dialup.conf
nas_query = "SELECT id, nasname, shortname, type, secret FROM ${nas_table}"
Afin de rendre plus propre la configuration de notre serveur d’authentification, nous allons supprimer les
liens symboliques existant situés dans le répertoire /sites-enabled/ et nous allons créer notre propre fichier de configuration. Respectez cependant le fonctionnement de base de Freeradius en plaçant votre fichier
de déclaration dans /site-available/ et en lui faisant pointer un lien symbolique dans /sites-enabled/.
24
Voici une proposition de déclaration de notre site :
authorize {
preprocess
eap {
ok = return
}
expiration
logintime
sql
}
authenticate {
Auth-Type CHAP {
chap
}
eap
}
preacct {
preprocess
acct_unique
}
accounting {
detail
radutmp
}
session {
radutmp
sql
}
post-auth {
exec
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
pre-proxy {
}
post-proxy {
eap
}
Une fois la déclaration de notre site opérationnelle, nous devons déclarer explicitement les NAS (ou
clients, ou authenticator) autorisés à réaliser les processus d’authentification entre nos utilisateurs et notre serveur d’authentification.
Utilisez la commande suivante pour déclarer notre NAS dans la table adéquate :
# echo "INSERT INTO nas(nasname,shortname,type,secret,server) VALUES \
(’192.168.2.159’,’hp2626’,’other’,’test’,’’)" | mysql -u radius -pradius radius
25
Faites de même pour les autres NAS que vous souhaitez exploiter.
Relancez enfin votre serveur Freeradius toujours en mode debug, pour vérifier si vous n’avez pas d’erreur de configuration. Validez également la configuration en testant un utilisateur à l’aide de son certificat, et
l’utilisateur foobar. Tentez de comprendre pourquoi ... ou passez à la suite.
L’utilisateur foobar ne peut se connecter car il a été initialement déclaré dans le fichier users. Dans la
configuration de notre site tp-radius, nous avons désactivé la directive files dans la section authorize,
en autorisant uniquement eap et sql. Ainsi l’utilisateur foobar n’est plus un utilisateur déclaré pour notre Freeradius.
Pour l’ajouter, procédez ainsi :
echo "INSERT INTO radcheck(UserName,Attribute,op,Value) VALUES \
(’foobar’,’Cleartext-Password’,’:=’,’foobar’);" | mysql -u
\ radius -pradius radius
Concernant l’utilisateur [email protected] possédant un certificat lié à l’autorité de certification et au
certificat serveur de notre Debian, il a la capacité de s’authentifier car la directive eap est déclarée dans notre
fichier de configuration de site.
Le fait que eap soit une méthode d’authentification sans autre contrôle pose un réel problème ici ...
Quel que soit le certificat valide présenté, donc authentique et non révoqué, notre utilisateur le possédant
sera automatiquement accepté. C’est le problème de notre solution. Nous ne disposons pas ici d’une réelle
PKI, permettant facilement de révoquer pour x raisons le certificat d’un client. Ainsi nous ne sommes pas en
mesure de désactiver un utilisateur s’authentifiant par un certificat par le biais du protocole EAP-TLS.
Pour pallier cette faille, nous allons contourner un peu le fonctionnement natif cette méthode en ajoutant
un contrôle supplémentaire nous assurant un contrôle réel sur nos utilisateurs. Nous allons désactiver dans la
section authorize la directive eap, pour ne la laisser que dans authenticate.
Ainsi notre site tp-radius :
authorize {
preprocess
eap {
ok = return
}
expiration
logintime
sql
}
authenticate {
Auth-Type CHAP {
chap
}
eap
}
... devient :
26
authorize {
preprocess
expiration
logintime
sql
}
authenticate {
Auth-Type CHAP {
chap
}
eap
}
Ainsi, même si le processus d’authentification est autorisée par Freeradius lors d’une tentative EAP-TLS
valide par les certificats, nous bloquons par défaut l’autorisation aux ressources par ce procédé. L’utilisateur
est ainsi rejeté.
Si vous retentez de vous connecter à l’aide de votre utilisateur possédant un certificat, vous devriez être
rejeté par Freeradius, et le debug devrait correspondre à :
[...]
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user
Failed to authenticate the user.
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/tp-radius
+- entering group REJECT {...}
[attr_filter.access_reject]
expand: %{User-Name} -> [email protected]
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Sending delayed reject for request 0
Sending Access-Reject of id 45 to 192.168.2.159 port 1024
Nous devons cependant permettre à nos utilisateurs possédant un certificat valide de s’authentifier par le
serveur Freeradius. Pour cela, nous allons nous appuyer sur la table radgroupcheck, en déclarant un groupe
autorisé à utiliser la méthode EAP pour s’authentifier :
mysql> insert into radgroupcheck (GroupName,Attribute,op,Value) values \
(’eap-group’,’Auth-Type’,’:=’,’EAP’);
Query OK, 1 row affected (0.00 sec)
Maintenant, associez vos utilisateurs possédant un certificat valide à ce groupe par l’intermédiaire de la
table radusergroup :
27
mysql> insert into radusergroup (UserName,GroupName) values \
(’[email protected]’,’eap-group’);
Query OK, 1 row affected (0.00 sec)
Vous devriez désormais pouvoir authentifier vos utilisateurs possédant un certificat valide, et présents
dans le groupe eap-group que nous venons de créer.
MS-MPPE-Recv-Key = 0x170063a9c22c5198946a7043221e2c775735a91e3ebcac657cc5772cb386945e
MS-MPPE-Send-Key = 0xa5a6517975829590bdcc59b1b75cf8860f4d82a71b9e6f9def6a877b102df715
EAP-Message = 0x03070004
User-Name = "[email protected]"
Finished request 7.
Nous allons maintenant nous pencher sur l’attribution dynamique des vlan associés à nos utilisateurs
authentifiés par le protocole 802.1X. Nous avons pour le moment forcé les utilisateurs dans un vlan (untag 2),
et nous avons demandé à notre switch de les basculer dans un vlan public si l’authentification 802.1X échouait.
Cela fonctionne mais ce fonctionnement reste très limité. En effet, par cette méthode, nous ne pouvons
forcer un étudiant de BTS SIO a basculé dans un vlan dédié, quelque soit le switch et le port sur lequel il se
connecterait.
Pour permettre aux administrateurs de forcer chaque utilisateur a utiliser un vlan particulier, nous allons
exploiter trois attributs RADIUS par l’intermédiaire de la table radgroupreply.
— Réaliser les requêtes SQL pour arriver au résultat suivant :
mysql> SELECT * FROM radgroupreply;
+----+-----------+-------------------------+----+----------+
| id | groupname | attribute
| op | value
|
+----+-----------+-------------------------+----+----------+
|
|
1 | eap-group | Tunnel-Type
2 | eap-group | Tunnel-Medium-Type
| =
| =
|
3 | eap-group | Tunnel-Private-Group-ID | =
| VLAN
|
| IEEE-802 |
| 2
|
+----+-----------+-------------------------+----+----------+
3 rows in set (0.00 sec)
Ces attributs forcent les utilisateurs du groupe eap-group à basculer lors d’une authentification réussie
dans le vlan 2 LAN. Modifiez la configuration du port du switch sur lequel vous testez votre client à utiliser le
vlan 3 untag.
Cette solution permet donc d’activer tous les ports de plusieurs actifs paramétrés en 802.1X, de paramétrer avec un vlan public cette authentification échouait, et, en fonction de l’utilisateur, l’associer à groupe
le renvoyant dans son vlan attitré.
Réitérez les tests et vérifier le fonctionnement.
28
IX. Annexes
IX
1.
Annexes
Autentification Radius-MAC
L’authentification par Radius-MAC est la solution la plus simple à mettre en oeuvre. Vu la facilité d’ur-
super une adresse mac, elle est cependant à éviter.
La configuration de Freeradius ne demande que l’activation de l’autorisation et de l’authentification
CHAP.
La déclaration d’un utilisateur correspond à :
50465D38F676 Auth-Type := Local, User-Password == 50465D38F676
Tunnel-Type = VLAN,
Tunenl-Private-Group-ID = 2
Concernant la configuration du switch 2626 (non native sur le 2960G) :
radius-server host 192.168.2.100 key secret
aaa port-access mac-based addr-format no-delimiter
aaa port-access mac-based 10
Concernant la configuration du serveur Freeradius, il suffit d’activer l’authentification CHAP dans les
sections authorize et authenticate.
2.
Cumul d’une authentification EAP-TLS et Radius-MAC
Il s’agit ici d’authentifier la machine elle-même. Nous avons vu que la simple adresse MAC n’était pas
suffisamment fiable pour être utilisé comme seul moyen. Une autre méthode consiste à créer un certificat
pour chaque machine. Le supplicant est configuré pour EAP-TLS et avec le certificat de la machine. Si le CN du
certificat correspond au nom fqdn de la machine, alors on peut déclarer notre utilisateur ainsi :
pc-l-laforet Auth-Type := EAP, Calling-Station-Id == 50465D38F676
Tunnel-Type = VLAN,
Tunenl-Private-Group-ID = 2
3.
Configuration d’un actif Cisco 2960G
Cas d’un Cisco 2960G :
aaa new-model
aaa authentication dot1x default group radius
dot1x system-auth-control
aaa authorization network default group radius
radius-server host 192.168.2.100 auth-port 1218 key test123
interface fastEthernet 0/10
switchport mode access
dot1x port-control auto
radius-server dead-criteria time 5 tries 3
radius-server deadtime 10 minutes
29
IX. Annexes
4.
Intégration de Freeradius et Active Directory
Le but de cette section est de proposer une solution pour intégrer notre serveur Freeradius dans un
domaine Active Directory existant. Un domaine Windows peut uniquement assurer le rôle d’authentification.
Il faudra disposer d’une autre solution pour gérer l’autorisation (fichier, base MySQL ...). L’utilisation d’un
domaine Windows est intéressante lorsque ce domaine est existant, et surtout qu’il possède l’ensemble des
comptes des utilisateurs d’une entreprise.
L’intérêt est donc d’interroger la base Windows avec l’identifiant fournir par le supplicant pour valider
son authentification grâce à son mot de passe.
La seule contrainte est de déployer sur notre serveur trois rôles supplémentaires :
1. samba : nécessaire pour joindre notre serveur Freeradius à notre domaine Windows existant.
2. kerberos : nécessaire pour dialoguer et échanger les mots de passe entre samba et notre CPD.
3. winbind : nécessaire pour lier samba au domaine Windows.
Pour réaliser l’intégration de notre authentification Freeradius par l’intermédiaire de notre contrôleur
principal de domaine, il est nécessaire de réaliser les opérations suivantes :
1. Installer les paquets nécessaires ;
2. Configurer le fichier de configuration smb.conf ;
3. Configurer le fichier kerb5.conf ;
4. Configurer le fichier ntlm_auth ;
5. Joindre le serveur Freeradius au domaine Active Directory Windows ;
6. Tester la jonction au domaine ;
7. Ajouter l’authentification MSCHAP à notre serveur Freeradius ;
8. Tester l’authentification d’un utilisateur.
root@srvm-freeradius-02:~# apt-get install samba krb5-user winbind
Répondre aux questions pour valider la liaison de Kerberos au domaine Windows existant. Éditons le
fichier de configuration de samba.
root@srvm-freeradius-02:~# nano /etc/samba/smb.conf
workgroup = AUTH-REZO
security = ads
winbind use default domain = no
password server = windows-2008.auth-rezo.adds
wins server = 192.168.2.200
realm = realm.AUTH-REZO.ADDS
Activons le domaine Windows sur le module ntlm_auth :
root@srvm-freeradius-02:/etc/freeradius# cat modules/ntlm_auth
exec ntlm_auth {
wait = yes
program = "/usr/bin/ntlm_auth --request-nt-key --domain=AUTH-REZO
30
IX. Annexes
--username=%{mschap:User-Name}
--password=%{User-Password}"
}
Éditons le fichier de configuration /etc/freeradius/modules/mschap :
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None}
--domain=%{%{mschap:NT-Domain}:-AUTH-REZO}
--challenge=%{mschap:Challenge:-00}
--nt-response=%{mschap:NT-Response:-00}"
Activons l’authentification ntlm_auth :
authenticate {
...
ntlm_auth
...
}
Joignons le serveur au domaine Windows (la configuration de vos DNS et de votre FQDN est important) :
root@srvm-freeradius-02:~# cat /etc/resolv.conf
domain auth-rezo.adds
search auth-rezo.adds
nameserver 192.168.2.200
root@srvm-freeradius-02:~# net join -U Administrateur -w WINDOWS
Enter Administrateur’s password:
Using short domain name -- AUTH-REZO
Joined ’RADIUS-02’ to realm ’auth-rezo.adds’
root@srvm-freeradius-02:~# net rpc testjoin
Join to ’AUTH-REZO’ is OK
Effectuons différents tests pour valider notre configuration :
root@debian:# wbinfo -a tyty%pass
plaintext password authentication failed
Could not authenticate user tyty%pass with plaintext password
challenge/response password authentication succeeded
root@debian:# ntlm_auth --request-nt-key --domain=AUTH-REZO --username=tyty --password=pass
NT_STATUS_OK: Success (0x0)
root@debian:#
Réalisons un premier test pour valider la configuration :
root@debian:~# radtest -t mschap tyty pass localhost 0 testing123
Sending Access-Request of id 12 to 127.0.0.1 port 1812
31
IX. Annexes
User-Name = "tyty"
NAS-Port = 0
MS-CHAP-Challenge = 0x146ccadf37ec919d
MS-CHAP-Response = 0x0001000000000000000000000000000000000000000000000000b5a6e2d403e5e1663d
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=12, length=84
MS-CHAP-MPPE-Keys = 0x00000000000000000c075e1ae8ab7c564e629b0b4d2331330000000000000000
MS-MPPE-Encryption-Policy = 0x00000001
MS-MPPE-Encryption-Types = 0x00000006
root@debian:~#
32

Proposition de sécurisation d`un réseau à l`aide des protocoles

Transcription

Documents pareils

Formation Freeradius en pdf

Mohamad DIB

- pronetis

Serveur RADIUS avec MySQL pour authentification sur

LR248 Boulevard Bir Anzarane, Casablanca, Maroc 8 000 Dhs par

Contrôle d`Accès : Authentification Forte, Kiosque…

Télécharger

Installation de FreeRadius avec EAP