asyd’s blog

Depuis quelques jours, une version alpha d’iTop 2 est disponible chez mes amis de Combodo. iTop est un fabuleux outil qui vous permet de créer votre propre CMDB, et d’y associer des services tels que la gestion de tickets (incidents, changements). Pour rappel, une CMDB (Configuration Management DataBase) décrit l’ensemble des composants d’un système d’information. Cela peut aller du SAN, serveur physique, machine virtuelle, carte réseaux, switch jusqu’a remonter à la couche applicative : serveur d’application (par exemple Tomcat), application, etc.

L’objectif d’une telle base de données est de pouvoir d’une part cartographier votre SI, mais surtout de pouvoir faire des liens entre tous ces objets, ce qui permet d’en obtenir des analyses de dépendances (de quelle brique technique mon application métier a besoin pour fonctionner) et aussi des analyses d’impact (il se passe quoi si j’éteins ce serveur).

Les nouveautés visibles d’iTop 2

Rentrons dans le vif du sujet, à savoir quelles sont les nouveautés – point de vue utilisateur – de cette nouvelle version ? Et bien, la réponse courte tiens en deux mots : “le modèle”. Concrètement, si vous êtes utilisateur ou même testeur de la première version, vous aviez remarquez l’absence des machines virtuelles dans le modèle de base, ce qui est de nos jours est d’utilisation très courante. Ce manque à – je pense – freiné un peu l’adoption du logiciel.

Donc, voici en vrac les changements notables du modèle (liste non exhaustive) :

• Machines virtuelles : une VM peut être rattachée – via la notion d’hyperviseur – soit à un serveur physique (zone Solaris, dom0 Xen), soit à un cluster
• Gestion du SAN, de la baie de stockage aux volumes logiques, en passant par les switch
• Des attributs supplémentaires tels que la gestion de l’alimentation des serveurs physiques, la gestion des racks/chassis

Un autre changement notable concerne l’installation. Un assistant (wizard) plus complet permet de choisir entre – par exemple – plusieurs niveaux de gestions des tickets.

Les autres nouveautés

L’autre, sinon LA nouveauté d’iTop, bien qu’elle est soit invisible pour les utilisateurs réside dans le changement du format de données décrivant le modèle. Dans la version 1, le modèle est décrit via des fichiers PHP, quelques connaissances de programmation sont donc nécessaire, et surtout il n’était pas facile de maintenir un suivi avec les mises à jour coté iTop.

Dans cette version, les développeurs ont choisi d’utiliser XML, ce qui permettra à chacun de modifier le modèle de données sans avoir à modifier les fichiers fournis par iTop ! Et j’avoue que ça, c’est un point non négligeable pour un intégrateur comme moi ! De plus, l’utilisation de fichiers XML rend plus facilement possible la création d’un éditeur graphique du modèle (qui existe pour les partenaires de Combodo).

Conclusion

Cette nouvelle version est doublement appréciable. D’une part, le modèle est maintenant complet et ne nécessitera que quelques retouches (je pense surtout à l’ajout d’attributs) pour être utilisable dans 90% des cas, et d’autre part, le changement en profondeur du format de description du modèle va considérablement simplifier la vie, et permettra – je l’espère rapidement – la création d’outils pour gérer son modèle.

cette fois, c’est pour de bon ! la quatrième édition des séminaires sysadmins se tiendra les Jeudi 28 Février et Vendredi 1er Mars sur Paris (à l’IRCAM, 5mn de Châtelet).

Toute proposition de conférence (50mn questions incluses pour les pleinières, 5 à 15 minutes pour les conférences éclaires) est la bienvenue ! Faire vos propositions d’ici fin novembre à asyd at asyd dot net ou en par un commentaire sur cette présente page.

Merci d’avance !

Bonjour à tous,

la quatrième édition des séminaires sysadmins se tiendra les 26 et 27 avril sur Paris. Comme les précédentes éditions, une journée sera dédiée à un thème particulier et cette fois c’est autour du monitoring et métrologie. La deuxième journée n’a pas de thème spécifique, donc toute proposition est la bienvenue !

Dans le cadre du projet SOIF (qui fera l’objet d’un prochain billet), je travaille actuellement sur un job de transformation d’une base Puppet facts pour injecter dans iTop.

Avant tout, un peu de contexte : Puppet intègre la commande facter qui renvoie tout un ensemble d’informations sous la forme attribut=valeur, et qui est facilement extensible, bref c’est très intéressant. Là où le bat blesse, c’est que – logiquement – ces informations sont stockées en base de données en utilisant le modèle de conception EAV pour Entity Attribute Value.

