Ca pourrait etre pas mal de demander comment font d'autres collectifs qui administrent a plusieurs des serveurs sensibles, peut-etre qu'il existe des protocoles voire des logiciels deja bien rodes.

Avoir une machine afin de tester dans le vide toute action a effectuer sur la machine en production : Un serveur virtuel sous debian lenny est opérationnel sur bignookie.dyndns.org . Il est accessible en SSH sur le port 5000. Pour obtenir le mot de passe root, envoyez un mail chiffré à Julien.

Une personne a parle de son experience de git, ou tout le monde peut proposer des modifications sur les fichiers de configuration, mais celles-ci ne sont envoyees sur le serveur que lorsqu'il y a consensus pour la modification.

Il est assez facile de mettre place à la main un versionnement du répertoire /etc . Par contre cela est assez lourd à l'utilisation car tout changement dans /etc devra être suivi d'une validation (commit), enfin une création de version. Heureusement il existe des magnifiques paquets debian comme etckeeper qui créent des déclencheurs (hook) pour versionner tout seul au fur et à mesure de l'utilisation du système!! C'est fou non? etckeeper peut gérer Mercurial (Hg), Git Darcs et Bzr. Testé et approuvé. Il est en place sur le serveur de test avec un dépot Mercurial.

Ce genre d'outil est super pour ce qui est de l'historisation des changements de config, ce qui englobe “qui a fait quoi, quand” et aussi “je veux revenir en arrière”. Par contre celà ne nous règle pas le problème du partage des droits d'administration.

Mis a part la configuration, il est parfois necessaire d'y agir en direct pour regler tel ou tel probleme en tant que super administrateur (root). Une idee simple serait de “decouper” le mot de passe root de sorte qu'il soit necessaire que plusieurs personnes approuvent la modification pour qu'elle soit effectuee. Un probleme avec cela est si une personne est absente, donc faire un truc avec redondance ou (par exemple) 3 personnes suffisent a approuver la modification.

Utilisation fine de sudo?

Le système “Action non-solitaire” risque d'être lourde, voici autre solution envisageable:

Nous supposons ici que l'accès en tant qu'administrateur est confié à des personnes dont le groupe a une confiance raisonnable, car si cette personne est hostile elle est détectée mais il peut y avoir une perturbation du service et du travail de réparation. Néanmoins ce système ne permet pas une agression forte. Nous supposons aussi qu'un système de sauvegarde permet de rétablir le serveur en cas de dégradation ( ce qui de toute manière est nécessaire).

L'idée est de

• permettre à chaque administrateur l'accès
• tracer (en envoyant le log vers un serveur à l'accès très restreint) les commandes éxécutées. Pour cela on peut utiliser un outil tel que snoopylogger.
• demander aux administrateurs de respecter des règles tel que:
  • écrire dans un journal le but de l'action et d'expliquer l'intervention
  • de ne pas faire d'intervention majeure sans le consentement du groupe (technique et ou non technique suivant la porté de l'intervention).

Il faut remarquer que le système de trace ne permet pas de tout savoir, car l'agresseur peut toujours stoper le système de trace. Mais il permet de détecter qui a causé le problème car le début de l'agression est tracé.

les commandes ecrites sur le serveur seraient envoyees sur une mailing-list exterieure en direct.

Le programme log2mail, trouvé par hasard, fait ça simplement apparement. Il observe les logs et envoie un mail pour chaque log qui matche une expression régulière. Simple et efficace.