66
service émetteur : Télécom Bretagne date : 11 mars 2010 Contributeurs : David FAVA & Hervé MARTIN Rapport de projet professionnel Source Address Validation Improvement Projet professionnel réalisé dans le cadre des scolarités : Mastère spécialisé Réseaux et Services de Mobiles Mastère spécialisé Sécurité des Systèmes d’Information

Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

  • Upload
    buithuy

  • View
    221

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

service émetteur : Télécom Bretagne

date : 11 mars 2010

Contributeurs : David FAVA & Hervé MARTIN

Rapport de projet professionnel Source Address Validation Improvement

Projet professionnel réalisé dans le cadre des scolarités :

Mastère spécialisé Réseaux et Services de Mobiles Mastère spécialisé Sécurité des Systèmes d’Information

Page 2: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation
Page 3: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

3

Sommaire

SOMMAIRE ....................................................................................................................... 3

A ETAT DE L’ART SAVI ................................................................................................. 6

1 CADRE ................................................................................................................................. 6 1.1 Constat ...................................................................................................................................... 6 1.2 Modèle ...................................................................................................................................... 6 1.3 Optimisations ............................................................................................................................ 7

2 MENACES DUES A L’USURPATION D’ADRESSE ................................................................................. 8 2.1 Vecteurs d’attaque basés sur l’usurpation ............................................................................... 8

2.1.1 Attaques aveugles .............................................................................................................. 9 2.1.2 Attaques non aveugles ....................................................................................................... 9

2.2 Solutions actuelles contre l’usurpation .................................................................................... 9 2.2.1 Cas d’un hôte vers un autre sur le même segment ou via un switch ............................... 10 2.2.2 Cas des routeurs en amont ............................................................................................... 10 2.2.3 Cas des PE Router ........................................................................................................... 11 2.2.4 Cas d’un NNI Router vers un autre NNI Router ............................................................. 11 2.2.5 Usurpation dans les segments de LAN ............................................................................ 11 2.2.6 Liage de l’adresse à un port ............................................................................................. 11 2.2.7 Techniques cryptographiques .......................................................................................... 11

2.3 Considérations diverses .......................................................................................................... 11 2.4 Solutions actuelles pour la validation des adresses IP source ................................................ 11

3 UNE PREMIERE APPROCHE DE L’IMPLEMENTATION DE SAVI ............................................................ 12 3.1 Modèle conceptuel d’un switch SAVI ..................................................................................... 12 3.2 Proposition .............................................................................................................................. 13

3.2.1 Implémentation dans une configuration DHCP ............................................................... 13 3.2.2 Implémentation utilisant SEND (SEcure Neighbor Discovery) ...................................... 13 3.2.3 Implémentation utilisant ND (Neighbor Discovery) ....................................................... 14

4 FIRST-COME FIRST-SERVE SOURCE ADDRESS VALIDATION FOR LOCALLY ASSIGNED ADDRESSES (FCFS-SAVI) 14

4.1 Cadre d’utilisation ................................................................................................................... 14 4.2 Spécifications de FCFS SAVI .................................................................................................... 15

4.2.1 Structures de données ...................................................................................................... 15 4.2.2 Algorithme ....................................................................................................................... 16

4.2.2.1 Traitement du trafic de transit ..................................................................................... 16 4.2.2.2 Traitement du trafic local ............................................................................................ 16 4.2.2.3 Configuration des ports ............................................................................................... 17

4.3 Considérations de sécurité ..................................................................................................... 17

5 SOLUTION SAVI POUR DHCP .................................................................................................. 18 5.1 Structures de données conceptuelles..................................................................................... 18 5.2 Attributs des binding anchors ................................................................................................. 19 5.3 Mise en place des liens ........................................................................................................... 19

5.3.1 Définitions des états et des évènements........................................................................... 19 5.3.2 Processus d’espionnage des paquets de contrôle ............................................................. 20 5.3.3 Machine à états finis ........................................................................................................ 20

5.4 Filtrage des paquets ................................................................................................................ 21

6 SEND-BASED SOURCE-ADDRESS VALIDATION IMPLEMENTATION ..................................................... 22

Page 4: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

4

6.1 Structures de données ............................................................................................................ 22 6.2 Traitement du trafic ................................................................................................................ 22

6.2.1 Traitement du trafic de transit ......................................................................................... 23 6.2.2 Traitement du trafic local à destination du dispositif SAVI ............................................ 23 6.2.3 Traitement du trafic local ................................................................................................ 23

B MISE EN ŒUVRE DU PROJET INDUSTRIEL ............................................................... 25

1 PROBLEMATIQUE ET EVOLUTIONS DU SUJET ................................................................................. 25 1.1 Problématique ........................................................................................................................ 25 1.2 Evolution initiale du sujet ....................................................................................................... 25 1.3 Seconde évolution du sujet .................................................................................................... 27

2 MISE EN PRATIQUE ............................................................................................................... 27 2.1 Choix logiciels .......................................................................................................................... 27 2.2 Illustration association MAC/identifiant ................................................................................. 28 2.3 Illustration association MAC/IPv6 ........................................................................................... 31 2.4 Mauvaise authentification ...................................................................................................... 33 2.5 Usurpation d’adresse MAC ..................................................................................................... 35 2.6 Ajout d’adresse IPv6 ............................................................................................................... 36

3 BILAN ............................................................................................................................... 37 3.1 Difficultés rencontrés .............................................................................................................. 37

3.1.1 Difficultés d’ordre matériel ............................................................................................. 37 3.1.2 Difficultés d’ordre logiciel .............................................................................................. 37 3.1.3 Difficultés d’ordre personnel ........................................................................................... 37

3.2 Enseignements ........................................................................................................................ 37

ANNEXES ........................................................................................................................ 38

ANNEXE 1 - FCFS SAVI ...................................................................................................................... 38

ANNEXE 2 - SAVI-DHCP .................................................................................................................... 41

ANNEXE 3 - SEND-SAVI .................................................................................................................. 43

ANNEXE 4 - LISTES DIVERSES ............................................................................................................. 47 4.1. Liste des illustrations .............................................................................................................. 47 4.2. Liste des références ................................................................................................................ 47

ANNEXE 5 - FICHIERS DE CONFIGURATION ............................................................................................. 48 5.1. hostapd ................................................................................................................................... 48

5.1.1. Fichier hostapd.conf ........................................................................................................ 48 5.1.2. Fichier hostapd.radius_clients ......................................................................................... 54

5.2. freeradius ................................................................................................................................ 54 5.2.1. Fichier eap.conf ............................................................................................................... 54 5.2.2. Fichier radiusd.conf ......................................................................................................... 57 5.2.3. Fichier users.conf............................................................................................................. 62

5.3. Fichier wpa_supplicant.conf (client) ....................................................................................... 63

Page 5: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

5

Il apparaît nécessaire aujourd’hui, dans un souci constant d’authentification et de non-répudiation, de tenter de lier fortement l’identité d’un utilisateur à son adresse IP. L’utilisation de différents protocoles et standards pourraient permettre de réaliser ce lien :

le protocole Source Address Validation Improvement (SAVI), qui est en cours de définition à

l’Internet Engineering Task Force (IETF), a pour but principal d’empêcher l’usurpation

d’adresses IP (« IP spoofing ») en réalisant un lien « fort » entre l’adresse logique (@IP) et le

lien physique (numéro de port de raccordement et/ou adresse MAC de la station). Ce

protocole permet également de filtrer les paquets IP sur l’adresse source grâce à la création

d’un lien fort (« binding anchor ») entre l’adresse IP de l’utilisateur (rendu légitime grâce au

« binding anchor ») et le paramètre physique (numéro de port sur le switch de

raccordement, adresse MAC, numéro de canal radio, index du VPN…) ;

le Protocol for carrying Authentication for Network Access (PANA) défini notamment par les

RFC 5191 et 5193 est un mécanisme de transport de l’Extensible Authentication Protocol

(EAP) au niveau réseau permettant l’authentification de l’accès au réseau entre un client et

son réseau d’accès. PANA est donc un protocole s’appuyant sur la pile IP/UDP et permet de

lier l’identité d’un utilisateur à plusieurs paramètres notamment à son adresse IP ;

le port-based network access control (802.1X) défini par l’Institute of Electrical and

Electronics Engineers (IEEE) est un standard qui permet de restreindre l’utilisation des ports

d’un réseau local afin de sécuriser les communications entre des dispositifs authentifiés et

autorisés ; ce standard passe par l’authentification de l’accès au réseau lors de la connexion

physique à ce réseau et permet de lier l’identité d’un utilisateur (celui qui s’authentifie) à son

port de connexion au réseau.

L’objectif du projet industriel est, dans un premier temps, d’étudier théoriquement les protocoles mis en jeu afin de choisir l’association la plus adaptée à la problématique, puis de mettre en place une maquette permettant d’évaluer le protocole SAVI et enfin, en le couplant au protocole d’authentification choisi entre le standard 802.1X et le protocole PANA, de tenter de lier une identité à une adresse IPv6.

Page 6: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

6

A Etat de l’art SAVI

1 CADRE

Cette section est tirée du document draft-ietf-savi-framework-01(1) du 25 octobre 2010 publié sur le site de l’IETF.

1.1 CONSTAT

L’usurpation (spoofing) d’adresses IP source permet des phénomènes d’imitation (impersonation) de dissimulation (concealment) et de redirection de trafic malveillant (malicious traffic redirection). Mais l’architecture d’internet ne permet pas d’empêcher cette usurpation. De plus, l’adresse IP source ne jouant aucun rôle dans l’expédition d’un paquet, elle peut être choisie par l’expéditeur sans compromettre la délivrance du paquet. La validation de l’adresse IP source peut avoir lieu à des granularités différentes : le filtrage d’entrée (ingress filtering *BCP38+ (2)) est un standard pour la validation de l’adresse IP source qui vérifie que le préfixe d’une adresse IP source route vers le réseau en provenance duquel le paquet a été reçu. La validation plus fine de l’adresse IP source serait bénéfique pour permettre de :

localiser un hôte, l’autoriser et l’authentifier à partir de l’adresse IP source

identifier efficacement les hôtes au comportement déviant

La méthode SAVI a été développée pour compléter l’ingress filtering avec la validation, à une granularité la plus fine, d’une adresse IP source individuelle et standardisée. Cette méthode empêche également un hôte d’usurper les adresses IP source des autres hôtes attachés au même lien et se veut modulaire et reproductible (basée sur le réseau uniquement).

1.2 MODELE

Une instance SAVI est placée sur le chemin des paquets envoyés par les hôtes et impose l’utilisation par ces hôtes d’adresse IP source légitimes conformément aux trois phases suivantes :

identifier quelles adresses IP source sont légitimes pour un hôte en se basant sur la surveillance des paquets échangés par l’hôte

lier une adresse IP légitime à une propriété de la couche liaison sur laquelle fonctionne le réseau de l’hôte ; cette propriété, appelée ancre de liaison (binding anchor) doit être vérifiable dans chaque paquet envoyé par l’hôte et doit être plus difficile à usurper que l’adresse IP source de l’hôte

imposer que les adresses IP source incluses dans les paquets correspondent aux binding anchors auxquelles elles ont été liées

Point particulier : la méthode SAVI sera d’autant plus efficace que l’instance SAVI sera proche des hôtes ; par exemple, l’instance SAVI pourra être placée dans le switch auquel sont attachés les hôtes dont les adresses IP source sont en cours de validation. Le déploiement de la méthode SAVI est conditionné par les deux aspects suivants :

l’identification des adresses IP source légitimes dépend de la méthode utilisée pour l’attribution des adresses IP

les binding anchors dépendent de la technologie d’élaboration de la liaison sur laquelle elles sont utilisées

Ainsi, la méthode SAVI possède de multiples variantes dépendantes de la méthode d’attribution des adresses IP. Les cas traités dans ce document seront :

First-Come First-Serve Source Address Validation for locally assigned addresses (FCFS-SAVI) (3)

Page 7: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

7

SAVI Solution for DHCP (4)

SEND-based Source-Address Validation Implementation (5)

De même, la méthode SAVI supporte une gamme de binding anchors dont les impacts seront significativement différents quant à la sécurité qu’elles fournissent. Ainsi, les binding anchor peuvent être :

l’identifiant unique (EUI-48 ou EUI-64) défini par l’IEEE de l’interface de l’hôte

le port d’un switch Ethernet auquel un hôte est attaché

l’association de sécurité, sur une liaison sans fil, entre un hôte et la station de base

d’autres items non détaillés dans ce document

1.3 OPTIMISATIONS

Afin de ne pas subir le facteur d’échelle et donc réduire les exigences de mémoire pour les instances SAVI, chaque instance SAVI sera uniquement responsable de la validation des adresses IP source sur les ports auxquels les hôtes sont directement connectés (ou à travers de switch sans instance SAVI). Les switches implémentant SAVI forment alors un périmètre de protection. Remarques :

la validation de l’adresse IP source est activée sur tous les ports situés le long du périmètre de protection et désactivée sur les autres ports

l’intégration d’un legacy switch dans le périmètre de protection permet que ce dernier soit unique et non partitionné ; les exigences en mémoire pour les instances SAVI sont ainsi minimisées car chaque lien n’est stocké qu’une seule fois par l’instance SAVI relié à l’hôte en cours de validation

il est possible dans ce cas d’intégrer le legacy switch dans le périmètre de protection car la topologie de niveau liaison représentée sur le schéma garantit que les paquets ne peuvent pénétrer le périmètre de protection via ce legacy switch

Page 8: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

8

Afin d’être fiabilisée et de limiter les perturbations que peuvent engendrer des liens manquant pour des adresses IP légitimes, la méthode SAVI inclut un mécanisme pour la création réactive de liens à partir des paquets réguliers (data). Cette création a lieu lorsque des instances SAVI reconnaissent des suppressions excessives de paquets réguliers originaires de la même adresse IP : l’instance SAVI vérifie alors si cette adresse IP est unique sur la liaison et si tel est le cas, elle lui crée un lien.

2 MENACES DUES A L’USURPATION D’ADRESSE

Cette section est tirée du document draft-ietf-savi-threat-scope(6) du 8 septembre 2010 Le protocole internet (IPv4 [RFC0791](7) ou IPv6 [RFC2460](8)) emploie une méthode de transmission des paquets saut par saut en mode datagramme. Les hôtes générant des paquets à transmettre ont l’opportunité de falsifier l’adresse source figurant dans ces paquets et ainsi usurper une adresse source. La vérification des adresses source est devenue une nécessité afin de détecter et rejeter les paquets usurpés. Des solutions de filtrage d’adresses source telles que BCP 38 [RFC2827](2) existent déjà mais ne font que du ingress filtering (filtrage à l’entrée du réseau sur le préfixe de l’adresse IP source). Les entreprises souhaiteraient mettre en œuvre cette protection localement et avec une meilleure traçabilité et ainsi empêcher les hôtes d’un même sous-réseau local d’usurper les adresses sources des autres hôtes. Cette partie dresse succinctement quelques détails concernant les vecteurs de menace basés sur l’usurpation d’adresse et traite des implications dues aux topologies des différents réseaux.

2.1 VECTEURS D’ATTAQUE BASES SUR L’USURPATION

Deux classes de vecteurs d’attaque sont à considérer : les attaques aveugles et les attaques non-aveugles

Figure 1 : concept de périmètre de protection

Page 9: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

9

2.1.1 Attaques aveugles

Les attaques aveugles ont lieu lorsque l’attaquant n’a pas accès à une source légitime ou au système cible. Quelques exemples d’attaques aveugles sont listés ci-dessous :

les attaques déni de service par paquet unique consistent à injecter une information usurpée dans le réseau dont la conséquence est soit un effondrement complet du système cible, soit une corruption de la configuration ou d’une autre information du système cible de manière à impacter le réseau ou d’autres services (exemples : LAND attack1)

les attaques déni de service par flooding (inondation) consistent à envoyer un grand nombre de paquets à travers un système cible afin de le rendre inaccessible ; ces paquets ont généralement une adresse IP source usurpée pour cacher la source réelle du système attaquant

les vers et autres malware falsifient leurs adresses source avant de se propager vers d’autres systèmes afin de cacher l’adresse source du système qu’ils ont infecté

les attaques réfléchissantes qui utilisent une adresse source usurpée afin que les paquets envoyés engendrent des réponses multiples vers le système cible (exemple des attaques smurf : un message ICMP echo request avec une adresse IP source usurpée engendrant un grand nombre de messages ICMP echo response dirigés vers le système cible)

2.1.2 Attaques non aveugles

L’attaque la plus connue dans cette partie est le Man in the Middle (MITM)

2.2 SOLUTIONS ACTUELLES CONTRE L’USURPATION

La première exigence est d’éliminer d’internet les datagrammes contenant des adresses source usurpées. Les sites pour lesquels une relation est possible entre l’adresse source et la topologie du réseau ont l’opportunité d’identifier et d’éliminer de tels datagrammes. Par exemple, certains dispositifs internet peuvent confirmer que :

l’adresse IP source est appropriée à l’adresse de la couche inférieure (elles identifient le même système)

l’adresse IP source est appropriée au dispositif du port du switch de niveau 2 (l’adresse a été attribuée au système qui utilise ce port)

le préfixe auquel appartient l’adresse IP source est appropriée à la partie de la topologie du réseau de laquelle le paquet provient

1 L'« attaque LAND » est une attaque réseau datant de 1997, utilisant l'usurpation d'adresse IP afin d'exploiter une faille de certaines

implémentations du protocole TCP/IP dans les systèmes. Le nom de cette attaque provient du nom donné au premier code source (appelé « exploit ») diffusé permettant de mettre en oeuvre cette attaque : land.c.

L'attaque LAND consiste ainsi à envoyer un paquet possédant la même adresse IP et le même numéro de port dans les champs source et destination des paquets IP (source : http://www.commentcamarche.net/contents/attaques/attaque-land.php3)

Page 10: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

10

La figure 2 montre les quatre chemins sur lesquels une adresse source peut être validée :

depuis un hôte vers un switch ou entre deux hôtes via le switch

depuis un hôte vers le CPE router2 de l’entreprise

depuis le CPE router vers le PE router3 de l’ISP4 (et le chemin inverse)

entre deux NNI router5 de deux ISP différents

En règle générale, les paquets contenant des adresses usurpées peuvent être détectés et détruits par des dispositifs qui autorisent les liens entre adresse IP et topologie du réseau. Le degré de confiance en l’adresse source dépend de l’emplacement de la détection de l’usurpation et de l’agrégation de préfixe mise en place entre cet emplacement et la source du paquet.

2.2.1 Cas d’un hôte vers un autre sur le même segment ou via un switch

Un paquet contenant une adresse usurpée peut être détecté au niveau du lien sur lequel la source du paquet est connectée : les adresses sources IP et couche liaison sont disponibles toutes les deux et peuvent être confrontées ; un paquet pour lequel l’adresse IP source ne correspond pas à l’adresse de la couche liaison peut alors être détruit. Quand deux hôtes sont connectés à travers un switch, l’hôte source peut être précisément identifié en se basant sur le port à travers lequel le paquet est reçu ou sur l’adresse MAC.

