Product SiteDocumentation Site

10.5. Idées géniales ou paranoïaques — ce que vous pourriez faire

C'est probablement la section la plus instable et la plus amusante, car j'espère que quelques unes des idées « bah, ça semble dingue » pourraient être réalisées. Vous trouverez ci-dessous certaines idées pour améliorer la sécurité — suivant votre point de vue vous les qualifierez de géniales, paranoïaques, folles ou inspirées.
  • S'amuser avec PAM (Pluggable Authentication Modules). Conformément à l'article PAM du phrack 56, ce qui est bien avec PAM, c'est qu'« il n'est limité que par votre imagination ». C'est vrai. Imaginez une connexion de superutilisateur seulement possible avec empreinte digitale ou un scan de l'œil ou une cryptocarte (pourquoi ai-je fait une conjonction de OU et pas de ET ici ?).
  • Journalisation fasciste. Je voudrais dire que tout ce dont nous avons discuté plus haut est de la « journalisation douce ». Si vous voulez effectuer une vraie journalisation, procurez-vous une imprimante avec du papier listing et journalisez tout en l'imprimant. Cela semble amusant, mais c'est fiable et ne peut être supprimé, ni altéré.
  • Distribution CD. Cette idée est très simple à réaliser et offre une assez bonne sécurité. Créez une distribution Debian durcie, avec les règles de pare-feu adéquate, faites-en une image ISO amorçable et gravez-la sur un CD. Vous avez maintenant une bonne distribution en lecture seule avec environ 600 Mo d'espace pour les services. Assurez-vous juste que toutes les données qui devraient être écrites soient écrites sur le réseau. Il est impossible pour des intrus d'obtenir un accès en lecture et écriture sur ce système et toute modification réalisée par un intrus sera désactivée avec un redémarrage du système.
  • Désactiver la prise en charge des modules. Comme décrit auparavant, une fois désactivée l'utilisation des modules du noyau à la compilation, beaucoup de portes dérobées basées sur le noyau sont impossibles à implémenter car la plupart d'entre elles sont basées sur l'installation de modules du noyau modifiés.
  • Journalisation par câble série (contribution de Gaby Schilders). Tant que les serveurs ont des ports série, imaginez une machine dédiée à la journalisation pour un certain nombre de serveurs. Le système de journalisation serait déconnecté du réseau, et connecté aux serveurs par un multiplexeur de ports série (cyclades ou similaire). Maintenant faites journaliser vos serveurs par leurs ports série en écriture seule. La machine de journalisation n'accepterait que du texte en clair en entrée sur ses ports séries et n'écrirait que sur un fichier journal. Branchez un graveur de CD ou DVD et transférez-y les fichiers journaux quand le fichier journal atteint la capacité du support. Maintenant il ne manque plus qu'un graveur avec chargeur de CD automatique… Pas autant « copie en dur » que la journalisation directe vers l'imprimante, mais cette méthode peut gérer de larges volumes et les CD prennent moins d'espace de stockage.
  • Modifiez les attributs de tous les fichiers avec chattr (tiré du Tips-HOWTO écrit par Jim Dennis). Tout de suite après avoir installé et configuré initialement le système, utilisez le programme chattr avec l'attribut +i pour rendre les fichiers non-modifiables (le fichier ne peut être supprimé, renommé, lié ou réécrit). Envisagez de positionner cet attribut sur tous les fichiers de /bin, /sbin/, /usr/bin, /usr/sbin, /usr/lib et tous les fichiers noyau de la racine. Vous pouvez également faire une copie de tous les fichiers de /etc/, en utilisant tar, et marquer l'archive comme immuable.
    Cette stratégie permettra de limiter les dégâts possibles une fois connecté en superutilisateur. Cela empêchera d'écraser des fichiers avec un opérateur de redirection mal placé, de rendre le système inutilisable avec une espace mal placée dans une commande rm -rf (il est toujours possible de faire pas mal de dégâts aux données, mais les bibliothèques et binaires seront mieux protégés).
    Cela limite aussi la réalisation d'un grand nombre d'exploitations de faille de sécurité et de dénis de service (car beaucoup d'entre eux dépendent de l'écrasement d'un fichier par les actions d'un programme SETUID qui ne fournit aucune invite de commandes).
    Le seul inconvénient de cette stratégie survient lorsque vous compilez et installez divers binaires systèmes. D'un autre côté, cela empêche aussi le make install d'écraser les fichiers. Quand vous oubliez de lire le Makefile et de faire un chattr -i, les fichiers qui vont être réécrits (et les répertoires auxquels vous voulez ajouter des fichiers) ‐ la commande make échoue, utilisez juste la commande chattr et relancez-le. Vous pouvez aussi profiter de l'occasion pour déplacer vos vieux binaires et bibliothèques dans un répertoire .old/ ou dans une archive tar par exemple.
    Remarquez que cette stratégie empêche aussi de mettre à jour les paquets du système car les fichiers existants ne peuvent être remplacés, vous pourriez donc avoir un mécanisme pour désactiver l'attribut immuable sur tous les binaires juste avant de faire un apt-get update.
  • Couper 2 ou 4 fils du câble réseau afin de rendre les communications UDP unidirectionnelles. Ensuite, utilisez des paquets UDP pour envoyer des informations à la machine destinatrice qui peut agir en tant que serveur de journalisation sécurisé ou système de stockage de carte de crédit.

