La sécurité, c’est savoir regarder qui est devant sa porte. Avec l’évolution technologique, nous pouvons bénéficier depuis nos smartphones à l’intégralité de notre propriété et autres biens si nous avons choisi de souscrire à une entreprise de surveillance ou d’avoir déployer soit même quelques équipements.

Ces Judas électroniques étaient inexistant il n’y a pas si longtemps. A défaut d’être chez soi et de lorgner dans le Judas pour vérifier qui frappe à la porte (ou s’abandonner au plaisir solitaire du commérage), nous étions bien e******s quand nous n’étions pas chez nous. D’où les systèmes d’alarmes, sirènes qui hurlent et c*****t les c******s du voisinage.

A partir de ce postulat et avec un peu d’imagination, mon domicile c’est mon serveur LINUX. Se pose la question de vérifier qui frappe à la porte, qui rentre, qui rentre pas. Qui se fait kick par Jean-Pierre, notre bon chien (plus petit que Cerbère quand même car il bouffe ce c*n) quand je ne suis pas scotché sur mon système le nez dans mes journaux de log.

Une nouvelle fois je me suis tourné vers une solution purement personnelle. Pourquoi ?

Parce que j’ai pas trouvé chaussure à mon pied…

Afin de répondre à cette question, je vais vérifier si des utilisateurs sont lock et envoyer une notification mail à l’équipe en charge du MCO du serveur. Si ça ne suffit, pas, le mail reviendra tant que le compte n’aura pas été unlock.

Plusieurs raisons peuvent être dû au verrouillage d’un compte :

Syndrome des doigts palmés
Oublie du login, password
Compte non habilité à se connecter
Tentative d’intrusion

Dans la majorité des cas, il résulte du syndrome du palmipède. Le compte est rapidement déverrouillé (par un autre compte ou par un autre biais). Dans le dernier cas, il convient d’éplucher les journaux et de mettre rapidement des mesures pour isoler et interdire les IPs sources ayant tenter de s’authentifier. D’aller consulter son Responsable Sécurité pour engager les actions nécessaires en adéquations selon le risque couru.

Prérequis

RHEL, Debian, Ubuntu
Mutt, cyrus-sasl-plain, Faillock

Locked Account & Notifications

Installation et configuration de MUTT

Concernant cette partie, je vous invite à parcourir la section déjà documentée dans l’article Apps – MUTT.

Configuration de Faillock

Le module faillock vient remplacer le module pam_tally2 devenu obsolète il y a un petit moment déjà. Il est présent nativement sur quasi tout les systèmes à ce jour.

Je ne traite pas volontairement dans cette partie de la politique de mot de passe. Cela fera parti d’un autre article à la limite de l’indigeste.

Il va être nécessaire de modifier les fichiers password-auth et system-auth du module d’authentification.

password-auth

Editer le fichier password-auth

$ sudo /etc/pam.d/password-auth

Ajouter les lignes suivantes dans le fichier

1) auth        required      pam_faillock.so preauth audit silent deny=5 unlock_time=900

2) auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

3) account     required      pam_faillock.so

La première ligne assure que l’utilisateur à 5 tentatives de connexion avant de voir son compte verrouillé pour une durée de 15 minutes. Nous choisissons de logger l’information et de ne pas indiquer que le compte est désactivé.

La seconde ligne indique qu’en cas d’échec de la ligne précédente, le compte sera locked.

La troisième ligne indique que le module d’authentification faillock et requis.

system-auth

Editer le fichier system-auth

$ sudo /etc/pam.d/system-auth

Ajouter les lignes suivantes dans le fichier

1) auth        required      pam_faillock.so preauth audit silent deny=5 unlock_time=900

2) auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

3) account     required      pam_faillock.so

Les explications sont les mêmes que pour le module précédent.

Test

Vérifions que les modifications apportées ont bien été prise en compte. Pour se faire nous allons vérifier l’état des comptes Valid

$ sudo faillock

Volontairement nous allons verrouiller le compte adm.r-one. Il est nécessaire d’avoir un second shell d’ouvert en parallèle pour déverrouiller le compte ou de passer par la console système en root directement.

Ou encore, en dernière option d’attendre 15 minutes.

Nous allons libérer l’utilisateur adm.r-one puis vérifier que ce dernier est bien unlocked.

