Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Filtrage des URL

Présentation du filtrage d’URL

Vous pouvez utiliser le filtrage d’URL pour déterminer quel contenu Web n’est pas accessible aux utilisateurs.

Les composants de cette fonctionnalité sont les suivants :

  • Fichier de base de données de filtre d’URL

  • Configuration d’un ou plusieurs modèles (jusqu’à huit par profil)

  • Plug-in de filtre d’URL (jservices-urlf)

  • démon de filtrage d’URL (url-filterd)

Le fichier de base de données de filtre d’URL est stocké sur le moteur de routage et contient toutes les URL non autorisées. Les modèles configurés définissent le trafic à surveiller, les critères à appliquer et les actions à entreprendre. Vous configurez les modèles et l’emplacement du fichier de base de données de filtre d’URL dans un profil.

À partir de Junos OS version 17.2R2 et 17.4R1, pour Adaptive Services, vous pouvez désactiver le filtrage du trafic HTTP qui contient une adresse IP incorporée (par exemple, http :/10.1.1.1) appartenant à un nom de domaine non autorisé dans la base de données de filtrage d’URL. À partir de la version 19.3R2 de Junos OS, cette même fonctionnalité est prise en charge pour les services de nouvelle génération sur MX240, MX480 et MX960.

Pour activer la fonctionnalité de filtrage d’URL, vous devez la configurer jservices-urlf au niveau de package-name la [edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] hiérarchie. Une fois activé, jservices-urlf maintient le profil de filtrage des URL et reçoit tout le trafic à filtrer, les critères de filtrage et l’action à effectuer sur le trafic filtré.

Note:

MX-SPC3 n’a pas besoin jservices-urlf explicitement d’être utilisé package-name au niveau de la [edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] hiérarchie. Il est pris en charge par défaut.

Le démon de filtrage d’URL (url-filterd), qui réside également sur le moteur de routage, résout le nom de domaine de chaque URL dans la base de données de filtrage d’URL en une liste d’adresses IPv4 et IPv6. Il télécharge ensuite la liste des adresses IP dans le PIC du service, qui exécute jservices-urlf. Ensuite, l’URL filtrée interagit avec le processus de pare-feu dynamique (dfwd) pour installer des filtres sur le moteur de transfert de paquets afin de transférer le trafic sélectionné du moteur de transfert de paquets au PIC de service.

Lorsque du nouveau trafic HTTP et HTTPS atteint le routeur, une décision est prise en fonction des informations contenues dans le fichier de base de données de filtre d’URL. Les règles de filtrage sont vérifiées et le routeur accepte le trafic et le transmet, ou le bloque. Si le trafic est bloqué, l’une des actions configurées suivantes est effectuée :

  • Une redirection HTTP est envoyée à l’utilisateur.

  • Une page personnalisée est envoyée à l’utilisateur.

  • Un code d’état HTTP est envoyé à l’utilisateur.

  • Une réinitialisation TCP est envoyée.

Accepter est également une option. Dans ce cas, le trafic n’est pas bloqué.

La figure 1 illustre le filtrage des URL pour les sessions HTTP.

Figure 1 : filtrage des URL de flux de paquets pour les sessions Packet Flow-URL Filtering for HTTP Sessions HTTP

La figure 2 illustre le filtrage des URL pour les sessions HTTPS.

Figure 2 : filtrage des URL de flux de paquets pour les sessions Packet Flow-URL Filtering for HTTPS Sessions HTTPS

Pour plus d’informations sur la fonctionnalité de filtrage d’URL, consultez les sections suivantes :

Fichier de base de données de filtre d’URL

Le fichier de base de données de filtre d’URL contient des entrées d’URL et d’adresses IP. Créez le fichier de base de données de filtre d’URL au format indiqué dans le Tableau 1 et localisez-le sur le moteur de routage dans le répertoire /var/db/url-filterd .

Tableau 1 : format de fichier de la base de données de filtre d’URL

Entrée

Description

Exemple

FQDN

Nom de domaine complet.

www.badword.com/jjj/bad.jpg

URL

URL de chaîne complète sans le protocole de couche 7.

www.srch.com/*gros mot*/

www.srch.com

www.srch.com/xyz

www.srch.com/xyz*

Adresse IPv4

HTTP sur une adresse IPv4 spécifique.

10.1.1.199

Adresse IPv6

HTTP sur une adresse IPv6 spécifique.

1::1

Vous devez spécifier une base de données de filtres d’URL personnalisée dans le profil. Si nécessaire, vous pouvez également affecter un fichier de base de données de filtre d’URL personnalisé avec n’importe quel modèle, et cette base de données est prioritaire sur la base de données configurée au niveau du profil.

Si vous modifiez le contenu du fichier de base de données de filtre d’URL, utilisez la request services (url-filter | web-filter) update commande. D’autres commandes pour vous aider à maintenir le fichier de base de données de filtre d’URL sont les suivantes :

  • request services (url-filter | web-filter) delete

  • request services (url-filter | web-filter) force

  • request services (url-filter | web-filter) validate

Mises en garde relatives au profil de filtre d’URL

Le profil de filtre URL se compose de un à huit modèles. Chaque modèle se compose d’un ensemble d’interfaces logiques configurées dans lesquelles le trafic est surveillé pour le filtrage des URL et un ou plusieurs termes.

Un terme est un ensemble de critères de correspondance avec des actions à entreprendre si les critères de correspondance sont remplis. Vous devez configurer au moins un terme pour configurer le filtrage des URL. Chaque terme se compose d’une instruction et d’une from then instruction, où l’instruction from définit les préfixes IP source et les ports de destination qui sont surveillés. L’énoncé then spécifie l’action à entreprendre. Si vous omettez l’instruction from , tout préfixe IP source et tout port de destination sont considérés comme correspondants. Toutefois, vous ne pouvez omettre qu’une from seule instruction par modèle ou par profil.

Exemple de configuration de plusieurs termes sans instructions from

Si vous omettez plus d’une from instruction par modèle, vous obtiendrez le message d’erreur suivant lors de la validation :

Voir aussi

Configuration du filtrage des URL

Pour configurer la fonctionnalité de filtrage d’URL, vous devez d’abord la configurer jservices-urlf au niveau de package-name la [edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] hiérarchie. Pour plus d’informations sur la configuration de l’instruction extension-provider package package-name de configuration, reportez-vous à l’instruction package (Chargement sur PIC).

Note:

MX-SPC3 n’a pas besoin jservices-urlf explicitement d’être utilisé package-name au niveau de la [edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] hiérarchie. Il est pris en charge par défaut.

