Un des serveurs de la fameuse distribution Debian a été compromis le 12 juillet. Une histoire banale d’un compte compromis, puis l’exploitation d’une faille du kernel et le tour est joué. Apparemment les administrateurs du système s’en sont aperçus rapidement et la machine a été ré-installée. Les détails de l’opération sont sur le site de Debian.

Sécuriser une machine servant un repository de code n’est pas chose facile. En effet, l’ensemble des développeurs doivent y avoir accès et la machine est donc accessible publiquement. On imagine facilement que pour des raisons de commodité, il n’est pas fait usage de certificats X.509. Encore moins que ces certificats soient stockés sur des tokens externes. Reste donc l’éternelle paire username/password.

Comment s’en sortir dans ces conditions ? Comme c’est sans doute le cas pour le système visé, il faut monitorer. D’abord dans le but de détecter une activité malveillante sur le système. Il existe une myriade d’outils permettant de vérifier que rien d’anormal ne se passe sur le système. L’approche la plus basique consiste tout simplement à vérifier les logs, et tant qu’à faire, de manière automatique avec logwatch par exemple. On pourra également coupler la surveillance locale avec une analyse des logs du firewall ou d’un système de détection d’intrusion.

Ensuite, il faut être capable de détecter les changements. Par exemple, le communiqué précise que seule une modification de l’exécutable /bin/ping a été relevée. Ce résultat a probablement été obtenu en utilisant un logiciel de vérification d’intégrité, du style tripwire, pour ne citer que le plus connu. Ils ont probablement également vérifié que de nouveaux comptes n’avaient pas été créés, qu’il n’y avait pas de processus supplémentaires, pas de rootkits, etc. Toutes ces opétations ont été effectuées en bootant sur un CD par exemple, puis en montant les partitions compromises en read-only, de manière à pouvoir analyser le file system sans rien supprimer, avec des outils comme The Coroner’s Toolkit.

Au final, la machine a été ré-installée de zéro et restaurée avec un backup antécédent à la date de compromission. Eh oui, ils font des backups

On se rend compte, que finalement, avec une bonne préparation et un monitoring correct, il est possible de relativement bien s’en sortir, même après une compromission totale d’un système. Pour résumer, comment éviter le pire :

1. Faire un backup journalier (et le stocker sur un autre serveur)
2. Démarrer le logging et l’auditing du système
3. Mettre en place un système d’analyse des logs (si on n’a pas le temps de le faire à la main)
4. Corréler les logs locaux avec les logs du firewall ou de l’IDS
5. Utiliser au minimum un outil de vérification de l’intégrité du système
6. Se préparer pour une analyse post-mortem (c’est pas quand c’est arrivé qu’il faut vous y mettre)

Tout ça ne vous empêche pas de patcher régulièrement et supprimer tous les services inutiles du système. Passez donc en bonus le script Bastille (Linux) ou JASS (Solaris) sur la machine et vous ne devriez jamais avoir à vous servir du Coroner’s Toolkit

[Via vulnerabilité.com]

This entry was posted on Sunday, July 16th, 2006 at 7:27 pm and is filed under Glups. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.