sudo + RADIUS : 2FA sur CentOS 7 et Ubuntu 14.04

Ce guide explique comment intégrer un serveur RADIUS (par ex. WiKID, FreeRADIUS ou NPS) à sudo via PAM pour activer l’authentification à deux facteurs (2FA) sur CentOS/RHEL 7 et Ubuntu 14.04. Inclut étapes d’installation, configuration, tests, scénarios d’échec, options alternatives et vérifications post-déploiement.

Important: sauvegardez les fichiers PAM et testez avec une session non privilégiée avant de déployer en production.

But et variantes de recherche

But principal: ajouter RADIUS à sudo pour 2FA. Variantes recherchées courantes: sudo RADIUS 2FA, libpam-radius-auth CentOS, pam_radius_auth Ubuntu, WiKID Strong Authentication, FreeRADIUS sudo PAM.

Contexte rapide

Les attaquants exploitent souvent des identifiants perdus, volés, faibles ou par défaut pour élever leurs privilèges. L’ajout d’une seconde preuve (OTP) réduit fortement ce risque. PAM permet d’insérer un serveur RADIUS pour déléguer l’autorisation (via AD/NPS) et l’authentification 2FA (via WiKID, FreeRADIUS, Duo, etc.).

Prérequis

Accès root ou sudo sur les serveurs CentOS/RHEL 7 et Ubuntu 14.04.
Serveur RADIUS opérationnel (WiKID, FreeRADIUS, NPS) et secret partagé.
Sauvegarde des fichiers PAM avant modification.

Astuce: tester localement avec 127.0.0.1 avant d’ajouter le serveur RADIUS distant.

Installer et configurer pam_radius sur CentOS/RHEL 7

Installez les prérequis:

sudo yum -y install make gcc pam pam-devel

Téléchargez le code PAM RADIUS (vérifiez la version actuelle sur le site FreeRADIUS):

wget ftp://ftp.freeradius.org/pub/radius/pam_radius-x.x.x.tar.gz

Construisez la bibliothèque:

tar -xzvf pam-radius-x.x.x.tar.gz
cd pam-radius-x.x.x
sudo ./configure
sudo make

Copiez la bibliothèque au bon emplacement:

cp pam_radius_auth.so /lib/security/

Ou pour les systèmes 64 bits:

cp pam_radius_auth.so /lib64/security/

Créez le répertoire de configuration et copiez le fichier de config sous le nom “server”:

sudo mkdir /etc/raddb
cp pam_radius_auth.conf /etc/raddb/server

Éditez /etc/raddb/server et ajoutez l’IP du serveur RADIUS et le secret partagé. Exemple:

# server[:port] shared_secret     timeout (s)
127.0.0.1       secret             1
radius_server_IP    secret          3
#
# avoir localhost dans la configuration RADIUS est recommandé.

Remarque: vous pouvez pointer vers votre serveur WiKID local pour des tests rapides en ajoutant cette machine en tant que client réseau sur WiKID.

Configurez sudo pour utiliser RADIUS. Éditez /etc/pam.d/sudo et remplacez la ligne auth include system-auth par:

auth       required      pam_radius_auth.so

Ceci force sudo à utiliser le module RADIUS pour l’authentification.

Installer et configurer pam_radius sur Ubuntu 14.04

Installez le paquet:

sudo apt-get install libpam-radius-auth

Éditez /etc/pam_radius_auth.conf pour ajouter le serveur RADIUS et le secret, comme ci‑dessous:

# server[:port] shared_secret     timeout (s)
127.0.0.1       secret             1
radius_server_IP   secret          3
#
# avoir localhost dans la configuration RADIUS est recommandé.

Modifiez /etc/pam.d/sudo. Ajoutez la ligne auth sufficient pam_radius_auth.so au-dessus de @include common-auth.

Exemple de fichier /etc/pam.d/sudo:

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth sufficient pam_radius_auth.so
@include common-auth
@include common-account
@include common-session-noninteractive

Cela permet au module RADIUS d’authentifier l’utilisateur via OTP avant que common-auth ne prenne le relais.

Tester la configuration

Test de base:

Ouvrez une nouvelle session SSH non privilégiée.
Lancez sudo -l pour vérifier que sudo fonctionne.
Lancez une commande nécessitant sudo, par exemple sudo whoami.
Entrez votre mot de passe puis l’OTP si le serveur RADIUS le demande.

Critères d’acceptation:

