DAT-NT-006/ANSSI/SDE

PREMIER MINISTRE

Secrtariat gnral de la dfense et de la scurit nationale Agence nationale de la scurit des systmes dinformation

Paris, le 30 mars 2013 No DAT-NT-006/ANSSI/SDE/NP Nombre de pages du document : 1+15

Note technique Recommandations pour la dfinition dune politique de filtrage rseau dun pare-feu

Public vis: Dveloppeur Administrateur RSSI DSI Utilisateur

Informations

Avertissement Ce document rdig par lANSSI prsente les Recommandations pour la dnition dune politique de ltrage rseau dun pare-feu . Il est tlchargeable sur le site www.ssi.gouv.fr. Il constitue une production originale de lANSSI. Il est ce titre plac sous le rgime de la Licence ouverte publie par la mission Etalab (www.etalab.gouv.fr). Il est par consquent diusable sans restriction. Ces recommandations sont livres en ltat et adaptes aux menaces au jour de leur publication. Au regard de la diversit des systmes dinformation, lANSSI ne peut garantir que ces informations puissent tre reprises sans adaptation sur les systmes dinformation cibles. Dans tous les cas, la pertinence de limplmentation des lments proposs par lANSSI doit tre soumise, au pralable, la validation de ladministrateur du systme et/ou des personnes en charge de la scurit des systmes dinformation.

Personnes ayant contribu la rdaction de ce document: Contributeurs BSS, LAM BAI, BAS, Rdig par BSS Approuv par SDE Date 30 mars 2013

volutions du document : Version 1.0 Date 30 mars 2013 Nature des modications Version initiale

Pour toute remarque: Contact Bureau Communication de lANSSI Adresse 51 bd de La Tour-Maubourg 75700 Paris Cedex 07 SP @ml communication@ssi.gouv.fr Tlphone 01 71 75 84 04

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 1 sur 15

Table des matires

1 2 3 Prambule Pourquoi cette note ? Organisation dune politique de ltrage rseau 3.1 3.2 3.3 Prsentation du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conditions dapplication du modle . . . . . . . . . . . . . . . . . . . . . . . Dtail du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Section n1 : rgles dautorisation des ux destination du pare-feu . 3.3.2 Section n2 : rgles dautorisation des ux mis par le pare-feu . . . 3.3.3 Section n3 : rgle de protection du pare-feu . . . . . . . . . . . . . . 3.3.4 Section n4 : rgles dautorisation des ux mtiers . . . . . . . . . . . 3.3.5 Section n5 : rgles "antiparasites" . . . . . . . . . . . . . . . . . . . 3.3.6 Section n6 : rgle dinterdiction nale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 5 5 6 6 6 7 7 8 8 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 10 11 11 11 11 11 13 13 13 14 14 14 14 15

Mise en forme dune politique de ltrage rseau 4.1 Mise en forme des objets . . . . . . . . . . 4.1.1 Convention de nommage . . . . . . 4.1.2 Convention de mise en forme . . . Mise en forme des rgles de scurit . . . . 4.2.1 Convention de nommage . . . . . . 4.2.1.1 Nommage des rgles . . . 4.2.1.2 Commentaires des rgles Sparateurs de rgles . . . . . . . . . . . .

4.2

4.3 5

Bonnes pratiques dordre gnral 5.1 5.2 Dsactivation des ux implicites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vrication de la squence de dmarrage . . . . . . . . . . . . . . . . . . . . . . . . . .

Documentation, validation et maintenance 6.1 6.2 6.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Illustration

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 2 sur 15