Le filtrage des URL est configuré sur un pic de service. Il s’agit d’interfaces de services (qui utilisent le ms préfixe) ou d’interfaces multiservices agrégés (AMS) (qui utilisent le ams préfixe). Pour plus d’informations sur les interfaces AMS, reportez-vous au Guide de l’utilisateur des interfaces de services adaptatifs pour les périphériques de routage en commençant par Présentation des interfaces multiservices agrégées.

Un profil de filtrage d’URL est un ensemble de modèles. Chaque modèle se compose d’un ensemble de critères qui définissent quelles URL sont interdites et comment le destinataire est notifié.

Pour configurer le profil d’URL :

  1. Attribuez un nom au profil d’URL.

    À partir de Junos OS version 18.3R1, pour les services adaptatifs. Configurez le profil au niveau de la [edit services web-filter] hiérarchie. Avant Junos OS version 18.3R1, configurez le profil au niveau de la [edit services url-filter] hiérarchie. À partir de la version 19.3R2 de Junos OS, cette même fonctionnalité est disponible pour les serveurs nouvelle génération sur MX240, MX480 et MX960.

  2. Spécifiez le nom de la base de données de filtrage d’URL à utiliser.
  3. Configurez un ou plusieurs modèles pour le profil.

    Pour configurer chaque modèle, procédez comme suit :

    1. Nommez le modèle.
      Note:

      À partir de Junos OS version 18.3R1, configurez le modèle à l’aide de l’instruction url-filter-template . Avant Junos OS version 18.3R1, configurez le modèle à l’aide de l’instruction template .
    2. Accédez à ce nouveau niveau hiérarchique de modèles.
    3. Spécifiez le nom de la base de données de filtrage d’URL à utiliser.
    4. Spécifiez l’interface de bouclage pour laquelle l’adresse IP source est sélectionnée pour l’envoi des requêtes DNS.
    5. Désactivez le filtrage du trafic HTTP qui contient une adresse IP incorporée (par exemple, http :/10.1.1.1) appartenant à un nom de domaine non autorisé dans la base de données de filtrage d’URL.
    6. Configurez l’intervalle de temps de résolution DNS en minutes.
    7. Configurez le nombre de nouvelles tentatives d’une requête DNS en cas d’échec ou d’expiration.
    8. Spécifiez les adresses IP (IPv4 ou IPv6) des serveurs DNS auxquels les requêtes DNS sont envoyées.
    9. Spécifiez les interfaces logiques côté client sur lesquelles le filtrage des URL est configuré.
    10. Spécifiez les interfaces logiques côté serveur sur lesquelles le filtrage des URL est configuré.
    11. Spécifiez l’instance de routage sur laquelle le filtrage d’URL est configuré.
    12. Spécifiez l’instance de routage sur laquelle le serveur DNS est accessible.
  4. Configurez les informations sur le terme.

    Les termes sont utilisés dans les filtres pour segmenter la stratégie ou filtrer en petites paires de correspondances et d’actions.

    1. Nommez le terme.
    2. Accédez au nouveau niveau de hiérarchie des termes.
    3. Spécifiez les préfixes d’adresse IP source pour le trafic que vous souhaitez filtrer.
    4. Spécifiez les ports de destination pour le trafic que vous souhaitez filtrer.
    5. Configurez une action à effectuer.

      L’action peut être l’une des suivantes :

      custom-page custom-page

      Envoyez une chaîne de page personnalisée à l’utilisateur.
      http-status-code http-status-code

      Envoyez un code d’état HTTP à l’utilisateur.
      redirect-url redirect-url

      Envoyez une redirection HTTP à l’utilisateur.
      tcp-reset

      Envoyez une réinitialisation TCP à l’utilisateur.
  5. Associez le profil d’URL à un ensemble de services de saut suivant.
    Note:

    Pour le filtrage d’URL, vous devez configurer l’ensemble de services en tant qu’ensemble de services de saut suivant.
    Note:

    L’interface de service peut également être du ams préfixe. Si vous utilisez ams des interfaces au niveau de la [edit services service-set service-set-name] hiérarchie pour le filtre d’URL, vous devez également configurer l’instruction load-balancing-options hash-keys au niveau de la [edit interfaces ams-interface-name unit number] hiérarchie. .
    Note:

    À partir de Junos OS version 18.3R1, configurez le jeu de services à l’aide de l’instruction web-filter-profile . Avant Junos OS version 18.3R1, configurez le jeu de services à l’aide de l’instruction url-filter-profile .

Voir aussi

Filtrage des requêtes DNS pour les domaines de sites Web non autorisés

Vue d’ensemble du filtrage des requêtes DNS

À partir de la version 18.3R1 de Junos OS, vous pouvez configurer le filtrage DNS afin d’identifier les requêtes DNS pour les domaines de sites Web non autorisés. À partir de Junos OS version 19.3R2, vous pouvez configurer le filtrage DNS si vous exécutez les services de nouvelle génération avec la carte de services MX-SPC3. Les services nouvelle génération sont pris en charge sur les routeurs MX240, MX480 et MX960. Pour les requêtes DNS de type A, AAAA, MX, CNAME, TXT, SRV et ANY, vous configurez l’action à effectuer pour une requête DNS pour un domaine non autorisé. Vous pouvez soit :

  • Bloquez l’accès au site Web en envoyant une réponse DNS contenant l’adresse IP ou le nom de domaine complet (FQDN) d’un serveur de sinkhole DNS. Ainsi, lorsque le client tente d’envoyer du trafic vers le domaine non autorisé, le trafic est dirigé vers le serveur sinkhole (voir Figure 3).

  • Consignez la demande et autorisez l’accès.

À partir de la version 21.1R1 de Junos OS, vous pouvez également configurer les actions suivantes pour une requête DNS pour un domaine non autorisé :

  • Alerte
  • Accepter
  • Goutte
  • Drop-no-log (en anglais)

Pour les autres types de requêtes DNS pour un domaine non autorisé, la demande est consignée et l’accès est autorisé.

Les actions effectuées par le serveur sinkhole ne sont pas contrôlées par la fonctionnalité de filtrage des requêtes DNS ; Vous êtes responsable de la configuration des actions du serveur sinkhole. Par exemple, le serveur sinkhole peut envoyer un message au demandeur, l’informant que le domaine n’est pas accessible et empêcher l’accès au domaine non autorisé.

Figure 3 : requête DNS pour un domaine DNS Request for Disallowed Domain non autorisé

Avantages

Le filtrage DNS redirige les requêtes DNS pour les domaines de sites Web non autorisés vers des serveurs de dolines, tout en empêchant toute personne utilisant le système de voir la liste des domaines interdits. En effet, les noms de domaine non autorisés sont dans un format crypté.

