Goffinet Training

Dans un système d’information, les politiques de filtrage et de contrôle du trafic sont placées sur un matériel ou un logiciel  intermédiaire communément appelé pare-feu (firewall). Ce Linuxlabs propose de mettre en place ce type de solution.

Lectures préalables.

Sur l’état du marché à partir d’une étude « Gartner, Magic Quadrant for Enterprise Network Firewalls ».

Pour les généralités on ira lire avec prudence Wikipedia : Pare-feu_(informatique), Firewall_(computing), Zone_démilitarisée_(informatique), etc.

Pour la mise en oeuvre se documentera sur Iptables ou on implémentera une distribution comme M0n0wall ou PFsense ou encore Zentyal. Un bon début est de suivre (en anglais) ce guide : Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables.

Arrière-plan.

1. Introduction.

La maîtrise des concepts protocolaires IPv4/IPv6 et de TCP/UDP voire des applications comme HTTP ou DNS sont nécessaires pour la mise en oeuvre d’une solution de type pare-feu.

Bien souvent, les CPE et les stations de travail embarquent un pare-feu qui par défaut autorise tout trafic venant d’un réseau de confiance (et son trafic de retour légitime), typiquement un LAN, alors que tout accès extérieur non contrôlé est refusé, par exemple venant directement du WAN, une connexion extérieure vers l’Internet. Ces politiques de sécurité peuvent être mise en oeuvre finement sur les pare-feux. Dans une perspective sécuritaire, tout trafic TCP/IP non contrôlé est considéré comme une attaque.

2. Taxonomie

On distinguera les fonctionnalités : pare-feu sans état, pare-feu avec état, et pare-feu applicatif. Dans une autre typologie fondée sur l’emplacement des fonctionnalités, on distinguera les pare-feux locaux des pare-feux dédiés.

3. Fonctionnalités et technologies complémentaires.

Compte tenu de son emplacement critique, il hébergera ou utilisera des fonctions de mandataire pour le trafic local ou distant afin d’effectuer un contrôle plus fin et/ou plus efficace

• en inspectant le contenu
• ou en contrôlant l’identité des utilisateurs.

Dans le même ordre d’idée, on pourra y trouver des fonctions

• de concentrateur VPN,
• de répartiteur de charge du trafic,
• le support des encapsulations VLAN,
• des protections contre les virus, logiciels et messages TCP/IP malveillants,
• de la détection et/ou de la prévention de d’intrusion (IDS/IPS),
• etc.

En soi, le pare-feu ne protège le réseau que de manière incomplète. On complétera l’infrastructure sécurisée par des solutions de surveillance du réseau. L’Open Source propose entre autres des distributions spécialisées qui n’ont rien à envier aux solutions commerciales telles que OpenVAS. Une infrastructure de gestion des anti-virus et pare-feu locaux ainsi que des mises à jours des systèmes d’exploitation et des logiciels installées est aussi conseillée. Cette perspective de la sécurité des systèmes d’informations envisage celle-ci de manière globale et unifiée dans une collaboration transparente entre les éléments du réseau et les systèmes qui fonctionnent sur les périphériques. Dans cette perspective concrètement difficile à mettre en oeuvre, les systèmes Open Source sont compétitifs.

4. Topologies

Selon les besoins, on placera les politiques de filtrage à différents endroits du réseau, au minimum sur chaque hôte contrôlé et en bordure du réseau administré. Ces emplacements peuvent être distribué dans la topologie selon sa complexité.

Pour éviter qu’il ne devienne un point unique de rupture, on s’efforcera d’assurer la redondance des pare-feux.

La virtualisation des fonctionnalités de filtrage et de contrôle global du trafic est un besoin du marché actuel pour les centre de données autant que pour le déploiement du architecture de type cloud.

5. Fonctionnement et configuration

La configuration d’un pare-feu consiste la plupart du temps en un ensemble de règles qui déterminent une action de rejet ou d’autorisation du trafic en fonction de certains critères telles que :

