Sécurité des systèmes informatiques/Sécurité informatique/Protection réseau et firewall

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

Le composant privilégié de la protection réseau sur TCP/IP reste le firewall. Sous cette désignation générique, qui cache parfois des technologies extrêmement différentes, on désigne en réalité la mise en place d'un système informatique placé en situation de coupure par rapport aux flux de communication réseau, et capable d'autoriser ou d'interdire ces flux en fonction de son paramétrage. Lequel est généralement appelé la « politique de sécurité » du firewall. C'est une dénomination un peu abusive à notre sens, et nous préférerons parler des règles de filtrage réseau du firewall, ou plus simplement des règles du firewall quand le contexte ne permet pas de confusion.

Bien que formellement un niveau de sécurité identique (voire supérieur) puisse être atteint avec d'autres approches, la mise en place d'un firewall reste une voie largement répandue pour tenter d'améliorer la sécurité d'un système informatique et de son réseau. En effet, dans un système informatique pré-existant, ce type d'équipement présente l'avantage d'être indépendant des systèmes informatiques déjà présents, qu'il s'agisse de serveurs d'applications, de serveurs de fichiers, ou d'équipements d'interconnexion réseaux. Cette autonomie est vérifiée à la fois du point de vue technique mais aussi du point de vue de l'administration et donc par rapport à l'organisation d'un service informatique (où l'intégration d'un périmètre de responsabilité et de compétence nouveau n'est pas forcément facile). Par ailleurs, bien qu'il soit assez intrusif (il faut qu'un firewall soit en coupure des flux réseaux pour remplir sa fonction) et parfois difficile à paramétrer quand les flux sont nombreux (notamment dans le cas d'un réseau d'entreprise segmenté en interne) ce type d'équipement se positionne assez naturellement dans le réseau au niveau des interconnexions entre organismes, entre sites, ou entre une entreprise et les réseaux externes (généralement Internet). Quoiqu'elle fasse rarement l'objet d'une réelle justification en terme de besoins de sécurité, cette mise en place en « entrée » et en « sortie » du réseau est facile à proposer et à appréhender, notamment par les décideurs. Enfin, malgré tout, par rapport à une situation antérieure où la sécurité n'est absolument pas prise en compte et notamment par rapport à des applications fermées, héritées et figées (ce qui ne veut pas forcément dire qu'elles soient anciennes), la mise en place d'un firewall reste une réelle opportunité d'obtenir le minimum de contrôle et de protection qui est désormais nécessaire pour un système d'information professionnel.

Par contre, du point de vue de la mise en œuvre technique, un firewall est un équipement assez intéressant, touchant à la fois au fonctionnement protocolaire d'IP, de TCP, et d'UDP, ainsi qu'éventuellement au fonctionnement des applications. Même en se limitant aux protocoles principaux (TCP et UDP), la réalisation efficace du filtrage réseau, à la fois en terme de performance, de facilité d'administration et de sécurité, implique des fonctions assez avancées comme le suivi de l'état des connexions TCP par exemple. Par ailleurs, ces systèmes offrent un certain nombre d'opportunités d'actions nouvelles dont certaines, comme la translation d'adresses, sont parfois cruciales pour offrir un accès réseau à un grand nombre d'utilisateurs, et d'autres comme la gestion de la qualité de service au niveau TCP sont techniquement très intéressantes pour améliorer la qualité des services réseaux.

Principaux modes de fonctionnement

Les premiers firewall ont débutés en offrant simplement des capacités de filtrage basées sur les adresses source et destination présentes dans chaque paquet IP, en complément des fonctions de la pile IP d'un système d'exploitation et notamment du routage. À l'heure actuelle ces fonctions, ne suffisent plus pour qualifier réellement un système informatique de firewall. Ces « filtres IP », quoique parfois particulièrement utiles, ne permettent pas de remplir le rôle de contrôle que l'on attend d'un système firewall complet. La confusion existe encore toujours parfois (par exemple, le « firewall personnel » intégré dans Windows XP semble bien être un simple moteur de filtrage IP) mais nous nous intéresserons dans ce chapitre à des logiciels plus avancés, capables d'effectuer des décisions de filtrage ne se limitant pas à l'examen de l'en-tête de chaque paquet IP pris isolément.