Fichier de base de données de filtre de domaine non autorisé

Le filtrage des requêtes DNS nécessite un fichier .txt de base de données de filtrage de domaine non autorisé, qui identifie chaque nom de domaine non autorisé, l’action à effectuer sur une requête DNS pour le domaine interdit et l’adresse IP ou le nom de domaine complet (FQDN) d’un serveur de sinkhole DNS.

Profil de filtre DNS

Vous configurez un profil de filtre DNS pour spécifier le fichier de base de données de filtre de domaine non autorisé à utiliser. Vous pouvez également spécifier les interfaces sur lesquelles le filtrage des requêtes DNS est effectué, limiter le filtrage aux requêtes pour des serveurs DNS spécifiques et limiter le filtrage aux requêtes provenant de préfixes d’adresses IP sources spécifiques.

Comment configurer le filtrage des requêtes DNS

Pour filtrer les requêtes DNS pour les domaines de sites Web non autorisés, procédez comme suit :

Comment configurer une base de données de filtrage de domaine

Créez un ou plusieurs fichiers de base de données de filtrage de domaine qui incluent une entrée pour chaque domaine non autorisé. Chaque entrée spécifie ce qu’il faut faire avec une requête DNS pour un domaine de site Web non autorisé.

Pour configurer un fichier de base de données de filtrage de domaine :

  1. Créez le nom du fichier. Le nom du fichier de base de données peut avoir une longueur maximale de 64 caractères et doit avoir une extension .txt .
  2. Ajoutez un en-tête de fichier avec un format tel que 20170314_01 :domain,sinkhole_ip,v6_sinkhole,sinkhole_fqdn,id,action.
  3. Ajoutez une entrée dans le fichier pour chaque domaine non autorisé. Vous pouvez inclure un maximum de 10 000 entrées de domaine. Chaque entrée du fichier de base de données contient les éléments suivants :

    nom de domaine haché, adresse de sinkhole IPv4, adresse de sinkhole IPv6, nom de domaine complet de sinkhole, ID, action

    où:

    • hashed-domain-name est une valeur hachée du nom de domaine interdit (64 caractères hexadécimaux). La méthode de hachage et la clé de hachage que vous utilisez pour produire la valeur de domaine hachée sont nécessaires lorsque vous configurez le filtrage DNS avec l’interface de ligne de commande de Junos OS.

    • IPv4 sinkhole address est l’adresse du serveur de sinkhole DNS pour les requêtes DNS IPv4.

    • IPv6 sinkhole address est l’adresse du serveur de sinkhole DNS pour les requêtes DNS IPv6.

    • sinkhole FQDN est le nom de domaine complet du serveur de sinkhole DNS.

    • ID est un nombre de 32 bits qui associe de manière unique l’entrée au nom de domaine haché.

    • action est l’action à appliquer à une requête DNS qui correspond au nom de domaine non autorisé. Si vous saisissez :

      • replace, le routeur MX Series envoie au client une réponse DNS avec l’adresse IP ou le nom de domaine complet du serveur de sinkhole DNS. Si vous entrez report, la requête DNS est consignée, puis envoyée au serveur DNS.
      • report, la requête DNS est consignée puis envoyée au serveur DNS.
      • alert, la requête DNS est consignée et la requête est envoyée au serveur DNS.
      • accept, la requête DNS est consignée et la requête est envoyée au serveur DNS.
      • drop, la requête DNS est abandonnée et la requête est consignée . La requête DNS n’est pas envoyée au serveur DNS.
      • drop-no-log, la requête DNS est abandonnée et aucun syslog n’est généré. La requête DNS n’est pas envoyée au serveur DNS.
  4. Dans la dernière ligne du fichier, incluez le hachage du fichier, que vous calculez à l’aide de la même clé et de la même méthode de hachage que celles que vous avez utilisées pour produire les noms de domaine hachés.
  5. Enregistrez les fichiers de base de données sur le moteur de routage dans le répertoire /var/db/url-filterd .
  6. Validez le fichier de base de données du filtre de domaine.
  7. Si vous apportez des modifications au fichier de base de données, appliquez-les.

Comment configurer un profil de filtre DNS

Un profil de filtre DNS inclut des paramètres généraux de filtrage des requêtes DNS pour les domaines de sites Web non autorisés et comprend jusqu’à 32 modèles. Les paramètres de modèle s’appliquent aux requêtes DNS sur des interfaces logiques ou des instances de routage spécifiques en liaison montante et descendante, ou aux requêtes DNS provenant de préfixes d’adresse IP source spécifiques, et remplacent les paramètres correspondants au niveau du profil DNS. Vous pouvez configurer jusqu’à huit profils de filtres DNS.