• l’origine et la destination du trafic,
• des informations d’un protocole de couche 3 (IPv4, IPv6, ARP, ICMP, etc.),
• des informations d’un protocole de couche 4 (TCP, UDP, etc.)
• et/ou des informations d’un protocole applicatif (HTTP, SMTP, DNS, etc.).

Les règles sont appliquées en fonction de la direction du trafic entrant ou sortant sur une interface, avant ou après le processus de routage des paquets. Cette dernière réalité diffère selon le logiciel ou le matériel choisi pour remplir ces tâches.

Chaque règle est examinée selon son ordonnancement.

1. Si le trafic ne correspond pas à la première règle, la seconde règle est évaluée et ainsi de suite.
2. Lorsqu’il y a correspondance entre les critères de la règle et le trafic, l’action définie  est prise et les règles suivantes ne sont pas examinées. La terminologie des actions usuelles peuvent être accept, permit, deny, block, reject ou autres.
3. En général, un ensemble de règles se termine par le refus de tout trafic, soit en dernier recours le refus du trafic. Ce comportement habituellement défini par défaut ou implicitement refuse tout trafic pour lequel il n’y avait pas de correspondance dans les règles précédentes.

6. Fonctionnalité NAT

Puisque chaque paquet qui traverse le pare-feu est examiné, les éléments de filtrage se proposent aussi de réécrire les en-têtes IP et TCP/UDP pour assurer des tables de traduction. Je parle déjà de ces fonctionnalités sur le site http://cisco.goffinet.org/search?SearchableText=nat. En rien le NAT ne constitue une mesure de sécurité. Penser autrement est une méprise. Toutes les configurations pratiques contredisent cette légende.

Exercice.

Fondamentalement, l’application la plus courante est celle d’un pare-feu à état en bordure du réseau qui pourra héberger des fonctionnalités de filtrage et d’authentification plus élevées.

Topologie typique de pare-feu à état

1. Mise en place de la topologie.

Pour simuler une telle topologie sur une station de travail, on profitera pleinement de la virtualisation en utilisant les réseaux VMNET, soit des commutateurs/routeurs virtuels de VMWare. En tant que commutateur, il se ponte à une interface physique; en tant que routeur, il remplit des fonctions de routeur NAT avec service DHCP; la segmentation LAN peut être totalement isolée des interfaces physiques. On les configure grâce au binaire « vmnetcfg.exe ». Les adaptateurs virtuels peuvent y être connectés de plusieurs manières. On ira lire le chapitre « Configuring Network Connections » de VMWare Workstation.

Une topologie consiste à créer trois réseaux VMNET distincts, un premier ponté (bridged) au réseau local qui représentera le LAN, un second NATé (NAT) pour assurer la connexion WAN et enfin, un réseau indépendant qui hébergera par exemple un service Web. Une station d’audit de sécurité pourra se placer dans le réseau local ou sur la connexion WAN.

[Image]

Une autre topologie de laboratoire plus simple consiste à utiliser le réseau ponté pour la connexion WAN et des réseaux virtuels indépendants pour les connexions LAN et DMZ. Aussi, on se contenter de simuler le WAN en y plaçant une machine d’audit et en utilisant un réseau VMNET ponté pour le LAN.

2. Applications de règles de filtrage.

Une politique de filtrage typique consistera en les règles suivantes basées sur les protocoles IP/TCP/UDP.

Politique de sécurité typique sur un pare-feu à état.

Une autre manière de symboliser les choses :

LAN > WAN
WAN X LAN
LAN > DMZ
DMZ X LAN
WAN X DMZ (sauf TCP80 par exemple)
DMZ > WAN

3. Configuration LAN/WAN

4. Mise en place du NAT si nécessaire.

5. Mise en place de la DMZ (en complément)

6. Auditer sa topologie et analyser le trafic.

Exercices complémentaires.

1. Mise en place d’un mandataire (proxy) local.

2. Mise en place de l’authentification NTLM.

3. Connexion à un service Active Directory.