PI Services

Problématique

Si il vous arrive d’oublier votre mot de passe utilisé pour l’accès à la console Symantec Endpoint Manager, il peut être bien pratique de rétablir les identifiants par défaut.

De plus, l’accès à la console SEP Manager est sécurisé par un système qui bloque pour une durée de temps variable l’authentification dès que plusieurs authentifications ont échouées.

Procédure

• Tout d’abords vérifier que les services utilisé par SEP sont bien lancé, si ce n’est pas le cas, les démarrer puis retenter l’authentification,
• Ouvrir un explorateur de fichier,
• Se placer dans C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tools
• Exécuter en tant qu’administrateur le script Resetpass.bat
• Les identifiants ont étés remis par défaut soit : admin/admin
• Le log scm-server-0.log situé dans C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tomcat\Logs enregistre tout les évènements d’échec d’authentification, pratique pour troobleshooter un problème. 

Problème rencontré :

Dans le cadre d’une implémentation de SEP dans une entreprise, beaucoup de services informatiques ont la volonté d’intégrer le client SEP dans le “Master”. Pour intégrer le produit, l’idée première serait de créer un package d’installation avec la console SEPM et de lier le client SEP directement a la console. Ce package serait déployé sur le poste de référence et donc présent au sein du "master".

Cette idée d’optimisation serait idéale si le client SEP ne possédait pas un “SID” unique créé lors de l’intégration du client à l’architecture SEP. L’effet créé est que un seul poste remonte dans la console (même si le master contenant l'installation de SEP est déployé sur des centraines de postes), et change de nom, d’IP, … à chaque démarrage d’une machine issue de la même intégration.

Exemple, dans l’ajout d’un poste (PosteB) avec le même client SEP d’installé, la communication avec le serveur SEPM ne fait pas s’ajouter un client supplémentaire dans la console, mais change les “informations” d’un autre poste (PosteA)

Solution apportée :

Pour optimiser le déploiement, il est possible de pré-installer le client SEP dans un “Master”. Le client doit être impérativement installé en mode “Non-géré”. A la fin d’un déploiement, il suffit de “lier” le client SEP a la console de gestion grâce a l’outil “Sylinkdrop.exe” et d’un fichier de liaison “Sylink.xml”.

Symantec recommande d’installer l’antivirus après la “masterisation” du poste. Cela évite d’avoir à refaire les “Masters” à chaque évolution (MRx) du produit.

Si des masters ont déjà été créé, voici un lien de Symantec qui explique les modifications à apporter au client SEP installé:

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/d84071c5137d6d318825738a00663b8d?OpenDocument

NOTE: La clé de registre HKLM \ SOFTWARE \ Symantec \ Symantec Endpoint Protection \ SMC \ SYLINK \ SyLink \ SySoftk peut également être supprimée si elle est présente.
Une fois l'image “Ghost” appliquée sur un nouveau système, le client va générer une valeur d'identification unique, se connecter avec son SEPM et s’enregistrer.  Lors de l'inscription sur le le serveur de gestion,  SEPM va enregistrer toutes les informations clientes nécessaires dans la base de données.

Problème rencontré

Certains postes peuvent rester indéfiniment avec la notification « besoin d’un redémarrage pour le Network Threat Protection » alors qu’ils ont déjà été redémarrés plusieurs fois depuis l’installation du client SEP et alors même que le composant Network Threat Protection (NTP) n’est pas installé.

Solution apportée

L’origine de cette panne est la DLL Teffer2.sys. Cette DLL n’arrive pas ou plus à se charger. Le problème est que cette DLL n’est utilisée que pour le composant NTP.

Cf. la Kb de Symantec :

• http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1d710556d47fe468882575ef00652769?OpenDocument

Une réparation de l’installation ou une réinstallation du produit ne suffisent pas pour régler ce problème.

La solution est d’installer le composant NTP de SEP pour que le système enregistre la DLL, puis de re-désinstaller proprement le composant pour que Windows dé-valide le besoin de redémarrage et de chargement de cette DLL.

Rappel sur LUA et PostGreSQL

Dans le cadre d’un projet d’intégration de SEP, j’ai installé un serveur LiveUpdate en interne. LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet (c'est l'équivalent d'un serveur WSUS chez Microsoft).

Dans la suite de ce billet, Live Update désigne le service de mise à jour et Live Update Administrateur (LUA) désigne le serveur interne de distribution des mises à jour.

Le client Live Update utilise une technologie PULL pour se connecter en HTTP et en FTP. Par défaut le client Live Update est configuré pour pointer vers les serveurs publics de Symantec. Il est possible de modifier ce comportement de manière à ce qu'il se connecte au serveur LUA interne en lieu et place des serveurs publics.

Le serveur LiveUpdate Administrateur utilise le moteur de base de données PostgreSQL . La version de PostgreSQL fournie avec LUA 2.x est la version 8.1(cf. site officiel PostGreSQL).

Remarque : Le support technique de Symantec recommande fortement à ses clients l'application de toutes les mises à jour du serveur LUA de manière à bénéficier de toutes les améliorations disponibles (notamment des améliorations apportées par la version 8.1 de PostGreSQL).

Le moteur PostGreSQL est configurable via le fichier « postgresql.conf » situé a la racine du dossier d’installation de LiveUpdate Administrator.

Tuning des performances PostGreSQL

Voici les principaux paramètres ayant une grande influence sur les performances de la base ainsi que les valeurs recommandées :

1. shared_buffers

Le paramètre shared_buffers détermine la quantité de mémoire utilisée pour la mise en cache des données. Certaines sources recommandent une valeur correspondant à 25% de la mémoire vive du serveur.

Par défaut la valeur du paramètre shared_buffers est de 32Mo avec LUA 2.2. Une valeur de 512 Mo permet d'améliorer les performances. Certains gros clients ont augmenté cette valeur jusqu'à 1024 Mo et on ensuite pû observer de grandes améliorations.

2. temp_buffers

Le paramètre temp_buffers n'est utilisé que pour le maintient des tables temporaires en mémoire.

Comme LUA 2.x ne dépend pas fortement de ces tableaux, certains clients ont réduit cette valeur de 2 Mo dans le cadre de leur mise au point.

3. work_mem

work_mem fixe la quantité maximale de mémoire à utiliser pour l’exécution d’une requête.

Le réglage de work_mem à 256 Mo a conduit à une amélioration des performances pour certains clients.

4. max_fsm_pages

Cette valeur doit être réglée sur le nombre maximum de pages de données (affichage Web) que vous voulez modifier ou supprimer. Une valeur de 20 000 a bien fonctionné pour certains clients.

5. wal_buffers

Une valeur de 256Kb devrait être suffisamment grande. pour une bonne utilisation de LUA.

6. checkpoint_segments

Les valeurs recommandées vont de 16 à 128 en fonction de l’espace disque disponible.

Par défaut, la valeur est de 3. Certains gros clients ont augmenté cette valeur à 30 et vu de grandes améliorations.

7. effective_cache_size

Effective_cache_size définit la taille du cache disque par rapport à la quantité de mémoire RAM disponible pour la mise en cache des données,

Il est recommandé de configurer la valeur effective_cache_size à 50% de la RAM du système (cette préconisation est valide si et seulement si le serveur est dédié au rôle LUA).

Par défaut, LUA 2.2 a effective_cache_size a une valeur de 128Mo. Certains gros clients ont augmenté cette valeur jusqu'à 2048 Mo et vu de grandes améliorations.

SEP, Symantec Endpoint Protection est le dernier antivirus de Symantec. Chaque évolution de SEP est nommée MR (Major Release). Symantec corrige et améliore la solution SEP à chaque release. Il est donc important de toujours maintenir à jour la solution avec le dernier correctif.

Aujourd’hui, nous sommes à la version SEP MR6

Chaque MR apporte trois évolutions :

• Evolution du SEPM (cf post sur l’architecture SEP)
• Evolution de la base SEP (SQL ou Sybase)
• Evolution des clients

Ces évolutions ne sont ni une mise a jour du moteur antivirus, ni une mise à jours de la base virale du client SEP.Chaque montée de version fait donc l’objet d’un « upgrade » de l’architecture SEP.

Il existe plusieurs méthodologies pour faire cette montée de version. Voici celle que j’estime être la plus sure, et la plus rapide.

Les pré-requis sont :

• Un serveur de « spare »
• La nouvelle version (les sources, CD1)
• Du temps :-) (cette migration peut se faire sur deux à trois jours)

1) Rappel d’une architecture SEP (cf : Lien Solution SEP )

