Jump to content
Sign in to follow this  
LBVS

Best practices pour les multi vlan

Recommended Posts

Bonjour,

ce n'est pas vraiment un incident, mais je suis en recherche des bonnes pratiques que vous appliquez sur Kaspersky.

Je suis sur une solution KES 10 (la dernière mouture en 10.5) avec du KSC en 10.3.0.6294

Je rencontre régulièrement des problèmes sur une partie de mon parc de PC portables. En effet, le réseau filaire et le réseau wifi sont sur 2 vlan différents, donc 2 subnets ip

L'enregistrement DHCP et actualisation DNS étant ce qu'il est (càd moisi), je me retrouve avec des postes clients dans KES avec des informations érronées, et donc des postes qui sont vus comme hors-ligne par le serveur d'admin, et aussi par l'agent local sur le poste.

Ma question donc, comment procédez-vous sur vos infras pour éviter ce genre de problématiques, faites-vous des sondages de plages IP, cochez vous "maintenir la connexion au serveur d'administration..."

ou alors est-ce du paramétrage DHCP/DNS ?

 

Merci pour vos retours d'expérience !

Share this post


Link to post

Bonjour,

Il y a 17 heures, LBVS a dit :

Je suis sur une solution KES 10 (la dernière mouture en 10.5) avec du KSC en 10.3.0.6294

ce n'est pas tout à fait ça... ;)

Il y a 17 heures, LBVS a dit :

L'enregistrement DHCP et actualisation DNS étant ce qu'il est (càd moisi), je me retrouve avec des postes clients dans KES avec des informations érronées, et donc des postes qui sont vus comme hors-ligne par le serveur d'admin, et aussi par l'agent local sur le poste.

actualisation DNS ?

informations erronées ?

ton agent pointe vers une IP, un nom ou un FQDN ?

"Maintenir la connexion au serveur d'administration..." n'est utile que pour gérer un poste derrière un routeur hors contrôle

Share this post


Link to post

ah oui, l'inverse, KES, KSC... il me reste 4 jours avant la quille, c'est long :)

merci pour ton retour

En gros, je me retrouve avec quelques PC, qui suite à des déplacements entre différents sites, ou suite à des mises à jour du bail DHCP, se voient attribués une nouvelle ip. Du classique quoi. Sauf que le serveur d'administration n'est pas tout le temps actualisé avec les nouvelles informations IP.

Si je comprends bien le process, c'est l'agent sur les postes qui envoie les nouvelles infos, mais je me retrouve parfois (je précise bien que ce n'est pas systématique) avec l'agent qui ne se connecte plus au serveur d'administration durant des jours voir des semaines (vérifié via l'utilitaire klcsngtgui.exe)

Les agents sont paramétrés pour se connecter au serveur d'administration via son nom FQDN

 

Share this post


Link to post

ton agent se synchronise par défaut toutes les 15 minutes... et doit naturellement remonter la nouvelle IP si y a

ton fqdn est résolvable de n'importe où ? et ton serveur est accessible à travers chaque vlan ?

Share this post


Link to post

oui, les vlan "clients" sont full routés, tout est en domaine.

Autre phénomène plus ou moins lié, sur certains postes je uis obligé de redémarrer manuellement l'agent ('C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\klnagchk.exe'-restart) car même à la suite d'un reboot du pc, la connectivité ne remonte pas. Je me retrouve donc avec des postes qui remontent en 'agent installé : non' alors que en fait, oui !

Share this post


Link to post

Désactive ton scan du réseau / domaine (qui ne permettent pas de savoir s'il y a agent et/ou KES d'installé)

Tu n'aurais pas des doublons ?

Plusieurs profils de stratégie ?

Share this post


Link to post

Donc tu préconises de ne faire qu'un sondage active directory?

Il n'y a pas de doublons, parfois sur les serveurs lorsque je fais des montées de version de KES, mais c'est rare

et j'ai une stratégie par version de KES (SP1, SP2, mr1 ...), surtout pour les serveurs.

J'ai une seule stratégie pour l'ensemble des postes "ordinateurs"

Share this post


Link to post
Il y a 2 heures, LBVS a dit :

Donc tu préconises de ne faire qu'un sondage active directory?

aucun sondage pardon...

essaye comme ça , regarde s'il y a du mieux

