DAT-NT-006/ANSSI/SDE

PREMIER MINISTRE

Secrtariat gnral
de la dfense
et de la scurit nationale

Paris, le 30 mars 2013

Agence nationale de la scurit

des systmes dinformation

Nombre de pages du document : 1+15

No DAT-NT-006/ANSSI/SDE/NP

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

Public vis:
Dveloppeur
Administrateur
RSSI
DSI
Utilisateur

X
X
X
X

Informations

Avertissement
Ce document rdig par lANSSI prsente les Recommandations pour la dfinition dune politique de filtrage 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 diffusable 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

Approuv par

Date

BSS

SDE

30 mars 2013

volutions du document :
Version

Date

Nature des modifications

1.0

30 mars 2013

Version initiale

Pour toute remarque:

Contact

Adresse

@ml

Tlphone

Bureau Communication
de lANSSI

51 bd de La
Tour-Maubourg
75700 Paris Cedex
07 SP

communication@ssi.gouv.fr

01 71 75 84 04

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

Page 1 sur 15

Table des matires

1

Prambule

Pourquoi cette note ?

Organisation dune politique de filtrage rseau

3.1
3.2
3.3

4.2

4.3

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

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 . . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

13
13
14

Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

9
9
10
11
11
11
11
11
13

Dsactivation des flux implicites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Vrification de la squence de dmarrage . . . . . . . . . . . . . . . . . . . . . . . . . .

Illustration

5
5
6
6
6
7
7
8
8
9

Documentation, validation et maintenance

6.1
6.2
6.3

.
.
.
.
.
.
.
.
.

Bonnes pratiques dordre gnral

5.1
5.2

.
.
.
.
.
.
.
.
.

Mise en forme dune politique de filtrage rseau

4.1

Prsentation du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conditions dapplication du modle . . . . . . . . . . . . . . . . . . . . . . .
Dtail du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Section n1 : rgles dautorisation des flux destination du pare-feu .
3.3.2 Section n2 : rgles dautorisation des flux mis par le pare-feu . . .
3.3.3 Section n3 : rgle de protection du pare-feu . . . . . . . . . . . . . .
3.3.4 Section n4 : rgles dautorisation des flux mtiers . . . . . . . . . . .
3.3.5 Section n5 : rgles "antiparasites" . . . . . . . . . . . . . . . . . . .
3.3.6 Section n6 : rgle dinterdiction finale . . . . . . . . . . . . . . . . .