Une architecture SEP est constituée des composants suivants :

• SEPM (manager)
• Clients SEP (postes et serveurs client)
• GUP (client SEP, serveur ou poste de travail, relais pour la mise à disposition des mises à jour)
• Base de données (une par défaut, SQL ou Sybase) SEP

2) Montage d’un serveur de relais pour la migration

Un second serveur de relais sert à ne pas impacter les utilisateurs lors de la migration du serveur SEPM (montée de version du SEPM et de la base de données).

Donc, la première des actions est de monter un second serveur avec une seconde base (même version que le premier).

3) Synchroniser les deux serveurs

Le but de la synchronisation est de s’assurer que les deux bases aient le même niveau d’information.

• Politique
• Client
• Package de déploiement
• …

4) Faire basculer les postes clients sur le second serveur

Cette bascule s’effectue via la configuration de la liste de serveur SEPM.

Il faut créer une liste (via la copie de la liste par défaut est un bon moyen).

Créer une nouvelle priorité de serveur, et ajouter le second serveur à la liste.

Attention, il faut bien vérifier que le nouveau serveur est en priorité1

5) Casser la synchronisation

Lors de la migration d’un serveur SEPM, la base est migrée. Si la synchronisation est active, elle risque de casser les tables de la seconde base.

6) Migrer le premier serveur

