Je pense que la liste pourrait être longue…

Pour ma part je ne suis pas un grand partisan de l’application des mises à jour automatique. Les raisons ? Avoir subi des aléas système avec WINDOWS et des aléas d’application tierce sous LINUX.

Le temps passé à diagnostiquer, refuser et désinstaller la, les mises à jour (quand c’est possible et que le SE à décider de boot jusqu’au bout) ou alors de réparer le système (restauration de la sauvegarde précédente pour le système, application de fix nébuleux pour ne pas dire opaque) couplé au temps d’interruption de service que subit les utilisateurs cela peut vite s’avérer un casse-tête et une source de stress…

L’un des meilleurs exemples qui me vient en tête :

Souviens toi, souviens toi du 15 Octobre 2021, de la conspiration de MICROSOFT et de VMWare car la mise à jour du pilote pvscsi à débugger jamais je ne pourrai me résoudre…

Erwan GUILLEMARD (sur la base de V for Vendetta 2005)

Je fais de le drama ! Le dysfonctionnement a été corrigé dans la matinée pour l’ensemble des serveurs concernées. Toutefois ça a été long et fastidieux. (cf

Afin d’éviter ce cas de figure, je me suis posé la question que préconise les éditeurs, les distributeurs de SE ?

Dans la logique il conviendrait d’avoir un miroir de son environnement de production en préproduction. Cela demande d’avoir les ressources de stockage et calcul nécessaire, d’avoir une réplication des données à J-1. Bref, c’est beaucoup de contrainte humaine, financière et matérielle pour des PMEs.

Il existe selon moi trois alternatives sans consommer trop de ressources :

1. Ne pas mettre à jour ces environnements (ça solde rapidement le problème)
2. Avoir un environnement de préproduction minimaliste avec les SEs les plus présent et au moins un de chaque. Appliquer les mises à jour en amont et si tout est correct appliquer les changements en production
3. Appliquer les mises à jour sur l’environnement de production en lissant ces dernières dans le temps. Application des mises à jour sur un AD la deuxième semaine du mois puis la troisième semaine pour les autres serveurs d’authentifications par exemple.

Sans m’étendre sur le scénario numéro un qui est pour moi celui le plus présent malheureusement (même si ce n’est pas empirique). J’ai tendance à préférer le cas de figure numéro 3. Il a des inconvénients, avantages et je trouve pour ma part une efficience à l’administrer au quotidien.

Cependant, pour les environnements critiques ou métiers à fort impact je préfére l’option 2. C’est le cas des environnements LINUX pour lesquelles je garde un historique des actions effectuées ainsi qu’une application dans un environnement de préproduction/test au préalable.

J’ajoute ceinture, bretelle et parachute avec une sauvegarde de la veille, dump des bdds et snapshot à froid si possible. Nous ne sommes jamais trop sûr, sait on jamais…

Prérequis

• SE: RHEL, Debian, Ubuntu
• Apps: Mutt, cyrus-sasl-plain
• Autres: Sauvegarde fonctionnelle et/ou sauvegarde des fichiers de configurations au préalable

Update 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 et installation du Script

J’ai 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_023_LINUX_UpdatesNotifications

SS_023_ t’es allé la cherché loin ta p****n de convention de nommage !

Effectivement, au premier abord, le nom peut paraitre compliqué, je vous explique. Et non, nous n’effleurerons pas le point G (Godwin) dans cet article. J’ai nommé mes projets suivant une convention personnelle depuis un grand nombre d’année déjà.

• GS : GraphicalScript
• SS : SystemScript
• XX : Le numéro du projet suivi du nom du projet

Editez le fichier ou copiez le fichier suivant : SS_023_D_LINUX_UpdatesNotification.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 mises à jour
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Dans un premier temps, par fainéantise un simple mail en texte brut me suffisait amplement. Puis il a fallu mettre en service tout ça et rendre lisible le rapport. C’est pourquoi il y a dans le script la possibilité de générer le rapport au format HTML ou TXT.

« T’es mignon, mais sans le script on ne peut pas aller bien loin… Ce n’est pas dans l’esprit communautaire ce que tu fais nanani nana »

Ouvrons une parenthèse et faisons une mise au point,

Oui j’en ai bien conscience, je n’ai tout simplement pas envie non plus de donner les fruits de mon travail et réflexion facilement. Il y a plusieurs raisons pour lesquelles je ne délivre pas mes scripts.

• Il est nécessaire d’assurer le support et la correction des bugs. Cela demande du temps et la communauté pour l’avoir plusieurs fois constaté sur d’autres forums on put se montrer malveillante et désobligeante bien que cela ne soit pas une généralité.
• Cela repose sur une personne et donc il y a un risque quant à la durée de vie et du fonctionnement de ma solution (MCO et MCS). J’ai peut-être réinventé la roue, mais c’est ma roue avec ces petits défauts et je ne peux et ne veux pas être tenu pour responsable de tous dysfonctionnements éventuels sur vos SIs.
• Un peu de pudeur singulière quand au code. Certains pourraient dire que c’est codé avec les pieds, que ça peut être mieux fait, factorisé ect. Je crois et c’est ce que j’ai retenu d’un de mes collègues, c’est que l’on peut toujours faire mieux que les autres et que chaque solution est optimisable. Toutefois, mes « outils » reflètent mon paradigme. Si ce dernier ne me convient pas intrinsèquement je n’en parle pas et né présente pas mes « travaux ».
• Je ne compte pas vendre les solutions car je pense que ces dernières doivent rester dans l’esprit du libre. Je suis prêt à donner mes outils mais pas de mon temps. Echanger sur le sujet reste un grand plaisir. Assurer le support et faire « à la place de » nécessite sonnant et trébuchant (communément appelé Prestation de Services).

Fermons la parenthèse.

Revenons à nos moutons. Le script mis en place, il est nécessaire de définir les droits.

Un simple 700 suffit sur le fichier.

$ sudo chmod 700 /script/SS_023_LINUX_UpdatesNotifications/SS_023_D_LINUX_UpdatesNotifications.sh

Néanmoins, les permissions restent root:root et ça c’est pas ouf. C’est comme allez aux p****s sans capotes. Ça peut le faire mais il subsiste un risque. Après chacun fait ce qui lui chante.

Malheureusement je n’ai pas à ce jour « procéduré » de manière correct l’exécution d’une tâche planifiée avec un utilisateur autre que root sans générer de trou dans la raquette niveau sécurité.

En gros soit c’est sécu mais ça ne fonctionne pas, soit ça fonctionne mais faut pas trop regarder côté sécu.

Configuration du cron

Comme pour Microsoft avec son mensuel Tuesday Update, j’aime quant à moi réaliser un rapport hebdomadaire le mercredi à 03:00 PM.

Et puis entre nous, le mercredi aprem c’est la journée télétravail, tout le monde fait semblant de taffer, la France est au 4/5eme, on se fait ch**r et nous ne sommes pas Vendredi soir pour faire une mise en production. Il faut bien s’occuper un peu !

# vim /etc/crontab

Ce qui nous donne dans notre BAL :

Nothing to do – No updates availables	MCO to do – Updates availables

Conclusion

J’ai peut-être réinventé la roue et je suis certains qu’un paquet répond déjà à mon besoin dans un repo.

Cependant, si une solution existe dans les gestionnaires de paquet il est fort probable que ces dernières ne répondent pas à mon besoin personnel dans sa globalité.

Je vois donc dans ma solution « maison » les avantages et inconvénients suivants :

Mon objectif étant maintenant selon mon temps libre et la criticité des « Inconvénients » de faire de ces derniers des avantages. Jusqu’à réduire au plus possible le nombre de point énuméré.

M’affranchir de MUTT et de faire mon propre service de relai de messagerie par exemple.

Pour répondre au point de l’altération et ou non du script et d’aborder la non répudiation et véracité du script, ce dernier a été déjà été traité et sera abordé dans un autre article.

Pour d’avantage d’information sur le script vous pouvez me contacter, ça serait avec un grand plaisir que je vous répondrai.

Le mot de la fin :

Je DISM mon kernel LINUX, dnf update mon MSSQL et fax le résultat à Philippe RISOLI

Erwan GUILLEMARD

Sources

• Mutt

Il est petit, efficace, fiable et facile d’utilisation.

Parlons peu, parlons bien, parlons MUTT !

MUTT est une solution de messagerie en mode console. Ce dernier est assez flexible, prend en charge un bon nombre des protocoles de messagerie et est super léger.

Ce que j’affectionne le plus dans cette solution, reste la rapidité de déploiement ainsi que sa simplicité de mise en place en tant que relai SMTP (en quasi moins de 5 minutes si je n’ai pas à chercher les identifiants et mots de passe).

What else ? Ba c’est tout, rien à ajouter votre honneur.

Je ne vais pas réinventer la multitude de post sur le sujet quant à l’implémentation de la solution. Je me limiterai uniquement à la configuration nécessaire à mon usage personnel, et nécessaire au bon fonctionnement de mes outils/scripts bash.

(Pour être efficient et ne pas dire fainéant, c’est surtout un mémo pour déployer rapidement mon relai de messagerie ou plus si affinité sans chercher tous les temps les arguments et ma configuration. 🙂 )

Prérequis

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

Installation

Rechercher et installer les paquets suivants, mutt et cyrus-sasl-plain.

• Le premier paquet permettra d’envoyer les mails via un relai smpt
• Le second paquet permettra de prendre en charge l’authentification

$ sudo dnf search mutt
$ sudo search cyrus-sasl-plain

$ sudo dnf install mutt cyrus-sasl-plain 

Configuration

Relai SMTP

Pour la phase de configuration, la majorité des actions sont à réaliser en tant qu’utilisateur et non en tant que root.

Renommez le fichier de configuration par défaut Muttrc :

$ sudo mv /etc/Muttrc /etc/Muttrc.ori

Editez le fichier de configuration Muttrc :

$ sudo vim /etc/Muttrc

Parcourons rapidement le fichier de configuration de MUTT

• Set from : L’adresse utilisée lors de l’envoie du mail
• Set realname : Le nom qui sera affiché
• Set use_from : Actif
• Set ssl_* : Désactivation du TLS car non pris en charge ce qui génére l’erreur 503 BadSequence
• Set smtp_pass : Le password du compte à utiliser
• Set smtp_url : L’url de connexion au relai smtp sous la forme «smtp://user@contoso.com:password@relaissmtp:587 »

Naturellement, la configuration est à adapter par vos soins, vous n’êtes pas obligé d’utiliser mutt non plus et donc de quitter ce billet.

J’ai choisi mutt car il me permet de générer des mails au format HTML. Bien avant de rencontrer et d’utiliser ce paquet, l’ensemble de mes mails était en texte brut (pour cela je passe par msmtp).

Les droits appliqués sur le fichier de configuration sont 655 root:root. Le password spécifié pour l’authentification à notre relai smtp est donc visible de tous les utilisateurs. C’est pas top…

Il est donc nécessaire de remédier à cela en retirant les droits sur le fichier pour les autres :

$ sudo chmod 650 /etc/Muttrc

Pour vérifier, un petit $ cat /etc/Muttrc en tant qu’utilisateur vous retournera l’un des plus beau message du monde, à la fois simple, clair et efficace. 😀

Test & Debug

Afin de vérifier le bon fonctionnement de notre configuration nous allons envoyer notre premier mail.

Dans un premier temps, générons un fichier dans /tmp/test_mutt contenant « Délivrez moi ce message de la plus haute importance, héraut ! »

$ vim /tmp/test_mutt

Délivrez moi ce message de la plus haute importance, héraut !

Entrez la commande suivante

$ sudo mutt -s "Message de la plus haute importance" erwanguillemard@gmail.com < /tmp/test_mutt

Regardons d’un peu plus près la commande que nous avons lancés. La présence du sudo semble étrange. En réalité non car j’ai durci mon SE :D, d’où l’élévation de privilège.

Le reste de la commande, un rapide –man nous renseigne sur l’ensemble des arguments disponible ainsi que les syntaxes supportées.

Dans notre cas :

• -s : Indique l’objet du mail
• adresse mail : l’adresse mail du, des destinataire(s)
• < /path/file : le corps du mail contenu dans un fichier

Si un argument est manquant Mutt vous invitera à travers un menu contextuel en console à finaliser votre courrier (brave bête).

Si nous consultons notre BAL

Concernant la parti diagnostic et debug, j’ai tendance à dire que plusieurs choix s’offre à nous, d’abord le fichier de log maillog ou la commande de debug prévu à cette effet

$ sudo tail -f /var/log/maillog
et
$ sudo mutt -nd 5

Conclusion

Un rapide relai SMTP opérationnel en quelques minutes permettant de remettre les courriers qui seront envoyés uniquement par nos robots et services.

Le mot de la fin :

Le héraut est l’ancètre du Petit Travailleur Tranquille ? Que nenni mareau, je suis syndiqué !

Erwan GUILLEMARD

Sources

• Mutt
• Cyrus-sasl

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

Sources

• Faillock
• Mutt