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 des 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 filtres d’URL

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

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

  • Démon de filtrage d’URL (filtré par URL)

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

À partir de Junos OS versions 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 filtres d’URL. À partir de Junos OS version 19.3R2, 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 package-name niveau de la [edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] hiérarchie. Une fois activé, jservices-urlf conserve le profil de filtrage d’URL et reçoit tout le trafic à filtrer, les critères de filtrage et l’action à effectuer sur le trafic filtré.

Remarque :

MX-SPC3 n’a pas explicitement besoin jservices-urlf de comme au package-name 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 filtres d’URL en une liste d’adresses IPv4 et IPv6. Il télécharge ensuite la liste des adresses IP vers le PIC de service, qui exécute jservices-urlf. Ensuite, le filtrage URL 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 vers le 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 filtres URL. Les règles de filtrage sont vérifiées et le routeur accepte le trafic et le transmet ou bloque le trafic. Si le trafic est bloqué, l’une des actions configurées suivantes est exécuté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 de détails sur la fonctionnalité de filtrage d’URL, consultez les sections suivantes :

Fichier de base de données de filtres URL

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

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

Entrée

Descriptif

Exemple

Nom de domaine complet (FQDN)

Nom de domaine complet.

www.badword.com/jjj/bad.jpg

URL (en anglais)

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

www.srch.com/*mot malveillant*/

www.srch.com

www.srch.com/xyz

www.srch.com/xyz*

Adresse IPv4

Requête HTTP sur une adresse IPv4 spécifique.

10.1.1.199

Adresse IPv6

Requête 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 filtres 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 filtres d’URL, utilisez la request services (url-filter | web-filter) update commande. Voici d’autres commandes permettant de gérer le fichier de base de données de filtres d’URL :

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

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

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

Mises en garde concernant les profils de filtres d’URL

Le profil de filtre d’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 d’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 d’URL. Chaque terme se compose d’une from instruction et d’une then instruction, où l’instruction from définit les préfixes IP sources et les ports de destination qui sont surveillés. L’instruction then spécifie l’action à entreprendre. Si vous omettez cette from instruction, tout préfixe IP source et tout port de destination sont considérés comme correspondants. Mais vous ne pouvez omettre qu’une from seule déclaration 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 d’URL

Pour configurer la fonctionnalité de filtrage d’URL, vous devez d’abord la configurer jservices-urlf en tant que package-name au niveau de 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 de extension-provider package package-name configuration, consultez l’instruction package (Chargement sur PIC).

Remarque :