2.2.2 Cas des routeurs en amont

Les routeurs situés en amont peuvent également filtrer le trafic en provenance des routeurs plus en aval. Cependant, comme ils n’ont pas accès à l’adresse couche liaison de l’expéditeur du paquet, ils ne peuvent que confirmer que l’adresse IP source contient un préfixe approprié aux routeurs en aval

2 Customer Premises Equipment Router : le routeur situé sur la bordure du réseau client (routeur de sortie) qui appartient soit au

client soit au fournisseur d’accès 3 Provider Edge Router : le routeur directement connecté au réseau du client d’un fournisseur d’accès 4 Internet Service Provider : fournisseur d’accès internet 5 Network to Network Interface Router : le routeur d’un ISP directement connecté au routeur d’un autre ISP ou d’un autre réseau plus

vaste

Figure 2 : endroits où une adresse peut être validée

Page 11: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

11

et en provenance desquels le paquet a été reçu. Unicast RPF et Strict RPF6 sont deux exemples de ce genre de filtrage et sont détaillés dans la RFC3704.

2.2.3 Cas des PE Router

BCP 38(2) encourage spécifiquement les fournisseurs d’accès à utiliser le filtrage d’entrée (ingress filtering) pour limiter l’incidence des adresses usurpées dans le réseau. Le problème est de savoir à quel point ils peuvent faire confiance aux routeurs des clients en aval et dans quelle mesure le fournisseur peut imposer à ses clients de mettre en œuvre le filtrage d’entrée sur ses routeurs.

2.2.4 Cas d’un NNI Router vers un autre NNI Router

Les considérations sont ici les mêmes qu’entre les routeurs d’un fournisseur d’accès et les routeurs d’un client : chacun des fournisseurs d’accès doit avoir la certitude que l’autre fournisseur applique le filtrage d’entrée et le fait appliquer à ses clients.

2.2.5 Usurpation dans les segments de LAN

Dans un segment de LAN ou de multiples hôtes résident, il est nécessaire de lier l’adresse IP à une adresse de niveau 2 (adresse MAC) afin de priver un attaquant de certains vecteurs d’attaque tel que MITM.

2.2.6 Liage de l’adresse à un port

Une grande partie de la menace d’usurpation d’adresse dans un LAN peut être marginalisée en configurant les ports de manière à lier adresse IP et adresse MAC. Cette configuration peut être manuelle, automatique ou utiliser le protocole 802.1X(9).

2.2.7 Techniques cryptographiques

Le protocole SEND(10) emploie des techniques cryptographiques mais il est peu implémenté. Une méthode SAVI utilisant ce protocole est développée au paragraphe 6.

2.3 CONSIDERATIONS DIVERSES

Les considérations suivantes sont à prendre en compte dans les éventuelles propositions d’implémentation d’une méthode SAVI :

les différents mécanismes d’attribution d’adresse IP (manuel, dynamique…)

les dispositifs avec plusieurs adresses (routeurs, NATs, hôtes multi-instances, hôtes multi-LAN, firewalls, hôtes mobiles…)

concernant IPv6 : l’auto configuration des adresses IP, l’espace d’adressage important…

2.4 SOLUTIONS ACTUELLES POUR LA VALIDATION DES ADRESSES IP SOURCE

Les techniques actuelles pour la validation des adresses IP source sont insuffisantes et possèdent toutes au mois l’une des lacunes suivantes :

faux-négatifs : ils permettent à un attaquant d’utiliser une adresse IP source usurpée tout en réussissant la validation de l’adresse IP source

faux-positifs : ils causent une interruption de service pour les hôtes utilisant une adresse IP source légitime

configuration non triviale : les risques d’une mauvaise configuration décourage les opérateurs à utiliser une méthode de validation d’adresse IP source

propriétaire : les politiques des organisations encouragent les techniques standardisées et empêchent ainsi le développement de techniques propriétaires

6 Unicast Reverse Path Filtering et Strict Reverse Path Filtering

Page 12: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

12

3 UNE PREMIERE APPROCHE DE L’IMPLEMENTATION DE SAVI

Cette section se réfère au document draft-baker-savi-one-implementation-approach-00 du 10 mai 2010 (EXPIRE le 11 novembre 2010).

3.1 MODELE CONCEPTUEL D’UN SWITCH SAVI

Considérons le plan simplifié d’un switch au niveau du traitement des données. Il y existe deux sortes de filtres :

le port filter applique une politique aux datagrammes reçus sur un port, généralement en détruisant ou en autorisant les datagrammes sélectionnés

la forwarding logic identifie l’ensemble des ports vers lesquels une trame Ethernet d’un port donné sera envoyée ; cet ensemble de ports peut être vide, ne correspondre qu’à un seul port, un ensemble plus large ou même être constitué de tous les ports sauf celui par lequel est arrivé le datagramme

Le modèle SAVI considère principalement le port filter. Son implémentation configure le port filter pour :

identifier les datagrammes IPv6 [RFC2460](8)

isoler les valeurs liées qui forment un sous-ensemble choisi parmi le port, l’adresse MAC, et l’adresse IPv6 source

accepter les datagrammes IPv6 qui sont liés avec un des liens de la liste des liens spécifiés

détruire tous les autres datagrammes IPv6

Tout dépend également des relations de lien entre les interfaces et les adresses qui peuvent être :

configurées de manière statique

dérivées de Stateless Address Autoconfiguration

désignées par DHCPv6

Figure 3 : niveau données d'un switch Ethernet

Page 13: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

13

3.2 PROPOSITION

En temps normal, les tables de filtrage et de transfert ne requièrent aucune modification : le port filter et la forwarding logic s’y réfèrent pour manipuler les datagrammes. Cependant, dans certains cas exceptionnels, le datagramme ou des informations le concernant sont mis en file d’attente dans la control plane pour une analyse ultérieure. Ces cas pourraient inclure les informations concernant les échecs relatifs à SAVI sur les entrées du port filter.

Si le port filter ne reconnaît aucune concordance dans sa table, le datagramme est détruit mais une requête est mise en file d’attente dans la Table Management Process afin de déterminer si une nouvelle concordance SAVI doit être ajoutée au port filter. Si c’est le cas, le port filter est mis à jour par l’ajout d’un nouveau lien et quand le client retransmet son datagramme, il passe.

3.2.1 Implémentation dans une configuration DHCP

Dans un réseau utilisant DHCPv6 [RFC3315](11), une source d’information autorisée est disponible. L’implémentation correcte dépend du traitement des informations données par DHCPv6 :

la forwarding logic doit être configurée pour identifier les datagrammes DHCP et en envoyer des copies au table management process ; si le switch observe un datagramme en provenance du serveur DHCP autorisant un lien entre un port, une adresse MAC et une adresse IPv6 source, le lien est stocké dans le port filter du port considéré

quand une adresse IPv6 source est utilisée par un client mais ne correspond à aucun lien, le table management process peut construire une DHCPv6 request semblant provenir du client pour l’acquisition d’une adresse ; si le serveur répond par l’affirmative, l’action précédente sera mise en œuvre

3.2.2 Implémentation utilisant SEND (SEcure Neighbor Discovery)

Dans un réseau utilisant SEND [RFC3971](10), un échange d’informations autorisé est disponible. L’implémentation correcte dépend du traitement des informations données par SEND :

la forwarding logic doit être configurée pour identifier les messages SEND et en envoyer des copies au table management process ; si le switch observe une SEND Response prouvant les

Figure 4 : les niveaux contrôle et données d'un switch

Page 14: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

14

certificats nécessaires pour autoriser un lien entre un port, une adresse MAC et une adresse IPv6 source, le lien est stocké dans le port filter du port considéré

quand une adresse IPv6 source est utilisée par un client mais ne correspond à aucun lien, le table management process peut construire une Secure Neighbor Solicitation pour cette adresse : le client répondra au datagramme et l’action précédente sera mise en œuvre

3.2.3 Implémentation utilisant ND (Neighbor Discovery)

Dans un réseau sans source d’information autorisée, l’implémentation correcte dépend de l’observation d’une implémentation correcte de Neighbor Discovery and Address Autoconfiguration [RFC4862](12). Quand une adresse IPv6 source est utilisée par un client mais ne correspond à aucun lien, le table management process devrait initier une multicast Neighbor Solicitation pour trouver le client utilisant cette adresse source ; trois cas peuvent survenir :

aucun Neighbor Advertisement n’est répondu : dans ce cas, l’adresse n’est pas une adresse IPv6 source et le lien ne doit pas être configuré

un ou plusieurs Neighbor Advertisement sont répondus, dont au moins un est en provenance d’un autre client : dans ce cas, l’adresse source est usurpée et le lien ne doit pas être configuré

un seul Neighbor Advertisement est répondu de la part du client considéré : dans ce cas, le switch stocke le lien indiqué par la réponse

Remarque : ce modèle n’est pas sécurisé mais il peut détecter des cas où une adresse ne possède aucun utilisateur actif ou de multiples utilisateurs

4 FIRST-COME FIRST-SERVE SOURCE ADDRESS VALIDATION FOR LOCALLY ASSIGNED ADDRESSES (FCFS-SAVI)

Cette partie décrit un mécanisme pour fournir la validation de l’adresse source dans un réseau Ipv6 en utilisant l’approche « premier arrivé premier servi ». Ce mécanisme est détaillé dans le document draft-ietf-savi-fcfs-05 du 25 octobre 2010(3).

4.1 CADRE D’UTILISATION

Le scénario d’application de FCFS-SAVI est limité au lien local et à un trafic local ; les adresses sont configurées avec Stateless Address Autoconfiguration et aucun changement chez les hôtes ne doit être requis. La validation FCFS-SAVI est exécutée par la fonction FCFS-SAVI qui peut être implémentée dans un routeur ou un switch de niveau 2 mais doit être placée à des endroits clés de la topologie afin de pouvoir détruire les paquets non-conformes quant à l’adresse source. La principale fonction effectuée par FCFS SAVI est de vérifier que l’adresse source utilisée dans les paquets de données appartient réellement à l’expéditeur du paquet. La preuve de la possession de l’adresse est basée sur l’approche « premier arrivé premier servi » (FCFS : first come first serve) : le premier hôte qui revendique une adresse source donnée devient le propriétaire de cette adresse puis un état est créé dans le dispositif implémentant la fonction FCFS SAVI qui lie l’adresse source à l’information de niveau 2 considéré (en l’occurrence, les ports des switches du réseau pour FCFS SAVI). L’approche FCFS SAVI repose sur quatre postulats :

SAVI fournit une sécurité périmétrique : certaines interfaces d’un dispositif SAVI sont connectées à la partie interne (fiable) de la topologie et les autres à la partie externe (non fiable)

un dispositif SAVI vérifie uniquement les paquets venant par une interface non fiable

un dispositif SAVI stocke uniquement les informations de lien pour les adresses source liées à des ancres de niveau 2 qui correspondent aux interfaces non fiables

Page 15: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

15

SAVI utilise les messages NS (Neighbor Solicitation) et NA (Neighbor Advertisement) pour préserver la cohérence des états des liens SAVI distribués parmi les dispositifs SAVI à l’intérieur d’un domaine

Dans la figure 5, le périmètre d’application SAVI est fournit par les switches SAVI 1, SAVI 2, SAVI 3 et SAVI 4 qui vérifient les informations relatives à l’adresse source dans les paquets de données et les paquets ND (Neighbor Discovery) et filtrent ces paquets en conséquence. Les dispositifs SAVI ont deux types de ports :

les Validating Ports (VP) dans lesquels le traitement et le filtrage SAVI sont effectués ; les ports 1 et 2 de SAVI 1, 1 de SAVI 2, 4 de SAVI 3, 4 de SAVI 4 sont de VP

les Trusted Ports (TP) dans lesquels le traitement SAVI n’est pas effectué : les ports 3 et 4 de SAVI 1, 2 et 3 de SAVI 2, 1, 2 et 3 de SAVI 3, 1 de SAVI 4 sont de TP

4.2 SPECIFICATIONS DE FCFS SAVI

4.2.1 Structures de données

La fonction FCFS SAVI repose sur l’information contenant l’état du lien entre l’adresse source des paquets de données et l’information de niveau 2 que contient le premier paquet utilisant cette adresse IP source : cette information est stockée dans la FCFS SAVI Data Base (DB). Chaque entrée de la DB contient donc :

l’addresse IP source

l’information de niveau 2 (adresse de niveau 2, port)

la durée de vie

le status : tentative (provisoire), valid (valide) ou testing (en test)

le moment de la création de l’entrée (CT)

FCFS SAVI doit également connaitre les préfixes directement connectés et tient donc à jour une FCFS SAVI prefix list contenant :

le prefix

Figure 5 : périmètre d'application SAVI (FCFS SAVI)

Page 16: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

16

l’interface sur lequel le préfixe est directement connecté

4.2.2 Algorithme

Point particulier : afin de différencier le trafic local du trafic de transit, le dispositif SAVI s’appuie sur la FCFS SAVI prefix list et doit supporter les deux méthodes d’attribution de préfixe que sont la configuration manuelle et la configuration par Router Advertisement [RFC4861](12)

4.2.2.1 Traitement du trafic de transit

Si le paquet de données est reçu par un Trusted Port, il est transmis et aucun traitement SAVI n’est effectué sur le paquet. Si le paquet de données est reçu par un Validating Port, la fonction SAVI doit vérifier si le paquet de données appartient au trafic local ou de transit en cherchant dans la FCFS SAVI Prefix List :

si l’adresse IP source n’appartient à aucun préfixe (trafic de transit), le paquet doit être détruit

si l’adresse source du paquet appartient à un des préfixes, le processus de validation SAVI pour le trafic local est exécuté conformément au paragraphe suivant

4.2.2.2 Traitement du trafic local

La description du traitement des paquets de données et de contrôle par le dispositif SAVI sera effectuée par une approche machine à états finis. Considérons une adresse IP donnée dans un dispositif SAVI donné. Notons :

IPAddr : l’adresse IP considérée (c’est l’attribut clé)

L2A : l’ancre de niveau 2 (layer 2 anchor)

LT : lifetime

Les différents états possibles (State) sont :

NO_BIND : l’entrée IPAdrr ne contient pas d’ancre P

TENTATIVE : un paquet de données ou un message DAD-NS concernant IPAddr vient d’être reçu, la procédure DAD s’exécute

VALID : le lien pour IPAddr a été vérifié, il est valide et utilisable pour filtrer le trafic

TESTING_TP-LT : soit un message DAD-NS a été reçu concernant IPAddr par un TP, soit le LT d’IPAddr est sur le point d’expirer

TESTING_VP : un message DAD-NS ou un paquet de données est reçu par un VP autre que P

La figure ci-dessous montre un schéma simplifié de la machine à états finis.

Page 17: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

17

Des explications plus détaillées sont fournies dans le tableau figurant en annexe 1.

4.2.2.3 Configuration des ports

La configuration des ports d’un dispositif SAVI doit respecter les items suivants :

les ports connectés à un autre dispositif SAVI doivent être configurés comme Trusted Ports (TP)

les ports connectés aux hôtes doivent être configurés comme Validating Ports (VP)

les ports connectés aux routeurs doivent être configurés comme Trusted Ports (TP)

les ports connectés à une série d’un ou plusieurs switches (non SAVI) ayant des hôtes connectés doivent être configurés comme Validating Ports (VP)

les ports connectés à une série d’un ou plusieurs switches (non SAVI) ayant des dispositifs SAVI ou des routeurs connectés mais pas d’hôtes doivent être configurés comme Trusted Ports (TP)

les ports connectés à une série d’un ou plusieurs switches (non SAVI) ayant des dispositifs SAVI ou des routeurs connectés avec des hôtes doivent être configurés comme Validating Ports (VP)

4.3 CONSIDERATIONS DE SECURITE

Avant tout, il est utile de rappeler qu’une solution SAVI ne peut pas être plus sûre que l’ancre de niveau inférieur qu’elle utilise. Ainsi, si l’ancre est falsifiable, la solution sera fragile. Attaques par déni de service :

Envoi de paquets avec des adresses source différentes pour que le dispositif SAVI crée des entrées pour chaque adresse et gaspille de la mémoire :

Recommandations : o lorsque le dispositif SAVI fonctionne en dehors de la mémoire affectée à la SAVI DB

(data base), il doit créer de nouvelles entrées en effaçant les plus récentes, si bien que le coût de l’attaque augmente fortement

Figure 6 : machine à états finis simplifiée

Page 18: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

18

o le dispositif SAVI doit réserver une quantité de mémoire minimale pour chaque port (4 liens par port) si bien qu’un hôte connecté à un port garde de la mémoire disponible même en cas d’attaque

Création de liens dans un dispositif SAVI par un attaquant dont le résultat est de bloquer les paquets de données envoyés par le propriétaire légitime de l’adresse source : peu probable en IPv6

5 SOLUTION SAVI POUR DHCP

Cette partie, issue du document draft-ietf-savi-dhcp-07(4) du 26 novembre 2010 traitera de la procédure pour la création de liens entre une adresse attribuée par DHCP et une binding anchor. Ce mécanisme est déployé sur un dispositif d’accès (switch, point d’accès…) et fonctionne principalement par l’espionnage de DHCP pour établir les liens entre les adresses IP source attribuées par DHCP et les binding anchors correspondantes. Cette solution est à considérer dans un scénario pour lequel seuls des serveurs DHCP peuvent attribuer des adresses globales valides.

5.1 STRUCTURES DE DONNEES CONCEPTUELLES

Deux structures de données redondantes sont utilisées pour enregistrer les liens et leurs états respectifs :

le Binding State Table (BST) concerne le niveau contrôle, il est composé des champs : o Anchor : la binding anchor, premier attribut clé d’une entrée o Address : l’addresse IP source, deuxième attribut clé d’une entrée o Lifetime : la durée de vie restante d’une entrée o State : l’état du lien

Figure 7 : scénario DHCP pour SAVI-DHCP

Page 19: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

19

o Other : information temporaires (identifiant de transaction d’une requête DHCP, durée de bail d’une adresse)

Anchor Address State Lifetime Other

A IP_1 Bound 65535

A IP_2 Bound 10000

B IP_3 Start 1

le Filtering Table (FT) concerne le niveau données, il est utilisé pour filtrer les paquets (Anchor et Address sont les attributs clés) :

Anchor Address

A IP_1

A IP_2

5.2 ATTRIBUTS DES BINDING ANCHORS

Une binding anchor peut avoir un ou plusieurs attributs configurables. Par défaut, elle n’en a pas et les messages DHCP venant d’une binding anchor sans attribut doivent être supprimés. Les attributs possibles sont :

SAVI-Validation Attribute : pour une binding anchor sur laquelle les adresses source doivent être validées ; le processus de filtrage est décrit au paragraphe 5.4.

SAVI-DHCP-Trust Attribute : pour une binding anchor située sur le chemin vers un serveur ou un relais DHCP de confiance ; les messages DHCP en provenant sont transmis

