Contrôle d'intégrité
Contrôle d'intégrité
|
||||
| |
Dans quel but installer un contrôle d'intégrité ?
Un contrôle d'intégrité s'exerce avec un Contrôleur d'intégrité chargé d'alerter l'utilisateur chaque fois que quelque chose est modifié, créé ou supprimé sur une machine alors que ce quelque chose est "critique" (un programme, un paramètre de comportement de l'ordinateur, une commande, un composant du système etc. ...) pour :
Que faut-il surveiller ?
Les propriétés de tous les fichiers "sensibles" - on ne surveille pas les fichiers de données utilisateur (documents de traitement de texte, images, sons etc. ...) par des outils de contrôle d'intégrité.
Ces propriétés portent sur :
Comment surveiller ?
Alors que le système est réputé dans un état sain (immédiatement après son installation et application des derniers correctifs à partir d'un support local (cd-rom) sans aller sur l'Internet, vous faites un calcul de chiffres clé pour tous les fichiers système et tous les objets critiques. Vous notez tout cela ainsi que toutes les propriétés dans une base de données. C'est un ciiché du système à un instant de raison.
Par la suite, chaque fois qu'un objet est sollicité (ouverture d'un programme exécutable, d'un composant du système etc. ...) vous refaites la même chose et comparez les résultats obtenus à ceux notés dans la base de données de référence.
Dans la pratique, ceci est fait automatiquement et en temps réel avec un "contrôleur d'intégrité".
S'il y a concordance parfaite, aucune alerte n'est émise est le travail se poursuit normalement.
S'il y a une divergence, et en fonction du degré de surveillance souhaité (paranoïa totale, moyenne, faible...) il y a production d'un message d'alerte signalant à l'utilisateur qu'un composant est modifié. Le système d'alerte empêche alors le composant de s'ouvrir (de s'exécuter) et attend que l'utilisateur donne son avis.
Limites du contrôle d'intégrité
Un ordinateur simplement "bien protégé" comporte déjà un pare-feu, un antivirus et un anti-trojans (voir nos recommandations de kits de sécurité). Il s'avère, dans la pratique, que cette configuration minimale de sécurité est déjà rare. Un ordinateur qui comporterait, en sus, un contrôleur d'intégrité, est un ordinateur blindé avec un utilisateur qui a tout prévu ! Seulement voilà :
Assistance à la prise de décision
Ce genre de décision ne relève, normalement, que d'un administrateur système. Comment s'en sortir lorsque l'on est un simple particulier utilisant son ordinateur sans en avoir le mode d'emploi mais tout en souhaitant échapper à la face obscure de l'Internet. Il n'y a pas de solution simple et "presse bouton". Pour s'assurer qu'un composant Microsoft (et de quelques autres marques) est fiable (il a un bon chiffre clé signé par l'éditeur) on peut consulter le serveur de signatures des éditeurs avec RunScanner mais ce n'est déjà pas un produit simple.
La solution réside donc dans un paramétrage fin du contrôleur d'intégrité pour qu'il ne produise pas trop d'alertes, c'est-à-dire en baissant son niveau de vigilance et en excluant un certain nombre d'objets de la surveillance ce qui nécessite un travail de paramétrage initial pointilleux (entendez, par là, un travail long et fastidieux).
Evènements produisant de grandes quantités d'alertes
Il s'agit des mises à jour comme "Microsoft Update". Ces modifications doivent être faites avec la plus grande précaution, si possible en ayant téléchargé et gravé les correctifs depuis les sites des éditeurs eux-mêmes (sans jamais passer par un site de téléchargement tiers) puis en appliquant ces correctifs HORS LIGNE. Microsoft Update, par exemple, oblige à se connecter au site de Microsoft avec Internet Explorer (ce qui est une première faille de sécurité) et avec la technologie ActiveX activée (ce qui est une seconde faille de sécurité).
Ensuite, les alertes risquent de ne pas être émissent immédiatement mais diluées dans le temps (le fonctionnement en temps réel des contrôleurs d'intégrité fait que l'objet est contrôlé au moment où il est sollicité - s'il est modifié maintenant mais sollicité dans plusieurs mois, l'utilisateur sera, au bas mot, perplexe. Il faut donc, après une mise à jour touchant plusieurs composants, pouvoir faire un recalcul des contrôles d'intégrité sur la totalité des objets, analyser le journal (le rapport) produit par le contrôleur d'intégrité et mettre à jour la base de données en une seule fois.
Attaques des contrôleurs d'intégrité
Les contrôleurs d'intégrité qui analysent les journaux des systèmes (les traces dans les logs) peuvent être aveuglés par un attaquant qui efface ou camoufle ses traces.
Un attaquant peut tenter de modifier la base de signatures du contrôleur d'intégrité. Le contrôleur d'intégrité doit être assez fort pour protéger ses objets.
Un attaquant peut tenter de modifier l'exécutable même du contrôleur d'intégrité qui doit être assez fort pour s'auto-protéger.
Solutions existantes
Contrôleurs d'intégrité
Avant de se lancer dans l'installation, même gratuite, d'un véritable contrôleur d'intégrité, il existe dans les pare-feu majeurs un contrôleur d'intégrité.
Recommandé :
Remarque :
Les "grands" contrôleurs d'intégrité, comme Tripwire, sont souvent sous Linux mais pas sous Windows, analysent les journaux et fonctionnent en batch (en temps différé), produise des alertes à postériori (c'est trop tard !) mais pas en temps réel et omettent également le contrôle d'injection dans un processus déjà monté en mémoire. Ils n'accèdent pas aux serveurs de signatures des éditeurs ce qui serait la base même, l'essence, le fondamental de leur travail !
Un contrôle d'intégrité s'exerce avec un Contrôleur d'intégrité chargé d'alerter l'utilisateur chaque fois que quelque chose est modifié, créé ou supprimé sur une machine alors que ce quelque chose est "critique" (un programme, un paramètre de comportement de l'ordinateur, une commande, un composant du système etc. ...) pour :
- Détecter une intrusion
- Détecter une faille de sécurité
- Tracer une installation d'un logiciel ou une session de travail
- Contrôleurs d'intégrité :
Les contrôleurs d'intégrité sont passifs et vérifient l'intégrité des objets (fichiers)
- IDS - HIDS
Les IDS et HIDS détectent et signalent des comportements suspects et ne contrôlent pas l'intégrité des objets (fichiers).
- IPS - HIPS
Les IPS et HIPS contrôlent des comportements (de composants ou du réseau), pas l’intégrité des objets (fichiers). Ils sont actifs et réagissent en temps réel pour bloquer un comportement suspect.
Que faut-il surveiller ?
Les propriétés de tous les fichiers "sensibles" - on ne surveille pas les fichiers de données utilisateur (documents de traitement de texte, images, sons etc. ...) par des outils de contrôle d'intégrité.
Ces propriétés portent sur :
- le contenu (chiffre clé de type MD5 ou SHA1 etc. ... (checksum) comme peut en produire SummerProperties)
- le contenant (l'enveloppe). Des informations comme la taille du fichier ou sa date de dernière modification et sa date de dernier accès sont peu significatives mais des paramètres modifiés portant sur les droits (d'exécuter, d'ouvrir, de modifier, de créer, de supprimer etc. ...) et les propriétaires des fichiers peuvent être significatifs.
Comment surveiller ?
Alors que le système est réputé dans un état sain (immédiatement après son installation et application des derniers correctifs à partir d'un support local (cd-rom) sans aller sur l'Internet, vous faites un calcul de chiffres clé pour tous les fichiers système et tous les objets critiques. Vous notez tout cela ainsi que toutes les propriétés dans une base de données. C'est un ciiché du système à un instant de raison.
Par la suite, chaque fois qu'un objet est sollicité (ouverture d'un programme exécutable, d'un composant du système etc. ...) vous refaites la même chose et comparez les résultats obtenus à ceux notés dans la base de données de référence.
Dans la pratique, ceci est fait automatiquement et en temps réel avec un "contrôleur d'intégrité".
S'il y a concordance parfaite, aucune alerte n'est émise est le travail se poursuit normalement.
S'il y a une divergence, et en fonction du degré de surveillance souhaité (paranoïa totale, moyenne, faible...) il y a production d'un message d'alerte signalant à l'utilisateur qu'un composant est modifié. Le système d'alerte empêche alors le composant de s'ouvrir (de s'exécuter) et attend que l'utilisateur donne son avis.
Limites du contrôle d'intégrité
Un ordinateur simplement "bien protégé" comporte déjà un pare-feu, un antivirus et un anti-trojans (voir nos recommandations de kits de sécurité). Il s'avère, dans la pratique, que cette configuration minimale de sécurité est déjà rare. Un ordinateur qui comporterait, en sus, un contrôleur d'intégrité, est un ordinateur blindé avec un utilisateur qui a tout prévu ! Seulement voilà :
- Installation du contrôleur d'intégrité
Le contrôleur d'intégrité est installé sur une machine réputée saine. Il calcule alors les chiffres clé de tous les objets à surveiller et collecte toutes les propriétés sensibles. Avec cela il construit sa base de signatures initiale et en fait la clé de voûte de son utilisation - c'est son système de référence.
Par quelle aberration un individu, même ingénieur expert en sécurité, peut déclarer qu'une machine est saine ?
Il faudra un jour donner un coup de balais là-dedans car monter une base de signatures à partir des composants trouvés dans une machine au lieu de le faire à partir des signatures numériques des éditeurs (serveurs de certificats numériques) me laisse bouché bée. Toute la sécurité, appuyée sur un contrôleur d'intégrité, est trivialement fondée sur l'idée saugrenue qu'à, un jour, quelqu'un qui se dit que sa machine est réputée saine, que tous ses composants sont réputés sains et il prend l'initiative d'en faire les signatures de référence. Personne n'a aucun moyen d'en être assuré ! C'est juste une supposition, un espoir ! Dans ces conditions, un contrôleur d'intégrité risque de signer un composant infesté et d'alerter l'utilisateur le jour ou le même composant, mais sain, tente (pour une raison ou pour une autre - réparation du système...), de remplacer le virus ! On marche sur la tête ! Il y a un soucis avec tous les contrôleurs d'intégrité.
- Utilisation du contrôleur d'intégrité
- L'utilisateur face à une alerte
L'utilisateur est bloqué par une alerte et il ne sait pas pourquoi un composant est modifié or les composants sont très souvent modifiés, même en dehors des périodes de mises à jour (le second mardi de chaque mois pour les produits Microsoft, par exemple). Que faire ? Refuser la modification et rester bloqué ou l'accepter sans savoir pourquoi ou perdre un temps fou à chercher sur l'Internet ou au téléphone de quoi il retourne (information que l'on ne trouvera jamais car elle n'existe pas) ?
C'est là qu'apparaît, avec les meilleures intentions du monde, le virus PELCEC. L'observation du comportement des utilisateurs montre que la modification est généralement acceptée sans aucune vérification, au petit bonheur la chance, les mains jointes, en prière, en espérant que l'on ne fait pas une bêtise et que la modification est "normale".
On ne gère pas un système de traitement de l'information les yeux fermés et en vivant dans l'espoir que "ça marche" ! Il y a un soucis là, avec l'usage de tous les contrôleurs d'intégrité ! Le traitement d'une l'information comme "Il y a une modification du contenant ou du contenu de tel composant" est tout simplement transféré à l'utilisateur. Je met au défi l'utilisateur, même très avancé, de savoir pourquoi et par qui un composant est modifié !
- Les composants "exceptionnels"
Il y a la liste d'exceptions : ne pas contrôler tel et tel composants ! Qui est capable de dire pourquoi on ne peut contrôler l'injection dans Excel car son comportement fait qu'il se modifie "naturellement" une fois monté en mémoire ? A partir du moment où des composants sont exclus "institutionnellement" des contrôles d'intégrités, c'est la porte ouverte, probablement réellement (ce n'est pas un fantasme de maniaque de la sécurité ou de paranoïaque) à des choses comme la NSA Trapdoor.
Combien de logiciels sont équipés de système d'autodéfense ? Pour un OutPost Pro qui se protège avec son mécanisme "Légitime Défense", combien se laissent faire. Pourquoi l'explorateur de Windows tente de modifier OutPost Pro une fois celui-ci lancé ?
Et pourquoi les Contrôleur d'intégrité ne s'intéressent pas aux injections en mémoire.
- Le retour en arrière - Le RollBack
Il s'agit de droit de repentir. Je me suis trompé : j'ai accepté une alerte et je n'aurais pas dû - je veux restaurer ma machine à son état précédent en ce qui concerne telle alerte (dont restaurer la version précédente du composant modifié ou supprimé etc. ...).
Ne cherchez pas - aucun contrôleur d'intégrité ne dispose de cette fonctionnalité.
- L'utilisateur face à une alerte
Assistance à la prise de décision
Ce genre de décision ne relève, normalement, que d'un administrateur système. Comment s'en sortir lorsque l'on est un simple particulier utilisant son ordinateur sans en avoir le mode d'emploi mais tout en souhaitant échapper à la face obscure de l'Internet. Il n'y a pas de solution simple et "presse bouton". Pour s'assurer qu'un composant Microsoft (et de quelques autres marques) est fiable (il a un bon chiffre clé signé par l'éditeur) on peut consulter le serveur de signatures des éditeurs avec RunScanner mais ce n'est déjà pas un produit simple.
La solution réside donc dans un paramétrage fin du contrôleur d'intégrité pour qu'il ne produise pas trop d'alertes, c'est-à-dire en baissant son niveau de vigilance et en excluant un certain nombre d'objets de la surveillance ce qui nécessite un travail de paramétrage initial pointilleux (entendez, par là, un travail long et fastidieux).
Evènements produisant de grandes quantités d'alertes
Il s'agit des mises à jour comme "Microsoft Update". Ces modifications doivent être faites avec la plus grande précaution, si possible en ayant téléchargé et gravé les correctifs depuis les sites des éditeurs eux-mêmes (sans jamais passer par un site de téléchargement tiers) puis en appliquant ces correctifs HORS LIGNE. Microsoft Update, par exemple, oblige à se connecter au site de Microsoft avec Internet Explorer (ce qui est une première faille de sécurité) et avec la technologie ActiveX activée (ce qui est une seconde faille de sécurité).
Ensuite, les alertes risquent de ne pas être émissent immédiatement mais diluées dans le temps (le fonctionnement en temps réel des contrôleurs d'intégrité fait que l'objet est contrôlé au moment où il est sollicité - s'il est modifié maintenant mais sollicité dans plusieurs mois, l'utilisateur sera, au bas mot, perplexe. Il faut donc, après une mise à jour touchant plusieurs composants, pouvoir faire un recalcul des contrôles d'intégrité sur la totalité des objets, analyser le journal (le rapport) produit par le contrôleur d'intégrité et mettre à jour la base de données en une seule fois.
Attaques des contrôleurs d'intégrité
Les contrôleurs d'intégrité qui analysent les journaux des systèmes (les traces dans les logs) peuvent être aveuglés par un attaquant qui efface ou camoufle ses traces.
Un attaquant peut tenter de modifier la base de signatures du contrôleur d'intégrité. Le contrôleur d'intégrité doit être assez fort pour protéger ses objets.
Un attaquant peut tenter de modifier l'exécutable même du contrôleur d'intégrité qui doit être assez fort pour s'auto-protéger.
Solutions existantes
Contrôleurs d'intégrité
Avant de se lancer dans l'installation, même gratuite, d'un véritable contrôleur d'intégrité, il existe dans les pare-feu majeurs un contrôleur d'intégrité.
Recommandé :
- le contrôleur d'intégrité en temps réel du pare-feu OutPost Pro
- la surveillance d'installation, désinstallation et le "surfback" / "RollBack" avec Total Uninstall
- le contrôle de signatures numériques avec RunScanner
Remarque :
Les "grands" contrôleurs d'intégrité, comme Tripwire, sont souvent sous Linux mais pas sous Windows, analysent les journaux et fonctionnent en batch (en temps différé), produise des alertes à postériori (c'est trop tard !) mais pas en temps réel et omettent également le contrôle d'injection dans un processus déjà monté en mémoire. Ils n'accèdent pas aux serveurs de signatures des éditeurs ce qui serait la base même, l'essence, le fondamental de leur travail !
| Historique des révisions de ce document : |
|
19.01.2007
|
Rédigé en écoutant :
Music
Music