$ sudo faillock --user adm.r-one --reset
$ sudo faillock

Configuration et installation du Script

J’ai toujours pour habitude de positionner mes scripts à la racine du système dans un répertoire à part avec des droits spécifiques. L’objectif étant de toujours garantir un niveau de sécurité suffisant et d’éviter une escalade potentiel des droits.

$ sudo mkdir /script
$ sudo mkdir /script/SS_027-LINUX_LockAccount

Editez le fichier ou copiez le fichier suivant : SS_027_D_LINUX_LockAccount.sh

A ce jour le fichier en version D est construit de la manière suivante :

Les constantes
Une fonction vérifiant l’OS
Une fonction vérifiant les derniers logon authentifiés avec succès (utilisateurs et services)
Une fonction vérifiant les comptes verouillés
Une fonction pour préparer le mail
Une fonction d’envoi de mail
Une fonction pour forger le mail en html

Comme tous mes autres outils, les premiers échanges de mails se sont fait au format texte brut, puis pour un soucis de compréhension j’ai dû passer au format HTML…

Il est encore trop tôt pour expliquer cette aversion personnel pour le monde du web… Mais passons, il est donc possible d’envoyer les notifications sous les deux formats.

Pour le script, comme pour mon premier article sur le sujet je ne souhaite pas pour l’instant rendre ce dernier accessible à la disposition de tous.

Couvrez ce code que je ne saurais voir. Par de pareils objets les AdminSys sont blessées, Et cela fait venir de coupables pensées…
Molière 2.0

Et surtout cela me demanderai de configurer mon GitHub, de soigner mon code etc.

So, comment le code fonctionne ? De la plus simple des façons.

Le code va vérifier la version du SE, puis vérifier si des comptes sont verrouillés ou non. Si un des comptes est verrouillés, nous récupérons ces derniers. Nous récupérons la date de la dernière fois que tous les comptes se sont connectés (afin de contrôler qu’il n’y a pas de Léviator sous Racaillou). S’ensuit la préparation du mail, le « forgeage » puis l’envoi.

Dans le cas où aucun compte n’est verrouillé, le code ne fait rien.

Nous controllons les droits sur le fichier afin de s’assurer que ce dernier est bien en 700 pour root:root.

$ sudo ls -ahl /script/SS_027-LINUX_LockAccount/

Dans le cas contraire, il sera nécessaire de réaliser les opérations adéquates.

Configuration du cron

Comme nous voulons une alerte plutôt réactive, mais qui ne spam pas trop non plus, j’aime par confort définir une vérification toutes les 3 minutes. Libre à chacun de faire comme il le souhaite.

# vim /etc/crontab

Ce qui nous donne dans notre BAL, lorsqu’un compte est verrouillé la notification ci-dessous.

Conclusion

La roue a dû encore une fois être réinventée. Mais cette solution me convient et répond à mon besoin.

Nous revenons toujours sur ce curseur bénéfices, risques que cette solution apporte.

Si niveau système, la configuration et l’usage du module faillock dans les modules d’authentifications relève de la bonne pratique, ma solution pose question.

Avantages

Suivi des alertes quasi en temps réel sur lock du compte

Inconvénients

Utilise le compte root pour la tâche planifiée
Repose sur un paquet, application tiers « MUTT »
Doit être ajusté selon les SEs qui ne sont pas pris en charge
S’assurer que le script n’est pas altéré

Au delà des axes récurrents d’améliorations, nous comptons plus d’inconvénients que d’avantages. Le point le plus bloquant selon moi est que tout repose sur le daemon assurant les notifications mails. Si le daemon vient à planter ou à être la cible d’un individu malveillant rendant ce dernier inopérant, l’attaquant a le champ libre.

Dans un sens si nous revenons à notre analogie initiale du serveur et de notre maison, l’individu malveillant nous à couper notre système d’alarme, internet et électricité ect.

Nous devons donc coupler des mécanismes de sécurité supplémentaires en amont et aval de notre serveur.

Le mot de la fin :

J’Houdini ma twingo et pars avant l’orage. Vous ne pouvez pas vous êtes faillock avec Francis Huster pendant deux madeleines
Erwan GUILLEMARD

LINUX – Locked Account