SAVI-SAVI Attribute : pour une binding anchor à partir de laquelle le trafic ne doit pas être vérifié ; tous les messages en provenant sont transmis sans vérification

SAVI-BindRecovery Attribute : pour une binding anchor requérant une reprise de lien (non décrit dans ce document)

Les attributs suivant s’excluent mutuellement :

SAVI-Validation // SAVI-SAVI

SAVI-SAVI // SAVI-BindRecovery

Les attributs SAVI-SAVI et SAVI-Validation implémentent le concept de périmètre de sécurité décrit en figure 1.

5.3 MISE EN PLACE DES LIENS

La procédure de mise en place des liens est basée sur l’espionnage des paquets de contrôle et n’est valable que pour les binding anchor possédant l’attribut SAVI-Validation.

5.3.1 Définitions des états et des évènements

Les liens peuvent être dans trois états différents :

NO_BIND : avant que le lien ne soit mis en place

INIT_BIND : une requête DHCP a été reçue de la part d’un hôte et doit déclencher un nouveau lien

BOUND : l’adresse est autorisée pour le client

Les évènements sont définis comme ci-dessous :

EVE_ENTRY_EXPIRE : la durée de vie d’une entrée a expiré

EVE_DHCP_REQUEST : une requête DHCP est reçue de la part d’une binding anchor avec l’attribut SAVI-Validation et des entrées sont disponibles

EVE_DHCP_CONFIRM : une confirmation DHCPv6 est reçue de la part d’une binding anchor avec l’attribut SAVI-Validation et des entrées sont disponibles

Page 20: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

20

EVE_DHCP_OPTION_RC : une sollicitation DHCPv6 avec option Rapid Commit est reçue de la part d’une binding anchor avec l’attribut SAVI-Validation et des entrées sont disponibles

EVE_DHCP_REPLY : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu de la part d’une binding anchor avec l’attribut SAVI-DHCP-Trust et doit être transmis à une binding anchor avec l’attribut SAVI-Validation

EVE_DHCP_REPLY_NULL : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu de la part d’une binding anchor avec l’attribut SAVI-DHCP-Trust

EVE_DHCP_DECLINE : un message de refus DHCP est reçu de la part d’une binding anchor avec l’attribut SAVI-Validation

EVE_DHCP_RELEASE : un message de libération DHCP est reçu de la part d’une binding anchor avec l’attribut SAVI-Validation

EVE_DHCP_REPLY_RENEW : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu et suggère une nouvelle durée de bail

EVE_LEASEQUERY_REPLY : une réponse affirmative DHCP LEASEQUERY est reçu d’une binding anchor avec l’attribut SAVI-DHCP-Trust

5.3.2 Processus d’espionnage des paquets de contrôle

Le processus détaillé d’espionnage des paquets de contrôle est décrit en Annexe 2.

5.3.3 Machine à états finis

Le processus est décrit plus simplement dans la figure ci-dessous avec les valeurs suivantes :

REQ : EVE_DHCP_REQUEST

CFM : EVE_DHCP_CONFIRM

RC : EVE_DHCP_OPTION_RC

RPL : EVE_DHCP_REPLY

DCL : EVE_DHCP_DECLINE

RLS : EVE_DHCP_RELEASE

RNW : EVE_DHCP_REPLY_RENEW

LQR: EVE_LEASEQUERY_REPLY

Timeout : EVE_ENTRY_EXPIRE

LQ_DLY : MAX_LEASEQUERY_DELAY

Page 21: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

21

5.4 FILTRAGE DES PAQUETS

Les paquets de données avec une binding anchor dont l’attribut est SAVI-Validation doivent être vérifiés : si l’adresse d’un paquet et sa binding anchor sont dans la FT, le paquet doit être transmis ; sinon il doit être détruit (éventuellement après avoir enregistré l’évènement). Concernant le filtrage des paquets de contrôle pour les binding anchor dont l’attribut est SAVI-Validation, les messages suivant doivent être détruits :

DHCPv4 Discovery dont l’adresse source n’est pas tout 0

DHCPv4 Request dont l’adresse source n’est ni tout 0 ni une adresse liée dans un FT

DHCPv6 Request dont l’adresse source n’est pas liée avec la binding anchor correspondante

DHCPv6 Confirm / Solicit dont l’adresse source n’est pas une LLA liée avec la binding anchor correspondante

autres messages DHCP dont l’adresse source n’est pas liée avec la binding anchor correspondante

IPv6 NS et gratuitous ARP dont l’adresse source n’est pas liée avec la binding anchor correspondante

NA et ARP Replies dont l’adresse cible et l’adresse source ne sont pas liée avec la binding anchor correspondante

Concernant le filtrage des paquets de contrôle pour les binding anchor dont l’attribut n’est pas SAVI-Validation, les messages DHCP Reply / Ack ne provenant pas d’une binding anchor dont l’attribut est SAVI-DHCP-Trust ou SAVI-SAVI doivent être détruits.

Figure 8 : machine à états finis pour l'espionnage DHCP

Page 22: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

22

6 SEND-BASED SOURCE-ADDRESS VALIDATION IMPLEMENTATION

Cette section décrit un mécanisme pour fournir la validation de l’adresse source en se basant sur le protocole SEcure Neighbor Discovery (SEND)(10). Cette description se réfère au document draft-ietf-savi-send-04(5) du 25 octobre 2010.

Pour valider le propriétaire d’une adresse, SEND SAVI utilise les messages DAD_NS (Duplicate Address Detection Neighbor Solicitation), DAD_NA (Duplicate Address Detection Neighbor Advertisement), NUD_NS (Neighbor Unreachability Detection Neighbor Solicitation) et NUD_NA (Neighbor Unreachability Detection Neighbor Advertisement).

Au même titre que FCFS SAVI (résistance au facteur d’échelle), les dispositifs SEND SAVI doivent être disposer de façon à former un périmètre de protection comme le montre la Figure 5 : périmètre d'application SAVI (FCFS SAVI). La configuration des ports sur les dispositifs SEND SAVI est également identique à celle préconisée sur les dispositifs FCFS SAVI.

6.1 STRUCTURES DE DONNEES

Les structures de données suivantes sont définies pour SEND SAVI :

Port List contient une entrée par port d’un dispositif SAVI ; cette entrée est formée des champs suivant :

o le port

o son rôle (TP : Trusted Port ou VP : Validating Port)

o un bit router port (uniquement pour les VP) si un routeur est connecté au port

Address List contient une entrée pour chaque adresse IP source utilisée sur un VP d’un dispositif SAVI ; cette entrée est formée des champs suivants :

o l’adresse IP source

o le VP auquel l’hôte est connecté

o la durée de vie

o le status : TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, TESTING_VP’

Prefix List contient une entrée par préfixe ; cette entrée est formée des champs suivants :

o le préfixe

o la durée de vie

Router List contient une entrée pour chaque routeur autorisé connecté sur un VP d’un dispositif SAVI ; cette entrée est formée des champs suivants :

o l’adresse IPv6 du routeur

o la durée de vie

Un dispositif SAVI doit de plus être configuré avec :

une adresse CGA valide

au moins un TP pour valider les Certification Paths qui autorisent les opérations de routage

des Certifications Paths (voir les spécifications SEND [RFC3971](10))

chaque port doit avoir un rôle défini dans Port List

6.2 TRAITEMENT DU TRAFIC

Le trafic est divisé en trois catégories en analysant l’adresse IP source des paquets :

le trafic de transit si le préfixe de l’adresse IP source n’est pas dans Prefix List

le trafic local destiné au dispositif SAVI lui-même

Page 23: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

23

le trafic local

6.2.1 Traitement du trafic de transit

Le trafic de transit est traité de manière différente en fonction du port par lequel il est reçu :

si le paquet est reçu par un TP, il est transmis et aucun traitement SAVI n’est exécuté

si le paquet est reçu par un VP, deux cas se présentent :

o si le port contient, dans Port List, le bit Router, le paquet est transmis

o sinon, le dispositif SAVI doit envoyer un message RS par le port

6.2.2 Traitement du trafic local à destination du dispositif SAVI

Le trafic local à destination exclusive du dispositif SAVI est traité de la manière suivante :

6.2.3 Traitement du trafic local

Le traitement du trafic local sera décrit par une machine à états finis. Les états suivants sont définis pour un port P lié à une adresse IP source IPAddr au sein d’un dispositif SAVI :

NO_BIND : aucun lien n’existe pour IPAddr

TENTATIVE_DAD : le dispositif SAVI a reçu un message DAD_NS validé et attend un éventuel DAD_NA ; les paquets avec l’adresse source correspondant au lien ne sont pas transmis

TENTATIVE_NUD : un paquet différent d’un message DAD_NS est reçu par un port VP et le dispositif SAVI a envoyé un message NUD_NS au port ; les paquets avec l’adresse source correspondant au lien ne sont pas transmis

VALID : le lien pour l’adresse source a été vérifié ; les paquets provenant de cette adresse sont transmis

TESTING_VP : la durée de vie du lien a expiré, le dispositif SAVI a envoyé un message NUD_NS vers le port ou un DAD_NS a été reçu par un autre dispositif SAVI ; le dispositif SAVI attend un NA validé et les paquets avec l’adresse source correspondant au lien sont autorisés à être transmis

TESTING_VP’ : un message DAD_NS validé a été reçu par un VP d’un dispositif SAVI ; le dispositif attend un DAD_NA venant de VP ou change le lien vers le port VP’ si aucune réponse n’est reçu après TENT_LT ms ; les paquets venant de VP avec l’adresse source correspondant au lien sont autorisés à être transmis

Une description simplifiée de cette machine à états finis est illustrée dans la figure ci-dessous.

Page 24: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

24

Une description plus détaillée figure en annexe 3.

Figure 9 : machine à états finis SEND SAVI

Page 25: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

25

B Mise en œuvre du projet industriel

1 PROBLEMATIQUE ET EVOLUTIONS DU SUJET

1.1 PROBLEMATIQUE

Le protocole SAVI est actuellement en cours de standardisation. Il n'y actuellement aucun matériel avec IOS disponible pour pouvoir implémenter cette solution. Après avoir contacté Jean-Michel COMBES du Centre de Physique Théorique et Eric LEVY-ABEGNOLI de CISCO des membres éminents du workgroup SAVI, il s'est avéré que l'implémentation la plus proche dont dispose la société CISCO ne tourne que sur un Catalyst6000, et uniquement avec un superviseur Sup2T, qui n'est pas un équipement très courant. De plus il s'agit d'une implémentation très édulcorée de SAVI. Le protocole PANA n'est disponible qu'en version « Beta » non soutenue. Cela semble assez délicat à implémenter dans le cadre de ce projet. Après contact avec Maryline Laurent de l'Institut Telecom Sud PARIS, les seuls logiciels disponibles afin d'implémenter PANA se trouvent dans le SP3 du projet VERICERT (pana-eap-tls)(13). En revanche, plus personne ne maintient le logiciel. Les protocoles SAVI et PANA ne pouvaient être mis en œuvre dans le cadre de ce projet. Il convient donc d'essayer d'atteindre le but initialement fixé qu'est l'association d'une adresse Ipv6 délivrée en mode Stateless avec un identifiant usager.

1.2 EVOLUTION INITIALE DU SUJET

Après avoir effectué un état de l'art du protocole SAVI et étant dans l'incapacité d'implémenter cette solution, nous allons essayer de réaliser une architecture nous permettant d'atteindre le but fixé par le projet. Les pistes à exploiter sont les suivantes :

La plate-forme présentée en figure 10 va permettre de créer une association sur un réseau filaire entre une adresse Ipv6, une adresse MAC, un numéro de port ainsi qu'un identifiant. Cela permettra donc l'association adresse Ipv6 et identifiant initialement souhaitée pour le projet.

Figure 10 : Binding anchor sur un réseau filaire

Page 26: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

26

La plate-forme présentée en figure 11 va permettre de créer une association sur un réseau wifi entre une adresse Ipv6, une adresse MAC, un numéro de port ainsi qu'un identifiant (wpa et/ou nom d'authentification). Cela permettra donc l'association adresse Ipv6 et identifiant initialement souhaitée pour le projet.

L’architecture globale présentée en figure 12 aurait permis d'atteindre le but initialement recherché que constitue l'association d'une adresse Ipv6 et d'un identifiant quelque soit la méthode d'accès. Le manque de moyens et de temps nous a conduits à réduire considérablement le champ d'action du projet.

Figure 11 : Binding anchor sur un réseau Wifi

Figure 12 : architecture globale du projet

Page 27: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

27

1.3 SECONDE EVOLUTION DU SUJET

Nous avons donc décidé de nous concentrer sur l'association en mode wifi entre une adresse Ipv6 et une identité. Pour ce faire, nous avons utilisé l'architecture suivante :

Le principe de fonctionnement de la plate-forme présentée en figure 13 s'articule en 3 phases :

la première consiste à réaliser l'authentification de l'utilisateur sur l'access point via le serveur freeradius intégré (récupération adresse MAC et identifiant) ;

la seconde phase est réalisée par l'access point qui après avoir authentifié l'utilisateur lui permet d'accéder au routeur en relayant les Router Sollicitation ainsi que les Router Advertisement qui lui donneront les indications nécessaires pour construire son adresse globale ;

la troisième phase consiste à capturer le DAD effectué par l'utilisateur après avoir construit son adresse globale (récupération adresse Ipv6 et adresse MAC de l'utilisateur).

2 MISE EN PRATIQUE

2.1 CHOIX LOGICIELS

Nous avons fait le choix d'installer sur un système d'exploitation Ubuntu (UNIX) disposant d'un accès Wifi, le package Hostapd 0.7.3 afin de réaliser manuellement un point d'accès Wifi sécurisé. Nous avons également installé sur cette même machine le package Freeradius 2.0.4 qui nous permettra d'installer un serveur Radius effectuant l'authentification des utilisateurs souhaitant accéder au réseaux via le point d'accès. 2 utilisateurs ont été créer en local sur le serveur Radius ; ces utilisateurs sont 'dfava' et 'hmartin'. L'utilisation de serveur LDAP ou MySQL n'était pas nécessaire dans le cadre du projet. Nous avons utilisé airodump du package aircrack afin de vérifier le bon fonctionnement de notre point d'accès ainsi que ses paramètres radio. Nous avons choisi de réaliser une authentification par clé WPA2 pour les clients via EAP. Nous avons utilisé le package WPA-Supplicant sur la machine cliente afin de réaliser l'authentification de l'usager sur notre point d'accès. Afin de mettre en place le mode Stateless d'IPv6 nous allons raccorder notre point d'accès à un routeur CISCO 1605. Nous allons également mettre en place WIRESHARK sur notre serveur afin de capturer sur l'interface radio les DAD effectués par les clients après la création de leur adresse Ipv6 globale ce qui nous permettra d'associer cette fois l'adresse Ipv6 globale de l'utilisateur à son adresse MAC (on pourrait également associé à cela l'adresse lien local de l'usager).

Figure 13 : architecture du projet après évolutions

Page 28: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

28

2.2 ILLUSTRATION ASSOCIATION MAC/IDENTIFIANT

Figure 14 : vue airodump du point d'accès

Figure 15 : authentification par hostapd

Page 29: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

29

La fenêtre présentée en figure 14 illustre l'émission du point d'accès créé pour le projet via airodump. On peut y retrouver la puissance, les canaux utilisés ainsi que les méthodes d'authentification. La vue présentée en figure 15 représente le traitement de la demande d'authentification en WPA de l'utilisateur auprès du point d'accès. On peut vérifier que l'authentification s'effectue via le protocole 802.1X sur le serveur RADIUS. On retrouve également l'adresse MAC, l'identité de l'utilisateur ainsi que les méthodes d'authentification utilisées. La vue présentée en figure 16 représente le traitement de la demande d'authentification relayée par le point d'accès au serveur RADIUS. On y retrouve l'identifiant et l'adresse MAC de l'utilisateur, ainsi que des informations sur la connexion et les challenges effectués.

La vue présentée en figure 17 illustre le dénouement final de l'authentification de l'utilisateur. On peut y voir différentes informations sur le point d'accès ainsi que le type d'authentification réalisée.

Figure 16 : traitement de l'authentification par le serveur radius

Page 30: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

30

Figure 17 : résultat de l'authentification sur le poste de l'utilisateur

Figure 18 : association sur le serveur radius

Page 31: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

31

Nous pouvons utiliser l'association adresse MAC / Identifiant relevée sur le serveur radius (figure 18). Cette association peut également être enrichie des différents paramètres relevés sur les différentes captures précédentes via le serveur Radius et le point d'accès (numéro de session, message authenticator...). Le couple « adresse MAC/ Identifiant » étant réalisée, il nous faut maintenant leur associer une adresse Ipv6 que l'utilisateur obtiendra en mode Stateless.

2.3 ILLUSTRATION ASSOCIATION MAC/IPV6

Pour mettre en place le réseau avec un adressage Ipv6 en mode stateless nous avons configuré (figure 19) un routeur CISCO 1605 nous permettant d'attribuer au client les préfixes Ipv6. Le préfixe Ipv6 alloué aux clients est 2001:660:7301:BEBE::/64, ils construisent leur adresse globale automatiquement à partir de ce préfixe.

Une fois l'authentification via l'access point réalisée, celui-ci laissera passer les échanges de niveaux 3 (Router Sollicitation, Neighbor Sollicitation, Router Advertisement) entre l'abonné et le routeur. Pour se faire nous avons réalisé un pont entre l'interface filaire (reliée au routeur) et l'interface radio (utilisée pour l'access point). L'interface Br0 est ainsi créée, elle se construit une adresse IPV6 globale configurée dynamiquement (figure 20).

Figure 19 : configuration routeur CISCO

Page 32: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

32

L'abonné va donc réaliser après s'être authentifié et avoir récupéré le préfixe un Neighbor Sollicitation afin d'exécuter son DAD. Cette requête a été capturée avec Wireshark (on pourrait également utiliser Tcpdump). La fenêtre présentée en figure 21 montre que le DAD est effectué avec l'adresse multicast sollicitée FF02::1:FF06:81a9 mais l'adresse Ipv6 globale de l'abonné se trouve distinctement dans le champ « target ». On y trouve également l'adresse MAC de l'abonné (00-24-23-06-81-9A) ainsi que l'adresse MAC sollicitée 33-33-FF-06-81-9A. Le changement d'adresse Ipv6 dans le temps n'échappera pas au DAD effectué par le client ce qui permettra de mettra à jour les différentes tables afin de mettre en corrélation les nouveaux éléments.

Figure 20 : configuration du pont

Page 33: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

33

Les différentes associations permettent d'obtenir le triplet @Ipv6/@MAC/Identifiant. Même si un utilisateur se connecte depuis plusieurs équipement ou dispose de plusieurs adresses, il est possible d'enrichir ces associations (un même identifiant peut avoir plusieurs adresses Ipv6 et plusieurs adresses MAC).

2.4 MAUVAISE AUTHENTIFICATION