Pour configurer un profil de filtre DNS :

  1. Configurez le nom d’un profil de filtre DNS :

    Le nombre maximal de profils est de 8.

  2. Configurez l’intervalle de journalisation des statistiques par client pour le filtrage DNS. La plage est comprise entre 0 et 60 minutes et la valeur par défaut est de 5 minutes.
  3. Configurez les paramètres généraux de filtrage DNS pour le profil. Ces valeurs sont utilisées si une requête DNS ne correspond pas à un modèle spécifique.
    1. Spécifiez le nom de la base de données de filtrage de domaine à utiliser lors du filtrage des requêtes DNS.
    2. (Facultatif) Pour limiter le filtrage DNS aux requêtes DNS destinées à des serveurs DNS spécifiques, spécifiez jusqu’à trois adresses IP (IPv4 ou IPv6).
    3. Spécifiez le format de la clé de hachage.
    4. Spécifiez la clé de hachage que vous avez utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtre de domaine.
    5. Spécifiez la méthode de hachage qui a été utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtre de domaine.

      La seule méthode de hachage prise en charge est hmac-sha2-256.

    6. Configurez l’intervalle de journalisation des statistiques pour les requêtes DNS et pour les actions de sinkhole effectuées pour chaque adresse IP client. La plage est comprise entre 1 et 60 minutes et la valeur par défaut est de 5 minutes.
    7. Configurez la durée de vie lors de l’envoi de la réponse DNS après avoir effectué l’action de sinkhole DNS. La plage est comprise entre 0 et 86 400 secondes et la valeur par défaut est 1800.
    8. Configurez le niveau des sous-domaines recherchés pour une correspondance. La plage est comprise entre 0 et 10. La valeur 0 indique que les sous-domaines ne sont pas recherchés.

      Par exemple, si vous définissez le wildcarding-level sur 4 et que le fichier de base de données inclut une entrée pour example.com, les comparaisons suivantes sont effectuées pour une requête DNS qui arrive avec le domaine 198.51.100.0.example.com :

      • 198.51.100.0.example.com : pas de match

      • 51.100.0.example.com : pas de match pour un niveau inférieur

      • 100.0.example.com : pas de match pour deux niveaux plus bas

      • 0.example.com : pas de match pour trois niveaux plus bas

      • example.com : match pour quatre niveaux vers le bas

  4. Configurez un modèle. Vous pouvez configurer un maximum de 8 modèles dans un profil. Chaque modèle identifie les paramètres de filtre pour les requêtes DNS sur des interfaces logiques ou des instances de routage spécifiques en liaison montante et descendante, ou pour les requêtes DNS provenant de préfixes d’adresse IP source spécifiques.
    1. Configurez le nom du modèle.
    2. (Facultatif) Spécifiez les interfaces logiques côté client (liaison montante) auxquelles le filtrage DNS est appliqué.
    3. (Facultatif) Spécifiez les interfaces logiques côté serveur (liaison descendante) auxquelles le filtrage DNS est appliqué.
    4. (Facultatif) Spécifiez l’instance de routage de l’interface logique côté client à laquelle le filtrage DNS est appliqué.
    5. (Facultatif) Spécifiez l’instance de routage de l’interface logique orientée serveur à laquelle le filtrage DNS est appliqué.
      Note:

      Si vous configurez les interfaces client et serveur ou les instances de routage client et serveur, des filtres implicites sont installés sur les interfaces ou les instances de routage pour diriger le trafic DNS vers le PIC de services pour le filtrage DNS. Si vous ne configurez ni les interfaces client et serveur, ni les instances de routage, vous devez fournir un moyen de diriger le trafic DNS vers le PIC des services (par exemple, via des routes).
    6. Spécifiez le nom de la base de données de filtrage de domaine à utiliser lors du filtrage des requêtes DNS.
    7. (Facultatif) Pour limiter le filtrage DNS aux requêtes DNS destinées à des serveurs DNS spécifiques, spécifiez jusqu’à trois adresses IP (IPv4 ou IPv6).
    8. Spécifiez la méthode de hachage qui a été utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtre de domaine.

      La seule méthode de hachage prise en charge est hmac-sha2-256.

    9. Spécifiez la clé de hachage qui a été utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtre de domaine.
    10. Configurez l’intervalle de journalisation des statistiques pour les requêtes DNS et pour les actions de sinkhole effectuées pour chaque adresse IP client. La plage est comprise entre 1 et 60 minutes et la valeur par défaut est de 5 minutes.
    11. Configurez la durée de vie lors de l’envoi de la réponse DNS après avoir effectué l’action de sinkhole DNS. La plage est comprise entre 0 et 86 400 secondes et la valeur par défaut est 1800.
    12. Configurez le niveau des sous-domaines recherchés pour une correspondance. La plage est comprise entre 0 et 10. La valeur 0 indique que les sous-domaines ne sont pas recherchés.

      Par exemple, si vous définissez le wildcarding-level sur 4 et que le fichier de base de données inclut une entrée pour example.com, les comparaisons suivantes sont effectuées pour une requête DNS qui arrive avec le domaine 198.51.100.0.example.com :

      • 198.51.100.0.example.com : pas de correspondance

      • 51.100.0.example.com : pas de match pour un niveau inférieur

      • 100.0.example.com : pas de match pour deux niveaux plus bas

      • 0.example.com : pas de match pour trois niveaux plus bas

      • example.com : match pour quatre niveaux inférieurs

    13. (Facultatif) Spécifiez le code d’erreur de réponse pour les types de requête SRV et TXT.

      (Facultatif) Spécifiez le code d’erreur de réponse pour les types de requête SRV et TXT.

    14. Configurez un terme pour le modèle. Vous pouvez configurer un maximum de 64 termes dans un modèle.
    15. (Facultatif) Spécifiez les préfixes d’adresse IP source des requêtes DNS que vous souhaitez filtrer. Vous pouvez configurer un maximum de 64 préfixes au cours d’une période.
    16. Spécifiez que l’action de sinkhole identifiée dans la base de données de filtre de domaine est effectuée sur les requêtes DNS non autorisées.

Comment configurer un ensemble de services pour le filtrage DNS

Associez le profil de filtre DNS à un ensemble de services de saut suivant et activez la journalisation pour le filtrage DNS. Il peut s’agir d’une interface ms ou vms (services nouvelle génération avec carte de services MX-SPC3) ou d’une interface multiservices agrégée (AMS).

Prise en charge multi-utilisateur du filtrage DNS

Aperçu

À partir de Junos OS version 21.1R1, vous pouvez configurer des flux de domaine personnalisés par client ou sous-groupe IP. Vous pouvez:

  • Configurez les noms de domaine et les actions pour plusieurs locataires de manière à ce que les flux de domaine puissent être gérés par locataire.
  • Configurez la gestion hiérarchique des flux de domaine par profil, par modèle de filtre dns ou par terme de filtre dns.
  • Flux de domaine exemptés au niveau de l’adresse IP, du sous-réseau ou du CIDR.

Pour implémenter la prise en charge mutiltenant du filtrage DNS, la création du fichier de base de données de filtre de domaine au niveau du modèle ou du profil est désactivée. Vous n’avez pas besoin de spécifier un fichier au niveau du modèle ou du profil. À partir de Junos OS 21.1R1, par défaut, un fichier global avec un nom fixe, nsf_multi_tenant_dn_custom_file.txt (format texte brut) ou dnsf_multi_tenant_dn_custom_file_hashed.txt (fichier chiffré) est disponible.

Chaque entrée du fichier de base de données contient les éléments suivants :

nom de domaine haché, adresse de sinkhole IPv4, adresse de sinkhole IPv6, FQDN de sinkhole, ID, action, nom de flux.

Le hachage du fichier est calculé et ajouté à la liste des entrées de nom de domaine dans le fichier. Le hachage du fichier est calculé à l’aide d’une clé et d’une méthode globales, qui sont validées avec le hachage du fichier calculé à l’aide de la clé de hachage configurée au niveau de la [edit services web-filter] hiérarchie. La validation du fichier n’est réussie que si le hachage de fichier calculé correspond au hachage de fichier présent dans le fichier.

Chaque entrée de nsf_multi_tenant_dn_custom_file.txt fichier se compose d’un champ supplémentaire appelé nom-flux. Ce nom de flux est utilisé comme indicateur pour regrouper un ensemble de noms de domaine et les mapper à un locataire (profil, modèle, terme ou adresse IP).

