La politique de découverte de réseau du centre de gestion contrôle la façon dont le système recueille les données sur les ressources réseau de votre entreprise et les segments de réseau et ports à surveiller.

Les politiques de découverte de réseau ne peuvent être configurées que pour les périphériques Cisco Secure Firewall Threat Defense qui envoient des événements à un gestionnaire d’analyse réseau. (Network Analytics Manager est un Cisco Secure Firewall Management Center local configuré pour fournir des analyses d’événements uniquement.)

Dans un déploiement multidomaine, chaque domaine descendant est doté d’une politique de découverte de réseau indépendante. Les règles de découverte de réseau et les autres paramètres ne peuvent pas être partagés, hérités ou copiés entre les domaines. Chaque fois que vous créez un nouveau domaine, le système crée une politique de découverte de réseau pour le nouveau domaine, en utilisant les paramètres par défaut. Vous devez appliquer explicitement les personnalisations souhaitées à la nouvelle politique.

Les règles de découverte de la politique précisent les réseaux et les ports que le système surveille pour générer des données de découverte en fonction des données réseau dans le trafic et des zones dans lesquelles la politique est déployée. Dans une règle, vous pouvez configurer si les hôtes, les applications et les utilisateurs ne faisant pas autorité sont découverts. Vous pouvez créer des règles pour exclure des réseaux et des zones de la découverte. Vous pouvez configurer la découverte des données à partir des exportateurs NetFlow et restreindre les protocoles au trafic dans lequel les données utilisateur sont découvertes sur votre réseau.

La politique de découverte de réseau comporte une seule règle par défaut en place, configurée pour découvrir des applications pour tout le trafic observé. La règle n’exclut aucun réseau, aucune zone ou aucun port; la découverte d’hôte et d’utilisateur n’est pas configurée et la règle n’est pas configurée pour surveiller un exportateur NetFlow. Cette politique est déployée par défaut sur tous les périphériques gérés lorsqu’ils sont enregistrés dans centre de gestion. Pour commencer à collecter des données sur l’hôte ou l’utilisateur, vous devez ajouter ou modifier des règles de découverte et redéployer la politique sur un périphérique.

Si vous souhaitez ajuster la portée de la découverte de réseau, vous pouvez créer des règles de découverte supplémentaires et modifier ou supprimer la règle par défaut.

N’oubliez pas que la politique de contrôle d’accès de chaque périphérique géré définit le trafic que vous autorisez pour cet appareil et, par conséquent, le trafic que vous pouvez surveiller avec la découverte de réseau. Si vous bloquez une partie du trafic à l’aide du contrôle d’accès, le système ne peut pas examiner ce trafic pour détecter l’activité de l’hôte, de l’utilisateur ou de l’application. Par exemple, si une politique de contrôle d’accès bloque l’accès aux applications de réseaux sociaux, le système ne peut fournir aucune donnée de découverte sur ces applications.

Si vous activez la détection d’utilisateurs basée sur le trafic dans vos règles de découverte, vous pouvez détecter les utilisateurs ne faisant pas autorité grâce à l’activité de connexion des utilisateurs dans le trafic sur un ensemble de protocoles d’application. Vous pouvez désactiver la découverte dans des protocoles particuliers pour toutes les règles, le cas échéant. La désactivation de certains protocoles peut aider à éviter d’atteindre la limite d’utilisateurs associée à votre modèle centre de gestion, en réservant le nombre d’utilisateurs disponibles pour les utilisateurs des autres protocoles.

Les paramètres de découverte réseau avancés vous permettent de gérer quelles données sont journalisées, comment les données de découverte sont stockées, quelles règles Indicateurs de compromission (IOC) sont actives, quels mappages de vulnérabilité sont utilisés pour l’évaluation d’impact et ce qui se passe lorsque des sources offrent des données de découverte contradictoires. Vous pouvez également ajouter des sources à surveiller pour l’entrée de l’hôte et les exportateurs NetFlow.

Les informations sur votre trafic réseau collectées par le système Firepower sont plus précieuses pour vous lorsque le système peut corréler ces informations pour identifier les hôtes les plus vulnérables et les plus importants de votre réseau.