Il convient de vérifier le comportement de l'access point lors d'une mauvaise authentification. On peut vérifier sur le serveur radius que cette mauvaise authentification est réalisé avec le nom d'utilisateur entré et l'adresse MAC correspondante. Les figures 22 et 23 montrent qu'aucun RA n'est acheminé vers le client tant que celui-ci n'est pas authentifié. Le client ne peut obtenir de préfixe afin de configurer son adresse Ipv6 globale et donc accéder au réseau.

Figure 21 : vue Wireshark du message DAD

Page 34: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

34

Figure 22 : échec de l'authentification sur le serveur radius

Figure 23 : échec de l'authentification sur le poste de l'utilisateur

Page 35: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

35

2.5 USURPATION D’ADRESSE MAC

Dans un premier temps, l’attaquant se connecte de manière légitime. Il possède donc :

un login et un mot de passe

une adresse MAC

une adresse IPv6 attribuée par le routeur

L’attaquant procède ensuite de deux façons différentes pour usurper une adresse MAC. La figure 24 présente les résultats d’une tentative de connexion avec une adresse MAC usurpée : l’attaquant a changé son adresse MAC alors que l’interface est down. A la connexion, l’usurpation est détectée.

La figure 25 présente les résultats de l’usurpation d’adresse MAC alors que l’interface est up : l’attaquant conserve alors ses adresses IPv6 précédentes mais n’a plus d’accès au réseau.

Figure 24 : détection du doublon adresse MAC

Page 36: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

36

2.6 AJOUT D’ADRESSE IPV6

Un client connecté de façon légitime tente d’usurper une adresse IPv6 en la rajoutant sur son interface de connexion. Le DAD capturé par Wireshark en figure 26 montre que cette nouvelle adresse IP se retrouve associée à l’adresse MAC du client.

Figure 26 : ajout d'une nouvelle adresse IPv6

Figure 25 : déconnexion après usurpation d'adresse MAC

Page 37: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

37

3 BILAN

3.1 DIFFICULTES RENCONTRES

3.1.1 Difficultés d’ordre matériel

Comme il a été expliqué dans ce rapport, aucun matériel contenant une implémentation SAVI n’est disponible actuellement. C’est pourquoi nous avons dû effectuer un certain « bricolage » (utilisation des résultats du DAD) afin de lier artificiellement l’adresse IPv6, l’adresse MAC et l’identité de l’utilisateur.

3.1.2 Difficultés d’ordre logiciel

La première difficulté à laquelle nous avons été confrontés a été un « fatal error kernel » sur la machine où nos serveurs étaient installés. Un temps précieux a été perdu lors du remontage de la machine, des drivers puis des serveurs.

La deuxième difficulté a été due à une certaine « instabilité » des logiciels et drivers libres utilisés : certains points de configuration sont peu ou pas abordés dans la documentation accessible (exemple de freeradius en IPv6).

3.1.3 Difficultés d’ordre personnel

Une méconnaissance relative de certaines commandes Unix et du fonctionnement des logiciels utilisés (essentiellement hostapd et freeradius) a été préjudiciable à un éventuel approfondissement complémentaire du sujet.

3.2 ENSEIGNEMENTS

La conduite de ce projet industriel a néanmoins été grandement profitable et nous a apporté de nombreux enseignements, notamment en ce qui concerne l’utilisation des commandes Unix et les différentes interactions souvent complexes entre client et serveur.

Cependant, il subsiste une légère frustration : les objectifs initiaux ambitieux de ce projet, que nous avons jugé particulièrement intéressant, n’ont pas pu être menés à bien dans le temps imparti. L’implémentation réelle d’une méthode SAVI aurait pu contribuer à une réalisation plus complète.

Page 38: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

38

Annexes

ANNEXE 1 - FCFS SAVI

Cette annexe décrit le mécanisme FCFS-SAVI sous la forme d’une machine à états finis. La présentation, sous forme de tableau, se veut à la fois claire et détaillée.

Page 39: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

39

Etat initial Déclencheur Action à réaliser Etat final Commentaires

NO_BIND LT=0 L2A=NULL

Réception d’un message DAD-NS par un VP pour IPAddr Envoi de messages DAD-NS pour IPAddr par les TP avec paramètres (DupAddrDetectTransmits=2, RetransTimer=250ms)

TENTATIVE LT=TENT_LT L2A=VP

Réception d’un paquet de données par un VP de IPAddr

Envoi de messages DAD-NS pour IPAddr par les TP avec paramètres (DupAddrDetectTransmits=2, RetransTimer=250ms) Destruction du paquet

TENTATIVE LT=TENT_LT L2A=VP

Réception d’un paquet de données par un TP de IPAddr Transmission du paquet inchangé Pas de traitement SAVI

Réception d’un message DAD-NS par un TP pour IPAddr Transmission du message vers les autres TP, pas vers les VP

inchangé

Réception d’un DAD-NA par un VP pour IPAddr Destruction du message inchangé

Réception de tout autre paquet de signalisation Transmission du paquet inchangé Pas de traitement SAVI

TENTATIVE 0<LT≤TENT_LT L2A=P

LT expire Transmission des paquets de données éventuellement stockés

VALID LT=DEFAULT_LT

Réception d’un message DAD-NA par un TP pour IPAddr Transmission du message vers le port P Destruction des paquets de données éventuellement stockés correspondant à ce lien

NO_BIND LT=NULL L2A=NULL

Réception d’un message DAD-NA par un VP pour IPAddr Destruction du message inchangé

Réception d’un paquet de données par P de IPAddr Stockage ou destruction du paquet de données inchangé

Réception d’un paquet de données par un TP de IPAddr Transmission du paquet de données inchangé

Réception d’un paquet de données par un VP≠P de IPAddr

Destruction du paquet inchangé

Réception d’un message DAD-NS par un TP pour IPAddr Transmission du message vers le port P Destruction des paquets de données éventuellement stockés correspondant à ce lien

NO_BIND LT=NULL L2A=NULL

Réception d’un message DAD-NS par un VP P’≠P pour IPAddr

Transmission du message vers le port P et les TP Destruction des paquets de données éventuellement stockés correspondant au lien avec P

LT=TENT_LT L2A=P’

Réception de tout autre paquet de signalisation Transmission du paquet inchangé Pas de traitement SAVI

VALID 0<LT≤DEFAULT_LT L2A=P

Réception d’un paquet de données par P de IPAddr Transmission du paquet LT=DEFAULT_LT

Réception d’un message DAD_NS par un TP Transmission du message vers P et les autres TP TESTING_TP-LT LT=TENT_LT

Réception d’un paquet de données de IPAddr ou d’un Envoi de messages DAD-NS pour IPAddr par P avec TESTING_VP

Page 40: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

40

message DAD-NS / DAD-NA pour IPAddr par un VP P’≠P paramètres (DupAddrDetectTransmits=2, RetransTimer=250ms) Transmission du DAD-NS vers P Destruction du paquet de données

LT=TENT_LT

LT expire Envoi de messages DAD-NS pour IPAddr par P avec paramètres (DupAddrDetectTransmits=2, RetransTimer=250ms)

TESTING_TP-LT LT=TENT_LT

Réception d’un paquet de données de IPAddr par un TP Destruction du paquet Enregistrement de l’évènement

inchangé

Réception de tout autre paquet de signalisation Transmission du paquet, en particulier les messages DAD-NA venant de P pour IPAddr

inchangé Pas de traitement SAVI

TESTING_TP-LT 0<LT≤TENT_LT L2A=P

LT expire NO_BIND L2A=NULL

Réception d’un message DAD-NA par P pour IPAddr Transmission du message VALID LT=DEFAULT_LT

Réception d’un paquet de données de IPAddr par P Transmission du paquet VALID LT=DEFAULT_LT

Réception d’un message DAD-NS par un TP Transmission du message

Réception d’un message DAD-NS par un VP P’≠P Transmission du message TESTING_VP

Réception d’un paquet de données par un VP P’≠P Destruction du paquet

Réception d’un paquet de données par un TP Destruction du paquet Enregistrement de l’évènement

TESTING_VP 0<LT≤TENT_LT L2A=P

LT expire Transmission des paquets de données éventuellement stockés venant de P’

VALID LT=DEFAULT_LT L2A=P’

Réception d’un message DAD-NA par P pour IPAddr Transmission du message VALID LT=DEFAULT_LT

Réception d’un paquet de données de IPAddr par P Transmission du paquet

Réception d’un paquet de données par un VP P’’≠P ou P’ Destruction du paquet

Réception d’un paquet de données par un TP≠P Destruction du paquet TESTING_TP-LT

Réception d’un message DAD-NS par un TP Transmission du paquet TESTING_TP-LT

Réception d’un message DAD-NS par un VP P’’≠P ou P’ Transmission du message L2A=P’’

Page 41: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

41

ANNEXE 2 - SAVI-DHCP

Cette annexe décrit le mécanisme SAVI-DHCP sous la forme d’une machine à états finis. La présentation, sous forme de tableau, se veut à la fois claire et détaillée.

Rappel des évènements définis :

EVE_ENTRY_EXPIRE : la durée de vie d’une entrée a expiré

EVE_DHCP_REQUEST : une requête DHCP est reçue de la part d’une binding anchor avec l’attribut SAVI-Validation et des entrées sont disponibles

EVE_DHCP_CONFIRM : une confirmation DHCPv6 est reçue de la part d’une binding anchor avec l’attribut SAVI-Validation et des entrées sont disponibles

EVE_DHCP_OPTION_RC : une sollicitation DHCPv6 avec option Rapid Commit est reçue de la part d’une binding anchor avec l’attribut SAVI-Validation et des entrées sont disponibles

EVE_DHCP_REPLY : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu de la part d’une binding anchor avec l’attribut SAVI-DHCP-Trust et doit être transmis à une binding anchor avec l’attribut SAVI-Validation

EVE_DHCP_REPLY_NULL : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu de la part d’une binding anchor avec l’attribut SAVI-DHCP-Trust

EVE_DHCP_DECLINE : un message de refus DHCP est reçu de la part d’une binding anchor avec l’attribut SAVI-Validation

EVE_DHCP_RELEASE : un message de libération DHCP est reçu de la part d’une binding anchor avec l’attribut SAVI-Validation

EVE_DHCP_REPLY_RENEW : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu et suggère une nouvelle durée de bail

EVE_LEASEQUERY_REPLY : une réponse affirmative DHCP LEASEQUERY est reçu d’une binding anchor avec l’attribut SAVI-DHCP-Trust

Page 42: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

42

Etat initial Déclencheur Action à réaliser

Etat final

BST FT BST FT

NO ENTRY (State = NO_BIND)

NO ENTRY

EVE_DHCP_REQUEST EVE_DHCP_OPTION_RC

Transmission des messages

Anchor = A Address = NULL State = INIT_BIND Lifetime = MAX_DHCP_RESPONSE_TIME Other = TID

NO ENTRY

EVE_DHCP_CONFIRM Transmission des messages

Anchor = A Address = Addr State = INIT_BIND Lifetime = MAX_DHCP_RESPONSE_TIME Other = TID

NO ENTRY

EVE_DHCP_REPLY_NULL Délivrance du message à la destination

Anchor = A Address = Addr1, Addr2 State = BOUND Lifetime = Lease time1, Lease time2 Other = NULL

Anchor = A Address = Addr1, Addr2

Anchor = A Address = NULL / Addr State = INIT_BIND Lifetime = MAX_DHCP_RESPONSE_TIME Other = TID

NO ENTRY

EVE_DHCP_REPLY

Délivrance du message à la destination Cas particulier : Address = Adrr [Voir plus loin]

Anchor = A Address = Addr State = BOUND Lifetime = Lease time Other = NULL

Anchor = A Address = Addr

EVE_ENTRY_EXPIRE NO ENTRY NO ENTRY

EVE_LEASEQUERY_REPLY Lifetime = New Lease time

Anchor = A Address = Addr State = BOUND Lifetime = Lease time Other = NULL

Anchor = A Address = Addr

EVE_ENTRY_EXPIRE NO ENTRY NO ENTRY

EVE_DHCP_RELEASE EVE_DHCP_DECLINE

Le message Release ou Decline doit être transmis

NO ENTRY NO ENTRY

EVE_DHCP_REPLY_RENEW

Anchor = A Address = Addr State = BOUND Lifetime = New Lease time Other = NULL

Anchor = A Address = Addr

Page 43: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

43

ANNEXE 3 - SEND-SAVI

Cette annexe décrit le mécanisme SAVI-DHCP sous la forme d’une machine à états finis. La présentation, sous forme de tableau, se veut à la fois claire et détaillée.

Page 44: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

44

Stade initial / Pré requis

Evénement Stade final Actions / Commentaires

NO_BIND

Aucun DAD_NS ou NUD_NS non résolu

Réception d’un DAD_NS validé d’un VP Waiting_timer=TENT_LT

TENTATIVE_DAD pour VP

Transmission des messages aux TPs

Stockage des informations pour valider le futur DAD_NA

Réception d’un message ≠ DAD_NS d’un VP Waiting_timer=TENT_LT

TENTATIVE_NUD pour VP Emission d’un NUD_NS vers VP

Réception d’un DAD_NS validé concernant IPAddr d’un TP

Inchangé Transmission des messages aux TPs

Réception d’un message ≠ DAD_NS d’un TP Inchangé Transmission du message

TENTATIVE_DAD

Le dispositif SAVI a reçu DAD_NS de VP et l’a transmis aux TPs

Réception d’un DAD_NA validé d’un TP Waiting_timer=NULL

NO_BIND

Réception d’un DAD_NS validé d’un TP Waiting_timer=NULL

NO_BIND Transmission du NS à VP et aux TPs

Réception d’un message ≠ (DAD_NS or DAD_NA) validé d’un TP

Inchangé Transmission du message

Réception d’un DAD_NS validé de VP’≠VP Waiting_timer=TENT_LT

TENTATIVE_DAD pour VP’ Transmission du NS à VP et aux TPs

Réception d’un message ≠ DAD_NS validé de VP’≠VP Inchangé

Réception d’un DAD_NS validé de VP Waiting_timer=TENT_LT

TENTATIVE_DAD pour VP

Réception d’un message ≠ DAD_NS validé de VP Waiting_timer=DEFAULT_LT

VALID

Waiting_time expire Waiting_timer=DEFAULT_LT

VALID

VALID

Réception de DAD_NS validé de IPAddr par VP

Waiting_timer=TENT_LT

TENTATIVE_DAD Transmission du NS aux TPs

Page 45: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

45

VP

IPAddr Réception d’un message ≠ DAD_NS validé de IPAddr par VP

Inchangé Transmission du message

Réception de DAD_NS validé de IPAddr par un TP Waiting_timer=TENT_LT

TESTING_VP

Transmission du message vers VP

Envoi d’un NUD_NS sécurisé à IPAddr vers VP

Réception d’un message ≠ DAD_NS de IPAddr par un TP

Waiting_timer=TENT_LT

TESTING_VP

Transmission du NS à VP et aux TPs

Envoi d’un NUD_NS sécurisé vers VP

Réception de DAD_NS validé de IPAddr par VP’≠VP Waiting_timer=TENT_LT

TESTING_VP’

Transmission du NS à VP

Envoi d’un NUD_NS sécurisé vers VP

Réception d’un message ≠ DAD_NS de IPAddr par VP’≠VP

Waiting_timer=TENT_LT

TESTING_VP’ Destruction du message

Envoi d’un NUD_NS sécurisé vers VP Après au plus DEFAULT_LT ms et si pas de réponse au NUD_NS, NO_BIND

Waiting_time expire Waiting_timer=TENT_LT

TESTING_VP Envoi d’un NUD_NS sécurisé à IPAddr vers VP

TESTING_VP

Le dispositif SAVI a envoyé un NUD_NS vers VP

Les paquets de VP ou TPs sont transmis

Réception de NUD_NA validé de VP Waiting_timer=DEFAULT_LT

VALID Destruction du message

Réception de DAD_NS validé de VP Waiting_timer=TENT_LT

TENTATIVE_DAD Transmission du NS aux TPs

Réception d’un message ≠ (DAD_NS ou NUD_NA) de IPAddr par VP

Inchangé Transmission du message

Réception de DAD_NS validé d’un TP Inchangé Transmission du NS à VP et aux TPs

Réception d’un message ≠ DAD_NS d’un TP Inchangé Transmission du message

Réception de DAD_NS validé de VP’≠VP Waiting_timer=TENT_LT

TESTING_VP’

Transmission du NS à VP et aux TPs

Envoi d’un NUD_NS sécurisé vers VP

Réception d’un message ≠ DAD_NS de VP’≠VP NO_BIND Destruction du message

Waiting_time expire Waiting_timer=NULL

NO_BIND

TESTING_VP’ Réception de NUD_NA validé de VP Waiting_timer=DEFAULT_LT

Page 46: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

46

Un hôte sur VP’ a envoyé des données de IPAddr lié à VP

Le dispositif SAVI a envoyé un NUD_NS vers VP

VALID pour VP

Réception de DAD_NS validé de VP Waiting_timer=TENT_LT

TENTATIVE_DAD Transmission du NS à VP’

Réception d’un message ≠ (DAD_NS ou NUD_NA) de VP

Inchangé Transmission du message

Réception de DAD_NS validé de VP’ Waiting_timer=TENT_LT

TESTING_VP’ Transmission du NS à VP

Réception d’un message ≠ DAD_NS de VP’ Inchangé Destruction du message

Réception de DAD_NS validé de VP’’≠(VP et VP’) Inchangé Transmission du NS à VP et VP’

Réception d’un message ≠ DAD_NS de VP’’≠(VP et VP’)

Destruction du message

Réception de DAD_NS validé d’un TP TESTING_VP Transmission du NS à VP, VP’ et TPs

Réception d’un message ≠ DAD_NS d’un TP Inchangé Transmission du message

Waiting_time expire Waiting_timer=DEFAULT_LT

VALID pour VP’

TENTATIVE_NUD

Un paquet de données a été reçu par VP sans lien dans le dispositif SAVI.

Le dispositif SAVI a envoyé un NUD_NS à VP.

Réception de NUD_NA validé de VP Waiting_timer=DEFAULT_LT

VALID pour VP Destruction du message

Réception de DAD_NS validé de VP Waiting_timer=TENT_LT

TENTATIVE_DAD Transmission du NS aux TPs

Réception d’un message ≠ (NUD_NA et DAD_NS) de VP

Destruction du message

Réception de DAD_NS de VP’≠VP Waiting_timer=TENT_LT

TENTATIVE_DAD pour VP’ Transmission du NS aux TPs

Réception d’un message ≠ DAD_NS de VP≠VP Inchangé Destruction du message

Réception de DAD_NS d’un TP Inchangé Transmission du NS à VP

Réception d’un message ≠ DAD_NS d’un TP Inchangé Transmission du message

Waiting_time expire Waiting_timer=NULL

NO_BIND

Page 47: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

47

ANNEXE 4 - LISTES DIVERSES

4.1. LISTE DES ILLUSTRATIONS

