Principes de fonctionnement

Dans cette section

•Informations générales

•Définition des zones du système de fichiers à surveiller

•Mode de surveillance renforcée des fichiers

Informations générales

Le moniteur du système de fichiers SpIDer Guard fonctionne dans l’espace utilisateur (user mode) et utilise pour le contrôle des événements du systeme de fichiers le mécanisme système fanotify ou un module noyau chargeable spécial Linux (LKM — Loadable Kernel Module) développé par la société Doctor Web. Dans les paramètres, il est recommandé d’utiliser le mode automatique (Auto), qui permettra au composant de déterminer et d’utiliser le meilleur mode de fonctionnement au démarrage, car toutes les versions du noyau Linux ne prennent pas en charge le mécanisme fanotify utilisé par le moniteur. Si le composant ne peut pas utiliser le mode d’intégration spécifié dans les paramètres, il s’arrête immédiatement après le démarrage. Si le mode automatique est spécifié, le composant essaiera d’utiliser d’abord fanotify, puis le module du noyau LKM. Si l’utilisation de l’un de ces modes échoue, le composant s’arrêtera.

Lorsque des fichiers nouveaux ou modifiés sont détectés, le moniteur envoie une tâche d’analyse au composant d’analyse des fichiers Dr.Web File Checker, qui à son tour lance leur analyse par le moteur de scan Dr.Web Scanning Engine. Lorsqu’il fonctionne via le mécanisme système fanotify, le moniteur peut bloquer l’accès aux fichiers (de tous les types ou uniquement aux fichiers exécutables — PE, ELF, scripts avec préambule #!) qui n’ont pas encore été analysés, jusqu’à la fin de leur analyse (voir ci-dessous).

Définition des zones du système de fichiers à surveiller

Pour optimiser l’analyse du système de fichiers, le moniteur de système de fichiers SpIDer Guard contrôle uniquement l’accès aux fichiers situés dans les zones du système de fichiers spécifiées dans la configuration. Chaque zone est définie comme un chemin d’accès à un répertoire de l’arborescence du système de fichiers et est appelée espace protégé (protected space). L’ensemble de tous les espaces protégés forme dans le système de fichiers une zone de surveillance unique, contrôlée par le moniteur. Outre la zone de surveillance, il est également possible de définir dans les paramètres du composant un ensemble de répertoires du système de fichiers à exclure de la surveillance (zone d’exclusion). Si aucun espace protégé n’est spécifié dans les paramètres du composant, la zone de surveillance couvre l’ensemble de l’arborescence des répertoires du système de fichiers. Ainsi, seuls les fichiers dont les chemins d’accès appartiennent à la zone de surveillance, mais pas à la zone d’exclusion, sont soumis à la surveillance.

L’utilisation d’exceptions peut s’avérer nécessaire, par exemple, si certains fichiers sont fréquemment modifiés, ce qui entraîne leur analyse constante et, par conséquent, surcharge le système. Si vous savez avec certitude que les modifications fréquentes des fichiers dans un certain répertoire ne sont pas le résultat d’une activité malveillante, mais le résultat du fonctionnement d’un programme de confiance, vous pouvez ajouter le chemin d’accès à ce répertoire ou aux fichiers modifiés à la liste des exceptions. Dans ce cas, le moniteur du système de fichiers SpIDer Guard ne réagira pas aux modifications de ces fichiers, même s’ils appartiennent à la zone de surveillance. De plus, il est possible d’indiquer le programme qui gère les fichiers dans la liste des programmes de confiance (paramètre de configuration ExcludedProc), alors les opérations sur les fichiers effectuées par ce programme n’entraîneront pas non plus d’analyse des fichiers, même si ces fichiers se trouvent dans la zone de surveillance. De même, si nécessaire, vous pouvez interdire la surveillance et l’analyse des fichiers situés dans d’autres systèmes de fichiers montés sur le système de fichiers local (par exemple, les répertoires montés via CIFS à partir de serveurs de fichiers externes). Pour spécifier les systèmes de fichiers dont les fichiers ne doivent pas être analysés, utilisez le paramètre ExcludedFilesystem.

Les espaces protégés, en tant que parties de la zone de surveillance avec les paramètres d’analyse qui leur sont spécifiés, sont définis dans les paramètres du composant comme des sections nommées contenant dans leur nom un identificateur unique arbitraire attribué à l’espace protégé. Chaque section décrivant un espace contient le paramètre Path qui définit le chemin d’accès dans le système de fichiers où sont stockés les répertoires de cet espace protégé (c’est-à-dire la partie de l’arborescence du système de fichiers surveillée dans le cadre de cet espace), ainsi que le paramètre ExcludedPath qui définit la zone d’exclusion locale (c’est-à-dire relative à Path) à l’intérieur de l’espace protégé. Le paramètre ExcludedPath peut contenir des masques de fichiers standard (c’est-à-dire contenir les caractères * et ?). Outre les zones d’exclusion locales, une zone d’exclusion globale peut également être définie dans les paramètres à l’aide du paramètre ExcludedPath, spécifié en dehors des sections décrivant les espaces protégés. Tous les répertoires appartenant à cette zone, y compris les répertoires des espaces protégés, seront exclus de l’analyse. Seules les zones d’exclusion globales et propres s’appliquent à chaque espace protégé : si un espace est imbriqué dans un autre, les paramètres d’exclusion spécifiés pour l’espace protégé qui l’englobe ne s’appliquent pas à l’espace imbriqué. En outre, les paramètres de chaque espace protégé comportent un paramètre logique Enable qui détermine si la surveillance des fichiers situés dans la zone de surveillance de cet espace est activée ou non. Si la valeur No est définie pour le paramètre, le contenu de cet espace n’est pas contrôlé par le moniteur. De plus, l’espace protégé n’est pas contrôlé par le moniteur si le paramètre Path a une valeur vide.

Examinons un exemple de configuration des zones de surveillance et d’exclusion. Supposons que les paramètres suivants soient définis dans la configuration du composant :

Cela signifie que les fichiers situés dans le répertoire /directory1 et ses sous-répertoires sont surveillés, à l’exception du répertoire /directory1/tmp. De plus, les fichiers dont le nom complet correspond au masque /directory1/*.tmp sont exclus de la surveillance (cela ne concerne pas la zone imbriquée /directory1/directory2, à laquelle ce masque ne s’applique pas, même si cette zone est imbriquée dans l’espace protégé space1). Les fichiers situés dans le répertoire /directory3 ne sont pas contrôlés.

Mode de surveillance renforcée des fichiers

SpIDer Guard peut utiliser trois modes de surveillance :

•Standard (spécifié par défaut) : surveillance d’accès aux fichiers (création, ouverture, fermeture, lancement d’un fichier). Requête de l’analyse du fichier auquel une tentative d’accès a été effectuée. Si une menace est détectée dans le fichier, des actions de neutralisation peuvent y être appliquées. L’accès des applications au fichier en cours d’analyse n’est pas restreint.

•Surveillance renforcée des fichiers exécutables : la surveillance des fichiers non exécutable est la même que dans le mode standard. SpIDer Guard bloque l’opération d’accès demandée jusqu’à l’obtention des résultats de l’analyse pour la présence de menaces.

•Mode paranoïde : SpIDer Guard bloque l’opération demandée d’accès à un fichier jusqu’à l’obtention des résultats de l’analyse pour la présence de menaces.

Pendant un temps déterminé, Dr.Web File Checker enregistre les résultats de l’analyse des fichiers dans un cache spécial. C’est pourquoi en cas d’un nouvel accès à ce fichier, il ne sera pas rescanné si le cache contient les informations nécessaires. Dans ce cas, le résultat tiré du cache sera utilisé en tant que le résultat de l’analyse. Pourtant, l’utilisation du mode « paranoïde » ralentit le travail lors de l’accès aux fichiers.

Pour configurer le mode de surveillance, modifiez la valeur du paramètre BlockBeforeScan dans les paramètres du composant.