Lorsque les paquets DNS sont reçus d’une adresse IP SRC particulière, le nom de flux correspondant est récupéré et la recherche a lieu par rapport aux noms de domaine mappés avec le nom de flux associé au terme. Si le nom de flux n’est pas provisionné pour cette adresse IP, il revient au nom de flux configuré au niveau du modèle et la recherche s’effectue par rapport aux noms de domaine mappés avec le nom de flux associé au modèle. Si le nom de flux n’est pas configuré au niveau du modèle, la recherche se fait par rapport aux noms de domaine mappés au nom de flux associé au profil.

Configuration de la prise en charge mutualisée du filtrage DNS

  1. Configurez le filtre Web.
  2. Prise en charge multi-tenant
  3. Configurez la clé de hachage globale du fichier et la méthode de hachage.
    Note:

    Lorsqu’il multi-tenant-hashest configuré, il indique que le fichier de flux DNS global est constitué uniquement de flux chiffrés. Lorsqu’il multi-tenant-hash n’est pas configuré, il indique que le fichier de flux DNS global contient des flux au format texte brut.

  4. Configurez le nom d’un profil de filtre DNS et mappez le flux de domaine au niveau du profil. L’indicateur de nom de flux configuré au niveau du profil est appliqué à tous les modèles et termes du profil pour lesquels l’indicateur de nom de flux n’est pas configuré.
  5. Configurez les paramètres généraux de filtrage DNS pour le profil. Ces valeurs sont utilisées si une requête DNS ne correspond pas à un modèle spécifique.
    1. (Facultatif) Pour limiter le filtrage DNS aux requêtes DNS destinées à des serveurs DNS spécifiques, spécifiez jusqu’à trois adresses IP (IPv4 ou IPv6).
    2. Configurez l’intervalle de journalisation des statistiques pour les requêtes DNS et pour les actions de sinkhole effectuées pour chaque adresse IP client. La plage est comprise entre 1 et 60 minutes et la valeur par défaut est de 5 minutes.
    3. Configurez la durée de vie (TTL) pour envoyer la réponse DNS après avoir effectué l’action de sinkhole DNS. La plage est comprise entre 0 et 86 400 secondes et la valeur par défaut est 1800.
    4. Configurez le niveau des sous-domaines recherchés pour une correspondance. La plage est comprise entre 0 et 10. La valeur 0 indique que les sous-domaines ne sont pas recherchés.
    5. (Facultatif) Spécifiez le code d’erreur de réponse pour le type de requête TXT.
  6. Configurez un modèle. Vous pouvez configurer un maximum de 8 modèles dans un profil. Chaque modèle identifie les paramètres de filtre pour les requêtes DNS sur des interfaces logiques ou des instances de routage spécifiques en liaison montante et descendante, ou pour les requêtes DNS provenant de préfixes d’adresse IP source spécifiques.
    1. Configurez le nom du modèle.
    2. Configurez le nom du flux. Avec le format mutualisé, vous ne pouvez plus ajouter de nom de fichier sous profil ou modèle. Le nom du flux spécifié sous le profil est moins prioritaire que celui configuré sous le modèle.
    3. (Facultatif) Spécifiez les interfaces logiques côté client (liaison montante) auxquelles le filtrage DNS est appliqué.
    4. (Facultatif) Spécifiez les interfaces logiques côté serveur (liaison descendante) auxquelles le filtrage DNS est appliqué.
    5. (Facultatif) Spécifiez l’instance de routage de l’interface logique côté client à laquelle le filtrage DNS est appliqué.
    6. (Facultatif) Spécifiez l’instance de routage de l’interface logique orientée serveur à laquelle le filtrage DNS est appliqué.
      Note:

      Si vous configurez les interfaces client et serveur ou les instances de routage client et serveur, des filtres implicites sont installés sur les interfaces ou les instances de routage pour diriger le trafic DNS vers le PIC de services pour le filtrage DNS. Si vous ne configurez ni les interfaces client et serveur, ni les instances de routage, vous devez fournir un moyen de diriger le trafic DNS vers le PIC de services (par exemple, via des routes).
    7. Configurez l’intervalle de journalisation des statistiques pour les requêtes DNS et pour les actions de sinkhole effectuées pour chaque adresse IP client. La plage est comprise entre 1 et 60 minutes et la valeur par défaut est de 5 minutes.
    8. Configurez la durée de vie lors de l’envoi de la réponse DNS après avoir effectué l’action de sinkhole DNS. La plage est comprise entre 0 et 86 400 secondes et la valeur par défaut est 1800.
    9. Configurez le niveau des sous-domaines recherchés pour une correspondance. La plage est comprise entre 0 et 10. La valeur 0 indique que les sous-domaines ne sont pas recherchés.
    10. Configurez un terme pour le modèle. Vous pouvez configurer un maximum de 64 termes dans un modèle.
    11. Configurez le nom du flux. Le nom de flux configuré au terme est prioritaire sur celui configuré sous le modèle. Toutefois, si le domaine du sinkhole correspond au seul domaine mentionné dans le nom du flux sous le modèle, l’action spécifiée pour cette entrée est implémentée.
    12. (Facultatif) Spécifiez les préfixes d’adresse IP source des requêtes DNS que vous souhaitez filtrer. Vous pouvez configurer un maximum de 64 préfixes au cours d’une période.
    13. Configurez que l’action de sinkhole identifiée dans la base de données de filtrage de domaine est effectuée sur les requêtes DNS non autorisées.
  7. Associez le profil de filtre DNS à un ensemble de services de saut suivant et activez la journalisation pour le filtrage DNS. Il peut s’agir d’une interface multiservices (ms) ou virtuelle multiservice (vms) (services de nouvelle génération avec carte de services MX-SPC3) ou d’une interface multiservices agrégée (AMS).
  8. Si vous exécutez des services de nouvelle génération sur la carte de services MX-SPC3, configurez l’interface de la machine virtuelle pour obtenir les informations FPC et PIC dans le syslog.

Exemple : configuration de la prise en charge mutualisée du filtrage DNS

Configuration

Configuration rapide de la CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].

Intégration du filtrage Juniper ATP Cloud et Web sur les routeurs MX Series

Aperçu

Juniper Advanced Threat Prevention (Juniper ATP Cloud) est intégré aux routeurs MX Series pour protéger tous les hôtes de votre réseau contre les menaces de sécurité en constante évolution grâce à un logiciel de détection des menaces basé sur le cloud et doté d’un système de pare-feu de nouvelle génération.

Cette rubrique donne un aperçu de Juniper ATP Cloud, de Policy Enforcer, de Security Intelligence, du filtrage Web et de leurs avantages lorsqu’ils sont intégrés sur les routeurs MX Series.