En excluant ces systèmes, deux grandes catégories de firewall restent à distinguer : les firewall avec suivi d'état, et les firewall basés sur des proxy. Ces catégories ne sont pas exclusives et les implémentations les plus sophistiquées mélangent parfois des idées provenant des deux approches.

Firewall avec suivi d'état

Les firewall avec suivi d'état sont capables de suivre les différentes étapes de la mise en place d'une communication réseau, et notamment toute la séquence d'une communication TCP : l'échange initial (SYN, SYN+ACK, ACK), les paquets de données (PSH, ACK) et la terminaison (RST, RST+ACK). Dans le cas d'UDP, qui reste normalement un protocole non connecté, le suivi d'état s'appuie généralement sur l'hypothèse d'un fonctionnement des applications en mode « question/réponse » dans lequel un message UDP initial est suivi d'un deuxième message en sens inverse contenant la réponse.

La prise en compte du fonctionnement normal de ces sessions TCP (ou des pseudo-sessions UDP) doit inclure également la prise en compte des erreurs de fonctionnement, comme l'émission éventuelle d'un paquet ICMP indiquant l'échec d'une tentative de connexion TCP ou de l'acheminement d'un message UDP. L'objectif du suivi d'état de ces firewall est d'utiliser l'ensemble des informations collectées sur le déroulement des sessions de communication afin d'autoriser seulement les paquets IP appartenant à une session à transiter sur le réseau, et de protéger au mieux cette communication en détectant (et en bloquant) tout fonctionnement anormal par rapport aux définitions protocolaires ou aux flux réseau usuels.

Le suivi d'état permet également de faciliter la définition des règles de filtrage en permettant une autorisation implicite des différents types de paquets IP associés à une communication : ainsi il n'est pas nécessaire de prévoir les autorisations IP bidirectionnelles nécessaires à la réponse à une demande UDP, ou au déroulement d'une communication TCP. La formulation des règles de filtrage est alors beaucoup plus naturelle : on autorise en quelque sorte seulement le premier paquet initiant une communication, les autres autorisations nécessaires étant automatiquement dérivés à l'aide des informations de suivi d'état.

Ce fonctionnement est également plus performant dans la pratique : en effet, les informations de suivi d'état sont associées aux communications actives. Les autorisations issues des tables d'état sont donc normalement relatives à la grande majorité des paquets IP manipulés à un instant t par la pile réseau. Ce sont donc celles qui peuvent faire l'objet d'une mise en œuvre prioritaire et particulièrement optimisée de manière à améliorer la performance de l'ensemble du firewall. Le parcours systématique de toutes les règles de filtrage du firewall (qui peuvent être extrêmement nombreuses si la configuration est très précise) n'est alors plus nécessaire que pour une minorité de paquets IP, ceux associés à des débuts de communication. Dans la pratique, ce mode de fonctionnement est fréquemment optimal et cette optimisation n'exclut que des types de trafic réseau quasiment pathologiques (comme des connexions extrêmement fréquentes et de très courte durée). Les firewall avec suivi d'état peuvent donc généralement supporter un nombre de règles de filtrage largement supérieur aux filtres IP (pourtant techniquement plus simples). Les dernières générations de firewall, notamment certaines visant à fournir des capacités de filtrage sur des réseaux Gigabit, mettent en œuvre ces autorisation basées sur les tables d'état directement au niveau hardware, dans des ASIC dédiés. La partie logicielle du firewall n'est alors sollicitée que pour l'examen des connexions nouvelles.

Firewall proxy