MX-SPC3 n’a pas explicitement besoin jservices-urlf de comme au package-name 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. Les interfaces auxquelles vous avez affaire sont des interfaces de services (qui utilisent le ms préfixe) ou des interfaces multiservices agrégées (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 adaptatives 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 une collection 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 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 la version 18.3R1 de Junos OS, configurez le profil au niveau de la [edit services url-filter] hiérarchie. À partir de Junos OS version 19.3R2, cette même fonctionnalité est disponible pour les services de nouvelle génération sur MX240, MX480 et MX960.

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

    Pour configurer chaque modèle :

    1. Nommez le modèle.
      Remarque :

      À partir de Junos OS version 18.3R1, configurez le modèle avec l’instruction url-filter-template . Avant Junos OS version 18.3R1, configurez le modèle avec 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 filtres d’URL à utiliser.
    4. Spécifiez l’interface de bouclage pour laquelle l’adresse IP source est sélectionnée pour l’envoi de 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 filtres 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 de la requête.
    8. Spécifiez les adresses IP (IPv4 ou IPv6) des serveurs DNS vers lesquels les requêtes DNS sont envoyées.
    9. Spécifiez les interfaces logiques côté client sur lesquelles le filtrage d’URL est configuré.
    10. Spécifiez les interfaces logiques côté serveur sur lesquelles le filtrage d’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 le terme information.

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

    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 du trafic que vous souhaitez filtrer.
    5. Configurez une action à entreprendre.

      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.
    Remarque :

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

    L’interface de service peut également avoir le 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.
    Remarque :

    À partir de la version 18.3R1 de Junos OS, configurez l’ensemble de services à l’aide de l’instruction web-filter-profile . Avant la version 18.3R1 de Junos OS, configurez l’ensemble 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

Présentation 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 la version 19.3R2 de Junos OS, vous pouvez configurer le filtrage DNS si vous exécutez des 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 types 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 :

  • Bloquer 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 DNS sinkhole. Ainsi, lorsque le client tente d’envoyer du trafic vers le domaine non autorisé, le trafic va plutôt 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
  • Chute
  • Drop-no-log

Pour les autres types de requêtes DNS pour un domaine non autorisé, la requête est enregistré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 sinkhole, tout en empêchant quiconque exploitant le système de voir la liste des domaines non autorisés. En effet, les noms de domaine non autorisés sont dans un format crypté.

Fichier de base de données de filtres de domaine non autorisés

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

Profil de filtre DNS

Vous configurez un profil de filtre DNS pour spécifier le fichier de base de données de filtres 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 adressées à 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 site Web non autorisés, procédez comme suit :

Configuration d’une base de données de filtres de domaine

Créez un ou plusieurs fichiers de base de données de filtres 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 filtres de domaine :

  1. Créez le nom du fichier. Le nom du fichier de base de données peut comporter au maximum 64 caractères et doit avoir une extension .txt .
  2. Ajoutez un en-tête de fichier avec un format tel que 20170314_01 :domaine,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 :

    hashed-domain-name,adresse du gouffre IPv4, adresse du gouffre IPv6, nom de domaine complet du gouffre, ID, action

    où :

    • hashed-domain-name est une valeur hachée du nom de domaine non autorisé (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 la CLI de Junos OS.

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

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

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

    • 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 entrez :

      • replace, le routeur MX Series envoie au client une réponse DNS avec l’adresse IP ou le nom de domaine complet du serveur DNS sinkhole. Si vous entrez report, la requête DNS est enregistrée puis envoyée au serveur DNS.
      • report, la requête DNS est enregistrée puis envoyée au serveur DNS.
      • alert, la requête DNS est enregistrée et la requête est envoyée au serveur DNS.
      • accept, la requête DNS est enregistrée et la requête est envoyée au serveur DNS.
      • drop, la requête DNS est abandonnée et la requête est enregistré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 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 de filtres 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 pour filtrer les requêtes DNS pour les domaines de sites Web non autorisés et comprend jusqu’à 32 modèles. Les paramètres du modèle s’appliquent aux requêtes DNS sur des interfaces logiques ou des instances de routage de liaison montante et descendante spécifiques, ou aux requêtes DNS provenant de préfixes d’adresses IP sources 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 maximum 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 filtres de domaine.
    5. Spécifiez la méthode de hachage utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtres 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 gouffre effectuées pour chaque adresse IP client. La plage est de 1 à 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 gouffre 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 sur wildcarding-level 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 : aucun 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 plus 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 de liaison montante et descendante spécifiques, ou pour les requêtes DNS provenant de préfixes d’adresses IP sources 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 côté serveur à laquelle le filtrage DNS est appliqué.
      Remarque :

      Si vous configurez les interfaces client-serveur ou les instances de routage client-serveur, des filtres implicites sont installés sur les interfaces ou les instances de routage pour diriger le trafic DNS vers le PIC des services pour le filtrage DNS. Si vous ne configurez ni les interfaces client/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 utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtres de domaine.

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

    9. Spécifiez la clé de hachage utilisée pour créer le nom de domaine haché dans le fichier de base de données de filtres de domaine.
    10. Configurez l’intervalle de journalisation des statistiques pour les requêtes DNS et pour les actions de gouffre effectuées pour chaque adresse IP client. La plage est de 1 à 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 gouffre 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 : aucun 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 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 par trimestre.
    16. Spécifiez que l’action sinkhole identifiée dans la base de données de filtres 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. L’interface de service peut être une interface ms ou vms Services nouvelle génération avec carte de services MX-SPC3), ou une interface multiservices agrégée (AMS).

Prise en charge multilocataire du filtrage DNS

Vue d’ensemble

À partir de la version 21.1R1 de Junos OS, 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 sorte 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 sous le modèle ou le niveau du profil est désactivée. Il n’est pas nécessaire 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 gouffre IPv4, adresse de gouffre IPv6, FQDN de gouffre, 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 dans la [edit services web-filter] hiérarchie. La validation du fichier n’est réussie que si le hachage calculé correspond au hachage du 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é feed-name. 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 sur les noms de domaine mappés au 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 sur les noms de domaine mappés au nom de flux associé au modèle. Si le nom de flux n’est pas configuré dans le modèle, la recherche se fait en regard des noms de domaine mappés au nom de flux associé au profil.

Configuration de la prise en charge multilocataire pour le filtrage DNS

  1. Configurez le filtre web.
  2. Activer la prise en charge multilocataire
  3. Configurez la clé de hachage du fichier global et la méthode de hachage.
    Remarque :

    Lorsque multi-tenant-hashest configuré, cela indique que le fichier de flux DNS global se compose uniquement de flux cryptés. Lorsque multi-tenant-hash s n’est pas configuré, cela 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 qui n’ont pas l’indicateur de nom de flux 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 gouffre effectuées pour chaque adresse IP client. La plage est de 1 à 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 gouffre 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 de liaison montante et descendante spécifiques, ou pour les requêtes DNS provenant de préfixes d’adresses IP sources spécifiques.
    1. Configurez le nom du modèle.
    2. Configurez le nom du flux. Avec le format multilocataire, vous ne pouvez plus ajouter de nom de fichier sous profil ou modèle. Le nom de flux spécifié sous profil a une priorité moindre par rapport à 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 côté serveur à laquelle le filtrage DNS est appliqué.
      Remarque :

      Si vous configurez les interfaces client-serveur ou les instances de routage client-serveur, des filtres implicites sont installés sur les interfaces ou les instances de routage pour diriger le trafic DNS vers le PIC des services pour le filtrage DNS. Si vous ne configurez ni les interfaces client/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).
    7. Configurez l’intervalle de journalisation des statistiques pour les requêtes DNS et pour les actions de gouffre effectuées pour chaque adresse IP client. La plage est de 1 à 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 gouffre 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 du flux configuré au niveau du terme est plus prioritaire que celui configuré sous le modèle. Toutefois, si le domaine du gouffre 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 par trimestre.
    13. Configurez que l’action sinkhole identifiée dans la base de données de filtres de domaine soit 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 nouvelle génération avec carte de services MX-SPC3), ou d’une interface multiservices agrégée (AMS).
  8. Si vous exécutez les services de nouvelle génération sur la carte de services MX-SPC3, configurez l’interface vms pour obtenir les informations FPC et PIC dans syslog.

