Home Search Contact New
[ Up | Back | Next | Home | Search | Contact | New | EdelWeb ]

Mise à jour automatique de signatures anti-virus


Jean-Christophe Touvet expose la problématique de mise à jour automatique des signatures anti-virus ainsi que les failles qui en résultent. Exemple concret de solution.

Introduction
1. Problématique
2. Solution retenue
3. Mise en oeuvre
4. Problèmes de sécurité posés par les mises à jour automatisées
Introduction

La mise à jour régulière de signatures anti-virus sur les postes de travail d'une entreprise est indispensable. Lorsque l'entreprise est connectée à Internet, donc lorsque les utilisateurs sont susceptibles de recevoir par messagerie ou de télécharger sur le Web des fichiers infectés à tout moment, il est nécessaire que les mises à jour soient effectuées le plus rapidement possible après leur mise à disposition.

Presque tous les produits anti-virus du marché intègrent une fonction de mise à jour en ligne depuis le site Internet de l'éditeur. Mais l'automatisation de cette mise à jour pose quelques problèmes, particulièrement lorsque le nombre de postes de travail et serveurs concernés est élevé. Après une description de cette problématique, cet article expose une solution possible et son application pratique dans le cas du produit anti-virus McAfee VirusScan de NAI.

1. Problématique

Le produit McAfee VirusScan de NAI propose de paramétrer et éventuellement de programmer la mise à jour des signatures au moyen d'une console d'administration.


Copie d'écran 1 : console VirusScan

Deux types de mises à jour sont proposés :

  • AutoUpdate, pour mettre à jour la base des signatures de virus.
  • AutoUpgrade, pour mettre à jour le moteur de recherche de virus. Ce type de mise à jour est beaucoup moins fréquent (typiquement tous les deux ou trois mois contre plusieurs fois par semaine pour le précédent).

Par défaut, une mise à jour AutoUpdate par FTP depuis le site Internet de NAI est définie (mais non programmée). Il est donc possible, pour des utilisateurs disposant d'un accès Internet, d'utiliser cette fonction pour télécharger les nouvelles signatures.


Copie d'écran 2 : paramètres de mise à jour par FTP depuis le site Internet de NAI

