Intégration via le protocole ICAP
Une intégration d'Olfeo On premises en ICAP avec un équipement tiers est possible si vous disposez déjà d'un équipement tiers qui réalise le routage et/ou la proxification du trafic et que vous souhaitez déléguer la catégorisation du trafic et/ou le filtrage à Olfeo On premises.
L’intégration s’appuie sur l'ICAP (Internet Content Adaptation Protocol), un protocole léger de type HTTP. Ce protocole offre une méthode standardisée pour adapter le contenu de requêtes/réponses HTTP selon différentes règles et ainsi par exemple étendre les fonctionnalités d'un proxy et/ou diminuer la charge supportée par ce proxy.
Contraintes, Limitations, Avantages
Dans ce mode, Olfeo On premises ne réalisant ni authentification forte, ni déchiffrement, la charge supportable du filtrage web (en req/sec) est très supérieure aux intégrations en proxy.
Seules les méthodes d'identification gérées par le moteur de filtrage sont compatibles avec une intégration ICAP : voir Identification et authentification : définitions. Cette fonction doit être réalisée par votre équipement.
SI vous souhaitez analyser l'URL et/ou le contenu des charges utiles, le déchiffrement doit être réalisé par l'équipement tiers.
Pour limiter la latence, placez Olfeo On premises au plus près de l'équipement réalisant la proxyfication.
Fonctionnalités compatibles
Compatibles :
Filtrage web (REQMOD)
Antivirus, analyse de contenu transmis par le proxy (RESMOD)
Domaine Olfeo & haute disponibilité
Non compatibles :
Toutes les fonctions liées au proxy lui-même (authentification, cache, QoS, quotas, déchiffrement SSL, statistiques en volume de données et quotas en volume) car le flux ne passe pas par le proxy interne à la solution.
Fonctionnement
L'utilisateur tente d'accéder à une page web.
Le flux arrive à l'équipement tiers, qui interroge Olfeo On premises. Les informations transmises peuvent varier suivant l'usage fait du produit (catégorisation seule, filtrage, analyse de contenus...).
Le moteur de filtrage évalue la requête (politiques, règles du moteur) et décide si elle doit être bloquée ou non.
Si la requête est autorisée, Olfeo On premises renvoie la requête à l'équipement tiers (3), qui l'effecture alors vers la ressource demandée (4) (5) et lui retourne éventuellement la réponse (6) pour analyse (7) avant de la retourner à l'utilisateur (8).
Si le flux n'est pas autorisé, Olfeo On premises renvoie un contenu adapté à l'équipement tiers, qui le retourne ensuite à l'utilisateur (par ex: une URL de redirection vers une page de blocage ou un contenu HTML modifié).
Réaliser une intégration ICAP avec un équipement tiers
Ajoutez un connecteur ICAP depuis l'interface d'administration dOlfeo On premises (voir ci-dessous),
Paramétrez l'équipement tiers pour diriger les flux vers l'adresse IP d'Olfeo On premises et vers le port que vous avez défini lors de la création du connecteur : référez-vous à la documentation de votre équipement.
Les connecteurs ICAP peuvent servir deux objectifs:
Analyser et adapter -ou non- le contenu des réponses des serveurs reçues par le proxy : typiquement pour une analyse antivirale sur certains contenus. C'est le cas le plus courant.
Analyser et adapter la réponse à une requête d'un équipement tiers (souvent d'un proxy HTTP tiers) : typiquement pour des cas d'usages où Olfeo On premises est utilisé comme moteur de filtrage seul mais pas comme proxy.
Connecteur par défaut
Par défaut Olfeo On premises est fournie avec un connecteur ICAP configuré en RESMOD pour être utilisé avec l'antivirus intégré à Olfeo On premises.
Sa configuration par défaut est suffisante dans une majorité de cas d'usages. Toutefois il est possible de modifier les options ICAP de cette configuration par défaut pour améliorer le comportement de la solution dans certains cas d'usages marginaux.
Ajouter un connecteur
Note
Chaque connecteur est une instance du serveur ICAP inclus dans le moteur de filtrage. Un connecteur est défini sur un port précis du moteur de filtrage.
Un même connecteur peut recevoir des flux en provenance de plusieurs équipements. Un seul connecteur par équipement est suffisant : créer 2 connecteurs aux paramétrages identiques ne permet pas de traiter deux fois plus de données.
Pour ajouter un connecteur supplémentaire :
Rendez vous sur → → .
Cliquez sur Ajouter un connecteur.
Saisissez un nom et une description.
Saisissez un numéro de port qui ne soit pas déjà utilisé par ailleurs.
Le port par défaut est
1344.Configurez les options du connecteur, notamment :
Activez REQMOD si vous souhaitez que le connecteur soit utilisé pour faire du filtrage d'URL
Activez RESMOD si vous souhaitez que le connecteur soit utilisé pour faire de l'analyse de contenus (antivirus)
Retrouvez ici les caractéristiques des autres options du connecteur ICAP.
Enregistrez pour activer le connecteur.
Les paramètres définis ici seront communiqués au client ICAP lors de la requête OPTIONS.
Option | Mode | Description |
|---|---|---|
Taille limite de Preview | REQMOD et RESPMOD | Utilisé si la case Prévisualiser en RESPMOD et/ou Prévisualiser en REQMOD est cochée. Taille qui sera annoncée par le moteur de filtrage (le serveur ICAP) comme étant la taille maximale de l'aperçu qu’il souhaite recevoir. Cette valeur correspond au nombre de caractères du body de la réponse HTTP (les en-têtes sont toujours transmis). La valeur par défaut, 63 Ko, est la taille maximale de l'aperçu que peut envoyer le client ICAP du proxy HTTP interne à la solution Olfeo. Cette taille peut en revanche être plus grande avec d’autres clients ICAP : fixez cette valeur en fonction de votre équipement. |
Bufferisation de la réponse | RESPMOD | Chaque requête ICAP reçue par le serveur ICAP est mise en attente par celui-ci (en mémoire ou sur le disque) : définissez la quantité de données à bufferiser.
Cas des réponses sans taille annoncée Le paramètre permet également de définir la taille jusqu'à laquelle analyser les contenus lorsqu'une réponse HTTP ne contient pas de taille annoncée, c'est-à-dire pas d'en-tête HTTP Content-Length. Le fichier peut par exemple ne pas annoncer de taille à cause d'un problème de configuration du serveur distant, ou avoir une taille infinie (streaming). (Si la réponse annonce sa taille, c'est le paramètre Taille maximum qui est pris en compte.) Le moteur de filtrage met en attente (en mémoire ou sur le disque) le contenu de la réponse HTTP jusqu’à cette taille.
Voir aussi Gestion de la taille des fichiers reçus. |
Taille maximum | RESPMOD | Utilisé uniquement lorsque les réponses HTTP indiquent leur taille (dans l'en-tête HTTP Content-Length). (Si la taille n'est pas indiquée, c'est le paramètre Bufferisation de la réponse qui est utilisé.)
Valeur par défaut : 10 Mo .Voir aussi Gestion de la taille des fichiers reçus. |
Prévisualiser en RESPMOD | RESPMOD | Indique si le serveur doit déclarer au client qu'il accepte les prévisualisations en mode “modification de réponse” dans la requête OPTIONS. Cette option doit être activée pour que les règles de l’onglet Aperçu soient appliquées. Certains clients déclarent savoir gérer la prévisualisation alors qu'ils ne la gèrent pas : dans ce cas, décochez la case. Le client devra envoyer le contenu entier. Les règles de l'onglet Aperçu seront ignorées. |
Prévisualiser en REQMOD | REQMOD | Indique si le serveur doit déclarer au client qu'il accepte les prévisualisations en mode “modification de requête” dans la requête OPTIONS. La prévisualisation en REQMOD concerne l'upload de fichiers et les informations envoyées avec la méthode POST. Si la prévisualisation est désactivée (si la case est décochée), le fichier uploadé doit transiter par le moteur de filtrage, ce qui peut prendre du temps. Cependant, le moteur de filtrage n'a pas besoin du contenu du fichier uploadé pour prendre une décision de blocage ou non (l'Olfeo n'effectue pas de filtrage sur les fichiers uploadés). Cochez la case pour que seule une partie du fichier soit transmise au moteur de filtrage, afin d'éviter un transfert de données inutile. La taille du preview est celle indiquée dans le champ Taille limite de Preview. |
Ne pas tenir compte de la prévisualisation | REQMOD et RESPMOD | Paramètre permettant de prendre en charge le comportement de certains clients ICAP. Certains clients ICAP ne savent pas gérer la prévisualisation correctement : ils envoient l'ensemble de la requête en indiquant qu'il ne s'agit que d'un aperçu. Ce paramètre permet de considérer toutes les requêtes ICAP comme complètes même si le client indique qu'il s'agit d'un aperçu. Les règles de l'onglet Aperçu sont évaluées. |
Accepter d'utiliser le 204 | RESPMOD | Paramètre permettant de prendre en charge le comportement de certains clients ICAP.
Attention, les échanges sont plus lents si l'on n'utilise pas de réponses 204. |
Transfert des données par défaut | RESPMOD | Permet de définir le comportement de l'Olfeo pour les gros fichiers qui mettront du temps à être transmis à l'utilisateur. La valeur définie ici est une valeur par défaut : elle peut être surchargée via une règle de l'onglet Aperçu du moteur de règles (action Transfert des données). L'action Transfert des données par défaut est effectuée si la taille annoncée est supérieure à 1024 ko, et inférieure à la taille définie dans le paramètre Taille maximum.
|
Expiration de la page de patience | RESPMOD | Utilisé si le paramètre Transfert des données par défaut a la valeur Page de patience, ou si une règle du moteur définit une action Transfert des données avec la valeur Page de patience. Cette valeur indique combien de temps le moteur de filtrage doit attendre un morceau de fichier avant de considérer la connexion caduque et de mettre un terme à la page de patience. |
Forcer l'authentification ICAP au format LDAP | REQMOD et RESPMOD | Les clients ICAP peuvent fournir les informations d'identité des utilisateurs dans différents formats. Par défaut, le serveur ICAP du moteur de filtrage n'attend pas ces informations au format LDAP. Si le client ICAP que vous utilisez envoie ces informations au format LDAP (DN LDAP), cochez cette case pour le signaler au moteur de filtrage. |
Utiliser X-Forwarded-For au lieu de X-Client-IP | REQMOD et RESPMOD | Pertinent si l'Olfeo est couplé avec un proxy faisant de l'authentification, et que ce proxy est également proxy parent. Si la case est cochée, le moteur de filtrage déterminera l'adresse IP de l'utilisateur à partir de l'en-tête X-Forwarded-For. En effet, si le proxy est proxy parent, l'en-tête X-Client-IP donne l'adresse IP du proxy enfant et non celle de l'utilisateur. |
Utiliser X-Forwarded-User pour récupérer l'identifiant depuis l'en-tête HTTP | REQMOD et RESPMOD | Pertinent si l'Olfeo est couplé avec un proxy lui-même parent d'un proxy réalisant de l'authentification. Si la case est cochée, le moteur de filtrage récupérera l'identifiant de l'utilisateur à l’origine de la requête depuis l'en-tête X-Forwarded-User de la requête HTTP incluse dans la requête ICAP. L'en-tête contient l'information au format suivant : |
Utiliser l'en-tête ICAP X-Authenticated-Groups | REQMOD et RESPMOD | Cette option peut être utilisée lorsque l'équipement tiers transmet le libellé du groupe auquel appartient l'utilisateur, encodé en base 64 dans l'en-tête ICAP X-Authenticated-Groups. L'Olfeo se base alors sur le groupe de l'utilisateur pour appliquer règles et politiques (colonne Source du moteur de règles, politiques). Cela permet d'appliquer des règles ou des politiques au niveau d'un groupe lorsqu'on ne dispose pas d'autre moyen d'identification. Attention, pour que cette option fonctionne, l'option Utiliser X-Forwarded-User pour récupérer l'identifiant depuis l'en-tête HTTP doit être décochée. |
Tenter de résoudre la fin des en-têtes HTTP même s'ils ne sont pas corrects | REQMOD et RESPMOD | Certains serveurs HTTP utilisent à mauvais escient des caractères correspondant aux fins de ligne Unix dans leurs en-têtes, ce qui génère une erreur ICAP dans le navigateur et une entrée dans le journal d'évènements (à la page → → ). Cocher cette case permet de supprimer de telles erreurs mais affecte légèrement les performances. |
En cas de blocage, REQMOD envoie directement une réponse HTTP | REQMOD | Paramètre permettant de prendre en charge le comportement de certains clients ICAP.
|
En REQMOD, transmettre la catégorie Olfeo correspondant à la requête | REQMOD | Si la case est cochée, le serveur ICAP ajoute un en-tête X-Olfeo-Category à la réponse REQMOD. Cet en-tête indique l'ID de la catégorie Olfeo correspondant au domaine vers lequel pointe la requête. L'ID dépend de la version de la base d'URLs installée (version France, Belgique...). |
Transmettre l'ID de la catégorie correspondant à la requête | REQMOD et RESPMOD | Si la case est cochée, l'Olfeo envoie à l'équipement tiers l'ID de la catégorie correspondant au domaine de destination de la requête, dans un en-tête ICAP X-Olfeo-Category-ID. Cet ID dépend de la base d'URLs Olfeo installée. |
Transmettre le libellé de la catégorie correspondant à la requête | REQMOD et RESPMOD | Si la case est cochée, l'Olfeo envoie à l'équipement tiers le libellé de la catégorie correspondant au domaine de destination de la requête, dans un en-tête ICAP X-Olfeo-Category. |
Transmettre la décision de filtrage | REQMOD et RESPMOD | Si la case est cochée, l'Olfeo envoie à l'équipement tiers la décision prise par le moteur de filtrage, dans un en-tête ICAP X-Olfeo-Status. Valeurs possibles : Allowed, Denied. |