[ Administration des systèmes et réseaux | sécurité informatique ]
Un post pour annoncer la naissance de secfault un blog dedié à la sécurité informatique. L’initiateur de ce projet m’a gentiment invité à participer à ce blog collaboratif. J’essaierais d’y apporter mon actualité et mes sentiments par rapport à la sécurité (qui ne seront forcément pas le mêmes qu’un “pain taster” fou ou des gens impliqués dans les aspects recherche).
Longue vie à S3cF@u1t !
Il y’a deux jours, un message assez intéressant est passé sur la liste debian security. Une étude initié par l’université d’Arizona met en lumière plusieurs vulnérabilités dans la manière dont sont conçus les systèmes style apt, yum, yast etc …
En gros ces systèmes sont soumis à trois types d’attaques :
- Les attaques par rejeu.
- Les attaques sur les méta-données des dépôts.
- Les “man in the middle”.
1) Les attaques par rejeu.
Ce type d’attaque consiste à monter un miroir ne distribuant que des vieilles versions de ses logiciels. Ces logiciels sont signés mais vulnérables. L’attaquant pourra logger les IP des machines récupérant les logiciels. On obtient donc une liste des machines avec les paquets vulnérables qu’elles ont téléchargés. Cette attaque se base en grande partie sur le fait qu’il est facile de faire enregistrer un serveur miroir. L’impact de cette attaque est très limité sous Debian et Ubuntu car les updates de sécurité sont distribués via les fameux serveur security.debian.org (sauf pour les versions non stables sid et testing). Ces serveurs sont trusted. Ce type attaque a tout de même initié une réflexion chez les développeurs d’apt : ils souhaitent associer aux dépôts un timestamp signé pour savoir si un dépôt est désynchronisé. Pour finir, il est malheureusement impossible de distribuer les releases via les dépôts security.debian.org, le délai de synchronisation diminuerait énormément l’aspect réactif de ces serveurs.
2) Les attaques sur les méta données.
Les dépôts sont composées de deux éléments : des logiciels (en général signés) et des méta-données. Ces méta-données contiennent souvent un fichier d’index. Une attaque type DoS serait de faire de gigantesques fichiers d’index car dans tout les cas, ils sont téléchargés. La seule parade serait de contenir le cache du système de gestion de paquets sur une partition dédiée. Cette attaque est décrite ici.
3) Les MiM.
Revenons sur l’attaque par rejeu. Les dépôts security.debian.org ne sont pas si invulnérables que ça. Ils sont sensibles au MiM. Si une machine réalise ses mises à jour de sécurité et qu’un proxy transparent intercepte ses requêtes en les loggants, on obtient la listes des vulnérabilités associées à cette machine. Une parade envisagée est de passer les serveurs de sécurité en HTTPS. Une suite de scénarios (catastrophes) commence à ce thread. Certaines distributions commerciales utilisent des miroirs HTTPS.
Today j’ai installé quelques vieux Dell en Ubuntu 8.04 pour faire une salle de libre service.
J’ai pour habitude sur ce genre de machines de me mettre un petit script qui me remonte un résumé logwatch et les paquets nécessitants une mise à jour.
Seulement sur des machines complètement identiques et dont la disponibilité n’est pas un facteur critique, je trouve dommage de réaliser les mises à jour (ou tout autre opération de maintenance) au cas par cas. J’ai donc cherché comment envoyer une commande sur plusieurs machines. J’ai trouvé un paquet de liens sur des scripts bash qui font un for sur une liste d’hôtes et passent des traitements en forced commands. L’avantage de ce genre de trucs est que c’est “cronable” mais il faut avoir des clès SSH sans passphrase. Argh !
J’ai fini par trouver un truc très sympa : ClusterSSH. Cette utilitaire s’installe sur la console d’administration. Une fois installé, on crée des groupes de n machines (sous la forme groupe1 = admin@host1, admin@host2 etc …). Une fois ces groupes crées, on lance le client SSH fourni par ClusterSSH : cssh.
[root@admin]# cssh groupe1
Cette commande vous ouvre n+1 fenêtres :
- n xterm connectés aux machines du groupe.
- 1 zone de saisie dédiée à cssh qui, une fois sélectionnée, vous permet d’écrire sur vos n consoles en même temps.
Je vais pouvoir ranger mon usine à gaz PXELinux / Netboot au placard : elle me servait uniquement à pousser une installation “à jour” sur mes postes 
Arno m’a donné quelques alternatives : capistrano, dsh et pssh