Ce qui donne :

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | int(11)      | NO   | PRI | NULL    | auto_increment |
| name       | varchar(255) | NO   | MUL | NULL    |                |
| updated_at | datetime     | YES  |     | NULL    |                |
| created_at | datetime     | YES  |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+

et

mysql> desc fact_values;
+--------------+----------+------+-----+---------+----------------+
| Field        | Type     | Null | Key | Default | Extra          |
+--------------+----------+------+-----+---------+----------------+
| id           | int(11)  | NO   | PRI | NULL    | auto_increment |
| value        | text     | NO   |     | NULL    |                |
| fact_name_id | int(11)  | NO   | MUL | NULL    |                |
| host_id      | int(11)  | NO   | MUL | NULL    |                |
+--------------+----------+------+-----+---------+----------------+

Donc, pour obtenir par exemple la fact serialnumber pour un hôte donné, cela donne quelque chose du genre :


select fact_values.value FROM fact_values LEFT JOIN hosts ON fact_values.host_id = hosts.id LEFT JOIN fact_names ON fact_values.fact_name_id = fact_names.id WHERE hosts.name = 'xxx' AND fact_names.name = 'serialnumber';


Mais maintenant, retour à mon objectif : travailler par lot, c’est à dire pour tous les enregistrements de la table hosts. Se pose donc la question de comment faire pour obtenir la liste de tous les hôtes, avec la valeur serialnumber, à froid, pour l’expert SQL que je ne suis pas, mon premier jet à donné :

SELECT hosts.id, fact_values.value FROM hosts LEFT JOIN fact_values ON hosts.id = fact_values.host_id LEFT JOIN fact_names ON fact_names.id = fact_values.fact_name_id WHERE fact_names.name = 'serialnumber';

qui semble fonctionné à priori, mais, MAIS, cela ne renvoie que les enregistrements pour lesquels il existe la valeur serialnumber.

Après de nombreuses recherches, il semblerait que la seule solution à mon problème soit :

SELECT 
  hosts.id, 
  (SELECT fact_values.value
    FROM fact_values
    JOIN fact_names
     ON fact_names.id = fact_values.fact_name_id
    WHERE fact_names.name = 'serialnumber' 
     AND fact_values.host_id = hosts.id) as serialnumber,
FROM hosts;

et là, on le voit tout de suite, ça devient compliqué. Pourquoi ? parce que je n’ai pas seulement besoin du serialnumber mais de nombreux autres champs, et pour chaque champ que je veux, je dois donc rajouter un nouveau SELECT, je vous laisse deviner l’impact sur les performances.

Bref, EAV, ça pue. Bien évidemment si vous avez une autre solution, n’hésitez pas à commenter !

Dans mes péripéties mod_security, j’ai eu l’erreur suivante :