Par exemple, si plusieurs périphériques de votre réseau exécutent une version personnalisée de SuSE Linux, le système ne peut pas identifier ce système d’exploitation et ne peut donc pas mapper les vulnérabilités aux hôtes. Cependant, sachant que le système comporte une liste de vulnérabilités pour SuSE Linux, vous pouvez créer une empreinte personnalisée pour l’un des hôtes. Vous pourrez ensuite l’utiliser pour identifier les autres hôtes exécutant le même système d’exploitation. Vous pouvez inclure un mappage de la liste de vulnérabilités pour SuSE Linux dans l’empreinte afin d’associer cette liste à chaque hôte qui correspond à l’empreinte.

Le système vous permet également de saisir des données sur l’hôte de systèmes tiers directement dans la cartographie du réseau, à l’aide de la fonction de saisie de l’hôte. Cependant, les données d’applications ou de systèmes d’exploitation tiers ne sont pas automatiquement mappées aux informations sur les vulnérabilités. Si vous souhaitez afficher les vulnérabilités et effectuer une corrélation des impacts pour les hôtes à l’aide des données du système d’exploitation, du serveur et du protocole d’application tiers, vous devez mapper les informations sur le fournisseur et la version du système tiers avec celles et celles indiquées dans la base de données sur les vulnérabilités. (VDB). Vous pouvez également conserver les données d’entrée de l’hôte sur une base continue. Notez que même si vous mappez des données d’application avec le fournisseur et les définitions de version du système Firepower, les vulnérabilités tierces importées ne sont pas utilisées pour l’évaluation d’impact pour les clients ou les applications Web.

Si le système ne peut pas identifier les protocoles d’application exécutés sur les hôtes de votre réseau, vous pouvez créer des détecteurs de protocoles d’application définis par l’utilisateur qui permettent au système d’identifier les applications en fonction d’un port ou d’un modèle. Vous pouvez également importer, activer et désactiver certains détecteurs d’applications pour personnaliser davantage la capacité de détection d’applications du système Firepower.

Vous pouvez également remplacer la détection du système d’exploitation et des données d’application par les résultats d’analyse de l’analyseur actif Nmap ou élargir les listes de vulnérabilités par des vulnérabilités tierces. Le système peut concilier des données provenant de plusieurs sources afin de déterminer l'identité pour une application.

Les règles de découverte de réseau vous permettent d’adapter les informations découvertes à la cartographie de votre réseau afin d’inclure uniquement les données spécifiques que vous souhaitez. Les règles de votre politique de découverte de réseau sont évaluées dans l’ordre. Vous pouvez créer des règles dont les critères de surveillance se chevauchent, mais cela peut affecter les performances de votre système.

Lorsque vous excluez un hôte ou un réseau de la surveillance, l'hôte ou le réseau ne s'affiche pas dans la cartographie du réseau et aucun événement n'est signalé pour celui-ci. Cependant, lorsque les règles de découverte d’hôte pour l’adresse IP locale sont désactivées, les instances du moteur de détection sont touchées par une charge de traitement plus élevée, car les données de chaque flux sont créées de nouveau au lieu d’utiliser les données de l’hôte existantes.

Nous vous recommandons d’exclure les équilibreurs de charge (ou des ports spécifiques sur les équilibreurs de charge) et les périphériques NAT de la surveillance. Ces périphériques peuvent créer un nombre excessif et trompeur d’événements, remplir la base de données et surcharger centre de gestion. Par exemple, un périphérique NAT surveillé peut présenter plusieurs mises à jour de son système d’exploitation sur une courte période. Si vous connaissez les adresses IP de vos équilibreurs de charge et périphériques NAT, vous pouvez les exclure de la surveillance.

Astuces

Le système peut identifier de nombreux équilibreurs de charge et périphériques NAT en examinant votre trafic réseau.

En outre, si vous devez créer une empreinte de serveur personnalisée, vous devez temporairement exclure de la surveillance l’adresse IP que vous utilisez pour communiquer avec l’hôte à qui vous attribuez des empreintes. Sinon, les affichages de la cartographie du réseau et des événements de découverte seront encombrés d’informations inexactes sur l’hôte représenté par cette adresse IP. Après avoir créé l’empreinte, vous pouvez configurer votre politique pour surveiller à nouveau cette adresse IP.