10.5.1. Construction d'un pot de miel

Un pot de miel est un système conçu pour apprendre aux administrateurs système les techniques de sondage et d'exploitation des attaquants. Il s'agit d'une configuration système qui a pour but d'être sondée, attaquée et potentiellement exploitée. En apprenant les outils et méthodes utilisées par l'attaquant, un administrateur système peut apprendre à mieux protéger ses propres systèmes et son réseau.
Un système Debian GNU/Linux peut facilement être configuré comme un pot de miel, si vous y consacrez le temps de l'implémenter et de le surveiller. Vous pouvez facilement mettre en place le serveur de pot de miel factice ainsi que le pare-feu[76] qui contrôle le pot de miel et un certain type de détecteur d'intrusion réseau, placez-le sur Internet et attendez. Prenez soin de vous assurer d'être averti à temps (consultez Section 4.13, « L'importance des journaux et des alertes ») si le système est victime d'une exploitation pour que vous puissiez prendre des mesures appropriées et mettre un terme à la compromission après en avoir assez vu. Voici quelques paquets et problèmes à considérer lors de la configuration de pot de miel :
  • la technologie pare-feu dont vous aurez besoin (fournie par les noyaux Linux) ;
  • syslog-ng pour envoyer les journaux du pot de miel vers un serveur de journalisation système distant ;
  • snort pour configurer la capture de tout le trafic réseau arrivant sur le pot de miel et détecter les attaques ;
  • osh, un interpréteur de commande restreint à sécurité améliorée et SETUID root avec journalisation (consultez l'article de Lance Spitzner référencé ci-dessous) ;
  • tous les démons à utiliser pour le serveur factice pot de miel. Selon le type d'attaque que vous voulez analyser, vous renforcerez ou non le pot de miel et vous le conserverez ou non à jour avec les mises à jour de sécurité ;
  • des vérificateurs d'intégrité (consultez Section 4.17.3, « Vérifier l'intégrité des systèmes de fichiers ») et la boîte à outils du légiste (The Coroner's Toolkit (tct)) pour faire des audits après l'attaque ;
  • honeyd et farpd pour mettre en place un pot de miel qui écoutera les connexions vers des adresses IP non utilisées et les fera suivre vers des scripts simulant des services actifs. Regardez également iisemulator ;
  • tinyhoneypot pour mettre en place un serveur pot de miel simple avec des services factices.
Si vous ne pouvez pas utiliser des systèmes de réserve pour construire les pots de miel et les systèmes réseau pour le protéger et le contrôler, vous pouvez utiliser la technologie de virtualisation disponible dans xen ou uml (User-Mode-Linux). Si vous choisissez cette route, vous devrez modifier le noyau soit avec kernel-patch-xen, soit avec kernel-patch-uml, ou encore installer l'un des noyaux précompilés disponibles depuis Debian Lenny.
Vous pouvez en lire plus sur la construction des pots de miel dans l'excellent article http://www.net-security.org/text/articles/spitzner/honeypot.shtml de Lance Spizner (dans la série des « connaissez votre ennemi »). De même, le http://project.honeynet.org/ fournit des informations utiles sur la façon de configurer un pot de miel et de contrôler les résultats d'une attaque.

[76] Vous utiliserez généralement un pare-feu pont pour que le pare-feu lui-même ne soit pas détectable, consultez Section B.4, « Configuration d'un pare-feu pont ».