Face aux firewall à suivi d'état, qui ont connu une diffusion importante, l'apparition de composants de plus en plus sophistiqués (modules embarqués dans les noyaux des systèmes d'exploitation, logiciels influant sur le fonctionnement des piles réseau, voire mise en œuvre matérielle par des composants associés aux cartes réseaux) et une débauche d'investissement, les firewall basés sur les logiciels proxy peuvent parfois donner l'impression qu'ils ne sont pas en mesure de soutenir la compétition. Pourtant, à l'origine, cette approche de la mise en œuvre du filtrage des communications réseau visait avant tout à offrir le meilleur niveau de sécurité en envisageant de réexaminer, pour chaque application souhaitant communiquer au travers du firewall, le contenu du flux de communication, en tenant compte de la sémantique applicative.

Pour chaque type d'application, il faut alors disposer d'un logiciel proxy (relais) capable d'analyser dans une certaine mesure le flux de communication afin de le contrôler précisément (sans aller jusqu'à pouvoir l'exécuter, il faut que le proxy puisse comprendre le sens de la communication qu'il relaye), voire de n'autoriser que certaines des actions de communication possibles. Il est donc nécessaire de développer des relais spécifiques pour chaque application que l'on souhaite autoriser. En règle générale, on peut espérer disposer de relais concernant les principaux protocoles de communication utilisés :