Figure 1 : concept de périmètre de protection ................................................................................................................. 8 Figure 2 : endroits où une adresse peut être validée ..................................................................................................... 10 Figure 3 : niveau données d'un switch Ethernet............................................................................................................. 12 Figure 4 : les niveaux contrôle et données d'un switch .................................................................................................. 13 Figure 5 : périmètre d'application SAVI (FCFS SAVI) ....................................................................................................... 15 Figure 6 : machine à états finis simplifiée ....................................................................................................................... 17 Figure 7 : scénario DHCP pour SAVI-DHCP ...................................................................................................................... 18 Figure 8 : machine à états finis pour l'espionnage DHCP ............................................................................................... 21 Figure 9 : machine à états finis SEND SAVI ..................................................................................................................... 24 Figure 10 : Binding anchor sur un réseau filaire ............................................................................................................. 25 Figure 11 : Binding anchor sur un réseau Wifi ................................................................................................................ 26 Figure 12 : architecture globale du projet ...................................................................................................................... 26 Figure 13 : architecture du projet après évolutions ....................................................................................................... 27 Figure 14 : vue airodump du point d'accès ..................................................................................................................... 28 Figure 15 : authentification par hostapd ........................................................................................................................ 28 Figure 16 : traitement de l'authentification par le serveur radius ................................................................................. 29 Figure 17 : résultat de l'authentification sur le poste de l'utilisateur ............................................................................. 30 Figure 18 : association sur le serveur radius ................................................................................................................... 30 Figure 19 : configuration routeur CISCO ......................................................................................................................... 31 Figure 20 : configuration du pont ................................................................................................................................... 32 Figure 21 : vue Wireshark du message DAD ................................................................................................................... 33 Figure 22 : échec de l'authentification sur le serveur radius .......................................................................................... 34 Figure 23 : échec de l'authentification sur le poste de l'utilisateur ................................................................................ 34 Figure 24 : détection du doublon adresse MAC ............................................................................................................. 35 Figure 26 : ajout d'une nouvelle adresse IPv6 ................................................................................................................ 36 Figure 25 : déconnexion après usurpation d'adresse MAC ............................................................................................ 36

4.2. LISTE DES REFERENCES

1. Source Address Validation Improvement Framework. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/draft-ietf-savi-framework/. 2. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc2827/. 3. FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/draft-ietf-savi-fcfs/. 4. SAVI Solution for DHCP. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/. 5. SEND-based Source-Address Validation Implementation. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/draft-ietf-savi-send/. 6. SAVI Threat Scope. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/. 7. Internet Protocol. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc791/. 8. Internet Protocol, Version 6 (IPv6) Specification. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc2460/. 9. IEEE Get Grogram. IEEE Standards Association. [En ligne] http://standards.ieee.org/getieee802/download/802.1X-2010.pdf. 10. SEcure Neighbor Discovery (SEND). datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc3971/. 11. Neighbor Discovery for IP version 6 (IPv6). datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc4861/. 12. IPv6 Stateless Address Autoconfiguration. datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc4862/. 13. Le projet incitatif VériCert (jan 2004-déc 2004). [En ligne] http://www-lor.int-evry.fr/~maknavic/VERICERT/.

Page 48: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

48

14. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). datatracker.ietf.org. [En ligne] http://datatracker.ietf.org/doc/rfc3315/.

Page 49: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

49

ANNEXE 5 - FICHIERS DE CONFIGURATION

5.1. HOSTAPD

5.1.1. FICHIER HOSTAPD.CONF

##### hostapd configuration file ############################################## # Empty lines and lines starting with # are ignored # AP netdevice name (without 'ap' postfix, i.e., wlan0 uses wlan0ap for # management frames); ath0 for madwifi interface=wlan7 # In case of madwifi, atheros, and nl80211 driver interfaces, an additional # configuration parameter, bridge, may be used to notify hostapd if the # interface is included in a bridge. This parameter is not used with Host AP # driver. If the bridge parameter is not set, the drivers will automatically # figure out the bridge interface (assuming sysfs is enabled and mounted to # /sys) and this parameter may not be needed. # # For nl80211, this parameter can be used to request the AP interface to be # added to the bridge automatically (brctl may refuse to do this before hostapd # has been started to change the interface mode). If needed, the bridge # interface is also created. #bridge=br0 # Driver interface type (hostap/wired/madwifi/test/none/nl80211/bsd); # default: hostap). nl80211 is used with all Linux mac80211 drivers. # Use driver=none if building hostapd as a standalone RADIUS server that does # not control any wireless/wired driver. driver=nl80211 # hostapd event logger configuration # # Two output method: syslog and stdout (only usable if not forking to # background). # # Module bitfield (ORed bitfield of modules that will be logged; -1 = all # modules): # bit 0 (1) = IEEE 802.11 # bit 1 (2) = IEEE 802.1X # bit 2 (4) = RADIUS # bit 3 (8) = WPA # bit 4 (16) = driver interface # bit 5 (32) = IAPP # bit 6 (64) = MLME # # Levels (minimum value for logged events): # 0 = verbose debugging # 1 = debugging # 2 = informational messages # 3 = notification # 4 = warning # logger_stdout=-1 logger_stdout_level=0 # Dump file for state information (on SIGUSR1) dump_file=/tmp/hostapd.dump # Interface for separate control program. If this is specified, hostapd # will create this directory and a UNIX domain socket for listening to requests # from external programs (CLI/GUI, etc.) for status information and # configuration. The socket file will be named based on the interface name, so # multiple hostapd processes/interfaces can be run at the same time if more # than one interface is used. # /var/run/hostapd is the recommended directory for sockets and by default, # hostapd_cli will use it when trying to connect with hostapd. ctrl_interface=/var/run/hostapd # Access control for the control interface can be configured by setting the # directory to allow only members of a group to use sockets. This way, it is # possible to run hostapd as root (since it needs to change network # configuration and open raw sockets) and still allow GUI/CLI components to be # run as non-root users. However, since the control interface can be used to # change the network configuration, this access needs to be protected in many # cases. By default, hostapd is configured to use gid 0 (root). If you # want to allow non-root users to use the contron interface, add a new group

# and change this value to match with that group. Add users that should have # control interface access to this group. # # This variable can be a group name or gid. #ctrl_interface_group=wheel ctrl_interface_group=0 ##### IEEE 802.11 related configuration ####################################### # SSID to be used in IEEE 802.11 management frames ssid=projetSAVIPANA # Country code (ISO/IEC 3166-1). Used to set regulatory domain. # Set as needed to indicate country in which device is operating. # This can limit available channels and transmit power. #country_code=US # Enable IEEE 802.11d. This advertises the country_code and the set of allowed # channels and transmit power levels based on the regulatory limits. The # country_code setting must be configured with the correct country for # IEEE 802.11d functions. # (default: 0 = disabled) #ieee80211d=1 # Operation mode (a = IEEE 802.11a, b = IEEE 802.11b, g = IEEE 802.11g, # Default: IEEE 802.11b hw_mode=g # Channel number (IEEE 802.11) # (default: 0, i.e., not set) # Please note that some drivers (e.g., madwifi) do not use this value from # hostapd and the channel will need to be configuration separately with # iwconfig. channel=1 # Beacon interval in kus (1.024 ms) (default: 100; range 15..65535) beacon_int=100 # DTIM (delivery trafic information message) period (range 1..255): # number of beacons between DTIMs (1 = every beacon includes DTIM element) # (default: 2) dtim_period=2 # Maximum number of stations allowed in station table. New stations will be # rejected after the station table is full. IEEE 802.11 has a limit of 2007 # different association IDs, so this number should not be larger than that. # (default: 2007) max_num_sta=255 # RTS/CTS threshold; 2347 = disabled (default); range 0..2347 # If this field is not included in hostapd.conf, hostapd will not control # RTS threshold and 'iwconfig wlan# rts <val>' can be used to set it. rts_threshold=2347 # Fragmentation threshold; 2346 = disabled (default); range 256..2346 # If this field is not included in hostapd.conf, hostapd will not control # fragmentation threshold and 'iwconfig wlan# frag <val>' can be used to set # it. fragm_threshold=2346 # Rate configuration # Default is to enable all rates supported by the hardware. This configuration # item allows this list be filtered so that only the listed rates will be left # in the list. If the list is empty, all rates are used. This list can have # entries that are not in the list of rates the hardware supports (such entries # are ignored). The entries in this list are in 100 kbps, i.e., 11 Mbps = 110. # If this item is present, at least one rate have to be matching with the rates # hardware supports. # default: use the most common supported rate setting for the selected # hw_mode (i.e., this line can be removed from configuration file in most # cases)

Page 50: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

50

#supported_rates=10 20 55 110 60 90 120 180 240 360 480 540 # Basic rate set configuration # List of rates (in 100 kbps) that are included in the basic rate set. # If this item is not included, usually reasonable default set is used. #basic_rates=10 20 #basic_rates=10 20 55 110 #basic_rates=60 120 240 # Short Preamble # This parameter can be used to enable optional use of short preamble for # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network performance. # This applies only to IEEE 802.11b-compatible networks and this should only be # enabled if the local hardware supports use of short preamble. If any of the # associated STAs do not support short preamble, use of short preamble will be # disabled (and enabled when such STAs disassociate) dynamically. # 0 = do not allow use of short preamble (default) # 1 = allow use of short preamble #preamble=1 # Station MAC address -based authentication # Please note that this kind of access control requires a driver that uses # hostapd to take care of management frame processing and as such, this can be # used with driver=hostap or driver=nl80211, but not with driver=madwifi. # 0 = accept unless in deny list # 1 = deny unless in accept list # 2 = use external RADIUS server (accept/deny lists are searched first) macaddr_acl=0 # Accept/deny lists are read from separate files (containing list of # MAC addresses, one per line). Use absolute path name to make sure that the # files can be read on SIGHUP configuration reloads. #accept_mac_file=/etc/hostapd.accept #deny_mac_file=/etc/hostapd.deny # IEEE 802.11 specifies two authentication algorithms. hostapd can be # configured to allow both of these or only one. Open system authentication # should be used with IEEE 802.1X. # Bit fields of allowed authentication algorithms: # bit 0 = Open System Authentication # bit 1 = Shared Key Authentication (requires WEP) auth_algs=3 # Send empty SSID in beacons and ignore probe request frames that do not # specify full SSID, i.e., require stations to know SSID. # default: disabled (0) # 1 = send empty (length=0) SSID in beacon and ignore probe request for # broadcast SSID # 2 = clear SSID (ASCII 0), but keep the original length (this may be required # with some clients that do not support empty SSID) and ignore probe # requests for broadcast SSID ignore_broadcast_ssid=0 # TX queue parameters (EDCF / bursting) # default for all these fields: not set, use hardware defaults # tx_queue_<queue name>_<param> # queues: data0, data1, data2, data3, after_beacon, beacon # (data0 is the highest priority queue) # parameters: # aifs: AIFS (default 2) # cwmin: cwMin (1, 3, 7, 15, 31, 63, 127, 255, 511, 1023) # cwmax: cwMax (1, 3, 7, 15, 31, 63, 127, 255, 511, 1023); cwMax >= cwMin # burst: maximum length (in milliseconds with precision of up to 0.1 ms) for # bursting # # Default WMM parameters (IEEE 802.11 draft; 11-03-0504-03-000e): # These parameters are used by the access point when transmitting frames # to the clients. # # Low priority / AC_BK = background #tx_queue_data3_aifs=7 #tx_queue_data3_cwmin=15 #tx_queue_data3_cwmax=1023 #tx_queue_data3_burst=0 # Note: for IEEE 802.11b mode: cWmin=31 cWmax=1023 burst=0 # # Normal priority / AC_BE = best effort #tx_queue_data2_aifs=3 #tx_queue_data2_cwmin=15 #tx_queue_data2_cwmax=63 #tx_queue_data2_burst=0 # Note: for IEEE 802.11b mode: cWmin=31 cWmax=127 burst=0 #

# High priority / AC_VI = video #tx_queue_data1_aifs=1 #tx_queue_data1_cwmin=7 #tx_queue_data1_cwmax=15 #tx_queue_data1_burst=3.0 # Note: for IEEE 802.11b mode: cWmin=15 cWmax=31 burst=6.0 # # Highest priority / AC_VO = voice #tx_queue_data0_aifs=1 #tx_queue_data0_cwmin=3 #tx_queue_data0_cwmax=7 #tx_queue_data0_burst=1.5 # Note: for IEEE 802.11b mode: cWmin=7 cWmax=15 burst=3.3 # # Special queues; normally not user configurable # #tx_queue_after_beacon_aifs=2 #tx_queue_after_beacon_cwmin=15 #tx_queue_after_beacon_cwmax=1023 #tx_queue_after_beacon_burst=0 # #tx_queue_beacon_aifs=2 #tx_queue_beacon_cwmin=3 #tx_queue_beacon_cwmax=7 #tx_queue_beacon_burst=1.5 # 802.1D Tag (= UP) to AC mappings # WMM specifies following mapping of data frames to different ACs. This mapping # can be configured using Linux QoS/tc and sch_pktpri.o module. # 802.1D Tag 802.1D Designation Access Category WMM Designation # 1 BK AC_BK Background # 2 - AC_BK Background # 0 BE AC_BE Best Effort # 3 EE AC_BE Best Effort # 4 CL AC_VI Video # 5 VI AC_VI Video # 6 VO AC_VO Voice # 7 NC AC_VO Voice # Data frames with no priority information: AC_BE # Management frames: AC_VO # PS-Poll frames: AC_BE # Default WMM parameters (IEEE 802.11 draft; 11-03-0504-03-000e): # for 802.11a or 802.11g networks # These parameters are sent to WMM clients when they associate. # The parameters will be used by WMM clients for frames transmitted to the # access point. # # note - txop_limit is in units of 32microseconds # note - acm is admission control mandatory flag. 0 = admission control not # required, 1 = mandatory # note - here cwMin and cmMax are in exponent form. the actual cw value used # will be (2^n)-1 where n is the value given here # wmm_enabled=1 # # WMM-PS Unscheduled Automatic Power Save Delivery [U-APSD] # Enable this flag if U-APSD supported outside hostapd (eg., Firmware/driver) #uapsd_advertisement_enabled=1 # # Low priority / AC_BK = background wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 # Note: for IEEE 802.11b mode: cWmin=5 cWmax=10 # # Normal priority / AC_BE = best effort wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0

Page 51: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

51

# Note: for IEEE 802.11b mode: cWmin=5 cWmax=7 # # High priority / AC_VI = video wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 # Note: for IEEE 802.11b mode: cWmin=4 cWmax=5 txop_limit=188 # # Highest priority / AC_VO = voice wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 # Note: for IEEE 802.11b mode: cWmin=3 cWmax=4 burst=102 # Static WEP key configuration # # The key number to use when transmitting. # It must be between 0 and 3, and the corresponding key must be set. # default: not set #wep_default_key=0 # The WEP keys to use. # A key may be a quoted string or unquoted hexadecimal digits. # The key length should be 5, 13, or 16 characters, or 10, 26, or 32 # digits, depending on whether 40-bit (64-bit), 104-bit (128-bit), or # 128-bit (152-bit) WEP is used. # Only the default key must be supplied; the others are optional. # default: not set #wep_key0=123456789a #wep_key1="vwxyz" #wep_key2=0102030405060708090a0b0c0d #wep_key3=".2.4.6.8.0.23" # Station inactivity limit # # If a station does not send anything in ap_max_inactivity seconds, an # empty data frame is sent to it in order to verify whether it is # still in range. If this frame is not ACKed, the station will be # disassociated and then deauthenticated. This feature is used to # clear station table of old entries when the STAs move out of the # range. # # The station can associate again with the AP if it is still in range; # this inactivity poll is just used as a nicer way of verifying # inactivity; i.e., client will not report broken connection because # disassociation frame is not sent immediately without first polling # the STA with a data frame. # default: 300 (i.e., 5 minutes) #ap_max_inactivity=300 # Maximum allowed Listen Interval (how many Beacon periods STAs are allowed to # remain asleep). Default: 65535 (no limit apart from field size) #max_listen_interval=100 # WDS (4-address frame) mode with per-station virtual interfaces # (only supported with driver=nl80211) # This mode allows associated stations to use 4-address frames to allow layer 2 # bridging to be used. #wds_sta=1 ##### IEEE 802.11n related configuration ###################################### # ieee80211n: Whether IEEE 802.11n (HT) is enabled # 0 = disabled (default) # 1 = enabled # Note: You will also need to enable WMM for full HT functionality. #ieee80211n=1 # ht_capab: HT capabilities (list of flags) # LDPC coding capability: [LDPC] = supported # Supported channel width set: [HT40-] = both 20 MHz and 40 MHz with secondary # channel below the primary channel; [HT40+] = both 20 MHz and 40 MHz # with secondary channel below the primary channel # (20 MHz only if neither is set) # Note: There are limits on which channels can be used with HT40- and # HT40+. Following table shows the channels that may be available for # HT40- and HT40+ use per IEEE 802.11n Annex J: # freq HT40- HT40+ # 2.4 GHz 5-13 1-7 (1-9 in Europe/Japan)

# 5 GHz 40,48,56,64 36,44,52,60 # (depending on the location, not all of these channels may be available # for use) # Please note that 40 MHz channels may switch their primary and secondary # channels if needed or creation of 40 MHz channel maybe rejected based # on overlapping BSSes. These changes are done automatically when hostapd # is setting up the 40 MHz channel. # Spatial Multiplexing (SM) Power Save: [SMPS-STATIC] or [SMPS-DYNAMIC] # (SMPS disabled if neither is set) # HT-greenfield: [GF] (disabled if not set) # Short GI for 20 MHz: [SHORT-GI-20] (disabled if not set) # Short GI for 40 MHz: [SHORT-GI-40] (disabled if not set) # Tx STBC: [TX-STBC] (disabled if not set) # Rx STBC: [RX-STBC1] (one spatial stream), [RX-STBC12] (one or two spatial # streams), or [RX-STBC123] (one, two, or three spatial streams); Rx STBC # disabled if none of these set # HT-delayed Block Ack: [DELAYED-BA] (disabled if not set) # Maximum A-MSDU length: [MAX-AMSDU-7935] for 7935 octets (3839 octets if not # set) # DSSS/CCK Mode in 40 MHz: [DSSS_CCK-40] = allowed (not allowed if not set) # PSMP support: [PSMP] (disabled if not set) # L-SIG TXOP protection support: [LSIG-TXOP-PROT] (disabled if not set) #ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40] ##### IEEE 802.1X-2004 related configuration ################################## # Require IEEE 802.1X authorization ieee8021x=1 # IEEE 802.1X/EAPOL version # hostapd is implemented based on IEEE Std 802.1X-2004 which defines EAPOL # version 2. However, there are many client implementations that do not handle # the new version number correctly (they seem to drop the frames completely). # In order to make hostapd interoperate with these clients, the version number # can be set to the older version (1) with this configuration value. eapol_version=2 # Optional displayable message sent with EAP Request-Identity. The first \0 # in this string will be converted to ASCII-0 (nul). This can be used to # separate network info (comma separated list of attribute=value pairs); see, # e.g., RFC 4284. #eap_message=hello #eap_message=hello\0networkid=netw,nasid=foo,portid=0,NAIRealms=example.com # WEP rekeying (disabled if key lengths are not set or are set to 0) # Key lengths for default/broadcast and individual/unicast keys: # 5 = 40-bit WEP (also known as 64-bit WEP with 40 secret bits) # 13 = 104-bit WEP (also known as 128-bit WEP with 104 secret bits) #wep_key_len_broadcast=5 #wep_key_len_unicast=5 # Rekeying period in seconds. 0 = do not rekey (i.e., set keys only once) #wep_rekey_period=300 # EAPOL-Key index workaround (set bit7) for WinXP Supplicant (needed only if # only broadcast keys are used) #eapol_key_index_workaround=0 # EAP reauthentication period in seconds (default: 3600 seconds; 0 = disable # reauthentication). eap_reauth_period=3600 # Use PAE group address (01:80:c2:00:00:03) instead of individual target # address when sending EAPOL frames with driver=wired. This is the most common # mechanism used in wired authentication, but it also requires that the port # is only used by one station. #use_pae_group_addr=1 ##### Integrated EAP server ################################################### # Optionally, hostapd can be configured to use an integrated EAP server # to process EAP authentication locally without need for an external RADIUS # server. This functionality can be used both as a local authentication server # for IEEE 802.1X/EAPOL and as a RADIUS server for other devices. # Use integrated EAP server instead of external RADIUS authentication # server. This is also needed if hostapd is configured to act as a RADIUS # authentication server. eap_server=0 # Path for EAP server user database #eap_user_file=/home/labo4g/hostapd-0.7.3/hostapd/hostapd.eap_user

