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 :
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 :
-
Cliquer sur Version dans l'onglet Administration
-
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.
En configurant le service DNS de Windows Server 2008 R2, j’ai détecté une anomalie assez étonnante : les adresses IP des serveurs DNS racines B.root-servers.net et L.root-servers.net sont erronées dans la configuration du DNS de Windows Server 2008 R2 !
En effet, on nous indique les adresses IP suivantes :
-
Pour le serveur B.root-servers.net :
128.9.0.107 dans la configuration du service DNS Windows Server contre 192.228.79.201 sur le site
http://www.root-servers.org/
-
Pour le serveur L.root-servers.net :
198.32.64.12 dans la configuration du service DNS Windows Server contre 199.7.83.42 sur le site
http://www.root-servers.org/
En ce qui concerne le serveur « L » appartenant à l’ICANN, on peut retrouver sur leur site un billet indiquant à tous les opérateurs de services DNS de mettre à jour l’adresse IP avant la date de la bascule prévue le 1er novembre 2007…
La liste des nouvelles adresses IP est aussi consultables sur le site de l’Internic (ftp://rs.internic.net/domain/named.root).
La liste des « root hints » de Windows Server 2008, Windows Server 2003 R2 et des versions précédentes semble également touchée.
Symptôme
Lors de l'installation d'Exchange 2010 sous Windows Server 2008 R2 ou Windows Server 2008 x64 SP2, le message d'erreur suivant peut apparaître :
De plus l'évènement suivant est enregistré dans le journal "Application" du serveur :
Event ID : 1002
Source : MSExchangeSetup
Task Category : Microsoft Exchange Setup
Level : Error
Error : The following error was generated when "$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }" was run: "Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.".
Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.
Explication
Cette erreur indique que le service de transport Hub s'est bien installé mais qu'il n'arrive pas à démarrer.
Cette erreur apparaît lorsque le service IPv6 est désactivé au niveau de la carte réseau mais pas au niveau du système.
Résolution :
Pour résoudre le problème deux options sont envisageables :
Cette clé doit être créée avec les paramètres suivants :
-
Ruche : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
-
Type de clé : DWORD (32 bits)
-
Nom de la clé : DisabledComponents
-
Valeur de la clé : 0xffffffff hex (4294967295)
Suite à cela les services de transport Hub d'Exchange 2010 acceptent de démarrer. Cette solution est tirée de l'article 952842 de la base de connaissance Microsoft (cette KB n'est pour le moment validée que pour Exchange Server 2007).
http://support.microsoft.com/kb/952842/en-us
Microsoft a mis en ligne (il y a déjà quelques temps), un site Web recensant les applications Microsoft supportées en environnement virtuel (Hyper-V, Xen ou même VmWare ESX)
Le site peut s’avérer fort utile. Il est accessible ici.
Microsoft vient de publier de nouveau agent pour les systèmes d’exploitations Unix/Linux.
Ces agents ajoutent le support de Suse Entreprise 11, Solaris Zone et corrigent un problème de charge CPU.
Attention: cette mise à jour est relativement conséquente puisqu’elle pèse tout de même 250Mo!
Le téléchargement se fait ici.
Une nouvelle version du fichier Excel d’aide au dimensionnement de “System Center Operation Manager” (compatible avec SCOM 2007 R2) est sorti.
Le fichier est en version 1.1 et nécessite l’utilisation des macros pour fonctionner.
Le téléchargement se fait ici.