j'ai compris

[Dr.WoW] [No.24] GRE-partie 2

publié il y a  2020-4-28 23:22:20 7 0 0 0

3 Configuration des mécanismes de sécurité GRE

Je suppose que tout le monde a une inquiétude commune: si un utilisateur malveillant sur Internet a falsifié un paquet GRE pour donner l'impression qu'il était envoyé de FW_A à FW_B, ce prétendant ne pourrait-il pas alors accéder aux ressources de FW_B? Lors de la construction du tunnel GRE sur FW_A et FW_B, comment pouvons-nous parvenir à une confiance mutuelle? Ensuite, nous discuterons des mécanismes de sécurité du GRE.

1.         Validation des mots clés

Une fois que le tunnel GRE a été configuré sur le pare-feu, le pare-feu ne gère pas réellement tous les paquets GRE qu'il reçoit, mais gère uniquement les paquets GRE envoyés par le terminal correspondant avec lequel il a construit conjointement le tunnel GRE. Le segment "clé" dans l'en-tête GRE est utilisé pour réaliser cette fonction.

Lorsque le pare-feu encapsule les paquets avec un en-tête GRE, la valeur du bit de clé dans l'en-tête GRE est définie sur 1 et le segment de clé est inséré dans l'en-tête GRE. Lorsque deux pare-feu construisent un tunnel, la valeur de ce segment clé est utilisée par les pare-feu pour vérifier l'identité de l'autre, et le tunnel ne peut être construit que si la valeur de la clé définie par les deux terminaux correspondants est exactement identique.

La figure ci-dessous montre les informations de l'en-tête GRE. Dans cet en-tête, le fait que le bit de clé soit mis à 1 montre que la fonction de validation des mots clés a été activée, tandis que la "Clé: 0x00003039" près du bas est la valeur du mot clé (convertie en système décimal c'est '12345') .


[Dr.WoW] [No.24] GRE-part 2-1334959-1

Les étapes de configuration de la validation des mots clés sont très simples. La seule chose à laquelle il faut faire attention est que les mots-clés définis pour les pare-feu aux deux extrémités du tunnel doivent être identiques.

Définissez le mot clé sur 12345 sur FW_A.

[FW_A-Tunnel1] gre key 12345

Définissez également le mot clé sur FW_B sur 12345.

[FW_B-Tunnel1] gre key 12345

2.         Validation de la somme de contrôle

Bien que les pare-feu aux deux extrémités du tunnel aient maintenant établi une confiance mutuelle, s'il existe la possibilité que des paquets soient falsifiés par des utilisateurs malveillants lorsqu'ils sont transmis sur Internet, comment pouvons-nous garantir l'intégrité des paquets pendant la transmission? Le champ "checksum" dans l'en-tête GRE peut être utilisé ici.

Lorsqu'un pare-feu encapsule un en-tête GRE dans un paquet, la valeur du bit de somme de contrôle de l'en-tête GRE est définie sur 1. Une somme de contrôle est ensuite calculée en fonction des informations du paquet, et cette somme de contrôle est ajoutée au champ de somme de contrôle. Lorsque l'autre terminal du tunnel reçoit ce paquet, il peut également calculer une somme de contrôle sur la base des informations du paquet et la comparer avec la somme de contrôle portée par le paquet. Si les résultats de la vérification sont identiques, le pare-feu acceptera le paquet; s'ils ne sont pas identiques, le paquet sera rejeté.

La fonction de validation de la somme de contrôle est unidirectionnelle; le fait que l'autre pare-feu ait ou non activé la fonction n'affectera pas la fonction de validation de la somme de contrôle du pare-feu. Dans les environnements du monde réel, il est conseillé de l'activer simultanément sur les pare-feu aux deux extrémités du tunnel.

Dans la capture d'écran ci-dessous, le bit de total de contrôle de l'en-tête GRE est 1, ce qui signifie que la fonction de validation du total de contrôle a été activée. La "somme de contrôle: 0x8f8d" dans la figure ci-dessous est la valeur de la somme de contrôle.


[Dr.WoW] [No.24] GRE-part 2-1334959-2

Les étapes de configuration de la validation de la somme de contrôle sont également très simples. Pour activer la validation de la somme de contrôle sur FW_A:

[FW_A-Tunnel1] gre checksum

Pour activer la validation de la somme de contrôle sur FW_B:

[FW_B-Tunnel1] gre checksum

3.         Keepalive

Les mécanismes de sécurité du GRE peuvent établir une confiance mutuelle entre les pare-feu aux deux extrémités d'un tunnel et peuvent garantir l'intégrité de la transmission des paquets. Cependant, il y a toujours un problème: si l'un des terminaux d'un tunnel a une panne / un problème, comment l'autre terminal du tunnel peut-il détecter cela?