Page 52: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

52

# CA certificate (PEM or DER file) for EAP-TLS/PEAP/TTLS #ca_cert=/etc/hostapd.ca.pem # Server certificate (PEM or DER file) for EAP-TLS/PEAP/TTLS #server_cert=/etc/hostapd.server.pem # Private key matching with the server certificate for EAP-TLS/PEAP/TTLS # This may point to the same file as server_cert if both certificate and key # are included in a single file. PKCS#12 (PFX) file (.p12/.pfx) can also be # used by commenting out server_cert and specifying the PFX file as the # private_key. #private_key=/etc/hostapd.server.prv # Passphrase for private key #private_key_passwd=secret passphrase # Enable CRL verification. # Note: hostapd does not yet support CRL downloading based on CDP. Thus, a # valid CRL signed by the CA is required to be included in the ca_cert file. # This can be done by using PEM format for CA certificate and CRL and # concatenating these into one file. Whenever CRL changes, hostapd needs to be # restarted to take the new CRL into use. # 0 = do not verify CRLs (default) # 1 = check the CRL of the user certificate # 2 = check all CRLs in the certificate path #check_crl=1 # dh_file: File path to DH/DSA parameters file (in PEM format) # This is an optional configuration file for setting parameters for an # ephemeral DH key exchange. In most cases, the default RSA authentication does # not use this configuration. However, it is possible setup RSA to use # ephemeral DH key exchange. In addition, ciphers with DSA keys always use # ephemeral DH keys. This can be used to achieve forward secrecy. If the file # is in DSA parameters format, it will be automatically converted into DH # params. This parameter is required if anonymous EAP-FAST is used. # You can generate DH parameters file with OpenSSL, e.g., # "openssl dhparam -out /etc/hostapd.dh.pem 1024" #dh_file=/etc/hostapd.dh.pem # Configuration data for EAP-SIM database/authentication gateway interface. # This is a text string in implementation specific format. The example # implementation in eap_sim_db.c uses this as the UNIX domain socket name for # the HLR/AuC gateway (e.g., hlr_auc_gw). In this case, the path uses "unix:" # prefix. #eap_sim_db=unix:/tmp/hlr_auc_gw.sock # Encryption key for EAP-FAST PAC-Opaque values. This key must be a secret, # random value. It is configured as a 16-octet value in hex format. It can be # generated, e.g., with the following command: # od -tx1 -v -N16 /dev/random | colrm 1 8 | tr -d ' ' #pac_opaque_encr_key=000102030405060708090a0b0c0d0e0f # EAP-FAST authority identity (A-ID) # A-ID indicates the identity of the authority that issues PACs. The A-ID # should be unique across all issuing servers. In theory, this is a variable # length field, but due to some existing implementations requiring A-ID to be # 16 octets in length, it is strongly recommended to use that length for the # field to provid interoperability with deployed peer implementations. This # field is configured in hex format. #eap_fast_a_id=101112131415161718191a1b1c1d1e1f # EAP-FAST authority identifier information (A-ID-Info) # This is a user-friendly name for the A-ID. For example, the enterprise name # and server name in a human-readable format. This field is encoded as UTF-8. #eap_fast_a_id_info=test server # Enable/disable different EAP-FAST provisioning modes: #0 = provisioning disabled #1 = only anonymous provisioning allowed #2 = only authenticated provisioning allowed #3 = both provisioning modes allowed (default) #eap_fast_prov=3 # EAP-FAST PAC-Key lifetime in seconds (hard limit) #pac_key_lifetime=604800 # EAP-FAST PAC-Key refresh time in seconds (soft limit on remaining hard # limit). The server will generate a new PAC-Key when this number of seconds # (or fewer) of the lifetime remains. #pac_key_refresh_time=86400 # EAP-SIM and EAP-AKA protected success/failure indication using AT_RESULT_IND

# (default: 0 = disabled). #eap_sim_aka_result_ind=1 # Trusted Network Connect (TNC) # If enabled, TNC validation will be required before the peer is allowed to # connect. Note: This is only used with EAP-TTLS and EAP-FAST. If any other # EAP method is enabled, the peer will be allowed to connect without TNC. #tnc=1 ##### IEEE 802.11f - Inter-Access Point Protocol (IAPP) ####################### # Interface to be used for IAPP broadcast packets #iapp_interface=eth0 ##### RADIUS client configuration ############################################# # for IEEE 802.1X with external Authentication Server, IEEE 802.11 # authentication with external ACL for MAC addresses, and accounting # The own IP address of the access point (used as NAS-IP-Address) own_ip_addr=192.168.103.1 # Optional NAS-Identifier string for RADIUS messages. When used, this should be # a unique to the NAS within the scope of the RADIUS server. For example, a # fully qualified domain name can be used here. # When using IEEE 802.11r, nas_identifier must be set and must be between 1 and # 48 octets long. #nas_identifier=ap.example.com # RADIUS authentication server auth_server_addr=127.0.0.1 auth_server_port=1812 auth_server_shared_secret=testing123 # RADIUS accounting server #acct_server_addr=127.0.0.1 #acct_server_port=1813 #acct_server_shared_secret=testing123 # Secondary RADIUS servers; to be used if primary one does not reply to # RADIUS packets. These are optional and there can be more than one secondary # server listed. #auth_server_addr=127.0.0.2 #auth_server_port=1812 #auth_server_shared_secret=secret2 # #acct_server_addr=127.0.0.2 #acct_server_port=1813 #acct_server_shared_secret=secret2 # Retry interval for trying to return to the primary RADIUS server (in # seconds). RADIUS client code will automatically try to use the next server # when the current server is not replying to requests. If this interval is set, # primary server will be retried after configured amount of time even if the # currently used secondary server is still working. #radius_retry_primary_interval=600 # Interim accounting update interval # If this is set (larger than 0) and acct_server is configured, hostapd will # send interim accounting updates every N seconds. Note: if set, this overrides # possible Acct-Interim-Interval attribute in Access-Accept message. Thus, this # value should not be configured in hostapd.conf, if RADIUS server is used to # control the interim interval. # This value should not be less 600 (10 minutes) and must not be less than # 60 (1 minute). radius_acct_interim_interval=6 # Dynamic VLAN mode; allow RADIUS authentication server to decide which VLAN # is used for the stations. This information is parsed from following RADIUS # attributes based on RFC 3580 and RFC 2868: Tunnel-Type (value 13 = VLAN), # Tunnel-Medium-Type (value 6 = IEEE 802), Tunnel-Private-Group-ID (value # VLANID as a string). vlan_file option below must be configured if dynamic # VLANs are used. Optionally, the local MAC ACL list (accept_mac_file) can be # used to set static client MAC address to VLAN ID mapping. # 0 = disabled (default) # 1 = option; use default interface if RADIUS server does not include VLAN ID # 2 = required; reject authentication if RADIUS server does not include VLAN ID #dynamic_vlan=0

Page 53: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

53

# VLAN interface list for dynamic VLAN mode is read from a separate text file. # This list is used to map VLAN ID from the RADIUS server to a network # interface. Each station is bound to one interface in the same way as with # multiple BSSIDs or SSIDs. Each line in this text file is defining a new # interface and the line must include VLAN ID and interface name separated by # white space (space or tab). #vlan_file=/etc/hostapd.vlan # Interface where 802.1q tagged packets should appear when a RADIUS server is # used to determine which VLAN a station is on. hostapd creates a bridge for # each VLAN. Then hostapd adds a VLAN interface (associated with the interface # indicated by 'vlan_tagged_interface') and the appropriate wireless interface # to the bridge. #vlan_tagged_interface=eth0 ##### RADIUS authentication server configuration ############################## # hostapd can be used as a RADIUS authentication server for other hosts. This # requires that the integrated EAP server is also enabled and both # authentication services are sharing the same configuration. # File name of the RADIUS clients configuration for the RADIUS server. If this # commented out, RADIUS server is disabled. #radius_server_clients=/home/labo4g/hostapd-0.7.3/hostapd/hostapd.radius_clients # The UDP port number for the RADIUS authentication server #radius_server_auth_port=1812 # Use IPv6 with RADIUS server (IPv4 will also be supported using IPv6 API) #radius_server_ipv6=1 ##### WPA/IEEE 802.11i configuration ########################################## # Enable WPA. Setting this variable configures the AP to require WPA (either # WPA-PSK or WPA-RADIUS/EAP based on other configuration). For WPA-PSK, either # wpa_psk or wpa_passphrase must be set and wpa_key_mgmt must include WPA-PSK. # For WPA-RADIUS/EAP, ieee8021x must be set (but without dynamic WEP keys), # RADIUS authentication server must be configured, and WPA-EAP must be included # in wpa_key_mgmt. # This field is a bit field that can be used to enable WPA (IEEE 802.11i/D3.0) # and/or WPA2 (full IEEE 802.11i/RSN): # bit0 = WPA # bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled) wpa=3 # WPA pre-shared keys for WPA-PSK. This can be either entered as a 256-bit # secret in hex format (64 hex digits), wpa_psk, or as an ASCII passphrase # (8..63 characters) that will be converted to PSK. This conversion uses SSID # so the PSK changes when ASCII passphrase is used and the SSID is changed. # wpa_psk (dot11RSNAConfigPSKValue) # wpa_passphrase (dot11RSNAConfigPSKPassPhrase) #wpa_psk=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef wpa_passphrase=SAVIPANA # Optionally, WPA PSKs can be read from a separate text file (containing list # of (PSK,MAC address) pairs. This allows more than one PSK to be configured. # Use absolute path name to make sure that the files can be read on SIGHUP # configuration reloads. #wpa_psk_file=/etc/hostapd.wpa_psk # Set of accepted key management algorithms (WPA-PSK, WPA-EAP, or both). The # entries are separated with a space. WPA-PSK-SHA256 and WPA-EAP-SHA256 can be # added to enable SHA256-based stronger algorithms. # (dot11RSNAConfigAuthenticationSuitesTable) wpa_key_mgmt=WPA-EAP # Set of accepted cipher suites (encryption algorithms) for pairwise keys # (unicast packets). This is a space separated list of algorithms: # CCMP = AES in Counter mode with CBC-MAC [RFC 3610, IEEE 802.11i/D7.0] # TKIP = Temporal Key Integrity Protocol [IEEE 802.11i/D7.0] # Group cipher suite (encryption algorithm for broadcast and multicast frames) # is automatically selected based on this configuration. If only CCMP is # allowed as the pairwise cipher, group cipher will also be CCMP. Otherwise, # TKIP will be used as the group cipher. # (dot11RSNAConfigPairwiseCiphersTabl # Pairwise cipher for WPA (v1) (default: TKIP) wpa_pairwise=TKIP CCMP # Pairwise cipher for RSN/WPA2 (default: use wpa_pairwise value)

#rsn_pairwise=CCMP # Time interval for rekeying GTK (broadcast/multicast encryption keys) in # seconds. (dot11RSNAConfigGroupRekeyTime) wpa_group_rekey=300 # Rekey GTK when any STA that possesses the current GTK is leaving the BSS. # (dot11RSNAConfigGroupRekeyStrict) #wpa_strict_rekey=6400 # Time interval for rekeying GMK (master key used internally to generate GTKs # (in seconds). wpa_gmk_rekey=86400 # Maximum lifetime for PTK in seconds. This can be used to enforce rekeying of # PTK to mitigate some attacks against TKIP deficiencies. #wpa_ptk_rekey=600 # Enable IEEE 802.11i/RSN/WPA2 pre-authentication. This is used to speed up # roaming be pre-authenticating IEEE 802.1X/EAP part of the full RSN # authentication and key handshake before actually associating with a new AP. # (dot11RSNAPreauthenticationEnabled) #rsn_preauth=1 # # Space separated list of interfaces from which pre-authentication frames are # accepted (e.g., 'eth0' or 'eth0 wlan0wds0'. This list should include all # interface that are used for connections to other APs. This could include # wired interfaces and WDS links. The normal wireless data interface towards # associated stations (e.g., wlan0) should not be added, since # pre-authentication is only used with APs other than the currently associated # one. #rsn_preauth_interfaces=eth0 # peerkey: Whether PeerKey negotiation for direct links (IEEE 802.11e) is # allowed. This is only used with RSN/WPA2. # 0 = disabled (default) # 1 = enabled #peerkey=1 # ieee80211w: Whether management frame protection (MFP) is enabled # 0 = disabled (default) # 1 = optional # 2 = required #ieee80211w=0 # Association SA Query maximum timeout (in TU = 1.024 ms; for MFP) # (maximum time to wait for a SA Query response) # dot11AssociationSAQueryMaximumTimeout, 1...4294967295 #assoc_sa_query_max_timeout=1000 # Association SA Query retry timeout (in TU = 1.024 ms; for MFP) # (time between two subsequent SA Query requests) # dot11AssociationSAQueryRetryTimeout, 1...4294967295 #assoc_sa_query_retry_timeout=201 # okc: Opportunistic Key Caching (aka Proactive Key Caching) # Allow PMK cache to be shared opportunistically among configured interfaces # and BSSes (i.e., all configurations within a single hostapd process). # 0 = disabled (default) # 1 = enabled #okc=1 ##### IEEE 802.11r configuration ############################################## # Mobility Domain identifier (dot11FTMobilityDomainID, MDID) # MDID is used to indicate a group of APs (within an ESS, i.e., sharing the # same SSID) between which a STA can use Fast BSS Transition. # 2-octet identifier as a hex string. #mobility_domain=a1b2 # PMK-R0 Key Holder identifier (dot11FTR0KeyHolderID) # 1 to 48 octet identifier. # This is configured with nas_identifier (see RADIUS client section above). # Default lifetime of the PMK-RO in minutes; range 1..65535 # (dot11FTR0KeyLifetime) #r0_key_lifetime=10000 # PMK-R1 Key Holder identifier (dot11FTR1KeyHolderID) # 6-octet identifier as a hex string.

Page 54: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

54

#r1_key_holder=000102030405 # Reassociation deadline in time units (TUs / 1.024 ms; range 1000..65535) # (dot11FTReassociationDeadline) #reassociation_deadline=1000 # List of R0KHs in the same Mobility Domain # format: <MAC address> <NAS Identifier> <128-bit key as hex string> # This list is used to map R0KH-ID (NAS Identifier) to a destination MAC # address when requesting PMK-R1 key from the R0KH that the STA used during the # Initial Mobility Domain Association. #r0kh=02:01:02:03:04:05 r0kh-1.example.com 000102030405060708090a0b0c0d0e0f #r0kh=02:01:02:03:04:06 r0kh-2.example.com 00112233445566778899aabbccddeeff # And so on.. One line per R0KH. # List of R1KHs in the same Mobility Domain # format: <MAC address> <R1KH-ID> <128-bit key as hex string> # This list is used to map R1KH-ID to a destination MAC address when sending # PMK-R1 key from the R0KH. This is also the list of authorized R1KHs in the MD # that can request PMK-R1 keys. #r1kh=02:01:02:03:04:05 02:11:22:33:44:55 000102030405060708090a0b0c0d0e0f #r1kh=02:01:02:03:04:06 02:11:22:33:44:66 00112233445566778899aabbccddeeff # And so on.. One line per R1KH. # Whether PMK-R1 push is enabled at R0KH # 0 = do not push PMK-R1 to all configured R1KHs (default) # 1 = push PMK-R1 to all configured R1KHs whenever a new PMK-R0 is derived #pmk_r1_push=1 ##### Neighbor table ########################################################## # Maximum number of entries kept in AP table (either for neigbor table or for # detecting Overlapping Legacy BSS Condition). The oldest entry will be # removed when adding a new entry that would make the list grow over this # limit. Note! WFA certification for IEEE 802.11g requires that OLBC is # enabled, so this field should not be set to 0 when using IEEE 802.11g. # default: 255 #ap_table_max_size=255 # Number of seconds of no frames received after which entries may be deleted # from the AP table. Since passive scanning is not usually performed frequently # this should not be set to very small value. In addition, there is no # guarantee that every scan cycle will receive beacon frames from the # neighboring APs. # default: 60 #ap_table_expiration_time=3600 ##### Wi-Fi Protected Setup (WPS) ############################################# # WPS state # 0 = WPS disabled (default) # 1 = WPS enabled, not configured # 2 = WPS enabled, configured #wps_state=2 # AP can be configured into a locked state where new WPS Registrar are not # accepted, but previously authorized Registrars (including the internal one) # can continue to add new Enrollees. #ap_setup_locked=1 # Universally Unique IDentifier (UUID; see RFC 4122) of the device # This value is used as the UUID for the internal WPS Registrar. If the AP # is also using UPnP, this value should be set to the device's UPnP UUID. # If not configured, UUID will be generated based on the local MAC address. #uuid=12345678-9abc-def0-1234-56789abcdef0 # Note: If wpa_psk_file is set, WPS is used to generate random, per-device PSKs # that will be appended to the wpa_psk_file. If wpa_psk_file is not set, the # default PSK (wpa_psk/wpa_passphrase) will be delivered to Enrollees. Use of # per-device PSKs is recommended as the more secure option (i.e., make sure to # set wpa_psk_file when using WPS with WPA-PSK). # When an Enrollee requests access to the network with PIN method, the Enrollee # PIN will need to be entered for the Registrar. PIN request notifications are # sent to hostapd ctrl_iface monitor. In addition, they can be written to a # text file that could be used, e.g., to populate the AP administration UI with # pending PIN requests. If the following variable is set, the PIN requests will # be written to the configured file.

