Sécurité des systèmes informatiques/Sécurité informatique/Filtrage d'URL
Parmi les relais utilisables pour assurer des fonctions de sécurité, les relais HTTP font partie des plus répandus étant donné la forte utilisation du protocole HTTP. Un des intérêts de disposer d'un relais HTTP est notamment de pouvoir y associer un logiciel dit de filtrage d'URL. L'objectif de ce filtre est de contrôler les accès HTTP sortants et si besoin d'interdire des URL correspondant à des sites indésirables. En effet, dans un contexte professionnel par exemple, le contrôle de l'accès à certains sites doit pouvoir être mis en œuvre pour éviter les débordements. Mais dans un contexte moins étroit, on peut aussi vouloir interdire l'accès à certaines catégories de sites à des enfants chez soi ou dans une école par exemple. Enfin, du point de vue de la sécurité, des contraintes légales (sites étrangers violant les lois françaises) ou des besoins techniques (sites hébergeant des codes malveillants) conduisent à se doter d'un moyen de contrôle permettant de limiter les accès.
Une des principales difficultés dans la réalisation du filtrage d'URL est de classifier de manière fiable les différents sites Web présents sur Internet et leurs URL. Cet effort de classification à d'abord été orienté en direction des sites associés à des catégories de caractère très marqué : pornographique, violent, piratage/malveillance, publicité, drogue, etc.
Les éditeurs de logiciels de filtrage commerciaux ont poursuivi cet effort de manière à atteindre une classification plus fine de l'ensemble des sites Web permettant, par certains côtés, de mettre en place des autorisations d'accès thématiques. On trouve ainsi des catégories du type « Éducation », « Gouvernement », « Jeux », « Recherche d'emploi », « Sport », « Voyages », etc. Ces catégories sont parfois divisées en sous-catégories, par exemple pour faire la différence entre des sites consacrés au piratage et ceux diffusant de l'information sur la sécurité informatique. Un tel effort de classification n'est pour l'instant disponible que parmi des solutions commerciales, dont la plus répandue semble être le logiciel Websense mais parmi lesquels on trouve également CyberPatrol ou Sentian.
Nous nous intéresserons tout d'abord plus en détail à la mise en œuvre d'un tel filtrage à l'aide de logiciels libres et notamment à l'aide du cache Squid et du logiciel de filtrage associé SquidGuard.
Squid
[modifier | modifier le wikicode]Squid est un des premiers et des principaux relais HTTP mis en place dans l'infrastructure Web d'Internet. L'objectif initial de ce relais est de fournir des fonctions de cache permettant de réduire les communications vers Internet en stockant les informations les plus demandées dans un cache proche des utilisateurs. Cette fonction d'apparence simple a été implémentée de manière assez avancée dans Squid dans l'objectif de pouvoir déployer des hiérarchies de caches offrant des performances accrues. Squid supporte complètement le protocole de communication inter-caches ICP [RFC 2186] permettant à des caches voisins ou proches parents dans la hiérarchie de se tenir informé du contenu des autres caches proches d'eux de manière à optimiser l'utilisation de l'ensemble des espaces de stockage affectés à cette tâche. Squid offre également une large palette de fonctions comme l'authentification des clients, la redirection, l'intégration avec des outils de filtrage, la surveillance via SNMP, un cache DNS, un mode d'accélération de site Web, etc. L'intérêt pratique des caches HTTP du point de vue des performances a largement décru avec l'apparition de plus en plus courante de contenus dynamiques sur les sites Web d'Internet, mais ils constituent néanmoins un outil indispensable dans la boite à outils des administrateurs Web, réseau ou sécurité, notamment en raison du filtrage qu'ils rendent possible.
Squid permet tout d'abord de limiter les clients autorisés à l'accéder en fonction de leur adresse IP. Ce contrôle est réalisé à l'aide de directives de configuration suivant les caractéristiques indiquées ci-dessous :
- Les directives ont deux composantes :
- des éléments (ACL elements) ;
- et des règles (access lists rules).
- Il est possible de combiner ces éléments avec des règles logiques :
acl_type {allow|deny} acl AND acl AND ...
OR acl_type {allow|deny} acl AND acl AND ...
OR ...
- Enfin, les exemples suivants montrent comment sont rédigées les autorisations :
acl all src 0/0 http_access deny all acl myclients src 1.2.3.0/24 http_access allow myclients
Les informations suivantes extraites de la documentation d'origine de Squid détaillent l'ensemble des éléments utilisables pour la configuration des accès :
Squid knows about the following types of ACL elements3 : src: source (client) IP addresses dst: destination (server) IP addresses myip: the local IP address of a client's connection srcdomain: source (client) domain name dstdomain: destination (server) domain name srcdom_regex: source (client) regular expression pattern matching dstdom_regex: destination (server) regular expression pattern matching time: time of day, and day of week url_regex: URL regular expression pattern matching urlpath_regex: URL-path regular expression pattern matching, leaves out the protocol and hostname port: destination (server) port number myport: local port number that client connected to proto: transfer protocol (http, ftp, etc) method: HTTP request method (get, post, etc) browser: regular expression pattern matching on the request's user-agent header ident: string matching on the user's name ident_regex: regular expression pattern matching on the user's name src_as: source (client) Autonomous System number dst_as: destination (server) Autonomous System number proxy_auth: user authentication via external processes proxy_auth_regex: user authentication via external processes snmp_community: SNMP community string matching maxconn: a limit on the maximum number of connections from a single client IP address req_mime_type: regular expression pattern matching on the request content-type header arp: Ethernet (MAC) address matching rep_mime_type: regular expression pattern matching on the reply (downloaded content) content-type header. This is only usable in the http_reply_access directive, not http_access. external: lookup via external acl helper defined by external_acl_type »
Une fois définis, ces éléments peuvent être utilisés pour accorder ou non des accès en utilisant les types d'ACL suivants :
There are a number of different access lists : http_access: Allows HTTP clients (browsers) to access the HTTP port. This is the primary access control list. http_reply_access: Allows HTTP clients (browsers) to receive the reply to their request. This further restricts permissions given by http_access, and is primarily intended to be used together with the rep_mime_type acl type for blocking different content types. icp_access: Allows neighbor caches to query your cache with ICP. miss_access: Allows certain clients to forward cache misses through your cache. This further restricts permissions given by http_access, and is primarily intended to be used for enforcing sibling relations by denying siblings from forwarding cache misses through your cache. no_cache: Defines responses that should not be cached. redirector_access: Controls which requests are sent through the redirector pool. ident_lookup_access: Controls which requests need an Ident lookup. always_direct: Controls which requests should always be forwarded directly to origin servers. never_direct: Controls which requests should never be forwarded directly to origin servers. snmp_access: Controls SNMP client access to the cache. broken_posts: Defines requests for which squid appends an extra CRLF after POST message bodies as required by some broken origin servers. cache_peer_access: Controls which requests can be forwarded to a given neighbor (peer). »
SquidGuard
[modifier | modifier le wikicode]En utilisant les mécanismes de redirection disponibles au niveau de Squid, il est possible de développer un redirecteur jouant le rôle d'un outil de validation et de contrôle d'accès des URL accédées. C'est exactement ce que réalise le logiciel SquidGuard, en utilisant des techniques particulières pour gérer des listes de grande taille (plus de 100 000 entrées pour la catégorie porn par exemple) le plus efficacement possible.
La configuration de SquidGuard passe également par la définition de listes de contrôle d'accès indiquant pour certaines population d'utilisateurs les règles de filtrage à appliquer. On notera que ces règles peuvent prendre en compte des plages horaires pour modifier les autorisations d'accès en fonction du moment de la journée.
Enfin, le site de SquidGuard propose un ensemble de listes noires vérifiées périodiquement ; mais dont la mise à jour est essentiellement effectuée manuellement.
Voici un exemple assez facile à comprendre de configuration utilisable avec SquidGuard :
logdir /usr/local/squidGuard/log
dbhome /usr/local/squidGuard/db
src grownups { ip 10.0.0.0/24 user foo bar }
src kids { ip 10.0.1.0/24 }
dest porn { domainlist porn/domains urllist porn/urls }
acl {
grownups { pass all }
kids { pass !porn all }
default {
pass none
redirect http://info.foo.bar/cgi/blocked?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&targetgroup=%t&url=%u
}
}
Le seul point délicat est la présence impérative d'une page de redirection accessible par Squid pour signaler à l'utilisateur l'interdiction d'accès. Si on souhaite éviter la configuration manuelle des différents logiciels mentionnés ici (Squid et SquidGuard) il est possible sous Unix, notamment pour le premier, de disposer d'un outil de configuration plus convivial au travers du système d'administration Webmin. Un guide de configuration convivial et détaillé est disponible en français sur ce sujet (http://christian.caleca.free.fr/squid/).
Relais commerciaux et filtrage
[modifier | modifier le wikicode]Les relais HTTP disponibles dans le domaine commercial fonctionnent généralement de la même manière que le couple Squid+SquidGuard que nous avons déjà détaillé. Ils s'appuient sur un logiciel tiers dédié à la réalisation du filtrage d'URL.
La figure suivante présente un exemple de filtrage réalisé par le logiciel WebSense lors d'un accès HTTP au travers d'une infrastructure de proxy HTTP utilisant Microsoft ISA.
La figure suivante présente l'état de la configuration de filtrage mise en place dans ce cas particulier pour WebSense. Même avec une liste partielle, on note le nombre important de catégories de site Web disponibles par rapport à des listes noires librement disponibles. La fréquence des mises à jour est aussi probablement plus importante.
