Le blog technique

A l’occasion du déploiement d’agents Linux à partir d’une infrastructure SCOM 2012 R2 UR4, un client a rencontré le problème suivant pour les serveurs exécutant la distribution CentOS 7 :

Failed during SSH discovery. Exit code: 2
Standard Output:
Standard Error: /etc/centos-release: line 1: syntax error near unexpected token `(‘
/etc/centos-release: line 1: `CentOS Linux release 7.0.1406 (Core) ‘
Exception Message:

Il reste possible de procéder à une installation manuelle de l’agent, mais cette solution est beaucoup moins pratique et plus longue.

Pour comprendre d’où provient cette erreur, il est nécessaire de comprendre au préalable que le processus de découverte d’un serveur Linux est réalisé par le script GetOSVersion.sh, disponible dans le dossier d’installation de SCOM : C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents

Lors de la découverte, ce script est copié et exécuté sur les serveurs à découvrir et tente principalement d’identifier la version de Linux exécutée par le serveur afin d’y déployer l’agent approprié.
Pour ce faire, il cherche à récupérer le contenu du fichier standardisé os-release qui contient des informations sur le système, à l’aide des lignes suivantes dans le cas d’un CentOS :

Le souci, c’est que la variable . $ReleaseFile pointe vers un fichier nommé centos-release qui contient, ô surprise, la ligne CentOS Linux release 7.0.1406 (Core) à la place des informations attendues au format TAG=VALUE.

Informations qui se trouvent par contre bien dans le fichier os-release… il ne reste alors qu’à corriger le script afin qu’il pointe vers le bon fichier, en remplaçant la ligne
. $ ReleaseFile
Par la ligne
. ${EtcPath}/os-release
Ce qui donne ce résultat :

Répétez cette opération sur tous les serveurs du Management Pool Linux et votre découverte ne devrait désormais plus poser de problème!

Attention! Cette modification n’est pas supportée par Microsoft et n’a pas été testée en profondeur, elle pourrait donc provoquer d’autres problèmes dans  des contextes différents! 
Par ailleurs, il y a de fortes chances que le fichier GetOSVersion.sh soit écrasé lors de l’installation de mises à jour futures. Il serait alors nécessaire de réappliquer la modification détaillée ici, si Microsoft n’apporte pas de correction.

Merci à Stéphane J. pour son implication sur cette problématique Linux assez spécifique!

Contexte

La faille POODLE (découverte par une équipe de Google fin Septembre) permet d’extraire depuis une transaction sécurisée en SSLv3 des informations secrètes (cookies, password) lors d’une attaque de type “Man in the middle”.

Suite à la découverte de cette faille, le protocole SSLv3 est maintenant obsolète, il est conseillé sur un serveur WEB, d’interdire l’utilisation de SSLv3 ce qui peut présenter des problèmes de compatibilité.

Explications

Lors d’une connexion à un site WEB, le navigateur et le serveur WEB vont négocier un protocole de chiffrement, le protocole négocié doit correspondre au protocole le plus à jour implémenté par le serveur et le client.

Bien qu’actuellement la grande majorité des navigateurs et des sites WEB implémentent des protocoles plus sécurisées que le SSLv3, il est possible que le protocole SSLv3 soit choisi par “fallback”. Il est également possible pour un utilisateur malveillant qui contrôlerait le réseau entre le client et le serveur de forcer la négociation d’un protocole antérieur au protocole le plus à jour implémenté par le client et le serveur afin d’en exploiter les failles.

Avec la faille POODLE touchant le SSLv3 et contrairement aux failles précédentes rencontrées sur SSLv3, aucun contournement n’est possible. Il faut donc bannir l’utilisation du protocole SSLv3.

C’est dans cette optique que les principaux navigateurs dont Firefox et Google Chrome, annoncent le retrait du support de SSLv3 sur leurs prochains produits.

Résolution sur IIS & ASP.NET

Sur un serveur web utilisant le framework .NET et qui est compatible avec TLS 1.0, il est possible de forcer l’utilisation d’algorithmes de cryptographie compatibles FIPS.

Cela se fait via l’activation de la stratégie locale située dans :

“Paramètres de sécurité locaux/Stratégies locales/Option de sécurité/Stratégie/Chiffrement Système”

Après cette modification les protocoles non compatibles FIPS (dont SSLv3) ne pourront être utilisés.

Par défaut, ASP.NET utilise des algorithmes non-compatibles avec FIPS, l’erreur 1309, visible dans le logs des évènements Web, est donc susceptible d’apparaitre :

Afin de modifier ce comportement, il faut spécifier au niveau du fichier Web.Config de l’application ASP.NET l’algorithme de cryptographie à utiliser.

Pour ce faire il faut dans la partie <system.web> du fichier Web.Config, ajouter la ligne suivante :

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>

Sources :

http://support.microsoft.com/kb/911722

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/