14
14
14
15

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 filtrage 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 diffrentes 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 dfinir, 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 filtrage rseau appliques sur les pare-feux.
Dans la suite de ce document les termes pare-feu et passerelle seront utiliss indiffrement,
ils dsignent tous les deux un quipement dinterconnexion capable de raliser un filtrage 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 Dfinition 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 qualifis par lANSSI est disponible dans la section Certification/ Qualification
sur www.ssi.gouv.fr.
2. En effet, il existe deux catgories de pare-feux, la premire concerne ceux dont les rgles de filtrage sont dfinies par
paire dinterfaces rseaux (une entrante, une sortante), la seconde ceux dont les rgles sont dfinies 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 complexifient de plus en plus pour pouvoir faire face aux
nouvelles menaces, diffrentes 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 efficace, 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)
complexifie leur administration et peut rendre la lisibilit des politiques de filtrage rseau plus
difficile.
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 configurations (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 filtrage rseau

3.1 Prsentation du modle
La politique de filtrage 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 confiance quil isole ;
de faciliter la lisibilit de la politique de filtrage ;
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 flux destination du pare-feu
Rgles dautorisation des flux mis par le pare-feu
Rgle de protection du pare-feu
Rgles dautorisation des flux mtiers
Rgles "antiparasites"
Rgle dinterdiction finale

3.2 Conditions dapplication du modle

Les conditions dapplication du modle prsent sont les suivantes :
les rgles de filtrage sont values squentiellement par le pare-feu (de haut en bas) ;
une rgle de filtrage unique est applique un flux (la premire qui autorise ou interdit ce flux) ;
il est possible de dfinir prcisement les flux 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 filtrage.

4. Certaines solutions ne permettent pas de grer finement les flux mis ou reus par le pare-feu. Dans ces cas prcis,
des rgles sont automatiquement ajoutes la politique de filtrage, 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 flux destination du pare-feu
Cette premire section contient un nombre minimal de rgles car un pare-feu noffre 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

R1

Destination
Interface dadministration de la passerelle
Interface dadministration de la passerelle

Service
ssh, https
get-snmp

Action
Autoriser
Autoriser

Journalisation
Oui
Oui

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

3.3.2 Section n2 : rgles dautorisation des flux mis par le pare-feu

Cette seconde section contient galement un nombre limit de rgles, elle ne dcrit que les flux
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 flux 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

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

Service
syslog
trap-snmp
ssh

Action
Autoriser
Autoriser
Autoriser

Journalisation
Oui
Oui
Oui

Page 6 sur 15

R2

Les rgles de scurit qui autorisent les flux ayant pour origine le pare-feu doivent tre
regroupes dans la politique de filtrage. Ces rgles sont peu nombreuses et doivent tre
dfinies 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 trafic 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 flux 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 deffectuer cette vrification. La journalisation est obligatoirement active pour cette rgle afin
de conserver la trace de lensemble des flux non lgitimes destination de la passerelle.

R3

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

3.3.4 Section n4 : rgles dautorisation des flux mtiers

Cette section contient les rgles dautorisation qui dcrivent les flux 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 offerts : 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 flux mtiers doivent tre regroupes et organises selon une
logique tablie et adapte au contexte. Ces rgles constituent lessentiel de la politique de
filtrage, elles doivent tre dfinies prcisement au niveau de leurs adresses sources, de leurs
adresses de destination et de leur services.

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

Page 7 sur 15

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 flux non autoriss dont la trace nest volontairement pas conserve (certains flux de broadcast par exemple) afin de maintenir les journaux de la
passerelle exploitables. Cela suppose quune trace de ces flux 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 finale

Cette section ne comporte quune seule rgle dinterdiction ; celle-ci est dite finale car celle se trouve
toujours en dernire position dans la politique. Cette rgle a pour objectifs dune part dinterdire le
trafic qui na pas t explicitement autoris par les rgles prcdentes, dautre part de conserver une
trace des flux 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 fin de la politique de filtrage, mais celle-ci nest gnralement pas journalise ou napparat pas explicitement la
fin de la politique ; cest la raison pour laquelle une rgle finale explicite est ajoute dans tous les cas.

R6

Lajout dune rgle explicite dinterdiction finale 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 flux non lgitimes.

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

Page 8 sur 15

4 Mise en forme dune politique de filtrage rseau

La lisibilit et la maintenabilit dune politique de filtrage dpend avant tout de sa forme ; cest la
raison pour laquelle il est primordial de dfinir et de documenter les conventions respecter lors de
son laboration et de sa mise jour.
Une politique de filtrage se traduit par une liste de rgles, elles mme composes dobjets de diffrentes 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 dfinition 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 dfinition 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 dfinir 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 diffrentes 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 dfinir dans la
convention.
R8

Une convention de nommage doit tre dfinie pour lensemble des types dobjets qui composent les rgles de la politique de filtrage.

4.1.2 Convention de mise en forme

Certaines solutions offrent 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 confiance de la zone : un jeu de dgrad est choisi afin dassocier une couleur chacun des niveaux de confiance 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 confiance

Le rle de la zone : une couleur est associe selon un critre fonctionnel des diffrents types de
zone existant dans larchitecture. Le tableau 2 est un exemple illustrant ce type de code couleur :
Couleur

DMZ
DMZ
DMZ
DMZ

Type de zone
hbergeant les serveurs dauthentification
hbergeant les serveurs de base de donnes
hbergeant les proxys
hbergeant les reverse proxys

Table 2 Coloration selon un critre fonctionnel

R9

La dfinition 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 flches 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 signification de chacune des rgles composant la politique de filtrage.
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 modification de la rgle ;
lidentifiant de lintervenant qui a implment ou mis jour la rgle dans un format court.
Les lments choisis doivent tre rflchis 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 spcifiques chacune des rgles de scurit sont disponibles, il est important de les utiliser pour expliciter le contenu de la politique de filtrage.
Les lements constitutifs de ces champs doivent respecter une structure pralablement
dfinie et adapte au contexte.

4.3 Sparateurs de rgles

Certaines solutions sont capables de scinder la politique de filtrage 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 flux mtiers (contenu de la section n4). Si les sparateurs
disposent dun champ texte ditable, une convention de nommage doit galement tre dfinie 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 flux mtiers :
Section
1
2
3

5
6

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 finale

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

Page 12 sur 15

5 Bonnes pratiques dordre gnral

5.1 Dsactivation des flux implicites
Certaines solutions permettent louverture de flux implicites dans le but de faciliter ladministration
de la passerelle ou de simplifier 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 flux implicites que lon peut rencontrer :
flux ncessaires ladministration de la passerelle (https, ssh) ;
flux ncessaires au fonctionnement de la passerelle (snmp, ntp, syslog) ;
flux permettant ltablissement des VPN (IKE, IPsec) ;
flux DNS ;
flux ICMP.
R11

Une gestion rigoureuse de la politique de filtrage conduit dsactiver les flux implicites
sils existent et si la dsactivation est possible ; les flux lgitimes quels quils soient doivent
tre dfinis 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
flux stritement ncessaires au besoin.

5.2 Vrification de la squence de dmarrage

Un pare-feu peut tre vulnrable lors de sa squence de dmarrage. En effet, durant le laps de
temps qui spare lallumage lectrique de lquipement et lapplication effective de la politique de
filtrage 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 filtrera pas
les paquets et les routera en effectuant aucun contrle. Il convient donc de vrifier quelle tape de la
squence de dmarrage le routage sactive sur lquipement.
R12

Afin 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).

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

Page 13 sur 15

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. Leffort
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 filtrage rseau doivent tre documentes et diffuses aux personnes en charge de la mise en oeuvre et la gestion des pare-feux.

6.2 Validation
Les politiques de filtrage 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 filtrage,
mais il ne permet pas de se prmunir contre certaines erreurs humaines ou certains fonctionnements
spcifiques ; charge ladministrateur de rester vigilant quant la comprhension des oprations quil
excute.
R14

Une politique de filtrage rseau doit tre teste une fois implmente.

6.3 Maintenance
Pour conserver son efficacit et sa fonction de scurisation, une politique de filtrage doit tre passe
en revue rgulirement.
Ces vrifications 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 vrifier 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 filtrage ne dispense pas de la ralisation de ces revues rgulires.
R15

Une politique de filtrage 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 dfini sur un pare-feu NetAsq (solution qualifie par lANSSI).

Figure 1 Politique de filtrage rseau sur NetAsq

Les flux mis par le pare-feu (section n2) napparaissent pas dans lexemple ci-dessous car ils sont
dfinis 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