Cisco recommande également de ne pas surveiller le même segment de réseau avec les exportateurs NetFlow et les périphériques gérés. Bien que, dans l’ idéal , vous devez configurer votre politique de découverte de réseau avec des règles qui ne se chevauchent pas, le système supprime les journaux de connexions en double générés par les périphériques gérés. Cependant, vous ne pouvez pas supprimer les journaux de connexion en double pour les connexions détectées à la fois par un périphérique géré et un exportateur NetFlow.

Avant d’apporter des modifications aux capacités de détection par défaut du système, vous devez analyser les hôtes qui ne sont pas identifiés correctement et les raisons pour lesquelles vous pouvez décider de la solution à mettre en œuvre.

Les systèmes d’exploitation non identifiés ont-ils une pile TCP unique?

Si le système fait une erreur dans l’identification d’un hôte, vous devez rechercher pourquoi l’hôte est mal identifié afin de vous aider à décider entre créer et activer une empreinte personnalisée ou remplacer les données d’entrée de Nmap ou de l’hôte par les données de découverte.

Mise en garde

Si vous rencontrez des hôtes mal identifiés, contactez votre représentant du soutien avant de créer des empreintes personnalisées.

Si un hôte exécute un système d’exploitation qui n’est pas détecté par le système par défaut et ne partage pas les caractéristiques d’identification de la pile TCP avec les systèmes d’exploitation existants détectés, vous devez créer une empreinte personnalisée.

Par exemple, si vous avez une version personnalisée de Linux avec une pile TCP unique que le système ne peut pas identifier, vous auriez avantage à créer une empreinte personnalisée, qui permet au système d’identifier l’hôte et de continuer au surveiller, plutôt que d’utiliser les résultats d’analyse ou données de tiers, ce qui nécessite une mise à jour active et continue des données.

Notez que de nombreuses distributions Linux à code source libre utilisent le même noyau et que, par conséquent, le système les identifie à l’aide du nom du noyau Linux. Si vous créez une empreinte personnalisée pour un système Red Hat Linux, il se peut que d'autres systèmes d'exploitation (tels que Debian Linux, Mandrake Linux, Knoppix, etc.) soient identifiés comme étant Red Hat Linux, car la même empreinte correspond à plusieurs distributions Linux.

Vous ne devriez pas utiliser une empreinte dans toutes les situations. Par exemple, une modification peut avoir été apportée à la pile TCP d’un hôte de sorte qu’elle ressemble ou soit identique à un autre système d’exploitation. Par exemple, un hôte Apple Mac OS X est modifié, rendant son empreinte identique à celle d’un hôte Linux 2.4, ce qui fait que le système l’identifie comme Linux 2.4 au lieu de Mac OS X. Si vous créez une empreinte personnalisée pour l’hôte Mac OS X, cela peut entraîner l’identification à erreur de tous les hôtes Linux 2.4 légitimes comme des hôtes Mac OS X. Dans ce cas, si Nmap identifie correctement l’hôte, vous pouvez planifier des analyses Nmap régulières pour cet hôte.

Si vous importez des données d’un système tiers à l’aide de l’entrée de l’hôte, vous devez mapper les chaînes de fournisseur, de produit et de version que le tiers utilise pour décrire les serveurs et les protocoles d’application aux définitions Cisco pour ces produits. Notez que même si vous mappez des données d’application avec le fournisseur et les définitions de version du système Firepower, les vulnérabilités tierces importées ne sont pas utilisées pour l’évaluation d’impact pour les clients ou les applications Web.

Le système peut concilier des données provenant de plusieurs sources afin de déterminer l’identité actuelle pour un système d’exploitation ou une application.

Pour les données Nmap, vous pouvez planifier des analyses Nmap régulières. Pour les données d’entrée de l’hôte, vous pouvez exécuter régulièrement le script Perl pour l’importation ou l’utilitaire de ligne de commande. Cependant, notez que les données d’analyse active et les données d’entrée de l’hôte peuvent ne pas être mises à jour avec la fréquence des données de découverte.