1 Prambule
Lobjectif de ce document est de fournir les lments organisationnels permettant de structurer la base de rgles constituant la politique de ltrage rseau applique sur un pare-feu dinterconnexion. Cette note est indpendante de la fonction du pare-feu (accs internet, cloisement de datacenter, isolation dun partenaire) ; elle fait labstraction des solutions techniques qui peuvent tre employes 1 (logiciel, quipement ddi) et ne tient pas compte de son mode dadministration (ligne de commande, interface web, client lourd). Certaines des prconisations mentionnes dans ce document ne seront donc applicables que si la technologie utilise le permet ; il appartient au lecteur dapprcier et de dterminer si les direntes recommandations sont adaptes son cas dusage. Ceci dpend notamment de la famille 2 laquelle appartient le pare-feu. Cette note technique sadresse lensemble des personnes qui ont la charge de dnir, de mettre en uvre ou dadministrer des architectures dinterconnexion scurises et qui souhaitent inscrire dans leur dmarche la volont dassurer la prnnit des politiques de ltrage rseau appliques sur les pare-feux. Dans la suite de ce document les termes pare-feu et passerelle seront utiliss indirement, ils dsignent tous les deux un quipement dinterconnexion capable de raliser un ltrage rseau en tenant compte de ltat des connexions pralablement tablies (stateful). Les bonnes pratiques relatives au positionnement dun pare-feu dans une architecture ne sont pas prsentes dans ce guide, celles-ci sont dtailles dans un document complmentaire publi par lANSSI intitul Dnition dune architecture de passerelle dinterconnexion scurise . Ce guide est disponible dans la section Bonnes pratiques Recommandations et guides Scurit des rseaux sur www.ssi.gouv.fr.

1. Pour rappel, la liste des pare-feux qualis par lANSSI est disponible dans la section Certication/ Qualication sur www.ssi.gouv.fr. 2. En eet, il existe deux catgories de pare-feux, la premire concerne ceux dont les rgles de ltrage sont dnies par paire dinterfaces rseaux (une entrante, une sortante), la seconde ceux dont les rgles sont dnies globalement. Dans ce deuxime cas, ce nest pas ladministrateur qui dtermine les interfaces dentre/sortie auxquelles sappliquent chacune des rgles mais le pare-feu lui mme.

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 3 sur 15

2 Pourquoi cette note ?

La rdaction de cette note technique a t motive par les raisons suivantes : Les architectures dinterconnexion se complexient de plus en plus pour pouvoir faire face aux nouvelles menaces, direntes briques techniques y sont rgulirement ajoutes (exemple : IDS, Firewall Web Applicatif). Le pare-feu reste cependant lun des lments majeurs dune dfense en profondeur 3 ecace, il est le premier rempart pour stopper les attaques ou ralentir leur progression. Lajout permanent de nouvelles fonctionnalits aux pare-feux (ou leurs outils de management) complexie leur administration et peut rendre la lisibilit des politiques de ltrage rseau plus dicile. Lhistorique parfois lourd des passerelles dgrade naturellement ltat des politiques de pare-feux (mconnaissance de lutilit des certaines rgles, non suppression de rgles lies des quipements retirs de la production). La rotation des quipes en charge de ladministration des passerelles peut conduire une drive des congurations (rutilisation dadresses, rgles surcharges).

3. Le concept de dfense en profondeur est dtaill dans un mmento disponible dans la section Bonnes pratiques Outils mthodologiques sur www.ssi.gouv.fr

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 4 sur 15

3 Organisation dune politique de ltrage rseau

3.1 Prsentation du modle
La politique de ltrage dune passerelle peut tre construite en suivant un modle dorganisation de rgles applicable dans la majorit des cas dusage. Lorganisation propose dans ce document a pour objectifs : de renforcer la protection du pare-feu et des rseaux de conance quil isole ; de faciliter la lisibilit de la politique de ltrage ; de minimiser les sources derreurs et les drives. Cette organisation est construite selon un modle de scurit positif (tout ce qui nest pas explicitement autoris est interdit), il est possible de la dcomposer en 6 sections rigoureusement ordonnes de la faon suivante : Ordre Section n1 Section n2 Section n3 Section n4 Section n5 Section n6 Contenu Rgles dautorisation des ux destination du pare-feu Rgles dautorisation des ux mis par le pare-feu Rgle de protection du pare-feu Rgles dautorisation des ux mtiers Rgles "antiparasites" Rgle dinterdiction nale

3.2 Conditions dapplication du modle

Les conditions dapplication du modle prsent sont les suivantes : les rgles de ltrage sont values squentiellement par le pare-feu (de haut en bas) ; une rgle de ltrage unique est applique un ux (la premire qui autorise ou interdit ce ux) ; il est possible de dnir prcisement les ux ayant pour origine ou destination le pare-feu 4 . Si cela nest pas possible les sections n1 et n2 ne seront pas prsentes dans la politique de ltrage.

