Sécurité : Cisco Firepower Management Center

Dépannez les questions avec le Filtrage URL sur le système de FireSIGHT

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

La caractéristique de Filtrage URL au centre de Gestion de FireSIGHT classe le trafic des hôtes surveillés, et te permet par catégorie pour écrire une condition dans une règle de contrôle d'accès basée sur la réputation. Ce document décrit des problèmes courants avec le Filtrage URL.

Contribué par Nazmul Rajib, ingénieur TAC Cisco.

Processus de recherche de Filtrage URL

Problèmes de connectivité de nuage

Étape 1 : Vérifiez les permis

Le permis est-il installé ?

Vous pouvez ajouter la catégorie et les conditions basées sur réputation URL aux règles de contrôle d'accès sans Filtrage URL autorisent, toutefois vous ne pouvez pas appliquer la stratégie de contrôle d'accès jusqu'à ce que vous ajoutiez d'abord un permis de Filtrage URL au centre de Gestion de FireSIGHT, puis l'activez sur les périphériques visés par la stratégie.

Le permis est-il expiré ?

Si un permis de Filtrage URL expire, le contrôle d'accès ordonne avec la catégorie et les états basés sur réputation URL cessent de filtrer l'URLs, et le centre de Gestion de FireSIGHT ne contacte plus le service en nuage.

Conseil : Lisez ce document pour apprendre comment activer la caractéristique de Filtrage URL sur un système de FireSIGHT, et appliquez le permis de Filtrage URL sur un périphérique géré.

Étape 2 : Alertes de santés de contrôle

Les transmissions de pistes de module de moniteur de Filtrage URL entre le centre de Gestion de FireSIGHT et le Cisco opacifient, où le système obtient ses données de Filtrage URL (catégorie et réputation) pour l'URLs généralement visité. Le module de moniteur de Filtrage URL dépiste également des transmissions entre un centre de Gestion de FireSIGHT et tous les périphériques gérés où vous avez activé le Filtrage URL. 

Afin d'activer le Filtrage URL surveillez le module, vont à la page de configuration de politique de santés, moniteur choisi de Filtrage URL. Sélectionnez en fonction pour que l'option activée active l'utilisation du module pour le test d'état de santés. Vous devez s'appliquer la politique sanitaire au centre de Gestion de FireSIGHT si vous voulez que vos configurations les prennent effet.

  • Alerte essentielle : Si le centre de Gestion de FireSIGHT ne communique pas avec succès avec ou ne récupère pas une mise à jour du nuage, la classification d'état pour des modifications de ce module à essentiel.
  • Alerte d'avertissement : Si le centre de Gestion de FireSIGHT communique avec succès avec le nuage, les changements d'état de module à avertir si le centre de Gestion ne peut pas pousser de nouvelles données de Filtrage URL à ses périphériques gérés.

Étape 3 : Configurations de DN de contrôle

Un centre de Gestion de FireSIGHT communique avec les serveurs suivants pendant la consultation de nuage :

database.brightcloud.com
service.brightcloud.com

Une fois que vous vous assurez que les deux serveurs sont permis sur le Pare-feu, exécutez les commandes suivantes au centre de Gestion de FireSIGHT et les vérifiez si le centre de Gestion peut résoudre les cnames :

admin@FireSIGHT:~$ sudo nslookup database.brightcloud.com
admin@FireSIGHT:~$ sudo nslookup service.brightcloud.com

Étape 4 : Connectivité de contrôle aux ports requis

Les systèmes de FireSIGHT emploient les ports 443/HTTPS et 80/HTTP pour communiquer avec le service en nuage.

Une fois que vous confirmez que le centre de Gestion peut exécuter un nslookup réussi, vérifiez la Connectivité au port 80 et au port 443 utilisant le telnet.

telnet database.brightcloud.com 80
telnet database.brightcloud.com 443

telnet service.brightcloud.com 80
telnet service.brightcloud.com 443

La sortie suivante est un exemple d'une connexion réussie de telnet à database.brightcloud.com.

Connected to database.brightcloud.com.
Escape character is '^]'.

Contrôle d'accès et questions de Miscategorization

Problème 1 : L'URL avec le niveau non sélectionné de réputation est permis/bloqué

Si vous notez un URL est permis ou bloqué, mais vous n'avez pas sélectionné le niveau de réputation de cet URL dans votre règle de contrôle d'accès, lisez la section suivante pour comprendre comment effectue des travaux d'une règle de Filtrage URL.

L'action de règle est laissent

Quand vous créez une règle de permettre le trafic basé sur un niveau de réputation, sélectionner un niveau de réputation sélectionne également tous les niveaux de réputation moins sécurisé que le niveau que vous avez initialement sélectionné. Par exemple, si vous configurez une règle de permettre les sites bénins avec des risques de sécurité (niveau 3), il permet également automatiquement les sites bénins (niveau 4) et réputé (des sites de niveau 5).

L'action de règle est bloc

Quand vous créez une règle de bloquer le trafic basé sur un niveau de réputation, sélectionner un niveau de réputation sélectionne également tous les niveaux de réputation plus graves que le niveau que vous avez initialement sélectionné. Par exemple, si vous configurez une règle de bloquer les sites bénins avec des risques de sécurité (niveau 3), il bloque également automatiquement les sites méfiants (niveau 2) et risque fort (sites de niveau 1). 

Matrice de sélection URL

Niveau sélectionné de réputationAction sélectionnée de règle
Risque fortSite méfiant

Site bénin avec le risque de sécurité

Site béninRéputé
1 - Risque fortLe bloc, laissentLaissezLaissezLaissezLaissez
2 - Sites méfiantsBlocLe bloc, laissentLaissezLaissezLaissez
3 - Sites bénins avec le risque de sécuritéBlocBlocLe bloc, laissentLaissezLaissez
4 - Sites béninsBlocBlocBlocLe bloc, laissentLaissez
5 - RéputéBlocBlocBlocBlocLe bloc, laissent

Problème 2 : Le masque ne fonctionne pas dans la règle de contrôle d'accès

Le système de FireSIGHT ne prend en charge pas spécifier le masque en état URL. La condition suivante peut pour alerter sur cisco.com.


*cisco*.com
En outre, un URL inachevé peut s'assortir contre l'autre trafic entraînant un résultat peu désiré. Quand spécifier l'URLs individuel dans l'URL conditionne, vous doit soigneusement considérer l'autre trafic qui pourrait être affecté. Par exemple, considérez un scénario où vous voulez bloquer explicitement cisco.com. Cependant, apparier de sous-chaîne signifie que cela le blocage de cisco.com bloque également sanfrancisco.com, qui ne pourrait pas être votre intention.

En écrivant un URL, écrivez le nom de domaine et omettez les informations de sous-domaine. Par exemple, type cisco.com plutôt que www.cisco.com. En utilisant cisco.com dans une règle d'autoriser, les utilisateurs pourraient parcourir à l'un des après URLs :

http://cisco.com
http://cisco.com/newcisco
http://www.cisco.com

Problème 3 : La catégorie et la réputation URL ne sont pas remplies

Si un URL n'est pas dans la base de données locale et c'est la première fois l'URL est vu dans le trafic, une catégorie ou une réputation ne peut être remplie. Parfois les consultations URL pour l'URLs généralement visité peuvent ne pas les résoudre à la première fois qu'un URL est vu. Cette question est réparée sur la version 5.3.0.3, 5.3.1.2, et 5.4.0.2, 5.4.1.1.

Document connexe


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118852