Les utilisateurs valides reçoivent la demande d’OTP et se voient accorder l’élévation après validation.
Les OTP invalides ou expirés sont refusés.
Si le serveur RADIUS est injoignable, la politique PAM doit définir le comportement souhaité (blocage ou fallback). Ne laissez pas un échec RADIUS forcer la levée de privilèges.

Cas de test (exemples):

utilisateur connu + OTP valide => réussite
utilisateur connu + OTP invalide => échec
utilisateur inconnu => échec
serveur RADIUS injoignable => comportement conforme à la politique (échec sûr recommandé)

Scénarios d’échec et contremesures

Quand cela peut échouer:

Erreur de secret partagé ou IP incorrecte dans /etc/raddb/server ou /etc/pam_radius_auth.conf.
Pare-feu bloquant le port RADIUS (UDP 1812 ou 1645 selon configuration).
Problèmes de latence provoquant des timeouts trop courts.

Mitigations:

Tester la connectivité RADIUS depuis la machine (nc/rs) et vérifier les logs RADIUS.
Augmenter le timeout si nécessaire.
Avoir un compte d’administration d’urgence accessible via console ou session locale pour réparer PAM.

Rollback rapide:

Restaurer la copie sauvegardée de /etc/pam.d/sudo ou retirer la ligne pam_radius_auth.so.
Redémarrer la session SSH et vérifier l’accès sudo local.

Alternatives et approches complémentaires

Duo Security / Okta MFA / Yubico: solutions commerciales fournissant du PAM et des agents pour sudo.
Google Authenticator PAM: solution locale via TOTP sans serveur RADIUS central.
SSH avec clés et confirmation 2FA côté serveur : verrouiller l’accès root et exiger 2FA pour élévation.

Choix d’approche: si vous gérez un annuaire central (Active Directory), utiliser RADIUS/NPS + serveur 2FA externe permet une séparation claire entre autorisation et authentification.

Sécurité et confidentialité

Données envoyées au serveur RADIUS: nom d’utilisateur et secret/OTP. Minimisez les logs côté réseau.
Utilisez des canaux sécurisés entre composants (VPN/segment réseau sécurisé) pour réduire l’exposition des secrets partagés.
Conservez les secrets partagés de manière sécurisée et changez-les si compromis.
Conformité: l’utilisation de 2FA pour comptes administratifs peut répondre à des exigences réglementaires (ex. PCI DSS) selon l’implémentation et le périmètre.

Compatibilité et notes de migration

Ce guide cible CentOS/RHEL 7 et Ubuntu 14.04. Le même principe s’applique aux versions 5/6 de RHEL/CentOS ainsi qu’à des versions Ubuntu légèrement plus récentes, mais vérifiez les chemins de bibliothèques (/lib vs /lib64) et les noms de paquets.
Pour des distributions modernes, préférez les paquets précompilés (libpam-radius-auth) fournis par la distribution.

Checklist rôle-based avant déploiement

Administrateur système:

[ ] Sauvegarder /etc/pam.d/sudo et /etc/pam.d/common-auth le cas échéant.
Vérifier connectivité UDP vers le serveur RADIUS.
Tester localement avec 127.0.0.1 si possible.
Documenter procédure de rollback.

Responsable sécurité:

Valider la politique de timeout et comportement en cas d’échec RADIUS.
Vérifier la rotation des secrets partagés.

Opérations réseau:

Ouvrir les ports UDP nécessaires (1812/1645).
Mettre en place monitoring des tests RADIUS.

Diagramme de décision

flowchart TD
  A[Déployer 2FA pour sudo?] --> B{Avez-vous un serveur RADIUS central?}
  B -- Oui --> C[Configurer pam_radius sur les serveurs et ajouter client RADIUS]
  B -- Non --> D{Voulez-vous une solution commerciale?}
  D -- Oui --> E[Utiliser Duo/Okta agent PAM]
  D -- Non --> F[Utiliser Google Authenticator TOTP local]
  C --> G[Tester en session non-privilegiée et plan de rollback]
  E --> G
  F --> G

Résumé et bonnes pratiques

Intégrer RADIUS à sudo via pam_radius permet d’ajouter une couche 2FA pour l’élévation des privilèges.
Testez toujours sur une machine non critique et conservez un accès d’urgence pour corriger PAM si nécessaire.
Contrôlez la connectivité réseau, les secrets partagés et les politiques de timeout.
Envisagez des solutions commerciales si vous souhaitez un support, une intégration SSO ou des fonctionnalités avancées.

Notes

Important: modifier PAM peut bloquer l’accès administratif si mal fait. Toujours garder une session root active ou un accès console alternatif lors de la modification.

Fin du guide.