Cependant, cette méthode présente certains inconvénients :

  • Lorsque les postes de travail sont très nombreux, on subit un véritable gaspillage de bande passante, puisque chaque poste télécharge les mêmes fichiers (plusieurs centaines de Ko) indépendamment des autres. Or, même lorsqu'un proxy-cache est installée sur le site, les fichiers transférés par FTP sont rarement « cachés » de manière satisfaisante, nous y reviendrons ci-dessous.
  • Il n'est pas rare d'assister à des échecs de mise à jour dus à une connexion FTP interrompue prématurément. Lorsqu'un proxy-cache est utilisé sur le site, cela peut d'ailleurs avoir pour conséquence de laisser un fichier tronqué dans le cache, interdisant aux autres utilisateurs d'effectuer leur mise à jour correctement. C'est l'une des raisons pour lesquelles on désactive souvent la fonction de cache pour les transferts FTP.
  • Même dans le cas où les fichiers ont été transférés correctement, la mise à jour de l'anti- virus peut empêcher certaines applications de fonctionner (« faux positifs » introduits par de nouvelles signatures).
  • La présence d'un Firewall Internet sur le site pose souvent des problèmes pour les transferts FTP. Une option « Utiliser un serveur proxy » est disponible dans les paramètres de configuration de VirusScan, mais elle est implémentée de façon relativement sommaire, posant des problèmes d'incompatibilité avec certains logiciels proxy du marché (par exemple, proxy avec authentification).
  • La programmation de cette tâche à heure fixe, particulièrement lorsque le parc de machines est important, est difficile à envisager, car :
    • Le problème de saturation de la bande passante de la liaison Internet est largement amplifié, puisqu'à priori les postes de travail vont tous se mettre à jour à peu près au même moment.
    • La présence éventuelle d'un proxy avec authentification interdit totalement l'automatisation.
    • Le paramétrage sur les postes nomades (portables) peut poser des problèmes (par exemple, utilisation d'un proxy sur le lieu de travail mais pas à la maison).
    • Même dans le cas où on pourrait envisager d'automatiser la tâche AutoUpdate, il est presque impossible de le faire pour AutoUpgrade (mise à jour du moteur), car le processus est beaucoup plus lourd, nécessitant de fermer toutes les applications, et sous Windows NT de réaliser la mise à jour en tant qu'Administrateur du poste de travail.
  • Si l'on opte pour un démarrage manuel de la tâche par l'utilisateur, il est nécessaire de disposer d'un moyen de notification de la présence de mises à jour sur le site NAI.

Une meilleure solution serait donc de pouvoir procéder à une mise à jour depuis un serveur d'entreprise ayant téléchargé au préalable les nouvelles signatures. Les avantages sont multiples :

  • Economie de bande passante sur la liaison Internet, puisque le transfert depuis le site de l'éditeur n'est réalisé qu'une seule fois.
  • Possibilité de validation préalable de la mise à jour (vérification du bon fonctionnement des applications critiques de l'entreprise) par les administrateurs système avant la mise à disposition des nouvelles signatures.
  • Si la solution est correctement mise en oeuvre, elle permet aussi :
    • De procéder à un contrôle du bon déroulement de la session FTP avant la mise à disposition des fichiers transférés.
    • De mettre en place une notification par mail lorsque de nouvelles mises à jour sont disponibles.
    • Dans le cas où une mise à jour automatique sur les postes de travail est envisagée, de pouvoir déterminer facilement à quel moment il est opportun de la programmer.

2. Solution retenue

La solution décrite ci-dessous est basée sur l'outil gratuit mirror.pl (auteur : Lee McLoughlin, disponible sur ftp://src.doc.ic.ac.uk/computing/archiving/mirror), destiné à maintenir une arborescence commune avec un serveur FTP.

Les fonctions de base apportées par cet outil sont :

  • Une optimisation des transferts de fichiers (l'outil ne transfère que les fichiers modifiés depuis la dernière mise à jour).
  • Une validation du bon déroulement des transferts FTP (donc pas de fichiers tronqués installées sur le serveur miroir).
  • Un mécanisme de notification par mail à deux niveaux :
    • Niveau administrateur, pour fournir un rapport sur le déroulement d'une session de « mirroring ».
    • Niveau utilisateur, pour indiquer la présence de fichiers modifiés ou nouvellement créés.

Pré-requis pour la mise en oeuvre de cette solution : serveur FTP Intranet UNIX avec Perl et accès Internet.

3. Mise en oeuvre

Côté serveur FTP, installation et paramétrage de mirror.pl. L'outil sera lancé en cron au moins une fois par jour à heure fixe.

Dans cet exemple, deux packages distincts sont définis : DAT (base de signatures) et Engine (moteur). Comme nous l'avons expliqué plus haut, la mise à jour des signatures peut être réalisée simplement depuis une session utilisateur standard, alors que la mise à jour du moteur nécessite de fermer toutes les applications et, sous Windows NT, de se connecter sous le compte Administrateur de la machine. La liste de destinataires notifiés en cas de mise à jour est donc différente en fonction du package (utilisateurs pouvant ou non administrer leur poste de travail).

Paramétrage de mirror :

package=defaults
        # The LOCAL hostname - if not the same as `hostname`
        hostname=ftp.edelweb.fr
        # Keep all local_dirs relative to here
        local_dir=/usr/local/ftp/VirusScan/
        remote_password=ftp@edelweb.fr
        # Don't mirror file modes.  Set all dirs/files to these
        dir_mode=0755
        file_mode=0644
        # By defaults files are owned by root.zero
#       user=0
#       group=10
        # Keep a log file in each updated directory
#       update_log=.mirror
        update_log=
        # Don't overwrite my mirror log with the remote one.
        # Don't pull back any of their mirror temporary files.
        # Don't touch anything whose name begins with a space!
        # nor any FSP or gopher files...      
exclude_patt=(^|/)(\.mirror$|core$|\.cap|\.in\..*\.$|MIRROR.LOG|#.*#|\.FSP|\.cache|\.zipped|\.notar|\.message|lost+found/|\ )
        # Try to compress everything
#       compress_patt=.
#       compress_prog=compress
        # Don't compress information files, files that don't benifit from
        # being compressed, files that tell ftpd, gopher, wais... to do things,
        # the sources for compression programs...
        # (Note this is the only regexp that is case insensitive.)
        # z matches compress/pack/gzip, gz for gzip. (built into perl)
        # taz/tgz is compressed or gzipped tar files
        # arc, arj, lzh, zip and zoo are pc and/or amiga archives.
        # sea are mac archives.
        # vms used -z instead of .z.  stupid vms.
        # shk is multimedia? used on apple2s.
#       compress_excl+|-z(\d+)?$|\.tgz|_tgz|\.tar\.Z|\.tar\.gz|\.taz$|\.arc$|\.zip$|\.lzh$|\.zoo$|\.exe$|\.lha$|\.zom$|\.jpg$|\.jpeg$|\.jpg$|\.mpeg$|\.au$|\.shk$|read.*me|index|info|faq|gzip|compress|(^|/)\.\.?$
        # Don't delete own mirror log, .notar or .cache files (incl in subdirs)
        delete_excl=(^|/)\.(mirror|notar|cache)$
        # Ignore any local readme and .mirror files
        local_ignore=README.doc.ic|(^|/)\.(mirror|notar)$
        # Automatically delete local copies of files that the
        # remote site has zapped
        do_deletes=false
        max_delete_files=50%
        max_delete_dirs=50%
package=DAT
        site=ftp.nai.com
        remote_dir=/pub/antivirus/datfiles/4.x
        local_dir+datfiles/4.x
        mail_to=people@edelweb.fr
        do_deletes=true
package=Engine
        site=ftp.nai.com
        remote_dir=/pub/antivirus/engine/4.x
        local_dir+engine/4.x
        mail_to=power-users@edelweb.fr
        do_deletes=true

Côté postes clients, le paramétrage de VirusScan est très simple, voir l'exemple ci-dessous.


Copie d'écran 3 : paramètres de mise à jour par FTP depuis le site miroir

Notez que l'option Utiliser une connexion FTP anonyme n'est pas cochée : le bouton Informations permet de saisir le nom d'utilisateur et le mot de passe utilisé pour accéder au serveur FTP miroir.

Exemple de notification reçue par mail après une mise à jour :

Date: Thu, 21 Jun 2001 06:09:56 +0200 (MET DST)
From: VirusScan mirror update 
To: people@EdelWeb.fr
Subject: mirror update
 
Mirrored DAT (ftp.nai.com:/pub/antivirus/datfiles/4.x -> 
/usr/local/ftp/VirusScan/datfiles/4.x)  @ Thu Jun 21 06:09:54 MET DST 
2001
Got sdat4144.exe 4881698
Got 41434144.upd 129500
Got dat-4144.tar 2283520
Got dat-4144.zip 1957734
Got delta.ini 1279
Got readme.txt 52754
Got update.ini 553
Got SuperDAT.log 6315
unlink /usr/local/ftp/VirusScan/datfiles/4.x/dat-4143.zip
unlink /usr/local/ftp/VirusScan/datfiles/4.x/dat-4143.tar
unlink /usr/local/ftp/VirusScan/datfiles/4.x/sdat4143.exe
unlink /usr/local/ftp/VirusScan/datfiles/4.x/41284129.upd

4. Problèmes de sécurité posés par les mises à jour automatisées

Toujours dans le cas particulier de VirusScan, mais il est probable que cela soit aussi le cas avec d'autres produits du marché, nos experts sécurité Windows ont noté un certain nombre de failles potentielles introduites dans le système par la procédure de mise à jour.

Par exemple, lors de l'installation, il est demandé si la console d'administration doit être accessible ou non aux utilisateurs ne disposant pas des droits Administrateur. Si la console est accessible, les utilisateurs ont la possibilité de modifier facilement les paramètres de mise à jour. Même dans le cas contraire (option d'installation « Sécurité Maximale »), il est toujours possible de modifier les entrées de la base de registres correspondant à VirusScan (droits d'accès trop permissifs).

Autre problème, la fonction AutoUpgrade se lance avec les droits Administrateur lorsqu'elle est programmée comme tâche automatisée. Il est possible, en créant adroitement certains fichiers sur le poste de travail, d'utiliser cette procédure pour exécuter localement un programme de son choix avec les droits SYSTEM.

D'autre part, aucun mécanisme de certification des fichiers transférés pour la mise à jour n'étant mis en oeuvre, une attaque sur le serveur DNS d'une entreprise pourrait permettre de détourner le trafic à destination du site Internet de NAI afin de faire télécharger un programme hostile en lieu et place de la mise à jour par tous les postes de travail de l'entreprise.

Dans un prochain article :

  • Nous exposerons ces risques de façon détaillée, avec scénarios d'attaque à l'appui.
  • Nous tenterons de donner des solutions permettant aux administrateurs de limiter ces risques, par exemple les modifications à effectuer sur les droits d'accès à la base de registres.
  • Nous évaluerons l'impact de ces restrictions du point de vue de l'utilisateur.

Titre Mise à jour automatique de signatures anti-virus
Date 25/06/2001
Version 1.0
Auteur Jean-Christophe TOUVET jct@edelweb.fr

© Copyright EdelWeb 2001 all rights reserved

webmaster@edelweb.fr  Copyright EdelWeb (C) 1995, 1998