tu peux également regarder dans les logs d'un des postes ayant le souci

que donne klnagchk.exe lorsque le poste ne remonte pas ?

Share this post


Link to post

ok donc aucune découverte, et on laisse les règles de tri faire remonter les postes ?

j'ai trouvé une machine (serveur 2012R2) qui est vue en déconnecté, le klnagchk.exe est OK partout, mais ...

" Date/heure de la dernière requête de synchronisation:30/01/2018 04:06:54 GMT"

Dans la console il est vu en déconnecté depuis le 30/01 donc, mais la protection reste active

si j'envoie le paquet pouls, la reconnexion se fait automatiquement. Ce que je ne comprends pas, c'est pourquoi ça ne se fait pas suite à un reboot du serveur ?

Share this post


Link to post
il y a 39 minutes, LBVS a dit :

si j'envoie le paquet pouls, la reconnexion se fait automatiquement. Ce que je ne comprends pas, c'est pourquoi ça ne se fait pas suite à un reboot du serveur ?

Bonjour,

Le service de l'Agent d'administration est en démarrage différé, c'est la raison.

Cordialement.

Share this post


Link to post
Il y a 1 heure, LBVS a dit :

j'ai trouvé une machine (serveur 2012R2) qui est vue en déconnecté, le klnagchk.exe est OK partout, mais ...

" Date/heure de la dernière requête de synchronisation:30/01/2018 04:06:54 GMT"

Dans la console il est vu en déconnecté depuis le 30/01 donc, mais la protection reste active

ce qui parait normal si l'agent n'arrive pas à se synchroniser. As-tu regardé dans les logs comme indiqué précédemment ?

donne nous le retour du klnagchk.exe stp

Share this post


Link to post
Citation

Lancement de l'utilitaire 'klnagchk'...
Vérification des paramètre de ligne de commande...OK
Initialisation des bibliothèques de base...OK
Appareil actuel 'DOMAIN\SRNWL05'
Version de l'Agent d'administration '10.4.343 (SF1)'


Lecture de la configuration...OK
Vérification de paramètres...OK
Paramètres de l'Agent d'administration:
  Adresse du Serveur d'administration: 'INVSRWS03.domaine.priv'
  Utiliser une connexion SSL: 1
  Compresser le trafic: 1
  Numéros de ports SSL du Serveur d'administration: '13000'
  Numéros de ports du Serveur d'administration: '14000'
  Utiliser un serveur proxy: 0
  Certificat du Serveur d'administration: disponible
  Découvrir port UDP: 1
  Numéros de ports UDP: '15000'

  Période de synchronisation (min.): 15
  Temporisation de connexion (sec.): 30
  Temporisation d'envoi/réception, sec.: 180
  Identificateur de l'appareil: 460d4933-5a47-464e-aa6a-d5ae863ce627


Tentative de connexion au Serveur d'administration...OK

Tentative de connexion à l'Agent d'administration...OK
L'Agent d'administration est en cours d'exécution
Réception des statistiques de l'Agent d'administration...OK
  Données statistiques de l'Agent d'administration:
  Nombre total de requêtes de synchronisation: 4771
  Nombre de requêtes de synchronisation réussies: 4769
  Nombre total de synchronisations: 1
  Nombre de synchronisations réussies: 1
  Date/heure de la dernière requête de synchronisation:05/01/2018 02:37:12 GMT (
05/01/2018 03:37:12)


Annulation de l'initialisation des bibliothèques de base...OK
Appuyez sur une touche pour continuer...

voici un serveur non connecté depuis le 5 janvier

Il y a un journal d'événements nommé 'Kaspersky Event log' et j'ai ce message qui revient plusieurs fois par jour :

Citation

Impossible d'obtenir les mises à jour : impossible de se connecter au serveur, motif : '1270'.

et aussi ça :

Citation

EventsProcessorProxy: #1270 Une erreur s'est produite au niveau du transport lors de la connexion à http://INVSRWS03.domaine.priv:13000 : errreur SSL; un port autre qu'un port SSL est certainement utilisé.

Par contre ce poste continue d'envoyer ses infos au serveur d'administration :

Citation

Envoi au Serveur d'administration d'informations relatives à la durée de la dernière analyse achevée.

 

 

 