Pour plus d’informations sur la plate-forme et la version, reportez-vous à la section Explorateur de fonctionnalités .

Avantages

  • Simplifie le déploiement et améliore les capacités de protection contre les menaces lorsqu’il est intégré aux routeurs MX.

  • Fournit une protection contre les menaces « zero-day » à l’aide d’une combinaison d’outils pour fournir une couverture solide contre les menaces sophistiquées et évasives.

  • Vérifie le trafic entrant et sortant grâce à des politiques améliorées qui permettent aux utilisateurs d’arrêter les logiciels malveillants, de mettre en quarantaine les systèmes infectés, d’empêcher l’exfiltration de données et de perturber les mouvements latéraux.

  • Prend en charge la haute disponibilité pour fournir un service ininterrompu.

  • Offre l’évolutivité nécessaire pour gérer des charges de travail croissantes qui nécessitent davantage de ressources informatiques, une bande passante réseau accrue pour recevoir plus de soumissions de clients et une grande capacité de stockage pour les logiciels malveillants.

  • Fournit une inspection approfondie, des rapports exploitables et un blocage intégré des logiciels malveillants.

  • Permet de fournir des informations sur les locations à l’aide des informations VRF contenues dans les journaux

Comprendre Policy Enforcer et Juniper ATP Cloud

Juniper Networks Security Director comprend une fonctionnalité appelée Policy Enforcer (PE) qui lui permet d’apprendre des conditions de menace, d’automatiser la création de stratégies et de déployer dynamiquement l’application sur les équipements Juniper du réseau.

La figure 4 illustre le flux de trafic entre le PE, le cloud ATP de Juniper et le routeur MX qui fait office de pare-feu.

  • Policy Enforcer (PE) apprend des conditions des menaces, automatise la création de stratégies et déploie l’application sur les équipements Juniper du réseau.

  • Juniper Advanced Threat Prevention (Juniper ATP Cloud) protège tous les hôtes de votre réseau à l’aide d’un logiciel cloud de détection des menaces doté d’un système de pare-feu de nouvelle génération.

  • Le routeur MX récupère les flux de renseignements sur les menaces de Policy Enforcer (PE) et met en œuvre ces stratégies pour mettre en quarantaine les hôtes compromis. Il comprend les éléments importants suivants :

    • Processus de veille de sécurité

    • Processus de filtrage Web

    • Processus de pare-feu

Figure 4 : Architecture System Architecture du système

Pour comprendre les fonctionnalités de l’architecture système, prenons l’exemple suivant : si un utilisateur télécharge un fichier sur Internet et que ce fichier passe par un pare-feu MX, le fichier peut être envoyé au cloud Juniper ATP Cloud pour être inspecté (en fonction de vos paramètres de configuration). S’il s’avère que le fichier est un programme malveillant, PE identifie l’adresse IP et l’adresse MAC de l’hôte qui a téléchargé le fichier. En fonction d’une stratégie définie par l’utilisateur, cet hôte peut être placé dans un VLAN de quarantaine ou empêché d’accéder à Internet.

Les routeurs MX Series peuvent être intégrés à Juniper ATP Cloud pour empêcher les hôtes compromis (botnets) de communiquer avec les serveurs de commande et de contrôle :

  • À partir de Junos OS version 18.4R1 avec les services adaptatifs en tant que fonctionnalité de sécurité intégrée

  • À partir de Junos OS version 19.3R2 avec les services de nouvelle génération en tant que fonctionnalité de sécurité intégrée

Les routeurs MX Sseries peuvent télécharger C&C et Geo-IP à partir de l’une des méthodes suivantes :

  • Méthode indirecte : Policy Enforcer agit comme un proxy de flux pour tous les appareils d’un environnement défini. Cette méthode permet d’éviter que des appareils individuels accèdent aux services cloud de Juniper ATP sur Internet. Ainsi, il diminue la vulnérabilité des appareils qui se connectent à Internet.

  • Les routeurs MX Series s’inscrivent directement dans le cloud Juniper ATP pour télécharger les flux C&C et Geo-IP.

Informations de sécurité (SecIntel) - Présentation

Le processus IPFD (Security Intelligence) est chargé de télécharger les flux d’informations de sécurité et de les analyser à partir du connecteur de flux ou du serveur de flux cloud ATP Cloud. Le processus IPFD sur les plates-formes MX récupère les flux IPv4/IPv6 de commande et de contrôle auprès de Policy Enforcer. Les flux C&C sont essentiellement une liste de serveurs qui sont des serveurs de commande et de contrôle connus pour les botnets. La liste comprend également les serveurs qui sont des sources connues pour les téléchargements de logiciels malveillants. Les informations ainsi récupérées sont sauvegardées dans un fichier (urlf_si_cc_db.txt) créé dans le répertoire /var/db/url-filterd .

Le format de fichier des adresses IP non autorisées envoyées par IPFD au processus de filtrage Web est le suivant :

IPv4 address | IPv6 address, threat-level.

Il threat-level s’agit d’un entier compris entre 1 et 10 qui indique le niveau de menace des fichiers analysés à la recherche de logiciels malveillants et d’hôtes infectés. Ici, 1 représente le niveau de menace le plus faible et 10 représente le niveau de menace le plus élevé.

Par exemple : 178.10.19.20, 4

Ici, 178.10.19.20 indique l’adresse IP interdite et 4 indique le threat-level.

La base de données du flux C&C est synchronisée avec le moteur de routage de sauvegarde. IPFD partage ensuite les informations avec le processus de filtrage Web (url-filterd). Le processus de filtrage Web lit le contenu des fichiers et configure les filtres en conséquence.

Configuration des informations de sécurité pour télécharger le flux CC à partir de Policy Enforcer

Pour télécharger les flux IPv4/IPv6 de commande et de contrôle à partir de Juniper ATP Cloud/Policy Enforcer, incluez l’instruction security-intelligence dans la [edit services] hiérarchie, comme illustré dans l’exemple suivant :

Filtrage Web (filtré par URL) - Vue d’ensemble

Le processus de filtrage Web lit le contenu des fichiers récupérés à partir de l’IPFD et configure les filtres sur le moteur de transfert de paquets en conséquence. Le processus de filtrage Web applique les flux de commande et de contrôle en programmant les filtres dans le moteur de transfert de paquets afin qu’ils bloquent les paquets destinés aux adresses IP bloquées et génèrent des journaux pour signaler l’incident.

La figure 5 illustre la façon dont le flux C&C est récupéré par l’IPFD, puis traité par le processus de filtrage Web.

Figure 5 : filtrage Web Web Filtering