4. Certaines solutions ne permettent pas de grer nement les ux mis ou reus par le pare-feu. Dans ces cas prcis, des rgles sont automatiquement ajoutes la politique de ltrage, elles sont directement lies lactivation de certains paramtres dadministration de la solution, et il nest pas toujours possible de les dsactiver (se rfrer au paragraphe 5.1).

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 5 sur 15

3.3 Dtail du modle

3.3.1 Section n1 : rgles dautorisation des ux destination du pare-feu Cette premire section contient un nombre minimal de rgles car un pare-feu nore quun nombre restreint de services, sa surface dattaque doit tre la plus rduite possible. Un pare-feu doit idalement tre administr et supervis via une interface rseau physique ddie connecte un rseau dadministration. Deux types de rgles constituent cette section : les rgles autorisant les services dadministration de la passerelle ; les rgles autorisant les services de supervision de la passerelle. Voici une illustration simple :
Source Serveurs dadministration Serveurs de supervision Destination Interface dadministration de la passerelle Interface dadministration de la passerelle Service ssh, https get-snmp Action Autoriser Autoriser Journalisation Oui Oui

R1

Les rgles de scurit qui autorisent laccs aux services proposs par un pare-feu doivent tre regroupes dans la politique de ltrage. Ces rgles sont peu nombreuses et doivent tre dnies prcisment, en particulier au niveau de leurs adresses sources et de leurs services.

3.3.2 Section n2 : rgles dautorisation des ux mis par le pare-feu Cette seconde section contient galement un nombre limit de rgles, elle ne dcrit que les ux ayant pour origine la passerelle elle-mme. Trois types de rgles constituent cette section : les rgles autorisant les services denvoi de journaux de la passerelle ; les rgles autorisant les services dalerte de la passerelle ; les rgles autorisant les services qui permettent le maintien en condition oprationelle de la passerelle (par exemple les ux de sauvegarde). Voici une illustration simple :

Source Interface dadministration de la passerelle Interface dadministration de la passerelle Interface dadministration de la passerelle

Destination Serveur de journaux Serveur de supervision Serveur de sauvegarde

Service syslog trap-snmp ssh

Action Autoriser Autoriser Autoriser

Journalisation Oui Oui Oui

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 6 sur 15

R2

Les rgles de scurit qui autorisent les ux ayant pour origine le pare-feu doivent tre regroupes dans la politique de ltrage. Ces rgles sont peu nombreuses et doivent tre dnies prcisment, en particulier au niveau de leurs adresses de destinations et de leurs services.

3.3.3 Section n3 : rgle de protection du pare-feu Cette section ne comporte quune seule rgle dite de protection de la passerelle ; elle est toujours la mme et peut tre dcrite de la faon suivante :
Source Toutes Destination Toutes les interfaces de la passerelle Service Tous Action Interdire Journalisation Oui

Laction Interdire correspond une suppression du trac sans rponse du pare-feu (action drop en anglais), cela permet dviter un signalement trop explicite de la passerelle aux ventuels attaquants. Cette protection permet de verrouiller laccs la passerelle, si dans la suite de la politique est ajoute une rgle qui va lencontre (autorisation de ux destination du pare-feu), celle-ci ne sera pas prise en compte. Elle pourra mme tre signale comme incohrente si la solution technique est en mesure deectuer cette vrication. La journalisation est obligatoirement active pour cette rgle an de conserver la trace de lensemble des ux non lgitimes destination de la passerelle.

R3

La mise en place dune rgle de protection du pare-feu est imprative pour prvenir louverture de ux non lgitimes destination de la passerelle ; la journalisation de cette rgle permet de conserver la trace de ces ux illgitimes.

3.3.4 Section n4 : rgles dautorisation des ux mtiers Cette section contient les rgles dautorisation qui dcrivent les ux mtiers, celles-ci sont ordonnes selon une logique tablie ; plusieurs orientations sont possibles, en voici deux exemples : Organisation des rgles en fonction des entits mtier : les rgles sont regroupes en fonction des entits mtiers auxquelles elles ouvrent des services (comptabilit, ressources humaines). Organisation des rgles en fonction des services oerts : les rgles sont regroupes en fonction des services autoriss (navigation internet, accs aux proxy, accs aux bases de donnes). Le choix de lorganisation des rgles est dpendant de plusieurs lments du contexte comme le nombre de rgles de la politique ou encore le rle de la passerelle (accs internet, cloisement de datacenter, accs partenaire).