#wps_pin_requests=/var/run/hostapd_wps_pin_requests # Device Name # User-friendly description of device; up to 32 octets encoded in UTF-8 #device_name=Wireless AP # Manufacturer # The manufacturer of the device (up to 64 ASCII characters) #manufacturer=Company # Model Name # Model of the device (up to 32 ASCII characters) #model_name=WAP # Model Number # Additional device description (up to 32 ASCII characters) #model_number=123 # Serial Number # Serial number of the device (up to 32 characters) #serial_number=12345 # Primary Device Type # Used format: <categ>-<OUI>-<subcateg> # categ = Category as an integer value # OUI = OUI and type octet as a 4-octet hex-encoded value; 0050F204 for # default WPS OUI # subcateg = OUI-specific Sub Category as an integer value # Examples: # 1-0050F204-1 (Computer / PC) # 1-0050F204-2 (Computer / Server) # 5-0050F204-1 (Storage / NAS) # 6-0050F204-1 (Network Infrastructure / AP) #device_type=6-0050F204-1 # OS Version # 4-octet operating system version number (hex string) #os_version=01020300 # Config Methods # List of the supported configuration methods # Available methods: usba ethernet label display ext_nfc_token int_nfc_token # nfc_interface push_button keypad #config_methods=label display push_button keypad # Static access point PIN for initial configuration and adding Registrars # If not set, hostapd will not allow external WPS Registrars to control the # access point. The AP PIN can also be set at runtime with hostapd_cli # wps_ap_pin command. Use of temporary (enabled by user action) and random # AP PIN is much more secure than configuring a static AP PIN here. As such, # use of the ap_pin parameter is not recommended if the AP device has means for # displaying a random PIN. #ap_pin=12345670 # Skip building of automatic WPS credential # This can be used to allow the automatically generated Credential attribute to # be replaced with pre-configured Credential(s). #skip_cred_build=1 # Additional Credential attribute(s) # This option can be used to add pre-configured Credential attributes into M8 # message when acting as a Registrar. If skip_cred_build=1, this data will also # be able to override the Credential attribute that would have otherwise been # automatically generated based on network configuration. This configuration # option points to an external file that much contain the WPS Credential # attribute(s) as binary data. #extra_cred=hostapd.cred # Credential processing # 0 = process received credentials internally (default) # 1 = do not process received credentials; just pass them over ctrl_iface to # external program(s) # 2 = process received credentials internally and pass them over ctrl_iface # to external program(s) # Note: With wps_cred_processing=1, skip_cred_build should be set to 1 and # extra_cred be used to provide the Credential data for Enrollees. # # wps_cred_processing=1 will disabled automatic updates of hostapd.conf file # both for Credential processing and for marking AP Setup Locked based on # validation failures of AP PIN. An external program is responsible on updating # the configuration appropriately in this case. #wps_cred_processing=0

Page 55: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

55

# AP Settings Attributes for M7 # By default, hostapd generates the AP Settings Attributes for M7 based on the # current configuration. It is possible to override this by providing a file # with pre-configured attributes. This is similar to extra_cred file format, # but the AP Settings attributes are not encapsulated in a Credential # attribute. #ap_settings=hostapd.ap_settings # WPS UPnP interface # If set, support for external Registrars is enabled. #upnp_iface=br0 # Friendly Name (required for UPnP) # Short description for end use. Should be less than 64 characters. #friendly_name=WPS Access Point # Manufacturer URL (optional for UPnP) #manufacturer_url=http://www.example.com/ # Model Description (recommended for UPnP) # Long description for end user. Should be less than 128 characters. #model_description=Wireless Access Point # Model URL (optional for UPnP) #model_url=http://www.example.com/model/ # Universal Product Code (optional for UPnP) # 12-digit, all-numeric code that identifies the consumer package. #upc=123456789012 ##### Multiple BSSID support ##################################################

# # Above configuration is using the default interface (wlan#, or multi-SSID VLAN # interfaces). Other BSSIDs can be added by using separator 'bss' with # default interface name to be allocated for the data packets of the new BSS. # # hostapd will generate BSSID mask based on the BSSIDs that are # configured. hostapd will verify that dev_addr & MASK == dev_addr. If this is # not the case, the MAC address of the radio must be changed before starting # hostapd (ifconfig wlan0 hw ether <MAC addr>). If a BSSID is configured for # every secondary BSS, this limitation is not applied at hostapd and other # masks may be used if the driver supports them (e.g., swap the locally # administered bit) # # BSSIDs are assigned in order to each BSS, unless an explicit BSSID is # specified using the 'bssid' parameter. # If an explicit BSSID is specified, it must be chosen such that it: # - results in a valid MASK that covers it and the dev_addr # - is not the same as the MAC address of the radio # - is not the same as any other explicitly specified BSSID # # Please note that hostapd uses some of the values configured for the first BSS # as the defaults for the following BSSes. However, it is recommended that all # BSSes include explicit configuration of all relevant configuration items. # #bss=wlan0_0 #ssid=test2 # most of the above items can be used here (apart from radio interface specific # items, like channel) #bss=wlan0_1 #bssid=00:13:10:95:fe:0b # ...

5.1.2. FICHIER HOSTAPD.RADIUS_CLIENTS

# RADIUS client configuration for the RADIUS server #10.1.2.3 secret passphrase #192.168.103.0/24 another very secret passphrase 0.0.0.0/0 radius

5.2. FREERADIUS

5.2.1. FICHIER EAP.CONF

# -*- text -*- ## ## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.) ## ## $Id$ ####################################################################### # # Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # EAP types NOT listed here may be supported via the "eap2" module. # See experimental.conf for documentation. # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = md5 # A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60

# There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no # Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no # # Help prevent DoS attacks by limiting the number of # sessions that the server is tracking. Most systems # can handle ~30 EAP sessions/s, so the default limit # of 4096 should be OK. max_sessions = 4096 # Supported EAP-types # # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 {

Page 56: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

56

} # Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # leap { } # Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: " # The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # auth_type = PAP } ## EAP-TLS # # See raddb/certs/README for additional comments # on certificates. # # If OpenSSL was not found at the time the server was # built, the "tls", "ttls", and "peap" sections will # be ignored. # # Otherwise, when the server first starts in debugging # mode, test certificates will be created. See the # "make_cert_command" below for details, and the README # file in raddb/certs # # These test certificates SHOULD NOT be used in a normal # deployment. They are created only to make it easier # to install the server, and to perform some simple # tests with EAP-TLS, TTLS, or PEAP. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # tls { # # These is used to simplify later configurations. # certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = whatever private_key_file = ${certdir}/server.key

# If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # # If CA_file (below) is not used, then the # certificate_file below MUST include not # only the server certificate, but ALSO all # of the CA certificates used to sign the # server certificate. certificate_file = ${certdir}/server.pem # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. # # This parameter is used only for EAP-TLS, # when you issue client certificates. If you do # not use client certificates, and you do not want # to permit EAP-TLS authentication, then delete # this configuration item. CA_file = ${cadir}/ca.pem # # For DH cipher suites to work, you have to # run OpenSSL to create the DH file first: # # openssl dhparam -out certs/dh 1024 # dh_file = ${certdir}/dh random_file = ${certdir}/random # # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # # fragment_size = 1024 # include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # # include_length = yes # Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) uncomment the line below. # 5) Restart radiusd # check_crl = yes # CA_path = /path/to/directory/with/ca_certs/and/crls/ # # If check_cert_issuer is set, the value will # be checked against the DN of the issuer in # the client certificate. If the values do not # match, the cerficate verification will fail, # rejecting the user. # # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" # # If check_cert_cn is set, the value will

Page 57: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

57

# be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # This check is done only if the previous # "check_cert_issuer" is not set, or if # the check succeeds. # # check_cert_cn = %{User-Name} # # Set this option to specify the allowed # TLS cipher suites. The format is listed # in "man 1 ciphers". cipher_list = "DEFAULT" # # This configuration entry should be deleted # once the server is running in a normal # configuration. It is here ONLY to make # initial deployments easier. # make_cert_command = "${certdir}/bootstrap" # # Session resumption / fast reauthentication # cache. # cache { # # Enable it. The default is "no". # Deleting the entire "cache" subsection # Also disables caching. # # You can disallow resumption for a # particular user by adding the following # attribute to the control item list: # # Allow-Session-Resumption = No # # If "enable = no" below, you CANNOT # enable resumption for just one user # by setting the above attribute to "yes". # enable = no # # Lifetime of the cached entries, in hours. # The sessions will be deleted after this # time. # lifetime = 24 # hours # # The maximum number of entries in the # cache. Set to "0" for "infinite". # # This could be set to the number of users # who are logged in... which can be a LOT. # max_entries = 255 } } # The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. # # You can make TTLS require a client cert by setting #

# EAP-TLS-Require-Client-Cert = Yes # # in the control items for a request. # ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. default_eap_type = md5 # The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} copy_request_to_tunnel = no # The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} use_tunneled_reply = no # # The inner tunneled request can be sent # through a virtual server constructed # specifically for this purpose. # # If this entry is commented out, the inner # tunneled request will be sent through # the virtual server that processed the # outer requests. # virtual_server = "inner-tunnel" # This has the same meaning as the # same field in the "tls" module, above. # The default value here is "yes". # include_length = yes } ################################################## # # !!!!! WARNINGS for Windows compatibility !!!!! # ################################################## # # If you see the server send an Access-Challenge, # and the client never sends another Access-Request, # then # # STOP! # # The server certificate has to have special OID's # in it, or else the Microsoft clients will silently # fail. See the "scripts/xpextensions" file for # details, and the following page: # # http://support.microsoft.com/kb/814394/en-us

Page 58: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

58

# # For additional Windows XP SP2 issues, see: # # http://support.microsoft.com/kb/885453/en-us # # Note that we do not necessarily agree with their # explanation... but the fix does appear to work. # ################################################## # # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # # # You can make PEAP require a client cert by setting # # EAP-TLS-Require-Client-Cert = Yes # # in the control items for a request. # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. default_eap_type = mschapv2

# the PEAP module also has these configuration # items, which are the same as for TTLS. copy_request_to_tunnel = no use_tunneled_reply = no # When the tunneled session is proxied, the # home server may not understand EAP-MSCHAP-V2. # Set this entry to "no" to proxy the tunneled # EAP-MSCHAP-V2 as normal MSCHAPv2. # proxy_tunneled_request_as_eap = yes # # The inner tunneled request can be sent # through a virtual server constructed # specifically for this purpose. # # If this entry is commented out, the inner # tunneled request will be sent through # the virtual server that processed the # outer requests. # virtual_server = "inner-tunnel" } # # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { } }

5.2.2. FICHIER RADIUSD.CONF

# -*- text -*- ## ## radiusd.conf -- FreeRADIUS server configuration file. ## ## http://www.freeradius.org/ ## $Id$ ## ###################################################################### # # Read "man radiusd" before editing this file. See the section # titled DEBUGGING. It outlines a method where you can quickly # obtain the configuration you want, without running into # trouble. # # Run the server in debugging mode, and READ the output. # # $ radiusd -X # # We cannot emphasize this point strongly enough. The vast # majority of problems can be solved by carefully reading the # debugging output, which includes warnings about common issues, # and suggestions for how they may be fixed. # # There may be a lot of output, but look carefully for words like: # "warning", "error", "reject", or "failure". The messages there # will usually be enough to guide you to a solution. # # If you are going to ask a question on the mailing list, then # explain what you are trying to do, and include the output from # debugging mode (radiusd -X). Failure to do so means that all # of the responses to your question will be people telling you # to "post the output of radiusd -X".

###################################################################### # # The location of other config files and logfiles are declared # in this file. # # Also general configuration for modules can be done in this # file, it is exported through the API to modules that ask for # it. # # See "man radiusd.conf" for documentation on the format of this # file. Note that the individual configuration items are NOT # documented in that "man" page. They are only documented here, # in the comments. # # As of 2.0.0, FreeRADIUS supports a simple processing language # in the "authorize", "authenticate", "accounting", etc. sections. # See "man unlang" for details. # prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct # # name of the running server. See also the "-n" command-line option. name = freeradius # Location of config and logfiles. confdir = ${raddbdir} run_dir = ${localstatedir}/run/${name}

Page 59: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

59

# Should likely be ${localstatedir}/lib/radiusd db_dir = ${raddbdir} # # libdir: Where to find the rlm_* modules. # # This should be automatically set at configuration time. # # If the server builds and installs, but fails at execution time # with an 'undefined symbol' error, then you can use the libdir # directive to work around the problem. # # The cause is usually that a library has been installed on your # system in a place where the dynamic linker CANNOT find it. When # executing as root (or another user), your personal environment MAY # be set up to allow the dynamic linker to find the library. When # executing as a daemon, FreeRADIUS MAY NOT have the same # personalized configuration. # # To work around the problem, find out which library contains that symbol, # and add the directory containing that library to the end of 'libdir', # with a colon separating the directory names. NO spaces are allowed. # # e.g. libdir = /usr/local/lib:/opt/package/lib # # You can also try setting the LD_LIBRARY_PATH environment variable # in a script which starts the server. # # If that does not work, then you can re-configure and re-build the # server to NOT use shared libraries, via: # # ./configure --disable-shared # make # make install # libdir = /usr/lib/freeradius # pidfile: Where to place the PID of the RADIUS server. # # The server may be signalled while it's running by using this # file. # # This file is written when ONLY running in daemon mode. # # e.g.: kill -HUP `cat /var/run/radiusd/radiusd.pid` # pidfile = ${run_dir}/${name}.pid # chroot: directory where the server does "chroot". # # The chroot is done very early in the process of starting the server. # After the chroot has been performed it switches to the "user" listed # below (which MUST be specified). If "group" is specified, it switchs # to that group, too. Any other groups listed for the specified "user" # in "/etc/group" are also added as part of this process. # # The current working directory (chdir / cd) is left *outside* of the # chroot until all of the modules have been initialized. This allows # the "raddb" directory to be left outside of the chroot. Once the # modules have been initialized, it does a "chdir" to ${logdir}. This # means that it should be impossible to break out of the chroot. # # If you are worried about security issues related to this use of chdir, # then simply ensure that the "raddb" directory is inside of the chroot, # end be sure to do "cd raddb" BEFORE starting the server. # # If the server is statically linked, then the only files that have # to exist in the chroot are ${run_dir} and ${logdir}. If you do the # "cd raddb" as discussed above, then the "raddb" directory has to be # inside of the chroot directory, too. # #chroot = /path/to/chroot/directory # user/group: The name (or #number) of the user/group to run radiusd as. # # If these are commented out, the server will run as the user/group # that started it. In order to change to a different user/group, you # MUST be root ( or have root privleges ) to start the server. # # We STRONGLY recommend that you run the server with as few permissions # as possible. That is, if you're not using shadow passwords, the # user and group items below should be set to radius'.

# # NOTE that some kernels refuse to setgid(group) when the value of # (unsigned)group is above 60000; don't use group nobody on these systems! # # On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not. # # The server will also try to use "initgroups" to read /etc/groups. # It will join all groups where "user" is a member. This can allow # for some finer-grained access controls. # user = freerad group = freerad # max_request_time: The maximum time (in seconds) to handle a request. # # Requests which take more time than this to process may be killed, and # a REJECT message is returned. # # WARNING: If you notice that requests take a long time to be handled, # then this MAY INDICATE a bug in the server, in one of the modules # used to handle a request, OR in your local configuration. # # This problem is most often seen when using an SQL database. If it takes # more than a second or two to receive an answer from the SQL database, # then it probably means that you haven't indexed the database. See your # SQL server documentation for more information. # # Useful range of values: 5 to 120 # max_request_time = 30 # cleanup_delay: The time to wait (in seconds) before cleaning up # a reply which was sent to the NAS. # # The RADIUS request is normally cached internally for a short period # of time, after the reply is sent to the NAS. The reply packet may be # lost in the network, and the NAS will not see it. The NAS will then # re-send the request, and the server will respond quickly with the # cached reply. # # If this value is set too low, then duplicate requests from the NAS # MAY NOT be detected, and will instead be handled as seperate requests. # # If this value is set too high, then the server will cache too many # requests, and some new requests may get blocked. (See 'max_requests'.) # # Useful range of values: 2 to 10 # cleanup_delay = 5 # max_requests: The maximum number of requests which the server keeps # track of. This should be 256 multiplied by the number of clients. # e.g. With 4 clients, this number should be 1024. # # If this number is too low, then when the server becomes busy, # it will not respond to any new requests, until the 'cleanup_delay' # time has passed, and it has removed the old requests. # # If this number is set too high, then the server will use a bit more # memory for no real benefit. # # If you aren't sure what it should be set to, it's better to set it # too high than too low. Setting it to 1000 per client is probably # the highest it should be. # # Useful range of values: 256 to infinity # max_requests = 1024 # listen: Make the server listen on a particular IP address, and send # replies out from that address. This directive is most useful for # hosts with multiple IP addresses on one interface. # # If you want the server to listen on additional addresses, or on # additionnal ports, you can use multiple "listen" sections. # # Each section make the server listen for only one type of packet, # therefore authentication and accounting have to be configured in # different sections.

Page 60: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

60

# # The server ignore all "listen" section if you are using '-i' and '-p' # on the command line. # listen { # Type of packets to listen for. # Allowed values are: # auth listen for authentication packets # acct listen for accounting packets # proxy IP to use for sending proxied packets # detail Read from the detail file. For examples, see # raddb/sites-available/copy-acct-to-home-server # status listen for Status-Server packets. For examples, # see raddb/sites-available/status # coa listen for CoA-Request and Disconnect-Request # packets. For examples, see the file # raddb/sites-available/coa-server # type = auth # Note: "type = proxy" lets you control the source IP used for # proxying packets, with some limitations: # # * A proxy listener CANNOT be used in a virtual server section. # * You should probably set "port = 0". # * Any "clients" configuration will be ignored. # # See also proxy.conf, and the "src_ipaddr" configuration entry # in the sample "home_server" section. When you specify the # source IP address for packets sent to a home server, the # proxy listeners are automatically created. # IP address on which to listen. # Allowed values are: # dotted quad (1.2.3.4) # hostname (radius.example.com) # wildcard (*) ipaddr = * # OR, you can use an IPv6 address, but not both # at the same time. # ipv6addr = :: # any. ::1 == localhost # Port on which to listen. # Allowed values are: # integer port number (1812) # 0 means "use /etc/services for the proper port" port = 0 # Some systems support binding to an interface, in addition # to the IP address. This feature isn't strictly necessary, # but for sites with many IP addresses on one interface, # it's useful to say "listen on all addresses for eth0". # # If your system does not support this feature, you will # get an error if you try to use it. # # interface = eth0 # Per-socket lists of clients. This is a very useful feature. # # The name here is a reference to a section elsewhere in # radiusd.conf, or clients.conf. Having the name as # a reference allows multiple sockets to use the same # set of clients. # # If this configuration is used, then the global list of clients # is IGNORED for this "listen" section. Take care configuring # this feature, to ensure you don't accidentally disable a # client you need. # # See clients.conf for the configuration of "per_socket_clients". # # clients = per_socket_clients } # This second "listen" section is for listening on the accounting # port, too. # listen { ipaddr = * # ipv6addr = :: port = 0

