Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Orchestrator 2012 – Récupérer la sortie brute d’une activité Run .NET Script

Dans Orchestrator, l’activité Run .NET Script permet d’exécuter des scripts dans différents langages (Powershell, VB .NET, JScript…) ce qui se révèle très utiles dans les nombreux cas où les activités apportées par les différents Integration Pack se révèlent insuffisantes pour effectuer les tâches dont vous avez besoin.

Cependant, il peut vite devenir compliqué de débugger ces scripts puisque l’activité Run .NET Script ne publie pas le résultat brut de leur exécution dans le databus : impossible alors de savoir où le script a échoué!

En revanche, ce que cette activité peut publier à l’aide de sa fonctionnalité Published Data, c’est le contenu de n’importe quelle variable que contient le script exécuté.

Il ne reste donc plus qu’à utiliser ce fonctionnement afin de stocker le résultat d’exécution du script dans une variable et de la publier via les Published Data.

Prenons l’exemple de ce script Powershell, un simple compteur qui ne présente pas d’intérêt autre que de produire une sortie sur plusieurs lignes :

for ($i=0; $i -le 10; $i++) {write-host $i}

image

 

Il suffit de l’encapsuler comme suit pour récupérer cette sortie dans Orchestrator :

$result = Powershell { for ($i=0; $i -le 10; $i++) {write-host $i} }

image

Puis de publier la variable result dans les Published Data :

image

 

La sortie du script est donc désormais publiée dans le databus.

On peut ensuite la récupérer dans un fichier texte à l’aide de l’activité Append Line, dans un évènement avec Send Event Log Message etc. Attention car dans ce second cas, un évènement sera créé pour chaque ligne si le mode Run Behavior > Flatten n’est pas utilisé!

Prenons l’exemple du fichier texte :

image

On voit bien que l’activité Append Line est appelée une fois par ligne contenue dans la variable result car le flatten n’est pas activé :

image

Et le résultat final :

image

Evidemment, cette astuce sera beaucoup plus utile pour des scripts réels!

SCOM 2012 – Erreur lors de la découverte d’un serveur CentOS 7

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 :

image

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 :

image

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 :

image

 

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!

Retirer l’utilisation du SSLv3 sur un site ASP.NET suite à la faille POODLE

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”

image

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 :

image

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/