Les tunnels GRE sont une sorte de tunnel sans état. Ce mot "sans état" signifie qu'un terminal du tunnel ne déterminera pas l'état de l'autre terminal. Ou, pour dire les choses autrement, si un problème survient avec un terminal du tunnel, le terminal à l'autre extrémité du tunnel ne pourra pas le détecter. Pour résoudre ce problème, le tunneling GRE fournit le mécanisme Keepalive.

Comme le montre la figure 1-7 , une fois la fonction Keepalive activée sur FW_A, FW_A enverra régulièrement des paquets de sonde à FW_B pour détecter l'état de cette autre extrémité du tunnel. Si FW_B peut être atteint, alors FW__A recevra un paquet de réponse de FW_B, et FW_A maintiendra alors l'état normal du tunnel. Si FW_A ne reçoit pas de paquet de réponse de FW_B, cela signifie que FW_B est inaccessible et FW_A fermera le tunnel. Cela évite les "trous noirs" des données car l'un des terminaux d'un tunnel est inaccessible.

Figure 1-7 Fonction GRE Keepalive




[Dr.WoW] [No.24] Partie GRE 2-1334959-3 


La fonction Keepalive est unidirectionnelle; le fait qu'un terminal active ou non la fonction Keepalive n'affecte pas la fonction Keepalive de l'autre terminal. Dans des environnements réels, il est conseillé que les deux pare-feu d'un tunnel activent cette fonction simultanément.

Les commandes pour activer la fonction Keepalive sont données ci-dessous. Voici la commande pour activer la fonction Keepalive sur FW_A:

[FW_A-Tunnel1] keepalive

Pour activer la fonction Keepalive sur FW_B:

[FW_B-Tunnel1] keepalive

À ce stade de notre leçon, je suppose que tout le monde pense que les tunnels GRE sont une bonne chose, mais en réalité ce n'est pas complètement correct. Le tunnel GRE a son propre talon d'Achille: il ne comprend pas de fonction de cryptage de sécurité. Les paquets GRE sans paquets de chiffrement de sécurité ne sont vraiment que des «alter-egos» transparents, et les paquets sont tous «visibles» lorsqu'ils sont transmis dans le tunnel. Par conséquent, dans la vie réelle, nous utilisons très rarement GRE seul, mais nous utilisons plutôt fréquemment GRE et IPSec ensemble. La technologie IPSec étant équipée de fonctions de cryptage très puissantes, cette approche résout les problèmes de sécurité de GRE, et c'est la technologie GRE sur IPS que nous expliquerons ci-dessous.

4 Approche de la configuration de la politique de sécurité

Dans le «Chapitre 2 Politiques de sécurité», nous avons déclaré que «les flux de données transmis par un pare-feu et les flux de données entre un pare-feu et l'extérieur sont contrôlés par des politiques de sécurité». Dans cet esprit, quelles interfaces et zones de sécurité devons-nous utiliser avec GRE? Comment configurer les politiques de sécurité à utiliser avec GRE? En raison de l'existence d'interfaces de tunnel, la configuration de la politique de sécurité GRE peut être un peu compliquée et déroutante. Mais heureusement pour vous, le Dr WoW a une suite de méthodes que je vais utiliser pour vous aider à comprendre cela!

Dans la figure 1-8 , les interfaces F0_A et FW_B GE0 / 0/1 sont connectées à des réseaux privés et appartiennent à la zone de confiance; les interfaces GE0 / 0/2 appartiennent à la zone Untrust; l'interface du tunnel appartient à la zone DMZ.

Figure 1-8 Configuration d'une stratégie de sécurité GRE VPN d'un réseau


[Dr.WoW] [No.24] GRE-part 2-1334959-4 

Le processus de configuration des politiques de sécurité est le suivant:

1.         Nous configurons d'abord une politique de sécurité interzone aussi large que possible, afin de faciliter l'ajustement / les tests GRE.

L'action de filtrage de paquets par défaut interzone de FW_A est définie sur "autoriser":

[FW_A] firewall packet-filter default permit all

L'action de filtrage de paquets par défaut interzone de FW_B est définie sur "permettre":

[FW_B] firewall packet-filter default permit all

2. Une         fois GRE configuré, PC_A envoie un ping à PC_B. La table de session est ensuite vérifiée. En utilisant FW_A comme exemple:

[FW_A] display firewall session table verbose

 Current Total Sessions : 2

  gre  VPN:public --> public

  Zone: local--> untrust  TTL: 00:04:00  Left: 00:03:37

  Interface: GigabitEthernet0/0/2  NextHop: 1.1.1.2  MAC: 54-89-98-87-22-a4

  <--packets:4 bytes:352   -->packets:5 bytes:460

  1.1.1.1:0-->2.2.2.2:0

 

  icmp  VPN:public --> public

  Zone: trust--> dmz  TTL: 00:00:20  Left: 00:00:00

  Interface: Tunnel1  NextHop: 192.168.2.2  MAC: 00-00-00-00-00-00

  <--packets:1 bytes:60   -->packets:1 bytes:60

  192.168.1.2:22625-->192.168.2.2:2048