Exemple : configuration de la prise en charge multilocataire pour le filtrage DNS

La 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-collez les commandes dans la CLI au niveau de la hiérarchie [modifier].

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

Vue d’ensemble

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 dans le cloud 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, ainsi que de leurs avantages lorsqu’ils sont intégrés aux routeurs MX Series.

Pour plus de détails sur la plate-forme et les informations sur la version, voir Explorateur de fonctionnalités .

Avantages

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

  • Offre une protection robuste contre les menaces sophistiquées et furtives grâce à une combinaison d’outils qui assurent une protection robuste contre les menaces sophistiquées et furtives.

  • Contrôle 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 croissantes nécessitant davantage de ressources informatiques, une bande passante réseau accrue pour recevoir plus de soumissions de clients et un grand espace de stockage pour les logiciels malveillants.

  • Fournit une inspection approfondie, des rapports exploitables et un blocage des logiciels malveillants en ligne.

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

Comprendre Policy Enforcer et Juniper ATP Cloud

Security Director de Juniper Networks 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 appareils 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 fonctionne comme un pare-feu.

  • Policy Enforcer (PE) apprend des conditions de menace, automatise la création de politiques et déploie les mesures sur les appareils Juniper du réseau.

  • Juniper Advanced Threat Prevention (Juniper ATP Cloud) protège tous les hôtes de votre réseau en utilisant un logiciel de détection des menaces dans le cloud 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 renseignements 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 inspection des logiciels malveillants (en fonction de vos paramètres de configuration). S’il est déterminé que le fichier est un logiciel malveillant, PE identifie l’adresse IP et l’adresse MAC de l’hôte qui a téléchargé le fichier. Selon une stratégie définie par l’utilisateur, cet hôte peut être placé dans un VLAN de quarantaine ou empêcher l’accès à 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 comme fonctionnalité de sécurité en ligne

  • À partir de la version 19.3R2 de Junos OS, avec les services de nouvelle génération comme fonctionnalité de sécurité en ligne

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 dans un environnement défini. Cette méthode est avantageuse pour éviter que des appareils individuels n’accèdent aux services cloud Juniper ATP sur Internet. Cela diminue ainsi la vulnérabilité des appareils qui se connectent à Internet.

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

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

Le processus IPFD (Sécurité 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 ATP Cloud cloud. Sur les plates-formes MX, le processus IPFD récupère les flux de commande et de contrôle IPv4/IPv6 à partir 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 enregistré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 s’agit threat-level d’un entier compris entre 1 et 10 pour indiquer le niveau de menace des fichiers analysés à la recherche de programmes malveillants et d’hôtes infectés. Ici, 1 représente le niveau de menace le plus bas 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’IP interdite et 4 indique le threat-level.

La base de données de flux C&C est synchronisée sur le moteur de routage de sauvegarde. L’IPFD partage ensuite l’information avec le processus de filtrage Web (filtré par URL). Le processus de filtrage Web lit le contenu du fichier et configure les filtres en conséquence.

Configuration de Sécurité Intelligence pour télécharger le flux CC à partir de Policy Enforcer

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

Filtrage Web (filtré par URL) - Présentation

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 pour bloquer les paquets destinés aux adresses IP bloquées et générer des journaux pour signaler l’incident.

La figure 5 illustre la manière dont le flux C&C est récupéré par l’IPFD puis traité par le processus de filtrage Web.

Figure 5 : Filtrage Web Filtering Web

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 un flux C&C extrait 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 un security-intelligence-policy profil de filtre Web basé.

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 de locataire ou VRF sont intégrés dans les syslogs sortants. Les cartes de politique de classe de service sont améliorées avec un nouveau user-attribute integer mot-clé à stocker et indiquer le niveau de menace.

Vous pouvez configurer le user-attribute integer dans 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<> dans le terme de filtre dfw pilotant l’action configurée pour chaque niveau de menace. La carte de stratégie est utilisée 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_security-intelligence
  • informations 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, enregistrés et échantillonnés en fonction de l’action de menace que vous configurez. Pour les scénarios à l’échelle, il est préférable d’échantillonner les paquets plutôt que l’option de journalisation. En plus des 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 des flux en ligne échantillonne les paquets et envoie les enregistrements de flux au format IPFIX à un collecteur de flux. Vous pouvez dériver le niveau de menace pour les paquets échantillonnés reçus par le collecteur externe en faisant correspondre l’adresse IP reçue des paquets échantillonnés avec l’entrée 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 mé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 de 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 indiqué 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 indiqué dans l’exemple suivant :

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

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

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

Voir aussi

  • politique_security-intelligence
  • Configuration de l’échantillonnage du trafic sur les routeurs MX, M et T Series

Filtrage GeoIP

Vue d’ensemble

Les flux GeoIP sont essentiellement une liste de correspondances d’adresses IP vers des indicatifs de pays. À partir de Junos OS 21.4R1, vous pouvez configurer des emplacements géographiques basés sur IP sur les routeurs MX Series afin d’extraire les flux GeoIP 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 récupérer les flux GeoIP à partir de Policy Enforcer. Comme pour les flux IP C&C ou IPv6 existants, IPFD télécharge les flux GeoIP à partir de Policy Enforcer. IPFD traduit le flux au format de fichier traité par le processus de filtrage Web (filtré par URL) par la suite.

À 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 C&C ou IPv6 existants, 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 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 des 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 dans 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é. Le groupe 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 dans 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 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 d’opérations de sécurité ou comme mesure temporaire pour les faux positifs. À partir de Junos OS version 21.4R1, vous pouvez autoriser ou bloquer certaines adresses IP en fonction de la configuration via un CLI ou un fichier. Vous pouvez configurer une liste distincte pour la liste d’autorisation et une liste distincte pour la liste de blocage, ou inclure les adresses IP dans un fichier et inclure le nom du fichier dans la configuration de la CLI.

Vous pouvez créer un IP-address-list à 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) dans 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) dans 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 liste de blocage global est le suivant :

Security Intelligence Policy Enforcement Version 2.0

Le processus de filtrage Web analyse la liste des adresses IP de la liste globale d’autorisation ou de blocage global et programme les termes de filtre 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ération
Descriptif
19.3R2
À partir de Junos OS version 19.3R2, 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 Junos OS version 19.3R2, cette même fonctionnalité est disponible pour les services de nouvelle génération sur MX240, MX480 et MX960.
19.3R2
À partir de la version 19.3R2 de Junos OS, vous pouvez configurer le filtrage DNS si vous exécutez des 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 la version 19.3R2 de Junos OS, avec les services de nouvelle génération comme fonctionnalité de sécurité en ligne
19.3R1
À 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
18.4R1
À partir de Junos OS version 18.4R1 avec les services adaptatifs comme fonctionnalité de sécurité en ligne
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 la version 18.3R1 de Junos OS, configurez le profil au niveau de la [edit services url-filter] hiérarchie.
17.2R2
À partir de Junos OS versions 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 filtres d’URL.