[Thu Dec 29 08:44:22 2011] [error] [client xx.21.3.31] ModSecurity: Warning. Pattern match "\\W{4,}" at ARGS:typeLibelle. [file "/usr/local/apache2/conf/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "507"] [id "960024"] [rev "2.2.2"] [msg "SQL Character Anomaly Detection Alert - Repetative Non-Word Characters"] [data " \\xc3\\xa0 "] [hostname "dev.xxxx.fr"] [uri "/xxxx"] [unique_id "TvwaVgpArWEAAHu7CtMAAAAG"]


Et la question qui tue : à quoi correspond \\xc3\\xa0 ? Je me doutais que c’était un caractère UTF8, j’ai donc demandé à mon expert jeu de caractères (aka Laurent Blume) qui m’a donné l’astuce suivante :

• Avant tout, avoir un système en UTF-8
• Lancer vim (pas besoin d’ouvrir un fichier)
• Taper un caractère accentué, par exemple é
• Convertir en hexadécimal à l’aide de la commande “:%!xxd”, ce qui va donner quelque chose du genre “0000000: c3a9 0a”
• Modifier le c3a9 en c3a0
• Reconvertir en texte, à l’aide de la commande “:%!xxd -r”, et miracle on obtient le caractère “à” !

La troisième édition des séminaires sysadmin se tiendra les 20 et 21 Octobre à l’IRILL (merci à eux aux passage).

Le programme (non définitif) est maintenant disponible ! Les inscriptions seront ouvertes d’ici peu.

Un client m’a demandé récemment si je pouvais jeter un œil à mod_security pour ses besoins de protections d’URL (WAF, en anglais Web Application Firewall, plus d’infos sur l’article Wikipedia). En quelques mots, mod_security est un module Apache – comme son nom l’indique – qui apporte donc une fonctionnalité de filtre relativement avancé, mais avec l’avantage d’être opensource et donc gratuit. De plus, il vient avec un ensemble de règles déjà établies qui sont le fruit du travail du groupe OWASP, qui se définit comme un 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software.

L’objectif de ma première approche de mod_security est relativement simple puisqu’il consiste à logger toutes les tentatives d’authentification avec un nom d’utilisateur qui contient des caractères hormis [a-zA-Z0-9]. Voici un récapitulatif de l’architecture (simple) mise en œuvre :

• Distribution : CentOS
• un apache (où sera installé le module mod_security) en frontal devant un Tomcat, en utilisant le mod_proxy (en HTTP)
• un Tomcat avec une application de test nommée Xebia Travel développée par Xebia
• L’authentification des utilisateurs sur l’application Xebia Travel s’effectue via un POST au travers d’un formulaire, avec les variables j_username et j_password

Une fois installé mod_security (depuis le dépôt EPEL), et quelques petites heures de recherche, voici le résultat que j’ai obtenu :


SecAuditLog /var/log/httpd/ecommerce-audit.log
SecDebugLog /var/log/httpd/ecommerce-security.log
SecDebugLogLevel 3
SecAuditEngine relevantonly

SecRule ARGS:j_username "!@rx ^([A-Za-z0-9]+)$" auditlog,id:10000


Quelques explications :

• Les directives SecAuditLog, SecDebug, SecDebugLogLevel et SecAuditEngine sont relativement explicites. Elles permettent en effet de configurer les différents fichiers de logs et d’audit, ainsi que leur verbosité
• La directive SecRequestBodyAccess est très importante, puisqu’elle permet de dire à mod_security d’analyser non pas seulement les en-têtes des requêtes mais également le corps. Pourquoi est-ce important ? Parce qu’avec les formulaires de type POST, les variables sont passées non pas en en-tête, mais bien dans le corps du message. Sans cette directive, il est donc impossible d’analyser les arguments des formulaires de type POST
• et enfin, la directive la plus importante à savoir SecRule qui est exécutée à chaque fois qu’une requête est effectuée avec l’argument j_username (POST ou GET), et je vérifie au travers d’une expression rationnelle (regex) qu’elle contient d’autres caractères que [A-Za-z0-9], auquel cas je lui définie l’action auditlog, en lui demendant d’identifier cette règle avec l’id 10000, ce qui s’avère pratique pour l’analyse du fichier d’audit.

Bien entendu, ce billet ne montre qu’un centième des utilisations possible de mod_security, mais si cela peut aider à commencer, sur ce, à bientôt !

Bonjour à tous,

courant fin septembre 2011 se tiendra la troisième édition des séminaires de la liste francophone sysadmin (le programme de la deuxième édition est toujours en ligne, et surtout les vidéos et présentations). Cette troisième édition se tiendra sur deux journées, la première consacrée à des sujets autour de la conformité de configuration (tel que Chef, Puppet, etc.), la seconde avec des sujets divers et variés. Si vous êtes intéressé par faire une présentation, je vous invite à me contacter par mail à asyd at asyd dot net, et/ou en laissant un commentaire sur ce présent billet.

Merci de votre participation !

De retour chez un client après quelques années d’absences, je me retrouve avec un certificat d’administrateur expiré sur la PKI de test. Voici la procédure de création d’un nouveau certificat, le tout en ligne de commande, forcément :

./bin/ejbca.sh ra adduser bbonfils00 foo123 "cn=Bruno Bonfils,UID=bbonfils,O=Customer,C=FR" NULL AdminCA1 bruno@opencsi.com 1 P12 ENDUSER EE_PKI_ADMINISTRATOR
./bin/ejbca.sh ra setclearpwd bbonfils00 foo123
./bin/ejbca.sh batch


Bien entendu il faut que le certificat corresponde au profil. Si besoin, vous devez pouvoir utiliser le profil EMPTY en ne spécifiant uniquement le CN. Il faut maintenant obtenir le numéro de série du certificat.

./bin/ejbca.sh ra getusercert bbonfils00


Copier / coller le certificat dans un certificat, puis extraire le numéro de série à l’aide de la commande OpenSSL :

openssl x509 -in /tmp/bbonfils0.pem -noout -serial
serial=4AEDB10E68DC69B6


Et finalement, identifier un groupe d’administrateur, puis rajouter l’administrateur dans ce groupe :

./bin/ejbca.sh admins listgroups
Using JBoss JNDI provider...
PKI CA Administrators (1 admin)
Super Administrator Group (2 admins)
./bin/ejbca.sh admins addadmin "Super Administrator Group" "AdminCA" "WITHSERIALNUMBER" EQUALCASEINS 4AEDB10E68DC69B6


Suite aux problèmes récents de divers fournisseurs officiels de certificats, notamment Comodo, on peut croiser ici et là diverses propositions de changement (assez radicaux) quant à la gestion des certificats. Certains parlent d’un Web of Trust (pour faire simple et court, c’est l’utilisateur qui choisi au cas par cas à qui il fait confiance), d’autres encore pensent à sortir du modèle actuel des fournisseurs officiels, en utilisant notamment le DNS pour fournir l’information sur le certificat attendu, ce qui permettrait au navigateur de savoir si le certificat reçu est celui attendu.

Cependant, toutes ces propositions ne sont là que pour corriger le modèle actuel des fournisseurs de certificats, aucune proposition (du moins parmi celle que j’ai lues) ne remet en question le modèle du HTTPs, à savoir de la protection de transport. Pour moi, le vrai problème ne se situe plus à la protection du transport, mais à la protection du contenu. Qu’est ce que je veux dire par là ? Prenons un cas simple, une page d’authentification. Il va de soit que l’identifiant et surtout le mot de passe doit être transmis de manière sécurisé.

Aujourd’hui nous utilisons de plus en plus de sites internets, issus de différents éditeurs, et surtout de plus en plus de portails. Comme je l’avais imaginé il y a déjà plus de 2 ans, de mon avis l’avenir réside dans le fait de sécuriser le contenu, et non plus le contenant. Prenons l’exemple d’un utilisateur qui va sur un site que l’on appellera BLOG, cette personne veut publier un commentaire, mais ne dispose pas d’un compte sur la plateforme BLOG. Peu importe, nous sommes au XXI ème siècle, il est possible de s’identifier via Facebook ! Oui mais… suivant comment est implémentée cette authentification, rien ne garanti que le mot de passe circule de manière chiffrée sur la plateforme BLOG. Cependant, l’authentification est un cas à part, il existe déjà des mécanismes pour éviter ce genre de problème, notamment la fédération d’identité, qui permet à un fournisseur de service (tel qu’un blog wordpress comme celui que vous lisez actuellement) d’être indépendant du fournisseur d’identité (là où on tape son identifiant et son mot de passe).

Le principe est relativement simple, plutôt que de chiffrer le tuyau d’une communication sensible, on chiffre le contenu de la communication, qui peut donc transiter de manière sûre via des canaux non sûrs. Bien entendu, cela ne change en rien la problématique de délivrance des certificats. Mais je pense que plutôt que d’essayer de corriger le problème en bout de chaîne, essayons de corriger la source. Par exemple, la plupart de nos chers voisins belges disposent d’une carte d’identité électronique, qui contient un certificat. Ce dernier, au travers d’un lecteur de carte (avec des drivers qui fonctionnent aussi bien sous Windows que sous Linux, en passant par Mac OS X), peuvent utiliser leur certificat, notamment pour déposer des dossiers légaux de manière purement électronique. En aucun cas je ne suis en train de dire que tous les certificats serveurs doivent être délivrés par l’État ou assimilé (encore que, quand on voit cet article on peut se demander de la pertinence d’une telle solution). Mais l’utilisation massive par les utilisateurs d’un certificat permettrait – je le pense – une meilleure compréhension, et surtout cela imposerait aux éditeurs de logiciels de prendre du temps pour réfléchir à l’ergonomie associée. Car, et je terminerais la dessus, le problème de sécurité des certificats actuels, est surtout lié aux éditeurs des navigateurs.

En effet, bien que l’on puisse reprocher l’aspect monétaire, le modèle actuel pêche surtout par l’absence de renouvellement régulier des certificats racines, certains sont en 1024 bits, d’autres utilisent du MD4 (non, il n’y a pas de typo, je parle bien de MD4 et non MD5, qui de toute manière est tout aussi faible dans le cas de certificats). De plus, bien qu’il existe des mécanismes de vérification des certificats (tel que l’utilisation de CRL, et surtout de l’OCSP) ces mécanismes ne sont pas activés par défaut sur les navigateurs et/ou systèmes d’exploitations. Pour conclure, plutôt que d’essayer de trouver un nouveau modèle, il faudrait utiliser les technologies qui nous sont d’ores et déjà proposées.