R4

Les rgles qui autorisent les ux mtiers doivent tre regroupes et organises selon une logique tablie et adapte au contexte. Ces rgles constituent lessentiel de la politique de ltrage, elles doivent tre dnies prcisement au niveau de leurs adresses sources, de leurs adresses de destination et de leur services. Page 7 sur 15

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

3.3.5 Section n5 : rgles "antiparasites" Cette section est facultative, elle sinscrit dans le cadre dune politique globale de journalisation. Elle contient la liste des rgles dcrivant les ux non autoriss dont la trace nest volontairement pas conserve (certains ux de broadcast par exemple) an de maintenir les journaux de la passerelle exploitables. Cela suppose quune trace de ces ux est conserve par une autre brique de larchitecture (cela doit tre document dans la politique globale de journalisation). La rgle suivante illustre cette section : Source Rseau de test R5 Destination 255.255.255.255 Service udp-137,udp-138 (netbios) Action Interdire Journalisation Non

Les rgles "antiparasites" peuvent tre utilises pour allger les journaux de la passerelle, mais doivent tre tablies en accord avec la politique globale de journalisation de larchitecture.

3.3.6 Section n6 : rgle dinterdiction nale Cette section ne comporte quune seule rgle dinterdiction ; celle-ci est dite nale car celle se trouve toujours en dernire position dans la politique. Cette rgle a pour objectifs dune part dinterdire le trac qui na pas t explicitement autoris par les rgles prcdentes, dautre part de conserver une trace des ux non lgitimes. La rgle de protection est toujours la mme et peut tre dcrite de la faon suivante : Source Toutes Destination Toutes Service Tous Action Interdire Journalisation Oui

Certaines solutions techniques appliquent automatiquement une rgle dinterdiction la n de la politique de ltrage, mais celle-ci nest gnralement pas journalise ou napparat pas explicitement la n de la politique ; cest la raison pour laquelle une rgle nale explicite est ajoute dans tous les cas.

R6

Lajout dune rgle explicite dinterdiction nale journalise garantit lapplication du modle de scurit positif (tout ce qui na pas t autoris prcdemment est interdit) et permet de conserver la trace des ux non lgitimes.

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 8 sur 15

4 Mise en forme dune politique de ltrage rseau

La lisibilit et la maintenabilit dune politique de ltrage dpend avant tout de sa forme ; cest la raison pour laquelle il est primordial de dnir et de documenter les conventions respecter lors de son laboration et de sa mise jour. Une politique de ltrage se traduit par une liste de rgles, elles mme composes dobjets de direntes natures : des machines (Une adresse IP) ; des rseaux (Une adresse de rseau combine un masque) ; des plages rseau (Une suite dadresses IP conscutives) ; des services (tcp, udp, autres) ; des groupes dobjets. R7 La gestion rigoureuse dune politique de scurit commence par la dnition prcise de la reprsentation des objets et des rgles qui la composent.

4.1 Mise en forme des objets

4.1.1 Convention de nommage La dnition dune convention de nommage rigoureuse pour chacun des types dobjets utiliss dans la politique de scurit facilite les oprations suivantes : la recherche (dans une liste de taille consquente) ; la manipulation (tri, mise jour, suppression) ; laudit. Plusieurs orientations sont possibles pour dnir une convention de nommage, voici deux exemples : Convention de nommage fonctionnelle : les objets sont nomms en fonction de leur rle, par exemple : srv_dns-interne, tcp_appli1. Convention de nommage technique : les objets sont nomms en fonction dune caractristique technique qui leur est propre (adresse IP, nom dhote, port), par exemple : srv_appollo, tcp_21000. Le choix de lorientation dune convention dpend dlments lis au contexte, en particulier de la connaissance prcise du mtier. Il est possible de combiner direntes conventions, mais il faut garder lesprit de ne pas trop alourdir la lecture. La solution technique utilise pourra galement tre un facteur limitant prendre en considration (existence dune taille maximale des noms dobjets ou

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 9 sur 15

encore prsence de termes rservs). La casse fait galement partie des paramtres dnir dans la convention. R8 Une convention de nommage doit tre dnie pour lensemble des types dobjets qui composent les rgles de la politique de ltrage.

