À propos du déploiement de la configuration
Toute la configuration des périphériques est gérée par centre de gestion, puis déployées sur les périphériques gérés.
Modifications de la configuration qui nécessitent un déploiement
Le système signale les politiques périmées par un texte d'état rouge qui indique le nombre de périphériques ciblés nécessitant une mise à jour de la politique. Pour effacer cet état, vous devez redéployer la politique sur les périphériques.
Déploiement nécessaire
Voici les modifications de configuration qui nécessitent un déploiement :
-
La modification d'une politique de contrôle d'accès : toute modification apportée aux règles de contrôle d'accès, à l'action par défaut, aux cibles de la politique, au filtrage Security Intelligence, aux options avancées, y compris le prétraitement, etc.
-
La modification de toute politique appelée par la politique de contrôle d’accès : la politique SSL, les politiques d’analyse de réseau, les politiques de prévention des intrusions, les politiques de fichiers, les politiques d’identité ou les politiques DNS.
-
La modification de tout objet réutilisable ou de toute configuration utilisée dans une politique de contrôle d’accès ou des politiques de contrôle d’accès appelées :
-
les objets de réseau, de port, de balise VLAN, d'URL et de géolocalisation
-
Listes er flux de renseignements sur la sécurité
-
filtres ou détecteurs d'application
-
ensembles de variables de la politique de prévention des intrusions
-
listes de fichiers
-
les objets liés au déchiffrement et aux zones de sécurité;
-
-
Mise à jour du logiciel système, des règles de prévention des intrusions ou de la base de données de vulnérabilités (VDB).
Gardez à l’esprit que vous pouvez modifier certaines de ces configurations à partir de plusieurs endroits de l’interface Web. Par exemple, vous pouvez modifier des zones de sécurité à l’aide du gestionnaire d’objets (), mais la modification d’un type d’interface dans la configuration d’un périphérique () peut également modifier une zone et nécessiter un déploiement.
Déploiement non nécessaire
Notez que les mises à jour suivantes ne nécessitent pas de déploiement :
-
mises à jour automatiques des flux de renseignements sur la sécurité et des ajouts à la liste globale de blocage ou de non-blocage des renseignements sur la sécurité à l'aide du menu contextuel.
-
mises à jour automatiques des données de filtrage d’URL
-
mises à jour planifiées de la base de données de géolocalisation (GeoDB)
Aperçu du déploiement
L'aperçu présente un résumé de tous les changements de politique et d'objet qui doivent être déployés sur le périphérique. Les changements de politique comprennent les nouvelles politiques, les changements apportés aux politiques existantes et les politiques supprimées. Les changements apportés aux objets incluent les objets ajoutés et modifiés qui sont utilisés dans les politiques. Les changements apportés aux objets inutilisés ne sont pas affichés, car ils ne sont pas déployés sur le périphérique.
L'aperçu affiche toutes les valeurs par défaut, même lorsqu'elles ne sont pas modifiées, aux côtés des autres paramètres configurés lorsqu'une interface ou une politique de paramètres de plateforme est ajoutée pour la première fois. De même, les politiques relatives à la haute disponibilité et les valeurs par défaut des paramètres sont affichées, même si elles ne sont pas modifiées, dans le premier aperçu après la configuration ou la perturbation d’une paire à haute disponibilité.
Pour afficher les modifications dues à une restauration automatique, consultez Modifier les paramètres de déploiement.
Fonctionnalités non prises en charge
-
Les ajouts d’objets et les changements d’attributs ne sont affichés dans l’aperçu que si les objets sont associés à un périphérique ou à une interface. Les suppressions d’objets ne sont pas affichées.
-
L'aperçu n'est pas pris en charge pour les politiques suivantes :
-
Haute disponibilité
-
Détection du réseau
-
Analyse du réseau
-
Paramètres de l’appareil
-
-
Les renseignements sur les utilisateurs au niveau de la règle ne sont pas disponibles pour les politiques en lien avec la prévention des intrusions.
-
L'aperçu n'affiche pas la réorganisation des règles entre les politiques.
Pour les politiques DNS, les règles réorganisées apparaissent dans la liste d'aperçu sous la forme d'ajouts et de suppressions de règles. Par exemple, le déplacement d’une règle de la position 1 à la position 3 dans l’ordre des règles s’affiche comme si la règle était supprimée de la position 1 et ajoutée en tant que nouvelle règle à la position 3. De même, lorsqu'une règle est supprimée, les règles afférentes sont répertoriées comme règles modifiées, car leurs positions ont été modifiées. Les modifications sont affichées dans l’ordre final dans lequel elles apparaissent dans la politique.
-
La prévisualisation n'est pas prise en charge dans les scénarios de haute disponibilité suivants :
-
Si un périphérique était en mode autonome et si une chaîne est réalisée, un déploiement automatique est déclenché. Pour cette tâche en particulier, la prévisualisation n’est pas prise en charge. Lorsque vous passez le curseur sur le Aperçu (), un message indique qu’il s’agit d’un déploiement de démarrage à haute disponibilité et qu’aucun aperçu n’est pris en charge.
-
Groupes de configuration : Prenons l'exemple d'un flux dans lequel un périphérique est initialement autonome. Par la suite, trois déploiements ont eu lieu. Lors du quatrième déploiement, le périphérique était un déploiement de démarrage en mode haute disponibilité (HA bootstrap). Ensuite, l’utilisateur déploie les périphériques 5, 6 et 7. Le déploiement 7 est un déploiement avec rupture de la haute disponibilité, et l’utilisateur déploie les périphériques 8, 9 et 10.
Dans ce flux, l’aperçu entre 3 et 5 n’est pas pris en charge, car la valeur 4 était un déploiement de haute disponibilité. De même, l’aperçu entre 8 et 3 n’est pas non plus pris en charge. L’aperçu est pris en charge uniquement pour les versions 3 à 1, 7,6, 5, 4 et 10, 9 et 8.
-
Si un périphérique est défectueux (la haute disponibilité est défectueuse), le nouveau périphérique est considéré comme un tout nouveau périphérique.
-
Déploiement sélectif des politiques
Le centre de gestion vous permet de sélectionner une politique particulière dans la liste de toutes les modifications sur le périphérique qui doivent être déployées et de déployer uniquement la politique sélectionnée. Le déploiement sélectif est disponible uniquement pour les politiques suivantes :
-
Politiques de contrôle d’accès
-
Politique de prévention des intrusions
-
Politiques relatives aux fichiers et aux logiciels malveillants
-
Politiques DNS
-
Politiques d’identité
-
Politiques SSL
-
Politiques de QOS
-
Règles du préfiltre
-
Détection du réseau
-
Politiques NAT
-
Politiques de routage
-
Politiques VPN
Il y a certaines limites au déploiement sélectif des politiques. Suivez le contenu du tableau ci-dessous pour comprendre quand le déploiement sélectif des politiques peut être utilisé.
Type |
Description |
Scénarios |
---|---|---|
Déploiement complet |
Le déploiement complet est nécessaire pour des scénarios de déploiement particuliers, et le centre de gestionne prend pas en charge le déploiement sélectif dans de tels scénarios. Si vous rencontrez une erreur dans de tels scénarios, vous pouvez choisir de continuer en sélectionnant toutes les modifications à déployer sur le périphérique. |
Les scénarios dans lesquels un déploiement complet est requis sont les suivants :
|
Déploiement connexe de politiques |
Le centre de gestion détermine les politiques interdépendantes qui sont liées entre elles. Lorsqu'une des politiques interconnectées est sélectionnée, les politiques interconnectées restantes sont automatiquement sélectionnées. |
Scénarios dans lesquels une politique associée est automatiquement sélectionnée :
Scénarios dans lesquels plusieurs politiques sont automatiquement sélectionnées :
|
Modifications de politique interdépendantes (affichées à l’aide de balises à code de couleur) |
Le centre de gestion détecte dynamiquement les dépendances entre les politiques, et entre les objets partagés et les politiques. L’interdépendance des objets ou des politiques est indiquée à l’aide de balises de couleur. |
Scénarios dans lesquels des politiques ou objets interdépendants codés par couleur sont automatiquement sélectionnés :
|
Spécifications du groupe de politiques d’accès |
Les politiques du groupe de politiques d’accès sont répertoriées dans la fenêtre d’aperçu sous Access Policy Group (groupe de politiques d’accès) lorsque vous cliquez sur Afficher ou masquer la politique (). |
Les scénarios et le comportement attendu des politiques de groupe de politiques d’accès sont les suivants :
|
Nom d’utilisateur du système
Le centre de gestion présente le nom d'utilisateur en tant que système pour les opérations suivantes :
-
Restauration
-
Mise à jour
-
Défense contre les menaces Sauvegarde et restauration
-
Mise à jour de la SRU
-
Mise à jour du LSP
-
Mise à jour de la VDB
Détecteurs d’application à activation automatique
Si vous effectuez un contrôle des applications, mais désactivez les détecteurs requis, le système activera automatiquement les détecteurs appropriés fournis par le système lors du déploiement de la politique. S'il n'y en a pas, le système activera le détecteur défini par l'utilisateur le plus récemment modifié pour l'application.
Redécouverte des ressources à la suite de modifications apportées à une politique de découverte du réseau
Lorsque vous déployez des modifications apportées à une politique de découverte de réseau, le système supprime puis redécouvre les informations d’adresse MAC, de durée de vie et de sauts sur la carte réseau pour les hôtes de vos réseaux surveillés. En outre, les périphériques gérés rejettent toutes les données de découverte qui n’ont pas encore été envoyées au centre de gestion.
Scénarios de redémarrage de Snort
Lorsque le moteur d’inspection du trafic appelé processus Snort redémarre, l’inspection est interrompue jusqu’à la reprise du processus. Pendant cette interruption, la diminution de trafic ou son passage sans inspection dépend de la façon dont l’appareil cible gère le trafic. Consultez Comportement du trafic au redémarrage de Snort pour obtenir de plus amples renseignements. En outre, les demandes de ressources peuvent entraîner l'abandon d'un petit nombre de paquets sans inspection lors du déploiement, que le processus Snort soit redémarré ou non.
N’importe lequel des scénarios présentés dans le tableau suivant entraîne le redémarrage du processus Snort.
Scénario de redémarrage |
Autres renseignements |
---|---|
Déploiement d’une configuration spécifique nécessitant le redémarrage du processus Snort. |
Configurations qui redémarrent le processus Snort lors de leur déploiement ou activation |
la modification d’une configuration qui redémarre immédiatement le processus Snort. |
Modifications qui redémarrent immédiatement le processus Snort |
Activation du trafic de la configuration de contournement automatique des applications (AAB) actuellement déployée. |
|
Activation ou désactivation de la fonction « Journalisation des événements de connexion sur le disque RAM ». |
Consultez la section Log to Ramdisk (Journaliser sur la RAM) dans le dépannage du vidage des événements non traités de FMC. |
Redémarrer les avertissements pour les appareils
Lorsque vous effectuez un déploiement, la colonne Inspect Interruption interruption de l'inspection) de la boîte de dialogue de déploiement indique si une configuration déployée redémarre le processus Snort sur l'appareil défense contre les menaces . Lorsque le moteur d’inspection du trafic appelé processus Snort redémarre, l’inspection est interrompue jusqu’à la reprise du processus. L’interruption du trafic ou son passage sans inspection dépend de la gestion du trafic au niveau de l‘appareil. Notez que vous pouvez procéder au déploiement, annuler le déploiement et modifier la configuration ou reporter le déploiement à un moment où le déploiement aurait le moins d’impact sur votre réseau.
Lorsque la colonne Inspect Interruption (inspecter l’interruption) indique Yes (oui) et que vous développez la liste de configuration du périphérique, le système indique tout type de configuration spécifique qui redémarrerait le processus Snort avec Inspecter interruption (). Lorsque vous passez la souris sur l’icône, un message vous informe que le déploiement de la configuration peut interrompre le trafic.
Le tableau suivant résume l’affichage des avertissements d’interruption d’inspection dans la page du déploiement.
Type |
Inspecter l'interruption |
Description |
---|---|---|
Défense contre les menaces |
Inspecter interruption ()Oui |
Au moins une configuration interromprait l’inspection de l’appareil si elle était déployée; elle pourrait aussi interrompre le trafic, selon la façon dont l’appareil gère le trafic. Vous pouvez développer la liste de configuration du périphérique pour obtenir plus d'informations. |
-- |
Les configurations déployées n’interrompent pas le trafic sur l’appareil. |
|
Indéterminé |
Le système ne peut pas déterminer si une configuration déployée est susceptible d’interrompre le trafic sur le périphérique. Un état indéterminé s’affiche avant le premier déploiement, après une mise à niveau logicielle, ou, dans certains cas, lors d’un appel d’assistance. |
|
Erreurs () |
Le système ne peut pas déterminer l’état en raison d’une erreur interne. Annulez l’opération et cliquez à nouveau sur Deploy (déployer) pour permettre au système de déterminer à nouveau l’état en lien avec Inspect Interruption. Si le problème persiste, communiquez avec le service d’assistance. |
|
capteur |
-- |
L'appareil déterminé comme capteur n'est pas l'appareil défense contre les menaces ; le système ne détermine pas si une configuration déployée peut interrompre le trafic sur cet appareil. |
Pour en savoir plus sur toutes les configurations qui redémarrent le processus Snort pour tous les types d’appareils, consultez Configurations qui redémarrent le processus Snort lors de leur déploiement ou activation.
Inspecter le trafic pendant l’application de la stratégie
L’inspection du trafic pendant l’application de la politique est un paramètre général de contrôle d’accès avancé qui permet aux périphériques gérés d’inspecter le trafic tout en déployant des modifications de configuration. c’est le cas, sauf si une configuration que vous déployez nécessite le redémarrage du processus Snort. Vous pouvez configurer les options suivantes :
-
Activé : le trafic est inspecté pendant le déploiement, sauf si certaines configurations nécessitent le redémarrage du processus Snort.
Lorsque les configurations que vous déployez ne nécessitent pas de redémarrage Snort, le système utilise initialement la politique de contrôle d’accès actuellement déployée pour inspecter le trafic et bascule pendant le déploiement vers la politique de contrôle d’accès que vous déployez.
-
Désactivé : le trafic n’est pas inspecté pendant le déploiement. Le processus Snort redémarre toujours lorsque vous déployez.
Le graphique suivant illustre comment les redémarrages Snort peuvent se produire lorsque vous activez ou désactivez le trafic d’inspection pendant l’application de la politique.
Mise en garde |
Lorsque vous déployez, les demandes de ressources peuvent entraîner l’abandon un petit nombre de paquets sans inspection. En outre, le déploiement de certaines configurations redémarre le processus Snort, qui interrompt l’inspection du trafic. Pendant cette interruption, la diminution de trafic ou son passage sans inspection dépend de la façon dont l’appareil cible gère le trafic. Voir Comportement du trafic au redémarrage de Snort et Configurations qui redémarrent le processus Snort lors de leur déploiement ou activation. |
Comportement du trafic au redémarrage de Snort
Les tableaux suivants expliquent comment différents appareils gèrent le trafic au redémarrage du processus Snort.
Configuration de l’interface |
Comportement du trafic au redémarrage |
---|---|
en ligne : Snort Fail Open: Down (admission même en cas de non-conformité de Snort : inactif) : désactivée |
abandonné |
en ligne : Snort Fail Open: Down (admission même en cas de non-conformité de Snort : inactif) : activés |
réussi sans inspection Certains paquets peuvent être retardés dans la mémoire tampon pendant plusieurs secondes avant que le système ne reconnaisse que Snort est en panne. Ce délai peut varier en fonction de la répartition de la charge. Cependant, les paquets mis en mémoire tampon finissent par être transmis. |
routé, transparent (y compris EtherChannel, redondant, sous-interface) lorsque preserve-connection est activé (configure snort preserve-connection enable ; réglage par défaut) Pour en savoir plus, consultez Référence des commandes de défense contre les menaces de Cisco Secure Firewall. |
flux TCP/UDP existants : transmis sans inspection tant qu’au moins un paquet arrive alors que Snort est inactif flux TCP/UDP nouveaux et tous les flux qui ne font pas partie des protocoles TCP/UDP : abandon Signalons que trafic suivant est abandonné même lorsque l’option preserve-connection est activée :
|
routé, transparent (y compris EtherChannel, redondant, sous-interface) : option preserve-connection désactivée (configure snort preserve-connection disable ) |
abandonné |
en ligne : tap mode (mode Tap) |
paquet de sortie immédiatement, copie contourne Snort |
passif |
sans interruption, sans inspection |
Remarque |
Outre la gestion du trafic lorsque le processus Snort est arrêté pendant qu'il redémarre, le trafic peut également passer sans inspection ou être abandonné lorsque le processus Snort est occupé, selon la configuration de l'option Snort Fail Open (non-conformité de Snort) Busy (occupé) (voir Configurer un ensemble en ligne). Un périphérique prend en charge l’option Failsafe ou Snort Fail Open, mais pas les deux. |
Remarque |
Lorsque le processus Snort est occupé, mais pas arrêté pendant le déploiement de la configuration, certains paquets peuvent être abandonnés sur les interfaces routées, commutées ou transparentes si la charge totale du CPU dépasse 60 %. |
Avertissement |
Ne redémarrez pas le système pendant que la mise à niveau de la règle Snort est en cours. |
Les abandons Snort-busy se produisent lorsque Snort n'est pas en mesure de traiter les paquets assez rapidement. Lina ne sait pas si Snort est occupé en raison d'un retard de traitement, ou s'il est bloqué ou en raison d'un blocage d'appel. Lorsque la file d'attente de transmission est pleine, des abandons Snort-busy se produisent. En fonction de l’utilisation de la file d’attente de transmission, Lina tentera d’accéder si la file d’attente est traitée correctement.
Configurations qui redémarrent le processus Snort lors de leur déploiement ou activation
Le déploiement de l'une des configurations suivantes, à l'exception de l'AAB, redémarre le processus Snort, comme décrit précédemment. Le déploiement d'AAB n'entraîne pas de redémarrage, mais une latence excessive des paquets active la configuration AAB actuellement déployée, entraînant un redémarrage partiel du processus Snort.
Paramètres avancés de politique de contrôle d’accès
-
Procédez au déploiement lorsque l’option Inspect Traffic During Policy Apply (inspection du trafic pendant l’application de la politique) est désactivée.
-
Ajoutez ou supprimez une politique SSL.
Politique de fichier
Déployez la première ou la dernière des configurations suivantes : vous observerez que même si le déploiement de ces configurations de politique de fichiers n’entraîne pas de redémarrage, le déploiement de configurations sans politique de fichier peut entraîner des redémarrages.
-
Prenez l'une des mesures suivantes :
-
Activez ou désactivez Inspect Archives lorsque la politique de contrôle d’accès déployée comprend au moins une politique de fichiers.
-
Ajoutez la première ou supprimez la dernière règle de politique de fichier lorsque l’inspection des archives (Inspect Archives) est activée (notez qu’au moins une règle est nécessaire pour que l’inspection des archives ait un sens).
-
-
Activez ou désactivez Store files (stocker des fichiers) dans une règle de détection de fichiers (Detect Files) ou de blocage de fichiers (Block Files).
-
Ajoutez la première ou supprimez la dernière règle de fichier active qui combine l’action de règle de recherche de logiciels malveillants dans le nuage ( Malware Cloud Lookup) ou de blocage de logiciels malveillants (Block Malware) avec une option d’analyse (Spero Analysis ou MSEXE, Dynamic Analysis, ou encore Local Malware Analysis) ou une option de stockage de fichiers (Malware pour les programmes malveillants, Unknown pour les fichiers inconnus, Clean pour les fichiers fiables ou Custom pour un stockage personnalisé).
Notez que les règles de contrôle d’accès qui déploient ces configurations de politiques de fichiers vers des zones de sécurité ou des zones de tunnel engendrent un redémarrage uniquement lorsque votre configuration remplit les conditions suivantes :
-
Les zones de sécurité source ou de destination dans votre règle de contrôle d’accès doivent correspondre aux zones de sécurité associées aux interfaces sur les appareils cibles.
-
À moins que la zone de destination de votre règle de contrôle d’accès ne soit définie sur any (n’importe laquelle), une zone de tunnel source dans la règle doit correspondre à une zone de tunnel affectée à une règle de tunnel dans la politique de préfiltre.
Politique d’identité
-
Lorsque le déchiffrement SSL est désactivé (c’est-à-dire lorsque la politique de contrôle d’accès n’inclut pas de politique SSL), ajoutez la première ou supprimez la dernière règle d’authentification active.
Une règle d'authentification active comporte soit une action de règle d'authentification active (Active Authentication), soit une action de règle d'authentification passive (Passive Authentication) dont l’option Use active authentication if passive or VPN identity cannot be established (utiliser l'authentification active si l'identité passive ou VPN ne peut pas être établie) est sélectionnée.
Détection du réseau
-
Activez ou désactivez la détection d’utilisateur basée sur le trafic non autorisée sur les protocoles HTTP, FTP ou MDNS, en utilisant la politique de découverte de réseau.
Gestion des périphériques
-
MTU : Modifiez la valeur MTU la plus élevée parmi toutes les interfaces qui ne sont pas des interface de gestion sur un périphérique.
-
Automatic Application Bypass (AAB): La configuration AAB actuellement déployée s’active lorsqu'un dysfonctionnement du processus Snort ou une mauvaise configuration de l’appareil entraîne un temps de traitement excessif pour un seul paquet. Le résultat est un redémarrage partiel du processus Snort pour réduire la latence extrêmement élevée ou empêcher un blocage complet du trafic. Ce redémarrage partiel entraîne le passage de quelques paquets sans inspection, ou leur abandon, selon la configuration de la gestion du trafic sur l’appareil.
Mises à jour
-
Mise à jour du système : Déployez les configurations la première fois après une mise à jour logicielle qui comprend une nouvelle version du processus binaire Snort ou de la bibliothèque d’acquisition de données (DAQ).
-
VDB : Pour les appareils gérés exécutant Snort 2, le déploiement de configurations la première fois après l’installation d’une mise à jour de base de données de vulnérabilités (VDB) qui inclut des modifications applicables aux appareils gérés nécessitera un redémarrage du moteur de détection et pourrait entraîner une interruption temporaire du trafic. Pour ces derniers, un message vous avertit lorsque vous sélectionnez le centre de gestion pour commencer l'installation. Le dialogue de déploiement fournit des avertissements supplémentaires pour les défense contre les menaces appareils lorsque des modifications de la VDB sont en attente. Les mises à jour de la VDB qui s'appliquent uniquement à la centre de gestion ne provoquent pas de redémarrage du moteur de détection, et vous ne pouvez pas les déployer.
Pour les appareils gérés exécutant Snort 3, le déploiement des configurations la première fois après l’installation d’une mise à jour de la base de données de vulnérabilités (VDB) peut interrompre temporairement la détection des applications, mais il n’y aura aucune interruption de trafic.
Modifications qui redémarrent immédiatement le processus Snort
Les modifications suivantes redémarrent immédiatement le processus Snort sans passer par le processus de déploiement. La façon dont le redémarrage influe sur le trafic dépend de la façon dont le périphérique cible gère le trafic. Consultez Comportement du trafic au redémarrage de Snort pour obtenir de plus amples renseignements.
-
Effectuez l'une des actions suivantes concernant les applications ou les détecteurs d'applications :
-
Activer ou désactiver un détecteur de système ou d’application personnalisée.
-
Supprimer un détecteur personnalisé activé.
-
Enregistrer et réactiver un détecteur personnalisé activé.
-
Créer une application définie par l’utilisateur
Un message vous avertit de la poursuite du redémarrage du processus Snort et vous permet de l'annuler; le redémarrage se produit sur tout périphérique géré dans le domaine actuel ou dans l’un de ses domaines enfants.
-
-
Créer ou rompre une paire défense contre les menaces à haute disponibilité
Un message vous avertit que la poursuite de la création d’une paire à haute disponibilité redémarre le processus Snort sur les périphériques principal et secondaire et vous permet de l’annuler.