Lancer simplement le setup. Exe du CD 1 dans le dossier SEPM

7) Vérifier le bon fonctionnement du SEPM, de la base

Redémarrer le serveur et la base.

Vérifier que les informations de la base sont accessibles via la console de gestion SEP…

8) Basculer un lot de postes clients SEP et vérifier le bon fonctionnement de ceux-ci

Tester que le client est bien connecté au serveur SEPM

Le bouclier informe de l’état de la solution SEP client et informe du lien avec le SEPM (pastille et couleur).

• Vert OK
• Jaune lié mais léger problème SEP ou définitions non a jour
• Rouge antivirus désactivé ou non fonctionnel
• -Non présent SEP en mode « Autonome – Hors Ligne »

9) Basculer le reste des clients

Les clients doivent être rebasculés dans l’intégralité avant de passer à l’étape d’après.

10) Couper le serveur relais

Le serveur relais n’a pas besoin d’être migré.

La solution SEP est la dernière solution antivirale avancée de Symantec. Elle regroupe plusieurs fonctionnalités.

• Protection antivirale
• Protection réseau
• Contrôle des périphériques
• Protection contre les intrusions
• Protection contre les « malwares »

Le client (agent SEP), la console (SEPM) de gestion et une base de données (Sybase, SQL), le moteur de mise à jour (LiveUpdate LU) sont les composants principaux.

1) LiveUpdate - LU

LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet. Il utilise une technologie PULL pour se connecter en http, puis (et/ou) ftp. En combinaison avec un serveur LiveUpdate Administrateur il est possible de modifier son comportement pour qu’il utilise un site interne au réseau d’entreprise pour ses connexions.

 2) Serveur SEPM

La gestion centralisée de la solution Symantec Endpoint Protection (SEP) se fait par l’intermédiaire d’un serveur SEP Manager (SEPM). Ce serveur s’appuie sur une base de données pour stocker toutes les informations générées par les activités de la solution configurations, politiques, logs, packages d’installation, mises à jour logicielles ou de signatures, etc. Ce serveur est géré par une console qui peut être locale ou déportée.

3) Console SEPM locale ou déportée

Cette console, écrite en JAVA, se connecte à un serveur SEPM, soit localement, ou à distance. Son installation est automatique pendant l’installation du serveur SEPM, mais par une simple connexion au site SEPM il est possible de l’installer à distance sur un ou plusieurs poste(s) administrateur.

4) Group Update Provider (GUP) - optionnel

Le Group Update Provider, ou GUP (en français : Fournisseur de Mise à jour Groupée), est un PC ou un serveur sur un site, qui a été identifié par la console comme un « proxy » pour la mise à disposition des mises à jour de signatures. Il utilise un protocole http(s) modifié, et donc simule un serveur.