4.1.2 Convention de mise en forme Certaines solutions orent la possibilit de colorer une partie des objets (machine, rseau, plage rseau), cest un moyen supplmentaire utilis pour augmenter la lisibilit de la politique de scurit. Des incohrences grossires peuvent ainsi tre dtectes visuellement plus rapidement. La logique consiste utiliser une couleur pour lensemble des objets appartenant une mme zone, le code couleur est tabli en fonction dun critre ; par exemple : Le niveau de conance de la zone : un jeu de dgrad est choisi an dassocier une couleur chacun des niveaux de conance existant dans larchitecture. Le tableau 1 est un exemple illustrant ce type de code couleur : Couleur Type de zone Rseau externe DMZ publique DMZ prive Rseau interne

Table 1 Coloration selon le niveau de conance Le rle de la zone : une couleur est associe selon un critre fonctionnel des dirents types de zone existant dans larchitecture. Le tableau 2 est un exemple illustrant ce type de code couleur : Couleur Type de zone hbergeant les serveurs dauthentication hbergeant les serveurs de base de donnes hbergeant les proxys hbergeant les reverse proxys

DMZ DMZ DMZ DMZ

Table 2 Coloration selon un critre fonctionnel

R9

La dnition dune convention de coloration des objets qui composent les rgles de scurit est une aide supplmentaire la comprhension de la politique.

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 10 sur 15

4.2 Mise en forme des rgles de scurit

4.2.1 Convention de nommage 4.2.1.1 Nommage des rgles Certaines solutions permettent dattribuer un nom aux rgles de scurit, ce champ est utilis pour aider la comprhension de la politique, des ches peuvent tre employes pour indiquer le sens de communication que chacune des rgles doit transcrire. Exemple : Relais DNS -> DNS publiques 4.2.1.2 Commentaires des rgles Certaines solutions autorisent lajout de commentaires aux rgles de scurit, ce champ est utilis pour dcrire plus prcisement la signication de chacune des rgles composant la politique de ltrage. Voici une liste non exhaustive dlments qui peuvent apparatre dans un commentaire : le descriptif fonctionnel de la rgle ; la date dimplmentation ou de mise jour de la rgle dans un format court ; la rfrence de la demande dans loutil de gestion de tickets (sil existe) qui a conduit la cration ou la modication de la rgle ; lidentiant de lintervenant qui a implment ou mis jour la rgle dans un format court. Les lments choisis doivent tre rchis et adapts au contexte, la solution technique utilise pourra galement tre un facteur limitant prendre en considration lors du choix des lments inclure dans les commentaires (taille maximale du champ commentaire par exemple). R10 Si des champs textuels ditables spciques chacune des rgles de scurit sont disponibles, il est important de les utiliser pour expliciter le contenu de la politique de ltrage. Les lements constitutifs de ces champs doivent respecter une structure pralablement dnie et adapte au contexte.

4.3 Sparateurs de rgles

Certaines solutions sont capables de scinder la politique de ltrage laide de sparateurs de rgles, cette fonctionnalit est utilise pour augmenter la lisibilit de la politique et faciliter son exploitation. Ces sparateurs sont employs pour faire apparatre les sections prsentes prcdemment et mettre en vidence les regroupements oprs pour les ux mtiers (contenu de la section n4). Si les sparateurs disposent dun champ texte ditable, une convention de nommage doit galement tre dnie pour celui-ci.

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 11 sur 15

Voici une illustration simple reprenant les 6 sections et quelques exemples de ux mtiers : Section 1 2 3 Intitul du sparateur Flux destination de la passerelle Flux mis par la passerelle Rgle de protection de la passerelle Flux mtiers |Flux daccs aux bases de donnes |Flux concernant la ferme 1 de bases de donnes |Flux concernant la ferme 2 de bases de donnes |Flux daccs aux proxys |Flux concernant le proxy x |Flux concernant le proxy y Rgles "antiparasites" Rgle dinterdiction nale

5 6

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 12 sur 15

5 Bonnes pratiques dordre gnral

