Sécurité des systèmes informatiques/Sécurité informatique/Filtrage d'URL

Sécurité des systèmes informatiques

• Introduction
• Fonctionnement dans une entreprise
  • Le domaine SSI
    • Documents SSI
  • La veille technologique sécurité
    • Scénarios
  • Administration/Exploitation
  • Environnement
  • Législation
• Moyens techniques de protection
  • Réseau et firewall
    • Aspects architecturaux
      • Utilisation de DMZ
      • Diversification et haute-disponibilité
  • Systèmes d'authentification
  • Chiffrement de flux et VPN
  • Détection d'intrusion
  • Gestion des traces
  • Observation, surveillance, supervision
• Protection et applications usuelles
  • Antivirus
  • Traces et mots de passe Windows
  • Serveur HTTP
  • Filtrage d'URL
  • Signature et messagerie
  • Serveur DNS (BIND 9)
  • PKI et signatures
  • Routage dynamique
  • Active directory
  • Samba
• Recherche de vulnérabilités

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

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

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

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.

Page d'interdiction du logiciel de filtrage WebSense

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.

Quelques catégories de filtrage disponibles avec WebSense