• HTTP/HTTPS : pour la navigation Internet (avec une problématique plus particulière associée au chiffrement d'HTTPS dont le « relayage » peut impliquer un déchiffrement/rechiffrement).
• FTP : pour les échanges de fichiers et le contrôle des commandes admises (PUT, GET, DEL, etc.), ainsi que pour la prise en compte des différents modes de fonctionnement (actif, passif).
• Telnet : pour le contrôle éventuel du contenu de la session, mais surtout pour assurer une authentification additionnelle.
• X11 : pour éviter les débordements possibles via le protocole X11 tout en permettant un affichage à distance de qualité acceptable.
• SOCKS : pour réaliser un relayage « générique » de tout protocole TCP/UDP en ajoutant une authentification en sortie (si possible transparente).
• H.323 : pour aborder un protocole basé sur UDP mais n'utilisant absolument pas un mode de fonctionnement demande/réponse tout en ayant de fortes exigences de continuité du flux réseau (transport de la voix).

Cette approche, lourde en terme de développement, est, on le sent bien, également parfois problématique en terme de performance : le logiciel proxy effectue une analyse de type applicatif en supplément de celle effectuée sur la machine réellement destinataire.

Pourtant, malgré ces inconvénients, cette approche présente un certain nombre d'avantages, qui font que l'utilisation des proxy reste toujours incontournable dans de nombreuses configurations de filtrage réseau. D'abord, le développement d'un proxy, même s'il est limité à un seul type d'application, est généralement plus facile que la réalisation d'un module de système d'exploitation, s'exécutant sans protection mémoire dans un environnement très contraignant. Par ailleurs, les proxy, parfois en complément d'un firewall avec suivi d'état mais aussi parfois tout à fait isolément, sont nécessaires pour réaliser facilement certaines fonctions, comme le filtrage des commandes applicatives pour FTP, le filtrage d'URL dans le cas d'HTTP, la lutte contre le spam avec SMTP ou l'ajout d'une authentification transparente sur un relais générique. À l'inverse, certains firewall s'exécutant prioritairement en mode noyau en association avec un système de suivi d'état peuvent intégrer des interfaces modulaires visant justement à faciliter la mise en œuvre de règles de filtrage applicatif (c'est notamment le cas de Netfilter sous Linux).

En règle générale, les deux approches sont complémentaires. L'utilisation d'un relais peut s'avérer assez naturelle si l'application concernée intègre la notion de relayage dans son fonctionnement (c'est par exemple le cas avec SMTP) et si le système d'exploitation hôte, notamment son module de filtrage noyau, facilite la mise en œuvre du proxy. Le firewall dans son ensemble en est alors largement bénéficiaire. C'est une approche pragmatique qu'illustre bien OpenBSD : même si le firewall avec suivi d'état du noyau est un composant essentiel, à l'usage, l'importance des proxy disponibles se révèle rapidement pour certaines des problématiques mentionnées précédemment, et la coopération entre les deux éléments, quand elle permet le relayage transparent (transparent proxying) offre un réel confort aux utilisateurs finaux. (Ce qui n'est pas inutile pour faire passer l'ajout d'une barrière de sécurité additionnelle.)

Équipements et solutions disponibles

Solutions commerciales

La liste suivante tente de rassembler les principales solutions commerciales pertinentes au moment de la rédaction de cette section.

• Leaders
  • Firewall-1 (CheckPoint)
  • PIX (Cisco)
• Challengers
  • Netscreen
  • Cyberguard
  • ISA (Microsoft)
  • IOS FW (Cisco)
  • Sidewinder
  • SonicWall
  • WatchGuard
  • ...
• Français
  • Netwall (Evidian/Bull)
  • M>Wall (Matranet)
  • Arkoon
  • Netasq

Solutions open-source

Dans le domaine des logiciels librement disponibles, les principaux systèmes d'exploitation existants incluent également des composants logiciels susceptibles de jouer le rôle de firewall. Ceux-ci ont évolué progressivement, mais constituent à l'heure actuelle des mise en œuvre complètes et généralement très efficaces.

• OpenBSD pf (http://www.benzedrine.cx/pf.html) : Le firewall disponible avec le système d'exploitation OpenBSD constitue probablement une des implémentations les plus modernes d'un firewall complet. Elle a été démarrée en 2001 suite à un désaccord des principaux auteurs d'OpenBSD avec l'auteur du firewall utilisé à l'origine dans ce système d'exploitation (jusqu'à la version 3.0), IPFilter (voir ci-dessous). Ce désaccord concernait la licence d'IPFilter et il a conduit les principaux développeurs d'OpenBSD à retirer cette première implémentation exogène de leur distribution standard. Étant donné l'orientation résolument affirmée d'OpenBSD sur les problématiques de sécurité, ce vide a été rapidement comblé (en moins de 6 mois) par une implémentation nouvelle mais très complète d'un firewall à suivi d'état TCP/UDP avec des capacités de translation d'adresses (NAT). Cette implémentation, baptisée pf (pour Packet Filter) a continué à évoluer, en s'intégrant notamment étroitement avec le système de gestion de qualité de service réseau (QoS) ALTQ et en améliorant la facilité de gestion et les performances (avec des fonctions comme les listes d'adresses dynamiques, un logiciel séparé de gestion des traces, ou plus récemment des capacités d'optimisation des règles de filtrage et un protocole de gestion de la redondance). Le langage de définition des règles de filtrage est un langage textuel, dans la droite ligne des langages de configuration Unix, mais très commode (il a visiblement bénéficié de toute l'expérience d'administrateurs réseaux largement accoutumés aux problèmes de la protection et du filtrage). L'ensemble constitue désormais un logiciel très complet auquel il ne manque plus grand chose pour se mesurer aux meilleures implémentations commerciales en terme de fonctionnalités. Trois ans après la mise en œuvre initiale, pf a désormais été adopté par les cousins FreeBSD, NetBSD ou même DragonFlyBSD.
• Linux/IPTables (Netfilter) (http://www.netfilter.org/) : Le firewall intégré au noyau Linux a connu une évolution plus progressive, évoluant notamment avec la version 2.4 du noyau pour intégrer le suivi d'état (TCP, UDP, ou autre). Il a d'ailleurs changé de nom plusieurs fois, la version la plus aboutie étant baptisée Netfilter (ou IPTables, par abus du nom de l'utilitaire de configuration du noyau iptables(8)). Cette implémentation présente notamment la caractéristique d'une mise en œuvre extrêmement modulaire permettant la prise en charge de protocoles complexes ou nouveaux par le développement de modules de filtrage venant s'intégrer à Netfilter dans le noyau Linux.
• Linux/IPChains Linux/ipfwadm : Les versions plus anciennes du firewall Linux étaient baptisées IPChains (noyau 2.2) et ipfwadm (noyau 2.0). Il s'agissait là d'un filtre de paquet n'intégrant pas complètement le suivi d'état des sessions réseaux (notamment pour TCP). Elle fut assez populaire, car associée à une phase de forte diffusion du noyau Linux lui-même et probablement parce qu'elle intégrait des fonctions de translation d'adresses (appelées masquerading dans IPChains) au moment où leur intérêt devenait crucial, mais elle a été totalement remplacée par Netfilter. Elle est ici avant tout mentionnée pour éclaircir la confusion, parfois encore possible, entre le firewall du noyau Linux 2.2 (IPChains) et celui des noyaux ultérieurs à Linux 2.4 (Netfilter/IPTables), ou celle, quand même moins répandue, entre le firewall originel de FreeBSD et NetBSD (ipfw) et celui de Linux 2.0 (ipfwadm).
• IPFilter (http://coombs.anu.edu.au/ipfilter/) : Il est encore important de mentionner IPFilter dans le domaine des implémentations librement disponibles d'un logiciel firewall. Bien que désormais supplantée (notamment en terme de diffusion) par les alternatives issues d'OpenBSD et de Linux, IPFilter constitue encore une des rares mises en œuvre fonctionnant sur une gamme de systèmes d'exploitation, et notamment des Unix commerciaux (Solaris, HP-UX, etc.). C'est un firewall à suivi d'état TCP/UDP très complet, dont le langage de paramétrage a largement inspiré les réalisations plus modernes (notamment pf).
• ipfw : Il s'agit du firewall présent initialement dans les différents membres de la famille de système d'exploitation BSD (FreeBSD et NetBSD notamment). La tendance récente sur ces systèmes est à l'intégration de l'implémentation du firewall pf issu d'OpenBSD en remplacement d'ipfw, cité ici seulement pour mémoire.

Exemples

Intégration différée pour:

• validation éventuelle de l'utilisation des copies d'écran constructeur (Firewall-1 et PIX) ;
• à rédiger pour les firewall open-source (Linux/Netfilter et OpenBSD/pf prévus).

Authentification utilisateur

L'installation d'un firewall peut permettre d'introduire une authentification additionnelle sur des protocoles n'en comportant pas ou incluant une authentification offrant un niveau de sécurité insuffisant. Cette authentification est ajoutée assez naturellement dans le cas des firewall proxy : c'est alors le proxy qui prend en charge l'authentification d'un utilisateur souhaitant accéder à un service réseau contrôlé par le firewall ; mais elle est également possible avec les firewall fonctionnant au niveau TCP. Dans la plupart des cas, l'utilisation de cette authentification additionnelle implique l'installation sur le poste utilisateur d'un composant logiciel spécifique.

Voici quelques exemples de mise en œuvre de ce genre d'authentification :

• ajout d'une phase d'authentification aux sessions Telnet d'administration (par exemple à destination des machines en DMZ) afin de pallier au problème de la transmission du mot de passe en clair sur les sessions Telnet ;
• authentification et autorisation des accès HTTP via le protocole NetBIOS sur le firewall Microsoft ISA Server – cette authentification est totalement transparente si le navigateur Web utilisé la supporte (c'est bien évidemment le cas pour Internet Explorer sur système d'exploitation Microsoft) et constitue un des principaux avantages pratiques d'ISA Server avec Internet Explorer ;
• authentification transparente des flux réseaux relayés sur le protocole de relais générique SOCKS v5 [RFC 1928] avec des extensions pour la prise en compte de NetBIOS, en se basant sur la couche WinSOCKS existant dans les systèmes d'exploitation Microsoft ;
• authentification forte et protection dans un tunnel IPSEC des accès nomades sur un firewall type CheckPoint VPN-1, en utilisant un module d'accès SecuRemote ou SecureClient sur le poste client ;
• authentification forte des accès via une passerelle OpenBSD en conditionnant l'activation de règles de filtrage réseau à l'ouverture d'une session SSH sur le firewall en utilisant authpf(8) comme login shell.

QoS

Comme nous l'avons déjà mentionné précédemment, la gestion de la qualité de service nous semble s'effectuer très efficacement au niveau de la définition des règles de contrôle du trafic réseau constituant la politique de sécurité du firewall. Cette approche est notamment illustrée dans l'extension logicielle FloodGate-1 de CheckPoint, ainsi que dans l'intégration d'ALTQ avec PF sous OpenBSD permettant d'utiliser les règles de PF pour associer des paquets aux différentes classes de trafic ordonnancées via les stratégies ALTQ. Ce type de fonction permet d'offrir des garanties de bande passante aux utilisateurs, mais aussi par exemple d'utiliser des protocoles interactifs facilement en présence de flux de transfert massifs (type FTP) ou de faire coexister des flux réseaux continus allant dans les deux sens quand une des directions est saturée (ce qui est notamment le cas sur des liaisons asymétriques, type ADSL). Dans certains cas, les améliorations obtenues sont extrêmement importantes (voir http://www.benzedrine.cx/ackpri.html)...