D-LINK NETDEFEND User Manual

Manuel utilisateur

D-Link Corporation

Manuel utilisateur

D-Link Corporation Publié le 09/01/2008

Note de copyright. Cette publication, ainsi que les photographies, illustrations et logiciels qu’elle contient, est protégée par les lois internationales sur le copyright. Tous droits réservés. Le présent manuel ainsi que les informations qu’il contient ne peuvent être reproduits sans le consentement écrit de leur auteur.

Avis de non-responsabilité. Les informations contenues dans ce document peuvent être modifiées sans avis préalable. Le fabricant ne fait ni cas ni garantie dudit contenu et décline toute garantie de qualité marchande ou d’adéquation à tout usage particulier. Le fabricant se réserve le droit de faire une révision de cette publication et d’apporter des modifications ponctuelles audit contenu sans obligation de sa part d’en informer quiconque.

Limitation de responsabilité. EN AUCUN CAS D-LINK OU SES FOURNISSEURS NE SERONT TENUS POUR RESPONSABLES DES DOMMAGES DE TOUS TYPES (PAR EXEMPLE, PERTE DE BÉNÉFICES, RESTAURATION DU LOGICIEL, ARRÊT DE TRAVAIL, PERTE DE DONNÉES SAUVEGARDÉES OU TOUT AUTRE DOMMAGE COMMERCIAL OU PERTE) DÉCOULANT DE L’APPLICATION, DU MAUVAIS USAGE OU DE LA PANNE D’ UN PRODUIT D-LINK, MÊM E SI D-LINK EST INFORMÉ D E LA POSSIBILITÉ DE TELS DOMMAGES. DE PLUS, D-LINK NE POURRA ÊTRE TENU POUR RESPONSABLE DES RÉCLAMATIONS FAITES CONTRE LES CLIENTS PAR DES TIERS POUR TOUTE PERTE OU ENDOMMAGEMENT. D- LINK NE SERA EN AUCUN CAS TENU POUR RESPONSABLE DES DOMMAGES DÉPASSANT LE MONTANT VERSÉ PAR L’UTILISATEUR FINAL À D-LINK POUR LE PRODUIT.

Table des matières

Préface ................................................................................................................................................... xi

1. Présentation du produit....................................................................................................................... 1

À propos de D-Link NetDefendOS............................................................................................... 1

L’architecture NetDefendOS ........................................................................................................ 2

Une architecture basée sur l’état.......................................................................................... 2

Blocs logiques de NetDefendOS......................................................................................... 3

Flux de paquets de base....................................................................................................... 3

Flux de paquets du moteur d’état de NetDefendOS...................................................................... 5

2. Gestion et maintenance ...................................................................................................................... 9

Gestion de NetDefendOS ............................................................................................................. 9

Présentation ........................................................................................................................ 9

Comptes administrateur par défaut ..................................................................................... 9

Interface de ligne de commande ......................................................................................... 9

L’interface utilisateur Web ................................................................................................. 11

Utilisation des configurations ............................................................................................. 14

Événements et consignation ......................................................................................................... 19

Présentation ........................................................................................................................ 19

Messages d’événements ..................................................................................................... 19

Répartition des messages d’événements ............................................................................. 20

Comptabilisation RADIUS .......................................................................................................... 22

Présentation ........................................................................................................................ 22

Messages de comptabilisation RADIUS ............................................................................. 22

Messages de comptabilisation d’attente ............................................................................. 24

Activation de la fonction de comptabilisation RADIUS .................................................... 24

Sécurité de comptabilisation RADIUS ............................................................................... 25

Comptabilisation RADIUS et haute disponibilité ............................................................... 25

Serveurs sans réponse ......................................................................................................... 25

Comptabilisation et interruption système ........................................................................... 25

Limitations avec NAT ........................................................................................................ 25

Surveillance .................................................................................................................................. 26

Surveillance SNMP ............................................................................................................ 26

Maintenance ................................................................................................................................. 27

Mécanisme de mise à jour automatique .............................................................................. 27

Configuration des sauvegardes et des restaurations ............................................................ 28

Réinitialisation des paramètres usine par défaut ................................................................. 28

3. Fondamentaux ................................................................................................................................... 30

Carnet d’adresses ......................................................................................................................... 30

Présentation ........................................................................................................................ 30

Adresses IP ......................................................................................................................... 30

Adresses Ethernet ............................................................................................................... 31

Groupes d’adresses ............................................................................................................. 32

Objets Address générés automatiquement .......................................................................... 32

Services ........................................................................................................................................ 32

Présentation ........................................................................................................................ 32

Services reposant sur les protocoles TCP et UDP .............................................................. 34

Services ICMP .................................................................................................................... 36

Services de Protocole IP personnalisés ............................................................................... 37

Interfaces ...................................................................................................................................... 37

Présentation ........................................................................................................................ 37

Ethernet .............................................................................................................................. 39

VLAN ................................................................................................................................. 40

PPPoE ................................................................................................................................. 42

Tunnels GRE ...................................................................................................................... 43

Groupes d’interfaces ........................................................................................................... 46

ARP .............................................................................................................................................. 46

Présentation ........................................................................................................................ 47

iii

ARP dans NetDefendOS .................................................................................................... 47

Cache ARP ......................................................................................................................... 47

Entrées ARP statiques et publiées ...................................................................................... 48

Paramètres ARP avancés .................................................................................................... 49

L’ensemble de règles IP ............................................................................................................... 50

Règles de sécurité ............................................................................................................... 50

Évaluation des règles IP ..................................................................................................... 52

Actions des règles IP .......................................................................................................... 52

Modification des entrées de l’ensemble de règles IP .......................................................... 53

Programmation ............................................................................................................................. 54

Certificats X.509 .......................................................................................................................... 55

Présentation ........................................................................................................................ 55

Certificats X.509 dans NetDefendOS ................................................................................. 56

Configuration de la date et de l’heure .......................................................................................... 57

Paramètres de date et heure généraux ................................................................................. 57

Serveurs horaires ................................................................................................................ 58

Recherche DNS ............................................................................................................................ 61

4. Routage............................................................................................................................................... 62

Présentation................................................................................................................................... 62

Routage statique ........................................................................................................................... 62

Principes de base du routage ............................................................................................... 62

Routage statique ................................................................................................................. 63

Basculement de route .......................................................................................................... 66

Proxy ARP .......................................................................................................................... 68

Routage basé sur des règles .......................................................................................................... 68

Présentation ........................................................................................................................ 68

Tables de routage basées sur des règles .............................................................................. 69

Règles de routage ............................................................................................................... 69

Sélection de la table de routage basée sur des règles .......................................................... 69

Le paramètre Ordering ........................................................................................................ 70

Routage dynamique ...................................................................................................................... 73

Présentation du routage dynamique .................................................................................... 73

OSPF .................................................................................................................................. 74

Règles de routage dynamique ............................................................................................. 77

Routage multidiffusion ................................................................................................................. 79

Présentation ........................................................................................................................ 79

Transfert multidiffusion avec règle SAT Multiplex ........................................................... 80

Configuration IGMP ........................................................................................................... 84

Mode transparent .......................................................................................................................... 89

Présentation du mode transparent ....................................................................................... 89

Comparaison avec le mode routage .................................................................................... 89

Mise en œuvre du mode transparent ................................................................................... 90

Activation du mode transparent .......................................................................................... 90

Haute disponibilité avec mode transparent ......................................................................... 91

Scénarios de mode transparent ........................................................................................... 91

5. Services DHCP .................................................................................................................................. 97

Présentation .................................................................................................................................. 97

Serveurs DHCP ............................................................................................................................ 97

Attribution DHCP statique ........................................................................................................... 98

Relais DHCP ................................................................................................................................ 99

Groupes IP ................................................................................................................................... 100

6. Mécanismes de sécurité ..................................................................................................................... 103

Règles d’accès .............................................................................................................................. 103

Introduction ........................................................................................................................ 103

Usurpation d’IP .................................................................................................................. 103

Paramètres des règles d’accès ............................................................................................. 103

Passerelles ALG (Application Layer Gateway) ........................................................................... 104

Présentation ........................................................................................................................ 105

HTTP .................................................................................................................................. 105

FTP ..................................................................................................................................... 107

Manuel utilisateur

TFTP ................................................................................................................................... 113

SMTP .................................................................................................................................. 113

POP3 ................................................................................................................................... 118

SIP ...................................................................................................................................... 119

H.323 .................................................................................................................................. 122

Filtrage de contenu Web .............................................................................................................. 136

Présentation ........................................................................................................................ 136

Traitement du contenu actif ................................................................................................ 136

Filtrage de contenu statique ................................................................................................ 137

Filtrage de contenu Web dynamique .................................................................................. 139

Analyse antivirus .......................................................................................................................... 148

Présentation ........................................................................................................................ 148

Mise en œuvre .................................................................................................................... 148

Activation de l’analyse antivirus ........................................................................................ 149

La base de données des signatures ...................................................................................... 149

Souscription au service antivirus de D-Link ....................................................................... 149

Options de l’antivirus ......................................................................................................... 149

Prévention et détection des intrusions .......................................................................................... 152

Présentation ........................................................................................................................ 152

Disponibilité de l’IDP sur les modèles D-Link ................................................................... 153

Règles IDP .......................................................................................................................... 155

Prévention des attaques de type insertion/évasion .............................................................. 155

Filtrage par motif IDP ......................................................................................................... 156

Groupes de signatures IDP ................................................................................................. 157

Actions IDP ........................................................................................................................ 158

Récepteur de journaux SMTP pour les événements IDP .................................................... 158

Attaques de déni de service .......................................................................................................... 161

Présentation ........................................................................................................................ 161

Mécanismes d’attaque de déni de service ........................................................................... 161

Les attaques Ping of Death et Jolt ....................................................................................... 162

Les attaques de chevauchement de fragmentation : Teardrop, Bonk, Boink et Nestea ...... 162

Les attaques Land et LaTierra ............................................................................................ 162

L’attaque WinNuke ............................................................................................................ 163

Les attaques d’amplification : Smurf, Papasmurf, Fraggle ................................................. 163

Les attaques d’inondation TCP SYN .................................................................................. 164

L’attaque Jolt2 .................................................................................................................... 164

Les attaques de déni de service distribué ............................................................................ 165

Blacklisting des hôtes et réseaux .................................................................................................. 165

7. Traduction d’adresses ........................................................................................................................ 167

NAT dynamique ........................................................................................................................... 167

Groupes NAT ............................................................................................................................... 169

Traduction d’adresses statique ..................................................................................................... 171

Traduction d’une adresse IP unique (1:1) ........................................................................... 171

Traduction d’adresses IP multiples (M:N) .......................................................................... 176

Mappages tous-un (N:1) ..................................................................................................... 178

Traduction de port .............................................................................................................. 179

Protocoles gérés par la SAT ............................................................................................... 179

Multiples correspondances de règles SAT .......................................................................... 179

Règles SAT et FwdFast ...................................................................................................... 180

8. Authentification de l’utilisateur ......................................................................................................... 183

Présentation .................................................................................................................................. 183

Configuration de l’authentification .............................................................................................. 183

Résumé du paramétrage ...................................................................................................... 183

La base de données locale .................................................................................................. 184

Serveurs d’authentification externes ................................................................................... 184

Règles d’authentification .................................................................................................... 184

Processus d’authentification ............................................................................................... 185

Authentification HTTP ....................................................................................................... 186

9. VPN ................................................................................................................................................... 191

Présentation .................................................................................................................................. 191

Manuel utilisateur

La nécessité des VPN ......................................................................................................... 191

Chiffrage VPN .................................................................................................................... 191

Planification VPN ............................................................................................................... 191

Distribution de clés ............................................................................................................. 192

Guide de démarrage rapide VPN ................................................................................................. 192

LAN-LAN IPsec avec clés pré-partagées ........................................................................... 192

Clients itinérants IPsec avec clés pré-partagées .................................................................. 194

Clients itinérants IPsec avec certificats .............................................................................. 195

Clients itinérants L2TP avec clés pré-partagées ................................................................. 195

Clients itinérants L2TP avec certificats .............................................................................. 197

Clients itinérants PPTP ....................................................................................................... 198

Dépannage VPN ................................................................................................................. 199

IPsec ............................................................................................................................................. 200

Présentation ........................................................................................................................ 200

Protocole d’échange de clés par Internet (IKE) .................................................................. 201

Authentification IKE .......................................................................................................... 206

Protocoles IPsec (ESP/AH) ................................................................................................ 207

Franchissement NAT .......................................................................................................... 208

Listes de propositions ......................................................................................................... 209

Clés pré-partagées .............................................................................................................. 210

Listes d’identification ......................................................................................................... 211

Tunnels IPsec ............................................................................................................................... 213

Présentation ........................................................................................................................ 213

Tunnels LAN-LAN avec clés pré-partagées ....................................................................... 213

Clients itinérants ................................................................................................................. 213

Recherche de CRL depuis un serveur LDAP alternatif ...................................................... 219

PPTP/L2TP .................................................................................................................................. 219

PPTP ................................................................................................................................... 220

L2TP ................................................................................................................................... 221

10. Gestion du trafic .............................................................................................................................. 226

Mise en forme du trafic ................................................................................................................ 226

Introduction ........................................................................................................................ 226

Mise en forme du trafic dans NetDefendOS ....................................................................... 226

Limite simple de bande passante ........................................................................................ 228

Limite de la bande passante dans les deux directions ......................................................... 229

Création de limites différenciées avec des chaînes ............................................................. 230

Priorités .............................................................................................................................. 231

Garanties ............................................................................................................................. 232

Garanties différenciées ....................................................................................................... 23 3

Groupes .............................................................................................................................. 234

Recommandations .............................................................................................................. 235

Récapitulatif de la mise en forme du trafic ......................................................................... 237

Règles aux seuils .......................................................................................................................... 237

Présentation ........................................................................................................................ 237

Limite du taux de connexion / du nombre total de connexions .......................................... 238

Groupement ........................................................................................................................ 238

Actions des règles ............................................................................................................... 238

Actions multiples ................................................................................................................ 238

Connexions dispensées ....................................................................................................... 238

Règles aux seuils et ZoneDefense ...................................................................................... 238

Fonction de « blacklisting » des règles aux seuils .............................................................. 238

Équilibrage du volume de trafic du serveur ................................................................................. 239

Présentation ........................................................................................................................ 239

Identification des serveurs .................................................................................................. 240

Mode de répartition de la charge ........................................................................................ 240

Algorithme de répartition ................................................................................................... 241

Surveillance de l'état des serveurs ...................................................................................... 243

Règles SLB_SAT ............................................................................................................... 243

11. Haute disponibilité ........................................................................................................................... 247

Présentation .................................................................................................................................. 247

Manuel utilisateur

Mécanismes HA ........................................................................................................................... 247

Configuration de la fonction HA .................................................................................................. 248

Configuration matérielle ..................................................................................................... 249

Configuration de NetDefendOS ......................................................................................... 250

Vérification du fonctionnement du cluster ......................................................................... 250

Problèmes liés à la fonction HA ................................................................................................... 251

12. ZoneDefense .................................................................................................................................... 253

Présentation .................................................................................................................................. 253

Switches ZoneDefense ................................................................................................................. 253

Fonctionnement de ZoneDefense ................................................................................................. 253

SNMP ................................................................................................................................. 253

Règles avec seuil ................................................................................................................ 254

Blocage manuel et listes d'exclusions ................................................................................. 254

Limites ................................................................................................................................ 256

13. Paramètres avancés .......................................................................................................................... 257

Paramètres IP ............................................................................................................................... 257

Paramètres TCP ............................................................................................................................ 258

Paramètres ICMP ......................................................................................................................... 263

Paramètres ARP ........................................................................................................................... 263

Paramètres de l'inspection dynamique ......................................................................................... 265

Expiration des délais de connexion .............................................................................................. 267

Limites de taille par protocole ...................................................................................................... 268

Paramètres de fragmentation ........................................................................................................ 270

Paramètres de réassemblage des fragments locaux ...................................................................... 273

Paramètres DHCP ........................................................................................................................ 273

Paramètres des relais DHCP (DHCPRelay) ................................................................................. 274

Paramètres du serveur DHCP (DHCPServer ) .............................................................................. 275

Paramètres IPsec .......................................................................................................................... 275

Paramètres de consignation .......................................................................................................... 276

Paramètres de synchronisation temporelle ................................................................................... 277

Paramètres PPP ............................................................................................................................ 278

Paramètre du moniteur matériel ................................................................................................... 278

Paramètres de réassemblage des paquets ..................................................................................... 279

Autres paramètres ........................................................................................................................ 280

A. Abonnement aux mises à jour de sécurité ......................................................................................... 281

B. Groupes de signatures IDP ................................................................................................................ 283

C. Types de fichiers MIME vérifiés ...................................................................................................... 287

D. La structure OSI ................................................................................................................................ 291

E. Bureaux internationaux de D-Link .................................................................................................... 292

Index alphabétique ................................................................................................................................. 294

Manuel utilisateur

vii

Liste des figures

1.1. Schéma du flux de paquets Partie I ................................................................................................. 1

1.2. Schéma du flux de paquets Partie II ................................................................................................ 6

1.3. Schéma du flux de paquets Partie III .............................................................................................. 8

3.1. Exemple de cas de figure GRE ....................................................................................................... 30

4.1. Scénario de basculement de route pour un accès ISP ..................................................................... 62

4.2. Liens virtuels exemple 1 ................................................................................................................. 66

4.3. Liens virtuels exemple 2 ................................................................................................................. 76

4.4. Transfert multidiffusion sans traduction d’adresses ....................................................................... 77

4.5. Transfert multidiffusion avec traduction d’adresses ....................................................................... 81

4.6. Surveillance multicast ..................................................................................................................... 83

4.7. Proxy de multidiffusion .................................................................................................................. 85

4.8. Scénario 1 du mode transparent ...................................................................................................... 85

4.9. Scénario 2 du mode transparent ...................................................................................................... 91

6.1. Filtrage SPAM DNSBL .................................................................................................................. 111

6.2. Flux de filtrage de contenu dynamique ........................................................................................... 133

6.3. Mise à jour de la base de données IDP ........................................................................................... 140

9.1. Le protocole AH ............................................................................................................................. 191

9.2. Le protocole ESP ............................................................................................................................ 207

10.1. Ensemble de règles des tuyaux appliqué au flux de paquets des tuyaux ...................................... 226

10.2. Les huit priorités de tuyau ............................................................................................................ 228

10.3. Priorités de tuyau minimum et maximum ..................................................................................... 231

10.4. Trafic groupé par adresses IP ........................................................................................................ 232

10.5. Exemple de configuration de l'équilibrage du volume de trafic du serveur .................................. 235

10.6. Connexions provenant de trois clients .......................................................................................... 240

10.7. Mode « persistance » et algorithme Round-Robin ........................................................................ 242

10.8. Mode « persistance » et algorithme Connection Rate (Taux de connexion) ................................. 242

11.1. Configuration HA ......................................................................................................................... 247

D.1. Les 7 couches du modèle OSI ........................................................................................................ 291

viii

Liste des exemples

1. Exemple de notation .......................................................................................................................... xi

2.1. Autorisation de l’accès SSH distant ................................................................................................ 10

2.2. Activation de la gestion HTTPS distante ........................................................................................ 14

2.3. Liste des objets de configuration .................................................................................................... 15

2.4. Affichage d’un objet de configuration ............................................................................................ 15

2.5. Modification d’un objet de configuration ....................................................................................... 16

2.6. Ajout d’un objet de configuration ................................................................................................... 17

2.7. Suppression d’un objet de configuration ........................................................................................ 17

2.8. Annulation de la suppression d’un objet de configuration .............................................................. 17

2.9. Affichage de la liste des objets de configuration ............................................................................ 18

2.10. Activation et confirmation d’une configuration ............................................................................ 18

2.11. Activation de l’enregistrement sur un hôte Syslog ....................................................................... 21

2.12. Envoi des interruptions SNMP à un récepteur d’interruptions SNMP ......................................... 22

2.13. Activation de la surveillance SNMP ............................................................................................. 27

2.14. Configuration des sauvegardes et des restaurations ...................................................................... 28

2.15. Réinitialisation complète .............................................................................................................. 28

3.1. Ajout d’un hôte IP .......................................................................................................................... 30

3.2. Ajout d’un réseau IP ....................................................................................................................... 31

3.3. Ajout d’une plage d’adresses IP ..................................................................................................... 31

3.4. Suppression d’un objet Address ..................................................................................................... 31

3.5. Ajout d’une adresse Ethernet .......................................................................................................... 31

3.6. Référencement des services disponibles ......................................................................................... 33

3.7. Visualisation d’un service spécifique ............................................................................................. 33

3.8. Ajout d’un Service TCP/UDP ......................................................................................................... 35

3.9. Ajout d’un service de protocole IP ................................................................................................. 37

3.10. Activation de DHCP ..................................................................................................................... 40

3.11. Définition d’un VLAN ................................................................................................................. 41

3.12. Configuration d’un client PPPoE sur l’interface WAN avec routage du trafic via PPPoE ........... 43

3.13. Création d’un groupe d’interfaces ................................................................................................ 46

3.14. Affichage du cache ARP .............................................................................................................. 47

3.15. Alignement du cache ARP ............................................................................................................ 48

3.16. Définition d’une entrée ARP statique ........................................................................................... 48

3.17. Configuration d’une règle planifiée .............................................................................................. 54

3.18. Chargement d’un certificat X.509 ................................................................................................ 56

3.19. Association de certificats X.509 à des tunnels IPsec .................................................................... 57

3.20. Configuration de la date et de l’heure actuelles ............................................................................ 57

3.21. Configuration du fuseau horaire ................................................................................................... 58

3.22. Activer le passage à l’heure d’été ................................................................................................. 58

3.23. Activation de la synchronisation du temps via SNTP ................................................................... 59

3.24. Déclenchement manuel de la synchronisation du temps ............................................................... 60

3.25. Modification de la valeur de réglage maximale ............................................................................ 60

3.26. Forcer la synchronisation du temps .............................................................................................. 60

3.27. Activation du serveur D-Link NTP .............................................................................................. 61

3.28. Configuration des serveurs DNS .................................................................................................. 61

4.1. Affichage de la table de routage ..................................................................................................... 64

4.2. Affichage des routes du noyau ........................................................................................................ 65

4.3. Création d’une table de routage basée sur des règles ...................................................................... 71

4.4. Création de la route ......................................................................................................................... 71

4.5. Configuration du routage basé sur des règles ................................................................................. 72

4.6. Importation de routes d’un AS OSPF vers la table de routage principale ...................................... 78

4.7. Exportation des routes par défaut vers un AS OSPF ...................................................................... 79

4.8. Transfert de trafic multidiffusion avec règle SAT multiplex .......................................................... 81

4.9. Transfert multidiffusion avec traduction d’adresses ....................................................................... 83

4.10. IGMP sans traduction d’adresses .................................................................................................. 85

4.11. Configuration de if1 ...................................................................................................................... 87

4.12. Configuration d’if2 et traduction de gr oupe ................................................................................. 88

4.13. Scénario 1 : paramétrage du mode transparent ............................................................................. 91

4.14. Scénario 2 : paramétrage du mode transparent ............................................................................. 93

5.1. Configuration d’un serveur DHCP ................................................................................................. 97

5.2. Vérification de l’état d’un serveur DHCP ...................................................................................... 98

5.3. Configuration du mode DHCP statique .......................................................................................... 98

5.4. Configuration d’un relais DHCP .................................................................................................... 99

5.5. Création d’un groupe IP .................................................................................................................. 101

6.1. Configuration d’une règle d’accès .................................................................................................. 104

6.2. Protection d’un serveur FTP avec une passerelle ALG .................................................................. 107

6.3. Protection des clients FTP .............................................................................................................. 110

6.4. Protection des téléphones situés derrière les firewalls D-Link ....................................................... 124

6.5. H.323 avec adresses IP privées ....................................................................................................... 125

6.6. Deux téléphones situés derrière des firewalls D-Link différents .................................................... 126

6.7. Utilisation d’adresses IP privées ..................................................................................................... 128

6.8. H.323 avec portier .......................................................................................................................... 129

6.9. H.323 avec un portier et deux firewalls D-Link ............................................................................. 131

6.10. Utilisation du H.323 ALG en entreprise ....................................................................................... 132

6.11. Configuration des entreprises distantes pour H.323 ..................................................................... 135

6.12. Autoriser la passerelle H.323 à s’enregistrer auprès du portier .................................................... 135

6.13. Élimination des applets Java et ActiveX ...................................................................................... 137

6.14. Configuration des listes blanches et noires ................................................................................... 138

6.15. Activation du filtrage de contenu Web dynamique ...................................................................... 141

6.16. Activation du mode Audit ............................................................................................................ 142

6.17. Reclassement d’un site bloqué ...................................................................................................... 143

6.18. Activation de l’analyse antivirus .................................................................................................. 151

6.19. Configuration d’un récepteur de journaux SMTP ......................................................................... 158

6.20. Configuration d’un IDP pour un serveur de messagerie ............................................................... 159

7.1. Ajout d’une règle NAT ................................................................................................................... 168

7.2. Utilisation de pools NAT ................................................................................................................ 170

7.3. Autorisation du trafic vers un serveur Web protégé pa r une DMZ ................................................. 172

7.4. Autorisation du trafic vers un serveur Web sur un réseau interne .................................................. 174

7.5. Traduction du trafic en direction de plusieurs serveurs Web protégés ........................................... 176

8.1. Création d’un groupe utilisateurs d’authentification ...................................................................... 187

8.2. Configuration de l’authentification utilisateur pour l’accès au Web .............................................. 188

8.3. Configuration d’un serveur RADIUS ............................................................................................. 189

9.1. Utilisation d’une liste de propositions ............................................................................................ 209

9.2. Utilisation d’une clé pré-partagée ................................................................................................... 210

9.3. Utilisation d’une liste d’identification ............................................................................................ 211

9.4. Configuration d’un tunnel VPN basé sur une clé pré-partagée pour les clients itinérants .............. 214

9.5. Configuration d’un tunnel VPN basé sur un certificat autosigné pour les clients itinérants ........... 215

9.6. Configuration d’un tunnel VPN basé sur un certificat émis par un serveur AC pour

les clients itinérants ............................................................................................................................... 216

9.7. Configuration du mode de configuration ........................................................................................ 218

9.8. Utilisation du mode de configuration avec des tunnels IPsec ......................................................... 218

9.9. Configuration d’un serveur LDAP ................................................................................................. 219

9.10. Configuration d’un serveur PPTP ................................................................................................. 220

9.11. Configuration d’un serveur L2TP ................................................................................................. 221

9.12. Configuration d’un tunnel L2TP ................................................................................................... 222

10.1. Application d’une limite simple de bande passante ...................................................................... 228

10.2. Limite de la bande passante dans les deux directions ................................................................... 229

10.3. Configuration de la fonction SLB ................................................................................................. 244

12.1. Un scénario ZoneDefense simple ................................................................................................. 254

User Manual

Préface

Public visé

Le présent guide de référence s’adresse aux administrateurs responsables de la configuration et de la gestion des Firewalls D-Link qui fonctionnent s o us l e sy st ème d’exploitation NetDefendOS. Ce guide suppose que le lecteur possède certaines connaissances de base sur les réseaux et leur système de sécurité.

Structure du texte et normes

Ce texte est subdivisé en chapitres et sous-sections. Les sous-chapitres numérotés sont consultables dans la table des matières au début du docum ent. U n index est incl us à la fi n du doc um ent, ré pertori ant l es catégorie s par o rdre alphabétique.

En cliquant sur un lien « Voir chapitre/section » (tel que : voir) contenu dans le corps du texte, vous pouvez directement accéder à la partie en question.

Le texte pouvant apparaître dans l’interface utilisateur du produit est désigné en gras. Lorsqu’un term e est mis en valeur ou introduit pour la première fois, il peut apparaître en italique.

Une console d’interaction dans le corps du texte et en dehors d’un exemple apparaîtra dans un encadré au fond gris.

En cliquant sur une adresse Internet dans le texte, vous pouvez ouvrir l’URL spécifiée dans une nouvelle fen être du navigateur (certains systèmes ne le permettent pas). Exemple : http://www.dlink.com.

Exemples

Les exemples dans le texte sont indiqués par l’en-tête « Exemple » et apparaissent sur fond gris, comme indiqué ci-dessous. Ils contiennent un exemple de l’interface de ligne de commande et/ou un exemple d’interface Web selon le cas. (Le « CLI Reference Guide » (Guide de référence sur l’interface de ligne de commande) associé fournit des informations sur toutes les commandes de l’interface).

Exemple 1. Exemple de notation

Les informations sur ce que veut illustrer l’exemple sont consultables ici, accompagnées parfois d’une image d’explication.

Interface de ligne de commande

L’exemple d’interface de ligne de commande a pparaît ici . L’invite de commande apparaît en premier, suivie de la commande :

gw-world:/> somecommand someparameter=somevalue

Interface Web

Les exemples d’actions sur l’interface Web sont présentés ici. De m anière générale, une liste numérotée m ontrant les éléments de l’arborescence sur la gauche de l’interface, dans la barre de menu ou dans un menu flottant doit être ouverte, suivie des informations sur les données qui doivent être saisies :

o Sélectionnez Élément X > Élément Y > Élément Z

Entrez :

DonnéeÉlément1 : donnéevaleur1

DonnéeÉlément2 : valeurdonnée2

Préface

Contenu important

Les sections spéciales du texte auxquelles le lecteur doit prêter une attention particulière sont indiquées par des icônes à gauche de la page, suivies d’un petit paragraphe en italique. Voici les différents types de sections disponibles avec l’objectif correspondant :

Remarque

Elle indique une information complémentaire en relation avec le texte qui précède. Elle peut concerner un sujet qui est mis en relief ou qui n’est pas évident ou énoncé explicitement dans le texte précédent.

Conseil

Il indique une information non cruciale, qu’il est utile de connaître dans certains cas mais qu’il n’est pas nécessaire de lire.

Attention

Elle indique les passages où le lecteur doit f aire attention à ses act ions, un manque de précaution pouva nt engendrer une situation indésirable.

Important

Cette section marque un point essentiel que le lecteur doit lire et comprendre.

Avertissement

La lecture de ce passage est essentielle, car l’utilisateur doit être conscient que des problèmes graves peuvent survenir si certaines actions sont ou ne sont pas accomplies.

xii

Chapitre 1. Présentation du produit

Le présent chapitre décrit les principales fonctionnalités de NetDefendOS.

À propos de D-Link NetDefendOS

D-Link NetDefendOS est le firmware, le moteur logiciel qui gère et contrôle tous les produits Firewall D-Link. Conçu comme un système d’exploitation de sécurité réseau, NetDefendOS se distingue par un haut débit et une

grande fiabilité en plus d’un contrôle très précis. Contrairement aux produits reposant sur des systèmes d’exploitation standard (Unix ou Microsoft Windows), NetDefendOS s’intègre en transparence à tous les sous-systèmes, permet de surveiller de manière approfondie toutes les fonctionnalités tout en réduisant la zone d’attaque potentielle, ce qui lui permet d’être moins exposé aux menaces de sécurité.

Du point de vue de l’administrateur, NetDefendOS repose sur une approche conceptuelle visant à visualiser les opérations au moyen d’ensemble de blocs logiques (ou objets) qui permettent de configurer le produit de mille-et-une manières. Ce co ntrôle t rès p récis perm et à l ’admi nistrateur de ré pondre aux besoins des ca s de figure les plus exigeants en matière de sécurité réseau.

NetDefendOS est un système d’exploitation de réseau puissant doté de nombreuses fonctionnalités. La liste ci-dessous présente les principales fonctionnalités :

Routage IP NetDefendOS propose de nombreuses options pour le routage IP,

notamment le routage statique, le routage dynamique, ainsi que des fonctions de routage multidiffusion. En outre, NetDefendOS p ropose des fonctionnalités telles que les LAN virtuels, la surveillance du routage, le proxy-ARP et la transparence. Pour plus d’informations, reportez-vous au Chapitre 4, Routage.

Traduction d’adresses Pour des raisons de fonctionnalité et de sécurité, NetDefendOS propose

une fonction de traduction d’a dresses reposant sur de s règles. La traductio n d’adresses dynamiques (NAT) ainsi que la traduction d’adresses statiques (SAT) est prise en charge et satisfait la plupart des types de besoins en matière de traduction d’adresses. Nous aborderons cette fonctionnalité dans le Chapitre 7, Traduction d'adresses.

Firewalls Le cœur du produit NetDefendOS propose des firewalls basés sur le

filtrage dynamique pour les protocoles courants tels que TCP, UDP et ICMP. En tant qu’administrateur, vous pouvez définir des stratégies détaillées en matière de firewalls, reposant sur les réseaux et interfaces source et de destination, le protocole, les ports, les authentifiants de l’utilisateur, la période de la journée et bien d’autres éléments. La section

intitulée « Ensemble de règles IP aux firewalls de NetDefendOS.

Prévention et détection des intrusions Pour atténuer les attaques de la couche d’application qui exploitent des

vulnérabilités dans les services et les applications, NetDefendOS propose un puissant moteur de prévention et de détection des intrusions (Intrusion Detection and Prevention). Le moteur IDP repose sur des règles. Il peut exécuter une analyse et une détection très performante des attaques et bloquer ou mettre sur liste noire les hôtes responsables des attaques, si nécessaire. Pour plus de renseignements sur les capacités IDP de NetDefendOS, reportez-vous à la section intitulée « Prévention et

détection des intrusions

» décrit comment utiliser les aspects liés

».

Antivirus NetDefendOS intègre une fonctionnalité de passerelle anti-virus. Le trafic

qui transite par la passerelle peut être soumis à une analyse antivirus en profondeur et les hôtes responsables des attaques peuvent être, au choix,

Filtrage de contenu Web NetDefendOS propose divers mécanismes pour le filtrage du contenu Web

Réseau privé virtuel (Virtual Private Network) Un périphérique qui exécute NetDefendOS est

Gestion du trafic NetDefendOS prend en charge la mise en forme du trafic, les règles aux

Présentation du produit

bloqués ou mis sur liste noire. La section intitulée « Analyse antivirus » fournit des informations complémentaires sur l’utilisation de la fonctionnalité antivirus intégrée.

considéré comme inapproprié d’après vos règles d’utilisatio n du Web. Le contenu Web peut être bloqué selon la catégorie, les objets malveillants enlevés et les sites Web mis sur liste blanche ou noire, selon de multiples règles. Pour plus d’informations, reportez-vous à la section intitulée « Filtrage de contenu Web ».

