Déployer des agents logiciels
![]() Note |
Les scripts du programme d’installation téléchargés à partir de comptes LDAP ou AD avec le mappage automatique des rôles échouent une fois que vous êtes déconnecté. Pour donner aux scripts du programme d’installation un accès ininterrompu à la grappe, activez Use Local Authentication (utiliser l’authentification locale). |
Lors du déploiement, l’agent se voit attribuer une identité unique par la grappe Cisco Secure Workload en fonction d’un ensemble de paramètres propres à l’hôte sur lequel l’agent est exécuté. Si le nom d’hôte et l’UUID du BIOS font partie de l’ensemble de paramètres, vous pourriez rencontrer les problèmes suivants :
-
Échec de l’enregistrement lors du clonage d’une machine virtuelle en conservant l’UUID BIOS et le nom d’hôte, et lors du clonage instantané d’un VDI. L’échec de l’enregistrement se produit parce que Cisco Secure Workload comporte déjà un agent logiciel enregistré qui utilise les mêmes paramètres définis. Vous pouvez supprimer l’agent enregistré à l’aide d’OpenAPI. Dans certains cas, un UUID BIOS en double configuré lors du démarrage est modifié par VMware après un certain temps. L’inscription de l’agent est rétablie une fois que les services Cisco Cisco Secure Workload sont redémarrés.
-
Une nouvelle identité est générée pour l’agent si le nom d’hôte est modifié et l’hôte redémarré. L’agent redondant ou l’ancien agent est marqué comme inactif après un certain temps. Pour en savoir plus, consultez la section Foire aux questions.
Supported Platforms and Requirements
For supported platforms and additional requirements for software agents, see:
-
The release notes for your release, see Release Notes.
-
The agent install wizard in the Secure Workload web portal: In the navigation bar on the left, choose Installer tab. Choose an installation method, a platform, and if applicable, an agent type to see supported platform versions.
, then click the -
For additional dependencies, see Support Matrix. Ensure that you are seeing all the columns.
-
Additional requirements for each platform and agent type are listed in the following sections.
Installation des agents Linux pour une visibilité approfondie et une application
Configuration requise et conditions préalables à l’installation des agents Solaris
-
Consultez la section Plateformes prises en charge et exigences.
-
Privilèges racine pour installer et exécuter les services.
-
Espace de stockage de 1 Go pour l’agent et le fichier journal.
-
Des exclusions de sécurité sont configurées sur les applications de sécurité qui surveillent l’hôte pour empêcher ces applications de bloquer l’installation ou l’activité des agents. Pour en savoir plus, consultez Exclusions de sécurité.
-
Un utilisateur spécial, tet-sensor, est créé sur l’hôte sur lequel l’agent est installé. Si PAM ou SELinux est configuré sur l’hôte, l’utilisateur tet-sensor doit recevoir les privilèges appropriés pour exécuter le processus tet-sensor et établir des connexions avec les collecteurs. Si un autre répertoire d’installation est fourni et que SELinux est configuré, assurez-vous que l’exécution est autorisée pour cet emplacement.
-
Vous devez être en mesure d’utiliser la commande unzip si l’agent est installé à l’aide de la méthode d’installation automatique (script d’installation).
Méthodes prises en charge pour l’installation des agents Linux
Méthodes d’installation d’un agent Linux pour une visibilité et une application approfondies :
Installer l’agent Linux à l’aide de la méthode du programme d’installation de l’image de l’agent
Nous vous recommandons d’utiliser la méthode du script d’installation automatisé pour installer les agents Linux. Utilisez la méthode de l’installation par image si vous avez une raison précise d’utiliser cette méthode manuelle.
Prérequis
Configurez ACTIVATION_Key et HTTPS_PROXY dans le fichier user.cfg pour les grappes de logiciels-services et lorsque vous installez l’agent sur un détenteur autre que par défaut, des grappes sur site à plusieurs détenteurs. Pour en savoir plus, consultez (Installations manuelles uniquement) Mise à jour du fichier de configuration de l'utilisateur.
Pour installer un agent Linux à l'aide de la méthode de l'image de l'agent :
Procedure
Step 1 |
Accédez à Méthodes d’installation des agents :
|
||
Step 2 |
Cliquez sur Agent Image Installer (Programme d'installation de l'image de l'agent). |
||
Step 3 |
Dans le champ Platform (plateforme), saisissez Linux. |
||
Step 4 |
Saisissez le type et la version de l’agent requis, puis, à partir des résultats, téléchargez la version de l’agent nécessaire. |
||
Step 5 |
Copiez le paquet logiciel RPM sur tous les hôtes Linux pour le déploiement.
|
||
Step 6 |
En fonction de votre plateforme, exécutez les commandes RPM avec les privilèges racine.
|
Installer l’agent Linux à l’aide de la méthode du programme d’installation du script de l’agent
Nous vous recommandons d’utiliser la méthode du script du programme d’installation pour déployer des agents Linux afin d’assurer la visibilité approfondie et l'application.
![]() Note |
|
Pour installer un agent Linux à l'aide du programme d'installation de script :
Procedure
Step 1 |
Accédez à Méthodes d’installation des agents :
|
||
Step 2 |
Cliquez sur Agent Script Installer (Installateur de script d'agent). |
||
Step 3 |
Dans le menu déroulant Select Platform (sélectionner une plateforme), choisissez Linux. Pour afficher les plateformes Linux prises en charge, cliquez sur Show Supported Platforms(afficher les plateformes prises en charge). |
||
Step 4 |
Choisissez le détenteur pour installer les agents.
|
||
Step 5 |
Si vous souhaitez attribuer des étiquettes à la charge de travail, choisissez les clés d’étiquette et saisissez les valeurs d’étiquette. Lorsque l'agent installé signale des adresses IP sur l'hôte, les étiquettes CMDB de l'installateur sélectionnées ici, ainsi que les autres étiquettes CMDB téléversées qui ont été attribuées aux adresses IP signalées par cet hôte, sont automatiquement attribuées à la nouvelle adresse IP. En cas de conflit entre les étiquettes de la CMDB téléversées et celles de la CMDB d’installation :
|
||
Step 6 |
Si un serveur mandataire HTTP est requis pour communiquer avec Cisco Secure Workload, choisissez Yes(oui), puis saisissez une URL de serveur mandataire valide. |
||
Step 7 |
Dans la section Installer expiration (Expiration de la validité du programme d'installation), sélectionnez une option :
|
||
Step 8 |
Cliquez sur Download (Télécharger) et enregistrez le fichier sur le disque local. |
||
Step 9 |
Copiez le script d’interface Shell du programme d’installation sur les hôtes Linux et exécutez la commande suivante pour accorder
l’autorisation d’exécution au script :
|
||
Step 10 |
Pour installer l’agent, exécutez la commande suivante avec les privilèges de l’utilisateur racine :
|
Nous vous recommandons d’exécuter la vérification préalable, comme spécifié dans les détails d’utilisation du script.
bash tetration_linux_installer.sh [--pre-check] [--skip-pre-check=<option>] [--no-install] [--logfile=<filename>] [--proxy=<proxy_string>] [--no-proxy] [--help] [--version] [--sensor-version=<version_info>] [--ls] [--file=<filename>] [--save=<filename>] [--new] [--reinstall] [--unpriv-user] [--force-upgrade] [--upgrade-local] [--upgrade-by-uuid=<filename>] [--basedir=<basedir>] [--logbasedir=<logbdir>] [--tmpdir=<tmp_dir>] [--visibility] [--golden-image]
--pre-check: run pre-check only
--skip-pre-check=<option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '--skip-pre-check=all' will skip all pre-installation checks; All pre-checks will be performed by default
--no-install: will not download and install sensor package onto the system
--logfile=<filename>: write the log to the file specified by <filename>
--proxy=<proxy_string>: set the value of CL_HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
--no-proxy: bypass system wide proxy; this flag will be ignored if --proxy flag was provided
--help: print this usage
--version: print current script's version
--sensor-version=<version_info>: select sensor's version; e.g.: '--sensor-version=3.4.1.0'; will download the latest version by default if this flag was not provided
--ls: list all available sensor versions for your system (will not list pre-3.1 packages); will not download any package
--file=<filename>: provide local zip file to install sensor instead of downloading it from cluster
--save=<filename>: download and save zip file as <filename>
--new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
--reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than --new
--unpriv-user=<username>: use <username> for unpriv processes instead of tet-sensor
--force-upgrade: force sensor upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --force-upgrade'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-local: trigger local sensor upgrade to version given by --sensor-version flag: e.g.: '--sensor-version=3.4.1.0 --upgrade-local'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-by-uuid=<filename>: trigger sensor whose uuid is listed in <filename> upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --upgrade-by-uuid=/usr/local/tet/sensor_id'; apply the latest version by default if --sensor-version flag was not provided
--basedir=<base_dir>: instead of using /usr/local use <base_dir> to install agent. The full path will be <base_dir>/tetration
--logbasedir=<log_base_dir>: instead of logging to /usr/local/tet/log use <log_base_dir>. The full path will be <log_base_dir>/tetration
--tmpdir=<tmp_dir>: instead of using /tmp use <tmp_dir> as temp directory
--visibility: install deep visibility agent only; --reinstall would overwrite this flag if previous installed agent type was enforcer
--golden-image: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
![]() Note |
|
Prise en charge des agents pour la plateforme de mise en réseau Blufield de NVIDIA
Une unité de traitement des données (DPU) est un processeur programmable conçu pour gérer des tâches centrées sur les données, notamment le transfert de données, l'optimisation de la consommation d'énergie, la sécurité, la compression, l'analyse et le chiffrement.
L’unité de traitement de données (DPU) de NVIDIA est une carte d’interface réseau Smart (SmartNic) offrant des rendements réseau intéressants. Elle offre une capacité de carte réseau Ethernet NIC haut débit. Notamment, elle permet l’exécution de logiciels directement sur la carte NIC elle-même, ce qui permet l’interception, la surveillance ou la manipulation du trafic réseau passant par la NIC.
NVIDIA facilite cette fonctionnalité en fournissant le SDK DOCA. S'appuyant sur la technologie de virtualisation basée sur la virtualisation PCIe Single Root I/O (SR-IOV), la DPU établit un mécanisme permettant aux machines virtuelles (VM) de communiquer directement sans l'intervention de l'hyperviseur. La DPU intègre un commutateur électronique eSwitch à accélération matérielle basé sur OpenVSwitch pour le contrôle du réseau, ce qui améliore l’efficacité globale.
Exigences et prérequis
-
Assurez-vous que DOCA basé sur Ubuntu 22.04 est installé sur la plateforme de réseau BlueField.
-
Configurez le réseau de la carte DPU pour permettre la connexion de l’agent à la grappe par l’intermédiaire de l’une des interfaces hors bande. Les options incluent oob_net0, tmfifo_net0 ou la connexion dans la bande par enp3s0f0s0.
Installation des agents
L’installation suit un processus de type Linux.
-
Accédez à Méthodes d’installation des agents :
-
Si vous utilisez le logiciel pour la première fois, lancez l’assistant de démarrage rapide et cliquez sur Install Agents (Installer les agents).
-
Dans le volet de navigation, choisissez Manage (Gestion)> Workloads (Charges de travail)> Agents (Agents).
-
-
Dans l’onglet Installer (Programme d'installation), sélectionnez Agent Script Installer (Programme d'installation de script d'agent).
-
Dans le menu déroulant Select Platform (sélectionner une plateforme), choisissez Linux.
Pour afficher les plateformes Linux prises en charge, cliquez sur Show Supported Platforms(afficher les plateformes prises en charge).
Note
L'agent Cisco Secure Workload est uniquement pris en charge sur le SDK DOCA basé sur Ubuntu 22.
-
Choisissez le détenteur pour installer les agents.
Note
La sélection d’un détenteur n’est pas requise pour les grappes de logiciel-service Cisco Secure Workload.
-
Si vous souhaitez attribuer des étiquettes à la charge de travail, choisissez les clés d’étiquette et saisissez les valeurs d’étiquette.
-
Si un serveur mandataire HTTP est requis pour communiquer avec Cisco Secure Workload, choisissez Yes(oui), puis saisissez un serveur mandataire valide.
-
Dans la section Installer expiration (expiration du programme d’installation), sélectionnez-en une option parmi celles disponibles :
-
Aucune expiration : le script d’installation peut être utilisé plusieurs fois.
-
Une fois : le script d’installation ne peut être utilisé qu’une seule fois.
-
Limité dans le temps : vous pouvez définir le nombre de jours pendant lesquels le script d’installation peut être utilisé.
-
Nombre de déploiements : vous pouvez définir le nombre d'utilisations du script d'installation.
-
-
Cliquez sur Download (Télécharger) pour télécharger le script d’installation de Linux sur la DPU à l’aide de l’un de ses périphériques réseau.
-
Exécutez le script d’installation. Pour en savoir plus, consultez Installer l’agent Linux à l’aide de la méthode du programme d’installation du script de l’agent.
Figure 1. Script d’installation
Accédez à
et cliquez sur un nom d’hôte. Sous Interfaces, vous pouvez afficher le mappage actuel des interfaces avec les adresses IP associées.![](/c/dam/en/us/td/i/400001-500000/470001-480000/479001-480000/479837.jpg)
Accédez à
(Enquêter sur le trafic) pour surveiller le trafic réseau entre les machines virtuelles (VM) lorsque celles-ci utilisent les interfaces de réseau virtuelles SR_IOV fournies par la DPU. L’agent sur la DPU permet la segmentation du trafic réseau entre ces interfaces réseau virtuelles.Vérifier l’installation de l’agent Linux
Procedure
Exécutez la commande sudo rpm -q tet-sensor
Exemple de résulta : La sortie spécifique peut différer en fonction de la plateforme et de l’architecture. |
Installation des agents Windows pour une visibilité approfondie et pour application
Exigences et conditions préalables à l’installation de l’agent Windows
-
Consultez la section Plateformes prises en charge et exigences.
-
Des privilèges d’administrateur sont requis pour l’installation et l’exécution du service.
-
Npcap doit être installé sur les charges de travail exécutant Windows 2008 R2 ou lorsque la version de l’agent installé est antérieure à la version 3.8. Si le pilote Npcap n'est pas déjà installé, la version Npcap recommandée est installée en arrière-plan par l'agent après le démarrage du service. Pour en savoir plus, consultez les informations de version de Npcap.
-
Un Go d’espace de stockage pour les fichiers des agents et des journaux.
-
Activez les services Windows requis pour l’installation de l’agent. Certains des services Windows auraient pu être désactivés si vos hôtes Windows avaient été renforcés en matière de sécurité ou s’ils ont changé par rapport aux configurations par défaut. Pour en savoir plus, consultez la section Services Windows requis.
-
Les exclusions de sécurité configurées sur les applications de sécurité qui surveillent l’hôte et qui pourraient bloquer l’installation de l’agent ou son activité. Pour en savoir plus, consultez Exclusions de sécurité.
Méthodes prises en charge pour l’installation des agents Windows
Il existe deux méthodes pour installer les agents Windows pour une visibilité approfondie et la mise en application.
-
Installer l’agent Windows à l’aide de la méthode du programme d’installation du script de l’agent
-
Installer l’agent Windows à l’aide de la méthode du programme d’installation de l’image de l’agent
Vous pouvez également les installer en utilisant une image Golden. Pour en savoir plus, consultez la section Déploiement des agents sur une instance VDI ou un modèle de VM (Windows).
Installer l’agent Windows à l’aide de la méthode du programme d’installation du script de l’agent
Nous vous recommandons d’utiliser la méthode du programme d’installation de scripts pour déployer les agents Windows afin d’obtenir une visibilité et une application approfondies.
![]() Note |
|
Pour installer un agent Windows à l’aide du programme d’installation de script :
Procedure
Step 1 |
Accédez à Méthodes d’installation des agents :
|
||
Step 2 |
Cliquez sur Agent Script Installer (Installateur de script d'agent). |
||
Step 3 |
Dans le menu déroulant Select Platform (sélectionner une plateforme), choisissez Windows. Pour afficher les plateformes Windows prises en charge, cliquez sur Show Supported Platforms(afficher les plateformes prises en charge). |
||
Step 4 |
Choisissez le détenteur pour installer les agents.
|
||
Step 5 |
Si vous souhaitez attribuer des étiquettes à la charge de travail, choisissez les clés d’étiquette et saisissez les valeurs d’étiquette. Lorsque l'agent installé signale des adresses IP sur l'hôte, les étiquettes CMDB de l'installateur sélectionnées ici, ainsi que les autres étiquettes CMDB téléversées qui ont été attribuées aux adresses IP signalées par cet hôte, sont attribuées à la nouvelle adresse IP. En cas de conflit entre les étiquettes de la CMDB téléversées et celles de la CMDB d’installation :
|
||
Step 6 |
Si un serveur mandataire HTTP est requis pour communiquer avec Cisco Secure Workload, choisissez Yes(Oui), puis saisissez une URL de serveur mandataire valide. |
||
Step 7 |
Dans la section Installer expiration (Expiration de la validité de l'installateur), sélectionnez une option parmi celles disponibles :
|
||
Step 8 |
Cliquez sur Download (Télécharger) et enregistrez le fichier sur le disque local. |
||
Step 9 |
Copiez le script d’installation PowerShell sur tous les hôtes Windows pour le déploiement et exécutez le script avec des privilèges d’administration.
|
# powershell -ExecutionPolicy Bypass -File tetration_windows_installer.ps1 [-preCheck] [-skipPreCheck <Option>] [-noInstall] [-logFile <FileName>] [-proxy <ProxyString>] [-noProxy] [-help] [-version] [-sensorVersion <VersionInfo>] [-ls] [-file <FileName>] [-save <FileName>] [-new] [-reinstall] [
-npcap] [-forceUpgrade] [-upgradeLocal] [-upgradeByUUID <FileName>] [-visibility] [-goldenImage] [-installFolder <Installation Path>]
-preCheck: run pre-check only
-skipPreCheck <Option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '-skipPreCheck all' will skip all pre-installation checks; All pre-checks will be performed by default
-noInstall: will not download and install sensor package onto the system
-logFile <FileName>: write the log to the file specified by <FileName>
-proxy <ProxyString>: set the value of HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
-noProxy: bypass system wide proxy; this flag will be ignored if -proxy flag was provided
-help: print this usage
-version: print current script's version
-sensorVersion <VersionInfo>: select sensor's version; e.g.: '-sensorVersion 3.4.1.0.win64'; will download the latest version by default if this flag was not provided
-ls: list all available sensor versions for your system (will not list pre-3.1 packages); will not download any package
-file <FileName>: provide local zip file to install sensor instead of downloading it from cluster
-save <FileName>: downloaded and save zip file as <FileName>
-new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
-reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than -new
-npcap: overwrite existing npcap
-forceUpgrade: force sensor upgrade to version given by -sensorVersion flag; e.g.: '-sensorVersion 3.4.1.0.win64 -forceUpgrade'; apply the latest version by default if -sensorVersion flag was not provided
-upgradeLocal: trigger local sensor upgrade to version given by -sensorVersion flag; e.g.: '-sensorVersion 3.4.1.0.win64 -upgradeLocal'; apply the latest version by default if -sensorVersion flag was not provided
-upgradeByUUID <FileName>: trigger sensor whose uuid is listed in <FileName> upgrade to version given by -sensorVersion flag; e.g.: '-sensorVersion 3.4.1.0.win64 -upgradeByUUID "C:\\Program Files\\Cisco Tetration\\sensor_id"'; apply the latest version by default if -sensorVersion flag was not provided
-visibility: install deep visibility agent only; -reinstall would overwrite this flag if previous installed agent type was enforcer
-goldenImage: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
-installFolder: install Cisco Secure Workload Agent in a custom folder specified by -installFolder e.g.: '-installFolder "c:\\custom sensor path"'; default path is "C:\Program Files\Cisco Tetration"
Installer l’agent Windows à l’aide de la méthode du programme d’installation de l’image de l’agent
Nous vous recommandons d’utiliser la méthode du script d’installation automatisé pour installer les agents Windows. Utilisez la méthode de l’installation par image si vous avez une raison précise d’utiliser cette méthode manuelle.
![]() Note |
Ne déployez pas manuellement une version antérieure de l’agent MSI lorsqu’un agent existant est déjà en cours d’exécution sur l’hôte. |
Les fichiers liés au site qui se trouvent dans le paquet :
-
ca.cert - Obligatoire : certificat de l’autorité de certification pour les communications des capteurs.
-
enforcer.cfg - Obligatoire uniquement lors de l’installation du capteur d’application - Contient la configuration des points terminaux de mise en application.
-
sensor_config - Obligatoire : configuration pour le capteur de visibilité approfondie.
-
sensor_type :Type de capteur (mise en application ou visibilité approfondie).
-
site.cfg : obligatoire : configuration du point terminal de site global.
-
user.cfg :obligatoire pour les logiciels-services : configuration de la clé d’activation du capteur et du serveur mandataire.
Prérequis
Configurez ACTIVATION_Key et HTTPS_PROXY dans le fichier user.cfg pour les grappes de logiciels-services et lorsque vous installez l’agent sur un détenteur autre que par défaut, des grappes sur site à plusieurs détenteurs. Pour en savoir plus, consultez (Installations manuelles uniquement) Mise à jour du fichier de configuration de l'utilisateur.
Pour installer un agent Windows à l’aide de la méthode de l’image de l’agent :
Procedure
Step 1 |
Accédez à Méthodes d’installation des agents :
|
||||||||||||||||||
Step 2 |
Cliquez sur Agent Image Installer (Programme d'installation de l'image de l'agent). |
||||||||||||||||||
Step 3 |
Dans le champ Platform (plateforme), saisissez Windows. |
||||||||||||||||||
Step 4 |
Saisissez le type et la version de l’agent requis, puis, à partir des résultats, téléchargez la version de l’agent nécessaire. |
||||||||||||||||||
Step 5 |
Copier le fichier tet-win-sensor<version>.win64-<clustername>.zipsur tous les hôtes Windows pour le déploiement. |
||||||||||||||||||
Step 6 |
Assurez-vous que vous disposez de privilèges d’administration et extrayez le fichier ZIP. |
||||||||||||||||||
Step 7 |
Dans le dossier extrait, exécutez la commande suivante pour installer l’agent : En outre, les options suivantes sont disponibles pour le programme d’installation MSI.
|
![]() Note |
|
Vérifier l’installation de l’agent Windows
Procedure
Step 1 |
Vérifiez que le dossier |
Step 2 |
Vérifiez que le serviceTetSensor CswAgent, pour une visibilité et une application approfondies, existe et qu’il est en cours d’exécution. Exécutez la commande Exécutez la commande Vérifiez si l’état est Running (En cours d’exécution) Exécuter la commande Vérifiez si DISPLAY-NAME est Cisco Secure Workload Deep Visibility (Visibilité approfondie de Cisco Secure Workload) OU Exécutez la commande services.msc Trouvez le nom de Cisco Secure Workload Deep Visibility (Visibilité approfondie de Cisco Secure Workload) Vérifiez si l’état est Running (En cours d’exécution) |
Vérification de l’agent Windows dans le contexte utilisateur du service configuré
-
Vérifiez que les protocoles TetSensor (pour la visibilité approfondie) et TetEnforcer (pour la mise en application) s’exécutent dans le contexte d’utilisateur de service configuré. TetSensor et TetEnforcer s’exécutent dans le même contexte d’utilisateur de service.
Assurez-vous que le service CswAgent en cours d’exécution dans le contexte d’utilisateur de service configuré. CswAgent s’exécute dans le même contexte d’utilisateur de service.
Exécutez la commande
cmd.exe
avec des privilèges d’administrateur.Exécuter la commande
sc qc tetsensor
sc qc cswagent
Cochez SERVICE_START_NAME.<utilisateur du service configuré>
Exécutez la commande
sc qc tetenforcer
Cochez SERVICE_START_NAME.<utilisateur du service configuré>
OU
Exécutez la commande
services.msc
Trouvez le nom de Cisco Secure Workload Deep Visibility (Visibilité approfondie de Cisco Secure Workload)
Cochez Log On As (Ouvrir une session en tant que) pour l'<utilisateur du service configuré>
Trouvez le nom Cisco Secure Workload Enforcement.
Cochez Log On As (Ouvrir une session en tant que) pour l'<utilisateur du service configuré>
OU
Exécutez la commande
tasklist /v | find /i “tet"
Exécutez la commande
tasklist /v | find /i “cswengine”
Vérifier le contexte utilisateur pour les processus en cours d’exécution (5e colonne)
Modifier le compte de service
Après avoir installé les agents Windows, utilisez l’une des méthodes suivantes pour modifier les services de visibilité approfondie et de mise en application existants.
-
Utilisez services.msc.
Illustration 3. Modifier le compte de service en fonction du compte services.msc -
Utilisez une application tierce pour configurer les services.
-
Utilisez les commandes suivantes :
-
Exécutez cmd en tant qu’administrateur.
-
Modifiez les services à l'aide du nom du compte de service en exécutant les commandes suivantes :
-
sc config tetsensor obj= <service user name> password= <password>
-
sc config tetenforcer obj= <service user name> password= <password>
-
sc config cswagent obj= <service user name> password= <password>
-
-
Vérifiez les configurations de service en exécutant les commandes suivantes :
-
sc qc tetsensor
-
sc qc tetenforcer
-
sc qc cswagent
-
-
Redémarrez les services tetsensor et tetenforcer en exécutant les commandes suivantes :
Redémarrez le service CswAgent en exécutant les commandes suivantes :
-
sc stop tetsensor / tetenforcer
-
sc start tetsensor / tetenforcer
-
sc stop cswagent
-
sc start cswagent
-
-
Déploiement des agents sur une instance VDI ou un modèle de machine virtuelle (Windows)
Par défaut, les services d’agent démarrent automatiquement après l’installation des agents. Lors de l’installation sur une image idéale (golden), vous devez utiliser des indicateurs d’installation pour empêcher ces services de démarrer. Lorsque des instances sont dupliquées à partir de l’image idéale, les services d’agent, comme prévu, démarrent automatiquement.
L’agent n’installera pas NPCAP sur les machines virtuelles golden, mais sera automatiquement installé si nécessaire sur les instances de VM clonées à partir d’une image golden. Pour en savoir plus, consultez Programme d’installation de l’agent Windows et NPCAP.
Installer l’agent sur une image idéale dans un environnement VDI ou un modèle de machine virtuelle
Procedure
Step 1 |
Installez l’agent sur une image idéale dans un environnement VDI ou un modèle de machine virtuelle à l’aide d’un programme d’installation MSI ou d’un script d’installation PowerShell : Utiliser le programme d’installation MSI avec nostart=yes
OU Utilisez le programme d’installation PowerShell avec l’indicateur -goldenImage.
|
Step 2 |
Vérifiez que le dossier |
Step 3 |
Assurez-vous que le service TetSensor (pour une visibilité approfondie) existe et qu’il est arrêté : Exécutez la commande Exécutez la commande Vérifiez si STATE (ÉTAT) est arrêté. |
Step 4 |
Assurez-vous que le service TetEnforcer (pour la mise en application) existe et qu’il est arrêté : Exécutez la commande sc query tetenforcer. Vérifiez si STATE (ÉTAT) est arrêté. . |
Step 5 |
Vérifiez que le service CswAgent existe et qu’il est arrêté : Exécutez la commande Exécutez la commande Vérifiez si STATE (ÉTAT) est arrêté. |
Step 6 |
Le modèle de machine virtuelle est maintenant configuré. |
Step 7 |
Arrêtez le modèle de machine virtuelle. |
Créer une nouvelle instance de machine virtuelle VDI
Procedure
Step 1 |
Créez une nouvelle machine virtuelle d’instance VDI en dupliquant le modèle de machine virtuelle. |
||
Step 2 |
Redémarrez la machine virtuelle de l’instance VDI. |
||
Step 3 |
Après avoir redémarré la machine virtuelle de l’instance VDI, assurez-vous que les services – TetSensor (pour une visibilité approfondie) et TetEnforcer (pour l’application) – s’exécutent dans le contexte de service configuré. Reportez-vous à la section Vérifiez que l’agent est installé. |
||
Step 4 |
Après avoir redémarré la machine virtuelle de l’instance VDI, vérifiez que le service CswAgent est en cours d’exécution dans le contexte de service configuré. Reportez-vous à la section Vérifiez que l’agent est installé. |
||
Step 5 |
Sur la machine virtuelle de l’instance VDI, assurez-vous que le pilote NPCAP est installé et en cours d’exécution : Exécutez la commande Exécutez la commande Vérifiez si STATE (ÉTAT ) est égal à Running (Exécution en cours) |
||
Step 6 |
Sur la machine virtuelle de l’instance VDI, assurez-vous que l’agent est enregistré à l’aide d’un sensor_id (identifiant de capteur) valide :
|
Programme d’installation de l’agent Windows et Npcap : pour Windows 2008 R2
-
Pour les versions de Npcap prises en charge, consultez la matrice de prise en charge à l’adresse https://www.cisco.com/go/secure-workload/requirements/agents.
-
Installation :
Si Npcap n’est pas installé, l’agent installe la version prise en charge dix secondes après le démarrage du service. Si Npcap est installé chez l’utilisateur, mais que la version est antérieure à la version prise en charge, Npcap n’est pas mis à niveau. Mettez à niveau ou désinstallez manuellement Npcap, exécutez le programme d’installation de l’agent en incluant l’option overwritenpcap=yes ou exécutez le script d’installation avec -npcap pour obtenir la version de Npcap prise en charge. Si le pilote Npcap est en cours d'utilisation par une application, l’agent met à niveau Npcap ultérieurement.
-
Mettre à niveau :
Si Npcap est installé par l’agent Windows et que la version est antérieure à la version prise en charge, Npcap est mis à niveau à la version prise en charge dix secondes après le démarrage du service. Si le pilote Npcap est en cours d'utilisation par une application, l’agent met à niveau Npcap ultérieurement. Si Npcap n’est pas installé par l’agent Windows, Npcap n’est pas mis à niveau.
-
Désinstaller :
Si Npcap est installé par l’agent Windows, l’agent désinstalle Npcap. Si Npcap est installé par l’utilisateur, mais mis à niveau par le programme d’installation de l’agent avec l'option overwritenpcap=yes, Npcap n’est pas désinstallé. Si le pilote Npcap est utilisé par une application, l’agent ne désinstalle pas Npcap.
Captures de flux de l’agent Windows : pour tous les systèmes d’exploitation Windows, à l’exception de Windows Server 2008 R2
À partir de la dernière version de Windows, l’agent utilise le pilote ndiscap.sys (intégré à Microsoft) et le cadre Events Tracing using Windows (ETW) pour capturer les flux du réseau.
Lors de la mise à jour vers la dernière version :
-
L’agent passe à ndiscap.sys à partir de npcap.sys.
-
Le programme d'installation de l'agent désinstalle Npcap si :
-
Npcap est installé par l’agent.
-
Npcap n’est pas utilisé.
-
La version du système d’exploitation n’est pas Windows Server 2008 R2.
-
Une fois les services de l’agent démarrés, l’agent crée des sessions ETW, CSW_MonNet et CSW_MonDns (pour les données DNS), et lance la capture des flux réseau.
![]() Note |
|
Installation des agents AIX pour une visibilité approfondie et une mise en application
![]() Note |
Les fonctions d’arborescence de processus, de paquet (CVE) et de rapports sur les événements criminalistiques ne sont pas disponibles sur AIX. En outre, certains aspects de ces fonctionnalités peuvent ne pas être disponibles dans des versions mineures spécifiques de plateformes prises en charge en raison des limites du système d’exploitation. |
Configuration requise et conditions préalables à l’installation des agents AIX
-
Consultez la section Plateformes prises en charge et exigences.
-
Exigences supplémentaires pour une visibilité approfondie :
-
Privilèges racine pour installer et exécuter les services.
-
Exigences de stockage pour les fichiers d’agent et de journaux : 500 Mo.
-
Les exclusions de sécurité configurées sur toutes les applications de sécurité qui surveillent l’hôte. Ces exclusions visent à empêcher d’autres applications de sécurité de bloquer l’installation ou l’activité des agents. Pour en savoir plus, consultez Exclusions de sécurité.
-
AIX prend en charge la capture de flux de seulement 20 périphériques réseau (6 périphériques réseau si la version est AIX 7.1 TL3 SP4 ou antérieure). L’agent de visibilité approfondie effectue la capture à partir d’un maximum de 16 périphériques réseau, laissant les quatre autres sessions de capture disponibles pour une utilisation générique exclusive du système (par exemple, tcpdump).
-
L’agent de visibilité en profondeur effectue les opérations suivantes pour assurer la capture des flux de 20 périphériques réseau :
-
L'agent crée 16 nœuds de périphérique bpf dans le répertoire agents (/opt/cisco/tetration/chroot/dev/bpf0 à /opt/cisco/tetration/chroot/dev/bpf15)
-
tcpdump et d’autres outils système utilisant bpf analyseront les nœuds du périphérique système (/dev/bpf0 à /dev/bpf19) jusqu’à ce qu’ils trouvent un nœud inutilisé (!EBUSY).
-
Les nœuds bpf créés par l’agent et les nœuds bpf du système partagent les mêmes majeures/mineures, chaque majeure ou mineure étant ouverte par une seule instance (tcpdump ou agent).
-
L’agent n’accède pas aux nœuds du périphérique système et ne les crée pas comme le fait tcpdump (tcpdump-D crée /dev/bpf0. . . /dev/bpf19 s’ils n’existent pas).
-
-
L’exécution d’iptrace sur le système empêche, dans certains scénarios, la capture du flux à partir de tcpdump et de l’agent de visibilité approfondie. Il s’agit d’un problème de conception connu qui doit être vérifié auprès d’IBM.
-
Pour vérifier si ce scénario existe, avant d’installer l’agent, exécutez tcpdump. Si le message d’erreur est tcpdump: BIOCSETIF: en0: File exists iptrace bloque la capture de flux. Arrêtez iptrace pour résoudre le problème.
-
-
Toutes les fonctions de visibilité approfondie ne sont pas prises en charge dans AIX. La comptabilité des paquets et des processus fait partie de celles qui ne sont pas prises en charge.
-
-
Exigences supplémentaires pour l’application des politiques :
-
Si le filtre de sécurité IP est activé (c’est-à-dire, smitty IPsec4), l’installation de l’agent échoue lors de la vérification préalable. Nous vous recommandons de désactiver le filtre de sécurité IP avant d’installer l’agent.
-
Si la sécurité IP est activée lorsque l’agent de mise en application de Cisco Secure Workload est en cours d’exécution, une erreur est signalée et l’agent d’application arrête l’application de la politique. Communiquez avec le service d’assistance pour désactiver en toute sécurité le filtre de sécurité IP lorsque l’agent de mise en application est en cours d’exécution.
-
Installer l’agent AIX à l’aide de la méthode du programme d’installation du script de l’agent
Les agents AIX de visibilité et d'application en profondeur ne peuvent être installés qu'à l'aide de la méthode d'installation par script de l'agent.
![]() Note |
|
Pour installer un agent AIX :
Procedure
Step 1 |
Accédez à Méthodes d’installation des agents :
|
||
Step 2 |
Cliquez sur Agent Script Installer (Installateur de script d'agent). |
||
Step 3 |
Dans le menu déroulant Select Platform (sélectionner une plateforme), choisissez AIX. Pour afficher les plateformes AIX prises en charge, cliquez sur Show Supported Platforms (Afficher les plateformes prises en charge). |
||
Step 4 |
Choisissez le détenteur pour installer les agents.
|
||
Step 5 |
Si vous souhaitez attribuer des étiquettes à la charge de travail, choisissez les clés d’étiquette et saisissez les valeurs d’étiquette. Lorsque l'agent installé signale des adresses IP sur l'hôte, les étiquettes CMDB de l'installateur sélectionnées ici, ainsi que les autres étiquettes CMDB téléversées qui ont été attribuées aux adresses IP signalées par cet hôte, sont automatiquement attribuées à la nouvelle adresse IP. En cas de conflit entre les étiquettes de la CMDB téléversées et celles de la CMDB d’installation :
|
||
Step 6 |
Si un serveur mandataire HTTP est requis pour communiquer avec Cisco Secure Workload, choisissez Yes(Oui), puis saisissez une URL de serveur mandataire valide. |
||
Step 7 |
Dans la section Installer expiration (Expiration de la validité de l'installateur), sélectionnez une option parmi celles disponibles :
|
||
Step 8 |
Cliquez sur Download (Télécharger) et enregistrez le fichier sur le disque local. |
||
Step 9 |
Copiez le script Shell du programme d’installation sur tous les hôtes AIX pour le déploiement. |
||
Step 10 |
Pour accorder l'autorisation d'exécution au script, exécutez la commande :
|
||
Step 11 |
Pour installer l’agent, exécutez la commande suivante avec les privilèges racine :
|
Nous vous recommandons d’exécuter la vérification préalable, comme spécifié dans les détails d’utilisation du script.
Détails de l’utilisation du script d’installation d’AIX :
ksh tetration_installer_default_enforcer_aix.sh [--pre-check] [--pre-check-user] [--skip-pre-check=<option>] [--no-install] [--logfile=<filename>] [--proxy=<proxy_string>] [--no-proxy] [--help] [--version] [--sensor-version=<version_info>] [--ls] [--file=<filename>] [--osversion=<osversion>] [--save=<filename>] [--new] [--reinstall] [--unpriv-user] [--libs=<libs.zip|tar.Z>] [--force-upgrade] [--upgrade-local] [--upgrade-by-uuid=<filename>] [--logbasedir=<logbdir>] [--tmpdir=<tmp_dir>] [--visibility] [--golden-image]
--pre-check: run pre-check only
--pre-check-user: provide alternative to nobody user for pre-check su support
--skip-pre-check=<option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '--skip-pre-check=all' will skip all pre-installation checks; All pre-checks will be performed by default
--no-install: will not download and install sensor package onto the system
--logfile=<filename>: write the log to the file specified by <filename>
--proxy=<proxy_string>: set the value of HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
--no-proxy: bypass system wide proxy; this flag will be ignored if --proxy flag was provided
--help: print this usage
--version: print current script's version
--sensor-version=<version_info>: select sensor's version; e.g.: '--sensor-version=3.4.1.0'; will download the latest version by default if this flag was not provided
--ls: list all available sensor versions for your system (will not list pre-3.3 packages); will not download any package
--file=<filename>: provide local zip file to install sensor instead of downloading it from cluster
--osversion=<osversion>: specify osversion for --save flag;
--save=<filename>: download and save zip file as <filename>; will download package for osversion given by --osversion flag; e.g.: '--save=myimage.aix72.tar.Z --osversion=7.2'
--new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
--reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than --new
--unpriv-user=<username>: use <username> for unpriv processes instead of tet-snsr
--libs=<libs.zip|tar.Z>: install provided libs to be used by agents
--force-upgrade: force sensor upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --force-upgrade'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-local: trigger local sensor upgrade to version given by --sensor-version flag: e.g.: '--sensor-version=3.4.1.0 --upgrade-local'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-by-uuid=<filename>: trigger sensor whose uuid is listed in <filename> upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --upgrade-by-uuid=/usr/local/tet/sensor_id'; apply the latest version by default if --sensor-version flag was not provided
--logbasedir=<log_base_dir>: instead of logging to /opt/cisco/tetration/log use <log_base_dir>. The full path will be <log_base_dir>/tetration
--tmpdir=<tmp_dir>: instead of using /tmp use <tmp_dir> as temp directory
--visibility: install deep visibility agent only; --reinstall would overwrite this flag if previous installed agent type was enforcer
--golden-image: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
Vérifier l’installation de l’agent AIX
Procédure
Exécutez la commande
État PID de groupe de sous-systèmes tet-sensor 1234567 active
État PID de groupe de sous-systèmes tet-enforcer 7654321 actif |
Installer les agents Kubernetes ou OpenShift pour une visibilité et une application approfondies
Requirements and Prerequisites
Kubernetes 1.[16-22]
-
RHEL: 7.[0-9] (only x86_64 architecture)
-
CentOS: 7.[0-8] (only x86_64 architecture)
-
Oracle Linux: 7.[0-8] (only x86_64 architecture)
-
Ubuntu: 16.04, 18.04, 20.04 (only x86_64 architecture)
-
SUSE Linux Enterprise Server: 12sp[0-5] (only x86_64 architecture)
-
Amazon Linux 2 (only x86_64 architecture)
Openshift 4.[5-9]
-
Red Hat Enterprise Linux CoreOS: 4.[5-9] (only x86_64 architecture)
Container Runtime
-
Docker
-
CRI-O
-
containerd (>= 1.5.x)
![]() Note |
For containerd runtime, if the config_path is not set, modify your config.toml (default location: /etc/containerd/config.toml) as follows: [plugins.”io.containerd.grpc.v1.cri”.registry] config_path = “/etc/containerd/certs.d” Restart the containerd daemon. |
Additional Requirements
-
The install script requires Kubernetes or OpenShift admin credentials to start privileged agent pods on the cluster nodes.
-
Secure Workload entities are created in a namespace named ‘tetration’.
-
The node or pod security policies should permit privileged mode pods.
-
busybox:1.33 images should either be pre-installated or downloadable from Docker Hub.
-
In order to run on Kubernetes or OpenShift control plane nodes, the –toleration flag can be used to pass in a toleration for the Cisco Secure Workload pods. This usually is the NoSchedule toleration that normally prevents pods from running on control plane nodes.
Requirements for Policy Enforcement
Agents enforcing policy on container orchestration platforms are supported on RHEL 7.[0-9], CentOS 7.[0-8] or Ubuntu 16.04/18.04/20.04 nodes.
IPVS based kube-proxy mode is not supported for OpenShift.
These agents should be configured with the Preserve Rules option enabled. See Creating an Agent Config Profile.
For enforcement to function properly, any installed CNI plugin must:
-
Provide a flat address space (IP network) between all nodes and pods. Network plugins which masquerade the source pod IP for intra-cluster communication are not supported.
-
Not interfere with Linux iptables rules or marks used by the Cisco Secure Workload Enforcement Agent (mark bits 21 and 20 are used to allow and deny traffic for NodePort services)
The following CNI plugins have been tested to meet the requirements above:
-
Calico (3.13) with the following Felix configurations: (ChainInsertMode: Append, Ipta- blesRefreshInterval: 0) or (ChainInsertMode: Insert, IptablesFilterAllowAction: Return, IptablesMangleAllowAction: Return, IptablesRefreshInterval: 0). All other options use their default values.
See the Felix configuration reference for more information on setting these options.
Installer l'agent Kubernetes ou OpenShift à l’aide de la méthode du programme d’installation du script de l’agent
![]() Note |
La méthode du programme d’installation du script de l’agent installe automatiquement les agents sur les nœuds inclus ultérieurement. |
Procedure
Step 1 |
Accédez aux méthodes d’installation des agents :
|
||
Step 2 |
Cliquez sur Agent Script Installer (Installateur de script d'agent). |
||
Step 3 |
Dans le menu déroulant Select Platform (Sélectionner une plateforme), choisissez Kubernetes. Pour afficher les plateformes Kubernetes ou OpenShift prises en charge, cliquez sur Show Supported Platforms(afficher les plateformes prises en charge). |
||
Step 4 |
Choisissez le détenteur pour installer les agents.
|
||
Step 5 |
Si un serveur mandataire HTTP est requis pour communiquer avec Cisco Secure Workload, choisissez Yes(Oui), puis saisissez une URL de serveur mandataire valide. |
||
Step 6 |
Cliquez sur Download (Télécharger) et enregistrez le fichier sur le disque local. |
||
Step 7 |
Exécutez le script d’installation sur une machine Linux qui a accès au serveur d’API Kubernetes et à un fichier de configuration kubectl avec des privilèges d’administration comme contexte/grappe/utilisateur par défaut. Le programme d’installation tente de lire le fichier à partir de son emplacement par défaut ( ~/.kube/config). Cependant, vous pouvez spécifier explicitement l’emplacement du fichier de configuration à l’aide de la commande --kubeconfig. |
Le script d’installation fournit des instructions sur la vérification du daemonset de l’agent Cisco Secure Workload et des pods installés.
![]() Note |
Le serveur mandataire HTTP configuré sur la page du programme d’installation de l’agent avant le téléchargement contrôle uniquement la façon dont les agents Cisco Secure Workload se connectent à la grappe Cisco Secure Workload. Ce paramètre n’affecte pas la façon dont les images Docker sont extraites par les nœuds Kubernetes ou OpenShift, car l’environnement d’exécution du conteneur sur ces nœuds utilise sa propre configuration de serveur mandataire. Si les images Docker ne sont pas extraites de la grappe Cisco Secure Workload, déboguer le processus d’extraction d’image du conteneur et ajouter un serveur mandataire HTTP approprié. |
Installation des agents Solaris pour une visibilité approfondie
Configuration requise et conditions préalables à l’installation des agents Solaris
-
Consultez la section Plateformes prises en charge et exigences.
-
Privilèges racine pour installer et exécuter les services.
-
Un Go d’espace de stockage pour les fichiers des agents et des journaux.
-
Configuration des exclusions de sécurité sur les applications de sécurité qui surveillent l'hôte, afin d'empêcher d'autres applications de sécurité de bloquer l'installation ou l'activité de l'agent. Pour en savoir plus, consultez Exclusions de sécurité.
Installer l’agent Solaris à l’aide de la méthode du programme d’installation du script de l’agent
L'agent Solaris installé prend en charge à la fois la visibilité en profondeur et la visibilité des processus ou des paquets.
Procedure
Step 1 |
Accédez à Méthodes d’installation des agents :
|
||
Step 2 |
Cliquez sur Agent Script Installer (Installateur de script d'agent). |
||
Step 3 |
Dans le menu déroulant Select Platform (sélectionner une plateforme), choisissez « Solaris ». Pour afficher les plateformes Solaris prises en charge, cliquez sur Show Supported Platforms(Afficher les plateformes prises en charge). |
||
Step 4 |
Choisissez le détenteur pour installer les agents.
|
||
Step 5 |
Si vous souhaitez attribuer des étiquettes à la charge de travail, choisissez les clés d’étiquette et saisissez les valeurs d’étiquette. Lorsque l'agent installé signale des adresses IP sur l'hôte, les étiquettes CMDB de l'installateur sélectionnées ici, ainsi que les autres étiquettes CMDB téléversées qui ont été attribuées aux adresses IP signalées par cet hôte, sont automatiquement attribuées à la nouvelle adresse IP. En cas de conflit entre les étiquettes de la CMDB téléversées et celles de la CMDB d’installation :
|
||
Step 6 |
Si un serveur mandataire HTTP est requis pour communiquer avec Cisco Secure Workload, choisissez Yes(Oui), puis saisissez une URL de serveur mandataire valide. |
||
Step 7 |
Dans la section Installer expiration (Expiration de la validité de l'installateur), sélectionnez une option parmi celles disponibles :
|
||
Step 8 |
Cliquez sur Download (Télécharger) et enregistrez le fichier sur le disque local. |
||
Step 9 |
Copiez le script du shell d'installation sur les hôtes Solaris et exécutez la commande suivante pour accorder l'autorisation
d'exécution au script :
|
||
Step 10 |
Pour installer l’agent, exécutez la commande suivante avec les privilèges d’utilisateur racine :
|
Nous vous recommandons d’exécuter la vérification préalable, comme spécifié dans les détails d’utilisation du script.
Détails d’utilisation du script d’installation de Cisco Solaris :
tetration_installer_default_sensor_solaris.sh [--pre-check] [--skip-pre-check=<option>] [--no-install] [--logfile=<filename>] [--proxy=<proxy_string>] [--no-proxy] [--help] [--version] [--sensor-version=<version_info>] [--ls] [--file=<filename>] [--save=<filename>] [--new] [--reinstall] [--unpriv-user] [--force-upgrade] [--upgrade-local] [--upgrade-by-uuid=<filename>] [--basedir=<basedir>] [--logbasedir=<logbdir>] [--tmpdir=<tmp_dir>] [--visibility] [--golden-image]
--pre-check: run pre-check only
--skip-pre-check=<option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '--skip-pre-check=all' will skip all pre-installation checks; All pre-checks will be performed by default
--no-install: will not download and install sensor package onto the system
--logfile=<filename>: write the log to the file specified by <filename>
--proxy=<proxy_string>: set the value of CL_HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
--no-proxy: bypass system wide proxy; this flag will be ignored if --proxy flag was provided
--help: print this usage
--version: print current script's version
--sensor-version=<version_info>: select sensor's version; e.g.: '--sensor-version=3.4.1.0'; will download the latest version by default if this flag was not provided
--ls: list all available sensor versions for your system (will not list pre-3.1 packages); will not download any package
--file=<filename>: provide local zip file to install sensor instead of downloading it from cluster
--save=<filename>: download and save zip file as <filename>
--new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
--reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than --new
--unpriv-user=<username>: use <username> for unpriv processes instead of nobody
--force-upgrade: force sensor upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --force-upgrade'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-local: trigger local sensor upgrade to version given by --sensor-version flag: e.g.: '--sensor-version=3.4.1.0 --upgrade-local'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-by-uuid=<filename>: trigger sensor whose uuid is listed in <filename> upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --upgrade-by-uuid=/usr/local/tet/sensor_id'; apply the latest version by default if --sensor-version flag was not provided
--logbasedir=<log_base_dir>: instead of logging to /opt/cisco/secure-workload/log use <log_base_dir>. The full path will be <log_base_dir>/secure-workload
--tmpdir=<tmp_dir>: instead of using /tmp use <tmp_dir> as temp directory
--visibility: install deep visibility agent only; --reinstall would overwrite this flag if previous installed agent type was enforcer
--golden-image: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
Vérifier l’installation de l’agent Solaris
Procedure
Step 1 |
Exécutez la commande : |
||||||||
Step 2 |
Une seule entrée constituant la sortie confirme qu’un agent Solaris est installé sur l’hôte.
|
(installations manuelles seulement) Mettre à jour le fichier de configuration utilisateur
La procédure suivante est requise uniquement pour les installations impliquant tous les éléments suivants :
-
Le logiciel-service ou grappes sur site Cisco Secure Workload avec plusieurs détenteurs (les grappes sur site qui utilisent uniquement le détenteur par défaut n’ont PAS besoin de cette procédure)
-
Installation manuelle
-
Plateforme Linux ou Windows
Les agents ont besoin d’une clé d’activation pour s’enregistrer sur la grappe Cisco Secure Workload. ils nécessitent une clé d’activation de grappe. En outre, ils peuvent avoir besoin d’un serveur mandataire HTTPS pour atteindre la grappe.
![]() Note |
Dans un environnement Windows, vous n’avez pas besoin de configurer manuellement le fichier user.cfg, si les options de clé d’activation et de serveur mandataire sont utilisées lors de l’installation manuelle. |
Avant l’installation, configurez les variables requises dans le fichier de configuration utilisateur :
Procedure
Step 1 |
Pour récupérer votre clé d'activation, accédez à , cliquez sur l'ongletInstaller (Installateur) , cliquez sur Manual Install using classic packaged installers (Installation manuelle à l'aide d'installateurs classiques), puis cliquez sur Agent Activation Key (Clé d'activation de l'agent). |
Step 2 |
Ouvrez le fichier |
Step 3 |
Ajoutez la clé d’activation à la variable ACTIVATION_KEY. Exemple : |
Step 4 |
Si l’agent nécessite un serveur mandataire HTTPS, ajoutez le serveur mandataire du protocole http et le port à l’aide de la variable HTTPS_PROXY. Exemple : |
Other Agent-Like Tools
AnyConnect agents
Platforms supported by Cisco AnyConnect Secure Mobility agent with Network Visibility Module (NVM). No additional Cisco Secure Workload agent is required. AnyConnect connector registers these agents and exports flow observations, inventories, and labels to Cisco Secure Workload. For more information, please refer to AnyConnect Connector.
For Windows, Mac, or Linux platforms, please refer to Cisco AnyConnect Secure Mobility Client Data Sheet.
ISE agents
Endpoints registered with Cisco Identity Services Engine (ISE). No Cisco Secure Workload agent on the endpoint is required. ISE connector collects metadata about endpoints from ISE through pxGrid service on ISE appliance. It registers the endpoints as ISE agents on Cisco Secure Workload and pushes labels for the inventories on these endpoints. For more information, please refer to ISE Connector.
SPAN agents
SPAN agents work with the ERSPAN connector. For information, see ERSPAN Connector.
Integration with third-party and additional Cisco products
-
Integrations using external orchestrators configured in Cisco Secure Workload.
-
Integrations using connectors configured in Cisco Secure Workload.
See What are Connectors.
Renseignements sur la connectivité
En général, lorsque l’agent est installé sur le charges de travail, il établit plusieurs connexions réseau aux services principaux hébergés sur la grappe Cisco Secure Workload. Le nombre de connexions varie selon le type d’agent et ses fonctions.
Le tableau suivant présente les différentes connexions permanentes établies par les différents types d'agents.
Type d’agent |
Serveur de configuration |
Collecteurs |
Serveur principal d’application |
---|---|---|---|
Visibilité (sur site) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:5640 |
S. O. |
visibilité (logiciel-service SaaS) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:443 |
S. O. |
des politiques de sécurité (sur site) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:5640 |
ENFORCER-IP:5660 |
enforcement (SaaS) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:443 |
ENFORCER-IP:443 |
images de Docker |
CFG-SERVER-IP:443 |
s.o. |
s.o. |
Légende :
-
CFG-SERVER-IP est l’adresse IP du serveur de configuration.
-
COLLECTOR-IP est l'adresse IP du collecteur. Les agents de visibilité approfondie et d’application se connectent à tous les collecteurs disponibles.
-
ENFORCER-IP est l’adresse IP du point terminal de mise en application. L’agent d’application se connecte à un seul des points terminaux disponibles.
-
Pour les déploiements d’agents Kubernetes/OpenShift, le script d’installation ne contient pas le logiciel agent – Les images Docker contenant le logiciel agent sont extraites de la grappe Cisco Secure Workload par chaque nœud Kubernetes/OpenShift. Ces connexions sont établies par le composant de récupération de l’image de l’exécution du conteneur et dirigées vers CFG-SERVER-IP:443.
Accédez à Platform (Plateforme) > Cluster Configuration (Configuration de la grappe) pour connaître l’adresse IP du serveur de configuration et l’adresse IP du collecteur.
-
VIP de capteur est l'adresse IP du serveur de configuration : l’adresse IP qui a été configurée pour le serveur de configuration dans cette grappe.
-
Les adresses IP externes sont destinées aux adresses IP des collecteurs et à l’appareil de mise en application : si ce champ est rempli, lors de l'attribution d'adresses IP de grappe externe, le processus de sélection est limité aux adresses IP définies dans cette liste, qui font partie du réseau externe.
![]() Note |
|
Les connexions à la grappe peuvent être refusées si la charge de travail est derrière un pare-feu, ou si le service de pare-feu de l’hôte est activé. Dans de tels cas, les administrateurs doivent créer des politiques de pare-feu appropriées pour autoriser les connexions.