PI Services

La problématique

Lors de l’installation de Symantec Mail Security for Exchange 6.5 sur un serveur Exchange 2010, l’erreur suivante se produit :

Failed to enable ASP.NET web extensions. Installation will not continue.

L’explication

A l’heure actuelle Symantec Mail Security utilise encore des fonctionnalités héritées de IIS 6 (l’installeur à notamment besoin du script iisext.vbs).

Par défaut les composants de rétrocompatibilité IIS 6 suivants sont installés sur un serveur Exchange 2010 exécutant le rôle Hub, Mailbox, Cas ou Unified Messaging (seul le rôle Edge n’est pas concerné car il n’utilise pas IIS) :

• IIS 6 Metabase Compatibility
• IIS 6 Management Console

Cela n’est pas suffisant pour SMS qui nécessite également le composant IIS 6 Scripting Tools.

La Solution

La solution consiste tout simplement à installer les composants IIS 6 Scripting Tools et IIS 6 WMI Compatibility (le premier étant dépendant du second, les deux doivent être installés).

Cette opération peut être effectuée graphiquement via la console MMC Server Manager ou bien en console Powershell via la commande Add-WindowsFeature.

Pour plus d’informations sur les pré-requis nécessaires à Exchange 2010, vous pouvez consulter le lien suivant :

http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

Cette solution est tirée de la note technique suivante, pour l’instant uniquement validée avec SMS 6.0 :

http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2008081210523154

Durant les phases de POC ou de pilote il peut s'avérer intéressant de générer des messages reconnus comme étant des SPAM par Brightmail.

Cela permet notamment de valider le bon fonctionnement des règles antispam et/ou des règles de conformité positionnées dans l'environnement du client.

Pour cela il est tout à fait possible d'envoyer un email contenant dans l'objet ou dans le corps du message quelques mots ou expressions savamment choisies.

Il est également possible d'utiliser un en-tête SMTP prévu à cet effet dans le moteur antispam des Appliances SBG !

L'astuce consiste à ajouter l'expression X-Advertisement:spam lorsque vous envoyez un email de test sur une invite de commande en telnet (NB : Cette expression doit être saisie après la commande DATA).

Dans l'exemple ci-dessus, l'email est bel et bien reconnu comme SPAM et l'action prise consiste à modifier l'objet du message, puis à envoyer le message dans la quarantaine.

Ce tips est tiré de la note technique suivante :

Testing mail flow and spam detection in Symantec Brightmail products and Symantec Mail Security appliances.

Introduction

Les boitiers Symantec Brightmail Gateway (anciennement SMS 8300) sont des Appliances antispam et antivirus commercialisées par Symantec. Ces Appliances sont également capables d'appliquer des règles de conformité voir de s'intégrer à des solutions DLP.

On distingue plusieurs types de mises à jour sur les boitiers SBG :

• Les mises à jour des définitions antispam sont appliquées automatiquement par le service Conduit (les mises à jour ont lieu toutes les 10 minutes environ)
• Les mises à jour des définitions antivirus sont appliquées automatiquement par le service LiveUpdate en fonction de la planification définie par l'administrateur
• Les mises à jour du logiciel (software) qui sont appliquées manuellement à l'initiative de l'administrateur

C'est bien entendu la troisième catégorie qui nous intéresse ici ! Symantec ne fournit par de roadmap publique précise en ce qui concerne les mises à jour du logiciel. Néanmoins on peut considérer que des mises à jour mineures sont disponibles de manière trimestrielle et que des mises à jour majeures sont effectuées tous les 1 à 2 ans.

A titre informatif, voici la liste des mises à jour du software de ces deux dernières années en ordre chronologique :

• Août 2007 - 7.5
• Mars 2008 - 7.6.1-7
• Août 2008 - 7.6.1-14
• Septembre 2008 - 7.7.0-17
• Janvier 2009 - 8.0.0-24
• Mars 2009 - 8.0.1
• Mai 2009 - 8.0.2
• Octobre 2009 - 8.0.3  