type = acct # interface = eth0 # clients = per_socket_clients } # hostname_lookups: Log the names of clients or just their IP addresses # e.g., www.freeradius.org (on) or 206.47.27.232 (off). # # The default is 'off' because it would be overall better for the net # if people had to knowingly turn this feature on, since enabling it # means that each client request will result in AT LEAST one lookup # request to the nameserver. Enabling hostname_lookups will also # mean that your server may stop randomly for 30 seconds from time # to time, if the DNS requests take too long. # # Turning hostname lookups off also means that the server won't block # for 30 seconds, if it sees an IP address which has no name associated # with it. # # allowed values: {no, yes} # hostname_lookups = no # Core dumps are a bad thing. This should only be set to 'yes' # if you're debugging a problem with the server. # # allowed values: {no, yes} # allow_core_dumps = no # Regular expressions # # These items are set at configure time. If they're set to "yes", # then setting them to "no" turns off regular expression support. # # If they're set to "no" at configure time, then setting them to "yes" # WILL NOT WORK. It will give you an error. # regular_expressions = yes extended_expressions = yes # # Logging section. The various "log_*" configuration items # will eventually be moved here. # log { # # Destination for log messages. This can be one of: # # files - log to "file", as defined below. # syslog - to syslog (see also the "syslog_facility", below. # stdout - standard output # stderr - standard error. # # The command-line option "-X" over-rides this option, and forces # logging to go to stdout. # destination = files # # The logging messages for the server are appended to the # tail of this file if destination == "files" # # If the server is running in debugging mode, this file is # NOT used. # file = ${logdir}/radius.log # # If this configuration parameter is set, then log messages for # a *request* go to this file, rather than to radius.log. # # i.e. This is a log file per request, once the server has accepted # the request as being from a valid client. Messages that are # not associated with a request still go to radius.log. # # Not all log messages in the server core have been updated to use # this new internal API. As a result, some messages will still # go to radius.log. Please submit patches to fix this behavior. # # The file name is expanded dynamically. You should ONLY user # server-side attributes for the filename (e.g. things you control). # Using this feature MAY also slow down the server substantially,

Page 61: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

61

# especially if you do thinks like SQL calls as part of the # expansion of the filename. # # The name of the log file should use attributes that don't change # over the lifetime of a request, such as User-Name, # Virtual-Server or Packet-Src-IP-Address. Otherwise, the log # messages will be distributed over multiple files. # # Logging can be enabled for an individual request by a special # dynamic expansion macro: %{debug: 1}, where the debug level # for this request is set to '1' (or 2, 3, etc.). e.g. # # ... # update control { # Tmp-String-0 = "%{debug:1}" # } # ... # # The attribute that the value is assigned to is unimportant, # and should be a "throw-away" attribute with no side effects. # #requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log # # Which syslog facility to use, if ${destination} == "syslog" # # The exact values permitted here are OS-dependent. You probably # don't want to change this. # syslog_facility = daemon # Log the full User-Name attribute, as it was found in the request. # # allowed values: {no, yes} # stripped_names = no # Log authentication requests to the log file. # # allowed values: {no, yes} # auth = yes # Log passwords with the authentication requests. # auth_badpass - logs password if it's rejected # auth_goodpass - logs password if it's correct # # allowed values: {no, yes} # auth_badpass = yes auth_goodpass = yes # Log additional text at the end of the "Login OK" messages. # for these to work, the "auth" and "auth_goopass" or "auth_badpass" # configurations above have to be set to "yes". # # The strings below are dynamically expanded, which means that # you can put anything you want in them. However, note that # this expansion can be slow, and can negatively impact server # performance. # msg_goodpass = "******BON LOGIN*******" msg_badpass = "*******MAUVAIS LOGIN**********" } # The program to execute to do concurrency checks. checkrad = ${sbindir}/checkrad # SECURITY CONFIGURATION # # There may be multiple methods of attacking on the server. This # section holds the configuration items which minimize the impact # of those attacks # security { # # max_attributes: The maximum number of attributes # permitted in a RADIUS packet. Packets which have MORE # than this number of attributes in them will be dropped. # # If this number is set too low, then no RADIUS packets # will be accepted.

# # If this number is set too high, then an attacker may be # able to send a small number of packets which will cause # the server to use all available memory on the machine. # # Setting this number to 0 means "allow any number of attributes" max_attributes = 200 # # reject_delay: When sending an Access-Reject, it can be # delayed for a few seconds. This may help slow down a DoS # attack. It also helps to slow down people trying to brute-force # crack a users password. # # Setting this number to 0 means "send rejects immediately" # # If this number is set higher than 'cleanup_delay', then the # rejects will be sent at 'cleanup_delay' time, when the request # is deleted from the internal cache of requests. # # Useful ranges: 1 to 5 reject_delay = 1 # # status_server: Whether or not the server will respond # to Status-Server requests. # # When sent a Status-Server message, the server responds with # an Access-Accept or Accounting-Response packet. # # This is mainly useful for administrators who want to "ping" # the server, without adding test users, or creating fake # accounting packets. # # It's also useful when a NAS marks a RADIUS server "dead". # The NAS can periodically "ping" the server with a Status-Server # packet. If the server responds, it must be alive, and the # NAS can start using it for real requests. # # See also raddb/sites-available/status # status_server = yes } # PROXY CONFIGURATION # # proxy_requests: Turns proxying of RADIUS requests on or off. # # The server has proxying turned on by default. If your system is NOT # set up to proxy requests to another server, then you can turn proxying # off here. This will save a small amount of resources on the server. # # If you have proxying turned off, and your configuration files say # to proxy a request, then an error message will be logged. # # To disable proxying, change the "yes" to "no", and comment the # $INCLUDE line. # # allowed values: {no, yes} # proxy_requests = yes $INCLUDE proxy.conf # CLIENTS CONFIGURATION # # Client configuration is defined in "clients.conf". # # The 'clients.conf' file contains all of the information from the old # 'clients' and 'naslist' configuration files. We recommend that you # do NOT use 'client's or 'naslist', although they are still # supported. # # Anything listed in 'clients.conf' will take precedence over the # information from the old-style configuration files. # $INCLUDE clients.conf # THREAD POOL CONFIGURATION # # The thread pool is a long-lived group of threads which

Page 62: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

62

# take turns (round-robin) handling any incoming requests. # # You probably want to have a few spare threads around, # so that high-load situations can be handled immediately. If you # don't have any spare threads, then the request handling will # be delayed while a new thread is created, and added to the pool. # # You probably don't want too many spare threads around, # otherwise they'll be sitting there taking up resources, and # not doing anything productive. # # The numbers given below should be adequate for most situations. # thread pool { # Number of servers to start initially --- should be a reasonable # ballpark figure. start_servers = 5 # Limit on the total number of servers running. # # If this limit is ever reached, clients will be LOCKED OUT, so it # should NOT BE SET TOO LOW. It is intended mainly as a brake to # keep a runaway server from taking the system with it as it spirals # down... # # You may find that the server is regularly reaching the # 'max_servers' number of threads, and that increasing # 'max_servers' doesn't seem to make much difference. # # If this is the case, then the problem is MOST LIKELY that # your back-end databases are taking too long to respond, and # are preventing the server from responding in a timely manner. # # The solution is NOT do keep increasing the 'max_servers' # value, but instead to fix the underlying cause of the # problem: slow database, or 'hostname_lookups=yes'. # # For more information, see 'max_request_time', above. # max_servers = 32 # Server-pool size regulation. Rather than making you guess # how many servers you need, FreeRADIUS dynamically adapts to # the load it sees, that is, it tries to maintain enough # servers to handle the current load, plus a few spare # servers to handle transient load spikes. # # It does this by periodically checking how many servers are # waiting for a request. If there are fewer than # min_spare_servers, it creates a new spare. If there are # more than max_spare_servers, some of the spares die off. # The default values are probably OK for most sites. # min_spare_servers = 3 max_spare_servers = 10 # There may be memory leaks or resource allocation problems with # the server. If so, set this value to 300 or so, so that the # resources will be cleaned up periodically. # # This should only be necessary if there are serious bugs in the # server which have not yet been fixed. # # '0' is a special value meaning 'infinity', or 'the servers never # exit' max_requests_per_server = 0 } # MODULE CONFIGURATION # # The names and configuration of each module is located in this section. # # After the modules are defined here, they may be referred to by name, # in other sections of this configuration file. # modules { # # Each module has a configuration as follows: # # name [ instance ] { # config_item = value # ... # }

# # The 'name' is used to load the 'rlm_name' library # which implements the functionality of the module. # # The 'instance' is optional. To have two different instances # of a module, it first must be referred to by 'name'. # The different copies of the module are then created by # inventing two 'instance' names, e.g. 'instance1' and 'instance2' # # The instance names can then be used in later configuration # INSTEAD of the original 'name'. See the 'radutmp' configuration # for an example. # # # As of 2.0.5, most of the module configurations are in a # sub-directory. Files matching the regex /[a-zA-Z0-9_.]+/ # are loaded. The modules are initialized ONLY if they are # referenced in a processing section, such as authorize, # authenticate, accounting, pre/post-proxy, etc. # $INCLUDE ${confdir}/modules/ # Extensible Authentication Protocol # # For all EAP related authentications. # Now in another file, because it is very large. # $INCLUDE eap.conf # Include another file that has the SQL-related configuration. # This is another file only because it tends to be big. # # $INCLUDE sql.conf # # This module is an SQL enabled version of the counter module. # # Rather than maintaining seperate (GDBM) databases of # accounting info for each counter, this module uses the data # stored in the raddacct table by the sql modules. This # module NEVER does any database INSERTs or UPDATEs. It is # totally dependent on the SQL module to process Accounting # packets. # # $INCLUDE sql/mysql/counter.conf # # IP addresses managed in an SQL table. # # $INCLUDE sqlippool.conf } # Instantiation # # This section orders the loading of the modules. Modules # listed here will get loaded BEFORE the later sections like # authorize, authenticate, etc. get examined. # # This section is not strictly needed. When a section like # authorize refers to a module, it's automatically loaded and # initialized. However, some modules may not be listed in any # of the following sections, so they can be listed here. # # Also, listing modules here ensures that you have control over # the order in which they are initalized. If one module needs # something defined by another module, you can list them in order # here, and ensure that the configuration will be OK. # instantiate { # # Allows the execution of external scripts. # The entire command line (and output) must fit into 253 bytes. # # e.g. Framed-Pool = `%{exec:/bin/echo foo}` exec # # The expression module doesn't do authorization, # authentication, or accounting. It only does dynamic # translation, of the form: # # Session-Timeout = `%{expr:2 + 3}`

Page 63: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

63

# # So the module needs to be instantiated, but CANNOT be # listed in any other section. See 'doc/rlm_expr' for # more information. # expr # # We add the counter module here so that it registers # the check-name attribute before any module which sets # it # daily expiration logintime # subsections here can be thought of as "virtual" modules. # # e.g. If you have two redundant SQL servers, and you want to # use them in the authorize and accounting sections, you could # place a "redundant" block in each section, containing the # exact same text. Or, you could uncomment the following # lines, and list "redundant_sql" in the authorize and # accounting sections. # #redundant redundant_sql { # sql1 # sql2 #} } ###################################################################### # # Policies that can be applied in multiple places are listed # globally. That way, they can be defined once, and referred # to multiple times. #

###################################################################### $INCLUDE policy.conf ###################################################################### # # Load virtual servers. # # This next $INCLUDE line loads files in the directory that # match the regular expression: /[a-zA-Z0-9_.]+/ # # It allows you to define new virtual servers simply by placing # a file into the raddb/sites-enabled/ directory. # $INCLUDE sites-enabled/ ###################################################################### # # All of the other configuration sections like "authorize {}", # "authenticate {}", "accounting {}", have been moved to the # the file: # # raddb/sites-available/default # # This is the "default" virtual server that has the same # configuration as in version 1.0.x and 1.1.x. The default # installation enables this virtual server. You should # edit it to create policies for your local site. # # For more documentation on virtual servers, see: # # raddb/sites-available/README # ######################################################################

5.2.3. FICHIER USERS.CONF

# # Please read the documentation file ../doc/processing_users_file, # or 'man 5 users' (after installing the server) for more information. # # This file contains authentication security and configuration # information for each user. Accounting requests are NOT processed # through this file. Instead, see 'acct_users', in this directory. # # If you are not sure why a particular reply is being sent by the # server, then run the server in debugging mode (radiusd -X), and # you will see which entries in this file are matched. # # When an authentication request is received from the comm server, # these values are tested. Only the first match is used unless the # "Fall-Through" variable is set to "Yes". # The first field is the user's name and can be up to # 253 characters in length. This is followed (on the same line) with # the list of authentication requirements for that user. This can # include password, comm server name, comm server port number, protocol # type (perhaps set by the "hints" file), and huntgroup name (set by # the "huntgroups" file). # # # A special user named "DEFAULT" matches on all usernames. # You can have several DEFAULT entries. All entries are processed # in the order they appear in this file. The first entry that # matches the login-request will stop processing unless you use # the Fall-Through variable. # # If you use the database support to turn this file into a .db or .dbm # file, the DEFAULT entries _have_ to be at the end of this file and # you can't have multiple entries for one username. # # Indented (with the tab character) lines following the first # line indicate the configuration values to be passed back to # the comm server to allow the initiation of a user session. # This can include things like the PPP configuration values # or the host to log the user onto. # # You can include another `users' file with `$INCLUDE users.other' # #

# For a list of RADIUS attributes, and links to their definitions, # see: # # http://www.freeradius.org/rfc/attributes.html # # # Deny access for a specific user. Note that this entry MUST # be before any other 'Auth-Type' attribute which results in the user # being authenticated. # # Note that there is NO 'Fall-Through' attribute, so the user will not # be given any additional resources. # #lameuser Auth-Type := Reject # Reply-Message = "Your account has been disabled." # # Deny access for a group of users. # # Note that there is NO 'Fall-Through' attribute, so the user will not # be given any additional resources. # #DEFAULT Group == "disabled", Auth-Type := Reject # Reply-Message = "Your account has been disabled." # # # This is a complete entry for "steve". Note that there is no Fall-Through # entry so that no DEFAULT entry will be used, and the user will NOT # get any attributes in addition to the ones listed here. # #steve Cleartext-Password := "testing" # Service-Type = Framed-User, # Framed-Protocol = PPP, # Framed-IP-Address = 172.16.3.33, # Framed-IP-Netmask = 255.255.255.0, # Framed-Routing = Broadcast-Listen, # Framed-Filter-Id = "std.ppp", # Framed-MTU = 1500, # Framed-Compression = Van-Jacobsen-TCP-IP #0024230681a9 Cleartext-Password := "0024230681a9"

Page 64: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

64

# Fall-Through = Yes user1 Cleartext-Password := "test" Fall-Through = Yes dfava Cleartext-Password := "azerty" Fall-Through = Yes hmartin Cleartext-Password := "123456" Fall-Through = Yes # Framed-IP-Address = 127.0.0.1, # Framed-IP-Netmask = 255.255.255.0, # Fall-Through = Yes # This is an entry for a user with a space in their name. # Note the double quotes surrounding the name. # #"John Doe" Cleartext-Password := "hello" # Reply-Message = "Hello, %{User-Name}" # # Dial user back and telnet to the default host for that port # #Deg Cleartext-Password := "ge55ged" # Service-Type = Callback-Login-User, # Login-IP-Host = 0.0.0.0, # Callback-Number = "9,5551212", # Login-Service = Telnet, # Login-TCP-Port = Telnet # # Another complete entry. After the user "dialbk" has logged in, the # connection will be broken and the user will be dialed back after which # he will get a connection to the host "timeshare1". # #dialbk Cleartext-Password := "callme" # Service-Type = Callback-Login-User, # Login-IP-Host = timeshare1, # Login-Service = PortMaster, # Callback-Number = "9,1-800-555-1212" # # user "swilson" will only get a static IP number if he logs in with # a framed protocol on a terminal server in Alphen (see the huntgroups file). # # Note that by setting "Fall-Through", other attributes will be added from # the following DEFAULT entries # #swilson Service-Type == Framed-User, Huntgroup-Name == "alphen" # Framed-IP-Address = 192.168.1.65, # Fall-Through = Yes # # If the user logs in as 'username.shell', then authenticate them # using the default method, give them shell access, and stop processing # the rest of the file. # #DEFAULT Suffix == ".shell" # Service-Type = Login-User, # Login-Service = Telnet, # Login-IP-Host = your.shell.machine # # The rest of this file contains the several DEFAULT entries.

# DEFAULT entries match with all login names. # Note that DEFAULT entries can also Fall-Through (see first entry). # A name-value pair from a DEFAULT entry will _NEVER_ override # an already existing name-value pair. # # # Set up different IP address pools for the terminal servers. # Note that the "+" behind the IP address means that this is the "base" # IP address. The Port-Id (S0, S1 etc) will be added to it. # #DEFAULT Service-Type == Framed-User, Huntgroup-Name == "alphen" # Framed-IP-Address = 192.168.1.32+, # Fall-Through = Yes #DEFAULT Service-Type == Framed-User, Huntgroup-Name == "delft" # Framed-IP-Address = 192.168.2.32+, # Fall-Through = Yes # # Sample defaults for all framed connections. # #DEFAULT Service-Type == Framed-User # Framed-IP-Address = 255.255.255.254, # Framed-MTU = 576, # Service-Type = Framed-User, # Fall-Through = Yes # # Default for PPP: dynamic IP address, PPP mode, VJ-compression. # NOTE: we do not use Hint = "PPP", since PPP might also be auto-detected # by the terminal server in which case there may not be a "P" suffix. # The terminal server sends "Framed-Protocol = PPP" for auto PPP. # DEFAULT Framed-Protocol == PPP Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP # # Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression. # DEFAULT Hint == "CSLIP" Framed-Protocol = SLIP, Framed-Compression = Van-Jacobson-TCP-IP # # Default for SLIP: dynamic IP address, SLIP mode. # DEFAULT Hint == "SLIP" Framed-Protocol = SLIP # # Last default: rlogin to our main server. # #DEFAULT # Service-Type = Login-User, # Login-Service = Rlogin, # Login-IP-Host = shellbox.ispdomain.com # # # # Last default: shell on the local terminal server. # # # DEFAULT # Service-Type = Administrative-User # On no match, the user is denied access.

5.3. FICHIER WPA_SUPPLICANT.CONF (CLIENT) ctrl_interface=/var/run/wpa_supplicant ap_scan=1 network={ ssid="projetSAVIPANA" scan_ssid=1 key_mgmt=WPA-EAP

eap=PEAP identity="hmartin" password="123456" phase2="auth=MSCHAPV2" }

Page 65: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation
Page 66: Rapport de projet professionnel Source Address …blog.g6.asso.fr/wp-content/uploads/2011/03/Projet22_rapport_final.pdf · Rapport de projet professionnel Source Address Validation

66