Présentation du filtrage Web
Le filtrage Web vous permet de gérer l’utilisation d’Internet en empêchant l’accès à du contenu Web inapproprié. Il existe trois types de solutions de filtrage Web :
Filtrage Web de redirection : la solution de filtrage Web de redirection intercepte les requêtes HTTP et HTTPS et les envoie à un serveur de filtrage d’URL externe, fourni par Websense, pour déterminer s’il faut bloquer les requêtes.
Le filtrage Web redirigé ne nécessite pas de licence.
Filtrage Web local : la solution de filtrage Web local intercepte chaque requête HTTP et la requête HTTPS dans une connexion TCP. Dans ce cas, la prise de décision est effectuée sur l’appareil après qu’il a recherché une URL pour déterminer s’il figure dans la liste d’autorisation ou la liste de blocage en fonction de la catégorie définie par l’utilisateur.
Le filtrage Web local ne nécessite pas de licence ni de serveur de catégorie distant.
Filtrage Web amélioré : la solution de filtrage Web amélioré intercepte les requêtes HTTP et HTTPS et envoie l’URL HTTP ou l’adresse IP source HTTPS au Websense ThreatSeeker Cloud (TSC). Le TSC catégorise l’URL dans l’une des 151 catégories prédéfinies et fournit également des informations sur la réputation du site. Le TSC renvoie en outre la catégorie d’URL et les informations de réputation du site à l’appareil. L’appareil détermine s’il peut autoriser ou bloquer la demande en fonction des informations fournies par le TSC.
La redirection Websense prend en charge le trafic IPv6.
Le filtrage Web utilise la prise en charge de JDPI-Decoder pour le traitement des données de l’application. Vous devez activer le décodeur JDPI pour appliquer la fonctionnalité de filtrage Web. Le décodeur JDPI a besoin d’AppID pour traiter les données de l’application.
Vous pouvez lier des profils de filtrage Web ou des profils antivirus, ou les deux, à une stratégie de pare-feu. Lorsque les deux sont liés à une stratégie de pare-feu, le filtrage Web est appliqué en premier, puis l’antivirus est appliqué. Si une URL est bloquée par le filtrage Web, la connexion TCP est fermée et aucune analyse antivirus n’est nécessaire. Si une URL est autorisée, le contenu de la transaction est alors transmis au processus d’analyse antivirus.
Le filtrage Web est appliqué par numéro de port TCP.
Le filtrage Web prend en charge le protocole HTTPS. La solution de filtrage Web utilise l’adresse IP du paquet HTTPS pour établir des décisions sur liste de blocage, d’autorisation, d’autorisation ou de blocage.
Lors d’une décision de blocage, la solution de filtrage Web ne génère pas de page de blocage, car le texte clair n’est pas disponible pour une session HTTPS. Cependant, la solution met fin à la session et envoie des réinitialisations au client et au serveur pour les sessions HTTPS bloquées.
La configuration du filtrage Web pour HTTP s’applique également aux sessions HTTPS.
La commande CLI sessions-per-client limit , qui impose une limitation de session pour empêcher un utilisateur malveillant de générer simultanément de grandes quantités de trafic, ne prend pas en charge le filtrage Web.
Le trafic relais IPv6 pour les protocoles HTTP, HTTPS, FTP, SMTP, POP3, IMAP est pris en charge pour les fonctionnalités de sécurité de filtrage Web et de filtrage de contenu de Content Security.
Prise en charge de l’indication du nom du serveur (SNI)
Le SNI est une extension du protocole SSL/TLS qui indique le nom du serveur que le client contacte via une connexion HTTPS. SNI insère le nom d’hôte réel du serveur de destination dans le message « Client Hello » au format texte clair avant la fin de l’établissement de liaison SSL. Le filtrage Web inclut les informations SNI dans la requête. Dans cette implémentation, le SNI inclut uniquement le nom du serveur, et non l’URL complète du serveur. La prise en charge de SNI améliore la fonctionnalité de filtrage Web, car l’utilisation uniquement de l’adresse IP de destination dans la requête peut entraîner des résultats inexacts, car plusieurs serveurs HTTP peuvent partager la même adresse IP d’hôte.
Avec la prise en charge de SNI, le filtrage Web analyse le premier paquet du trafic HTTPS sous la forme d’un message « Client Hello » et extrait le nom du serveur de l’extension SNI, puis utilise le nom du serveur ainsi que l’adresse IP de destination pour maintenir/exécuter la requête. Si ce paquet n’a pas d’extension SNI ou si une erreur est rencontrée lors de l’analyse, le filtrage Web revient à utiliser uniquement l’adresse IP de destination.
Dans le filtrage Web (EWF), si une session HTTPS avec proxy de transfert SSL est activée, l’indication du nom du serveur (SNI) est obtenue avant le filtrage Web et utilisée pour la requête de pré-vérification, la réputation du site et la catégorie en réponse. Si le cache est activé, ces réponses remplissent le cache sans aucune action. EWF extrait le chemin complet et vérifie s’il y a un cache. Si le chemin d’accès complet dans le cache ne correspond pas, l’EWF envoie une requête.
La fonctionnalité SNI est activée par défaut pour tous les types de filtrage Web. Par conséquent, aucune configuration supplémentaire à l’aide de la CLI n’est requise.
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.