Pour être averti instantanément lors de la disponibilité d'une nouvelle version du logiciel, le plus simple reste d'utiliser les alertes par emails intégrées au sein du produit (cf. capture d'écran ci-dessous).

Les Best Practices

Voici les best practices en ce qui concerne les mises à jour du logiciel d'une Appliance Symantec Brightmail Gateway :

• Effectuer une sauvegarde de la configuration du "control center"
• Vérifier que le "control center" n'est pas en train d'effectuer une synchronisation avec un serveur d'annuaire
• Vérifier que les "scanner" ne sont pas en train d'effectuer une réplication des données LDAP à partir du "control center"
• Configurer la pile MTA des boitiers "scanner" sur "Do not accept incoming messages"
• Mettre à jour les boitiers "scanner" avec le "control center"

Procédure

Pour lancer la mise à jour d'une Appliance via l'interface Web, il faut suivre la procédure suivante :

1. Cliquer sur Version dans l'onglet Administration
2. Aller dans l'onglet Updates

Il faut ensuite sélectionner la mise à jour, afficher la description (les "release notes"), puis cliquer sur le bouton Update.

L'interface Web affiche ensuite la barre de progression ci-dessous :

Aucune précision supplémentaire n'est ensuite affichée dans l'interface Web. Pour suivre de manière plus précise les différentes étapes de l'installation (téléchargement des différents modules, installation...), il faut se connecter en SSH sur l'Appliance avec un client tel que putty et utiliser la commande watch update.log (cf. capture d'écran ci-dessous).

A l'issue de l'installation, il est possible de vérifier la version installée sur le boitier à l'aide de la commande version.

Le contexte :

A l'instar de son prédécesseur, Forefront Threat Management Gateway 2010 (TMG) intègre un assistant de publication pour Exchange 2007.

Cet assistant permet de publier les divers services Web intégrés à Exchange 2007 :

• Le Webmail Outlook Web Access
• Le push mail ActiveSync
• Le mode Outlook Anywhere (RPC over HTTP)
• Les services Web Outlook 2007 (OAB Web, Autodiscover...)

Cet assistant génère des règles "sécurisées" dans le sens où seuls les répertoires virtuels associés à ces services Web sont publiés (/OWA, /EWS, /Autodiscover...). Il vous est aussi possible de paramétrer une authentification au niveau du périmètre à l'aide du port d'écoute Web.

Il est possible d'augmenter encore plus le niveau de sécurité de la publication en utilisant le filtre HTTP intégré à ISA/ TMG. Cette fonctionnalité, méconnue ou du moins très peu mise en valeur au sein d'ISA/TMG, permet d'effectuer un filtrage plus fin sur les requêtes HTTP.

Fonctionnement du filtre HTTP

Le filtre HTTP permet d'agir à différents niveaux :

• Limitation de la longueur des URL, des en-têtes et du corps des requêtes HTTP
• Blocage de certaines méthodes HTTP / Webdav
• Blocage d'extensions de fichiers et de types MIME
• Blocage de certains en-têtes HTTP
• Modification à la volée de l'en-tête "Server" ou de l'en-tête "Via"
• Blocage de "signatures" (une signature correspond à une application cliente reconnue grâce au contenu de l'en-tête HTTP "User-Agent")
• Etc.

Le filtre HTTP se configure indépendamment au niveau de chaque règle d'accès ou de publication Web. Dans une règle de publication Web, il est possible de lancer l'interface de configuration via le bouton Filtering de l'onglet Traffic (cf. capture d'écran ci-dessous).

Sinon il est également possible d'effectuer un clic droit sur la règle, puis de cliquer sur Configure HTTP.

Règles de publication pour Exchange 2007

Les outils d'analyse des requêtes HTTP comme Fiddler ou HTTPWatch permettent de mettre en valeur les méthodes HTTP utilisées par chacun des services Web Exchange.

Ainsi le Webmail Outlook Web Access n'utilise que les méthodes GET et POST alors que le mode Outlook Anywhere d'Outlook 2003/2007 utilise les méthodes Webdav RPC_IN_DATA et RPC_OUT_DATA.

Pour autoriser de manière très fine les bonnes méthodes sur chacun des types d'accès Web, il suffit de créer plusieurs règles de publication Web.

Le tableau ci-dessous est un exemple dans lequel six règles sont définies (une règle par service Web). Pour chaque règle sont indiquées les méthodes HTTP et les répertoires virtuels à autoriser.

Remarque : La sécurisation de ces flux passant également par l'authentification des utilisateurs, il est également intéressant d'implémenter une authentification au niveau du serveur ISA / TMG avec une délégation des informations d'identification vers le serveur CAS.

Sauvegarde de la configuration

Attention, la configuration du filtre HTTP n'est pas sauvegardée lorsque l'on effectue un export ou une sauvegarde dans la console MMC !!!

Pour sauvegarder la configuration du filtre HTTP il faut utiliser le script HttpFilterConfig.vbs fournit dans le SDK du produit ! Ce script prend en paramètre l'action (backup ou restore) ainsi que le nom de la règle.

Cela signifie qu'il faudra exécuter le script six fois pour sauvegarder la configuration de six règles. Dans ces conditions la création d'un batch est appréciable ! (ce batch peut également sauvegarder le reste de la configuration à l'aide du script ImportExport.vbs lui aussi présent dans le SDK).

A titre informatif, les SDK d'ISA Server 2006 et de Forefront Threat Management Gateway 2010 Beta3 sont disponibles aux adresses suivantes :

• SDK ISA : http://www.microsoft.com/downloads/details.aspx?familyid=16682c4f-7645-4279-97e4-9a0c73c5162e&displaylang=en
• SDK TMG : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dff77975-84bf-484f-a3bd-9d8dd800e220#filelist

N'hésitez pas à laisser vos commentaires sur cette procédure !