Le profil de filtre Web peut avoir plusieurs modèles. Chaque modèle se compose d’un ensemble d’interfaces logiques configurées pour le filtrage Web et d’un ou plusieurs termes. Un terme est un ensemble de critères de correspondance avec des actions à entreprendre si les critères de correspondance sont remplis. Pour configurer le profil de filtre Web afin d’utiliser le flux C&C récupéré dynamiquement, vous pouvez configurer la security-intelligence-policy commande au niveau de la [edit services web-filter profile profile-name hiérarchie. Vous n’avez pas besoin de configurer un terme pour les profils de security-intelligence-policy filtre Web basés.

Vous pouvez configurer les actions de niveau de menace suivantes pour le profil de filtre Web au niveau de la edit web-filter profile profile-name security-intelligence-policy threat-level threat-level threat-action hiérarchie :

  • drop

  • drop-and-log

  • log

Vous ne pouvez en configurer qu’un threat-action seul pour chaque threat level. Si le n’est threat-action pas configuré pour un threat level, la valeur par défaut threat-action est accept.

À partir de la version 24.4R1 de Junos OS, pour les menaces configurées avec log action, le niveau de menace et les informations du locataire ou VRF sont incorporés dans les syslogs sortants. Les mappages de stratégies de classe de service sont enrichis d’un nouveau user-attribute integer mot-clé à stocker et à indiquer le niveau de menace.

Vous pouvez configurer le user-attribute integer au niveau de la [editi class-of-service policy-map policy-name] hiérarchie.

Le mappage de stratégie est référencé dans chaque configuration au niveau de la menace pour mapper le nouvel attribut utilisateur<> au terme de filtre dfw qui détermine l’action configurée pour chaque niveau de menace. Le mappage de stratégie est utilisé au niveau de la hiérarchie ou [edit services web-filter profile profile-name url-filter-template template-name security-intelligence-policy threat level integer policy-map policy-name] de la [edit services web-filter profile profile-name security-intelligence-policy threat level integer policy-map policy-name] hiérarchie pour mapper le niveau de menace à un attribut utilisateur.

Par exemple

Voir aussi

  • politique de renseignement de sécurité
  • renseignements de sécurité

Configuration du profil de filtre Web pour l’échantillonnage

À partir de la version 19.3R1 de Junos OS, le processus de filtrage Web (filtré par URL) prend en charge l’échantillonnage en ligne des paquets en tant qu’action au niveau de la menace. Les paquets sont abandonnés, consignés et échantillonnés en fonction de l’action de menace que vous configurez. Pour les scénarios à l’échelle, l’échantillonnage des paquets est préférable à l’option de journalisation. Outre les actions de niveau de menace existantes, vous pouvez configurer les actions de niveau de menace suivantes sur le profil de filtre Web au niveau de la edit web-filter profile profile-name security-intelligence-policy threat-level threat-level threat-action hiérarchie :

  • drop-and-sample

  • drop-log-and-sample

  • log-and-sample

  • sample

La surveillance de flux en ligne échantillonne les paquets et envoie les enregistrements de flux au format IPFIX à un collecteur de flux. Vous pouvez déduire le niveau de menace pour les paquets échantillonnés reçus au niveau du collecteur externe en faisant correspondre l’adresse IP reçue des paquets échantillonnés avec l’entrée d’adresse IP correspondante dans /var/db/url-filterd/urlf_si_cc_db.txt. Vous pouvez configurer l’échantillonnage à l’aide de l’une des méthodes suivantes :

  • Associez une instance d’échantillonnage au FPC sur lequel l’interface multimédia est présente au niveau de la [edit chassis] hiérarchie. Si vous configurez l’échantillonnage de flux IPv4, de flux IPv6 ou de flux VPLS, vous pouvez configurer la taille de la table de hachage de flux pour chaque famille.

  • Configurez les propriétés du modèle pour la surveillance des flux en ligne au niveau de la [edit services flow-monitoring hiérarchie.

  • Configurez une instance d’échantillonnage et associez l’adresse IP du serveur de flux, le numéro de port, le taux d’exportation du flux et spécifiez les collecteurs au niveau de la [edit forwarding-options hiérarchie.

Associer une instance d’échantillonnage au FPC

Pour associer l’instance définie à un FPC, MPC ou DPC particulier, vous incluez l’instruction sampling-instance au niveau de la [edit chassis fpc number] hiérarchie, comme illustré dans l’exemple suivant :

Configurez une instance d’échantillonnage et associez le modèle à l’instance d’échantillonnage.

Pour configurer les propriétés du modèle pour la surveillance des flux en ligne, incluez les instructions suivantes au niveau de la edit services flow-monitoring hiérarchie, comme illustré dans l’exemple suivant :

Configurez l’exemple d’instance et associez l’adresse IP du serveur de flux et d’autres paramètres.

Pour configurer une instance d’échantillonnage et associer l’adresse IP du serveur de flux et d’autres paramètres. Incluez les instructions suivantes dans la [edit forwarding-options] hiérarchie, comme illustré dans l’exemple suivant :

Exemple : Configuration d’un profil de filtre Web pour définir différents niveaux de menace

Voir aussi

  • politique de renseignement de sécurité
  • Configuration de l’échantillonnage du trafic sur les routeurs MX, M et T Series

Filtrage GeoIP

Aperçu

Les flux GeoIP sont essentiellement une liste de correspondances d’adresses IP vers les codes de pays. À partir de Junos OS 21.4R1, vous pouvez configurer des emplacements géographiques IP sur les routeurs MX Series pour récupérer les flux GeoIP à partir de Policy Enforcer. En déployant les flux GeoIP, vous pouvez permettre au réseau d’empêcher les appareils de communiquer avec des adresses IP appartenant à des pays spécifiques.

Vous pouvez configurer le processus IPFD (Security Intelligence Process) sur les routeurs MX Series pour qu’il récupère les flux GeoIP à partir de Policy Enforcer. Comme pour les flux IP ou IPv6 C&C existants, IPFD télécharge les flux GeoIP à partir de Policy Enforcer. IPFD traduit le flux dans le format de fichier qui est ensuite traité par le processus de filtrage Web (filtré par URL).

À partir de Junos OS 22.1R1, vous pouvez configurer le processus IPFD (Security Intelligence Process) sur les routeurs MX Series pour récupérer les flux GeoIP de Juniper ATP Cloud. Comme pour les flux IP ou IPv6 C&C existants, l’IPFD télécharge les flux GeoIP à partir de Juniper ATP Cloud.

Comment configurer le filtrage GeoIP sur les routeurs MX Series

Les informations récupérées par l’IPFD sont enregistrées dans un fichier (urlf_si_geoip_db.txt) créé à l’emplacement filtré /var/db/url .

Le format du fichier envoyé par IPFD au processus de filtrage Web est le suivant :

IPv4 address|IPv6 address,Prefix,threat-level,VRF-name,Gen-num. Gen-num est toujours égal à 0. VRF-name fait référence à un code de pays.

Par exemple, 178.10.19.22,12,255,US,0

L’IPFD et le processus de filtrage Web maintiennent une connexion pconn pour communiquer la création ou la mise à jour de fichiers contenant des flux GeoIP. Le processus de filtrage Web applique les flux GeoIP en programmant les filtres dans le PFE pour bloquer les paquets destinés aux pays bloqués. Les API fournies par liburlf sont utilisées pour valider et analyser les fichiers.

Le processus de filtrage Web lit le fichier contenant la liste des adresses IP et les filtres PFE sont programmés avec les adresses IP de destination répertoriées dans le flux et l’action configurée pour le pays associé.

  • Filtre global : les pays sont configurés sous une règle globale au sein d’un profil. Toutes les adresses IP des pays spécifiques à cette règle globale sont programmées dans un filtre unique et appliquées à tous les modèles du profil. Vous pouvez configurer un profil pour récupérer dynamiquement le flux GeoIP en configurant geo-ip rule match country country-name dans la [edit services web-filter profile profile-name security-intelligence-policy] hiérarchie .

  • Filtre de groupe : les groupes de pays sont configurés sous un modèle. Toutes les adresses IP associées aux pays d’un groupe sont programmées dans un filtre de groupe appliqué aux modèles sous lesquels ce groupe est configuré. Group est une liste de pays définis dans un fichier json qui est analysé par liburlf.

    Pour configurer un filtre de groupe, vous devez configurer un fichier json à l’emplacement /var/db/url-filterd , où le fichier group.json contient les mappages de groupe.

    Le format du fichier json est le suivant :

    [

    {

    "group_name" : "group1",

    "country" : ["ZA","YE"]

    },

    {

    "group_name" : "group2",

    "country" : ["YT"]

    }

    ]

    Pour récupérer dynamiquement les flux GeoIP, vous pouvez configurer un filtre global à l’aide d’un seul profil ou configurer plusieurs filtres de groupe à l’aide de modèles. Nous ne prenons pas en charge les deux configurations ensemble.

    Les groupes créés dans le fichier json sont référencés dans la clause de correspondance GeoIP définie au niveau de la [edit services web-filter profile profile-name url-filter-template template-name security-intelligence-policy geo-ip rule match group group-name] hiérarchie.

Liste d’autorisation globale et liste de blocage globale

Vous pouvez choisir de personnaliser le flux d’adresses IP en ajoutant votre propre liste d’autorisation et de blocage. Cela peut être utile pour gérer les flux de renseignements personnalisés pour votre centre des opérations de sécurité ou comme mesure temporaire pour les faux positifs. À partir de la version 21.4R1 de Junos OS, vous pouvez autoriser ou bloquer certaines adresses IP en fonction de la configuration via une CLI ou un fichier. Vous pouvez soit configurer une liste distincte pour la liste d’autorisation et une liste distincte pour la liste de blocage, soit inclure les adresses IP dans un fichier et inclure le nom du fichier dans la configuration de l’interface de ligne de commande.

Vous pouvez créer un fichier IP-address-list dans la [edit services web-filter] hiérarchie. Ici, IP-address-list contient la liste des adresses IP qui doivent être autorisées ou bloquées. Vous pouvez également créer un fichier contenant les adresses IP qui doivent être autorisées ou bloquées dans l’emplacement filtré /var/db/url . Les adresses IP configurées dans le fichier ou la liste d’adresses IP sont programmées dans le filtre global, qui est attaché à tous les modèles.

Vous pouvez définir une liste d’autorisation globale en configurant white-list (IP-address-list | file-name) au niveau de la edit services web-filter profile profile-name security-intelligence-policy hiérarchie. Vous pouvez définir une liste de blocage globale en configurant le black-list (IP-address-list | file-name) au niveau de la edit services web-filter profile profile-name security-intelligence-policy hiérarchie. Ici, le IP-address-list, fait référence au nom de la liste d’adresses IP spécifiée dans la [edit services web-filter] hiérarchie. Le file-name fait référence au nom du fichier qui contient la liste des adresses IP qui doivent être autorisées ou bloquées. Le fichier doit se trouver à l’emplacement filtré /var/db/url et doit avoir le même nom que dans la configuration.

Le format du fichier de liste d’autorisation globale est le suivant :

Security Intelligence Policy Enforcement Version 2.0

Le format du fichier de la liste de blocage globale est le suivant :

Security Intelligence Policy Enforcement Version 2.0

Le processus de filtrage Web analyse la liste des adresses IP de la liste d’autorisation globale ou de la liste de blocage globale et programme les termes de filtrage implicites avec les adresses IP configurées pour autoriser ou bloquer les paquets.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libérer
Description
19.3R2
À partir de la version 19.3R2 de Junos OS, cette même fonctionnalité est prise en charge pour les services de nouvelle génération sur MX240, MX480 et MX960.
19.3R2
À partir de la version 19.3R2 de Junos OS, cette même fonctionnalité est disponible pour les serveurs nouvelle génération sur MX240, MX480 et MX960.
19.3R2
À partir de Junos OS version 19.3R2, vous pouvez configurer le filtrage DNS si vous exécutez les services de nouvelle génération avec la carte de services MX-SPC3. Les services nouvelle génération sont pris en charge sur les routeurs MX240, MX480 et MX960.
19.3R2
À partir de Junos OS version 19.3R2 avec les services de nouvelle génération en tant que fonctionnalité de sécurité intégrée
19.3R1
À partir de Junos OS version 19.3R1, le processus de filtrage Web (filtré par URL) prend en charge l’échantillonnage en ligne des paquets en tant qu’action au niveau de la menace
18.4R1
À partir de Junos OS version 18.4R1 avec les services adaptatifs en tant que fonctionnalité de sécurité intégrée
18.3R1
À partir de Junos OS version 18.3R1, pour les services adaptatifs. Configurez le profil au niveau de la [edit services web-filter] hiérarchie. Avant Junos OS version 18.3R1, configurez le profil au niveau de la [edit services url-filter] hiérarchie.
17.2R2
À partir de Junos OS version 17.2R2 et 17.4R1, pour Adaptive Services, vous pouvez désactiver le filtrage du trafic HTTP qui contient une adresse IP incorporée (par exemple, http :/10.1.1.1) appartenant à un nom de domaine non autorisé dans la base de données de filtrage d’URL.