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. Mais snoopylogger a un problème car il exécute la commande et log après (vérifié dans le source), donc si la commande consiste à détruire le système de log l'attaquant aurait réussit à ne pas être loggé. En fait il faudrait un système qui laisse le temps au message de partir.
• 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é.

Pour que le système fonctionne, il faut que la/les machines servant à réceptionner les traces (ie les serveurs de log) soient accessibles tout le temps, sinon un attaquant n'a qu'à attendre (voir provoquer) que le(s) serveur(s) de log soient hs. Ça me semble envisageable de fermer l'accès ssh du serveur d'email pendant n heures tant que le(s) serveur(s) de log ne sont pas accessibles ? Ça serait alors bien d'avoir deux niveaux d'accès pour les admins: un niveau super admin où il faut plusieurs admin pour accéder et ce service serait toujours ouvert, un niveau admin où là le service pourrait être fermé si les serveurs de logs sont hs.

D'après le document http://www.employees.org/~lonvick/transport/draft-ietf-syslog-transport-udp-00.html#reliability la transmission par udp des logs ne garantie pas l'origine du message. Ça pourrait permettre à un attaquant de faire croire que certaines commandes ont été lancées sur le serveur, ce qui peut discréditer une personne à tord ou nous désorganiser. Pour parer à cela je propose d'utiliser un tunnel par ssh pour les logs sur serveur distant.

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.