5.1 Dsactivation des ux implicites
Certaines solutions permettent louverture de ux implicites dans le but de faciliter ladministration de la passerelle ou de simplier louverture de services considrs parfois tort comme non risqus. Malheureusement cela conduit souvent louverture de rgles trop permissives ou mconnues des administrateurs. Voici le type de ux implicites que lon peut rencontrer : ux ncessaires ladministration de la passerelle (https, ssh) ; ux ncessaires au fonctionnement de la passerelle (snmp, ntp, syslog) ; ux permettant ltablissement des VPN (IKE, IPsec) ; ux DNS ; ux ICMP. R11 Une gestion rigoureuse de la politique de ltrage conduit dsactiver les ux implicites sils existent et si la dsactivation est possible ; les ux lgitimes quels quils soient doivent tre dnis manuellement et prcisment par les administrateurs.

Lobjectif de cette dmarche est double : porter la connaissance des administrateurs lensemble des rgles de scurit appliques par le pare-feu ; rduire la surface dattaque de la passerelle et des rseaux quelle protge on nautorisant que les ux stritement ncessaires au besoin.

5.2 Vrication de la squence de dmarrage

Un pare-feu peut tre vulnrable lors de sa squence de dmarrage. En eet, durant le laps de temps qui spare lallumage lectrique de lquipement et lapplication eective de la politique de ltrage rseau, le pare-feu peut se retrouver dans un tat ne lui permettant pas dassurer la scurit des rseaux quil protge ainsi que sa propre protection. Dans le pire des cas, le pare-feu ne ltrera pas les paquets et les routera en eectuant aucun contrle. Il convient donc de vrier quelle tape de la squence de dmarrage le routage sactive sur lquipement. R12 An dviter toute exposition inutile des rseaux et du pare-feu, il est recommand de se documenter sur le fonctionnement prcis de la solution employe, de raliser des tests et de prendre en considration leurs rsultats lors des oprations ncessitant un redmarrage de lquipement (maintenance par exemple). Page 13 sur 15

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

6 Documentation, validation et maintenance

6.1 Documentation
Les choix raliss en application des bonnes pratiques dcrites dans ce guide doivent tre formaliss dans un document transmis lensemble des intervenants oprant sur les pare-feux concerns. Leort de rdaction est ncessaire pour assurer le respect des consignes au del des personnes qui les ont tablies. R13 Les consignes permettant la gestion des politiques de ltrage rseau doivent tre documentes et diuses aux personnes en charge de la mise en oeuvre et la gestion des pare-feux.

6.2 Validation
Les politiques de ltrage mises en place doivent tre valides en pratique pour sassurer que la solution technique adopte se comporte correctement (utilisation doutil danalyse rseau par exemple). Le respect du modle prsent dans ce document contribue au maintien des politiques de ltrage, mais il ne permet pas de se prmunir contre certaines erreurs humaines ou certains fonctionnements spciques ; charge ladministrateur de rester vigilant quant la comprhension des oprations quil excute. R14 Une politique de ltrage rseau doit tre teste une fois implmente.

6.3 Maintenance
Pour conserver son ecacit et sa fonction de scurisation, une politique de ltrage doit tre passe en revue rgulirement. Ces vrications ont pour objectifs : de supprimer les rgles temporaires obsoltes cres depuis la dernire revue ; de corriger les ventuels carts par rapport aux conventions en vigueur ; de vrier la cohrence des rgles ajoutes depuis la dernire revue : origine, utilit, prcision, etc. La prsence de mcanismes techniques ou organisationnels visant conserver sous contrle la politique de ltrage ne dispense pas de la ralisation de ces revues rgulires. R15 Une politique de ltrage rseau doit tre passe en revue une frquence bi-annuelle ou annuelle minima.

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 14 sur 15

7 Illustration
Une partie des recommandations prsentes dans ce document sont illustres laide dun jeu de rgles simple dni sur un pare-feu NetAsq (solution qualie par lANSSI).

Figure 1 Politique de ltrage rseau sur NetAsq Les ux mis par le pare-feu (section n2) napparaissent pas dans lexemple ci-dessous car ils sont dnis implicitement (par exemple ntp et syslog) par la solution technique employe.

No DAT-NT-006/ANSSI/SDE/NP du 30 mars 2013

Page 15 sur 15