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 :
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 :
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
SecRequestBodyAccess On
SecRule ARGS:j_username "!@rx ^([A-Za-z0-9]+)$" auditlog,id:10000
Quelques explications :
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.
Au vu de mes futures (nouvelles ) activités, et parce qu’au XXI ème siècle, on se doit d’avoir un système d’information propre, j’ai commencé une maquette en n’utilisant que des outils libres. Les objectifs sont multiples :
Avant de rentrer dans la technique, je me permet un petit rappel sur la définition d’une CMDB (Configuration Management DataBase), qui est un concept né et normalisé par ITIL. Comme le décrit Wikipedia, une CMDB recense les composants d’un système d’information. Par exemple, la liste des serveurs, mais aussi et surtout la liste des serveurs d’applications, des applications, et de tout autre composant structurant. Une fois renseigné ces différentes briques, il est possible de les regrouper, notamment par solutions applications et par processus métier, et surtout, de lier toutes ces briques. L’objectif ? Définir des relations de dépendance, entre le métier (par exemple “Vendre des articles via mon site d’ecommerce”) et les briques techniques (le serveur “LDAP”). D’une part, renseigner ces informations oblige à documenter ces interactions, et éviter qu’elles ne soient que dans la tête de l’administrateur, mais pour un administrateur, cela permet de répondre à la question fatidique “qu’est ce qui se passe si je change mon serveur LDAP”. Bon nombre d’administrateur vont me dire “mais je sais très bien quelles applications utilisent le LDAP” ou bien encore “c’est dans Puppet, donc j’ai pas à m’en occuper”, je leur répondrais alors “oui, toi tu es conscient de l’impact technique. Si je demande à ta direction s’ils mesurent les impacts business de ta migration, ils vont en penser quoi ?” (Et là, je viens de me faire des ennemis, mais c’est une autre histoire).
Jusqu’il y a encore quelques années, je n’avais trouvé aucun logiciel opensource me permettant de créer cette CMDB. En effet, la plupart des logiciels de ce genre viennent avec un modèle déjà tout prêt. Cependant, nous n’avons pas tous les même besoin, et j’irais presque jusqu’à dire pas tous la même manière de les représenter (même si justement ITIL décrit un modèle de référence). Or, il y a quelques mois de cela, j’ai découvert un nouveau logiciel dans ce monde très spécifique, à savoir iTop. C’est un outil GPL, écrit en PHP, et d’origine française. Ses auteurs sont des anciens de HP, pour qui ils ont déjà travaillés sur ces problématiques. Résultat, bien qu’encore jeune, iTop est un outil formidable, car très simple d’utilisation, mais aussi par sa richesse. En effet, il est relativement aisé de modifier le modèle par défaut (au hasard celui d’ITIL) pour l’adapter à ses besoins. Pour citer un des fondateurs de la société Combodo éditrice de ce logiciel, il est tout à fait possible de schématiser une école maternelle avec ses élèves, ses professeurs, ses salles, etc. C’est typiquement le genre de logiciel que j’affectionne, il répond à un besoin, mais via une approche framework que logiciel rigide.
Voici un exemple du processus métier gérer la configuration. Étant administrateur système mon métier reste technique, chez d’autres sociétés, “Gérer la configuration” sera plutôt une solution applicative qu’un processus métier.
iTop : processus métier
Dans un SI, avec plein de serveurs, il peut être intéressant de pouvoir exécuter des jobs, aussi bien à intervalle régulier, que de manière occasionnelle. Bien entendu, chaque UNIX vient avec un daemon CRON, mais celui-ci est mono serveur, à une syntaxe différente entre les différents UNIX, etc. On pourrait très bien imaginer de gérer les fichiers cron via le logiciel de conformité de configuration, mais cela ne répond qu’au besoin de jobs réguliers. Pour cette brique, je me suis tourné vers RunDeck. Cet outil est un job scheduler en Java, encore une fois un projet relativement jeune, mais qui profite d’une grande expérience puisqu’il est issu des même développeurs que ControlTier, autre outil de job scheduling. Avec quelques lignes de développement PHP, RunDeck utilise iTop pour obtenir la liste des nodes (serveurs), et utilise une notion de tags dans iTop, pour rajouter par exemple le tag puppet que je défini sur les serveurs où l’agent est installé.
Chers lecteurs, étant donné que vous êtes en grande majorité des administrateurs systèmes, je vais passer outre la description de Puppet. Pour les autres, en quelques mots, c’est un outil qui permet de s’assurer que des classes de serveurs soient configurés de la même manière, par exemple en forçant la présence de tel ou tel package, que le fichier /etc/sshd/sshd_config soit identique, et ce à partir d’un fichier maître, etc. Par défaut, un daemon est présent sur chaque nœud, mais pour ma part j’ai choisi de ne pas l’utiliser, et d’exécuter l’agent via un job RunDeck (avec mon fameux tag). Cela me permet de centraliser via la WebUI de RunDeck la sortie des différentes instances des agents, et également de pouvoir exécuter l’agent avant d’attendre le prochain scheduling
Jusqu’ici, j’ai déclaré mes serveurs (grosso modo nom, adresse IP, informations SSH) dans iTop, mais j’aimerais bien avoir un inventaire plus précis, comme par exemple la liste des packages installés, la quantité de mémoire, etc. Ça tombe bien, il existe un outil performant pour faire l’inventaire d’une machine UNIX, à savoir FusionInventory. Et vous allez me demander, comment intégrer tout ça ? (en fait, je me doute que vous l’aurez déjà deviné). Tout simplement en forçant la présence du paquetage via Puppet, et l’exécution d’un inventaire toujours via Puppet (j’aurais pu également le faire via RunDeck cependant). Ensuite, je collecte le XML que génère FusionInventory, je lui applique quelques XSL, et j’intègre le résultat dans iTop, et tout ça de manière automatique. Voila, la boucle est bouclée.
Les liens entre les composants
Et bien, demain, je vais coupler de manière plus forte iTop et puppet. Avec un peu de travail, mais rien de bien compliqué, je vais pouvoir faire en sorte que iTop soit l’origine d’une partie de la configuration, notamment celle métier. L’objectif est par exemple, via iTop, de créer une nouvelle instance Tomcat sur un serveur, et que puppet assure son installation (je le fais déjà, mais via les fichiers de configuration puppet).
Étant donné mon futur changement professionnel (vous en saurez plus dans un futur proche), je me suis confronté au problème de la production des documents (principalement technique). Plusieurs solutions s’offraient à moi, la plus facile, en tant qu’utilisateur de Mac OS X, est d’utiliser Pages, de la suite iWork. Bien que ce dernier soit un produit très adapté pour produire rapidement un joli document, je trouve que la construction d’un thème from scratch n’est pas très facile, et de toute façon, il n’est utilisable que sous Mac, donc difficile en clientèle par exemple. La seconde solution, est d’utiliser OpenOffice ou LibreOffice, cependant, après quelques années d’expériences, je trouve que ce n’est pas très pratique sur le long terme, de plus, l’avenir des deux produits me semble incertain, le premier est devenu payant, le second, communautaire, ne me rassure pas quant à son avenir.
Les deux solutions restantes sont docbook et LaTeX. Le dernier, bien que connu pour être très bien, me parait coûteux en temps, principalement sur la personnalisation du rendu (PDF dans mon cas). Me reste donc docbook (si vous êtes anti XML, passé votre chemin). Pour ma part, il me semble absolument indispensable de différencier le contenu de son style (le rendu). Bien que beaucoup (mais ce n’est probablement pas votre cas, cher lecteur) pensent que <important>mon texte</important> soit équivalent à <gras>mon texte</gras>, ce n’est pas mon cas. Je peux pouvoir écrire un document (un contenu) à un instant t et le rendre en PDF mais surtout pouvoir modifier le style (couleur du titre, etc.) sans toucher le document d’origine, et ce plusieurs mois après la rédaction du fichier. C’est pourquoi je me suis tourné vers docbook.
Après quelques heures perdues, j’ai réussi à obtenir un squelette de production de mes documents, que je vais décrire dans le présent billet.
Pour commencer, voici la liste des fichiers impliqués dans la production d’un document :
Comme expliqué précédemment, ce fichier me permet d’automatiser la transformation d’un fichier docbook vers un fichier PDF. Et comme je galère un peu sur Makefile, je vais profiter de ce billet pour me faire un mémo.
DOCUMENTS=documentation.xml FOP=/Users/bbonfils/tools/fop-1.0/fop FOP_XSL=xsl/docbook.xsl FOP_CONF=conf/fop.xconf DEFAULT_XSL=xsl/default.xsl XSLTPROC=xsltproc XMLLINT=xmllint TMP=tmp ENV=LC_ALL=en_US.UTF-8 FOP_ENV=FOP_OPTS=-Djava.awt.headless=true default: $(DOCUMENTS:.xml=.pdf) %.pdf: %.xml $(ENV) $(XSLTPROC) $(DEFAULT_XSL) $? | $(XMLLINT) -format - > $(TMP)/$? $(ENV) $(FOP_ENV) $(FOP) -c $(FOP_CONF) -xml $(TMP)/$? -xsl $(FOP_XSL) -pdf $@ clean: @rm -f *.pdf
Les premières lignes définissent des variables, notamment DOCUMENTS qui me permet de lister les fichiers docbook à transformer en PDF. Ensuite, je défini la règle implicite suivante: :
%.pdf: %.xml $(ENV) $(XSLTPROC) $(DEFAULT_XSL) $? | $(XMLLINT) -format - > $(TMP)/$? $(ENV) $(FOP_ENV) $(FOP) -c $(FOP_CONF) -xml $(TMP)/$? -xsl $(FOP_XSL) -pdf $@
qui décrit la manière de compiler (transformer dans mon cas) un fichier XML vers un PDF. La première ligne permet d’appliquer ma XSL default.xsl qui permet de rajouter les informations de l’auteur si elles n’existent pas. La deuxième ligne applique la transformation docbook vers FO puis de FO vers PDF.
Et finalement, je définis la cible par défaut default en lui demande de me transformer la liste des fichiers renseignés par la variable DOCUMENTS en PDF, par substitution de l’extension.
Voilà, voilà, je dois avouer que ce billet est plus un memento personnel, mais tant qu’a faire, autant partager avec le monde. Pour les lecteurs avertis, vous aurez remarque que je traite que des fichiers textes qui sont donc parfaitement adaptés pour un gestionnaire de source tel que Subversion ou Git.