particulièrement approprié pour participer à un réseau privé virtuel. NetDefendOS prend en charge simultanément le VPN IPsec, L2TP et PPTP ; il peut tenir le rôle de serveur ou de client pour tous les types de VPN et peut fournir des règles de séc urité indivi duelles pour chaque tun nel VPN. Le réseau privé virtuel est traité en détail dans le chapitre 9, VPN.

seuils et les fonctionnalités d’équilibrage du volume de trafic du serveur, ce qui en fait l’outil idéal pour la gestion du trafic. La fonctionnalité de mise en forme du trafic permet une limitation et un équilibrage très précis de la bande passante ; les règles aux seuils permettent de mettre en œuvre différents types de seuils pour avertir ou limiter le trafic du réseau là où c’est nécessaire et l’équilibrage du volume de trafic du serveur permet au périphérique qui exécute NetDefendOS de distribuer les charges de réseau sur plusieurs hôtes. Le chapitre 10, Gestion du trafic, fournit des informations plus détaillées sur les différentes capacités de gestion du trafic.

Opérations et maintenance Pour faciliter la gestion d’un périphérique NetDefendOS, le contrôle

administrateur est activé à l’aide d’une interface utilisateur de type Web ou par l’interface de ligne de commande. De plus, NetDefendOS fournit des fonctions très détaillées de consignation et de suivi d’événements ainsi que la prise en charge de la surveillance à l’aide de standards tels que SNMP. Pour plus d’informations, reportez-vous au chapitre 2, Gestion et Maintenance.

ZoneDefense Vous pouvez utiliser NetDefendOS pour contrôler les switches D-Link à

l’aide de la fonctionnalité ZoneDefense.

La lecture minutieuse de cette documentation vous permettra de tirer le meilleur parti de votre produit NetDefendOS. En plus de ce document, le lecteur devrait également consulter les volumes additionnels suivants :

NetDefendOS CLI Guide (guide NetDefendOS CLI) qui détaille toutes les commandes console NetDefendOS. NetDefendOS Log Reference Guide (guide de référence des consignations de NetDef endOS) qui d étaille tous

les messages du journal d’événements de NetDefendOS.

L’ensemble de ces documents forme la documentation indispensable pour le fonctionnement de NetDefendOS.

Remarque

La haute disponibilité, l’antivirus, le filtrage de contenu Web et ZoneDefense ne sont pas disponibles avec certains modèles, comme cela est précisé dans les chapitres qui se rapportent à ces fonctionnalités.

Présentation du produit

L’architecture NetDefendOS

Une architecture basée sur l’état

L’architecture NetDefendOS est centrée autour du concept de conne xio ns basée s s ur l ’ét at. Les route urs IP ou les switches traditionnels inspectent généralement tous les paquets et effectuent ensuite des décisions relatives au transfert des données selon les informations trouvées dans les en-têtes des paquets. Avec cette approche, les paquets sont transmis sans se préoccuper du contexte, ce qui évite toute possibilité d e détecter et d'analyser des protocoles complexes et renforce les règles de sécurité correspondantes. Inspection dynamique. NetDefendOS emploie une technique appelée inspection dynamique, ce qui signifie qu’il inspecte et transmet le trafic en se basant sur une seule connexion à la fois. NetDefendOS détecte lorsqu’une nouvelle connexion est établie et conserve une faible quantité d'informations ou d'états dans sa table d'état pendant la durée de cette connexion. Grâce à cette opération, NetDefendOS est capable de comprendre le contexte du trafic réseau, ce qui lui permet notamment d’effectuer une analyse du trafic en profondeur et d’appliquer la gestion de la bande passante.

L’approche d'inspection dynamique propose en outre des performances de débit élevées en plus de l’atout d’une conception hautement évolutive. Le sous-système NetDefendOS qui met en œuvre l’inspection dynamique sera parfois appelé moteur d’état NetDe fen d OS dan s la doc umentation.

Blocs logiques de NetDefendOS

Les blocs logiques de base de Net DefendOS sont les inte rfaces, les objets l ogiques ainsi q ue les différents t ypes de règles (ou ensembles de règles).

Interfaces. Les interfaces sont les passages pour le trafic réseau en direction ou en provenance du système. Sans interfaces, un système NetDefendOS n’a aucun moyen de recevoir ou d’envoyer du trafic. Différents types

d’interfaces sont pris en charge Les interfaces physiques correspondent aux ports Ether net physiques réels ; les sous-interfaces physiques incluent les interfaces VLAN et PPPoE, tandis que les interfaces tunnels sont utilisées pour recevoir et envoyer le trafic dans les tunnels VPN.

Symétrie d’interface. La conception de l'interface NetDefendOS est symétrique, ce qui signifie que les i nterfaces du périphérique ne sont pas fixées sur « l’extérieur non sécurisé » ou « l’intérieur sécurisé » d’une topologie réseau. La notion de contenu interne et externe doit être entièrement définie par l'administrateur.

Objets logiques. Les objets logiques peuvent être c onsi dérés c om me des blocs lo giques prédéfi nis desti nés à être utilisés par les ensembles de règles. Le carnet d’adresses, par exemple, contient des objets nommés qui représentent les adresses réseau et hôtes. Les services, qui représentent un protocole spécifique et des combinaisons de ports, constituent d’autres exemples d’objets logiques. Les objets de la passerelle ALG (Application Layer Gateway), utilisés pour définir des paramètres supplémentaires qui concernent des protocoles spécifiques tels que HTTP, FTP, SMTP et H.323, sont également importants.

Ensembles de règles NetDefendOS. Enfin, les règles définies par l’administrateur dans les différents ensembles de règles sont utilisées pour réellement mettre en œuvre les règles de sécurité de NetDefendOS. L'ensemble de

règles le plus indispensable est l’ensemble de règles IP, utilisé aussi bien pour définir la règle de filtrage de la couche 3 (IP) que pour réaliser la traduction d’adresses et l’équilibrage du volume de trafic du serveur. Les règles de mise en forme du trafic définissent la stratégie de gestion de la bande passante, les règles IDP contrôlent le comportement du moteur de prévention des intrusions, etc.

: les interfaces physiques, les sous-interfaces physiques et les interfaces tunnels.

Flux de paquets de base

Cette section décrit le flux de base dans le moteur d’état pour les paquets reçus et transmis par NetDefendOS. Veuillez noter que cette description est simplifiée et ne pourrait s’appliquer entièrement à tous les cas de figure. Le principe de base est toutefois valable pour toutes les applications.

Une trame Ethernet est reçue par l’une des interfaces Ethernet du système. La procédure de validation de la

trame Ethernet de base est effectuée et le paquet est ignoré si la trame n’est pas valide.

Présentation du produit

Le paquet est associé à une interface source. L’interface source est définie comme suit :

Si la trame Ethernet contient un ID de VLAN (identifiant de réseau virtuel), le système vérifie l’existence

d’une interface VLAN configurée possédant un ID de VLAN correspondant. S’il en détecte une, celle-ci devient l’interface source pour le paquet. Si aucune interface correspondante n’est trouvée, le paquet est ignoré et l’événement est consigné.

Si la trame Ethernet contient une charge utile PPP, le système vérifie l’existence d’une interface PPPoE

correspondante. S'il en trouve une, celle-ci devient l'interface source pour le paquet. Si aucune interface correspondante n’est trouvée, le paquet est ignoré et l’événement est consigné.

Dans tous les autres cas, l’interface Ethernet réceptrice devient l’interface source pour le paquet.

Le datagramme IP inclus dans le paquet est transmis au vérificateur de cohérence NetDefendOS. Le

vérificateur de cohérence effectue un certain nombre de tests pour véri fier que le paquet est sain, pa rmi lesquels la validation des totaux de contrôle, les indicateurs de protocoles, la longueur du paquet, etc. Si le test de cohérence échoue, le paquet est ignoré et l’événement est consigné.

NetDefendOS tente à présent de répertorier un e connexion existante en associant les paramètres du paquet entrant. Un certain nombre de paramètres sont utilisés lors de la tentative de correspondance, notamment l’interface source, les adresses IP source et de destination ainsi que le protocole IP.

Si aucune correspondance n’est trouvée, le système exécute un processus d’établissement de connexion comprenant les étapes suivantes, jusqu’à l’étape 9. Si une correspondance est détectée, le processus de transmission continue à l’étape 10

ci-dessous.

Les règles d’accès sont examinées pour déterminer si l'adresse I P source de la nouvel le connexi on est autori sée

sur l’interface reçue. Si aucune règle d’accès ne co rrespond, une rés olution de routage inverse est effectué e. En d’autres termes, une interface n’acceptera par défaut que les adresses IP sources appartenant aux réseaux routés par cette interface. Si les règles d’accès ou la résolution de routage inverse déterminent que l’IP source n' est pas valide, le paquet est ignoré et l’événement est consigné.

Un chemin de routage est établi en utilisant la table de routage appropriée. L’interface de destination pour la

connexion est à présent déterminée.

Les règles IP sont désormais inspectées dans le but de trouver une règle qui corresponde au paquet. Les

paramètres suivants font partie du processus de mise en correspondance :

Interfaces source et de destination

Réseau source et de destination Protocole IP (par exemple TCP, UDP, ICMP)

Ports TCP/UDP Types ICMP Point dans le temps faisant référence à une planification prédéfinie.

Si aucune correspondance ne peut être trouvée, le paquet est ignoré. Si une règle correspondant à la nouvelle connexion est trouvée, le paramètre « Action » de la règle détermine la

manière dont NetDefendOS exploitera cette connexion. Si l’action est « Drop » (Ignorer), le paquet est ignoré et l'événement est consigné en fonction des paramètres de consignation de la règle.

Si l’action est « Allow » (Autoriser), le paquet est autorisé à transiter sur le système. Un état correspondant est ajouté à la table de connexion pour mettre en correspondance les prochains paquets apparten ant à la même connexion. De plus, il se peut que l’objet de service qui correspondait au protocole et aux ports IP ait déjà contenu une référence à un objet de la passerelle ALG (Application Layer Gateway). Cette information est consignée dans l’état de manière à ce que NetDefendOS sache que le traitement des couches d’application devra être effectué sur la connexion.

Enfin, l’ouverture de la nouvelle connexion est consignée en fonction des paramètres de consignation de la règle.

Présentation du produit

Remarque

Il existe en réalité un certain nombre d’actions supplémentaires disponibles, telles que la traduction d’adresses et l’équilibrage de charge du serveur. Le concept de base qui co nsiste à interrompre et à autoriser le trafic ne change pas.

Les règles de détection et de prévention des int rusions (IDP) sont à présent évaluées d’une m anière comparable

aux règles IP. Si une correspondance est trouvée, les données IDP sont consignées dans l’état. Grâce à cette opération, NetDefendOS sait que l’analyse IDP est supposée être effectuée sur tous les paquets appartenant à cette connexion.

La règle de mise en forme du trafic et l’ensemble de règles aux seuils sont à présent inspectés. Si une

correspondance est trouvée, cette information est consignée dans l’état. Cela permettra une gestion c orrect e du trafic de la connexion.

Grâce aux informations stockées dans l’état, NetDefendOS sait à prése nt la manière dont il doit traiter le paquet

entrant :

Si l’information ALG existe ou si l'analyse IDP est sur le point d'être effectuée, la charge utile du paquet est

prise en charge par le sous-système de pseudo-rassemblement TCP, qui à son tour utilise les différentes passerelles ALG, les moteurs d'analyse de l a couche 7 et ainsi de suite, pour analyser ou transformer le trafic en profondeur.

Si le contenu du paquet est encapsulé (comme c'est le cas avec IPsec, L2TP/PPTP ou un autre type de

protocole de tunnelisation), alors les listes d’interfaces sont analysées pour rechercher une interface correspondante. Si une interface correspondante est détectée, le paquet est décapsulé et la charge utile (le texte brut) est renvoyée à NetDefendOS, l’interface source étant alors l’interface tunnel correspondante. En d’autres termes, le processus se poursuit à l’étape 3 ci-dessus.

Si les informations sur la gestion du trafic existent, le paquet peut être mis en file d’attente ou être soumis à

des actions liées à la gestion du trafic.

Finalement, le paquet sera transmis à l'interface de destination en fonction de l’état. Si l'interface de destination

est une interface tunnel ou une sous-interface physique , des traitements supplémentaires tels que le chiffrement ou l’encapsulation peuvent avoir lieu.

La section suivante fournit un ensemble de schémas qui illustrent le flux de paquets qui traversent NetDefendOS.

Flux de paquets du moteur d’état de NetDefendOS

Les schémas de cette section offrent un résu mé du flu x de paquets qui t raverse le moteur d’état de NetDefendOS. Les trois schémas suivants doivent être lus de manière consécutive.

Figure 1.1 Schéma du flux de paquets Partie I

Présentation du produit

Le flux de paquets se poursuit sur la page suivante.

Figure 1.2 Schéma du flux de paquets Partie II

Présentation du produit

Le flux de paquets se poursuit sur la page suivante.

Présentation du produit

Figure 1.3 Schéma du flux de paquets Partie III

Chapitre 2. Gestion et maintenance

Ce chapitre décrit les aspects relatifs à la gestion, à la maintenance et aux opérations sur NetDefendOS.

Gestion de NetDefendOS

Présentation

NetDefendOS est conçu pour apporter un haut niveau de perfo rmances et une grande fiabilité. Non seulement il fournit un vaste ensemble de fonctions, mais aussi il permet à l’administrateur de pleinement contrôler tous les détails du système. En d’autres termes, le produit peut être déployé dans les environnements les plus difficiles.

Une bonne compréhension de la manière de configurer NetDefendOS est cruciale pour la bonne utilisation du système. Pour cette raison, cette section présente de façon détaillée le sous-système de configuration et décrit la manière de travailler avec les multiples interfaces de gestion. Interfaces de gestion. NetDefendOS comprend les interfaces de gestion suivantes :

L’interface utilisateur Web L’interface utilisateur Web propose une interface de gestion graphique

conviviale et intuitive, accessible depuis un navigateur Web standard.

L’interface de ligne de commande L’interface de ligne de commande, accessible en local via un port console

série ou à distance via le protocole SSH (Secure Shell), propose le contrôle l e pl us p oi ntu de tous les paramètres de NetDefendOS.

Remarque

Microsoft Internet Explorer (versio n 6 ou su périeure), Firefox et Net scape (versi on 8 ou su périeure) s ont les navigateurs Web recommandés pour l’utilisation de l’interface utilisateur Web. D’autres navigateurs peuvent aussi convenir.

L’accès aux interfaces de gestion distante peut être contrôlé grâce à la stratégie de gestion distante. Ainsi, l’administrateur peut restreindre l’accès au réseau source, à l’interface source et aux authe ntifiants. Il est possible d’autoriser l’accès à l’interface Web par des administrateurs de certains réseaux et l’accès distant à l’interface de ligne de commande par un administrateur connecté à l’aide d’un tunnel IPSec spécifique.

Par défaut, l’accès à l’interface utilisateur Web est autorisé aux utilisateurs réseau connectés via l’interface LAN du firewall (pour les produits dotés de plusieurs interfaces LAN, LAN1 est l’interface par défaut).

Comptes administrateur par défaut

Par défaut, NetDefendOS a une base de données utilisateur locale : AdminUsers, avec un compte utilisateur prédéfini.

Nom d’utilisateur : admin. Mot de passe : admin. Ce compte a tous les droits administrateur de lecture/d’écriture.

Important

Pour des raisons de sécurité, il est recomm andé de modifier le m ot de passe du compte par défaut aussitôt que possible après connexion au firewall de D-Link.

Création de comptes. Des comptes utilisateur supplémentaires peuvent être créés le cas échéant. Les comptes peuvent appartenir soit au groupe des administrateurs (dans ce cas, ils ont tous les droits administrateur de lecture/d’écriture), soit au groupe des auditeurs (dans ce cas, ils n’ont que les droits de lecture).

Interface de ligne de commande

NetDefendOS contient une interface de ligne de commande pour les administrateurs qui préfèrent ou exigent une approche par ligne de commande, ou qui ont besoin d’un contrôle plus précis de la configuration du système.

L’interface de ligne de commande est disponible en local grâce au port console série ou à distance grâce au protocole SSH (Secure Shell).

L’interface de ligne de commande dispose d’un vaste ensemble de commandes qui permettent non seulement l’affichage et la modification des données de configuration, mais aussi l’affichage des données d’exécution et la réalisation des tâches de maintenance du système.

Cette section ne fait qu’un résumé de l’utilisation de l’interface de ligne de commande. Pour plus de précisions sur les lignes de commande, reportez-vous au CLI Reference Guide (Guide de référence sur l’interface de ligne de commande), fourni par D-Link. Console série pour l’accès à l’interface de ligne de commande. Le port console série est un port RS- 232 sur le firewall de D-Link, qui permet l’accès à l’interface de ligne de commande grâce à une connexion série sur un PC ou un terminal. Pour localiser le port console série du système D-Link, reportez-vous au Guide de démarrage rapide de D-Link.

Pour utiliser le port console, vous avez besoin des éléments suivants :

Gestion et maintenance

Un terminal ou un ordinateur avec un port série et la capacité d’émuler un terminal (par exemple, le logiciel

Hyper Terminal inclus dans certaines éditions de Microsoft Windows). Le port console série utilise les paramètres par défaut suivants : 9600 bits par seconde, sans parité, 8 bits de données, 1 bit d'arrêt.

Un câble RS-232 avec les connecteurs appropriés. Un câble RS-232 simulateur de modem est inclus dans le

pack.

Pour connecter un terminal au port console, suivez ces étapes :

Paramétrez le protocole du terminal selon la procédure précédemment décrite. Branchez l’un des connecteurs du câble RS-232 directement sur le port console du matériel. Branchez l’autre extrémité du câble au terminal ou au port série d’un ordinateur qui exécute le logiciel de

communication.

Appuyez sur la touche Entrée du terminal. L’invite de connexion de NetDefendOS devrait apparaître sur

l’écran du terminal.

Accès SSH à l’interface de ligne de commande. Le protocole SSH (Secure Shell) peut être utilisé pour accéder à l’interface de ligne de commande par le biais du réseau d’un hôte distant. Le SSH est un protocole utilisé à l’origine pour des communications sécurisées sur des réseaux non sécurisés, ce qui implique une forte authentification et l’intégrité des données. Une grande partie des clients SSH sont disponibles gratuitement pour presque toutes les plates-formes matérielles.

NetDefendOS est compatible avec la version 1, 1.5 et 2 du protocole SSH. L’accès SSH est contrôlé par la stratégie de gestion distante de NetDefendOS et désactivé par défaut.

Exemple 2.1. Autorisation de l’accès SSH distant

Cet exemple montre comment vous pouvez autoriser l’accès SSH distant depuis le réseau lannet grâce à une interface lan, en ajoutant une règle à la stratégie de gestion distante.

Interface de ligne de commande

gw-world:/> add RemoteManagement RemoteMgmtSSH ssh Network=lannet Interface=lan

LocalUserDatabase=AdminUsers

Interface Web

Sélectionnez System > Remote Mana gement > Add > Sec ure Shell Managem ent (Système > Gestion distante >

Ajouter > Gestion SSH). Saisissez le nom de la stratégie de gestion SSH distante (par exemple, ssh_policy).

Dans les listes déroulantes, sélectionnez les options suivantes :

User Database (Base de données utilisateur) : AdminUsers (Administrateurs)

Gestion et maintenance

Interface : lan Network (Réseau) : lannet

Cliquez sur OK.

Connexion à l’interface de ligne de commande. Quand l’accès à l’interface de ligne de commande a été établi pour NetDefendOS grâce à une console série ou un client SSH, l’administrateur devra s’identifier sur le système avant de pouvoir exécuter n’importe quelle ligne de commande. Cette étape d’authentification est nécessaire pour assurer que seuls les utilisateurs autorisés peuvent accéder au système et pour fournir des informations utilisateur lors de vérifications.

En accédant à l’interface de ligne de commande, le système répond par une invite de connexion. Saisissez votre nom d’utilisateur et appuyez sur la touche Entrée, puis insérez votre mot de pa sse et appuyez de nouveau sur la touche Entrée. Une fois l’authentification réussie, une invite de commande apparaît. Si un message d’acc ueil a été paramétré, il s’affichera directement après l’authentification.

gw-world:/>

Pour des raisons de sécurité, il est conseillé de désactiver ou de ne pas personnaliser le message d’accueil de l’interface de ligne de commande. Modification de l’invite de l’interface de ligne de commande. L’invite de l’interface de ligne de commande par défaut est :

Device:/>

Device est la référence du firewall de D-Link. Elle peut être personnalisée e n gw-world:/> par exemple, à l’aide de la ligne de commande :

Device:/> set device name="gw-world"

Le CLI Reference Guide (Guide de référence sur l’interface de ligne de commande) utilise tout du long l ’invite de commande gw-world:/>.

Remarque

Quand l’invite de ligne de commande est remplacée par une nouvelle valeur, cette valeur apparaît aussi comme le nouveau nom du périphérique dans le nœud supérieur de l’arborescence de l’interface utilisateur Web.

Activation et confirmation des modifications. Si des modifications sont apportées à la configuration en cours par l’interface de ligne de commande, elles ne seront pas enregistrées dans NetDefendOS jusqu’à ce que la commande

gw-world:/> activate

soit émise. Immédiatement après la commande activate, la commande

gw-world:/> commit

doit être émise pour rendre ces modifications permanentes. Si une c omm ande commit n’a pas été lancée dans une période par défaut de 30 secondes, les modi fications seront automat iquement igno rées et l’ancienne c onfiguratio n sera restaurée. Déconnexion de l’interface de ligne de commande. Après avoir fini de travailler avec l’interface de ligne de commande, déconnectez-vous afin d’empêcher d’autres personnes de se connecter au système sans autorisation. Déconnectez-vous en utilisant la commande exit ou logout.

L’interface utilisateur Web

NetDefendOS propose une interface utilisateur Web très polyvalente pour la gestion d u sy stème par le biais d’un navigateur Internet standard. Ainsi, l’administrateur peut effectuer une gest ion distante de pratiquement n’i mporte quel endroit du monde sans avoir à installer de clients tiers.

Connexion à l’interface Web. Pour accéder à l’interface Web, lancez un navigateur Internet standard et saisissez

l’adresse IP du firewall. L’adresse par défaut du fabricant pour tout firewall D-Link est 192.168.1.1. Lors de la première connexion à NetDefendOS, l’administrateur DOIT utiliser le protocole https:// d ans l’URL