Par contre j'ai réactivé le sondage Active Directory, sinon comment les nouveaux postes peuvent remonter dans la console?

Share this post


Link to post

Tes agents sont en 10.4.343 SF1 alors que ton KSC est en 10.5 !!!!

Je te conseille très vivement de déployer le patch a de l'agent 10.4.343 ! il y a même le patch b qui inclut le patch a et sf1 depuis le quelques jours.... : https://support.kaspersky.com/fr/14530 Soit tu approuves le patch via la section "Mises à jour du logiciel" dans KSC soit via une tâche d'installation

sinon déploie l'agent 10.5.... ;)

Share this post


Link to post

Il est fortement conseillé d'installer l'agent en version 10.5.1781 si le KSC est en 10.5.1781

Cordialement.

Share this post


Link to post

Merci pour le conseil, je lance une tâche d'install sur le parc

mais ça ne répond pas à la problématique, je n'ai installé la 10.5 qu'il y a 2 semaines, et là j'ai un serveur qui ne se connecte pas depuis Janvier.

Share this post


Link to post
il y a 13 minutes, LBVS a dit :

ça ne répond pas à la problématique, je n'ai installé la 10.5 qu'il y a 2 semaines, et là j'ai un serveur qui ne se connecte pas depuis Janvier.

lit ce que corrige le patch a (fin 2017)...

et depuis janvier ça ne t'as pas inquiété ??? surtout avec un serveur...

Edited by Tchup

Share this post


Link to post
Citation

 

Erreur à cause de laquelle l'Agent d’administration ne réalisait pas la synchronisation complète et l'échange d'informations (impulsion) avec le Serveur d’administration, si le système d'exploitation local n’avait pas été redémarré depuis plus de 49 jours.

 

oh, 49 jours, si peu :D

on a un mal fou à faire comprendre aux services l'importance de pouvoir redémarrer les infras logicielles, bon bah ça va ajouter de l'eau au moulin.

et oui je zappe quelques serveurs, j'en ai 500 à gérer, je suis plus ou moins le seul qui "maitrise" Kaspersky dans l'équipe, et j'ai un périmètre assez large, donc non je ne m'inquiète pas trop

Share this post


Link to post
il y a 20 minutes, LBVS a dit :

et oui je zappe quelques serveurs, j'en ai 500 à gérer, je suis plus ou moins le seul qui "maitrise" Kaspersky dans l'équipe, et j'ai un périmètre assez large, donc non je ne m'inquiète pas trop

lol

bon courage alors ;)

Share this post


Link to post

Hello,

je pars en congés ce soir, donc on va dire que le sujet est clos, je vais tâcher de suivre un peu mieux l'évolution sur les serveurs (le parc pc n'étant pas vraiment mon périmètre).

merci à vous pour les informations !

Share this post


Link to post

Bonjour,

Je viens de lire ce post et cela m'a fait penser à un problème que j'avais rencontré il y a quelques temps avec un autre logiciel.

Tes vlan sont connecté sur un serveur DNS avec plusieurs cartes réseaux ? ou chaque VLAN a son propre serveur DNS ? Et as-tu plusieurs serveurs DNS ou un seul ?

Pour ma part le problème que je rencontré était que mon serveur DNS, qui avait 1 carte réseau par VLAN, répondait aux requêtes sur une carte réseau la plus disponible, donc pas forcement sur le bon VLAN.

Du coup il faut faire quelques modifs pour que la requête soit toujours acheminé sur la carte d'origine de la demande.

Comme je dit souvent les serveurs DNS sont la clé du succès ou des problèmes si ils n'ont pas étaient configuré comme il faut.

Share this post


Link to post
Le 25/09/2018 à 16:33, barman2015 a dit :

Du coup il faut faire quelques modifs pour que la requête soit toujours acheminé sur la carte d'origine de la demande.

vérification de la table de routage + gateway...

par contre plusieurs vlan sur un serveur... c'est bizarre : normalement c'est géré par les switchs et routeurs ça.

Le 25/09/2018 à 16:33, barman2015 a dit :

Comme je dit souvent les serveurs DNS sont la clé du succès ou des problèmes si ils n'ont pas étaient configuré comme il faut.

oui tout à fait ;)

Edited by Tchup

Share this post


Link to post
Sign in to follow this  

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.