Compte rendu de l`installation et de la maintenance du garde

Compte rendu de l’installation et la maintenance du pare-feu FORTINET
Université Pierre et Marie Curie - Paris 6 / Service Informatique de Gestion - SIG
(Version 4)
Auteur(s) : Arnaud DONNAT
Date : 27/09/05
Le réseau de l’administration de l’Université Pierre et Marie Curie, dénommé ADMP6, était
basé principalement sur le filtrage des adresses IP et des ports TCP/UDP sources et
destinations. Cette politique de sécurité a longtemps été efficace, mais est devenue limitée
face aux nouvelles menaces, notamment survenues1 à la fin des mois d’août et d’octobre 2003
avec les célèbres failles RPC des systèmes Windows. En effet, les récentes applications grand
public, comme les messageries instantanées gratuites ou les programmes d’échanges de
fichiers (P2P), utilisent à présent le port 80, initialement créé pour le protocole HTTP et
généralement ouvert pour permettre l’accès aux sites Internet depuis les réseaux locaux.
Techniquement, il est possible d’encapsuler un protocole donné dans un autre, et par
conséquent, une passerelle pirate installée dans le réseau interne encapsule/désencapsule le
protocole applicatif contournant ainsi le filtrage des équipements de routage. Ces tunnels
HTTP ouvrent une nouvelle brèche et facilitent la prolifération de virus informatiques et
d’attaques DoS (Denial of Service). Inévitablement, l’acquisition d’un matériel analysant
l’ensemble des flux de données en périphérie du réseau de l’administration est devenue
incontournable. Les caractéristiques techniques du matériel dévolu à cette tâche nécessitaient :
¾ au moins 3 ports Gigabit dont 2 en fibre optique pour l’interconnexion entre le
réseau ADMP6 géré par le SIG et celui du CCR,
¾ la gestion des VLAN 802.1Q en mode « Trunk »,
¾ le protocole RIPv2 pour annoncer les routes SIG au CCR,
¾ le protocole DHCP nécessaire à l’affectation d’adresses IP pour un VLAN invité,
¾ un pare-feu à états, souvent appelé « state-full », pour remplacer les filtres statiques
du routeur situé à l’extrémité du réseau de l’administration,
¾ les processus IDS/IPS (Intrusion Detection System / Intrusion Prevention System)
pour stopper les attaques connues et référencées (DoS et autres),
¾ un antivirus analysant les flux de données véhiculés par les services du réseau de
l’administration (HTTP, FTP, SMTP, POP et IMAP),
¾ les mises à jours régulières et automatiques pour la base des définitions antivirales
et celle destinée aux processus IDS/IPS.
L’installation d’un serveur possédant plusieurs cartes réseaux n’était pas envisageable. En
effet, les systèmes actuels (Linux et Windows) sont trop vulnérables et possèdent des
performances insuffisantes pour exécuter simultanément l’ensemble des différents
programmes de sécurité énoncés précédemment. L’alternative supposait l’installation d’un
boîtier spécialisé, également définit par le terme « appliance ». A la fin de l’année 2003,
ARKOON proposait une technologie ancienne, sans utiliser les processeurs spécialisés et
reprogrammables. Les solutions de NETSCREEN et NOKIA étaient d’un prix excessif, et le
modèle 5400 de SYMANTEC, annoncé en septembre 2003, n’était pas disponible
immédiatement. Par ailleurs, le prix des licences utilisateurs chez SYMANTEC dépassait le
budget alloué. Finalement, seule la gamme des boîtiers de la société FORTINET
correspondait d’un point de vue technique et financier.
1
Les infections virales endurées par le réseau de l’administration ont toutefois été limitées grâce à une mise à
niveau des correctifs systèmes installés pour chaque serveur et poste de travail sous Windows.
1
Système de base
Le produit est vendu en incorporant le nombre maximal de licences utilisateurs pour les
fonctionnalités du pare-feu « state-full », du moteur d’analyse antivirale et des processus
IDS/IPS. En option2, le service FortiGuard assurant le filtrage du contenu des URL est soumis
à un abonnement annuel et la connexion sécurisée du client propriétaire VPN doit s’affranchir
d’une licence logicielle pour chaque machine. Afin de répondre aux exigences d’un débit
réseau élevé et constant, le boîtier est construit autour de processeurs ASIC reprogrammables
et spécialisés exclusivement pour exécuter le système propriétaire FortiOS, contenu dans une
mémoire FLASH. Toutefois, l’ajout de fonctionnalités analysant les flux de données jusqu’au
niveau applicatif ralentit inévitablement la délivrance des informations. Le boîtier choisi,
c'est-à-dire un Fortigate de modèle 3000, possède des performances maximales de 2Gbps en
mode pare-feu « state-full » (niveau 3 et 4), de 100Mbps lorsque les processus IDS/IPS et
l’analyse antivirale des flux de données applicatifs (niveau 7) sont activés.
La société FORTINET a écrit son propre moteur antiviral, basé initialement sur celui de
TREND MICRO, l’un des concurrents directs de la société SYMANTEC dont les logiciels
équipent pour une grande partie les postes de travail et les serveurs du réseau de
l’administration. L’exploitation de ces deux environnements antiviraux distincts au sein d’un
même réseau améliore au quotidien la détection des nouveaux codes malicieux. Dès qu’une
attaque mondiale est repérée, FORTINET pousse automatiquement les nouvelles définitions
sur tous les boîtiers de sa gamme de pare-feu. De plus, les mises à jour sont programmables
pour un intervalle minimum d’une heure après le démarrage du système.
La livraison du Fortigate 3000 a été effectuée le 15 décembre 2003, date à laquelle les
premiers tests ont été réalisés avant sa mise en exploitation progressive.
Intégration du Fortigate 3000 dans le réseau ADMP6
En périphérie du réseau de l’administration, l’intégration de l’équipement de sécurité a
impliqué quelques modifications. Afin d’analyser l’ensemble des flux de données, il a fallu
migrer deux adresses de passerelles, soit :
¾ celle affectée précédemment au routeur d’extrémité (modèle 7206VXR de CISCO)
pour l’interconnexion de niveau 3 avec le CCR,
¾ celle nécessaire au VLAN invité hébergeant les machines externes aux services
administratifs et gérée ultérieurement par le commutateur-routeur CISCO 4506.
Ensuite, un nouveau VLAN a été créé pour l’ensemble des serveurs Web et LDAP en
exploitation. En effet, la création d’une zone DMZ (De-Militarized Zone) fournissant les
ressources informatiques à l’extérieur du réseau de l’administration était indissociable à la
mise en oeuvre du pare-feu, renforçant ainsi la sécurité du réseau. Situé en amont du routeur
7206VXR, le boîtier a été configuré pour les services de routage et de sécurité suivants :
¾ l’annonce des routes appartenant au réseau SIG vers le CCR en RIPv2,
¾ la mise en place du protocole DHCP pour les stations du VLAN invité hébergeant
les machines externes au réseau de l’administration,
¾ le filtrage « state-full » de l’ensemble du réseau de l’administration,
¾ l’analyse antivirale des services HTTP, FTP, SMTP, POP et IMAP,
¾ la prévention IPS des attaques référencées grâce à la détection IDS.
2
Pour évaluer préalablement ces options payantes, l’accès FortiGuard et le logiciel VPN FortiClient
fonctionnent gratuitement pendant une période d’essai de 30 jours.
2
Durant la migration, la sécurisation des flux de données au sein du réseau de l’administration
a été segmentée en 4 zones distinctes dans lesquelles un ou plusieurs VLAN coexistent. Ces
zones ont été configurées conformément aux descriptions posées dans le tableau 1.
Zones
Interne
DMZ
Hébergement
ou Invité
Externe
Domaines d’utilisation
VLAN
Totalité des réseaux internes ADMP6, soit 1000
machines comprenant les postes et les serveurs
de l’administration et des BU de l’Université
Accès des services administratifs pour les
utilisateurs externes au réseau ADMP6
(10 serveurs Web et annuaires LDAP)
Ensemble des utilisateurs non administratifs
(étudiants, services divers ou portables) hébergés
sur les infrastructures du réseau ADMP6
Interconnexion de niveau 3 en direction des
réseaux du campus Jussieu, RAP, RENATER et
l’Internet
12 VLAN
(passerelles sur 10 R-SIG)
1 VLAN
(passerelle sur FGT3000)
1 VLAN
(passerelles sur FGT3000)
1 VLAN
(passerelle sur FGT3000)
Tableau 1 : Zones de sécurité au sein du réseau ADMP6
Tous les flux de données, entrant ou sortant des zones, sont bloqués avec la configuration
initiale du boîtier. Afin d’autoriser la circulation de certains trafics réseau, des règles précises
doivent être saisies d’une zone vers une autre. Le filtrage utilise la méthode « state-full » qui
mémorise dans une table l’état des liaisons initiées et acceptées, informant ainsi le pare-feu si
un flux de données appartient ou non à une connexion établie, et ceci, quelque soit le
protocole réseau utilisé (TCP, UDP, ICMP, …). La figure 1 décrit la migration de la politique
de sécurité par un filtrage « state-full » de 2 zones existantes et l’ajout de 2 nouvelles zones3.
Externe
Pas de filtrage
Interne
Migration
Externe
DMZ
Hébergement
Interne
Légende
Tout est interdit sauf ce qui est autorisé par le filtrage « State-less »
Tout est interdit sauf ce qui est autorisé par le filtrage « State-full »
Tout est autorisé sauf ce qui est interdit par le filtrage « State-full »
Figure 1 : Migration et ajout de zones de sécurité
3
Depuis, d’autres zones ont été créées pour sécuriser la connexion VPN et les accès des postes publics aux BU.
3
La figure 2 schématise l’intégration du boîtier Fortigate 3000 dans l’architecture physique du
réseau ADMP6 en décembre 2003. Les zones de sécurité « DMZ » et « Hébergement/Invité »
ont été configurées sur le port cuivre Gigabit Ethernet, physiquement relié à l’une des
interfaces du CISCO 4506 et paramétré avec le mode « Trunk » du protocole 802.1Q.
Ultérieurement, d’autres VLAN ont été ajoutés à la liaison 802.1Q du Fortigate 3000 afin de
modifier leur niveau de sécurité. Par exemple, une nouvelle zone de sécurité associée à un
VLAN particulier est destinée aux postes des Bibliothèques en libre service et positionné dans
la liaison « Trunk ». Les 3 ports FastEthernet ont été laissés libres pour tester et déployer
éventuellement des solutions alternatives à certaines fonctionnalités de sécurité non présentes
ou dysfonctionnant dans la Fortigate 3000, comme les accès des clients VPN et VPN-SSL.
Liaison avec les
routeurs SIG
chiffrement en 3DES
Fortigate 3000
FortiOS 2.5MR6 Build 171
Routeur-FW-IPS-AV
< ADMP6 >
VLAN_IntercoSIG-CCR:Giga
Giga:VLAN_Interco1
VLAN_DMZ-Héberg :Giga
Commutateur 3550-12G
< CCR >
Giga0/3:VLAN_R-SIG
VLAN_ALL:Giga0/1
Giga0/2:VLAN_IntercoSIG-CCR
VLAN_ExterneSIG:Giga0/4
Liaison Interco de
routage avec le
CCR/RAP/Internet
3 Ports libres
FastEthernet
8xBRI
Fibre noire louée
vers Jussieu
Liaison VLAN pour les
machines ADM isolées à
Jussieu (vue en interne)
12.2(15)T5
Routeur 7206VXR
< ADMP6 >
Giga0/1:VLAN_Interco1
Giga0/2:VLAN_R-SIG
VLAN_Interco2:Giga0/3
Vers les
commutateurs
départementaux
du SIG
12.1(19)EW
Commutateur-Routeur 4506
< ADMP6 >
Giga1/1:VLAN_Interco2
VLAN_DMZ-Héberg:Giga4/4
VLAN_ExterneSIG:Giga1/2
Giga2/1-6:VLAN_InterneSIG
Giga3/1-6:VLAN_InterneSIG
Remarques :
=> Les interfaces soulignées sont configurées avec le mode « Trunk » du protocole 802.1Q .
=> Le schéma présente les versions Firmware des matériels actifs du réseau ADMP6
au moment de l’installation du pare-feu. Depuis décembre 2003, les versions Firmware
ont évolué et l’un des 3 ports FastEthernet libre du Fortigate 3000 a été connecté au port
d’un concentrateur VPN CISCO puis associé à la création d’une nouvelle zone de sécurité.
Figure 2 : Intégration physique du Fortigate 3000 en décembre 2003
Lors de l’installation initiale du pare-feu, seul l’accès en mode console (un câble série est
fourni avec le boîtier) permet la saisie des premiers éléments de configuration. Dès qu’une
adresse IP est affectée à l’une des interfaces, le paramétrage du boîtier se poursuit facilement
à partir d’un simple navigateur Internet (IE, Netscape ou Mozilla). Le mode graphique sous
HTTP ou HTTPS est nommé WebUI par FORTINET.
4
Premiers résultats - Décembre 2003 à Mars 2004 : FortiOS 2.5MR6 Build171
L’intégration du Fortigate 3000 s’est déroulée convenablement lors de l’activation du
protocole de routage RIPv2, de l’application des règles de filtrage concernant chacune des
zones à sécuriser, de la mise en place des processus IDS/IPS et de l’analyse antivirale des
protocoles HTTP, FTP, SMTP, POP et IMAP. La configuration du service DHCP pour la
zone « Hébergement/Invité », puis le déplacement des serveurs Web et LDAP dans la zone
« DMZ » ont finalisé la migration.
Pendant ces 4 premiers mois, 16 000 attaques ont été stoppées par le module IPS, sans
toutefois dénombrer de faux positifs. Le moteur IDS a notifié approximativement 1 million de
flux suspects, dont la version 2.5 ne peut bloquer les définitions relatives aux agressions, car
inconnues du processus IPS. Depuis la version 2.8 (sortie en Juillet 2004), le processus IPS a
été fusionné au moteur IDS afin d’arrêter ou d’ignorer toutes les intrusions détectées en
fonction de l’option choisie pour chaque référence de la base des signatures d’attaque. Par
défaut, un nombre restreint de définition est stoppé, évitant l’augmentation des faux positifs.
La principale fonctionnalité de sécurité attendue a été l’analyse antivirale des flux HTTP,
FTP, SMTP, POP et IMAP, où durant 4 mois, plus de 6500 virus ont été interceptés à l’entrée
du réseau de l’administration. Les courriels à destination des serveurs « MS-Exchange 2003 »
de l’administration sont acheminés via la passerelle de messagerie du CCR qui intègre un
antivirus de marque SOPHOS et protége ainsi l’ensemble des flux SMTP destinés aux
différents serveurs courriels du campus de Jussieu. Mais de nombreuses tentatives d’infection
ont été initiées par les serveurs de messagerie externe au campus de Jussieu, essentiellement
lorsque les utilisateurs du réseau de l’administration relevaient leur courriel personnel depuis
un poste de travail via POP ou IMAP. Cependant, la majorité des attaques virales ont été
stoppée à partir du port HTTP. Depuis la version 2.8, toutes les catégories connues de
« spyware » sont bloquées et intégrées dans les mises à jour des définitions antivirales.
Néanmoins, plusieurs inconvénients se sont présentés au bout de la première semaine de
production, répétés ensuite régulièrement : le pare-feu se bloquait et interrompait la délivrance
des flux protégés par l’analyse antivirale. Inévitablement, la partie administrative du boîtier
devenait indisponible quelque soit le mode d’accès (Console, Telnet, SSH, HTTP ou HTTPS),
et l’unique solution consistait à redémarrer la machine en débranchant ses 2 alimentations
électriques redondantes. Le problème a été soumis au support technique Europe de
FORTINET, relayant rapidement le dysfonctionnement aux équipes de développement situées
à Vancouver. Evidemment, nous étions en présence d’un nouveau bug non référencé. Ce
problème de stabilité a nécessité de nombreux échanges de courriels. La première explication
était liée à la migration des serveurs destinés à la zone DMZ. Le support m’a affirmé que le
souci provenait du fait qu'une des interfaces non connectée de la Fortigate était dans le même
plan d'adressage que la passerelle gérée par le commutateur-routeur 4506. La Fortigate voyait
des paquets provenant du routeur sur une autre interface que celle qui était sensée recevoir les
données. Cependant, même si la configuration du pare-feu était en attente pour permettre le
basculement des serveurs Web/LDAP dans la zone DMZ, le Fortigate n’aurait pas dû
dysfonctionner avec cette configuration.
Maintenance difficile des versions FortiOS 2.5 - Avril à Juillet 2004
La migration achevée, les plantages aléatoires du système ont néanmoins persistés et l’unique
solution restait le redémarrage de la machine en débranchant les 2 alimentations électriques
redondantes. Le support préconisait l’installation de la dernière MR (Maintenance Release),
soit la FortiOS 2.5MR7 Build212 officiellement disponible depuis le 01/03/2004.
5
Cette version n’améliora pas la stabilité du système, et régulièrement, le support me donnait
de nouvelles versions 2.5 « intérimaires » :
¾
¾
¾
¾
¾
¾
le 06/04/2004 - Pre-MR8 Build241 - instable et inexploitable,
le 09/04/2004 - Pre-MR8 Build244 - stable pendant 15 jours,
le 27/04/2004 - Pre-MR9 Build260 - stable de 2 à 3 jours,
le 05/05/2004 - Pre-MR9 Build263 - stable de 2 à 3 jours,
le 11/05/2004 - Pre-MR10 Build279 - stable de 2 à 3 jours,
le 28/05/2004 - Pre-MR10 Build287 - version spéciale debug et DHCP désactivé.
L’incrémentation continue d’un buffer, plus communément appelée « fuite de mémoire »,
était la piste la plus probable à l’instabilité du système. Entre temps, le support m’avait
envoyé une deuxième Fortigate 3000 pour écarter un dysfonctionnement matériel, puis
demandé d’arrêter les processus IDS/IPS et l’enregistrement des LOG réalisés sur le disque
dur interne. Après 3 semaines d’activité et un nouveau plantage en Build287, j’ai demandé
des explications officielles à FORTINET. Un responsable technique s’est déplacé pour
évaluer la « fuite de mémoire » et me garantir qu’il positionnait ce dysfonctionnement au
niveau priorité « top3 » des problèmes rencontrés en Europe. Nous avons également décidé de
laisser la première FGT3000 avec le système 2.5Pre-MR10 Build287 (la plus stable du
moment) et de configurer le deuxième boîtier avec les différentes versions 2.8 bêtas ou
officielles du moment, soit :
¾ le 24/06/2004 - Pre-MR3 Build174 - problème FTP4 et « fuite de mémoire »,
¾ le 08/07/2004 MR3 Build184 - problème de « fuite de mémoire »5,
¾ le 19/07/2004 - Pre-MR4 Build207 - « fuite de mémoire » enfin stabilisée.
Maintenance des versions FortiOS 2.8 – Août 2004 à Juillet 2005
En version 2.8Pre-MR4 Build207, l’incrémentation constante du buffer persistait avec
néanmoins un seuil limite programmé à 40%, libérant ainsi 10 à 15% de la mémoire allouée.
Figure 3 : Gestion de la mémoire
Pendant 8 semaines, le système 2.8Pre-MR4 Build207 n’avait pas nécessité un redémarrage
physique, mais de nombreuses fonctionnalités demeuraient inactivées (LOG, DHCP et
IDS/IPS) à la suite des investigations. Afin de ne pas surcharger immédiatement cette version
sans « fuite de mémoire » au-delà des 40%, seul l’enregistrement des LOG6 a été repositionné
4
Le 28/06/2004, le premier boîtier en FortiOS 2.5Pre-MR10 Build287 a été remis en exploitation suite aux
problèmes liés à l’analyse antivirale des flux FTP rencontrés avec le FortiOS 2.8Pre-MR3 Build174.
5
La première MR 2.8 Build184 mise en exploitation, soit 8 jours avant sa sortie officielle.
6
Un disque dur local enregistre les 6 journaux (Trafic, Evènements du système, Attaque, Antivirus, Filtre Web,
Filtre SPAM), et mémorise pendant une période donnée, les fichiers infectés ou bloqués.
6
dans un premier temps. L’exemple suivant présente une ligne du journal Antivirus, indiquant
l’interdiction à l’accès d’une page HTML qui exploite une faille de sécurité du navigateur IE :
2004-11-20 05:06:21 device_id=FG30002805033041 log_id=0211060000 type=virus
subtype=infected pri=warning src=134.157.161.99 dst=199.107.184.146
src_int=n/a dst_int=n/a service=http status=blocked from="n/a" to="n/a"
file=c.html virus="HTML/Exploit.IframeBO" msg="The file c.html is infected
with HTML/Exploit.IframeBO.ref
http://www.fortinet.com/VirusEncyclopedia/search/encyclopediaSearch.do?meth
od=quickSearchDirectly&virusName=HTML%2FExploit.IframeBO."
Cependant, le moteur antiviral n’effectuait pas correctement l’analyse de la taille des fichiers
et obligeait l’installation d’une nouvelle version :
¾ le 06/09/2004 - MR4 Build219 - sortie officielle le 08/09/2004
Tout en préservant le service des LOG, DHCP a été réactivé en MR4. Malheureusement, les
stations Mac OS X 10.3.4 ne pouvaient pas obtenir dynamiquement une adresse IP et
certaines machines, quelques soit les OS, se voyaient allouer un leasing de 3 mois pour une
configuration précisant un jour. Une nouvelle MR a été mise en place :
¾ le 11/10/2004 - MR5 Build250 - sortie officielle le 30/09/2004
Comme le dysfonctionnement du leasing DHCP a été corrigé en MR5, la prévention IDS/IPS
a été repositionnée. Le débit du trafic en sortie des interfaces et visualisé avec MRTG était
indisponible, mais corrigé avec la MR suivante :
¾ le 23/11/2004 - MR6 Build292 - sortie officielle le 19/11/2004
En MR6, le module IDS/IPS a été réécrit pour supprimer la partie du code qui s’exécutait
dans le noyau du système. La gestion de la mémoire a été également améliorée, élevant ainsi
la stabilité du système, et l’analyse antivirale des fichiers sous l’extension « tar.gz » ne pose
plus de problèmes. Toutefois, des soucis persistent avec cette version, notamment le passage à
l’heure d’hiver pour les LOG (BUG#18757 fixé en Build306), la configuration des messages
d’alerte (BUG#19038 fixé en Build307), …
¾ le 02/01/2005 - MR7 Build318 - sortie officielle le 22/12/2004
La MR7 corrige bien les BUG#18757 et BUG#19038 (et certainement d’autres), mais
possède malheureusement un nouveau problème de « fuite de mémoire », généré par le
processus de quarantaine. Le redémarrage du processus libère la zone mémoire inutilisé. Ce
dysfonctionnement est résolu à partir de la Build355, et donc corrigé :
¾ le 09/02/2005 - MR8 Build358 - sortie officielle le 04/02/2005
Egalement appelée MR8, la Build359 est apparue quelques jours après pour pallier des
problèmes en haute disponibilité (mise en cluster de 2 boîtiers), devenant ainsi la nouvelle
version officielle du mois de Mars 2005. Toutefois, un dysfonctionnement important est
apparu le 27 Mars. Le BUG#24339 est lié au changement de l’heure hiver/été (concerne
uniquement l’heure non universelle, soit GMT+n ou GMT-n) et interrompe les mises à jours
antivirale/IPS, perturbant ainsi le fonctionnement normal des processus de sécurité. Encore
une fois, la MR suivante résolvait le problème :
7
¾ le 11/04/2005 – MR9 Build393 - sortie officielle le 05/04/2005
En MR9, le processus « thttp » utilise par moment plus de 90% de la CPU. Il est nécessaire de
« killer » manuellement ce daemon ou d’attendre une mise à jour antivirale ou IDS/IPS pour
retrouver une utilisation normale de la CPU.
Figure 5 : Utilisation anormale des ressources CPU
Le moteur IDS/IPS serait responsable du problème, et corrigé :
¾ le 07/06/2005 – Pre-MR10 Build429 - sortie officielle le 27/05/2005
La MR incluant la résolution des pics CPU a été passée :
¾ le 05/07/2005 – MR10 Build456 - sortie officielle le 04/07/2005
Le moteur IDS/IPS de la MR10 génère de faux positifs, notamment LDAP et Oracle, via des
signatures qui n’en produisaient pas auparavant. De plus, l’analyse antivirale des fichiers
s’appuie sur le paramètre « content-length », retourné par le serveur Web distant et dont la
valeur est modifiable avec certaines vulnérabilités. Ainsi, un fichier de quelques kilos octets
pourrait être vu par la Fortigate avec une capacité fictive de plusieurs GIGA, et être ainsi
transféré sans analyse. Le pare-feu effectue une recherche antivirale sur tous fichiers ne
dépassant pas 139 Mo, valeur maximale pour une FGT3000. Une futur version (peut-être la
MR11) évitera la prise en compte du « content-length » et corrigera également le défaut du
moteur IDS/IPS, détectant de faux positifs liés à la mauvaise interprétation des flux analysés.
Lorsque la Fortigate aura un fonctionnement sans défaut majeur, éventuellement en MR11 ou
MR12, le protocole OSPF et la redistribution des routes vers RIPv2 sera implémentée
conformément à la topologie logique du réseau ADMP6.
VPN – accès nomade
Le système FortiOS permet la sécurisation des accès extérieurs au réseau interne via un client
VPN propriétaire et payant. Les ressources internes de l’administration supposent
l’établissement de tunnels VPN exclusifs, aboutissant dans une zone de sécurité dissociée des
autres pour permettre l’analyse des flux de données par le moteur antiviral et prévenir les
attaques via les processus IDS/IPS. Pour cela, une plage d’adresse IP appartenant au réseau de
l’administration est indispensable et référence logiquement chaque connexion VPN. Mais le
protocole « DHCP over IPSec » est indisponible en FortiOS 2.5. L’ingénieur avant-vente
m’avait confirmé la présence de cette fonctionnalité avec la version 2.8, malheureusement
non opérationnelle avec les premières distributions MR testées. Entre temps, l’accès VPN
nomade est devenu un service à déployer rapidement7. Une solution avec une stabilité
7
Le déploiement de réseaux WIFI et les offres ADSL ont fortement contribués aux déploiements de clients
VPN, suivit du VPN-SSL pour les accès nomades et résidentiels des utilisateurs de l’administration.
8
reconnue, de meilleures performances et des fonctionnalités supplémentaires, tel qu’un client
VPN disponible sous de multiples OS (Linux, Mac OS X et Windows), a été retenue. Pour ces
raisons, je n’ai pas approfondi la solution VPN de FORTINET.
WebUI – administration en mode graphique
L’URL www.fortinet.com/demo/ propose une démonstration8 en ligne de l’interface
graphique du FortiOS 2.8. Cette interface présente ainsi les fonctionnalités disponibles.
Depuis la MR3, des options ont été ajoutées ou modifiées dans chaque nouvelle MR
(interface Web en français, nouvelle configuration des LOG, modification de paramètres par
défaut, suppression de la temporisation sur le disque dur interne des fichiers à scanner par
l’antivirus, les paramètres « SPLICE » de l’antivirus, …). Malheureusement, certaines
configurations existent uniquement via l’interface du mode commande, soit le protocole de
routage OSPF, les options heuristiques antivirales, …
Anti-pourriels
La solution anti-pourriels, souvent dénommée « anti-SPAM », a été ajoutée dans la version
2.8. La Fortigate permet d’interroger les bases de données gratuites de l’Internet, c'est-à-dire
les listes noires ou « blacklist » contenant les adresses IP des machines ou domaines à bannir,
envoyant ou relayant les pourriels. Si l’abonnement au service AntiSpam est payé, une base
de définitions RBL (Realtime Blackhole List), référencée par FORTINET, stockée sur ses
propres serveurs et interrogée automatiquement par le pare-feu, annonce les pourriels reçus.
Figure 6 : La version des définitions RBL de FORTINET
Documentation et maintenance
Le marketing des produits FORTINET est visible aux pages www.fortinet.com.
Avec le contrat de maintenance standard, les versions Firmware sont téléchargeables depuis le
site FTP de FORTINET, le support est accessibles 24h/24 (téléphone, courriel ou le
site Web), les définitions9 Antivirales et IDS/IPS sont automatiquement mises à jour dans le
boîtier. Une base de connaissance kc.forticare.com, pour le moment succincte, permet
également l’accès aux documentations officielles des produits FORTINET. D’autre part, le
forum support.fortinet.com/forum fournit de nombreuses informations utiles à
l’administration et la résolution des problèmes concernant les produits FORTINET.
Inconvénients
L’équipe du support Europe est saturée et ne répond qu’aux problèmes bloquant :
8
Trois autres URL présentent respectivement en ligne les solutions FortiMail, FortiLog et FortiManager via
www.fortinet.com/fortimaildemo, www.fortinet.com/fortilogdemo et www.fortinet.com/fortimanagerdemo.
9
Depuis Juillet 2005, le contrat de maintenance standard n’intègre plus la mise à jour des définitions antivirale et
IDS/IPS, devenant des options séparées.
9
“All the Level-2 engineers are currently busy with higher priority issues. This ticket will be
handled when a slot frees up. Thanks for your patience.”
Le support des MAC OS X est difficilement pris en charge par FORTINET :
“I'm afraid that we do not have any MAC here and we will not have one in the near
future. At that point and as a general purpose, MAC is not really supported by us.
At that point and if this issue becomes a tough one could you please get in touch with
your Sales representative in order to make the MAC supported.”
Les flux HTTPS, pourtant de plus en plus utilisés avec les services Web sécurisés, ne sont pas
analysés par le moteur antiviral et le processus IPS du pare-feu. Cette fonctionnalité existe
chez les constructeurs concurrents, notamment avec les boîtiers de Webwasher/Cyberguard.
Le filtrage du contenu de site Internet est seulement accessible via l’abonnement payant du
service FortiGuard, sans aucune possibilité d’utiliser des listes externes et mises à jour en
fonction du pays hébergeant le pare-feu. En effet, la France n’a pas les mêmes critères
juridiques concernant le contenu des sites Web que les Etats-Unis, répertoriant certaines
organisations syndicales Françaises comme « terroristes », mais autorisant par ailleurs la
liberté de certains cultes définis comme sectaires en France. Cette restriction est uniquement
d’ordre commerciale et aucunement technique. En effet, les pare-feux concurrents autorisent
l’accès aux bases de données de sociétés tierces, comme par exemple la solution OLFEO
référençant le contenu de sites Internet relatifs à la culture et la législation Française.
Avantages
L’application des règles par zone de sécurité, l’analyse antivirale des différents services
réseau, la détection et la prévention des attaques référencées avec les processus IDS/IPS, sans
oublier la configuration aisée du produit sont appréciables. En effet, les virus interceptés par
le Fortigate 3000 pendant sa première expérience d’attaque mondiale, soit celle de fin janvier
2004, n’a pas demandé la mobilisation de l’équipe du support technique du SIG pour
décontaminer les machines dont l’antivirus n’était pas à jour. Le FortiOS 2.8MR9 semble
profiter d’une meilleure stabilité par rapport aux versions précédentes, d’ailleurs vite oubliées
des équipes du support et du développement.
Conclusion
Après 20 mois de production sur le réseau ADMP6, le Fortigate 3000 a connu 19 versions
Firmware différentes, principalement pour résoudre les problèmes de stabilité. De nombreuses
améliorations ont été réalisées, notamment la modernisation du produit avec FortiOS 2.8 et la
mise en place d’une base de connaissance en ligne. La solution de verrouiller l’analyse et le
filtrage du contenu des pages URL par un unique service payant, nommé FortiGuard, n’est
pas la méthode la plus efficace, particulièrement pour la France et les pays d’Europe. La
société FORTINET se préoccupe de stabiliser et d’améliorer son système de sécurité
(antivirus et IPS), de perfectionner la gestion des pourriels par l’interrogation d’une base des
définitions RBL propriétaire, dont l’accès nécessite l’achat d’une option à la maintenance10 du
pare-feu. Cependant, les prochaines versions FortiOS pourront-elles s’adapter aux défis des
nouveaux scénarii d’attaques utilisant par exemple les protocoles sécurisés11 ?
10
Le service RBL payant de FORTINET n’est pas intégré à la maintenance standard. Un boîtier spécialisé,
nommé FortiMail, possède cette maintenance en standard, ainsi que d’autres fonctionnalités inexistantes dans la
FortiGate, comme l’analyse heuristique et la mise en quarantaine des courriels suspects.
11
Comment intercepter les virus circulant via des tunnels chiffrés, où les flux applicatifs traversent les pare-feux
avec les protocoles HTTPS, POPS, IMAPS, etc. La version FortiOS 3.0, actuellement en phase bêta et peut être
disponible à l’horizon du dernier trimestre 2005, répondra éventuellement à cette question.
10