(par exemple, https://192.168.1.1). L’utilisation de HTTPS comme protocole chiffre le nom d’utilisateur et le mot de passe lorsqu’ils sont envoyés vers NetDefendOS.

Si la communication avec NetDefendOS est correctement établie, une boîte de dialogue d’authentification de l’utilisateur similaire à celle montrée ci-dessous apparaîtra dans la fenêtre du navigateur.

Gestion et maintenance

Saisissez votre nom d’utilisateur et cliquez sur le bouton Login (Connexion). Si les authentifiants de l’utilisateur sont corrects, la page Web principale de l’interface apparaîtra. Cette page dont les parties essentielles sont mises en évidence est présentée ci-dessous.

Prise en charge de plusieurs langues. La boîte de dialogue de connexion de l’interface utilisateur Web offre la possibilité de choisir une autre langue que l’anglais dans l’interface. Cette prise en charge s’appuie sur un ensemble distinct de fichiers de ressources fournis avec NetDefendOS.

Il arrive qu’une mise à niveau de NetDefendOS ne bénéficie temporairement pas d’une traduction complète à cause de contraintes de temps. Dans ce cas, la version originale en anglais sera utilisée comme une solution temporaire.

Interface du navigateur Internet. Sur le côté gauche de l’interface utilisateur Web se trouve une arborescence qui permet de naviguer au travers des différents modules de NetDefendOS. La partie centrale de l’interface utilisateur Web affiche les informations qui concernent ces modules. Les informations sur la performance en cours sont affichées par défaut.

Gestion et maintenance

Pour obtenir des informations sur le nom d’utilisateur et le mot de passe par défaut, vous pouvez consulter la section Comptes administrateur par défaut.

Remarque

L’accès à l’interface Web est contrôlé par la stratégie de gestion distante. Par défaut, le système n’autorisera l’accès qu’au réseau interne.

Structure de l’interface. L’interface Web principale est divisée en trois sections majeures : La barre de menus La barre de menus située en haut de l’interface Web contient des boutons et des menus

déroulants utilisés non seulement pour l’exécution des tâches de configuration, mais aussi pour l’accès à divers outils et pages d’état.

Home (Accueil) : renvoie à la première page de l’interface Web. Configuration

Save and Activate (Enregistrer et activer) : enregistre et active la configuration. Discard Changes (Ignorer les modi ficat ions) : ignore t out es l es modi ficati ons a pportées à

la configuration lors de la session en cours.

View Changes (Afficher les modifications) : répertorie les modifications apportées à la

configuration depuis la dernière sauvegarde.

Tools (Outils) : contient plusieurs outils utiles à la maintenance du système. Status (État) : propose diverses pages d’état utilisables lors de diagnostics du système. Maintenance

Gestion et maintenance

Update Center (Centre de mise à jour) : effectuez des mises à jour manuelles ou

programmées de la fonction de détection de s intrusions et des signatures de virus.

License (Licence) : affichez les détails de la licence ou saisissez le code d’activation. Backup (Sauvegarde) : sauvegardez la configuration sur votre ordinateur local ou

restaurez une sauvegarde téléchargée précédemment.

Reset (Réinitialiser) : redémarrez le firewall ou réinitialisez les paramètres usine par

défaut.

Upgrade (Mise à niveau) : mettez à niveau le firmware du firewall.

Navigateur Le navigateur situé sur le côté gauche de l’interface Web contient une arborescence de la

configuration du système. L’arborescence est divisée en plusieurs sections qui correspondent aux principales unités élémentaires de la configuration. L’arborescence peut être développée pour présenter des sections supplémentaires.

Fenêtre principale La fenêtre principale contien t les détails de la conf igur ation et d e l’état q u i correspond ent à la

section sélectionnée dans le navigateur ou dans la barre de menus.

Contrôle de l’accès à l’interface Web. Par défaut, l’interface Web n’est accessible que via le réseau interne. Si vous devez autoriser l’accès à d’autres parties du réseau, vous pouvez modifier la stratégie de gestion distante.

Exemple 2.2. Activation de la gestion HTTPS distante

Interface de ligne de commande

gw-world:/> add RemoteManagement RemoteMgmtHTTP https

Network=all-nets Interface=any LocalUserDatabase=AdminUsers HTTPS=Yes

Interface Web

Sélectionnez System > Remote Management > Add > HTTP/HTTPS Management (Système > Gestion

distante > Ajouter > Gestion HTTP/HTTPS).

Saisissez le nom de la stratégie de gestion HTTP/HTTPS distante (par exemple, https). Cochez la case HTTPS. Dans les listes déroulantes, sélectionnez les éléments suivants.

User Database (Base de données utilisateur) : AdminUsers (Administrateurs) Interface : any (toute)

Network (Réseau) : all-nets (tous les réseaux)

Cliquez sur OK.

Attention

L’exemple ci-dessus est donné à titre d’information uniquement. Il n’est jamais recommandé de dévoiler une interface de gestion à quiconque sur Internet.

Déconnexion de l’interface Web. Une fois le travail accompli sur l’interface Web, vous devez toujours vous déconnecter pour empêcher les utilisateurs qui peuvent se servir de votre poste de travail d’avoir un accès non autorisé au système. Déconnectez-vous en cliquant sur le bouton Logout (Déconnexion) à droite de la barre de menus.

Conseil

S’il survient un problème avec l’interface de gestion lors d’une communication via des tunnels VPN, vérifiez la table de routage p rincipale et cherchez une route all-nets (t ous les réseaux) ve rs le tunnel VP N. Si aucune route spécifique n’existe jusqu’à l’interface de gestion, le trafic de gestion en provenance de

NetDefendOS sera automatiquement dirigé vers le tunnel VPN. Si tel est le cas, l’administrateur doit ajouter une route pour diriger le trafic de gestion destiné au réseau de gestion vers la bonne interface.

Gestion et maintenance

Utilisation des configurations

La configuration du système s’appuie su r des objets. Chaque ob jet représente un élément configurable de tout t ype. Exemples d’objets de configuration : entrées de la table de routage, entrées du carnet d’adresses, définitions du service et règles IP. Chacun a plusieurs propriétés qui constituent les valeurs de cet objet.

Chaque objet de configuration a un type bien défini. Le type détermine les propriétés disponib les pour l’obj et de configuration et leurs contraintes. Par exemple, le type IP4Address est utilisé pour tous les objets de configuration qui représentent une adresse IPv4 nommée.

Dans l’interface utilisateur Web, les objets de configuration sont organisés en une sorte d’arborescence et classés selon leur type.

Dans l’interface de ligne de commande, les types similaires d’objet de configuration sont regro upés en catégo ries. Ces catégories sont différentes de la structure utilisée dans l’interface utilisateur Web, afin de permettre un accès plus rapide aux objets de configuration dans l’interface de ligne de c ommande. Les type s IP4Adress, IP4Group et EthernetAddress sont par exemple regroupés dans une catégorie nommée Address (Adresse), puisqu’ils représentent tous des adresses différentes. Par conséquent, les objets Ethernet et VLAN sont tous regroupés dans une catégorie nommée Interface puisqu’ils sont des objets d’interface. Ces catégories n’ont en fait aucun impact sur la configuration du système. Elles ne font que simplifier l’administration du système.

Les exemples suivants décrivent la manière d’utiliser les objets.

Exemple 2.3. Liste des objets de configuration

Pour identifier tous les objets de configuration existants, vous pouvez créer une liste de ceux-ci. Cet exemple décrit la manière d’établir une liste de tous les objets de service.

Interface de ligne de commande

gw-world:/> show Service

Une liste de tous les services classés selon leur type respectif s’affiche.

Interface Web

Sélectionnez Objects > Services (Objets > Services).

Une page Web qui répertorie tous les services s’affiche.

Une liste contient les éléments de base suivants.

Add (Ajouter) : le bouton affiche un menu déroulant après avoir cliqué dessus. Le menu répertorie tous les types d’élément de configuration qui peuvent être ajoutés à la liste.

Header (En-tête) : la ligne d’en-tête affiche les titres des colonnes de la liste. Les petites icônes en flèche situées

près de chaque titre peuvent être utilisées pour trier la liste dans chaque colonne.

Rows (Lignes) : chaque ligne de la liste correspond à un élément de configuration. De manière générale, chaque

ligne débute par le nom de l’objet (si l’élément a un nom), suivi par les valeurs des colonnes de la liste.

Le fait de cliquer à un endroit de la ligne sans lien hypertexte permet de ne sélectionner qu’une seule ligne. Le fond de la ligne devient bleu foncé. Le fai t de cliquer avec le bouton droit de la souris sur la ligne fait apparaître un menu grâce auquel les objets peuvent être modifiés, supprimés ou réordonnés.

Exemple 2.4. Affichage d’un objet de configuration

L’opération la plus simple à effectuer sur un objet de configuration est d’afficher son contenu, c’est-à-dire les valeurs des propriétés de cet objet. Cet e xemple décrit la m anière d’afficher le cont enu d’un objet de c onfiguration qui représente le service telnet.

Gestion et maintenance

Interface de ligne de commande

gw-world:/> show Service ServiceTCPUDP telnet

Property Value

----------------- -------

Name: telnet DestinationPorts: 23 Type: TCP SourcePorts: 0-65535 SYNRelay: No PassICMPReturn: No ALG: (none) MaxSessions: 1000 Comments: Telnet

La colonne Property (Propriété) répertorie les noms de toutes les propriétés de la classe ServiceTCPUDP et la colonne Value (Valeur) répertorie les valeurs des propriétés correspondan tes.

Interface Web

Sélectionnez Objects > Services (Objets > Services). Cliquez sur le lien hypertexte telnet dans la liste. Une page Web du service telnet s’affiche.

Remarque

Pour accéder à un objet via l’interface de ligne de commande, vous pouvez om ettre le nom de la catégorie et simplement utiliser le nom du type. La ligne de commande de l’exemple ci-dessus peut donc être simplifiée par :

gw-world:/> show ServiceTCPUDP telnet

Exemple 2.5. Modification d’un objet de configuration

Pour modifier le fonctionnement de NetDefendOS, vous allez très probablement devoir modifier un ou plusieurs des objets de configuration. Cet exemple décrit la manière de modifier la propriété Comments du service telnet.

Interface de ligne de commande

gw-world:/> set Service ServiceTCPUDP telnet Comments="Modified Comment"

Affichez à nouveau l’objet pour vérifier la nouvelle valeur de la propriété :

gw-world:/> show Service ServiceTCPUDP telnet

Property Value

----------------- -------

Name: telnet DestinationPorts: 23 Type: TCP SourcePorts: 0-65535 SYNRelay: No PassICMPReturn: No ALG: (none) MaxSessions: 1000 Comments: Modified Comment

Interface Web

Sélectionnez Objects > Services (Objets > Services). Cliquez sur le lien hypertexte telnet dans la liste. Dans la zone de texte Comments (Commentaires), saisissez votre nouveau commentaire. Cliquez sur OK.

Vérifiez que le nouveau commentaire a bien été mis à jour dans la liste.

Gestion et maintenance

Important

Les modifications apportées à un objet de configuration ne seront pas appliquées au système en cours d’exécution tant que vous ne les aurez pas activées et confirmées.

Exemple 2.6. Ajout d’un objet de configuration

Cet exemple décrit la manière dont vous pouvez ajouter un nouvel objet IP4Address en créant l’adresse IP

192.168.10.10 dans le carnet d’adresses.

Interface de ligne de commande

gw-world:/> add Address IP4Address myhost Address=192.168.10.10

Affichez le nouvel objet :

gw-world:/> show Address IP4Address myhost

Property Value

--------------------- -------------

Name: myhost Address: 192.168.10.10 UserAuthGroups: (none) NoDefinedCredentials: No Comments: (none)

Interface Web

Sélectionnez Objects > Address Book (Objets > Carnet d’adresses). Cliquez sur le bouton Add (Ajouter). Dans le menu déroulant affiché, sélectionnez l’adresse IP4. Dans la zone de texte Name (Nom), saisissez myhost. Saisissez 192.168.10.10 dans la zone de texte de l’adresse IP. Cliquez sur OK. Vérifiez que la nouvelle adresse IP4 de l’objet a bien été ajoutée à la liste.

Exemple 2.7. Suppression d’un objet de configuration

Cet exemple décrit la manière de supprimer l’objet IP4Address récemment ajouté.

Interface de ligne de commande

gw-world:/> delete Address IP4Address myhost

Interface Web

Sélectionnez Objects > Address Book (Objets > Carnet d’adresses).

Cliquez avec le bouton droit de la souris sur la ligne contenant l’objet myhost. Dans le menu déroulant affiché, sélectionnez Delete (Supprimer).

La ligne est barrée, ce qui indique qu’elle est en cours de suppression.

Exemple 2.8. Annulation de la suppression d’un objet de configuration

Un objet supprimé peut toujours être restauré avant que la configuration n’ait été activée et confirmée. Cet exemple décrit la manière de restaurer l’objet IP4Address précédemment supprimé.

Interface de ligne de commande

gw-world:/> undelete Address IP4Address myhost

Interface Web

Gestion et maintenance

Sélectionnez Objects > Address Book (Objets > Carnet d’adresses). Cliquez avec le bouton droit de la souris sur la ligne qui contient l’objet myhost. Dans le menu déroulant affiché, sélectionnez Undo Delete (Annuler la suppression).

Consultation de la liste des objets modifiés. A près avoir m odifié plusieurs objets de con figuration, v ous pouvez avoir envie de consulter une liste des objets modifiés, ajoutés ou supprimés depuis la dernière sauvegarde.

Exemple 2.9. Affichage de la liste des objets de configuration

Cet exemple décrit la manière de répertorier les objets de configuration modifiés.

Interface de ligne de commande

gw-world:/> show -changes

Type Object

------------- ------

- IP4Address myhost

* ServiceTCPUDP telnet

Le signe + au début d’une ligne indique que l’objet a été ajouté. Le signe * indique que l’objet a été modifié. Le signe - indique que l’objet est en cours de suppression.

Interface Web

Dans la barre de menus, sélectionnez Configuration > View Changes (Configuration > Afficher les

modifications).

Une liste des modifications apparaît. Activation et confirmation d’une configuration. Après avoir apporté des modifications à une configuration,

cette dernière doit être activée pour que les modifications prennent effet sur le système en cours d’exécution. Lors du processus d’activation, la nouvelle configuration est validée et NetDefendOS essaye d’initialiser les sous-systèmes affectés avec les données de la nouvelle configuration.

Confirmation des modifications IPSec

L’administrateur doit savoir que, si des modifications qui affectent les configurations des tunnels directs sont validées, les connexions de ces tunnels SERONT INTERROMPUES et devront être relancées.

Si la nouvelle configuration est validée, NetDefendOS attendra une courte période (30 secondes par défaut) durant laquelle une connexion avec l’administrateur doit être rétablie. À titre de rappel, si la configuration a été activée via l’interface de ligne de commande grâce à la commande activate, une commande commit doit être lancée au cours de cette période. Si une connexion per due ne peut êt re rétablie o u si la comm ande commit n’a pas été lancée, NetDefendOS reviendra à l’ancienne configuration. Il s’agit d’un mécanisme à sécurité intégrée, notamment capable d’éviter qu’un administrateur distant ne procède au verrouillage.

Exemple 2.10. Activation et confirmation d’une configuration

Cet exemple décrit la manière d’activer et de confirmer une nouvelle configuration.

Interface de ligne de commande

gw-world:/> activate

Le système valide et commence à utiliser la nouvelle configuration. Lorsque l’invite de commande

gw-world:/> commit

réapparaît, la nouvelle configuration est désormais confirmée.

Interface Web

Gestion et maintenance

Dans la barre de menus, sélectionnez Configuration > Save and Activate (Configuration > Enregistrer et

activer).

Cliquez sur OK.

Le navigateur Web essaye automatiquement de se reconnecter à l’interface Web après 10 secondes. Si la connexion s’établit, la gestion distante fonctionne toujours d’après l’interprétation de NetDefendOS. La nouvelle configuration est automatiquement confirmée.

Remarque

La configuration doit être confirmée avant que les modifications ne soient enregistrées. Toutes les modifications apportées à une configuration peuvent être ignorées en omettant l’étape de confirmation.

Événements et consignation

Présentation

La possibilité de consigner et d’analyser les activités du système représente une fonctionnalité essentielle de NetDefendOS. La consignation permet non seulement de surveiller l’état et le bon fonctionnement du système, mais aussi de vérifier l’utilisation du réseau et de faciliter le dépannage.

NetDefendOS définit plusieurs event messages (messages d’événements) qui sont générés en conséquence d’événements du système correspondants. Exemples d’événements : établissement ou échec de connexions, réception de paquets corrompus et interruption du trafic selon les règles de filtrage.

Quand un event message (message d’événement) est généré, il peut être filtré et affiché par tous les e vent receivers (récepteurs d’événements) après configuration. L’administrateur peut configurer plusieurs event receivers (récepteurs d’événements), qui peuvent avoir chacun leur propre event filter (filtre d’événements) personnalisé.

La conception complexe des mécanismes d’événements et de consignation de NetDefendOS garantit que la possibilité de connexion est simple et directe. Parallèlement, le contrôle de toutes les activités du système reste très fin pour les déploiements les plus avancés.

Messages d’événements

NetDefendOS détermine plusieurs centaines d’événements pour lesquels des event messages (messages d’événements) peuvent être générés. Les événements peuvent être : high-level (de haut niveau), customizable (personnalisables), user events (de l’utilisateur), low-level (de bas niveau) ou mandatory system events (obligatoires au système).

Par exemple, l’événement conn_open est un événement généralement high-level (de haut niveau), qui génère un event message (message d’événement) chaque fois qu’une nouvelle connexion est établie. En effet, la règle de sécurité correspondante définit que les event messages (messages d’événements) doivent être générés lors de cette connexion.

Exemple d’événement low-level (de bas niveau) : l’événement startup_normal, qui génère un event message (message d’événement) obligatoire lorsque le système démarre.

Tous les event messages (messages d’événements) sont établis sur un format commun, qui regroupe la catégorie,

la gravité et les actions recommandées. Ces attributs permettent un filtrage facile des messages, dans NetDefendOS avant même leur envoi à un event receiver (récepteur d’événement) ou lors de l’analyse après la consignation et le stockage des messages sur un serveur de consignation externe.

Une liste de tous les event messages (messages d’événements) est consultable dans le Log Reference Guide (Guide de référence des événements). Ce guide décrit aussi la structure des event messages (messages d’événements), ainsi que les divers attributs disponibles. La gravité de chaque événement est prédéfinie et classée selon son degré :

Emergency (Urgence) Alert (Alerte) Critical (Critique) Error (Erreur) Warning (Avertissement ) Notice (Avis) Info Debug (Débogage)

Par défaut, tous les messages du niveau Info ou supérieur sont affichés. La catégorie Debug (Débogage) n’est destinée qu’aux dépannages et ne doit être activée que s’il est nécessaire de résoudre un problème. Les messages de tout degré de gravité sont consultables dans le Log Reference Guide (Guide de référence des événements) de NetDefendOS.

Gestion et maintenance

Répartition des messages d’événements

Pour répartir et enregistrer les event messages (messages d’ événements) générés , il est nécessaire de défini r un ou plusieurs event receivers (récepteurs d’événements) qui spécifient quels événements choisir et où les envoyer.

NetDefendOS peut répartir les event messages (messages d’événements) des façons suivantes : Memlog Le firewall D-Link a un mécanisme de consignation intégré, du nom de Memory Log (Mémoire des

événements). Il sauvegarde tous les messages d’événements dans la m émoire et perm et de les afficher directement grâce à l’interface Web.

Syslog Le standard de référence pour la consignation d’événements des périphériques réseau. Si d’autres

périphériques réseau sont déjà consignés sur les serveurs Syslog, utiliser Syslog avec les messages de NetDefendOS peut simplifier l’admini st rat i on géné ral e .

Enregistrement vers des hôtes Syslog

Syslog est un protocole standard pour la transmission des données de journal, bien qu’il n’existe pas de format standard pour les messages de consignation eux-mêmes. Le format utilisé par NetDefendOS convient bien aux traitements, filtrages et recherches automatiques.

Bien que les formats exacts de chaque entrée de journal dépendent du mode de fonctionnement d’un récepteur Syslog, la plupart se ressemblent beaucoup. La façon dont les journaux sont lus dépend aussi du mode de fonctionnement du récepteur Syslog. Les daemons Syslog des serveurs UNIX enregistrent généralement des éléments dans des fichiers texte, ligne par ligne.

La plupart des récepteurs Syslog font précéder chaque entrée de journal d’une indication d’horodatage et de l’adresse IP de la machine à l’origine de l’envoi des données de journal.

Feb 5 2000 09:45:23 gateway.ourcompany.com

Vient ensuite le texte d’envoi choisi par l’expéditeur.

Feb 5 2000 09:45:23 gateway.ourcompany.com EFW: DROP:

Le texte qui vient ensuite dépend de l’événement survenu. Afin de faciliter le traitement automatique de tous les messages, NetDefendOS écrit toutes les données de journal

en une seule ligne de texte. Toutes les données suivant le texte d’origine est présenté sur le format : name=value (nom=valeur). Ainsi, les filtres automatiques permettent de rechercher facilement des valeurs sans partir du fait

qu’une donnée spécifique se trouve à un endroit spécifique dans l’entrée de journal.

Gestion et maintenance

Remarque

Le champ Prio= des messages Syslog contient les mêmes informations que le champ Severity (Gravité) des messages de journal D-Link. Toutefois, l’ordre de numérotation est inversé.

Exemple 2.11. Activation de l’enregistrement sur un hôte Syslog

Pour activer l’enregistrement de tous les événements dont le niveau de gravité est supérieur ou égal à Notice (Avis) sur un serveur Syslog dont l’adresse IP est 195.11.22.55, suivez les étapes présentées ci-dessous.

Interface de ligne de commande

gw-world:/> add LogReceiverSyslog my_syslog IPAddress=195.11.22.55

Interface Web

Sélectionnez System > Log and Event Receiver > Add > Syslog Receiver (Système > Journal et récepteur

d’événements > Ajouter > Récepteur Syslog).

Spécifiez un nom adapté à l’event receiver (récepteur d’événement). Par exemple : my_syslog. Saisissez l’adresse IP 195.11.22.55. Sélectionnez une option appropriée dans la liste « facility ». Le nom « facility » est généralement utilisé

comme un paramètre de filtrage pour la plupart des daemons Syslog.

Cliquez sur OK.

Le système enregistre désormais tous les événements dont le niveau de gravité est supérieur ou égal à Notice (Avis) dans le serveur Syslog 195.11.22.55.

Remarque

Le serveur Syslog devra peut-être être configuré pour recevoir les messages de consignation de NetDefendOS. Consultez la documentation spécifique du logiciel de votre serveur Syslog afin de le configurer correctement.

Interruptions SNMP

Protocole SNMP. Le SNMP (Simple Network Management Protocol) est un moyen de communication entre un service de messagerie réseau et un périphérique géré. Il définit 3 types de messages : la comma nde Read pour que le service de messagerie réseau examine un périphérique géré, une commande Write pour modifier l’état d’un périphérique géré et une commande Trap utilisée par les périphériques gérés pour envoyer des messages de manière décalée à un service de messagerie réseau à propos d’un changement d’état.

Interruptions SNMP dans NetDefendOS. NetDefendOS amène le concept d’interruption SNMP une ét ape plus loin en autorisant l’envoi de n’importe quel message comme une interruption SNMP. En d’autres termes, l’administrateur peut configurer la notification d’événements sur l’interruption SNMP que vous considérez comme étant importante pour l’utilisation d’un réseau.

Le fichier DFLNNN-TRAP.MIB (NNN représente la référence du firewall) est fourni par D-Link. Il définit les objets SNMP et les types de données utilisés pour décrire une interruption SNMP reçue de NetDefendOS.

Remarque

Il existe un fichier MIB différent pour chaque modèle de firewall D-Link. Assurez-vous d’utiliser le bon fichier.

Pour chaque modèle de firewa ll D-Link, il ex iste un objet d’interr uption gé nérique appel é DLNNNosGenericTrap et utilisé pour chaque interruption (NNN représente la référence). Cet objet inclut les paramètres suivants.

System (Système) : système générant l’interruption.

Gestion et maintenance

Severity (Gravité) : gravité du message. Category (Catégorie) : problème rapporté par le sous-système de NetDefendOS. ID : identification unique dans la catégorie. Description : courte description textuelle. Action : action de NetDefendOS.

Ces informations peuvent faire l’objet de références croisées – Log Reference Guide (Guide de référence des événements).

Remarque

NetDefendOS envoie des interruptions SNMP basées sur le standard SNMPv2c, comme le définissent les RFC1901, RFC1905 et RFC1906.

Exemple 2.12. Envoi des interruptions SNMP à un récepteur d’interruptions SNMP

Pour permettre l’envoi d’interruptions SNMP pour tous les événements dont le niveau de gravité est supérieur ou égal à Alert (Alerte) à un récepteur d’interruptions SNMP dont l’adresse IP est 195.11.22.55, suivez les étapes ci-dessous.

Interface de ligne de commande

gw-world:/> add LogReceiver EventReceiverSNMP2c my_snmp IPAddress=195.11.22.55

Interface Web

Sélectionnez Log & Event Receivers > Add > EventReceiverSNMP2c (Journal et récepteurs d’événements >

Ajouter > EventReceiverSNMP2c).

Spécifiez le nom de l’event receiver (récepteur d’événements). Par exemple : my_snmp. Saisissez l’adresse IP 195.11.22.55. Saisissez une chaîne de communauté SNMP si le récepteur d’interruption la requiert.

Cliquez sur OK.

Le système envoie désormais des interruptions SNMP pour tous les événements dont le niveau de gravité est supérieur ou égal à Alert (Alerte) à un récepteur d’interruptions SNMP 195.11.22.55.

Comptabilisation RADIUS

Présentation

Dans un environnement réseau basé sur un grand nombre d’utilisateurs, il est avantageux d’avoir un ou plusieurs serveurs centraux pour conserver les informations des comptes utilisateur et prendre en charge l’identification et les tâches d’autorisation. La base de données centrale se trouvant sur le ou les serveurs dédiés conserve tous les authentifiants des utilisateurs ainsi que le détail des connexions, ce qui réduit de manière significative la complexité de la tâche d’administration. RADIUS (Remote Authentication Dial-in User Ser vice) est un pr otoc ole d’authentification, d’autorisation et de comptabilisation (AAA) largement utilisé pour appliquer cette méthode et exploité par NetDefendOS pour mettre en œuvre la comptabilisation des utilisateurs.

Le protocole RADIUS est basé sur une architecture client/serveur. Le firewall D-Link agit comme le client du serveur RADIUS : il crée et envoie des requêtes à des serveurs spéciaux. Dans la terminologie RADIUS, le firewall agit comme le serveur d’accès réseau (NAS). Lors de l’identification de l’utilisateur, le serveur RADIUS reçoit les requêtes, vérifie les informations de l’utilisateur en consultant sa ba se de données, et accepte ou refuse le client demandé. Dans RFC2866, RADIUS allait jusqu’à se charger de la remise des informations de comptabilisation. Il s’agit du standard suivi par NetDefendOS pour la comptabilisation des utilisateurs. Les avantages d’avoir des serveurs centralisés s’étendent donc à la comptabilisation des connexions utilisateur. (Pour

obtenir des détails sur l’utilisation de RADIUS lors de l’authentification NetDefendOS, consultez la section Configuration de l’authentification.)

Gestion et maintenance

Messages de comptabilisation RADIUS

Les statistiques, telles que le nombre d’octets émis et reçus et le nombre de paquets émis et reçus, sont mises à jour et stockées tout au long des sessions RADIUS. Toutes les statistiques d’un utilisateur authentifié sont mises à jour chaque fois qu’une connexion relative à cet utilisateur est coupée.

Quand une nouvelle session client est ouverte par un utilisateur qui établit une nouvelle connexion grâce au firewall D-Link, NetDefendOS envoie un message AccountingRequest (réponse de comptabilisation) de type START à un serveur spécial pour enregistrer le début d’une nouvelle session. Les informations du compte utilisateur sont transmises au serveur RADIUS. Le serveur va renvoyer un message d’accusé de réception AccountingResponse (réponse de comptabilisation) à NetDefendOS.

Par exemple, quand un utilisateur n’est plus authentifié après sa déconnexion ou l’expiration d e la session, un message AccountingRequest (requête de comptabilisation) de type STOP sur les statistiques importantes de la session est envoyé par NetDefendOS. Les informations incluses dans ces statistiques sont configurables par l’utilisateur. Le contenu des messages de type START ou STOP est décrit ci-dessous.

Paramètres du message de type START. Les paramètres i nclus dans les messages de type START envoyés par NetDefendOS sont les suivants.

Type : signale le début (START) du service dans AccountingRequest (requête de comptabilisation).

ID : identifiant unique pour permettre la concordance d’AccountingRequest (requête de comptabilisation) et

d’Acct-Status-Type (Type-état-compt.) défini sur STOP.

User Name (Nom de l’utilisateur) : nom d’utilisateur de la personne authentifiée. NAS IP Address (Adresse IP NAS) : adresse IP du firewall de D-Link. NAS Port (Port NAS) : port du NAS sur lequel l’utilisateur était authentifié (il s’agit d’un port physique et non

d’un port TCP ou UDP).

User IP Address (Adresse IP de l’utilisateur) : adresse IP de l’utilisateur authentifié. Ce message est envoyé

uniquement en cas d’indication sur le serveur d’authentification.

How Authenticated (Mode d’authentification) : mode d’authentification de l’utilisateur. Il peut s’agir soit de

RADIUS si l’utilisateur s’est authentifié via RADIUS, soit de LOCAL si l’utilisateur s’est authentifié via la base de données utilisateur locale.

Delay Time (Temps d’attente) : temps d’attente (en secondes) entre l’envoi du paquet d’AccountingRequest (requête de comptabilisation) et la réception de la reconnaissance de l’authentification. Ce temps peut être soustrait au temps d’arrivée sur le serveur afin de trouver le temps approximatif de la génération de ce message AccountingRequest (requête de comptabilisation) par l’événement. Remarque : ce temps ne prend pas en compte les attentes réseau. Le paramètre de la première tentative sera défini sur 0.

Timestamp (Estampille) : nombre de secondes écoulées depuis le 01/01/1970. Elle est utilisée lors de l’envoi du

paquet par NetDefendOS.

Paramètres du message STOP. Les paramètres incl us dans les messages STOP envoyés par NetDefendOS sont les suivants.

Type : signale l’arrêt d’une session (STOP) dans AccountingRequest (requête de comptabilisation). ID : identifiant qui fait correspondre le paquet d’AccountingRequest (requête de comptabilisation)

précédemment envoyé avec l’Acct-Status-Type (Type-état-compt.) défini sur START.

User Name (Nom de l’utilisateur) : nom d’utilisateur de la personne authentifiée.

NAS IP Address (Adresse IP NAS) : adresse IP du firewall de D-Link.

Gestion et maintenance

NAS Port (Port NAS) : port NAS sur lequel l’utilisateur était authentifié. (Il s’agit d’un port physique et non

d’un port TCP ou UDP.)

User IP Address (Adresse IP de l’utilisateur) : adresse IP de l’utilisateur authentifié. Ce message est envoyé

uniquement en cas d’indication sur le serveur d’authentification.

Input Bytes (Octets entrants) : nombre d’octets reçus par l’utilisateur. (*) Output Bytes (Octets sortants) : nombre d’octets émis par l’utilisateur. (*) Input Packets (Paquets entrants) : nombre de paquets reçus par l’utilisateur. (*) Output Packets (Paquets sortants) : nombre de paquets émis par l’utilisateur. (*) Session Time (Durée de la session) : durée de la session en secondes. (*) Termination Cause (Cause de l’arrêt) : raison pour laquelle la session a été fermée. How Authenticated (Mode d’authentification) : mode d’authentification de l’utilisateur. Il s’agit soit de

RADIUS si l’utilisateur s’est authentifié via RADIUS, soit de LOCAL si l’utilisateur s’est authentifié via la base de données utilisateur locale.

Delay Time (Temps d’attente) : consultez la description ci-dessus. Timestamp (Estampille) : nombre de secondes écoulées depuis le 01/01/1970. Elle est utilisée lors de l’envoi du

paquet par le firewall de D-Link. De plus, deux attributs supplémentaires peuvent être envoyés.

Input Gigawords (Gigawords entrants) : indique le nombre de tours effectués par le compteur d’Input Bytes

(Octets entrants). Cet attribut est envoyé uniquement si le compteur a fait un tour et si l’attribut Input Bytes (Octets entrants) est envoyé.

Output Gigawords (Gigawords s orta nts) : indique le n ombre de t ours effec tués pa r le compt eur d’O utput Byte s

(Octets sortants). Cet attribut est envoyé uniquement si le compteur a fait un tour et si l’attribut Output Bytes (Octets sortants) est envoyé.

Remarque

Dans la liste ci-dessus, le symbole (*) indique que l’envoi du paramètre est configurable par l’utilisateur.

Messages de comptabilisation d’attente

En plus des messages START et STOP, NetDefendOS peut de manière facultative et périodique envoyer des Interim Accounting Messages (Messages de comptabilisation d’attente) pour mettre à jour le serveur de comptabilisation avec l’état en cours d’un utilisateur authentifié. Un Interim Accounting Message (Message de comptabilisation d’attente) peut être considéré comme une « capture » des ressources du réseau qu’un utilisateur authentifié a utilisé jusqu’à un moment donné. Grâce à cette fonctionnalité, le serveur RADIUS peut tracer le nombre d’octets et de paquets qu’un utilisateur authentifié a émis et reçu jusqu’au moment où le dernier message a été envoyé.

Un Interim Accounting Message (Message de comptabilisation d’attente) contient les valeurs en cours des statistiques d’un utilisateur authentifié. Il contient plus ou moins les mêmes paramètres que le message AccountingRequest (requête de comptabilisation) de type STOP, à l’exception faite que l’Acct-Terminate-Cause (Cause-arrêt-compt.) n’est pas incluse (puisque l’utilisateur n’est pas encore déconnecté).

La fréquence des Interim Accounting Messages (Messages de comptabilisation d’attente) peut être configurée soit sur le serveur d’authentification, soit sur NetDefendOS. Le fait d’enclencher ce paramètre dans NetDefendOS remplace ce même paramètre sur le serveur de comptabilisation.

Activation de la fonction de comptabilisation RADIUS

Pour activer la fonction de comptabilisati on R AD IU S, u n ce rt ai n nombre d’étapes doivent être suivies.

Le serveur de comptabilisation RADIUS doit être spécifié.

Gestion et maintenance

Une règle doit être associée à un objet d’authentification utilisateur sur le serveur RADIUS spécifié.

Quelques points importants sont à noter sur cette activation :

La fonction de comptabilisation RADIUS ne fonctionnera pas pour une connexion soumise à une règle

FwdFast paramétrée dans les règles IP.

Il n’est pas obligatoire d’utiliser un même serveur RADIUS pour l’authentification et la comptabilisation : un

serveur peut se charger de l’authentification et un autre peut se charger des tâches de comptabilisation.

Des serveurs RADIUS multiples peuvent être configurés dans NetDefendOS si le serveur principal est

inaccessible.

Sécurité de comptabilisation RADIUS

La communication entre NetDefendOS et n’importe quel serveur de comptabilisation RADIUS est protég ée par l’intermédiaire d’un secret partagé. Ce secret n’est jamais envoyé sur le réseau. À la plac e, un Authenticator code (authentificateur) de 16 octets est calculé à l’aide de la fonction de hachage MD5 et utilisé pour authentifier les messages de comptabilisation.

Le secret partagé respecte la casse, peut contenir jusqu’à 100 caractères, et doit être tapé d’exactement la même façon sous NetDefendOS et sur le serveur RADIUS.

Les messages sont envoyés à l’aide du p rot ocol e UDP . Le numéro du port par défaut est 1813. Ce pa ramè tre pe ut être configuré par l’utilisateur.

Comptabilisation RADIUS et haute disponibilité

Dans un cluster de haute disponibilité, les informations de comptabilisation sont synchronisées entre les firewalls D-Link passifs et actifs. En d’autres termes, les informations de comptabilisation sont automatiquement mises à jour sur les deux membres du cluster lorsque la connexion est terminée. L’unité active utilise deux événements de comptabilisation spéciaux pour être synchrone avec l’unité passive.

Un événement AccountingStart est envoyé au membre inactif avec un paramètre de haute disponibilité chaque

fois qu’une réponse est reçue de la part du serveur de comptabilisation. Il indique que les informations de comptabilisation doivent être stockées pour chaque utilisateur authentifié.

Un problème avec la synchronisation des informations de comptabilisation peut survenir si les connex ions associées à un utilisateur authentifié d’une unité active expirent avan t qu’elles ne soient synchronisées avec l’unité passive. Pour résoudre ce problème, un événement spécial AccountingUpdate est envoyé à l’unité passive sur la base d’une temporisation. Cet événement contient les informations de comptabil isation les plus récentes sur les connexions.

Serveurs sans réponse

Une question se soulève lorsqu’un client qui envoie le paquet AccountingRequest (réponse de comptabilisation) de type START avec le serveur RADIUS ne do nne jamais de réponse. Net DefendOS renverra la requête après une période en secondes spécifiée par l’utilisateur. Cependant, l’utilisateur bénéficiera encore d’un accès authentifié lorsque NetDefendOS essayera de contacter le serveur de comptabilisation.

Après trois tentatives infructueuses, NetDefendOS considère le serveur de comptabilisation comme étant inaccessible. L’administrateur peut utiliser le paramètre avancé AllowAuthIfNoAccountingResponse de NetDefendOS pour déterminer la manière de gérer cette situation. Si ce paramètre est activé, la session de l’utilisateur authentifié ne sera pas affectée. Dans le cas contraire, tous les utilisateurs effectifs seront automatiquement déconnectés même s’ils se sont déjà authentifiés.

Comptabilisation et interruption système

Si le client échoue dans l’envoi du paquet AccountingRequest (requête de comptabilisation) RADIUS de type STOP pour une quelconque raison, le serveur de comptabilisation ne pourra plus mettre à jour ses statistiques utilisateur et en déduira probablement que la session est encore active. Cette situation doit être évitée.

Si l’administrateur du firewall D-Link émet une commande d’interruption alors que des utilisateurs authentifiés sont encore connectés, le paquet AccountingRequest (requête de comptabilisation) de type STOP ne sera probablement jamais envoyé. Pour éviter cela, NetDefendOS a le paramètre avancé LogOutAccUsersAtShutdown. Ce paramètre permet à l’administrateur de spécifier explicitement que NetDefendOS doit envoyer un message de type STOP pour chaque utilisateur authentifié à tous les serveurs RADIUS configurés avant de lancer l’interruption.

Gestion et maintenance

Limitations avec NAT

Le module d’authentification utilisateur de NetDefendOS se base sur l’adresse IP de l’utilisateur. Des problèmes peuvent survenir avec des utilisateurs partageant une même adresse IP.

Cela peut arriver par exemple quand plusieurs utilisateurs sont derrière le même réseau et utilisent NAT pour pouvoir bénéficier d’un accès au réseau grâce à une seule adresse IP externe. En d’autres termes, dès qu’un utilisateur est authentifié, le trafic provenant de l’adresse IP de la passerelle NAT peut être considéré comme provenant de cet utilisateur authentifié, alors qu’il peut provenir d’autres utilisateurs du même réseau. La fonction de comptabilisation RADIUS de NetDefendOS regroupe donc les statistiques de tous les utilisateurs du réseau comme s’il n’en existait qu’un seul.

Surveillance

Surveillance SNMP

Présentation. SNMP (Simple Network Management Protocol) est un protocole standard pour la gestion des périphériques réseau. Un client compatible SNMP peut se connecter à un périphérique réseau également compatible avec le protocole SNMP pour lui envoyer des requêtes et la contrôler.

NetDefendOS est compatible avec la version 1 et 2 de SNMP. La connexion peut être établie par tout client compatible SNMP avec des périphériques NetDefendOS. Cependant, seules les opérations de requête sont autorisées pour des raisons de sécurité. NetDefendOS est plus particulièrement com pati ble avec l es opé rat ions de requête SNMP suivantes :

L’opération GET REQUEST. L’opération GET NEXT REQUEST.

L’opération GET BULK REQUEST (pour les versions 2c de SNMP uniquement).

MIB de NetDefendOS. MIB est une base de données, généralement sous forme d’un fichier, qui définit les paramètres d’un périphérique réseau qu’un client SNMP peut modifier ou auquel il peut envoyer une requête. Le fichier MIB pour un périphérique NetDefendOS est fourni avec le pack standard NetDefendOS sous le nom de fichier DFLNNN-TRAP.MIB (NNN représente la référence du firewall). Ce fichier doit être trans féré s ur le disque dur du poste de travail qui va exécuter le client SNMP pour qu’il puisse être importé par le logiciel du client. Lorsque le client fonctionne, le fichier MIB est ouvert pour indiquer les valeurs qui peuvent faire l’objet d’une requête sur un périphérique NetDefendOS.

Définition de l’accès SNMP. L’accès SNMP est défini par un objet Remote de NetDefendOS avec un Mode de SNMP. L’objet Remote requiert la saisie des éléments suivants.

Interface : interface de NetDefendOS dans laquelle la requête SNMP va arriver.

Network (Réseau) : adresse IP ou réseau source de la requête SNMP.

Community (Communauté) : chaîne de communauté qui garantit la sécurité des mots de passe des accès.

Chaîne de communauté. Pour la version 1 et 2 de SNMP, la sécurité est garantie par la chaîne de communauté, qui ressemble à un mot de passe d’accès SNMP. La chaîne de communauté ne doit pas être facile à deviner et donc être élaborée sur la même base que tout autre mot de passe (à l’aide d’une combinaison de majuscules, de minuscules et de chiffres).

Activation d’une règle IP pour SNMP. Le paramètre avancé SNMPBeforeRules de la section RemoteAdmin

(Administrateur distant) contrôle si la configuration de la règle IP surveille tous les accès par clients SNMP. Ce paramètre est désactivé par défaut, mais nous recommandons de toujours l’activer.

La conséquence de l’activation de ce paramètre est d’ajouter une règle invisible en haut de l’ensemble des règles IP, qui autorise automatiquement l’accès au port 161 du rése au et à l’interface définie pour l’accès SNMP. Le port 161 est généralement utilisé pour SNMP et NetDefendOS attend toujours le trafic SNMP sur ce port.

Chiffrement des accès distants. Remarque : lors des accès à la version 1 et 2c de SNMP, la chaîne de communauté est envoyée en texte clair sur le réseau. Cette situation est clairement un cas d’i nsécurité si un cli ent distant est en communication via Internet. Il est donc conseillé de faire en sorte que les accès distants s’effectuent via un tunnel VPN chiffré ou tout autre moyen de communication au niveau de sécurité équivalent.

Prévention de la surcharge SNMP. Le paramètre avancé SNMPReqLimit restreint le nombre de requêtes SNMP autorisées par seconde. Il peut aider à prévenir des attaques basées sur une surcharge SNMP.

Gestion et maintenance

Exemple 2.13. Activation de la surveillance SNMP

Cet exemple active l’accès SNMP par une interface LAN interne depuis le réseau mgmt-net, à l’aide de la chaîne de communauté Mg1RQqR. (Puisque la gestion du client se fait sur le réseau interne, nous n’avons pas besoin de lui appliquer un tunnel VPN.)

Interface de ligne de commande

gw-world:/> add RemoteManagement RemoteMgmtSNMP my_snmp Interface=lan Network=mgmt-net SNMPGetCommunity=Mg1RQqR

S’il est nécessaire d’activer SNMPBeforeRules (activation par défaut), la commande est alors :

gw-world:/> set Settings RemoteMgmtSettings SNMPBeforeRules=Yes

Interface Web

Sélectionnez System > Remote Management > Add > SNMP management (Système > Gestion distante >

Ajouter > Gestion SNMP).

Pour Remote access (Accès distant), saisissez les éléments suivants.

Name (Nom) : nom adapté

Community (Communauté) : Mg1RQqR

Pour Access Filter (Filtre d’accès), saisissez les éléments suivants.

Interface : lan

Network (Réseau) : mgmt-net

Cliquez sur OK.

S’il est nécessaire d’activer SNMPBeforeRules (activation par défaut), vous t rouverez ce paramèt re dans System > Remote Management > Advanced Settings (Système > Gestion distante > Paramètres avancés).

Maintenance

Mécanisme de mise à jour automatique

En ce qui concerne les mises à jour automatiques et le filtrage de contenu, des fonctionnalités de NetDefendOS reposent sur des serveurs externes. Le système de prévention et de détection des intrusions ainsi que les modules antivirus requièrent un accès à des bases de données de signatures actualisées pour garantir une protection contre les menaces les plus récentes.

Pour faciliter la fonctionnalité de mise à jour automatique, D-Link assure une infrastructure internationale de serveurs qui fournissent des services de mise à jour pour les firewalls de D-Link. Pour garantir une disponibilité et

des temps de réponse courts, NetDefendOS utilise un mécanisme qui sélectionne automatiquement le serveur le plus approprié pour garantir les mises à jour.

Pour plus de détails sur ces fonctionnalités, vous pouvez consulter :

Gestion et maintenance

La section Prévention et détection des intrusions La section Analyse antivirus La section Filtrage de contenu Web L’annexe A Abonnement aux mises à jour de sécurité

Configuration des sauvegardes et des restaurations

La configuration NetDefendOS d’un firewall D-Link peut être sauvegard ée ou restaurée sur demande. Cela p eut permettre par exemple de retrouver la « dernière configuration connue pour être bonne » lors d’essais d’autres configurations.

Exemple 2.14. Configuration des sauvegardes et des restaurations

Interface Web

Pour créer une sauvegarde de la configuration en cours d’exécution :

Sélectionnez Tools > Backup (Outils > Sauvegarde). Téléchargez la configuration, sélectionnez un nom et commencez la sauvegarde.

Pour restaurer une configuration sauvegardée :

Sélectionnez Tools > Backup (Outils > Sauvegarde). Dans Restore unit’s configuration (Restaurer la configuration de l’unité), recherchez la sauvegarde en question. Cliquez sur Upload configuration (Charger la configuration) et choisissez l’activation de cette configuration.

Remarque

Les sauvegardes n’incluent que les informations statiques de la configuration du firewall. Les informations dynamiques telles que l’attribution d’un serveur DHCP à une base de données ne sont pas sauvegardées.

Réinitialisation des paramètres usine par défaut

Une restauration des paramètres usine par défaut peut être appliquée pour qu’il soit possible de retourner à l’état du firewall au moment de sa livraiso n par D-Li nk. Q ua nd une restauration est appliquée, toutes les données telles que l’IDP et les bases de données antivirus sont perdues et doivent être rechargées.

Exemple 2.15. Réinitialisation complète

Interface de ligne de commande

gw-world:/> reset -unit

Interface Web

Sélectionnez Maintenance > Reset (Réinitialiser). Sélectionnez Restore the entire unit to factory defaults (Restaurer l’unité entière aux paramètres usine p ar

défaut), puis confirmez et attendez la fin de la restauration.

Réinitialisation des options du DFL-210/260/800/860 uniquement. Pour réinitialiser le DFL-210/260/800/860, vous devez maintenir ap puy é le bouton situé sur le panneau arrière pendant 10 à 15 secondes lors de la mise sous

tension de l’unité. Relâchez ensuite le bouton de réinitialisation. Le DFL-210/800 continue le charg ement et démarre en mode par défaut, c’est-à-dire avec 192.168.1.1 dans l’interface LAN.

Réinitialisation des options du DFL-1600 et du DFL-2500 uniquement. Appuyez sur n’importe quelle touche du clavier quand le message Press keypad to Enter Setup (Appuyez sur une touche pour entrer dans le menu de configuration) s’affiche. Sélectionnez Reset firewall (Réinitialiser le firewall), confirmez par Yes (Oui), et attendez la fin du processus.

Gestion et maintenance

Avertissement

N’INTERROMPEZ JAMAIS LE PROCESSUS DE RÉINITIALISATION DES PARAMÈTRES USINE PAR DÉFAUT. En cas d’abandon, le firewall de D-Link peut cesser de fonctionner correctement.

Chapitre 3. Fondamentaux

Le présent chapitre décrit les objets logiques fondamentaux qui forment NetDefendOS. Ces objets sont notamment de type adresse, service et programmation. De plus, le présent chapitre explique le mode de fonctionnement des différentes interfaces prises en charge. Il décrit la façon dont les règles de sécurité sont établies et dont les paramètres système de base sont configurés.

Carnet d’adresses

Présentation

Le carnet d’adresses contient des objets nommés qui représentent différents types d'adresses (IP, réseau et Ethernet MAC).

L’utilisation des objets du carnet d’adresses offre trois avantages distincts. Elle augmente la lisibilité, réduit le risque de saisir des adresses réseau incorrectes et facilite la modification des adresses. L’utilisation des objets à la place des adresses numériques vous permet d’effectuer des modifications à un seul emplacement, plutôt que d’avoir à les faire dans chaque partie de la configuration où apparaît l’adresse.

Adresses IP

Les objets IP Address servent à définir des nom s génériques po ur différe nts ty pes d’adresse s IP. En foncti on de la spécification de l’adresse, un objet IP Address peut représe nter un h ôte (u ne adresse IP u nique) , un réseau o u u ne plage d’adresses IP.

De plus, vous pouvez employer les objets IP Address pour spécifier les authentifiants de l’utilisateur qu i seront utilisés par la suite par les différents sous-systèmes d’authentification. Pour plus d’informations, reportez-vous au

chapitre 8, Authentification de l’utilisateur.

La liste suivante présente les différents types d’adresses qu’un objet IP Address peut détenir, outre le format utilisé pour représenter ce type spécifique.

Hôte Un hôte unique est représenté simplement par son adresse IP.

Réseau IP Un réseau IP est représenté en utilisant le format CIDR (Classless Inter Domain Routing). CIDR

Plage d’adresses IP Une plage d’adresses IP est représentée sous la forme a.b.c.d - e.f.g.h. Remarque : les

Exemple : 192.168.0.14

utilise une barre oblique et un chiffre (0 à 32) pour indiquer la taille du réseau (masque réseau). /24 correspond à un réseau de classe C avec 256 adresses (masqu e réseau 255.255.255.0), /27 correspond à un réseau avec 32 adresses (masque réseau 255.255.255.224) et ainsi de suite. Les nombres 0 à 32 correspondent au nombre de binaires dans le masque réseau.

Exemple : 192.168.0.0/24

plages ne sont pas restreintes aux limites des masques réseau. Elles peuvent inclure toute plage d’adresses IP.

Exemple : 192.168.0.10-192.168.0.15 représente six hôtes dans l’ordre consécutif.

Exemple 3.1. Ajout d’un hôte IP

Cet exemple ajoute l’hôte IP wwwsrv1 avec l’adresse IP 192.168.10.16 au carnet d’adresses.

Interface de ligne de commande

gw-world:/> add Address IP4Address wwwsrv1 Address=192.168.10.16

Interface Web

Fondamentaux

Sélectionnez Objects > Address Book > Add > IP address (Objets > Ca rnet d’adresses > Ajouter > Adresse IP). Spécifiez un nom convenable pour l’hôte IP, par exemple wwwwsrv1. Saisissez 192.168.10.16 comme adresse IP. Cliquez sur OK.

Exemple 3.2. Ajout d’un réseau IP

Cet exemple ajoute un réseau IP nommé wwwsrvnet avec l'adresse 192.168.10.0/24 au carnet d'adresses.

Interface de ligne de commande

gw-world:/> add Address IP4Address wwwsrvnet Address=192.168.10.0/24

Interface Web

Sélectionnez Objects > Address Book > Add > IP address (Objets > Ca rnet d’adresses > Ajouter > Adresse IP). Spécifiez un nom convenable pour le réseau IP, par exemple wwwwsrvnet. Saisissez 192.168.10.0/24 comme adresse IP. Cliquez sur OK.

Exemple 3.3. Ajout d’une plage d’adresses IP

Cet exemple ajoute une plage d’adresses IP allant de 192.168.10.16 à 192.168.10.21 nommée wwwservers :

Interface de ligne de commande

gw-world:/> add Address IP4Address wwwservers Address=192.168.10.16-192.168.10.21

Interface Web

Sélectionnez Objects > Address Book > Add > IP address (Objets > Ca rnet d’adresses > Ajouter > Adresse IP).

Spécifiez un nom convenable pour la plage d’adresses IP, par exem pl e wwwwservers. Saisissez 192.168.10.16-192.168.10.21 comme adresse IP.

Cliquez sur OK. Exemple 3.4. Suppression d’un objet Address

Pour supprimer un objet nommé wwwsrv1 du carnet d’adresses, procédez comme suit :

Interface de ligne de commande

gw-world:/> delete Address IP4Address wwwsrv1

Interface Web

Sélectionnez Objects > Address Book (Objets > Carnet d’adresses). Dans la liste, cliquez avec le bouton droit de la souris sur l’objet Address wwwsrv1. Choisissez Delete (Supprimer) dans le menu Cliquez sur OK.

Fondamentaux

Adresses Ethernet

Les objets Ethernet Address sont utilisés pour définir des noms génériques pour les adresses Ethernet (également connues sous le nom d’adresses MAC). Ils sont utiles, par exemple, lorsqu’on remplit la table ARP avec des entrées ARP statiques, ou pour d’autres éléments de configuration où l’on préfère utiliser des noms génériques plutôt que des adresses Ethernet numériques. Lorsque l’on spécifie une adresse Ethernet, on doit utiliser le format aa-bb-cc-dd-ee-ff. Les adresses Ethernet sont donc affichées sous ce format.

Exemple 3.5. Ajout d’une adresse Ethernet

L’exemple suivant ajoute l'objet Ethernet Address nommé wwwsrv1_mac avec l’adresse MAC numérique suivante : 08-a3-67-bc-2e-f2 :

Interface de ligne de commande

gw-world:/> add Address EthernetAddress wwwsrv1_mac Address=08-a3-67-bc-2e-f2

Interface Web

Sélectionnez Objects > Address Book > Add > Ethernet Address (Objets > Carnet d’adresses > Ajouter >

Adresse Ethernet).

Spécifiez un nom convenable pour l’objet Ethernet Address, par exemple wwwsrv1_mac. Saisissez 08-a3-67-bc-2e-f2 comme adresse MAC. Cliquez sur OK.

Groupes d’adresses

Il est possible de regrouper les objets Address pour simplifier la configuration. Considérez un certain nombre de serveurs publics qui doivent être accessibles à partir d’Internet. Les serveurs possèdent des adresses IP qui ne se suivent pas et ne peuvent donc pas être référencées comme une plage d'adresses IP unique. Par conséquent, vous devez créer des objets IP Address individuels pour chaque serveur.

Pour ne pas avoir à gérer la création et la maintenance de règles de filtrage séparées autorisant le trafic vers chaque serveur, il est possible de créer un Groupe d’adresses, nommé par exemple Webservers, avec les hôtes de serveur Web comme membres du groupe. Vous pouvez à présent utiliser une règle unique pour ce gro upe et réduire considérablement la charge de travail.

Les objets Address Group ne sont pas restreints à posséder des membres du même sous-type. En d’autres termes, les objets IP host peuvent être associés aux plages d’adresses, réseaux IP, etc. Toutes les adresses de l’ensemble des membres du groupe sont associées, ce qui engendre véritablement une union des adresses. Par exemple, un groupe contenant deux plages d’adresses IP, l’une possédant les adresses 192.168.0.10 – 192.168.0.15 et l’autre les adresses 192.168.0.14 – 192.168.0.19, engendrera une plage d’adresses IP unique possédant les adresses

192.168.0.10 - 192.168.0.19.

N’oubliez pas cependant que pour des raisons évidentes, vous ne pouvez pas associer les objets IP Address à des adresses Ethernet.

Objets Address générés automatiquement

Pour simplifier la configuration, plusieurs objets Address sont générés automatiquement lors de la première exécution du système. Ces objets sont utilisés par d’autres éléments de configuration dès le démarrage.

Les objets Address suivants sont générés automatiquement :

Fondamentaux

Interface Addresses (adresses des interfaces)

Default Gateway (passerelle par défaut)

All-nets (tout réseau) L’objet adresse IP all-nets est initialisé à l’adresse IP 0.0.0.0/0, qui représente toutes

Pour chaque interface Ethernet du système, deux objets IP Address sont prédéfinis, l’un pour l’adresse IP de l’interface en question et l’autre représentant le réseau local pour cette interface.

Les objets adresse IP de l’interface sont nommés interfacename_ip et les objets réseau, interfacenamenet. Par exemple, une interface nommée lan aura un objet IP d’interface nommé lan ip et un objet réseau nommé lannet.

Un objet IP Address nommé wan gw est généré automatiqu ement et représente la passerelle par défaut du système. L’objet wan_gw est utilisé principalement par la table de routage, mais également par le sous-système client DHCP pour stocker les informations sur les adresses de la passerelle récupérées à partir d’un serveur DHCP. Si une adresse de passerelle par défaut a été communiquée pendant la phase d’installation, l’objet wan_gw contiendra cette adresse. Dans le cas contraire, l’objet sera laissé vide (en d'autres termes, l'adresse IP sera 0.0.0.0).

les adresses IP possibles. Cet objet est largement utilisé tout au long de la configuration.

Services

Présentation

Un objet de service fait référence à un protocole IP spécifique avec des paramètres associés. La définition d’un service repose généralement sur l’un des protocoles principaux, tels que TCP ou UDP, avec le(s) numéro(s) de port(s) associé(s). Le service HTTP, par exemple, est défini comme celui qui utilise le protocole TCP avec le port 80 associé.

Toutefois, les objets de service ne sont en aucun cas restreints aux protocoles TCP ou UDP. Vous pouvez les utiliser pour définir des messages ICMP, tout comme n’importe quel protocole IP définissable par l’utilisateur.

Les services sont des objets passifs car ils ne peuvent eu x-mêmes ent reprendre aucune act ion dans le système. Au lieu de cela, les objets de service sont fréquemment utilisés dans les différentes règles de sécurité définies par les ensembles de règles. Une règle conten ue dans l’ensem ble de règles IP peut par exemple ut iliser un objet de service en tant que filtre pour décider d’autoriser ou non un quelconque trafic à trav ers le firewall D-Link. Pour plus d’informations sur l’utilisation des objets de service avec les règles IP, reportez-vous à la section Ensemble de règles IP.

Un nombre important d’objets de service prédéfinis accompagnent NetDefendOS. Ceux-ci comportent des services courants tels que HTTP, FTP, Telnet et SSH. Les services prédéfinis peuvent être utilisés et également modifiés de la même façon que les services définis par l’utilisateur. Toutefois, il est recommandé de NE PAS modifier les services prédéfinis, mais d'en créer plutôt des nouveaux avec les paramètres désirés.

Exemple 3.6. Référencement des services disponibles

Pour effectuer un référencement des services disponibles dans le système :

Interface de ligne de commande

gw-world:/> show Service

Le résultat sera similaire à la liste suivante :

ServiceGroup

Name Comments

------------ --------------------------------------------------

all_services All ICMP, TCP and UDP services all_tcpudp All TCP and UDP services ipsec-suite The IPsec+IKE suite

l2tp-ipsec L2TP using IPsec for encryption and authentication l2tp-raw L2TP control and transport, unencrypted pptp-suite PPTP control and transport

ServiceICMP ...

Interface Web

Fondamentaux

Sélectionnez Objects > Services (Objets > Services).

Exemple 3.7. Visualisation d’un service spécifique

Pour visualiser un service spécifique du système :

Interface de ligne de commande

gw-world:/> show Service ServiceTCPUDP echo

Le résultat sera similaire à la liste suivante:

Property Value

----------------- ----------------

Name: echo DestinationPorts: 7 Type: TCPUDP (TCP/UDP) SourcePorts: 0-65535 PassICMPReturn: No ALG: (none) MaxSessions: 1000 Comments: Echo service

Interface Web

Sélectionnez Objects > Services (Objets > Services). Sélectionnez l’objet de service spécifique dans la liste de contrôle. Une liste référençant tous les services s’affiche.

Services reposant sur les protocoles TCP et UDP

La plupart des applications utilisent le TCP et/ou l’UDP comme protocoles de tran sport pour le transfert des données d’applications sur les réseaux IP.

Le TCP (Transmission Control Protocol) est un protocole réservé à la connexion qui inclut, entre autres, des mécanismes garantissant une transmission fiable des données. Le TCP est utilisé par un grand nombre d’applications courantes telles que HTTP, FTP et SMTP, où les transferts exempts d’erreur sont obligatoires.

Pour d’autres types d’appl ications, te ls que le s services de diffusion audio et vi déo en c ontinu, o ù l’on accor de par exemple une grande importance aux performances, on préfèrera utiliser le protocole UDP (User Datagram Protocol). L’UDP est un protocole sans connexion, qui propose très peu de services de récupération d’erreur et entraîne ainsi une surcharge du trafic bien plus faible que le TCP. Pour cette raison, l’UDP est également u tilisé pour les services de non-diffusion en continu et il est courant dans ces cas-là que les applications fournissent elles-mêmes les mécanismes de récupération d’erreur.

Pour définir un service TCP ou UDP dans le firewall D-Link, on utilise un objet Service TCP/UDP. Ce type d’objet contient, outre un nom unique qui décrit le service, des informations sur le type de protocole (TCP et/ou UDP) et le type de ports source et de destination qui peuvent s’appliquer à ce service.

Les numéros de ports peuvent être spécifiés de différe nt es m a nières :

Single Port (port unique) Pour un grand nombre de services, un seul port de destination suffit. Le

protocole HTTP, par exemple, utilise le port de destination 80 dans la plupart des cas. SMTP utilise le port 25, et ainsi de suite. Pour ces types de services,

le numéro de port unique est simplement spécifié dans l’objet Service TCP/UDP.

Port Ranges (plages de ports) Certains services utilisent une plage de ports de destination. Par exemple, le

protocole NetBIOS utilisé par Microsoft Windows utilise les ports de destination 137 à 139. Pour définir une plage de ports dans un objet Service TCP/UDP, on utilise le format mmm-nnn. Une plage de ports est inclusive, ce qui signifie qu'une plage définie sur 137 à 139 couvre les ports 137, 138 et

139.

Fondamentaux

Multiple Ports and Port Ranges (ports multiples et plages de ports)

Il est également possible de saisir des plages multiples ou des ports individuels, séparés par des virgul es. Cela perm et de couvri r une vaste pl age de ports en n’utilisant qu'un seul objet Service TCP/UDP. Il est, par exemple, possible de couvrir l'ensemble du réseau Microsoft Windows en utilisant la définition de port suivante : 135-139,445. Vous pouvez couvrir HTTP et HTTPS en définissant les ports de destination sur 80,443.

Conseil

Les méthodes de spécification des numéros de ports ci-dessus ne sont pas utilisées uniquement pour les ports de destination. Les définitions de ports source peuvent suivre les mêmes conventions, bien que, généralement, ces derniers soient l aissés sur la vale ur par défaut 0-65535, q ui correspon d à tous les ports source possibles.

Exemple 3.8. Ajout d’un Service TCP/UDP

Cet exemple montre comment ajouter un Service TCP/UDP en se servant du port de destination 3306 utilisé par MySQL.

Interface de ligne de commande

gw-world:/> add Service ServiceTCPUDP MySQL DestinationPorts=3306 Type=TCP

Interface Web

Sélectionnez Objects > Services > Add > TCP/UDP se rvice (Objets > Services > Ajouter > Service TCP/UDP). Spécifiez un nom convenable pour le service, par exemple MySQL.

A présent, saisissez :

Type : TCP Source : 0-65535

Destination : 3306

Cliquez sur OK.

Outre les informations sur le prot oc ole et l e port , les objets de ser vice TCP /UDP c ont ienn ent égalem ent plusi eurs autres paramètres décrits plus en détail dans les autres sections du présent guide de l'utilisateur.

Fondamentaux

SYN Flood Protection (protection SYN-Flood)

Passing ICMP Errors (ignorer les erreurs ICMP)

Passerelle ALG (Application Layer Gateway)

Max Sessions (sessions maximum). Un paramètre important associé à un Service est le paramètre Max Sessions (sessions maximum). Ce paramètre se voit attribuer une valeur par défaut lorsque le service est associé à une

passerelle ALG. La valeur par défaut varie selon la passerelle ALG à laquelle elle est associée. Si la valeur par défaut est 100, cela signifie que seulem ent 100 connexions sont aut orisées au total pou r ce service à trave rs toutes les interfaces.

Pour un service comprenant, par exemple, une passerelle ALG HTTP, la valeur par défaut peut souvent être trop faible si un grand nombre de clients se connectent via le firewall D-Link. Il est par conséquent recommandé d'estimer si une valeur supérieure est exigée pour un cas de figure particulier.

Utilisation de « All Services » (tous les services). Au moment de la configuration d es règles de filtrage par service, il est possible d’utiliser le service « grouping_all services » pour se référer à tous les protocoles. Pour se référer uniquement aux protocoles principaux (TCP, UDP et ICMP), on peut utiliser le service « group all_tcpundpicmp ».

Vous pouvez configurer un service TCP pour activer la protection contre les attaques SYN Flood. Pour plus de détails sur le fonctionnement de cette fonctionnalité, reportez-vous à la section intitulée « Attaques TCP-SYN-Flood ».

Si une application utilisateur tente d’ouvrir une connexion TCP derrière le firewall D-Link et que le serveur distant n’est pas actif, un message d’erreur ICMP s’affiche en réponse. Vous pouvez soit ignorer ces erreurs ICMP, soit les autoriser à passer et à retourner vers l’application concernée.

Vous pouvez rattacher un Service TCP/UDP à une passerelle ALG pour activer une inspection approfondie de certains protocoles. Pour plus d’informations, reportez-vous à la section intitulée « Passerelles ALG ».

Services ICMP

Internet Control Message Protocol (IC M P) est un protocole intégré au protocole IP pour l e rap port d ’er r e urs et l a transmission des paramètres de contrôle. Le service PING utilise par exemple ICMP pour tester la connexion Internet.

Le message ICMP est distribué en paquets IP et comporte un Type de message qui spécifie le type, c’est-à-dire le format du message ICMP et un Code utilisé pour la désignation du message. Le type de message Destination Unreachable (destination injoignable) utilise par exemple le paramètre Code pour spécifier la cause exacte de l’erreur.

Les types de messages ICMP que vous pouvez configurer dans NetDefendOS sont répertoriés ci-dessous :

Echo Request (message d’écho) : envoyé par le protocole PING en direction d’une destination pour vérifier la

Destination Unreachable (destination injoignable) : la source est informée qu’un problème est survenu lors de

connectivité.

la remise du paquet. Il existe des codes allant de 0 à 5 pour ce type :

Code 0 : Net Unreachable (réseau injoignable) Code 1 : Host Unreachable (hôte injoignable) Code 2 : Protocol Unreachable (protocole injoignable) Code 3 : Port Unreachable (port injoignable) Code 4 : Cannot Fragment (fragmentation impossible) Code 5 : Source Route Failed (échec de la route source)

Fondamentaux

Redirect (redirection) : la source est informée qu’une meilleure route existe pour un paquet donné. Les codes

assignés sont les suivants :

Code 0 : Redirect datagrams for the network (redirection des datagrammes pour le réseau) Code 1 : Redirect datagrams for the host (redirection des datagrammes pour l’hôte) Code 2 : Redirect datagrams for the Type of Service and the network (redirection des datagrammes pour le

type de service et le réseau)

Code 3 : Redirect datagrams for the Type of Service and the host (redirection des datagrammes pour le type

de service et l’hôte)

Parameter Problem (problème de paramètre) : identifie un paramètre incorrect sur le datagramme. Echo Reply (réponse à écho) : réponse provenant de la destination, envoyée comme message de réponse à écho. Source Quenching (extinction de la source ) : la source envoi e les do nnées tro p rapidem ent po ur le réce pteur , la

mémoire tampon est pleine.

Time Exceeded (temps dépassé) : le paquet a été rejeté car il a mis trop de temps à être transmis.

Services de Protocole IP personnalisés

Les services qui fonctionnent sur le protocole IP et qui assurent les fonctions de la couche d’applications/de transport peuvent être affectés d’un identifiant unique grâce aux numéros de protocoles IP. Le protocole IP peut transporter des données pour un certain nombre de protocoles différents. Chacun d’entre eux est identifié par un numéro de protocole IP unique spécifié dans un champ se trouvant dans l’en-tête de l’IP. Par exemple, ICMP, IGMP et EGP possèdent respectivement les numéros de p r ot ocoles 1,2 et 8.

NetDefendOS prend en charge ces types de protocoles IP en utilisant le concept de Services de Protocole IP personnalisés. Un service de protocole IP personnalisé est une définitio n de service qui donne un nom à un numéro de protocole IP. Certains des protocoles IP courants, tels que IGMP, sont déjà prédéfinis dans la configuration système de NetDefendOS.

Vous pouvez utiliser une plage de numéros de protocoles IP semblable aux plages de ports TCP/UDP décrites précédemment pour spécifier de multiples applications pour un seul service.

Remarque

Les numéros de protocoles IP affectés actuellement ainsi que les références sont publiées par l’IANA (Internet Assigned Numbers Authority) et peuvent être consultées à l'adresse suivante :

http://www.iana.org/assignments/protocol-numbers

Exemple 3.9. Ajout d’un service de protocole IP

Cet exemple montre comment ajouter u n se rvice de protocole IP à l’aide du Virtual Ro u t er R ed un da nc y Protocol (protocole de redondance de routeur virtuel, VRRP).

Interface de ligne de commande

gw-world:/> add Service ServiceIPProto VRRP IPProto=112

Interface Web

Sélectionnez Objects > Services > Add > IP protocol service (Objets > Services > Ajouter > Service de protocole IP).

Spécifiez un nom convenable pour le service, par exemple VRRP. Saisissez 112 dans le contrôle de protocole IP. Si nécessaire, saisissez Virtual Router Redundancy Protocol dans le contrôle des commentaires.

Fondamentaux

Cliquez sur OK.

Interfaces

Présentation

Une interface est l’un des plus importants blocs logiques de NetDefendOS. L’ensemble du trafic réseau qui traverse le système ou qui s’interrompt dans celui-ci s'effectue à travers une ou plusieurs interfaces.

Une interface peut être considérée comme un passage pour le trafic réseau, vers ou en provenance du système. Donc, lorsque le trafic pénètre le système par une interface, on l’appellera interface réceptrice (ou parfois interface d’entrée). Par conséquent, lorsque le trafic quitte le système, l'interface utilisée pour expulser le trafic est appelée interface d'envoi (ou parfois interface de sortie).

NetDefendOS prend en charge un certain nombre de types d’interfaces qui peuve nt être réparties en quatre grands groupes, comme suit :

Interfaces physiques Chaque interface physique représente un port physique dans un produit

NetDefendOS. L’en semble du trafic réseau qui émane du système ou qui s’interrompt dans celui-ci traversera donc en fin de compte l’une des interfaces physiques.

Ethernet est le seul type d’interface physique actuellement pris en charge par NetDefendOS. Pour plus d’informations sur les interfaces Ethernet, reportez-vous à la section intitulée « Ethernet ».

Sous-interfaces physiques Certaines interfaces nécessitent une mise en association avec une interface

physique sous-jacente pour transférer des données. Ce groupe d’interfaces est appelé Sous-interfaces physiques.

NetDefendOS prend en charge deux types de sous-interfaces physiques:

Les interfaces VLAN (Virtual LAN ), comme spécifié par la norme IEEE

802.1Q. Si vous routez des paquets IP via une interface VLAN, ils seront encapsulés dans des trames Ethernet balisées VLAN. Pour plus d’informations sur les interfaces Ethernet, reportez-vous à la section intitulée « VLAN ».

Interfaces PPPoE (PPP-over-Ethernet) pour les connexions aux serveurs PPPoE. Pour plus d’informations sur les interfaces PPPoE, reportez-vous à la section intitulée « PPPoE

Interfaces tunnels Les interfaces tunnels sont utilisées lorsque le trafic réseau est acheminé par

un tunnel qui relie le système et l’autre extrémité du tunnel dans le réseau, avant qu’il soit routé vers sa destination finale.

Pour réaliser la tunnelisation, des en-têtes supplémentaires sont ajoutés au trafic acheminé par le tunnel. De plus, diverses trans form ations pe uvent êt re appliquées au trafic réseau en fonction du type d’interface tunnel. Lors que le trafic est routé via une interface IPsec par exemple, la charge utile est généralement chiffrée pour garantir la confidentialité.

».

NetDefendOS prend en charge les types d’interfaces tunnels suivantes :

Les interfaces IPsec sont utilisées comme extrémités pour les tunnels

VPN IPsec. Pour plus d’informations sur les interfaces VPN IPsec, reportez-vous à la section intitulée « IPsec

».

Les interfaces PPTP/L2TP sont utilisées comme extrémités pour les

tunnels PPTP ou L2TP. Pour plus d’informations sur les interfaces PPTP/L2TP, reportez-vous à la section intitulée « PPTP/L2TP ».

Fondamentaux

Les interfaces GRE sont utilisées pour établir des tunnels GRE. Pour plus

d’informations sur les interfaces GRE, reportez-vous à la section intitulée « Tunnels GRE ».

Même si les divers types d’interfaces sont très différents dans la manière dont ils sont déployés et la m anière dont ils fonctionnent, NetdefendOS considère toutes les interfaces comme des interfaces IP logiques. En d’autres termes, tous les types d’interfaces peuvent être utilisés pratiquement de manière interchangeable dans les différents sous-systèmes et règles. Il en résulte une très grande fiabilité dans le mode de contrôle et de routage du trafic dans le système.

Chaque interface de NetDefendOS se voit attribuer un nom unique pour qu’elle puisse êtr e sélectionnée dans d’autres sous-systèmes. Certains types d’interfaces proposent des noms adaptés par défaut qu’il est possible de modifier si nécessaire, tandis que d’autres types d’interfaces nécessitent un nom défini par l’utilisateur.

Avertissement

Si la définition d'une interface est supprimée de la configuration de NetDefendOS, il est important de commencer par supprimer ou modifier toutes les références à cette interface. Il est conseillé, par exemple, de supprimer ou de modifier les règles contenues dans l’ensemble de règles IP qui font référence à cette interface.

Les interfaces core et any. De plus, NetDefendOS propose deux interfaces logiques spéciales nommées core et any :

any représente toute les interfaces possibles, y compris les interfaces core core indique que c’est NetDefendOS lui-même qui se chargera du trafic. Core est par exemple utilisé lorsque le

firewall D-Link fonctionne en tant que serveur PPTP ou L2TP ou doit répondre aux requêtes ping ICMP. Si vous définissez l’interface de destination d’une route en tant que core, NetDefendOS saura qu’il est lui-même le récepteur final du trafic.

Ethernet

La norme Ethernet IEEE 802.3 permet de raccorder différents périphériques au niveau de points arbitraires ou « ports » à un mécanisme de transport physique (un câble coaxial, par exemple). Avec le protocole CSMA/CD, chaque périphérique connecté par le biais d’Ethernet « écoute » le réseau et envoie des données à un autre périphérique connecté alors qu'aucun autre envoi de données n'est en cours. Si deux périphériques diffusent simultanément, des algo ri t hm e s l eu r permettent de renvoyer les don nées à différents moments. Les périphériques diffusent des données sous forme de trames et les autres périphériques « écoutent » pour déterminer s'ils sont les destinataires visés par une de ces trames.

Une trame est une suite de bits qui défini t le périphé rique source et de destinat ion, le flux de données ains i que les bits de vérification d'erreur. Une pause entre la diffusion de trames individuelles donne du temps aux périphériques pour traiter c haque trame ava nt l’arrivée de l a suivante. Cett e pause se réduit progressivem ent au fur et à mesure que les taux de transmission augment ent, passant de norm al à rapide p uis à une transm ission Etherne t Gigabit.

Chaque interface Ethernet d’un firewall D-Li nk correspond à un port Et hernet physique du systèm e. Le nombre de ports, leur vitesse de liaison et la façon dont les ports sont mis en place dépend du modèle de matériel.

Remarque

Certains systèmes utilisent un switch de couche 2 pour fournir des ports physiques Ethernet supplémentaires. Ces ports supplémentaires sont considérés comme une interface unique par NetDefendOS.

Noms des interfaces Ethernet. Les noms des interfaces Ethernet sont prédéfinis par le système et sont calqués sur les noms des ports physiques ; un système possédant un port wan aura une i nterface E thernet nommée wan et ainsi de suite.

Vous pouvez modifier les noms des interfaces Ethernet pour mieux traduire leur utilisation. Par exemple, si une interface nommée dmz est connectée à un réseau local (LAN) sans fil, il peut être pratique de renommer cette interface radio. Pour la maintenance et la résolution des problèmes, il est recommandé de baliser le port physique

correspondant avec le nouveau nom.

Fondamentaux

Remarque

Le processus de démarrage va énumérer toutes les interfaces Ethernet disponibles. Chaque interface se verra attribuer un nom de la forme lanN, wanN et dmz, où N représente le numéro de l’interface si votre firewall D-Link possède plusieurs de ces interfaces. Dans la plupart des exemples de ce guide, « lan » désigne le trafic LAN et « wan » le trafic WAN. Si votre firewall D-Link ne possède pas ces interfaces, remplacez ces références par le nom de l'interface choisie.

Adresses IP Ethernet. Chaque interface Ethernet doit posséder une Adresse IP Ethernet, qui peut être soit une adresse statique, soit une adresse fournie par DHCP. L’adresse IP de l’interface est utilisée comme adresse principale pour communiquer avec le système à travers l'interface Ethernet spécifique.

La norme consiste à utiliser les objets adresse IP4 pour définir les adresses des interfaces Ethernet. Ces objets sont normalement générés automatiquement par le système. Pour plus d’informations, reportez-vous à la section intitulée « Objets adresse générés automatiquement ».

Conseil

Vous pouvez spécifier plusieurs adresses IP pour une interface Ethernet en utilisant la fonctionnalité ARP Publish (publication ARP). Pour plus d’informations, reportez-vous à la section intitulée « ARP ».

En plus des adresses IP de l’interface, une adresse réseau est également spécifiée pour l’interface Ethernet. L’adresse réseau fournit des informations à NetDefendOS concernant les adresses IP accessibles directement par l’interface, en d’autres termes celles qui résident sur le même segment LAN que l’interface elle-même. Dans la table de routage associée à l’interface, NetDefendOS va créer automatiquement une route directe vers le réseau spécifié via l’interface en question.

La passerelle par défaut. Si nécessaire, vous pouvez spécifier une adresse de passerelle par défaut pour une interface Ethernet. Ce paramètre indique à NetDefendOS comment atteindre les hôtes pour lesquels il n’existe pas aucune route. En d’autres termes, si une adresse de passerelle par défaut a été spécifiée, NetDefendOS va créer automatiquement une route p ar défaut (résea u de destinat ion tout réseau) via l’interface en question en utilisant la passerelle spécifiée. Pour des raisons évidentes, vous ne pouvez affecter qu’une seule interface Ethernet à la fois comme passerelle par défaut.

Utilisation de DHCP sur les interfaces Ethernet. NetDefendOS comprend un client DHCP pour l’affectatio n dynamique des informations d’adresse. Les informations qui peuvent être définies via DHCP comportent les adresses IP de l’interface, le réseau local auquel est connectée l’interface et la passerelle par défaut.

Toutes les adresses reçues du serveur DHCP sont affectées aux objets adresse IP4 correspondants. De cette manière, vous pouvez utiliser les adresses affectées de manière dynamique de la même manière que les adresses statiques dans l’ensemble de la configuration. Par défaut, les objets utilisés sont les mêmes que ceux définis dans la section intitulée « Objets adresse générés automatiquement ».

Exemple 3.10. Activation de DHCP

Interface de ligne de commande

gw-world:/> set Interface Ethernet wan DHCPEnabled=Yes

Interface Web

Sélectionnez Interfaces > Ethernet. Dans la liste, cliquez sur l’objet Ethernet souhaité. Activez l’option Enable DHCP client (Activer le client DHCP). Cliquez sur OK.

Fondamentaux

VLAN

Présentation. Les VLAN (Virtual LAN ) sont utiles dans plusieurs cas de figure, par exemple, lorsque le filtrage du trafic est nécessaire entre différents VLAN d’une organisation, ou pour toute autre raison, lorsque l’administrateur souhaite augmenter le nombre d’interfaces.

La prise en charge de VLAN par NetDefendOS permet de définir une ou plusieurs interfaces VLAN qui seront associées à une interface physique donnée. Celles-ci seront considérées comme des interfaces logiques par NetDefendOS et pourront être traitées comme des interfaces physiques dans les ensembles de règles et les tables de routage.

Fonctionnement VLAN. NetDefendOS est conforme à la norme IEEE 802.1Q relative aux réseaux VLAN. En ce qui concerne le protocole, VL AN fo nctionne en aj outant un ID de VL AN ( Virtual LAN Identifier) aux en-têtes de trames Ethernet. L’ID du VLAN est un nombre compris entre 0 et 4095 utilisé pour identifier le VLAN spécifique auquel appartient la trame. De cette manière, les trames Ethernet peuvent appartenir à différents VLAN, tout en continuant à partager la même interface physique. Avec NetDefendOS, l’ID du VLAN doit être unique pour l’interface physique et le même ID de VLAN peut être utilisé sur différentes interfaces physiques.

Les paquets reçus à travers les trames Ethernet par une interface physique de NetDefendOS sont examinés pour rechercher un ID de VLAN. Si un ID de VLAN valide est trouvé et qu’une interface VLAN correspondante a été définie pour cette interface, NetDefendOS utilisera l’interface VLAN comme interface source lors du traitement ultérieur avec les ensembles de règles IP.

Si aucun ID de VLAN valide n’est associé à une trame Ethernet reçue par l’interface physique, alors la trame est considérée comme étant reçue par l’interface physique et non par une quelconque interface VLAN pouvant être définie.

Limitations de licence. Le nombre d’interfaces VLAN pouvant être défi ni pour une installation NetDefendOS est limité par les paramètres de la licence utilisée. Les différents modèles matériels possèdent différentes licences et différentes limitations de VLAN.

Résumé de l’installation du VLAN. Il est important de comprendre que l’administrateur doit considérer une interface VLAN de la même façon qu’une interface physique dans le sens où celles-ci requièrent au moins des règles IP et des routes pour être définies et être capables de fonctionner. Si, par exemple, aucune règle Allow (Autoriser) n’est définie dans l’ensem bl e de règl es IP po ur une i nte rface V LAN, alor s les paq uets qui arr ivent su r cette interface seront ignorés. Pour configurer une interface VLAN, procédez comme suit :

Attribuez un nom à l’interface VLAN. Sélectionnez l’interface physique pour le VLAN. Attribuez un ID de VLAN unique sur l’interface physique. Si nécessaire, précisez une adresse IP pour le VLAN. Si nécessaire, précisez une adresse IP de diffusion pour le VLAN. Créez la(les) route(s) pour le VLAN dans la table de routage appropriée. Créez des règles dans l’ensemble de règles IP pour autoriser le trafic à traverser l’interface VLAN.

Exemple 3.11. Définition d’un VLAN

Cet exemple simple définit un VLAN nommé VLAN10 avec l’ID de VLAN 10. Notez que cette interface de VLAN utilisera l’adresse IP de l’interface Ethernet correspondante, car aucune adresse IP n’est spécifiée.

Interface de ligne de commande

gw-world:/> add Interface VLAN VLAN10 Ethernet=lan Network=all-nets VLANID=10

Interface Web

Fondamentaux

Sélectionnez Interfaces > VLAN > Add > VLAN (Interfaces > VLAN > Ajouter > VLAN). Saisissez un nom convenable pour le VLAN (dans notre exem pl e, VLAN10). A présent, saisissez :

Interface : lan VLAN ID (ID du VLAN) : 10

Cliquez sur OK.

PPPoE

PPPoE (Point-to-Point Protocol over Ethernet) est un protocole de tunnelisation utilisé pour connecter à Internet plusieurs utilisateurs d’un réseau Ethernet par une interface série commune, telle qu’une ligne DSL unique, un périphérique sans fil ou un modem câble. Tous les utilisateurs d’Ethernet partagent une connexion commune, tandis que le contrôle d’accès peut être effectué en fonction des utilisateurs.

Les FAI demandent souvent aux clients de se connecter à leur service haut débit par PPPoE. En utilisant PPPoE, le fournisseur peut :

mettre en œuvre des contrôles de sécurité et d’accès en utilisant l’authentification par nom d’utilisateur/mot de

passe ;

associer les adresses IP à un utilisateur spécifique ; attribuer automatiquement des adresses IP aux utilisateurs PC (similaire à DHCP). La fourniture d’adresses IP

peut se faire par groupe d’utilisateurs.

Présentation de PPP

PPP (Point-to-Point Protocol) est un protocole de communication entre deux ordinateurs qui utilisent une interface série (cas d’un ordinateur personnel connecté sur une ligne téléphonique commutée à un FAI, par exemple). Concernant le modèle OSI, PPP propose un mécanisme d’encapsulation de couche 2 pour autoriser les paquets de n’importe quel protocole à voyager à travers les réseaux IP. PPP utilise le protocole LCP (Link Control Protocol) pour établir des connexions, ainsi que pour la configuration et les tests. Une fois le LCP initialisé, un ou plusieurs NCP (Network Control Protocols) peuvent être utilisés pour transp orter du trafic pour une suite de protocoles donnée, de sorte que des protocoles multiples puissent être reliés par la même connexion. Par exemple, les trafics IP et IPX peuvent tous deux partager une liaison PPP.

L’authentification est une option de PPP. Les protocoles d’authentification pris en charge sont : PAP (Password Authentication Protocol), CHAP (Challen ge Hands hake Aut henticati on Protoc ol) et M icros oft CHA P (versi ons 1 et 2). Lorsque l’on utilise un protocole d’authentification, au moins l’un des nœuds doit s’authentifier avant que les paramètres de la couche réseau puissent être négociés à l’aide de NCP. Pendant la négociation LCP et NCP, des paramètres optionnels tels que le chiffrement peuvent également être négociés.

Configuration du client PPPoE

L’interface PPPoE. Puisque le protocole PPPoE exécute PPP via Ethernet, le firewall a besoin d’utiliser l’une des interfaces Ethernet normales pour exécuter PPPoE via celle-ci. Chaque tunnel PPPoE est considéré comme une interface logique par NetDefendOS, avec les mêmes capacités de routage et de configuration que les interfaces habituelles, l’ensemble de règles IP étant appliqué à la totalité du trafic. Le trafic réseau qui arrive vers le firewall à travers le tunnel PPPoE utilisera l’interface tunnel PPPoE comme interface source. L’interface tunnel PPPoE sera l’interface de destination pour le trafic sortant. Comme avec toute interface, une ou plusieurs routes sont définies de telle sorte que NetDefendOS puisse identifier les adresses IP en provenance desquelles il doit accepter le trafic et vers lesquelles il doit envoyer le trafic par le tunnel PPPoE. Vous pouvez configurer le client PPPoE de manière à utiliser un nom de service permettant de distinguer les différents serveurs sur le même réseau Ethernet.

Informations relatives à l’adresse IP. PPPoE utilise l’attribution automatique des adresses IP, comme le protocole DHCP. Lorsque NetDefendOS reçoit ces informations relatives à l’adresse IP de la part du FAI, il les stocke dans un objet réseau et les utilise en tant qu’adresse IP de l’interface.

Authentification utilisateur. Si le FAI exige une authentification utilisateur, vous pouvez configurer le no m d’utilisateur et le mot de passe dans NetDefendOS pour un envoi automatique en direction du serveur PPPoE.

Connexion à la demande. Si la connexion à la demande est activée, la connexion PPPoE sera uniquement opérationnelle lorsqu’il y aura du trafic sur l’interface PPPoE. Il est possible de configure r la façon dont le firewall détecte une activité sur l’interface, sur le trafic sortant, le trafic entrant ou les deux. Vous pouvez également configurer la durée d’inactivité avant la déconnexion du tunnel.

Fondamentaux

Exemple 3.12. Configuration d’un client PPPoE sur l’interface WAN avec routage du trafic via PPPoE

Interface de ligne de commande

gw-world:/> add Interface PPPoETunnel PPPoEClient EthernetInterface=wan Network=all-nets Username=exampleuser Password=examplepw

Interface Web

Sélectionnez Interfaces > PPPoE > Add > PPoE Tunnel (Interfaces > PPPoE > Ajouter > Tunnel PPoE).

Saisissez :

Name (nom) : PPPoEClient (client PPPoE) Physical Interface (interface physique) : wan Remote Network (réseau distant) : all-nets (tout-réseau, car l’ensemble du trafic sera routé vers le tunnel) Service Name (nom du service) : nom de service communiqué par le fournisseur d’accès Username (nom d'utilisateur) : nom d’utilisateur communiqué par le fournisseur d’accès Password (mot de passe) : mot de passe communiqué par le fournisseur d’accès

Confirm Password (confirmer le mot de passe) : Retype the password (retapez le mot de passe) Dans le menu Authentication (authentification), précisez quel protocole d’authentification vous souhaitez utiliser (s’il n’est pas spécifié, le paramètre par défaut sera utilisé)

Désactivez l’option Enable dial-on-demand (Activer la connexion à la demande)

Dans le menu Advanced (Avancé), si l’option Add route for remote network (Ajouter une rou te pour le

réseau distant) est activée, alors une nouvelle route sera ajoutée pour l’interface

Cliquez sur OK.

Remarque

Pour garantir une connexion point-à-point via Ethernet, chaque session PPP doit connaître l’adresse Ethernet du nœud distant et créer un identifiant de session unique. PPPoE intègre un protocole de détection qui permet ce processus.

Tunnels GRE

Présentation. Le protocole GRE (Generic Router Encapsulation) est un simple protocole d’encapsulation qui peut être utilisé chaque fois qu’il est nécessaire d’acheminer le trafic par un tunnel à travers les réseaux et/ou via des périphériques réseau. Le protocole GRE ne propose pas de fonctions de sécurité, mais son utilisation provoque ainsi une surcharge extrêmement faible.

Utilisation du protocole GRE. Le protocole GRE est généralement utilisé pour offrir une méthode permettant de

connecter ensemble deux réseaux à travers un troisième réseau tel que Internet. Les deux réseaux reliés communiquent par un protocole commun qui est acheminé par tunnel grâce au protocole GRE par le réseau intermédiaire. Exemples d’utilisation du protocole GRE :

Fondamentaux

Pour passer à travers un équipement réseau qui bloque un protocole donné. Pour la tunnelisation du trafic IPv6 via un réseau IPv4. Lorsqu’un flux de données UDP doit faire l’objet d’un envoi en multidiffusion et qu’il est nécessaire de passer

par un périphérique réseau qui ne prend pas en charge la multidiffusion. Le protocole GRE autorise la tunnelisation via le périphérique réseau.

Sécurité et performances du protocole GRE. Un tunnel GRE n’utilise pas de chiffrement pour communiquer et n’est donc pas, par définition, sécurisé. La sécurité doit être assurée par le protocole acheminé par tunnel. L’avantage de ce défaut de chiffrement du protocole GRE sont les hautes performances garanties par la faible surcharge lors du traitem ent du trafic. Le défaut de chi ffrement peut êt re acceptable da ns certaines circo nstances si la tunnelisation est effectuée à travers un réseau interne qui n’est pas public. Configuration du protocole GRE. Comme certains autres tunnels de NetDefendOS tels que le tunnel IPsec, un tunnel GRE est considéré comme une interface logique par NetDefendOS, avec les mêmes capacités de filtrage, de mise en forme du trafic et de configuration qu’une interface standard. Les options du protocole GRE sont :

Adresse IP : adresse IP de l’interface d’envoi. Cette information est facultative et peut rester vide. Si elle est

vide, l’adresse IP source sera l’adresse de l’hôte local par défaut : 127.0.0.1.

Réseau à distance : réseau distant auquel sera connecté le tunnel GRE. Extrémité distante : adresse IP du périphérique distant auquel sera connecté le tunnel. Utilisation d’une clé de session : si nécessaire, vous pouvez spécifier un numéro unique pour ce tunnel. Ce

paramètre autorise plusieurs tunnels GRE à fonctionner entre deux extrémités identiques. La variable clé de session permet de les différencier.

Total de contrôle d’encapsulation supplémentaire : le protocole GRE permet un total de contrôle

supplémentaire au-delà du total de contrôl e IPv4. Cela perm et une vérification suppl émentaire de l’inté grité des données.

Les paramètres avancés d’une interface GRE sont :

Ajouter automatiquement une route pour un réseau distant : on vérifiera généralement cette option pour que la

table de routage soit mise à jour automatiquement. Une solution alternative consiste à créer manuellemen t la route souhaitée.

Adresse à utiliser comme IP source : il est possible de spécifier une adresse IP particulière en tant qu’IP de

l’interface source pour le tunnel. Ensemble de règles IP et GRE. Un tunnel GRE établi ne signifie pas automatiquement que l’ensemble du trafic en provenance ou à destination de ce tunnel est autorisé. Bien au contraire, l e trafic réseau en provenance du tunnel GRE sera transféré vers l’ensemble de règles IP de NetDefendOS pour être évalué. Le tunnel GRE associé portera le nom de l’interface source du trafic réseau. Ceci est également valable pour le trafic en direction opposée, c’est-à-dire en direction d’un tunnel GRE. De plus, il faut définir une route pour que NetDefendOS identifie les adresses IP qui doivent être acceptées et envoyées par le tunnel.

Exemple de cas de figure GRE. Le schéma ci-dessous illustre un cas de figure GRE type, où deux firewalls D-Link A et B doivent communiquer l’un avec l’autre à travers le réseau interne intermédiaire 172.16.0.0/16.

Tout le trafic transitant entre A et B est acheminé par tunnel à travers le réseau intermédiaire au moyen d’un tunnel GRE. Le réseau étant interne et non public, aucun chiffrement n’est requis.

Fondamentaux

Figure 3.1. Exemple de cas de figure GRE

Configuration du firewall D-Link « A ». En supposant que le réseau 192.168.10.0/24 est un réseau lannet sur

l’interface lan, voici les étapes de configuration de NetDefendOS sur le firewall A : Dans le carnet d’adresses, configurez les objets IP suivants :

remote_net_B: 192.168.11.0/24 remote_gw: 172.16.1.1 ip_GRE: 192.168.0.1

Créez un objet tunnel GRE nommé GRE_to_B ayant les paramètres suivants :

Adresse IP : ip_GRE: Réseau distant : remote_net_B: Extrémité distante : remote_gw: Utilisation d’une clé de session : 1 Total de contrôle d’encapsulation supplémentaire : activé

Définissez une route dans la table de routage principale qui achemine l’ensemble du trafic vers remote_net_B sur

l’interface GRE GRE_to_B. Cette opération n’est pas nécessaire si l’option Add route for remote network (Ajouter une route pour un réseau distant) est activée dans l’onglet Advanced (Avancé), car la route sera alors ajoutée automatiquement.

Créez les règles suivantes dans l’ensemble de règles IP, qui autorisent le trafic à traverser le tunnel :

Action Interface src Réseau src Interface de dest. Réseau de dest. Service

Nom

To_B Autoriser lan lannet GRE_to_B remote_net_B: Tous From_B Autoriser GRE_to_B remote_net_B: lan lannet Tous

Configuration du firewall D-Link « B ». En supposant que le réseau 192.168.10.0/24 est un réseau lannet sur l’interface lan, voici les étapes de configuration de NetDefendOS sur le firewall B :

Dans le carnet d’adresses, configurez les objets IP suivants :

Fondamentaux

remote_net_A: 192.168.10.0/24 remote_gw: 172.16.0.1 ip_GRE: 192.168.0.2

Créez un objet tunnel GRE nommé GRE_to_A ayant les paramètres suivants :

Adresse IP : ip_GRE: Réseau distant : remote_net_A: Extrémité distante : remote_gw: Utilisation d’une clé de session : 1 Total de contrôle d’encapsulation supplémentaire : activé

Définissez une route dans la table de ro utage principale qui achemine l’ensemble du trafic vers remote_net_A sur

l’interface GRE GRE_to_A. Cette opération n’est pas nécessaire si l’option Add route for remote network (Ajouter une route pour un réseau distant) est activée dans l’onglet Advanced (Avancé), car la route sera alors ajoutée automatiquement.

Créez les règles suivantes dans l’ensemble de règles IP, qui autorisent le trafic à traverser le tunnel :

Action Interface src Réseau src Interface de dest. Réseau de dest. Service

Nom

To_A Autoriser lan lannet GRE_to_A remote_net_A: Tous From_A Autoriser GRE_to_A remote_net_A: lan lannet Tous

Groupes d’interfaces

Il est possible de regrouper plusieurs interfaces de NetDefendOS pour former un Groupe d’interfaces. Ce groupe logique peut par la suite être soumis à des règles communes et désigné par un nom de groupe dans l’ensemble de règles IP et dans les règles d’authentification utilisateur.

Un groupe peut être composé d’interfaces Ethernet habituelles, d’interfaces VLAN ou de tunnels VPN et les membre d’un groupe ne doivent pas être du même type. Un groupe peut être composé, par exemple, de deux interfaces Ethernet et de quatre interfaces VLAN.

Exemple 3.13. Création d’un groupe d’interfaces

Interface de ligne de commande

gw-world:/> add Interface InterfaceGroup examplegroup Members=exampleif1,exampleif2

Interface Web Sélectionnez Interfaces > Interface Groups > Add > InterfaceGroup (Interfaces > Groupes d’interfaces > Ajouter

> Groupe d’interfaces).

Saisissez les informations suivantes pour définir le groupe :

Name (nom) : nom du groupe qui sera utilisé ultérieurement. Security/Transport Equivalent (équivalent sécurité/transport) : lorsque cette option est activée, vous pouvez

utiliser le groupe d’interfaces en tant qu’interface de destination dans les règles pour lesquelles les

connexions peuvent nécessiter d’être permutées entre les interfaces. Le Route Fail-Over (reprise de routes) et l’OSPF sont des exemples d’applications.

Interfaces : sélectionnez les interfaces à placer dans le groupe

Cliquez sur OK.

Fondamentaux

ARP

Présentation

ARP (Address Resolution Protocol) est un protocole qui mappe une adresse de protocole de couche réseau vers l’adresse matérielle d’une couche de liaison de données. Il est utilisé pour traduire une adresse IP dans l’adresse Ethernet correspondante. Il fonct ionne sur la couche OSI Data Link (co uche 2 : consultez l’Annexe D, La structure OSI) et est encapsulé par des en-têtes Ethernet pour la transmission.

Un hôte du réseau Ethernet peut communiquer avec un autre hôte uniquement s’il connaît l’adresse Ethernet (adresse MAC) de cet hôte. Des protocoles de plus haut niveau tels que le protocole IP utilisent des adresses IP foncièrement différentes d’un plan d’adressage de plus bas niveau comme les adresses MAC. ARP est utilisé pour retrouver l’adresse MAC d’un hôte grâce à son adresse IP.

Lorsqu’un hôte a besoin de traduire une adresse IP dans l’adresse Ethernet correspondante, il transmet un paquet de requêtes ARP. Le paquet de requêtes ARP contient l’adresse MAC source et les adresses IP source et de destination. Chaque hôte du réseau local reçoit ce paquet. L’hôte avec l’adresse IP de destination spécifiée envoie un paquet de réponses ARP à l’hôte source avec son adresse MAC.

ARP dans NetDefendOS

NetDefendOS propose non seulement une prise en charge standard du protocole ARP, mais ajoute également un certain nombre de contrôles de sécurité au cœur de la mise en œuvre du protocole. Par exemple, NetDefendOS n’acceptera pas par défaut les réponses ARP pour lesquelles le système n’a envoyé aucune requête ARP correspondante. Sans ce type de protection, le système serait vulnérable aux « détournements de connexion ».

NetDefendOS prend en charge à la fois l ’ARP dy nami que et st atique, ce derni er éta nt disponi ble en de ux m odes : Publish et XPublish.

L’ARP dynamique est le mode de fonctio nnement principal d’ ARP, dans lequel Net DefendOS envoie de s requêtes ARP à chaque fois qu’il a besoin de tradui re une adresse IP en adresse Ethernet. Les réponses ARP sont st ockées dans le cache ARP du système.

L’ARP statique est utilisé pour verrouiller manuellement une adresse IP sur une adresse Ethernet spécifiq ue. Ce procédé est expliqué plus en détail dans les sections ci-dessous.

Cache ARP

Le cache ARP est la table temporaire de NetDefendOS pour stocker le mappage entre les adresses IP et Ethernet. Le cache ARP est vide au démarrage du système et ses entrées seront remplies si besoin.

Le contenu d’un cache ARP typique (minimal) est similaire à la table suivante :

Adresse IP Adresse Ethernet Expiration

Type

Dynamique 192.168.0.10 08:00:10:0f:bc:a5 45 Dynamique 193.13.66.77 0a:46:42:4f:ac:65 136 Publié 10.5.16.3 4a:32:12:6c:89:a4 -

Le premier élément de ce cache ARP est une entrée ARP dynamique qui nous apprend que l’adresse IP

192.168.0.10 est mappée sur l’adresse Ethernet 08:00:10:0f:bc:a5. Le second élément mappe de manière dynamique l’adresse IP 193.13.66.77 sur l’adresse Ethernet 0a :46 :42 :4f :ac :65. Enfin, le troisième élément est une entrée ARP statique qui associe l’adresse IP 10.5.16.3 à l’adresse Ethernet 4a :32 :12 :6c :89 :a4.

La troisième colonne de la table, Expiration, est utilisée pour indiquer la durée pendant laquelle l’entrée ARP sera valide. Le premier élément, par exemple, possède une valeur d’expiration de 45, ce qui signifie que cette entrée sera rendue invalide et supprimée du cache ARP après 45 secondes. Si un trafic est envoyé à l’adresse IP

192.168.0.10 après l’expiration, NetDefendOS émet une nouvelle requête ARP. Le temps d’expiration par défaut pour les entrées ARP dynamiques est de 900 secondes (15 minutes). Vous

pouvez le changer en modifiant le paramètre avancé ARPExpire. Le paramètre ARPExpireUnknown précise combien de temps NetDefendOS va garder en mémoire les adresses injoignables. Cette précaution permet de s’assurer que NetDefendOS ne sollicite pas ces adresses en continu. La valeur par défaut pour ce paramètre est de 3 secondes.

Fondamentaux

Exemple 3.14. Affichage du cache ARP

Vous pouvez afficher le contenu du cache ARP à partir de l’interface de ligne de commande. Interface de ligne de commande

gw-world:/> arp -show

ARP cache of iface lan Dynamic 10.4.0.1 = 1000:0000:4009 Expire=196 Dynamic 10.4.0.165 = 0002:a529:1f65 Expire=506

Alignement du cache ARP. Si un hôte de votre réseau a récemment été remplacé par un nouveau matériel tout en conservant la même adresse IP, il est très probable qu’il dispose d’une nouvelle adresse Ethernet. Si NetDefe ndOS possède une entrée ARP pour cet hôte, l’adresse Ethernet de cette entrée sera invalide, ce qui empêchera les données envoyées vers l’hôte de parvenir à destination.

Après le temps d’expiration ARP, NetDefendOS apprendr a évidemment la nouvelle adresse Ethernet de l’hôte demandé, mais il arrive parfois que l’on d oive force r une no uvelle requête m anuellem ent. Le pl us sim ple consist e à aligner le cache ARP, opération qui supprime toutes les entrées ARP dynamiques du cache, ce qui force NetDefendOS à émettre de nouvelles requêtes ARP.

Exemple 3.15. Alignement du cache ARP

Cet exemple montre comment aligner le cache ARP à partir de l’interface de ligne de commande. Interface de ligne de commande

gw-world:/> arp -flush ARP cache of all interfaces flushed.

Taille du cache ARP. Par défaut, le cache ARP peut détenir 4 096 entrées ARP à la fois. Cela convient pour la plupart des déploiements, mais il se peut que vous deviez parfois ajuster cette valeur, par exemple lorsque plusieurs LAN très volumineux sont connectés directement au firewall. Vous pouvez le faire en modifiant le paramètre avancé ARPCacheSize.

Les « tables de hachage » sont utilisées pour localiser des entrées dans le cache ARP. Pour une efficacité maximale, un hachage doi t être deux fois plus grand que l a ta ble q u’il i ndexe, donc si le LAN à con nexion directe le plus volumineux contient 500 adresses IP, la table de hachage ARP doit comporter au moins 1 000 entrées. L’administrateur peut modifier le paramètre avancé ARPHashSize pour traduire des besoins réseau spécifiques. La valeur par défaut pour ce paramètre est 512.

Le paramètre ARPHashSizeVLAN est similaire au paramètre ARPHashSize mais il affecte la taille de hachage pour les interfaces VLAN uniquement. La valeur par défaut est 64.

Entrées ARP statiques et publiées

NetDefendOS prend en charge la définition d’entrées ARP statiques (association statique d’adresses IP aux adresses Ethernet) ainsi que la publication d’adresses IP avec une adresse Ethernet spécifique.

Entrées ARP statiques. Les éléments ARP statiques peuvent être utiles lorsqu’un périphérique signale une

adresse Ethernet incorrecte en réponse aux requêtes ARP. Certains ponts entre les postes de travail, comme les modems radio, peuvent rencontrer ce type de problèmes. Vous pouvez également les utiliser pour verrouiller une adresse IP sur une adresse Et hernet spécifi que dans le but d’augm enter la sécurit é ou pour éviter le déni de service lorsque des utilisateurs pirates se trouvent dans un réseau. Notez toutefois qu’une telle protection s’applique uniquement aux paquets envoyés en direction de cette adresse IP, et non aux paquets envoyés à partir de celle-ci.

Fondamentaux

Exemple 3.16. Définition d’une entrée ARP statique

Cet exemple va créer un mappage statique entre l’adresse IP 192.168.10.15 et l’adresse Ethernet 4b:86:f6:c5:a2:14 sur l’interface lan.

Interface de ligne de commande

gw-world:/> add ARP Interface=lan IP=192.168.10.15 Mode=Static

MACAddress=4b-86-f6-c5-a2-14

Interface Web Sélectionnez Interfaces > ARP > Add > ARP (ARP > Ajouter > ARP). Dans les listes déroulantes, sélectionnez les options suivantes :

Mode : Static (statique) Interface : lan

Saisissez les paramètres suivants :

Adresse IP : 192.168.10.15 MAC (Adresse MAC) : 4b-86-f6-c5-a2-14

Cliquez sur OK. Entrées ARP publiées. NetDefendOS pren d en charge la publication d’entrées ARP, ce qui signifie que vous

pouvez définir des adresses IP (et , si nécessaire, des a dresses Ethe rnet) pour une i nterface. Net DefendOS propose alors des réponses ARP pour les requêtes ARP qui se rapportent à ces adresses IP.

Ce processeur a deux utilités majeures : Donner l’impression que l’interface de NetDefendOS possède plusieurs adresses IP. Aider l’équipement réseau proche répondant aux requêtes ARP de manière incorrecte. Cet usage est toutefois

moins courant. Le premier usage est pratique lorsque plusieurs plages IP distinctes se trouvent sur un seul LAN. Les hôtes de

chaque plage IP peuvent alors utiliser une passerelle de leur propre plage lorsque ces adresses de passerelles sont publiées sur l’interface NetDefendOS correspondante.

Un autre usage consiste à publier plusieurs adresses sur une interface externe, ce qui permet à NetDefendOS d’adresser de manière statique les c ommunications ve rs ces adresses et de l es transmettre en di rection des serveurs internes qui possèdent des adresses IP privées.

Il existe deux modes de publicati on : Publis h et XP ubl ish. La dif férence e ntre l es de ux e st que Xpu blish « ment » quant à l’adresse Ethernet de l’expédite ur se trouvant dans l’en-tête Ethe rnet ; celle-ci est définie de manière à être identique à l’adresse Ethernet publiée plutôt qu’à l’adresse Ethernet réelle de l’interface Ethernet. Si une adresse Ethernet publiée est identique à l’adresse Ethernet de l’interface, il n’y aura pas de différe nce si vous sélectionnez Publish ou XPublish. Dans les deux cas, le résultat sera le même.

Conseil

Dans la configuration des entrées ARP, les adresses peuvent uniquement être publiées une à la fois. Toutefois, vous pouvez utiliser la fonctionnalité ProxyARP pour gérer la publication de réseaux entiers (reportez-vous à la section nommée « ARP Proxy »).

Fondamentaux

Paramètres ARP avancés

Cette section présente certains paramètres avancés du protocole ARP. Dans la plupart des cas, vous n’avez pas besoin de modifier ces paramètres, mais pour certains déploiements, des modifications peuvent être requises. La plupart se trouvent dans WebUI, via ARP

Diffusion et multidiffusion. Les requêtes et les réponses ARP qui contiennent des adresses de diffusion ou multidiffusion ne sont, en général, jamais correctes, à l’exception de certains périphériques d’équilibrage du volume de trafic et de redondance, qui utilisent des adresses à multidiffusion de la couche matérielle.

Le comportement par défaut de NetDefendOS consiste à ignorer et à consigner de telles requêtes et réponses ARP. Vous pouvez toutefois le changer en modifiant les paramètres avancés ARPMulticast et ARPBroadcast.

Réponses ARP non sollicitées. Il est tout à fait possible pour un hôte présent sur le LAN d’envoyer une réponse ARP au firewall, même si aucune req uête AR P corre sponda nte n’a été effectuée. Selon l es spécifications ARP, le récepteur doit accepter ce type de réponses ARP. Toutefois, étant donné que ce processus peut faciliter le détournement de connexions locales, NetDefendOS ignore et consigne normalement ces réponses.

Vous pouvez changer ce comportement en modifiant le paramètre avancé UnsolicitedARPReplies. Requêtes ARP. La spécification ARP déclare qu’un hôte doit mettre à jour son cache ARP avec les données des

requêtes ARP reçues des autres hôtes. Toutefois, étant donné que cette procédure peut faciliter le détournement de connexions locales, NetDefendOS ne l’autorise pas.

> Advanced Settings (ARP > Paramètres avancés).

Pour rendre ce comportement compatible avec la spécification RFC 826, l’administrateur peut modifier le paramètre avancé ARPRequests. Même lorsque le paramètre ARPRequests est défini sur « Drop » (Ignorer), ce qui signifie que le paquet est rejeté sans être stocké, le sy stème va tout de même répondre à ce paquet, à condition que d’autres règles acceptent la demande.

Modifications du cache ARP. NetDefendOS propose quel ques paramèt res qui c ontrôle nt l a façon de modi fier le cache ARP.

Une réponse ou une requête ARP reçue peut modifier un élément existant du cache ARP. Le fait d’autoriser cette opération peut permettre le détournement de connexions locales. Toutefois, si on ne l’autorise pas, cela peut causer des problèmes si, par exemple, un adaptateur réseau est remplacé, car NetDefendOS n’acceptera pas la nouvelle adresse tant que l’entrée du cache ARP précédente n’a pas expiré.

Vous pouvez régler les paramètres avancés ARPChanges pour modifier le comportement. Le comportement par défaut de NetDefendOS consiste à autoriser les modifications, mais elles sont dans ce cas toutes consignées.

On rencontre une situation similaire lorsque les informations contenues dans les réponses ou dans les requêtes ARP coïncident avec les entrées statiques du cache ARP. Cela n’est, bien sûr, jamais autorisé. Toutefois, la modification du paramètre avancé StaticARPChanges autorise l’administrateur à spécifier si oui ou non de telles situations doivent être consignées.

IP expéditeur 0.0.0.0. Il est possible de configurer la façon dont NetDefendOS traite les requêtes ARP qui possèdent l’IP expéditeur 0.0.0.0. De tels IP expéditeur ne sont jamais valides en réponse, mais les unités réseau qui n’ont pas encore détecté leur adresse IP posent parfois des requêtes ARP avec un IP expéditeur « non spécifié ». Normalement, ces réponses ARP sont ignorées et consignées, mais vous pouvez changer ce comportement en modifiant le paramètre avancé ARPQueryNoSenderIP.

Correspondance des adresses Ethernet. Par défaut, NetDefendOS exige que l’adresse de l’expé diteur au niveau Ethernet soit conforme à l’adresse Ethernet indiquée par les données ARP. Si ce n’est pas le cas, la réponse sera ignorée et consignée. Vous pouvez changer ce comportement en modifiant le paramètre avancé ARPMatchEnetSender.

Fondamentaux

L’ensemble de règles IP

Règles de sécurité

Caractéristiques des règles. Les règles de sécurité NetDefendOS conçues par l’administrateur décident de la façon dont le trafic peut traverser un firewall D-Link. Dans NetDefendOS, les règles sont définies par différents ensembles de règles NetDefendOS. Ces ensembles de règles partagent une manière commune de spécifier les critères de filtrage qui déterminent le type de trafic auquel elles vont s’appliquer. Cet ensemble de critères comprend :

Une interface source Interface ou groupe d’interfaces qui reçoit le paquet au niveau du firewall

Un réseau source Réseau contenant l’adresse IP source du paquet. Il peut s’agir d’un objet IP

Une interface de destination Interface ou groupe d’interfaces par lequel le paquet quitte le firewall D-Link. Il

Un réseau de destination Réseau auquel appartient l’adresse IP de destination du paquet. Il peut s’agir

D-Link. Il peut aussi s’agir d’un tunnel VP N .

NetDefendOS qui définit une adresse IP unique ou une plage d’adresses.

peut aussi s’agir d’un tunnel VPN.

d’un objet IP NetDefendOS qui définit une adresse IP unique ou une plage d’adresses.

Un service Type de protocole auquel appartient l e paquet. Les objet s de service définissent

un type de protocole/de port, par exemple, HTTP ou ICMP. Vous pouvez également définir des services personnalisés (reportez-vous à la section Services pour plus d’informations).

Les ensembles de règles de NetDefendOS, qui utilisent tous les mêmes paramètres de filtrage, comprennent les éléments suivants :

Les règles IP. Les « pipe rules » ou règles de tuyau (reportez-vous à la section intitulée « Mise en forme du trafic »). Les politiques d’acheminement en fonction de règles (reportez-vous à la sectio n intitulée « Acheminement en

fonction de règles »). Les règles IDP (reportez-vous à la section intitulée « Prévention et détection des intrusions »). Les règles d’authentification – réseau/interface source uniquement (reportez-vous au chapitre 8, Authentification

utilisateur). Spécification d’une interface ou d’un réseau. Au moment de spécifier le critère de filtrage dans l’un des

ensembles de règles mentionnés ci-dessus, vous pouvez utiliser trois options utiles prédéfinies : Pour un réseau source ou de destination, l ’option « all-nets » (tout-réseau) équivaut à l’adresse IP 0.0.0.0/0, ce qui

implique que toute adresse IP est acceptable. Pour une interface source ou de destination, vous pouvez utiliser l’option « Any » afin que NetDefendOS ne

s’occupe pas de l’interface à destination ou en provenance de laquelle transite le trafic. Vous pouvez définir l’interfac e de destination en tant que « core ». Cela signifie que le trafic, par exemple un Ping

ICMP, est destiné au firewall D-Link lui-même et que c’est NetDefendOS qui va lui répondre. Règles IP. L’ensemble de règles IP est le plus important de ces ensembles de règles de sécurité. Il définit la

fonction essentielle de filtrage des paquets de NetDefendOS, en régulant ce qui est autorisé ou non à traverser le firewall D-Link et, si nécessaire, la façon dont s’appliquent les traductions d’adresses comme NAT.

Il existe deux approches possibles pour définir comment doit être traité le trafic qui traverse NetDefendOS :

Sauf autorisation spécifique, tout est refusé Sauf refus spécifique, tout est autorisé Pour permettre la meilleure sécurité possible, la première de ces approches est adoptée par NetDefendOS et

l’action « Drop » (Ignorer) est la règle par défaut de l’ensemble de règles IP, ce qui signifie que l’ensemble du trafic est refusé. Pour permettre tout trafic (notamment les réponses de NetDefendOS aux requêtes Ping ICMP), l’administrateur doit définir des rè gl es IP qui autorisent le trafic à traverser le firewall D-Link.

Bien que le rejet des paquets est réalisé sans qu’une règle IP spécifique existe, il est recommandé, à des fins de consignation, qu’une règle IP Drop avec consignation activée soit placée comme dernière règle dans l’ensemble de règles IP.

Fondamentaux

Évaluation des règles IP

Lorsqu’une nouvelle connexi on TC P/ IP est établ ie à t rave rs le firewall D-Link, la liste des règles IP est exam inée de haut en bas jusqu’à ce qu’une règle correspondant aux paramètres de la nouvelle connexion soit trouvée. L’action de la règle est alors exécutée.

Si l’action l’autorise, l’établissement de la nouvelle connexion se poursuit. Une nouvelle entrée (ou un état) représentant la nouvelle connexion est ensuite ajoutée à la table d’état interne de NetDefendOS, ce qui permet de surveiller les connexions ouvertes et actives qui utilisent le firewall D-Link. Si l’action est Drop (Ignorer) ou Reject (Rejeter), alors la nouvelle connexion est refusée.

Filtrage dynamique. Après l’évaluation de l’ouverture de la connexion par la règle initiale, les prochains paquets appartenant à cette connexion n’a uront pas à êt re exam inés indi vi duel lem ent pa r l’en sembl e de règl es. Au li eu de cela, un algorithme particulièrement efficace recherche chaque paquet dans la table pour déterminer s’il appartient à une connexion déjà établie.

Cette approche est appelée filtrage dynamique et ne s’applique pas seulement aux protocol es dynami ques tels que TCP mais également aux protocoles statiques tels que UDP et ICMP, au moyen de « pseudo-connexions ». Cette approche signifie que l’examen avec l’ensemble de règles IP est uniquement effectué lors de la phase initiale d’ouverture de connexion. La taille de l’ensemble de règles IP a par conséquent un effet négligeable sur le débi t global.

Le premier principe de correspondance. Si plusieurs règles correspondent aux mêmes paramètres, la première règle de correspondance dans un balayage de haut en bas est celle qui décide de la manière dont la connexion va être gérée.

Les règles SAT sont une excepti on car elles repo sent sur un ap pariement avec une seconde règle pour fonctionner. Après avoir rencontré une règle SAT correspondante, la recherche va se poursuivre pour trouver une seconde règle qui corresponde (pour plus d’informations, reportez-vous à la section « Traduction d’adresses statiques »).

Trafic non-correspondant. Les paquets entrants qui ne correspondent à aucune règle de l’ensemble de règles et qui ne possèdent pas de connexion correspondante dans la table d’état seront automatiquement soumis à l’action « Drop » (Ignorer). Pour être plus explicite, une règle finale appelée DropAll, possédant une action « D rop » (Ignorer) configurée sur all-nets comme réseau source/de destination et all comme interface source/de destination, devrait exister dans l’ensemble de règles.

Actions des règles IP

Une règle se compose de deux parties : les paramètres de filtrage et la mesure à prendre si une correspondance existe avec ces paramètres. Comme décrit ci-dessus, les paramètres de toute règle NetDefendOS, notamment les règles IP, sont :

Une interface source Un réseau source Une interface de destination Un réseau de destination

Un service L’élément service d’une règle IP est également important car si un objet de la passerelle ALG (Application Layer

Gateway) doit être appliqué au trafic, il doit être associé à un objet de service (reportez-vous à la section « Passerelle ALG »).

Lorsqu’une règle IP est déclenchée par une correspondance, l’une des actions suivantes peut se produire : Autoriser Le paquet est autorisé à passer. Étant donné que la règle est appliquée uniquement à l’ouverture

d’une connexion, une entrée est établie dans la « table d’état » pour enregistr er l’ouverture d’une connexion. Le reste des paquets attribués à cette connexion traversera le « moteur dynamique » de NetDefendOS.

FwdFast Laisse le paquet traverser le firewall D-Link sans configurer d’état qui lui soit spécifique dans la

table d’état. Cela signifie que le processus de filtrage dynamique est évité et est, par conséquent, moins sécurisé que les règles Allow ou NAT. La durée de traitement des paquets est également plus lente que pour les règles Allow car chaque paquet est comparé à l’ensemble de règles tout entier.

NAT La règle NAT fonctionne comme la règle Allow, mais avec la traduction dynamique d’adresse

(NAT) activée (pour une description détaillée, reportez-vous à la section intitulée « Traduction dynamique des adresses réseau » du chapitre 7, Traduction d’adresses).

SAT Cette action commande à NetDefendOS de procéder à la traduction d’adresse statique. Une règle

SAT nécessite toujours une règle Allow, NAT ou FwdFast correspondante en plus de l’ensemble de règles (pour une description détaillée, reportez-vous à la section intitulée « Traduction d’adresse statique » du chapitre 7, Traduction d’adresse).

Fondamentaux

Drop (Ig norer) Cette action commande à NetDefendOS d’ignorer immédiate ment le paquet. Il s’agit d’une

version « impolie » de l’action Reject (Rejeter), car aucune réponse n’est envoyée à l’expéditeur. Elle est souvent préférable car elle ne donne, au pirate potentiel, aucune information sur ce qui est arrivé à leurs paquets.

Reject (Rejeter) Cette action fonctionne comme l’action Drop (Ignorer), mais retourne un message « TCP

RST » ou « ICMP Injoignable », qui informe l’ordinateur expéditeur que le paquet a été rejeté. Il s’agit d’une version « polie » de l’action Drop (Ignorer).

Connexions bidirectionnelles. Une erreur courante lors de la configuration des règles IP est de définir deux règles, l’une pour le trafic allant dans un sens et l’autre pour le trafic rentrant dans l’autre sens. En fait, presque toutes les règles IP autorisent un flux de trafic bidirectionnel une fois que la connexion initiale est configurée. Le réseau source et l’interface source dans la règle correspondent à la source de la requête de connexion initiale. Une fois qu’une connexion est autorisée et établie, le trafic peut alors circuler dans chaque direction.

L’exception à ce flux bidirectionnel sont les règles FwdFast. Si l’action FwdFast est utilisée, alors la règle n’autorisera pas le trafic à revenir de la destination à la source. Si un flux bidirectionnel est exigé, alors deux règles FwdFast sont requises, c’est-à-dire une pour chaque direction. C’est également le cas lorsqu’une règle FwdFast est utilisée avec une règle SAT.

Utilisation de Reject (Rejeter). Dans certaines situations, l’action Reject (Rejeter) est recommandée, plutôt que l’action Drop (Ignorer), car une réponse polie est exigée par NetDefendOS. Un exemple d’une telle situation est la réponse au protocole d’identification de l’utilisateur IDENT.

Modification des entrées de l’ensemble de règles IP

Après avoir ajouté différentes règl es à l’e nsem bl e de règle s, v ous pou vez cl iquer a vec le bo uton droi t de la souris sur la ligne de votre choix dans l’interface Web pour la modifier.

Un menu contextuel apparaît avec les options suivantes : Modifier Autorise la modification du contenu de la règle. Supprimer Supprime définitivement la règle de l’ensemble de règles.

Activer/Désactiver Permet de désactiver la règle en la conservant dans l’ensemble de règles. Lorsque cette

option est définie sur « Désactiver », la ligne de l’ensemble de règles n’affectera pas le trafic et apparaîtra grisée dans l’interface utilisateur. Vous pouvez la réactiver à tout moment.

Options de déplacement La dernière section du menu contextuel permet de déplacer la règle à un autre

emplacement dans l’ensemble de règles, afin de lui affecter une priorité différente.

Fondamentaux

Programmation

Dans certains cas de figure, il peut être utile de contrôler non seulement quelle fonctionnalité est activée, mais également à quel moment cette fonctionnalité est utilisée.

La politique informatique d’une entreprise peut, par exemple, stipuler que le trafic Web en prov enance d’un service spécifique est uniquement autorisé à sortir du service pendant les heures normales de bureau. Un autre exemple : l’authentification qui utilise une connexion VPN spécifique est autorisée uniquement les jours de semaine avant midi.

NetDefendOS répond à cette en fournissant des objets programmation, ou simplement des programmes, que vous pouvez sélectionner et utiliser avec différents types de règles de sécurité pour obtenir un con trôle en fon ction du temps. Cette fonctionnalité n’est en aucun cas limitée aux règles IP, mais est valide pour la plupart des types de règles, notamment les règles de mise en forme du trafic et les règles de détection et de prévention des intrusions (IDP). Un objet programme est, en d’autres termes, un composant très puissant qui peut autoriser une régulation détaillée des périodes d’activation ou de désacti vat i on des f onct io ns de NetDefendOS.

Un objet programme vous pe rmet d’indiq uer pl usieurs plage s horai res po ur chaq ue jo ur de la sem aine. De pl us, il est possible de spécifier des dates de début et de fin qui imposeront des contraintes supplémentaires à la programmation. Par exemple, v ous pouvez définir le program me suivant : le lundi et l e mardi, de 8 h 30 à 10 h 40 et de 11 h 30 à 14 h, le vendredi, de 14 h 30 à 17 h.

Important

Étant donné que les programmes dépendent de la date et de l’heure exacte, il est très important que la date et l’heure du système soient correctement paramétrées. De préférence, la synchronisation de l’heure a également été activée pour s’assurer que les règles planifiées seront activées et désactivées au bon moment. Pour plus d’informations, reportez-vous à la section « Configuration de la date et de l’heure ».

Exemple 3.17. Configuration d’une règle planifiée

Cet exemple crée un objet programme pour l es heures de bureau en sem aine et l’associe à une règl e IP qui autorise le trafic HTTP.

Interface de ligne de commande

gw-world:/> add ScheduleProfile OfficeHours Mon=8-17 Tue=8-17 Wed=8-17 Thu=8-17

Fri=8-17

gw-world:/> add IPRule Action=NAT Service=http SourceInterface=lan SourceNetwork=lannet DestinationInterface=any DestinationNetwork=all-nets Schedule=OfficeHours name=AllowHTTP

Interface Web Sélectionnez Objects > Schedules > Add > Schedule (Objets > Programmation > Ajouter > Programme). Saisissez les paramètres suivants :

Name (nom): OfficeHours (heures de bureau) Dans la liste, sélectionnez de 8 h à 17 h, du lundi au vendredi. Cliquez sur OK. Sélectionnez Rules > IP Rules > Add > IPRule (Règles > Règles IP > Ajouter > Règle IP).

Saisissez les paramètres suivants :

Fondamentaux

Name (nom): AllowHTTP (autoriser HTTP) Dans les listes déroulantes, sélectionnez les options suivantes :

Action : NAT

Service: http

Schedule (programmation) : OfficeHours ( h eures de bureau)

SourceInterface (interface source) : lan

SourceNetwork lannet (réseau source lannet)

DestinationInterface (interface de destination) : any (toutes)

DestinationNetwork (réseau de destination) : all-nets (tout réseau) Cliquez sur OK.

Certificats X.509

NetDefendOS prend en charge des certificats numériques conformes à la norme ITU-T X.509. Cela implique l’utilisation d’une hiérarchie de certificats X.509 avec une cryptographie à clé publique utilisée pour la distribution de clés et l’authentification d’entités.

Présentation

Un certificat X.509 est une preuve d’identité numérique. Il crée un lien entre une identité et une clé publique dans le but de définir si une clé publique appartient réellement au propriétaire supposé. Par ce processus, il empêche l’interception des données transférées par un tiers malveillant qui pourrait poster une fausse clé avec le nom et l’identifiant utilisateur d’un destinataire souhaité.

Certificats des tunnels VPN. L’usage prédominant des certificats dans NetDefendOS concerne les tunnels VPN. La façon la plus simple et la plus rapide de sécuriser les extrémités d’un tunnel est d’utiliser des clés pré-partagées (PSK). La complexité d’utilisation des clés PSK augmente avec la taille des réseaux VPN. Les certificats sont un moyen de mieux gérer la sécurité dans les réseaux plus importants.

Composants des certificats. Un certificat comprend les éléments suivants : Une clé publique : l’identité de l’utilisateur, par exemple son nom ou son identifiant utilisateur. Les signatures numériques : Une déclaration qui stipule que les informations contenues dans le certificat ont été

approuvées par une autorité de certification.

En combinant les informations ci-dessus, un certificat est une clé publique comprenant une identification, couplée à un cachet de certification d’un organisme agrée. Autorités de certification. Une autorité de certification (AC) est une entité agrée qui délivre des certificats à d’autres entités. L’autorité de certification signe numériquement tous les certificats qu’elle délivre. Une signature de l’autorité de certification vérifie l’identité du propriétaire du certificat et garantit que le certificat n’a pas été falsifié par un tiers.

Une autorité de certification se charge de vérifier que les informations de chaque certificat qu’elle délivre sont correctes. Elle doit également s’assurer que l’identité du certificat correspond à l’identité du propriétaire du certificat.

Une AC peut également délivrer des certificats à d’autres AC. Cela entraîne une hiérarchie de certificats sous forme d’arbre. L’AC située au plus ha ut de la hiérarchie est a ppelée l’AC racine. Dans cette hiérarchie, ch aque AC est signée par l’AC située juste au-dessus, à l’exception de l’AC racine qui est généralement signée par elle-même.

Un chemin de certification fait référence au chemin de certificats allant d’un certificat à un autre. Lors du processus de vérification de la validité d’un certificat d’utilisateur, le chemin entier partant du certificat d’utilisateur jusqu’au certificat du nœud agrée doit être examiné avant que la validité du certificat d’utilisateur ne soit établie.

Le certificat AC est identique à n’importe quel certificat, hormis le fait qu’il autorise la clé privée correspondante à signer d’autres certificats. Si la clé privée de l’AC est altérée, toute l’AC est également altérée, y compris tous les certificats qu’elle a signés.

Durée de validité. Un certificat n’est pas valide indéfiniment. Chaque certificat contient les dates de validité du certificat. Lorsque cette période de validité arrive à expiration, le certificat ne peut plus être utilisé et un nouveau certificat doit être délivré.

Listes de révocation de certificats. Une liste de révocation de certificats (CRL) contient une liste de tous les certificats qui ont été annulés avant leur date d’expiration. Ces cas de figure peuvent se présenter pour plusieurs raisons, notamment lorsque les clés du certificat ont été altérées de quelque manière que ce soit ou que le propriétaire du certificat a perdu les droits d’authentification qui utilisent ce certificat. Cela peut arriver, p ar exemple, si un employé a quitté l’entreprise qui a délivré le certificat.

Une CRL est régulièrement publiée sur un serveur auquel peuvent accéder tous les utilisateurs de certificats, au moyen des protocoles LDAP ou HTTP.

Les certificats contiennent souvent un champ de points de distribution CRL, qui spécifie l’emplacement à partir duquel la liste de révocation de certificats peut être téléchargée. Dans certains cas, les certificats ne contiennent pas ce champ. Dans ces cas-là, l’emplacement de la liste CRL doit être configuré manuellement.

Fondamentaux

L’AC met à jour sa CRL à un intervalle donné. La longueur de cet intervalle dépend de la configuration de l’AC. Généralement, elle varie entre une heure et plusieurs jours.

Approbation des certificats. Lorsqu’on utilise des certificats, NetDefendOS fait confiance à toute personne qui détient un certificat signé par une AC donnée. Avant qu’un certificat soit approuvé, la validité du certificat est vérifiée de la manière suivante :

Construction d’un chemin de certification jusqu’à la racine AC agréée. Vérification des signatures de tous les certificats contenus dans le chemin de certification. Recherche de chaque certificat dans la liste CRL afin de vérifier qu’aucun des certificats n’a été révoqué. Listes d’identification. En plus de vérifier les signatures des certificats, NetDefendOS utilise également des listes

d’identification. Une liste d’identification est une liste qui mentionne toutes les identités distantes qui possèdent un accès autorisé par un tunnel VPN spécifique, à condition que la procédure de validation du certificat décrite ci-dessus ait abouti.

Réutilisation des certificats racine. Dans NetDefendOS, les certificats racines doivent être considér és comme des entités globales qui peuvent être réutilisées entre les tunnels VPN. Même si un certificat racine est associé à un tunnel VPN dans NetDefendOS, il peut toujours être réutilisé avec le nombre d’autres tunnels VPN différents que l’on souhaite.

Certificats X.509 dans NetDefendOS

Les certificats X.509 peuvent être chargés sur le firewall D-Link pour être utilisés lors des authentifications IKE/IPsec, Webauth, etc. Deux types de certificats peuvent être chargés : les certificats auto-signés et les certificats distants appartenant à un nœud distant ou un serveur AC.

Exemple 3.18. Chargement d’un certificat X.509

Il peut s’agir d’un certificat auto-signé ou d’un certificat appartenant à un nœud distant ou à un serveur AC.

Interface Web Sélectionnez Objects > Authentication Objects > Add > Certificate (Objets > Objets d’authentification > Ajouter

> Certificat). Spécifiez un nom convenable pour le certificat. Sélectionnez l’une des options suivantes :

Upload self-signed X.509 Certificate (charger un certificat X.509 auto-signé)

Upload a remote certificate (charger un certificat distant) Cliquez sur OK et suivez les instructions.

Fondamentaux

Exemple 3.19. Association de certificats X.509 à des tunnels IPsec

Pour associer un certificat importé à un tunnel IPsec. Interface Web Sélectionnez Interfaces > IPsec. Affichez les propriétés du tunnel IPsec. Sélectionnez l’onglet Authentication (Authentification). Sélectionnez l’option Certificat X509. Sélectionnez la passerelle et les certificats racine corrects. Cliquez sur OK.

Configuration de la date et de l’heure

Pour assurer le bon fonction nement de NetDefendOS, il est important de configurer correctem ent la date et l’heure. Les règles planifiées, les mises à jour automatiques de l’IDP et des bases de données antivirus, ainsi que d’autres fonctionnalités du produit exigent que l’horloge système soit réglée avec précision. De plus, les messages de consignation sont horodatés pour indiquer l’instant où se produit un événement spécifique. Cela suppose non seulement une horloge qui fonctionne, mais aussi qu’elle est correctement synchronisée avec les autres périphériques du réseau.

Pour garantir une date et une heure précises, NetDefendOS utilise une horloge matérielle en temps réel intégrée. Cette horloge est également équipée d’une pile de sauvegarde qui la protège contre les coupures de courant temporaires. De plus, NetDefendOS prend en ch arge les protocoles de synchronisation horaire, reposant sur des requêtes envoyées à des serveurs externes spécifiques, pour ajuster automatiquement l’horloge.

Paramètres de date et heure généraux

Date et heure actuelles. L’administrateur peut configurer la date et l’heur e manuellement. Cela est recommandé lorsqu’une nouvelle installation de NetDefendOS est lancée pour la première fois.

Exemple 3.20. Configuration de la date et de l’heure actuelles

Pour ajuster la date et l’heure actuelles, suivez les étapes ci-dessous : Interface de ligne de commande

gw-world:/> time -set YYYY-mm-DD HH:MM:SS

Où YYYY-mm-DD HH :MM :SS représente les nouvelles date et heure. Notez l’ordre de présentation de la date :

l’année, puis le mois et enfin le jou r. Pour ré gler la date et l’heure su r le 27 avril 2007, 9 h 25, la commande sera :

gw-world:/> time -set 2007-04-27 09:25:00

Interface Web Sélectionnez System > Date and Time (Système > Date et heure). Cliquez sur Set Date and Time (Ajuster la date et l’heure). Ajustez l’année, le mois, le jour et l’heure à l’aide des commandes déroulantes. Cliquez sur OK.

Fondamentaux

Remarque

Dès qu’elles sont définies, NetDefendOS applique les nouveaux paramètres de date et heure.

Fuseaux horaires. Le monde est divisé en un certain nombre de fuseaux horaires, l’Heure de Greenwich (GMT) à Londres à la longitude 0 étant utilisée comme fuseau de référence. Tous les autres fuseaux horaires situés à l’Est et à l’Ouest de la longitude 0 sont définis comme étant GMT plus ou moins un nombre d’heures entier. Tous les emplacements comptabilisés comme étant à l’intérieur d’un fuseau horaire donné posséderont alors la même heure locale, qui sera donnée par un nombre entier représentant le décalage horaire par rapport à GMT.

Le fuseau horaire de NetDefendOS correspond au fuseau horaire dan s lequel se trouve physiqu ement le fir ewall D-Link.

Exemple 3.21. Configuration du fuseau horaire

Pour régler le fuseau horaire de NetDefendOS sur GMT + 1 heure, suivez les étapes ci-dessous : Interface de ligne de commande

gw-world:/> set DateTime Timezone=GMTplus1

Interface Web Sélectionnez System > Date and Time (Système > Date et heure). Sélectionnez (GMT+01:00) dans la liste déroulante des fuseaux horaires. Cliquez sur OK.

Passage à l’heure d’été. De nombreuses régions observent le passage à l’heure d’été (Daylight Saving Time, DST), ce qui signifie que les horloges sont avancées pour la période estivale. Malheureusement, les principes qui

régulent le passage à l’heure d’été varient suivant les pays et il existe, dans certains cas, des différences au sein d’un même pays. Pour cette raison, NetDe fendOS ne sait pas automa tiquement quand il doi t passer à l’heure d’été. Vous devez saisir cette information manuellement si vous souhaitez utiliser le passage à l’heure d’été.

Deux paramètres régissent le passage à l’heure d’été ; la période DST et le décalage DST. La période de l’heure d’été indique à quelles dates débute et se termine le passage à l’he ure d’été. Le décalage de l’heure d’ét é indique le nombre de minutes qui doit être ajouté à l’horloge pendant la période de l’heure d’été.

Exemple 3.22. Activer le passage à l’heure d’été

Pour activer le passage à l’heure d’été, suivez les étapes ci-dessous : Interface de ligne de commande

gw-world:/> set DateTime DSTEnabled=Yes

Interface Web Sélectionnez System > Date and Time (Système > Date et heure).

Cochez la case Enable daylight saving time (Activer le passage à l’heure d’été). Cliquez sur OK.

Fondamentaux

Serveurs horaires

L’horloge matérielle utilisée par NetDefendOS peut parfois accélérer ou ralentir après une certaine période d’activité. Il s’agit d’un comportement normal dans la plupart des équipements informatiques et réseau qui peut être résolu en utilisant des Serveurs horaires.

NetDefendOS peut ajuster l’horloge automatiquement en fonction des informations reçues de la part d’un ou plusieurs serveurs horaires qui offrent une heur e ultra-précise, en utilisant généralement les horloges atomiques. L’utilisation de serveurs horaires est fortement recommandée car elle garantit que NetDefendOS align era son heure et sa date sur celles des autres périphériques réseau.

Protocoles de synchronisation de l’heure. Les protocoles de synchronisation de l’heure sont des méthodes normalisées qui permettent de récupérer les informations concernant l’heure sur les serveurs horaires externes. NetDefendOS prend en charge les protocoles de synchronisation horaire suivants :

SNTP - Défini par la norme RFC 2030, le SNTP (Simple Network Time Protocol) est une forme allégée du

protocole NTP (RFC 1305). Il est utilisé par NetDefendOS pour interroger les serveurs NTP.

UDP/TIME - Le Time Protoc ol (UDP/ TIME) est u ne ancienn e m éthode qui four nit un service de sync hron isation

horaire via Internet. Ce protocole propose une heure et une date indépendantes de tout site et lisibles par la machine. Le serveur renvoie l’heure en secondes depuis le 1

janvier 1900, à minuit.

La plupart des serveurs horaires publics exécutent le protocole NTP et sont accessibles via SNTP. Configuration des serveurs horaires. Jusqu’à trois serveurs horaires peuvent être configurés pour lancer des

requêtes visant à récupérer les informations d’heure. L’utilisation de plusieurs serveurs permet d’éviter les situations où un serveur injoignable entraîne l’échec du processus de synchronisation du temps. NetDefendOS interroge toujours l’ensemble des serveurs h oraires configurés et cal cule une heure moyenne en fo nction de toutes les réponses. Des moteurs de recherche Internet peuvent être utilisés pour établir la liste des serveurs horaires accessibles au plus grand nombre.

Important

Assurez-vous qu’un serveur DNS externe est configuré de manière à ce que les URL des serveurs horaires puissent être traduit es (reportez-vous à la section « Recherche DNS »). Cette opérat ion n’est pa s requise si vous utilisez des adresses IP de serveurs.

Exemple 3.23. Activation de la synchronisation du temps via SNTP

Dans cet exemple, la synchronisation du temps est configurée de façon à utiliser le protocole SNTP pour communiquer avec les serveurs NTP du Swedish National Laboratory for Time and Frequency. Les URL du serveur NTP sont ntp1.sp.se et ntp2.sp.se.

Interface de ligne de commande

gw-world:/> set DateTime TimeSynchronization=custom TimeSyncServer1=dns:ntp1.sp.se TimeSyncServer2=dns:ntp2.sp.se TimeSyncInterval=86400

Web Interface Sélectionnez System > Date and Time (Système > Date et heure). Cochez la case Enable time synchronization (Autoriser la synchronisation du temps) Saisissez :

Time Server Type (type de serveur horaire) : SNTP

Primary Time Server (serveur horaire primaire) : ntp1.sp.se

Secondary Time Server (serveur horaire secondaire) : ntp2.sp.se Cliquez sur OK.

Fondamentaux

Remarque

Si le paramètre TimeSyncInterval n’est pas spécifié lorsque l’interface de ligne de commande est utilisée pour paramétrer l’intervalle de synchronisation, la valeur par défaut de 86 400 secondes (1 jour) est appliquée.

Exemple 3.24. Déclenchement manuel de la synchronisation du temps

Vous pouvez déclencher la synchronisation du temps via l’interface de ligne de commande. Le résultat ci-dessous montre une réponse typique.

Interface de ligne de commande

gw-world:/> time -sync Attempting to synchronize system time...

Server time: 2007-02-27 12:21:52 (UTC+00:00) Local time: 2007-02-27 12:24:30 (UTC+00:00) (diff: 158)

Local time successfully changed to server time.

Réglage du temps maximum. Pour évi ter les situations o ù un serveur horaire défect ueux provoque la mise à jour de l’horloge avec une heu re extrêm em ent impréci se, vo us p ouvez pa ramé trer une valeur de réglage maximale (en secondes). Si la différence entre l’heure actuelle de NetDefendOS et l’heure reç ue à partir d’ un serveur horaire est supérieure à cette valeur de réglage maximale, alors la réponse du serveur horaire sera rejetée. Supposons par exemple que la valeur de réglage maximale est de 60 secondes et que l’heure actuelle de NetDefendOS est 16 h 42 min 35 s. Si la réponse d’un serveur horaire est 16 h 43 min 38 s, alors la différence est de 63 secondes. Cette valeur est supérieure à la valeur de réglage maximale donc aucune mise à jour n’est effectuée pour cette réponse.

Exemple 3.25. Modification de la valeur de réglage maximale

Interface de ligne de commande

gw-world:/> set DateTime TimeSyncMaxAdjust=40000

Web Interface Sélectionnez System > Date and Time (Système > Date et heure). Pour définir le décalage de temps maximal qu’un serveur est autorisé à ajuster, entrez la durée maximale en

secondes qu’un serveur est autorisé à ajuster. Cliquez sur OK. Il peut parfois être nécessaire de remplacer le réglage maximal, par exemple lorsque la synchronisation du temps

vient juste d’être activée et que la différence de durée initiale est supérieure à la valeur de réglage maximale. Il est alors possible de forcer manuellement une synchronisation et d’ignorer le paramètre de réglage maximal.

Exemple 3.26. Forcer la synchronisation du temps

Cet exemple démontre comment forcer la synchronisation du temps, en remplaçant le paramètre de réglage maximal.

Interface de ligne de commande

gw-world:/> time -sync -force

Intervalles de synchronisation. L’intervalle entre chaque tentative de synchronisation peut être ajusté si nécessaire. La valeur par défaut est de 86 400 secondes (1jour), ce qui signi fie que le proc essus de synchroni sation s’exécute une fois toutes les 24 heures.

Serveurs horaires D-Link. L’utilisation des serveurs horaires propres à D-Link est une option de NetDefendOS ; c’est la méthode préconisée pour synchroniser l’horloge du firewall. Ces serveurs communiquent avec NetDefendOS via le protocole SNTP.

Lorsque l’option serveur D-Link est sélectionnée, un ensemble de valeurs prédéfinies sont utilisées pour la synchronisation.

Fondamentaux

Exemple 3.27. Activation du serveur D-Link NTP

Pour activer l’utilisation du serveur D-Link NTP : Interface de ligne de commande

gw-world:/> set DateTime TimeSynchronization=D-Link

Web Interface Sélectionnez System > Date and Time (Système > Date et heure). Sélectionnez le bouton radio D-Link TimeSync Server. Cliquez sur OK. Comme mentionné ci-dessus, i l est im portan t de con figure r un ser veur DN S exte rne po ur que l es URL du serve ur

horaire D-Link puissent être traduites durant le processus d’accès.

Recherche DNS

Un serveur DNS peut traduire un Fully Qualified Domain Name (FQDN) en adresse IP numérique correspondante. Les FQDN sont des noms de domaines textuels non ambigus qui spécifient une position de nœud unique dans l’arbre hiérarchique du Système de Noms de Domaines (DNS) Internet. La résolution FQDN autorise la modification de l’adresse IP physique réelle tandis que le FQDN peut rester identique.

La différence entre une URL (Uniform Resource Locator) et un FQDN est que l’URL intègre, outre le FQDN, le protocole d’accès. Le protocole « http//:» peut par exemple être spécifié pou r les pa ges d u Wo rld Wi de Web .

Les FQDN sont utilisés dans de nombreux aspects d’une configuration NetDefendOS où les adresses IP sont inconnues ou lorsqu’il s’avère plus judicieux d’utiliser la résolution DNS à la place des adresses IP statiques.

Pour réaliser la résolution DNS, NetDefendOS possède un client DNS intégré qui peut être configuré pour utiliser jusqu’à trois serveurs DNS.

Exemple 3.28. Configuration des serveurs DNS

Dans cet exemple, le client DNS est configuré pour utiliser un serveur DNS primaire et un serveur DNS secondaire, possédant respectivement les adresses 10.0.0.1 et 10.0.0.2.

Interface de ligne de commande

gw-world:/> set DNS DNSServer1=10.0.0.1 DNSServer2=10.0.0.2

Web Interface Sélectionnez System > DNS (Système > DNS). Saisissez les paramètres suivants :

Primary DNS (DNS principal) : 10.0.0.1

Secondary DNS (DNS secondaire) : 10.0.0.2 Cliquez sur OK.

Chapitre 4. Routage

Le présent chapitre décrit comment configurer le routage IP sous NetDefendOS.

Présentation

Les fonctionnalités de routage IP font partie des possibilités les plus fondamentales de NetDefendOS : tout paquet IP qui navigue dans le système est soumis à au moins une décision de routage à un moment donné et une configuration adaptée du routage est cruciale pour que le système de NetDefendOS fonctionne comme prévu.

NetDefendOS prend en charge les types de mécanismes de routage suivants :

Routage statique. Routage dynamique.

De plus, NetDefendOS prend en charge la surveillance du routage pour accomplir le routage et la redondance des liens avec possibilité de fail-over (basculement).

Routage statique

Le Routage statique constitue la forme de routage la plus basique. Le terme « statique » se rapporte au fait que les entrées de la table de routage sont ajoutées manuellement et sont donc permanentes (ou statiques) de nature.

Cette approche manuelle fait du routage statique la méthode la plus appropriée aux plus petits déploiements de réseaux, au sein desquels les adresses sont presque toutes fixes et où le nombre de réseaux c onnectés so nt lim ités. Cependant, pour des réseaux plus étendus (ou bien lorsque la topologie du réseau est complexe), les tâches de maintenance manuelle des tables de routage statique seraient trop longues et problématiques. Dans ces cas de figure, le routage dynamique est donc recommandé. Pour plus d’informations sur les capacités de routage dynamique de NetDefendOS, veuillez consulter la section intitulée « Routage dynamique ». Notez cependant que même si vous choisissez de déployer un routage dynamique pour votre réseau, vous devez quand m ême compre ndre les principes du routage stat ique et la manière dont il s’applique à NetDefendOS.

Principes de base du routage

Le routage IP est le mécanisme utilisé dans les réseaux TCP/IP pour transmettre les paquets IP de leur source jusqu’à leur destination, en passant par de nombreux nœuds intermédiaires, le plus souvent désignés comme des routeurs ou des firewalls. Dans chaque routeur, une table de routage indique où le prochain paquet doit être envoyé. Une table de routage se com pose gé néralem e nt de plusie urs routes. Chaque route contient en principe un réseau de destination, une interface vers laquelle transférer le paquet et éventuellement l’adresse IP de la prochaine passerelle se trouvant sur le chemin de la destination.

Les images ci-dessous illustrent le déploiement typique d’un firewall D-Link, ainsi que la représentation de la table de routage associée.

Route n° Interface Destination

1 lan 192.168.0.0/24 2 dmz 10.4.0.0/16 3 wan 195.66.77.0/24 4 wan all-nets (tout réseau) 195.66.77.4

Passerelle

La table de routage ci-dessus fournit les informations suivantes :

Route n°1 : tous les paquets allant vers les hôtes du réseau 192.168.0.0/24 doivent être envoyés via l’interface

lan. Comme aucune passerelle n’est spécifiée pour cette route, l’hôte est supposé se situer sur le segment du réseau dédié à l’interface lan.

Routage

Route n°2 : tous les paquets al lant vers les hôtes du ré seau 10.4.0.0/1 6 doivent êt re envoyé s via l’interfac e dmz.

De même, aucune passerelle n’est spécifiée pour cette route.

Route n°3 : tous les paquets allant vers les hôtes du réseau 195.66.77.0/24 sont envoyés via l’interface wan.

Aucune passerelle n’est requise pour atteindre les hôtes.

Route n°4 : tous les paquets allant vers n’importe quel hôte (all-nets correspond à tous les hôtes) sont envoyés

via l’interface wan vers les passerelles dont l’adresse IP est 195.66.77.4. Cette passerelle va donc consulter sa table de routage pour savoir où transmettre les paquets. Une route dont la destination est all-nets (tout réseau) est souvent considérée comme la route par défaut puisqu’elle va correspondre à tous les paquets pour lesquels aucune route spécifique n’a été déterminée.

Lors de l’évaluation d’une table de routage, l’ordre des routes est important. En général, les routes les plus spécifiques d’une table de routage sont évaluées en premier. En d’autres term es, si deux routes ont de s réseaux de destination qui se chevauchent, le réseau le plus limité sera évalué en premier par rapport à un réseau plus étendu. Dans l’exemple ci-dessus, un paq uet dont l’adresse IP de destination est 192. 16 8. 0. 4 c o rrespond théoriquement à la première et à la dernière route. Cependant, la première route correspond davantage. L’évaluation s’arrête donc ici et le paquet est transmis en fonction de cette donnée.

Routage statique

Cette section décrit comment le routage est appliqué dans NetDefendOS et présente la manière de configurer le routage statique.

NetDefendOS prend en charge plu sieurs tabl es de routa ge. Une t able par d éfaut appelée « main » est prédéfinie et est toujours présente dans NetDefendOS. Cependant, l’administrateur peut définir des tables de routage supplémentaires et complètement indépendantes pour bénéficier d’un routage alternatif.

Ces tables de routage supplémentaires définies par l’utilisateur sont utiles pour mettre en œuvre un Policy Based Routing (routage basé sur des rè gles). Ceci si gnifie que l’administrat eur peut établi r des rè gles dans l’ens emble de règles IP qui déterminent quelles tables de routage se chargeront de quel type de trafic (voir la section intitulé e « Routage basé sur des règles »).

Le mécanisme de Route lookup (recherche de route). Le mécanisme de Route lookup (recherche de route) de NetDefendOS présente quelques différences par rapport au mode de fonctionnement d’autres routeurs. Pour beaucoup de routeurs chez lesquels les paquets IP sont transférés sans contexte (c’est-à-dire que le transfert est dépourvu d’état), la table de routage est analysée à chaque fois que le routeur reçoit un paquet IP. Dans NetDefendOS, les paquets sont transmis pourvus d’un état. Le processus de recherche de route est donc étroitement intégré dans le mécanisme d’ins pection dynamique de NetDe f endOS.

Quand un paquet IP est reçu sur n’importe laquelle des interfaces, la table de connexion est consultée pour vérifier si une connexion qui correspond au paquet reçu n’est p as déjà établie. Si une connexion existante est trouvée, l’entrée de la table de connexion informe de la direction du paquet et évite ainsi toute recherche dans la table de routage. Cette solution est bien plus efficace que les recherches traditionnelles sur table de routage. C’est aussi l’une des raisons qui explique les hautes performances de transmission de NetDefendOS.

Si aucune connexion n’est établie, la table de routage est consultée. Il est important de comprendre que la recherche de route est effectuée avant l’évaluation des différentes sections de règles. Ainsi, l’interface de destination est connue au moment où NetDefendOS décide si la connexion doit être autorisée ou ignorée. Cette méthode permet un contrôle plus fin des règles de sécurité.

Désignation des routes dans NetDefendOS. NetDefendOS désigne les routes de manière légèrement différente par rapport à la plupart des autres systèmes, mais sa méthode est plus facile à comprendre, ce qui peut éviter les erreurs.

Beaucoup d’autres produits n’utilisent pas l’interface spécifique dans la table de routage, mais spécifient l’adresse IP de l’interface. La table de routage ci-dessous provient d’un poste de travail Microsoft Windows XP :

==================================================================== Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 13 d4 51 8d dd ...... Intel(R) PRO/1000 CT Network

0x20004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface

====================================================================

==================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.10 20

10.0.0.0 255.0.0.0 10.4.2.143 10.4.2.143 1

10.4.2.143 255.255.255.255 127.0.0.1 127.0.0.1 50

10.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 50

85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10 20

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

192.168.0.0 255.255.255.0 192.168.0.10 192.168.0.10 20

192.168.0.10 255.255.255.255 127.0.0.1 127.0.0.1 20

192.168.0.255 255.255.255.255 192.168.0.10 192.168.0.10 20

224.0.0.0 240.0.0.0 10.4.2.143 10.4.2.143 50

224.0.0.0 240.0.0.0 192.168.0.10 192.168.0.10 20

255.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 1

255.255.255.255 255.255.255.255 192.168.0.10 192.168.0.10 1 Default Gateway: 192.168.0.1 ==================================================================== Persistent Routes: None

Routage

La même table de routage sous NetDefendOS ressemble à ceci :

Flags Network Iface Gateway Local IP Metric

----- ------------------ -------- -------------- --------- ------

192.168.0.0/24 lan 20

10.0.0.0/8 wan 1

0.0.0.0/0 wan 192.168.0.1 20

Le mode de désignation des rout es est plus f acile à li re et à com prendre so us NetDe fendOS. U n autre avanta ge de cette notation est que vous pouvez spéci fier une passerelle po ur une rout e particul ière san s qu’une r oute ne co uvre l’adresse IP de la passerelle, ou malgré le fait que la route qui couvre l’adresse IP de la passerelle passe normalement par une autre interface.

Il convient aussi de m entionner que NetDefendOS vous per met de spécifie r les ro utes pour des destinations qui ne sont pas alignées sur des masques de sous-réseau traditionnels. En d’autres termes, il est parfaitement légitime de spécifier une route pour les plages d’adresses de destination comprises entre 192.168.0.5 et 192.168.0.17 et une autre route pour les adresses 192.168.18 à 192.168.0.254. Cette fonctionnalité rend NetDefendOS vraiment approprié au routage dans des topologies de réseau très complexes.

Affichage de la table de routage. Il est important de bien di sting uer la tabl e de r outa ge act ive da ns le s yst èm e et la table de routage que vous configurez. La table de routage que vous configurez ne contient que les routes que vous avez ajoutées manuellement (les routes st atiques). Le cont enu de la t able de routage active, quant à lui, varie selon plusieurs facteurs. Par exemple, si le routage dynamique a été activé, la table de routage sera alimentée de routes connues lors des échanges avec les autres routeurs du réseau. De plus, les fonctionnalités telles que le fail-over (basculement) des routes modifient parfois l’apparence de la table de routage active.

Exemple 4.1. Affichage de la table de routage

Cet exemple indique comment afficher le contenu de la table de routage configurée et de la table de routage active. Interface de ligne de commande Pour afficher la table de routage configurée :

gw-world:/> cc RoutingTable main

gw-world:/main> show

Route

# Interface Network Gateway Local IP

- --------- -------- ------------- ------- 1 wan all-nets 213.124.165.1 (none) 2 lan lannet (none) (none) 3 wan wannet (none) (none)

Pour afficher la table de routage active, saisissez :

gw-world:/> routes

Flags Network Iface Gateway Local IP Metric

----- ------------------ -------------- --------------- --------------- ------

192.168.0.0/24 lan 0

213.124.165.0/24 wan 0

0.0.0.0/0 wan 213.124.165.1 0

Routage

Interface Web Pour afficher la table de routage configurée :

Sélectionnez Routing > Routing Tables (Routage > Tables de routage). Cliquez avec le bouton droit de la souris sur la table de routage principale (main) figurant dans la liste. Dans le menu, sélectionnez Edit (Modifier).

La fenêtre principale répertorie les routes configurées. Pour afficher la table de routage active, sélectionnez l’élément Routes dans le menu déroulant Status (État) de la

barre de menu. La fenêtre principale affiche la table de routage active. Routes du noyau. NetDefendOS alimente automatiquement la table de routage active avec les routes du noyau. Ces routes ont pour but d’indiquer au système où diriger le trafic qui est destiné au système lui-même. Une route est ajoutée pour chaque interface du système. En d’autres termes, deux interfaces nommées lan et wan, dont les adresses IP sont respectivement 192.168.0.10 et 193.55.66.77, vont créer les routes suivantes :

Route n° Interface Destination

Passerelle

1 noyau 192.168.0.10 2 noyau 193.55.66.77

Lorsque le système reçoit un paquet IP dont l’adresse de destination est l’une des adresses IP des interfaces, le paquet sera acheminé vers l’interface du noyau. En d’autres termes, le traitement est assuré par NetDefendOS lui-même.

Une route du noyau est aussi ajoutée pour toutes les adresses à multidiffusion :

Route n° Interface Destination

Passerelle

1 noyau 224.0.0.0/4

Pour inclure les routes du noyau lorsque vous affichez la table de routage active, vous devez spécifier une option dans la commande de routage.

Exemple 4.2. Affichage des routes du noyau

Cet exemple indique comment afficher les routes du noyau dans la table de routage active. Interface de ligne de commande

gw-world:/> routes -all

Flags Network Iface Gateway Local IP Metric

----- ------------------ -------------- --------------- --------------- ------

127.0.0.1 core (Shared IP) 0

192.168.0.1 core (Iface IP) 0

213.124.165.181 core (Iface IP) 0

127.0.3.1 core (Iface IP) 0

127.0.4.1 core (Iface IP) 0

192.168.0.0/24 lan 0

213.124.165.0/24 wan 0

224.0.0.0/4 core (Iface IP) 0

0.0.0.0/0 wan 213.124.165.1 0

Interface Web

Sélectionnez l’élément Routes dans le menu déroulant Status (État) de la barre de menu.

Cochez Show all routes (Afficher toutes les routes), puis cliquez sur le bouton Apply (Appliquer). La fenêtre principale affiche la table de routage active, y compris les routes du noyau.

Routage

Conseil

Pour plus d’informations sur la restitution des commandes de routage de l’interface de ligne de commande, veuillez consulter le CLI Reference Guide (Guide de référence sur l’interface de ligne de commande).

Basculement de route

Présentation. Les firewalls D-Link sont souvent déployés dans des endroits critiques où leur disponibilité et leur connectivité sont cruciales. Par exemple, une société dont le fonctionnement repose massivement sur l’accès à Internet, peut voir ses activités gravement interrompues si une connexion à l’Internet échoue.

Par conséquent, il est fréquent d’avoir une connexion Internet de secours en faisant appel à un Fournisseur d’Accès Internet (FAI) secondaire. Les accès Internet des deux FAI utilisent souvent des méthodes de connexion différentes pour prévenir tout point commun d’échec.

Pour simplifier les scénarios tels que les multiples FAI, NetDefendOS offre une fonctionnalité de failover (basculement) de route. Ainsi, si une route échoue, le trafic sera automatiquement basculé vers une route alternative. La fonctionnalité de fail-over (basculement) de route de NetDefendOS s’applique avec la fonctionnalité de surveillance du routage, par laquelle NetDefendOS surveille la disponibilité des routes et commute le trafic sur une route alternative en cas d’échec de la route principale.

Figure 4.1. Scénario de basculement de route pour un accès ISP

Configuration du basculement de route. La surveillance du routage doit être activée « route par route ». Pour

activer la fonction de basculement de route dans un scénario comportant une route préférée et une route de sauvegarde, il faut activer la surveillance du routage sur la route préférée. Cette fonction n’a pas besoin d ’être activée sur la route de sauvegarde puisque aucune route ne lui est associée pour tout basculement . Pou r une route dont la surveillance du routage est activée, vous devez choisir parmi deux méthodes de surveillance :

Interface Link Status (État de liaison de l’interface)

Gateway Monitoring (Surveillance des passerelles)

NetDefendOS surveille l’état de liaison de l’interface spécifiée sur la route. Tant que l’interface est active, la route apparaît comme étant en bon état de fonctionnement. Cette méthode permet de vérifier que l’interface est attachée physiquement et que le câblage fonctionne correctement. Cette méthode a la réponse à l’échec la plus rapide, puisque tout changement de l’état de liaison est tout de suite notifié.

Si une passerelle spécifique a été spécifiée comme étant le prochain saut pour une route, la surveillance de l’accessibilité de cette passerelle se fait

Routage

par envoi périodique de requêtes ARP. Tant que la passerelle répond à ces requêtes, la route apparaît comme étant en bon état de fonctionnement.

Configuration de la métrique d’une route. Lors de la spécification des routes, l’administrateur doit configurer manuellement une métrique des routes. La métrique est un entier positif qui indique une préférence dans le choix de la route à emprunter vers la destination donnée. Lorsque deux routes conduisent à la même destination, NetDefendOS sélectionne celle q ui possède l a valeur métri que la pl us basse pour env oyer les d onnées (si l es deux routes ont la même métrique, la route trouvée en premier dans la table de routage sera empruntée).

Une route principale préférée doit avoir une métrique basse (par exemple « 10 ») et une route secondaire de basculement doit avoir une métrique plus élevée (par exemple « 20 »).

Routes de basculement multiples. Il est possible de spécifier plusieurs routes de basculement. Par exem ple, il est possible d’associer à une route pri ncipale deux routes de ba sculement au lie u d’une seule. Dan s ce cas, la métrique doit être différente pour chacune des trois routes. Par exemple : « 10 » pour la route principale, « 20 » pour la première route de basculement et « 30 » pour la seconde route de basculement. La surveillance du routage doit être activée dans la table de routa ge pour l es de ux prem ières ro utes, m ais pas p our la de rnière (avec la mét rique la plus élevée) puisqu’elle n’a pas de route associée vers laquelle basculer.

Processus de basculement. Lorsque la surveillance détermine qu’une route n’est pas disponible, NetDefendOS marque la route comme désactivée et inspecte le basculement de route pour rechercher de nouvelles connexions ou des connexions existantes. Dans le cas de connexions déjà établies, une recherche de route est effectuée pour déterminer la prochaine route qui correspond le mieux. Les conn exions commutent alors ve rs la nouvelle route. Dans le cas de nouvelles connexions, la recherche de route ignore les routes désactivées et la prochaine route qui correspond le mieux est empruntée à leur place.

Le tableau ci-dessous définit deux routes par défaut. Elles ont toutes deux une destination « Tout réseau », mais n’utilisent pas la même passerelle. La première, la route principale, a la métrique la plus basse. La surveillance du routage est activée. Pour la seconde, la route alternative, la surveillance du routage n’est pas nécessaire puisque aucune route de basculement ne lui est associée.

Route n° Interface Destination 1 wan Tout réseau 195.66.77.1 10 Activée 2 wan Tout réseau 193.54.68.1 20 Désactivée

Lorsqu’une connexion vers un hôte sur Internet est sur le point d’être établie, la recherche de route choisira la route qui a la métrique la plus basse. Si le routeur principal WAN échoue, NetDefendOS le détectera et la première route sera désactivée. Par conséquent, une nouvelle recherche de route est effectuée et la seconde route est sélectionnée.

Réactivation des routes. Même si une route a été désactivée, NetDefendOS continuera de vérifier son état. Si la route est de nouveau disponible, elle sera réactivée et les connexions existantes lui seront automatiquement ré-attribuées.

Groupement de l’interface de routage. Lors de l’utilisation de la surveillance du routage, il est important de vérifier si le fail-over (basculement) vers une autre route provoquera des modi fications da ns l’interface de routage. Au vu de cette possibilité, il est nécessaire de prendre quelques précautions pour s’assurer que les règles et les connexions existantes seront maintenues.

Pour illustrer ce problème, analysez la configuration suivante : D’abord, une règle IP traduit les adresses réseau (NAT) de tout le trafic HTTP à destination de l’Internet par l’interface wan :

# Action Interface

1 NAT lan lannet wan Tout réseau http

source

Passerelle Métrique Surveillance

Réseau

source

Interface de

destination

Réseau de

destination

Paramètres

Par conséquent, la table de routage contient la route par défaut suivante :

Route n° Interface Destination Passerelle Métrique Surveillance 1 wan Tout réseau 195.66.77.1 10 Désactivée

On ajoute maintenant une route secondaire qui emprunte une co nnexion DSL de sauvegard e. La surveillance du routage est désactivée. La nouvelle table de routage ressemble à ceci :

Route n° Interface Destination 1 wan Tout réseau 195.66.77.1 10 Activée 2 dsl Tout réseau 193.54.68.1 20 Désactivée

Notez que la surveillance du routage est active pour la première route et non pas pour la route de basculement de sauvegarde.

Tant que la route wan préférée agira correctement, tout fonctionnera comme prévu. La surveillance du routage fonctionne également, donc la route secondaire sera activée si la route wan échoue.

Il existe cependant certains problèmes avec cette configuration : si un basculement de route est effectué, la route par défaut utilisera alors l’interface dsl. Quand une nouvelle conne xion HTTP est établie depuis le réseau Internet, une recherche de route est effectuée. Sa réponse est une interface de destination dsl. Les règles IP sont donc évaluées, mais la règle NAT d’origine part du principe que l’interface de destination est wan. La nouvelle connexion est donc ignorée par l’ensemble de règles.

Routage

Passerelle Métrique Surveillance

De plus, toute connexion existante qui correspond à la règle NAT est aussi ignorée à cause du changement d’interface de destination. Cette situation n’est clairement pas souhaitable.

Pour contourner ce problème, les interfaces de destination potentielles doivent être regroupées dans un groupe d’interfaces et l’indicateur de l’équivalent sécurité/transport doit être activé pour ce groupe. Le groupe d’interfaces est désormais utilisé comme interface de destination lors de la configuration des règles. Pour plus d’informations sur les groupes, veuillez consulter la section intitulée « Groupe d’interfaces ». Génération d’ARP gratuite. Par défaut, NetDefendOS génère une requête ARP gratuite lorsqu’un basculement de route survient, de sorte à informer les systèmes environnants qu’un changement de route a été effectué. Ce comportement peut être contrôlé via le paramètre avancé RFO_GratuitousARPOnFail.

Proxy ARP

Comme expliqué précédemment dans la section intitulée « ARP », le protocole ARP facilite le mappage entre une adresse IP et l’adresse MAC d’un nœud sur un réseau Ethernet. Cependant, il arrive qu’un réseau exécutant Ethernet soit divisé en deux parties, avec un seul appareil de routage tel que le Firewall D-Link. Dans ce cas, NetDefendOS peut répondre lui-mêm e aux requêtes ARP d irigées vers le réseau, vers la partie du firewal l D-Link qui utilise la fonctionnalité connue sous le nom de proxy ARP.

Par exemple, l’hôte A d’un sous-réseau envoie une requête ARP pour trouver l’adresse MAC de l’adresse IP de l’hôte B sur un autre réseau séparé. La fonctionnalité de proxy ARP suppose que NetDefendOS réponde à cette requête ARP à la place de l’hôte B. NetDefendOS envoie sa propre adresse MAC comme s’il était l’hôte de destination. Après réception de la réponse, l’hôte A envoie les données directement à NetDefendOS qui, dans son rôle de proxy, les transmettra vers l’hôte B. Durant cette procédure, l’appareil peut examiner et filtrer les données.

Diviser un réseau Ethernet en deux parties distinctes est une application courante d’une fonctionnalité proxy ARP d’un firewall D-Link. L’accès aux deux parties doit être contrôlé. Dans ce cas, NetDefendOS peut surveiller et réguler tout le trafic transitant entre les deux parties.

Remarque

Seul le proxy ARP peut fonctionner pour les interfaces Ethernet et VLAN.

Routage

Routage basé sur des règles

Présentation

Le Policy-based Routing (Routage basé sur des règles) est une extension du routage standard décrit ci-dessus. Il offre aux administrateurs une flexibilité accrue lors de la mise en œuvre de règles de décision de routage et permet de définir des règles pour que les tables de routage alternatives soient utilisées.

Le routage normal transmet des paquets selon l’adresse IP de destination dérivée de routes statiques ou d’un protocole de routage dynamique. Par exemple, lors de l’utilisation d’OSPF, la route choisie pour les paquets est le chemin de plus bas coût (le plus court) dérivé d’un calcul SPF. Le routage basé sur des règles implique que les routes choisies pour le trafic peuvent être basées sur des paramètres spécifiques de trafic.

Le routage basé sur des règles peut autoriser : Un routage basé sur la source Une table de routage supplémentaire peut être nécessaire, selon la source du

trafic. Quand les services Internet sont assurés par plusieurs FAI, le routage basé sur des règles peut router le trafic provenant de différents groupes d’utilisateurs au travers de différentes routes. Par exemple, le trafic provenant d’une catégorie d’adresses peut être routé par un FAI et le trafic provenant d’une autre catégorie d’adresses routé par un autre FAI.

Un routage basé sur le service Une table de routage supplémentaire peut être nécessaire, en fonction du

service. Le routage basé sur des règles pe ut route r un protoc ole donné te l que le HTTP à travers des proxys tels que les caches Web. Les services spécifiques peuvent également être routés vers un FAI spécifique de sorte que l’ensemble du trafic HTTP soit géré par un seul FAI.

Un routage basé sur l’utilisateur Une table de routage supplémentaire peut être nécessaire, selon l’identité de

l’utilisateur ou le groupe auquel l’utilisateur appartient. Cette solution est particulièrement utile dans des réseaux métropolitains à fournisseur indépendant, où tous les utilisateurs partagent le même cœur de réseau actif, mais où chacun peut choisir un FAI différent en souscrivant à des fournisseurs différents.

La mise en application du routage basé sur des règles dans NetDefendOS a deux fondements : Une ou plusieurs Policy-based Routing Tables (Tables de routa ge basées sur des règles), alternatives et défi nies

par l’utilisateur, en complément de la table de routage principale standard par défaut.

Une ou plusieurs Policy-based routing rules (Règles de routage), qui déterminent quelle table d e rou tage est à

utiliser pour quel trafic.

Tables de routage basées sur des règles

NetDefendOS dispose d’une table de routage standard par défaut, appelée « main ». En plus de cette table principale, il est possible de définir une ou plusieurs tables de routage alternatives supplémentaires (les tables de routage basées sur des règles sont parfois appelées « tables de routage alternatives » dans la présente section).

Les tables de routage alternatives contiennent les mêmes informations de désignation des routes que la table de routage « main », à l’exception d’un paramètre supplémentaire ordering défini pour chacune d’elles. Ce paramètre détermine la manière dont est effectuée la recherche de route à l’aide des tables alternatives et de la table principale. Ce procédé est décrit plus loin, dans la section intitulée « Le paramètre Ordering ».

Routage

Règles de routage

Une règle parmi l’ensemble de règles de routage peut déterminer quelle est la table de routage à utiliser. Une règle de routage peut être déclenchée par le type de service (HTTP par exemple) conjointement avec l’interface source ou de destination et le réseau source ou de destination.

Lors d’une recherche dans les règles, c’est la première règle correspondante trouvée qui est activée.

Sélection de la table de routage basée sur des règles

Lorsqu’un paquet qui correspond à une nouvelle conn exion arrive, la table de routage est choisie d e la manière suivante :

Une recherche dans les règles de PBR doit être effectuée, mais il faut pour cela que l’interface de destination du

paquet soit déterminée, ce qui suppose une recherche dans la table de routage « main ». Il est donc important

qu’une correspondance soit t r ou vée pour le réseau de destination ou au moins qu’une route « tout réseau » par

défaut existe, qui pourrait s’associer à tous les éléments pour les quel s aucune correspondance explicite n’a été

trouvée.

Une règle de routage est ensuite recherchée, qui correspond à l’interface source ou de destination du paquet, au

réseau source ou de destination du paquet ainsi qu’à son service. Si une règle correspondante est trouvée, la

table de routage à utiliser est déterminée. Si aucune règle en PRB n’est trouvée, la table « main » sera dans ce

cas utilisée.

Une fois que la table de routage correspondante a été localisée, le système vérifie l’adresse IP source af in de

s’assurer qu’elle appartient bien à l’interface réceptrice. Les règles d’accès sont d’abord examinées pour voir si

elles peuvent effectuer cette vérification (pour plus d’informations sur cette fonctionnalité, consultez la section

intitulée « Règles d’accès »). S’il n’y a aucune règle d’accès ou qu’aucune correspondance avec les règles ne

peut être trouvée, une recherche inversée est effectuée dans la table de routage sélectionnée à l’aide de l’adresse

IP source. Si la vérification échoue, un message d’erreur de règle d’accès par défaut est alors généré.

À cet instant, la recherche de route est effectuée à partir de la table de routage sélectionnée pour déterminer

l’interface de destination du paquet. Le paramètre ordering est utilisé pour déterminer la procédure de

recherche réelle. Les options de cette procédure sont décrites dans la section suivante. Pour mettre en œuvre

des systèmes virtuels, l’option d’ordering Only doit être utilisée.

La connexion est alors soumise à l’ensemble de règles IP normal. Si une règle SAT est rencontrée, une

traduction d’adresses sera effectuée. Le choix de la table à utiliser est effectué avant la traduction d’adresses et

la recherche de route est effectuée avec la nouvelle adresse. Notez que la recherche de route d’origine

permettant de trouver l’interface de destination à utiliser pour toutes les recherches de règles était effectuée

avec l’adresse originale non traduite.) Si l’ensemble de règles IP le permet, la nouvelle connexion est ouvert e dans l a table d’état de NetDefe ndOS et

le paquet est transmis par cette connexion.

Le paramètre Ordering

Une fois la table de routage de la n ouvell e c onne xi on sélectionnée et s’il s’agit d’une table de routage alternative, le paramètre Ordering associé à la table en question est utilisé pour décider de la manière elle doit être combinée avec la table de routage principale pour rechercher la route appropriée. Les trois options disponibles sont :

Default (Par défaut) : le comportement par défaut c onsiste à rechercher d’abord la route d ans la table principale.

Si aucune route correspondante n’est trouvée ou que la route par défaut est trouvée (la route avec l a destination

tout réseau 0.0.0.0/0), la recherche est poursuivie dans la table alternative. Si aucune correspondance n’est

trouvée dans la table alternative, la route par défaut de la table de routage principale sera utilisée.

First (En premier) : ce comportement implique de rechercher d’abord la route de connexion dans la table

alternative. Si aucune route correspondante n’est trouvée, la recherche est poursuivie dans la table principale.

Dans le cas contraire, la route tout réseau par défaut sera comptabilisée comme correspondance dans la table

alternative.

Routage

Only (Uniquement) : cette option ignore l’existence de toute autre table que la table alternative. Ainsi, la

recherche n’est effectuée que sur cette table. Une des applications de cette option est de permettre à

l’administrateur de dédier une table de routage à un ensemble d’interfaces. L’option only (Uniquement) est

utilisée pour créer des systèmes virtuels, puisqu’elle peut dédier une table de routage à un ensemble

d’interfaces. Les deux premières options peuvent être vues comme une combinaison de la table alternative et de la table

principale, qui assigne une route si une correspondance est trouvée dans chacune des deux tables.

Important : apparition de la destination tout réseau dans la table principale

Une erreur courante avec le routage basé sur des règles est l’absence de route par défaut avec une interface de destination tout réseau dans la table de routage principale. S’il n’existe aucune correspondance exacte, l’absence d’une route tout réseau par défaut implique l’échec de la connexion.

Exemple 4.3. Création d’une table de routage basée sur des règles

Dans cet exemple, nous créons une table de routage basée sur des règles appelée « TestPBRTable ». Interface Web Sélectionnez Routing > Routing Tables > Add > Routi ngTable (Routage > Tables de r outage > Ajouter > Table

de routage).

Entrez :

Name (Nom) : TestPBRTable

Pour l’Ordering, sélectionnez l’une des options suivantes :

First (En premier) : la table de routage créée est consultée en premier. Si cette recherche échoue, elle se

poursuivra dans la table de routage principale.

Default (Par défaut) : la table de routage principale est consultée en premier. Si la seule correspondance

est la route par défaut (tout réseau), la table de routage créée sera consultée. Si la recherche dans la table de routage créée échoue, alors la recherche dans son intégralité aura échoué.

Only (Uniquement) : la tabl e de rout age cré ée est l a se ule à être consultée. Si cette recherche éc houe, elle ne se poursuivra pas dans la table de routage principale.

Si l’option Remove Interface IP Routes (Supprimer les routes IP de l’interface) est activée, les routes de

l’interface par défaut sont supprimées, c’est-à-dire les routes dirigées vers l’interface du noyau (qui sont des

routes vers NetDefendOS lui-même). Cliquez sur OK.

Exemple 4.4. Création de la route

Après avoir défini la table de routage « TestPBRTable », nous allons à présent lui ajouter des routes. Interface Web Sélectionnez Routing > Routing Tables > TestPBRTable > Add > Route (Routage > Tables de routage >

TestPBRTable > Ajouter > Route).

Entrez :

Interface : l’interface à router.

Network (Réseau) : le réseau à router.

Gateway (Passerelle) : la passerelle vers laquelle envoyer les paquets.

Routage

Local IP Address (Adresse IP locale) : l’adresse IP spécifiée ici est automatiquement publiée sur l’interface

correspondante. Cette adresse est aussi utilisée comme adresse d’envoi pour les requêtes ARP. Si aucune adresse n’est spécifiée, l’adresse IP de l’interface du firewall sera utilisée.

Metric (Métrique) : spécifie la métrique de cette route (Plus particulièrement utilisée lors de scén arios de

basculement de routes.

Cliquez sur OK.

Exemple 4.5 Configuration du routage basé sur des règles

Cet exemple illustre un scénario de FAI multiples, où il est normal d’utiliser un routage basé sur des règles. On considère que :

Chaque FAI vous donne un réseau IP de sa propre gamme de réseaux. Considé rons un scénario à deux FAI, où

le réseau 10.10.10.0/24 appartient au FAI A et le réseau 20.20.20.0/24 appartient au FAI B. Les passerelles des FAI sont respectivement 10.10.10.1 et 20.20.20.1.

Pour plus de facilité, toutes les adresses de ce scénario sont des adresses publiques. Ceci est une structure simplissime : il n’y a pas de sous-réseau explicite entre les passerelles des FAI et le

firewall D-Link.

Dans un réseau indépendant de tout fournisseur d’accès, les clients auront probablement une adresse IP qui appartient à un des FAI. Dans un scénario à organisation unique, des serveurs accessibles au public seront configurés avec deux adresses IP sépa rées : une pour chaque FAI. Cependant , cette différence im porte peu pour la configuration des règles de routage.

Notez que pour cette organisation unique, la connexion Internet fournie par plusieurs FAI est normalement meilleure via le protocole BGP, q ui perm et de ne pl us se s oucier des diffé rent es plages d’ adresses I P et des règl es de routage. Cette solution n’est malheureusement pas toujours possible, c’est pourquoi le routage basé sur des règles devient une nécessité.

Nous allons configurer la table de routage principale pour utiliser le FAI A et ajo uter une table de ro utage « r2 » qui utilise la passerelle par défaut du FAI B.

Interface Réseau Passerelle Proxy ARP lan1 10.10.10.0/24 wan1 lan1 20.20.20.0/24 wan2 wan1 10.10.10.1/32 lan1 wan2 20.20.20.1/32 lan1 wan1 Tout réseau 10.10.10.1

Voici le contenu de la table de routage basée sur des règles r2 :

Interface Réseau Passerelle wan2 Tout réseau 20.20.20.1

Le paramètre Ordering de la table r2 est dé fini sur Default (Par défaut), ce qui implique qu’ell e sera consultée si la recherche dans la table de routage principale trouve la route par défaut (tout réseau).

Voici le contenu des règles de routage :

Interface source

lan1 10.10.10.0/24 wan2 Tout réseau TOUS r2 r2 wan2 Tout réseau lan1 20.20.20.0/24 TOUS r2 r2

Plage source Interface de

destination

Plage de

destination

Service Table de

transfert VR

Table de retour VR

Pour configurer c e scénario : Interface Web Ajoutez les routes trouvées dans la liste des routes de la table de routage principale, comme montré

précédemment. Créez une table de routage nommée « r2 » et assurez-vous que le paramètre ordering est défini sur « Default »

(Par défaut).

Ajoutez la route trouvée dans la liste des routes de la table de routage « r2 », comme montré précédemment. Ajoutez deux règles VR selon la liste des règles montrée précédemment.

Sélectionnez Routing > Routing Rules > Add > Routing Rule (Routage > Règles de routage > Ajouter >

Règle de routage).

Entrez les information s trouvées dans la liste des règles affichée précédemment.

Répétez la procédure pour ajouter la deuxième règle.

Routage

Remarque

Les règles de l’exemple ci-dessus sont ajoutées pour les connexions entrantes et sortantes.

Routage dynamique.

Présentation du routage dynamique

Le routage dynamique est différent du routage statique en ce sens que le firewall D-Link s’adapte automatiquement aux changem ents de topologie du résea u et à son trafic. NetDe fendOS s’enquiert d’abor d auprès des réseaux connectés directement, puis cherche des informations supplémentaires sur la route auprès des autres routeurs. Les routes détectées sont classées et celles qui conviennent le mieux pour les destinations sont ajoutées dans la table de routage. Ces informations sont ensuite envoyées vers les autres routeurs.

Le routage dynamique répond instantanément aux mises à jour, mais il présente l’inconvénient d’être plus prédisposé à certains problèmes tels que les boucles de ro utage. Sur Int ernet, deux ty pes d’algori thmes de rout age dynamique sont utilisés : l’algorithme Distance Vector (DV) et l’algorithme Link State (LS). Le type d’algorithme choisi détermine la procédure suivie par le routeur pour sélectionner la route optimale ou la « meilleure » et pour partager les informations mises à jour avec d’autres routeurs. Algorithmes Distance Vector. L’algorithme Distance Vector (DV) est un algorit hme de routa ge décentralis é qui calcule le « meilleur » chemin en répartissant le travail. Chaque routeur calcule les coûts de ses propres liens attachés et partage les informations de la route uniquement avec ses routeurs voisins. Le routeur va petit à petit s’enquérir du chemin le moins coûteux grâce à un procédé de calcul itératif et d’échange d’informations avec ses voisins.

Le RIP (Protocole d’Information de Routage) est un algorithme DV bien connu qui implique l’envoi régulier de messages de mise à jour, ainsi que l’envoi des modifications de routage vers la table de routage. Le choix du chemin est basé sur sa « longueur », c’est-à-dire le nombre de routeurs intermédiaires (con nu aussi sous le nom de « pas »). Après avoir mis à jour sa propre table de routage, le routeur commence immédiatement à la transmettre aux routeurs voisins pour les informer des modifications.

Algorithmes Link State. Contrairement aux algorithmes DV, les algorithmes Link State (LS) permettent aux routeurs de conserver des tables de routage qui reflètent la topologie du réseau entier. Chaque routeur diffuse ses liens attachés et leur coût vers tous les autres routeurs du réseau. Quand un routeu r reçoit ces informations, il exécute l’algorithme LS et calcule son propre ensemble de chemins à moindre coût. Toute modification de l’état du lien sera envoyé partout sur le réseau, afin que tous les routeurs aient les mêmes informations sur la table de routage.

Open Shortest Path First. L’Open Shortest Path First (OSPF) est un logarithme LS largement utilisé. Un routeur compatible OSPF identifie en premier les routeurs et les sous-réseaux qui y sont directement connectés, puis diffuse ces informations vers tous les autres routeurs. Chaque routeur utilise les informations qu’il reçoit pour

construire une table représentant l’intégralité du réseau. Avec une table de routage complète, chaque routeur peut identifier les sous-réseaux et les routeurs qui conduisent à n’importe quelle destination. Les routeurs qui utilisent l’OSPF diffusent uniquement les mises à jour qui informent d’une modification, et non pas l’intégralité de la table de routage.

L’OSPF dépend de plusieurs métriques pour déterminer le chemin à emprunter. Il prend aussi en compte les pas, la bande passante, le trafic et les délais. L’OSPF peut garantir un grand contrôle sur le processus de routage puisque ses paramètres peuvent être définis avec une grande précision.

Comparaison des algorithmes de routage dynamique. Puisque l’information sur l’état global du lien est envoyée partout sur le réseau, les algorithmes LS offrent un haut degré de contrôle de configuration et d’évolutivité. Les changements entraînent la diffusion vers d’autres routeurs de l’information mise à jour uniquement, ce qui implique une convergence plus rapide et moins de ris ques de boucles de routage. L’OSPF peut aussi fonctionner au sein d’une hiérarchie, bien que le RIP ne soit pas familier avec l’adressage du sous-réseau. NetDefendOS utilise l’OSPF comme algorithme de routage dynamique pour les multiples avantages qu’il offre. Métriques de routage. Les métriques de routage sont les critères qu’un algorithme de routage utilise pour calculer la « meilleure » route vers une destination. Un protocole de routage repose sur une ou plusieurs métriques pour évaluer les liens au travers d’un réseau et déterminer le chemin optimal. Les principales métriques utilisées incluent :

Routage

Path length (Longueur du chemin)

Item Bandwidth (Bande passante de l’élément)

Load (Charge) L’utilisation d’un routeur. Elle peut être évaluée en fonction de l’utilisation et

Delay (Durée) Le temps nécessaire pour transférer un paquet de sa source à sa destination.

La somme des coûts associés à chaque lien. Une des valeurs communément utilisées pour cette métrique est appelée « hop count » (décompte de pas). Elle représente le nombre d’appareils de routage qu’un paquet doit tr averser entre sa source et sa destination.

La capacité de trafic d’un chemin, mesuré en « Mbps ».

du débit du processeur.

Cette durée dépend de plusieurs facteur s tels que la bande passante, la charge et la longueur du chemin.

OSPF

Présentation. L’Open Shortest Path First (OSPF) est un protocole de routage développé pour les réseaux IP par l’IETF (Détachement d’Ingénieri e d’Internet). L’i mplantati on de l’OSPF dans NetDefe ndOS se base sur la norm e RFC 2328 et est compatible avec la norme RFC 1583.

L’OSPF route les paquets IP en se basant uniquement sur l’adresse IP de destination trouvée dans l’en-tête du paquet IP. Les paquets IP sont routés « en l’état », c’est-à-dire qu’ils ne sont pas encapsulés dans des en-têtes de protocole supplémentaires lors de leur transit dans l’AS (Système Autonome). L’OSPF est un protocole de routage dynamique qui détecte rapidement les modifications topologiques dans l’AS (tels que les échecs dans l’interface du routeur) et calcule les nouvelles routes dépourvues de boucles après une période de temps.

L’OSPF est un protocole de routage link-state qui requiert l’envoi d’annonces d’état de liens (LSA) vers tous les autres routeurs de la zone. Dans un pr otocol e de ro utage lin k-state, c haque ro uteur ent retient u ne base de données qui désigne la topologie de l ’AS. Cette base de don nées est dénomm ée base de d onnées link-state. C haque route ur du même AS possède une base de données identique. Grâce aux informations de la base de données link-state, chaque routeur représente la base d’u n arbre des c hemins les plus courts qu’il se construit lui-même. Cet arbre des chemins les plus courts propose une route pour chaque destination dans l’AS.

L’OSPF permet de regrouper différents réseaux : c’est ce que l’on appelle une zone. La topologie d’une zone est cachée du reste de l’AS. Ce masquage des informations rédu it l’im portance du tra fic écha ngé. De plus , le routage au sein même de la zone est uniquement déterminé par sa propre topologie, ce qui protège la zone des mauvaises données de routage. Une zone est la généralisation d’un sous-réseau IP.

Tous les échanges du protocole OSPF peuvent être authentifiés. Ceci implique que seuls les routeurs qui s’authentifient correctement peuvent joindre l’AS. Des schémas d’authentification différents peuvent être utilisés, tels que none, passphrase ou MD5digest. Il est possible de configure r des mé thodes d’aut hentifi cation di fférentes

pour chaque AS. Zones OSPF. L’AS est divisé en plus petites parties appelées Zones OSPF. Cette section définit les zones et les

termes associés.

Zones Une zone regroupe des réseaux et des hôtes au sein d’un AS. Les routeurs qui ne

font partie que d’une zone sont appelés routeurs internes. Toutes les interfaces des routeurs internes sont directement connectées aux réseaux de la zone. La topologie d’une zone est cachée du reste de l’AS.

ABR Les routeurs qui possèdent des interfaces dans plusieurs zone sont appelés ABR

(Area Border Routers). Ceux-ci gèrent une base de données topologique différente pour chaque zone à laquelle ils appartiennent.

ASBR Les routeurs qui échangent des informations de routage avec des routeurs

appartenant à d’autres AS sont appelés ASBR (Autonomous System Boundary Router). Ils indiquent a u sein de l’AS les r outes qu’i ls déc ouvre nt à l’ extéri eur de l a zone.

Zones de cœur de réseau Tous les réseaux OSPF ont besoin d’au moins une zone de cœur de réseau, d ont l’ID

est 0. Il s’agit de la zone à laquelle toutes les autres zones doivent être connectées. Ce cœur de réseau assure la distribution des informations de routage parmi les zones connectées. Quand une zone n’est pas directement connectée au cœur de réseau, elle a besoin d’être liée virtuellement avec lui.

Routage

Zone de stub Les zones de stub sont des zones par lesquelles ou dans lesquelles les annonces

externes de l’AS ne sont pas transmises. Qua nd une zone est configurée comme une zone de stub, le routeur annonce automatiquement une route par défaut afin que les routeurs de cette zone puissent atteindre des destinations extérieures.

Zones de transit Les zones de transit sont utilisées pour transférer le trafic d’une zone qui n’est pas

directement connectée à la zone de cœur de réseau.

Le routeur dédié. Chaque réseau de diffusion OSPF possède un rout eur d édié et un route ur dé dié de sa uvegar de. Les routeurs utilisent le protocole OSPF hello pour choisir le routeur dédié (DR) et le routeur dé dié de sauve garde (BDR) d’un réseau, en se basant sur les priorités annoncées par tous les routeurs. S’il y a déjà un DR s ur le réseau, le routeur l’acceptera en dépit de ses propres priorités de routeurs.

Voisins. Les routeurs qui appartiennent à la même zone deviennent voisins. Les voisins sont choisis via le protocole hello. Les paquets hello sont émis périodiquement par chaque interface qui utilise l’adresse IP à multidiffusion. Les routeurs deviennent voisins aussitôt qu’ils se voie nt répertoriés dans le m ême paquet hello. De cette manière, deux moyens de communication sont garantis.

Voici la définition des États des voisins :

Down Il s’agir de l’état initial de la relation entre voisins. Init Lorsqu’un paquet HELLO est reçu de la part d’un voisin, mais qu’il n’inclut PAS

l’ID routeur du firewall, le voisin sera mis à l’état Init. Aussitôt que le voisin en question reçoit un paquet HELLO, il connaît les ID routeur des routeurs expéditeurs. Il envoie alors un paquet HELLO qui contient ces informations. L’état des voisins change alors pour l’état 2-way.

2-Way Dans cet état, la communication entre le routeur et le voisin est bidirectionnelle. Pour

les interfaces de point à point et de point à multipoints, l’état passe à Full. Sur des interfaces de diffusion, seuls les DR et les BDR prennent l’état Full avec leurs voisins. Tous les autres voisins restent à l’état 2-Way.

ExStart Préparation à la construction d’une contiguïté. Exchange Les routeurs échangent des Descripteurs de données. Loading Les routeurs échangent des annonces d’état de liens.

Full Il s’agit de l’état normal d’une contiguïté entre un routeur et le DR/BDR.

Agrégats. Pour OSPF, les agrégats sont utilisés pour combiner des groupes de routes avec une adresse commune en une seule entrée dans la table de routage. Ils sont généralement utilisés pour réduire la table de routage.

Liens virtuels. Les liens virtuels sont utilisés pour :

Lier une zone qui n’a pas de connexion directe au cœur de réseau. Relier le cœur de réseau au cas où il serait partitionné.

Les zones sans connexion directe avec le cœur de réseau. Le cœur de réseau doit nécessairement êt re le centre de toutes les autres zones. Da ns les rares cas où il est i m possi ble d e c onnect er phy siq uem ent une z one a u cœur de réseau, on peut utiliser un lien virtuel. Le lien virtuel fournit à cette zone un chemin logique vers la zone de cœur de réseau. Ce lien virtuel est établi entre deux ABR se situant sur une zone commune, l’un des ABR étant connectés à la zone de cœur de réseau. Dans l’exemple ci-dessous, deux routeurs sont connectés à la même zone (Zone 1) mais uniquement l’un d’entre eux (fw1) est connecté physiquement à la zone de cœur de réseau.

Routage

Figure 4.2. Liens virtuels exemple 1

Dans l’exemple ci-dessus, le lien virtuel est configuré entre fw1 et fw2 sur la zone 1, puisqu’elle est utilisée comme zone de transit. Dans cette solution, seul l’ID routeur doit être configurée. Le diagramm e m ontre q ue fw2 a besoin d’un lien virtuel vers fw1 avec l’ID routeur 192.168.1.1 et vice-versa. Ces liens virtuels doivent être configurés dans la zone 1.

Un cœur de réseau partitionné. L’OSPF autorise les liens virtuels vers un cœur de réseau partitionné. Le lien virtuel doit être configuré entre deux différents ABR qui touchent le cœur de réseau de chaque côté et qui partagent une zone commune.

Figure 4.3. Liens virtuels exemple 2

Routage

Le lien virtuel est configuré entre fw1 et fw2 sur la zone 1, puisqu’elle est utilisée comme zone de transit. Dans cette solution, seule l’ID routeur doit être configurée. L’exemple ci-dessus montre que fw2 nécessite un lien virtuel vers fw1 avec l’ID rou teur 192.168.1.1 et vice-versa. Ces liens virtuels doive nt être configurés da ns la zone

1. Assistance de haute disponibilité OSPF. Notez qu’il existe des limitations dans l’assistance de haute

disponibilité pour l’OSPF : Chacune des parties actives et inactives d’un cluster de haute disponibilité exécutent des processus OSPF

différents, bien que la partie inactive assure qu’elle n’est pas le choix préféré pour le routage. Le maître et l’esclave de haute disponibilité ne forment pas de contiguïté l’un avec l’autre et ne sont pas autorisés à devenir des DR ou BDR sur un réseau de diffusion. Ceci peut être accompli en forçant la priorité du routeur à 0.

Pour que l’assistance de haute disponibilité de l’OSPF fonctionne correctement, le firewall D-Link doit posséder une interface de diffusion avec au moins UN voisin pour CHAQUE zone à laquelle le firewall est attaché. Par définition, la partie inactive du cluster doit avoir un voisin pour en obtenir la base de données link state.

Notez aussi qu’il n’est pas possible de mettre un cluster de haute disponibilité sur le même serveur de diffusion sans aucun voisin (ils ne fo rment pas de co ntiguïté ensem ble parce que la priorité du routeur est à 0). Cependa nt, il est possible selon le scénario de paramétrer un lien de point à point entre eux. Une attention particulière doit être portée lors du paramétrage d’un lien virtuel à un firewall de haute disponibilité. Le paramétrage final du lien vers le firewall de haute disponibilité doit comporter 3 liens différents : un lien vers l’ID routeur partagée, un vers l’ID routeur du maître et un vers l’ID routeur de l’esclave du firewall.

Règles de routage dynamique

Présentation. Dans un environnement de routage dynamique, il est important que les routeurs soient ca pabl es de réguler dans quelle mesure ils participent à l’échange du routage. Il ne faut pas qu’ils acceptent ou se fient à toutes les informations de routage reçues. Il peut être crucial d’éviter que certaines parties de la base de données du routage ne soient transmises à d’autres routeurs.

C’est pour cette raison que NetDefendOS fournit des règles de routage dynamique qui sont utilisées pour réguler le flux des informations de routage dynami que.

Une règle de routage dynamique filtre les routes aussi bien celles configurées statiquement que celles découvertes par l’OSPF, selon des paramètres tels que l’origine des routes, la destination, la métrique et autres. Les routes correspondantes peuvent être contrôlées par des actions pour être soit exportées vers des processus OSPF, soit ajoutées à une ou plusieurs tables de routage.

Les utilisations les plus courantes des règles de routage dynamique sont :

L’importation des routes OSPF d’un processus OSPF vers une table de routage. L’exportation des routes d’une table de routage vers un processus OSPF. L’exportation de routes d’un processus OPSF vers un autre.

Routage

Remarque

Par défaut, NetDefendOS n’importe ni n’exporte aucune route. En d’autres termes, pour que le routage dynamique soit significatif, il est obligatoire de définir au moins une règle de routage dynamique.

Exemple 4.6. Importation de routes d’un AS OSPF vers la table de routage principale

Dans cet exemple, les routes reçues qui utilisent l’OSPF sont ajoutées dans la table de routage principale. Tout d’abord, un filtre des règles de routage dynamique doit être créé. Le filtre doit être nommé. Dans cet exemple, nous utiliserons le nom ImportOSPFRoutes puisqu’il explique la fonction du filtre.

Le filtre doit aussi spécifier de quel AS OSPF les routes doivent être importées. Dans cet exemple, nous utiliserons un AS OSPF préconfiguré nommé as0.

Selon la topologie de votre routage, vous pourriez vouloir importer seulement certaines routes en utilisant les filtres Destination Interface/Destination Network (Interface de destination/Réseau de destination), mais dans ce scénario toutes les routes qui sont en tout réseau (ce qui revient à s pécifier une adresse IP 0.0.0.0/0) sont incluses.

Interface de ligne de commande

gw-world:/> add DynamicRoutingRule OSPFProcess=as0 Name=ImportOSPFRoutes DestinationNetworkExactly=all-nets

Interface Web

Sélectionnez Routing > Dynamic Routing Rules > Add > Dynamic routing policy rule (Routage > Règles de

routage dynamique > Ajouter > Règle de routage dynamique).

Saisissez un nom convenable pour le filtre (dans notre exemple, ImportOSPFRoutes). Dans Select OSPF Process (Sélectionnez un processus OSPF), sélectionnez as0. Choisissez all-nets dans le menu déroulant …Exactly Matches (…correspondances exactes). Cliquez sur OK.

L’étape suivante consiste à créer une action de routage dynamique qui se chargera de l ’importation des rout es vers une table de routage. Spécifiez la table de routage de destination à laquelle les routes doivent être ajoutées (dans cet exemple, main).

Interface de ligne de commande

gw-world:/> cc DynamicRoutingRule ImportOSPFRoutes

gw-world:/ImportOSPFRoutes> add DynamicRoutingRuleAddRoute

Destination=MainRoutingTable

Interface Web

Sélectionnez Routing > Dynamic Routing Rules (Routage > Règles de routage dynamique). Cliquez sur le filtre ImportOSPFRoutes récemment créé. Sélectionnez OSPF Routing Action > Add > DynamicRoutingRuleAddRoute (Action de routage OSPF >

Ajouter > Route de règle de routage dynamique).

Dans Destination, ajoutez la table de routage principale dans la liste Selected (Sélection). Cliquez sur OK.

Routage

Exemple 4.7. Exportation des routes par défaut vers un AS OSPF

Dans cet exemple, la route par défaut de la t able de ro utage princi pale est exportée vers un AS OSPF nomm é as0. Ajoutez d’abord un filtre de règles de routage dynamique qui correspond à la table de routage prin cipale et à la route par défaut :

Interface de ligne de commande

gw-world:/> add DynamicRoutingRule OSPFProcess=as0 name=ExportDefRoute RoutingTable=MainRoutingTable DestinationInterface=wan DestinationNetworkExactly=all-nets

Interface Web

Sélectionnez Routing > Dynamic Routing Rules > Add > Dynamic routing policy rule (Routage > Règles de

routage dynamique > Ajouter > Règle de routage dynamique).

Spécifiez un nom convenable pour le filtre (par exemple, ExportDefRoute). Dans From Routing Table (Depuis la table de routage), sélectionnez Main Routing Table (Table de routage

principale).

Choisissez wan dans Destination Interface (Interface de destination). Choisissez all-n ets dans la liste …Exactly Matches (…correspondances exactes). Cliquez sur OK.

Puis, créez une action OSPF qui exportera la route filtrée vers l’AS OSPF spécifié : Interface de ligne de commande

gw-world:/> cc DynamicRoutingRule ExportDefRoute gw-world:/ExportDefRoute/> add DynamicRoutingRuleExportOSPF ExportToProcess=as0

Interface Web

Sélectionnez Routing > Dynamic Routing Rules (Routage > Règles de routage dynamique). Cliquez sur le filtre ExportDefRoute récemment créé. Sélectionnez OSPF Action > Add > DynamicRoutingRuleExportOSPF (Action OSPF > Ajouter > OSPF

d’exportation de la règle de routage dynamique).

Dans Export to process (Exporter vers le processus), choisissez as0. Cliquez sur OK.

Routage

Routage multidiffusion

Présentation

Certains types d’interactions sur Internet (telles que les conférences en ligne et la diffusion de vidé os) impliquent qu’un seul client ou hôte envoie le même paquet à plusieurs récepteurs. Ce scénario est possible grâce à la duplication du paquet avec des adresses IP différentes par l’ émetteur ou grâce à la diffusion du pa quet sur Internet. Ces solutions gaspillent énormément les ressources de l’émetteur ou la bande passan te du réseau. Elles ne sont donc pas satisfaisantes. Une solution appropriée devrait aussi être capable de réguler le grand nombre de récepteurs.

Le routage multidiffusion résout ce problème grâce aux routeurs du réseau eux-mêmes, qui dupliquent et transmettent les paquets via une r oute optimale à tous les membres d’u n groupe. Les sta ndards IETF qui aut orisent le routage multidiffusion sont :

Classe D de la plage d’adresses IP dédiée au trafic multidiffusion. Chaque adresse IP à multidiffusion

représente un groupe arbitraire de récepteurs. L’IGMP (Internet Group Membership Protocol) autorise un récepteur à annoncer au réseau qu’il est membre

d’un groupe de multidiffusion pa rt i c ul i e r. Le PIM (Protocol Independent Multicast) est un groupe de protocoles de routage qui déterminent le chemin

optimal à emprunter pour les paquets de multidiffusion. Le routage multidiffusion fonctionne selon le principe où un récepteur intéressé rejoint un groupe de

multidiffusion en utilisant le protocole IGMP. Les routeurs PIM peuvent alors dupliquer et transmettre les paquets à tous les membres de ce groupe de multidiffusion, ce qui crée un arbre de distribution pour le flux du paquet. Plutôt que d’acquérir de nouvelles informations sur le réseau, le PIM utilise les informations de routage des protocoles déjà existants, tels que l’OSPF, pour choisir le chemin optimal.

L’un des mécanismes clé dans le processus de routage multidiffusion est le Reverse Path Forwarding (Transmission par chemin inverse). Pour le trafic à diffusion unique, le routeur ne s’intéresse qu’à la destination du paquet. Avec l'envoi en multidiffusion, le routeur s’intéresse aussi à la source du paquet puisqu’il transmet le paquet sur des chemins de sens descendant depuis la source. Cette approche est adoptée pour éviter les boucles dans l’arbre de distribution.

Par défaut, les paquets de multidiffusion sont routés par NetDefendOS jusqu’à l’interface du noyau. Les règles SAT Multiplex sont paramétrées dans l’ensemble de règles IP pour réaliser la transmission vers les bonnes interfaces. Une démonstration de cette situation apparaît dans les exemples qui suivent.

Remarque

Pour que l’envoi en multidiffusion fonctionne sur une interface Ethernet avec n’importe quel firewall D-Link, cette interface doit avoir le paramètre multidiffusion sur On ou Auto. Pour plus de détails, veuillez consulter la section intitulée « Ethernet ».

Transfert multidiffusion avec règle SAT Multiplex

La règle SAT Multiplex est utilisée pour effectuer la duplicatio n et la transmission des paquets au travers de plusieurs interfaces. Cette fonctionnalité applique le transfert multidiffusion dans NetDefendOS, grâce auquel un paquet de multidiffusion est envoyé via plusieurs interfaces. Notez que si cette règle outrepasse les tables de routage normales, les paquets qui doivent être dupliqués par la règle multiplex sont nécessairement routés vers l’interface du noyau.

Par défaut, les adresses IP à multidiffusion 224.0.0.0/4 sont toujours routées vers le noyau et ne doivent pas être ajoutées manuellement aux tables de routage. Chaque interface de sortie spécifiée peut être configurée séparém ent avec une traduction statique de l’adresse de destination. Le champ Interface dans la boîte de dialogue Interface/Net Tuple (N-uplet réseau) peut être vide si le champ IPAddress (A dresse IP) est paramétré. Dans ce cas, l’interface de sortie est déterminée lors d’une recherche de route sur l’adresse IP spécifiée.

La règle multiplex peut fonctionner selon deux modes : Use IGMP (Avec IGMP) Les hôtes qui utilisent l’IGMP doivent requérir le flux de trafic spécifié par la règle

multiplex avant que tout paquet de multidiffusion ne soit transmis au travers des interfaces spécifiées. C’est le comportement par défaut de NetDefendOS.

Not Using IGMP (Sans IGMP) Le flux de trafic est transféré directement par les interfaces spécifiées sans

aucune interférence de l’IGMP.

Routage

Remarque

Puisque la règle multiplex est une règle SAT, une règle Allow ou NAT doit être spécifiée avec la règle multiplex.

Transfert multidiffusion sans traduction d’adresses

Ce scénario indique comment configurer le transfert multidiffusion avec IGMP. L’émetteur de multidiffusion est

192.168.10.1 et génère un flux de multidiffusion 239.192.10.0/24 :1234. Ces flux doivent être transférés depuis une interface wan en traversant les interfaces if1, if2 et if3. L es flux doivent être transférés uni quement si certains hôtes ont requis les flux avec le protocole IGMP. L’exemple ci-dessous ne traite que de la configuration du transfert multidiffusion. La configuration de l’IGMP est consultable dans la section intitulée « Configuration de règles IGMP sans traduction d’adresses ».

Figure 4.4. Transfert multidiffusion sans traduction d’adresses

Remarque

Pensez bien à ajouter une règle Allow qui correspond à la règle SAT multiplex.

Routage

Exemple 4.8. Transfert de trafic multidiffusion avec règle SAT multiplex

Dans cet exemple, nous allons créer une règle multiplex afin de transférer les groupes de multidiffusion

239.192.10.0/24:1234 vers les interfaces if1, if2 et if3. Tous les groupes ont le même émetteur 192.168.10.1, situé derrière l’interface wan. Les groupes de multidiffusion doivent uniquement être transférés vers les interfaces de sortie si des clients derrière ces interfaces ont requis l’utilisation de l’IGMP. La procédure suivante doit être respectée pour configurer le transfert du trafic multidiffusion. L’IGMP doit être configuré à part.

Interface Web A. Créez un service personnalisé pour l’envoi en multidiffusion nommé multicast_service :

Sélectionnez Objects > Services > Add > TCP/UDP (Objets > Services > Ajouter > TCP/UDP). Saisissez :

Name (nom) : multicast_service

Type : UDP

Destination : 1234

B. Créez une règle IP :

Sélectionnez Rules > IP Rules > Add > IP Rule (Règles > Règles IP > Ajouter > Règle IP). Sous General (Général), entrez :

Name (nom) : un nom pour la règle (par exemple, Multicast_Multiplex)

Action : Multiplex SAT

Service: multicast_service

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : wan

Source Network (Réseau source) : 192.168.10.1

Destination Interface (Interface de destination) : core (noyau)

Destination Network (Réseau de destination) : 239.192.10.0/24

Cliquez sur l’onglet Multiplex SAT et ajoutez les interfaces de sortie if1, if2 et if3 une par une. Pour chaque

interface, laissez le champ IP Address (Adresse IP) vide puisqu’aucune traduction d’adresses de destination

n’est requise.

Assurez-vous d’avoir activé le transfert avec IGMP. Cliquez sur OK.

Routage

Transfert multidiffusion avec traduction d’adresses

Figure 4.5. Transfert multidiffusion avec traduction d’adresses

Ce scénario se base sur le scénario précédent à l’exception que nous allons traduire le groupe de multidiffusion. Lorsque les flux de multidiffusion 239.192.10.0/24 sont transférés via l’interface if2, les groupes de multidiffusion doivent être traduits en 237.192.10.0/24. Aucune traduction d’adresses ne doit être faite lors d’un transfert via l’interface if1. La configuration des règles IGMP correspondantes est consultable dans la section intitulée « Configuration de règles IGMP avec traduction d’adresses ».

Attention

Comme indiqué précédemment, pensez à ajouter une règle Allow qui correspond à la règle SAT multiplex.

Figure 4.9. Transfert multidiffusion avec traduction d’adresses

La règle SAT multiplex suivante doit être configurée pour correspondre au scénario décrit ci-dessus : Interface Web A. Créez un service personnalisé pour l’envoi en multidiffusion nommé multicast_service :

Sélectionnez Objects > Services > Add > TCP/UDP (Objets > Services > Ajouter > TCP/UDP). Saisissez :

Name (nom) : multicast_service

Type : UDP

Destination : 1234

B. Créez une règle IP :

Sélectionnez Rules > IP Rules > Add > IP Rule (Règles > Règles IP > Ajouter > Règle IP). Sous General (Général), entrez :

Routage

Name (nom) : un nom pour la règle, par exemple Multicast_Multiplex

Action : Multiplex SAT

Service: multicast_service

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : wan

Source Network (Réseau source) : 192.168.10.1

Destination Interface (Interface de destination) : core (noyau)

Destination Network (Réseau de destination) : 239.192.10.0/24

Cliquez sur l’onglet Address Translation (Traduction d’adresses). Ajoutez l’interface if1, mais laissez l’IPAddress (Adresse IP) vide. Ajoutez l’interface if2, mais cette fois entrez 237.192.10.0 comme adresse IP. Assurez-vous d’avoir activé le transfert avec IGMP. Cliquez sur OK.

Remarque

Si la traduction de l’adresse source est requise, la règle Allow qui suit la règle SAT Multiplex doit être remplacée par une règle NAT.

Configuration IGMP

La signalisation IGMP entre les hôtes et les routeurs peut être divisée en deux catégories : IGMP Reports (Rapports IGMP) Des rapports sont envoyés depuis les hôtes vers les routeurs lorsqu’un hôte

veut souscrire à un nouveau groupe de mul tidiff usi on o u modi fier ses act uel les sousc ripti ons de multidiffusion.

IGMP Queries (Requêtes IGMP) Les requêtes sont des messages IGMP émis par le routeur à destination des

hôtes afin de s’assurer qu’aucun flux attendu par un hôte ne sera interrompu.

Normalement, ces deux types de règles doivent être spécifiés pour que l’IGMP fonctionne. Il existe une exception : si la source de multidiffusion est située sur un réseau directement connecté au routeur. Dans ce cas, il n’y a pas besoin d’une règle de requête.

Voici une autre exception : si un routeur voisi n est configur é statiquem ent po ur délivre r un flux de mult idiffusi on vers le firewall D-Link. Là encore, il est inutile de spécifier une requête IGMP.

NetDefendOS est compatible avec deux modes de fonctionnement d’IGMP : surveillance et Proxy.

Figure 4.6. Surveillance multicast

Routage

Figure 4.7. Proxy de multidiffusion

En mode surveillance, le routeur agit de manière transparente entre l’hôte et un autre routeur IGMP. Il n’envoie aucune requête IGMP. Il se contente de transférer les requêtes et les rapports entre l’autre routeur et l’hôte. En mode Proxy, le routeur agit comme un routeur IGMP envers les clients et envoie des requêtes de manière active. Envers le routeur émetteur, il agit comme un hôte normal qu i souscrit à des groupes de multidiffusion à la place de ses clients.

Configuration des règles IGMP sans traduction d’adresses

Cet exemple décrit les règles IGMP nécessaires pour configurer l’IGMP selon le scénario sans traduction d’adresses décrit ci-dessus. Nous voulons que le routeur agisse comme un hôte e nvers le routeur émetteur. Il faut donc configurer l’IGMP pour qu’il fonctionne en mode proxy.

Routage

Exemple 4.10. IGMP sans traduction d’adresses

L’exemple suivant requiert un groupe d’interfaces configuré, IfGrpClients, qui comprend les interfaces if1, if2 et if3. L’adresse IP du routeur IGMP émetteur est connue en tant que UpstreamRouterIP. Nous avons besoin de deux règles. La première est une règle de rapport qui permet aux clients se situant derrière les interfaces if1, if2 et if3 de souscrire au groupe de multidiffusion 239.192.10.0/24. La deuxième est une règle de requête qui permet au routeur émetteur de nous envoyer une requête pour les groupes de multidiffusion que les clients demandent. La procédure suivante doit être respectée pour créer ces deux règles :

Interface Web A. Créez la première règle IGMP. Sélectionnez Routing > IGMP > IGMP Rules > Add > IGMP Rule (Routage > IGMP > R ègles IGMP > Ajouter

> Règle IGMP).

Sous General (Général), entrez :

Name (nom) : un nom qui convient pour la règle (par exemple, Reports).

Type : Report (Rapport)

Action : Proxy

Output (Sortie) : wan (qui est l’interface relais)

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : lfGrpClients

Source Network (Réseau source) : if1net, if2net, if3net

Destination Interface (Interface de destination) : core (noyau)

Destination Network (Réseau de destination) : auto

Multicast Source (Source de multidiffusion) : 192.168.10.1

Multicast Group (Groupe de multidiffusion) : 239.192.10.0/24

Cliquez sur OK.

B. Créez la deuxième règle IGMP : Retournez dans Routing > IGMP > IGMP Rules > Add > IGMP Rule (Routage > Règles IGMP > Ajouter >

Règle IGMP).

Sous General (Général), entrez :

Name (nom) : un nom qui convient pour la règle (par exemple, Queries).

Type : Query (Requête)

Action : Proxy

Output (Sortie) : IfGrpClients (qui est l’interface de relais)

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : wan

Source Network (Réseau source) : UpstreamRouterIp (IP du routeur émetteur)

Destination Interface (Interface de destination) : core (noyau)

Routage

Destination Network (Réseau de destination) : auto

Multicast Source (Source de multidiffusion) : 192.168.10.1

Multicast Group (Groupe de multidiffusion) : 239.192.10.0/24

Cliquez sur OK.

Configuration des règles IGMP avec traduction d’adresses

Les exemples suivant indiquent les règles IGMP nécessaires pour configurer l’IGMP selon le scénario de traduction d’adresses décrit dans la section intitulée « Transfert multicast avec traduction d’adresses ». Deux règles de rapport IGMP sont nécessaires, c’est-à-dire une pour chaque interface client. If1 ne fait pas de traduction d’adresses et if2 traduit le groupe de multidiffusion en 237.192.10.0/24. Deux règles de requête sont aussi nécessaires : une pour l’interface et l’adresse traduites, l’autre pour l’envoi de l’adresse d’origine vers if1.

Vous trouverez ci-après deux exemples, un pour chaque paire de règle. Le routeur qui émet en multidiffusion utilise l’IP UpstreamRouterIP.

Exemple 4.11. Configuration de if1

La procédure suivante doit être respectée pour créer la paire de règles de rapport et de requête pour if1 qui n’utilise pas de traduction d’adresses.

Interface Web A. Créez la première règle IGMP. Sélectionnez Routing > IGMP > IGMP Rules > Add > IGMP Rule (Routage > IGMP > R ègles IGMP > Ajouter

> Règle IGMP).

Sous General (Général), entrez :

Name (nom) : un nom qui convient pour la règle (par exemple, Reports_if1).

Type : Report (Rapport)

Action : Proxy

Output (Sortie) : wan (qui est l’interface relais)

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : if1

Source Network (Réseau source) : if1net

Destination Interface (Interface de destination) : core (noyau) Destination Network (Réseau de destination) : auto

Multicast Source (Source de multidiffusion) : 192.168.10.1

Multicast Group (Groupe de multidiffusion) : 239.192.10.0/24

Cliquez sur OK.

B. Créez la deuxième règle IGMP : Retournez dans Routing > IGMP > IGMP Rules > Add > IGMP Rule (Routage > Règles IGMP > Ajouter >

Règle IGMP). Sous General (Général), entrez :

Routage

Name (nom) : un nom qui convient pour la règle (par exemple, Queries_if1).

Type : Query (Requête)

Action : Proxy

Output (Sortie) : if1 (qui est l’interface relais)

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : wan

Source Network (Réseau source) : UpstreamRouterIp (IP du routeur émetteur)

Destination Interface (Interface de destination) : core (noyau)

Destination Network (Réseau de destination) : auto Multicast Source (Source de multidiffusion) : 192.168.10.1

Multicast Group (Groupe de multidiffusion) : 239.192.10.0/24

Cliquez sur OK.

Exemple 4.12. Configuration d’if2 et traduction de groupe

La procédure suivante doit être respectée pour créer la paire de règles de rapport et de requête pour if2 qui fait la traduction du groupe de multidiffusion. Notez que le groupe traduit et que les rapports IGMP incluent donc les adresses IP traduites. Les requêtes contiennent les adresses IP d’origine.

Interface Web A. Créez la première règle IGMP. Sélectionnez Routing > IGMP > IGMP Rules > Add > IGMP Rule (Routage > IGMP > R ègles IGMP > Ajouter

> Règle IGMP).

Sous General (Général), entrez :

Name (nom) : un nom qui convient pour la règle (par exemple, Reports_if2).

Type : Report (Rapport)

Action : Proxy Output (Sortie) : wan (qui est l’interface relais)

Sous Address Filter (Filtre d’adresses), entrez :

Source Interface (Interface source) : if2

Source Network (Réseau source) : if2net

Destination Interface (Interface de destination) : core (noyau)

Destination Network (Réseau de destination) : auto

Multicast Source (Source de multidiffusion) : 192.168.10.1

Multicast Group (Groupe de multidiffusion) : 239.192.10.0/24

Cliquez sur OK.

B. Créez la deuxième règle IGMP :

D-LINK NETDEFEND User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual