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é.
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.
HTTP
La figure 2 illustre le filtrage des URL pour les sessions HTTPS.
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 .
| 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
template1 {
client-interfaces [ xe-4/0/3.35 xe-4/0/3.36 ];
server-interfaces xe-4/0/0.31;
dns-source-interface xe-4/0/0.1;
dns-routing-instance data_vr;
routing-instance data_vr2;
dns-server 50.0.0.3;
dns-retries 3;
url-filter-database url_database.txt;
term term1 {
then {
tcp-reset;
}
}
term term2 {
then {
redirect-url www.google.com;
}
}
}
Si vous omettez plus d’une from instruction par modèle, vous obtiendrez le message d’erreur suivant lors de la validation :
URLFD_CONFIG_FAILURE: Configuration not valid: Cannot have two wild card terms in template template1 error: configuration check-out failed
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.