ORappel
L’objectif de cette série d’articles est de bâtir un cloud privé depuis le début.
Nous avons abordé l’architecture de référence Open Stack, l’architecture technique et l’architecture réseau.
Nous allons rajouter dans cette architecture réseau, les services minimums :
– annuaire des utilisateurs
– serveur de temps
– serveur dhcp
– serveur dns
La finalité est que les problèmes liés à l’infrastructure ne soit pas dans les root case des incidents de notre plateforme. De plus, ces services sont indispensable lors des mitigations de sécurité.
En résumé, nous allons mettre un serveur central (qui pourra être redondé, cela fera partie d’un article complémentaire) et une gestion d’un template de service qui contient l’inclusion et la déclaration client de ces services.
Serveur LDAP
Le service LDAP va héberger les fonctions d’authentification, les zones dns et la configuration dhcp. Cela apporte à ces services une gestion dynamic (sans redémarrage) et une réactivité aux changements de configuration de la plateforme.
Les étapes de la configuration de ce serveur que nous appellerons annuaire :
– installation d’une VM Debian 10
– installation de Openldap et sécurisation des flux avec TLS
– installation et configuration de Fusiondirectory, une application centralisée qui gère les utilisateurs, les zones dns, les configurations dhcp
– déclaration d’utilisateur dans l’annuaire
– intégration de l’authentification système (OS) avec comme fournisseur d’identité LDAP
– gestion des clés SSH depuis l’annuaire
– gestion de SUDO depuis l’annuaire
– configuration du service DHCP avec LDAP
– configuration du service DNS avec LDAP
Installation d’une VM debian 10
La VM annuaire fonctionnera sur le réseau admin et uniquement celui-ci. On installe donc celui-ci avec la commande suivante
virt-install --name annuaire \ --ram 2048 --vcpus 2 \ --disk path=/var/lib/libvirt/images/annuaire.qcow2,size=20 \ --os-type linux --os-variant debian10 \ --network network=admin,model=virtio --graphics vnc \ --console pty,target_type=serial \ --location 'http://ftp.debian.org/debian/dists/stable/main/installer-amd64/' \ --extra-args 'console=ttyS0,115200n8 serial'
Choisissez une installation de base avec service ssh.
Après l’installation de l’OS, nous pouvons procéder à la configuration de système. C’est à dire définir statiquement l’adresse ip et son hostname:
ip : 192.168.200.10/24
gateway : 192.168.200.1
dns : 192.168.200.1
hostname : annuaire.lab.ezydata.fr
Le DNS sera changé au moment de l’installation de bind9. Ces configurations s’effectuent dans le fichier de configuration /etc/network/interfaces
OpenLDAP avec certificat public/privé
La nouvelle procédure d’installation OpenLDAP récupère les informations du FQDN saisie lors de l’installation OS. Dans notre cas, la base dc=lab,dc=ezyddata,dc=fr nous convient. Si vous devez le changer, alors saisissez dpkg-reconfigure slapd.
sudo apt -y slapd ldap-utils
création d’un certificat pour le serveur annuaire
Nous allons sécurisé les flux réseaux par le chiffrement TLS avec l’utilisation de certificats. Par conséquent la création de certificat ne diffère pas de ceux pour le VPN.
Remarque : la deuxième commande sert à enlever le mot de passe du certificat.
Remarque : ce certificat sera aussi utilisé par Apache. Nous nous attarderons à gérer des certificats avec un SAN (subject Alternative Name) dans un autre article.
jph@ezydata:~/jphCA$ OPENSSL_CONFIG="-config ./openssl.cnf" ./CA.pl -newreq ... Common Name (e.g. server FQDN or YOUR name) []:annuaire.lab.ezydata.fr ... jph@ezydata:~/jphCA$ OPENSSL_CONFIG="-config ./openssl.cnf" ./CA.pl -sign ... jph@ezydata:~/jphCA$ mv newkey.pem jphCA/private/annuaire.lab.ezydata.fr.key jph@ezydata:~/jphCA$ mv newcert.pem jphCA/certs/annuaire.lab.ezydata.fr.pem jph@ezydata:~/jphCA$ scp jphCA/private/annuaire.lab.ezydata.fr.key \ jphCA/certs/annuaire.lab.ezydata.fr.pem \ jphCA/cacert.pem \ secours@192.168.200.10:/home/secours
Déclaration de l’autorité de certification
Il est important que l’autorité de certification soit intégré dans l’OS afin que les commandes ou services reposant sur OpenSSL reconnaisse notre certificat comme valide.
C’est de cette façon que les certificats tel verisign et consort sont intégré au système et qui nous permet de visiter des sites dont les certicats sont émis par eux d’être considérés comme valide.
Cela nous permet surtout de ne plus nous soucier d’inclure l’autorité de certification dans tous les services avec SSL/TLS.
root@annuaire:~# cp /home/secours/cacert.pem /usr/local/share/ca-certificates/ezydata.crt root@annuaire:~# update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. #verifier que le certificat root a été bien installé dans le système root@annuaire:~# openssl verify /home/secours/annuaire.lab.ezydata.fr.pem /home/secours/annuaire.lab.ezydata.fr.pem: OK root@annuaire:~# mkdir /etc/ssl/openldap
Configuration de OpenLDAP pour la prise en charge de SSL/TLS
Si vous avez déjà utilisé OpenLDAP dans les versions précédentes, la configuration de celui-ci pouvait être par fichier de configuration ou directement via la base config.
Par défaut dans les versions de Debian 10, c’est la configuration par database qui est défini. C’est pourquoi, il faut utiliser des commandes de type ldapmodify et des fichiers ldif ayant une structure particulière. Ce fichier est structuré de la manière suivante :
– première ligne le noeud sur lequel nous voulons intervenir
– deuxième ligne : le type d’action que l’on souhaite parmis modify, delete(suppression du noeud), modrdn
– troisième ligne et les suivantes (sauf pour delete) : les informations sur l’objet de l’action
– pour modrdn : le nouveau dn: …
– pour modify, le type de modification parmis replace, add, delete. Ces types de modification porte sur les attributs du noeud.
Ce que nous souhaitons faire est de rajouter des attributs aux noeuds cn=config (c’est la portée globales de paramètre de configuration). Ces attributs sont TLSCACertificate, TLSCertificateKeyFile et TLSCertificateFile qui respectivement servent à définir l’autorité de certification servant à signer le certificat public, la clé privé et le certificat public.
Si vous ne partez pas de zéro, il se peut que ces informations soient présents alors l’instruction n’est plus add mais replace.
Remarque 1: OpenLDAP dans cette version ne prend pas en charge les liens symboliques comme cible de ces options.
Remarque 2: si vous avez des erreurs, il se peut que vous ayez des problèmes de droit de lecture par l’utilisateur exécutant slapd. Effectuez un test su – openldap file /etc/ssl/openldap/certificat pour savoir si l’utilisateur peut lire ce fichier.
root@annuaire:~# cat ldap-tls.ldif dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/openldap/ezydata.crt - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.pem root@annuaire:~# ldapmodify -vvvvv -Y EXTERNAL -H ldapi:/// -f ldap-tls.ldif
Vérification de la configuration
Afin déviter des diagnostiques complémentaire, nous allons vérifier la configuration par deux actions simples. L’un consiste à s’assurer que les attributs soient les bons avec les bonnes valeurs et l’autre est de demander à ldap de vérifier la validité de la configuration.
root@annuaire:~# slapcat -b "cn=config" | grep -E "olcTLS" olcTLSCACertificateFile: /etc/ssl/openldap/ezydata.crt olcTLSCertificateKeyFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.key olcTLSCertificateFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.pem root@annuaire:~# slaptest -u config file testing succeeded
redémarrage de Openldap
Si vous redémarrer le daemon slapd tel quel, vous n’aurez pas une sécurisation de flux (à moins de demander start tls par le client) car celui-ci n’écoute pas sur le port 636 (port ldaps). Pour cela, nous devons modifier le fichier de configuration se trouvant /etc/default/slapd.
sudo sed -i 's/\(^SLAPD_SERVICES=\)\(.*\)/\1"ldap:\/\/\/ ldaps:\/\/\/ ldapi:\/\/\/"/' /etc/default/slapd sudo systemctl restart slapd
Gestionnaire utilisateur et service réseau : FusionDirectory
A moins d’être un pur défense de la ligne de commande, je vous propose d’utiliser un front end qui aura comme fonction de gérer les utilisateurs systèmes (créer, supprimer, modifier), la configuration dhcp, les zones dns, la configuration sudo, les attributs SSH des utilisateurs.
C’est une alternative à FreeIPA ou d’autre produit commerciaux.
Il repose sur PHP et un serveur web (par default Apache) et se marie très bien avec OpenLDAP.
Son installation va ramener toutes les dépendances dont il a besoin. L’architecture de FusionDirectory repose entièrement sur un annuaire ldap. Toutes sa configuration est portée par l’annuaire hormis les déclarations d’accès à ce même annuaire.
Tout installation les modules (ou plugin) et core repose à l’installation des fichiers php et l’inclusion des schémas dans l’annuaire.
installation du noyau FusionDirectory
Comme évoquer précédemment, l’installation de celui-ci nécessite l’utilisation du gestionnaire de package et de l’utilitaire d’insertion de schéma propre à fusiondirectory.
sudo apt-get install fusiondirectory fusiondirectory-schema #insertion du schema fusiondirectory sudo fusiondirectory-insert-schema
sécurisation de flux http
Comme l’annuaire va servir à gérer les utilisateurs systèmes. Les flux réseaux comportent des données sensibles. Nous allons activé TLS sur le serveur Apache en réutilisant le certificat utilisé pour OpenLDAP; le FQDN est le même.
Il faut activer le module ssl et le site ssl par défaut. Copier les certifcats aux bon endroits.
Après cela un redémarrage du serveur Apache est nécessaire.
root@annuaire:/etc/apache2# a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
systemctl restart apache2
root@annuaire:/etc/apache2# a2ensite default-ssl
...
root@annuaire:/etc/apache2# cp /etc/ssl/openldap/annuaire.lab.ezydata.fr.* /etc/ssl/apache/
root@annuaire:/etc/apache2# chown -R www-data: /etc/ssl/apache
root@annuaire:~# grep -vE '^#|^ *$|^[[:space:]]*#' /etc/apache2/sites-enabled/default-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@ezydata.fr
ServerName annuaire.lab.ezydata.fr
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCertificateFile /etc/ssl/apache/annuaire.lab.ezydata.fr.pem
SSLCertificateKeyFile /etc/ssl/apache/annuaire.lab.ezydata.fr.key
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</IfModule>
root@annuaire:/etc/apache2# systemctl restart apache2
root@annuaire:/etc/apache2# netstat -nap | grep apache
tcp6 0 0 :::80 :::* LISTEN 17474/apache2
tcp6 0 0 :::443 :::* LISTEN 17474/apache2
Base des utilisateurs système
L’objectif premier d’un annuaire d’entreprise est de gérer les utilisateurs systèmes. Aussi, ce chapitre aborde ce sujet avec comme critère la simplicité et la périnité de la solution.
Il existe à l’heure actuelle deux façon d’intégrer un système linux avec une authentification via un annuaire :
– ldap/nss
– sssd
Malgré son lien fort avec FreeIPA, la solution sssd est la nouvelle génération d’outil client pour gérer les fournisseurs d’identité. Il a en autre une option d’intégration avec un annuaire Microsoft. Ce qui sera un bon candidat si dans votre entreprise vous avez ce fournisseur d’identité.
Notre choix se porte donc sur SSSD en tant que client système pour l’intégration aux fournisseurs d’identité LDAP.
root@annuaire:/etc/apache2# apt-get install sssd-ldap sssd-tools
De base, l’installation ne créer pas de fichier de configuration. Il est nécessaire d’en créer un à partir de rien. La documentation (man sssd.conf) contient toutes les informations importantes sur les directives globaux et celui de sssd-ldap plus particulièrement pour les fournisseurs de type annuaire.
Voici le fichier de configuration /etc/sssd/sssd.conf
[sssd] services = nss, pam config_file_version = 2 domains = ezydata [nss] [pam] [domain/ezydata] id_provider = ldap ldap_uri = ldap://localhost ldap_search_base = dc=lab,dc=ezydata,dc=fr auth_provider = ldap cache_credentials = true
A ce stade, vous devez avoir les utilisateurs de l’annuaire présent dans la base système (command getent). Comme, nous n’avons pas encore créer d’utilisateur, c’est normal qu’il soit vide. Par défaut, à l’installation de sssd, le packageur Debian est inclus les directives dans les fichiers de configuration de nsswitch et pam.d les informations nécessaire à l’utilisation de sssd comme fournisseur d’identité.
Cependant, il manque encore l’automatisation de la création du répertoire home de l’utilisateur. En soit, c’est un choix qui s’appuie sur le retour d’expérience de grand déploiement qui héberge les homedirectory dans des points de montage. Dans notre cas, nous préférons un homedirectory local. Pour ce faire, il faut rajouter dans le fichier /etc/pam.d/common-session la directive
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
juste après pam_sss.so
Création du premier utilisateur
Avec l’interface graphique FusionDirectory, nous allons créer un utilisateur pour notre plateforme cloud.
Par la même occasion, nous allons créer une OU spéciale pour ce service que nous nommerons cloud.
Pour que l’utilisateur puisse avoir des attributs AccountPosix, il faut renseigner l’onglet Unix. FusionDirectory créera automatiquement le groupe associé à l’utilisateur.
id jph
Et vous pourrez alors, vous connecter avec ce même compte.
Sudo-ldap & clé SSH sur ldap
Avoir un annuaire pour gérer les utilisateurs c’est bien, mais aussi pouvoir y configurer certaines autorisations certralisées, c’est encore mieux.
Prenons le cas de sudo et des clés ssh. Il est fastidieux de créer ces configurations et à chaque fois de devoir le spécifier la clé ssh et la configuration sudo pour chaque nouveau serveur. Certains argueront qu’avec l’utilisation d’outil de configuration management tel puppet, chef et consort, il est facile d’arriver à ce même but. Cependant, tous les utilisateurs ne sont pas admin ni ont les compétences pour gérer ces outils. Aussi, avoir un outil graphique permet une adoption plus importante et donc une sécurité accrue.
Sudo-ldap
L’installation de sudo-ldap va désactiver le module sudo de votre système. Pour des raisons de perte d’acces, je vous conseille d’avoir un terminal connecter en tant que root en cas de problème.
Déploiement du module sudo et activation de celui dans fusiondirectory.
apt-get install fusiondirectory-plugin-sudo fusiondirectory-plugin-sudo-schema fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/sudo*
SUDO_FORCE_REMOVE=yes apt-get install sudo-ldap
Si tout s’est bien passé, le support ldap de sudo a été installé. Pour l’activer, deux points importans sont à vérifier:
– le fichier de configuration d’accès à l’annuaire renseigner avec la bonne uri;
– inclure une directive spéciale pour sudo-ldap.
Si on pousse la sécurité à l’extrème, des informations sensibles tel quel groupe à droit à faire quoi dans quel système, nous pouvons restreindre l’accès à l’ou suoders de l’annuaire qu’à un utilisateur spécifique ou un group spécifique. Cela sort du cadre de nos articles mais c’est une bonne pratique à considerer dans des environnements multi-tenants.
fichier /etc/sudo-ldap.conf
jph@annuaire:~$ cat /etc/ldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=lab,dc=ezydata,dc=fr URI ldap://localhost #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt # pour sudo sudoers_base ou=sudoers,ou=cloud,dc=lab,dc=ezydata,dc=fr
Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug
Création d’une règle sudo
Maintenant que les outils ont été configuré, nous allons créer une règle sudo depuis l’interface d’adminsitration de fusiondirectory.
La règle est la suivante : tous les utilisateurs du groupe sudo-ldap auront tous les droits sans avoir besoin de saisir son mot de passe.
création du group sudo-ldap
La règle sudo repose sur un group système or celui-ci n’est pas encore créer. Nous pouvons le faire à travers FusionDirectory. Attention à utiliser un groupposix comme source de group, sans quoi vous n’aurez pas les bons attributs.
clé SSH
Il est possible d’étendre les fonctionnalités d’openSSH pour rajouter d’autre méthode de fourniture de clé ssh. Cela se fait par la directive
AuthorizedKeysCommand
AuthorizedKeysCommandUser
Cette directive va permettre de rajouter d’autre source de clé public autorisé que celui par fichier. Le retour de la commande doit se faire par le STDOUT avec pour chaque ligne la clé publique ssh autorisé à se connecter à ce compte. En argument, ssh passe le nom de l’utilisateur.
La commande peut être écrite en n’importe quel langage pourvu qu’elle respecte ces conditions. Voici ce qui est fait dans notre infrastructure.
jph@annuaire:~$ cat /usr/local/bin/recupere_cle_ldap_ssh
#!/bin/sh
set -eu
log() {
logger -s -t sshd -p "auth.$1" "$2"
}
uid="$1"
if ! expr "$uid" : '[a-zA-Z0-9._-]*$' 1>/dev/null; then
log err "caractere interdit dans le nom d'utilisateur : $uid"
exit 2
fi
keys=$(ldapsearch -x -LLL -o ldif-wrap=no "(&(uid=$uid)(sshPublicKey=*))" \
'sshPublicKey' | sed -n 's/^sshPublicKey:\s*\(.*\)$/\1/p')
echo "$keys"
installation du module ssh dans fusiondirectory
Le daemon va effectuer dans l’ordre, une vérification locale et puis une vérification avec la directive keycommand. Pour renseigner ces attributs, nous allons installer le module ssh de fusiondirectory.
sudo apt-get install fusiondirectory-plugin-ssh \ fusiondirectory-plugin-ssh-schema sudo fusiondirectory-insert-schema /etc/ldap/schema/fusiondirectory/openssh-lpk.schema
Déclaration de clé ssh pour l’utilisateur
Chaque utilisateur peut désormais déclarer sa clé publique afin de se connecter sur les serveurs cloud sans rentrer de mot de passe. S’il fait partie de sudo, il peut aussi exécuter des commandes à la place de quelqu’un d’autre.
Fin de la partie 1/2
Dans cette article, nous avons déployer un annuaire centralisé pour l’identification des utilisateurs de notre cloud. Il permet d’avoir une gestion centralisée des comptes ainsi qu’une partie des autorisations.
La deuxième partie va s’intéresser à la gestion centraliser des systèmes :
DNS
DHCP
NTP