Les informations ci-dessus montrent que PC_A peut exécuter une commande ping sur PC_B et qu'une session GRE a été correctement et normalement établie.

3.         *** ysis du tableau de session permet de sélectionner la politique de sécurité la plus appropriée pour les conditions existantes.

Nous pouvons voir deux flux sur la table de session. L'un est les paquets ICMP de Trust à DMZ, et l'autre est les paquets GRE de Local à Untrust. Cela nous permet d'obtenir la direction des paquets sur FW_A, comme le montre la figure 1-9 .


Figure 1-9 Direction du paquet FW_A

[Dr.WoW] [No.24] GRE-part 2-1334959-5

 

La figure ci-dessus montre que FW_A doit configurer une stratégie de sécurité Trust -> DMZ qui autorise les paquets de PC_A cherchant à accéder à PC_B; une autre politique de sécurité Local -> Untrust qui permet à FW_A et FW_B d'établir un tunnel GRE doit également être configurée.

De même, nous pouvons également obtenir la direction des paquets sur FW_B, comme le montre la figure 1-10 .


Figure 1-10 Direction du paquet FW_B

[Dr.WoW] [No.24] GRE-part 2-1334959-6

 

La figure ci-dessus montre que FW_B doit configurer une politique de sécurité DMZ -> Trust qui autorise les paquets de PC_A cherchant à accéder à PC_B; une autre stratégie Untrust -> Local security qui autorise FW_A et FW_B à établir un tunnel GRE doit également être configurée.

Lorsque PC_B initie des appels sur PC_A, la direction du paquet est l'opposé de la direction lorsque PC_A accède à PC_B, et il n'est pas nécessaire de l'examiner davantage.

Pour résumer, les politiques de sécurité qui doivent être configurées sur FW_A et FW_B sous diverses conditions sont présentées dans le tableau 1-1 , et nous devons configurer les politiques de sécurité qui correspondent le mieux aux conditions existantes, comme indiqué dans le tableau.

Tableau 1-1 Sélection des politiques de sécurité pour FW_A et FW_B en fonction des conditions

Direction de la transaction

Dispositif

Zone de sécurité source

Zone de sécurité de destination

Adresse source

Adresse de destination

Utilisé dans

PC_A accède à PC_B

FW_A

Local

Méfiance

1.1.1.1/32

2.2.2.2/32

GRE

Confiance

DMZ

192.168.1.0/24

192.168.2.0/24

*

FW_B

Méfiance

Local

1.1.1.1/32

2.2.2.2/32

GRE

DMZ

Confiance

192.168.1.0/24

192.168.2.0/24

*

PC_B accède à PC_A

FW_A

Méfiance

Local

2.2.2.2/32

1.1.1.1/32

GRE

DMZ

Confiance

192.168.2.0/24

192.168.1.0/24

*

FW_B

Local

Méfiance

2.2.2.2/32

1.1.1.1/32

GRE

Confiance

DMZ

192.168.2.0/24

192.168.1.0/24

*

*: L'utilisation dans cette instance est liée au type de transaction et peut être configurée en fonction des circonstances réelles (par exemple: TCP, UDP et ICMP).

 

 

Dans les scénarios GRE, les interfaces de tunnel de FW_A et FW_B doivent être ajoutées aux zones de sécurité, et les zones de sécurité auxquelles appartiennent les interfaces de tunnel pour déterminer la direction des paquets dans un pare-feu . Si l'interface du tunnel appartient à la zone de confiance, aucune politique de sécurité interzone DMZ-Trust ne doit être configurée, mais cette approche comporte également des risques de sécurité. Par conséquent, je suggère que l'interface de tunnel soit ajoutée à une zone de sécurité distincte, puis configurée avec la politique de sécurité qui correspond le mieux aux conditions existantes.

4.         Enfin, l'action de filtrage de paquets par défaut est remplacée par "refuser".

Définissez l'action de filtrage de paquets par défaut de FW_A sur "refuser":

[FW_A] firewall packet-filter default deny all

Définissez l'action de filtrage de paquets par défaut de FW_B sur "refuser":

[FW_B] firewall packet-filter default deny all

Bien que le processus de réglage / test susmentionné soit un peu difficile, les politiques de sécurité configurées de cette manière sont relativement raffinées et peuvent garantir de manière adéquate la sécurité des pare-feu et du réseau interne.

 

 

Pour afficher la liste de tous les postes techniques du Dr. WoW, cliquez ici .


  • x
  • Standard:

Commentaire

envoyer
Connectez-vous pour répondre. Se connecter | Enregistrer

Remarque Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Politique de confidentialité ».
Si le bouton de la pièce-jointe n'est pas disponible, mettez à jour Adobe Flash Player à la dernière version.

My Followers

Connectez-vous pour participer à la communication et au partage

S'identifier

Communauté de Support de Huawei Entreprise
Communauté de Support de Huawei Entreprise