[Dr.WoW] [No.6] Annexe au mécanisme d'inspection et de session avec état

Dans la section 5 «Mécanisme d'inspection et de session avec état», nous apprenons comment fonctionne l'inspection avec état et ce que signifie 5 tuple. Maintenant, vous pouvez avoir les doutes suivants:

• Une session de pare-feu comprend-elle uniquement 5 tuples?

• Pour quels protocoles le pare-feu établit-il des connexions?

• L'inspection avec état s'applique-t-elle à tous les environnements réseau?

Dans cette annexe à la section précédente, Dr. WoW discutera plus en détail du mécanisme d'inspection et de session avec état, en présentera plus sur les sessions et conclura comment le pare-feu traite les paquets avec l'inspection avec état activée ou non. Espérons que cette annexe clarifiera vos doutes.

1 En savoir plus sur les sessions

Commençons également par une configuration réseau simple comme le montre la figure 1-1, où le PC et le serveur Web sont directement connectés au pare-feu. Le pare-feu a ajouté les ports du PC et du serveur Web à différentes zones de sécurité et appliqué une règle pour permettre au PC d'accéder au serveur Web.

Figure 1-1 Configuration réseau pour l'accès au serveur PC à Web

Le PC accède correctement au serveur Web. Si vous exécutez la commande display firewall session table verbose sur le pare-feu, vous pouvez constater que la session a été établie avec succès. Cette commande inclut le paramètre verbose , qui en demande plus sur la session.

[FW] display firewall session table verbose

Current Total Sessions : 1
  http  VPN:public --> public
  Zone: trust--> untrust  TTL: 00:00:10  Left: 00:00:04
  Interface: GigabitEthernet0/0/2  NextHop: 172.16.0.1  MAC: 54-89-98-fc-36-96
  <--packets:4 bytes:465   -->packets:7 bytes:455
  192.168.0.1:2052-->172.16.0.1:80

En plus du 5-tuple, la sortie de la commande comprend plus:

• Zone: la direction dans laquelle les paquets circulent entre les zones de sécurité. trust-> untrust indique que les paquets circulent d'une zone de confiance vers une zone de non confiance.

• TTL: durée de vieillissement de la session. Lorsque TTL expire, la session est supprimée.

• Gauche: temps restant pour vivre la session.

• Interface: sortie de paquets.

• NextHop: adresse IP du saut suivant pour la destination des paquets, qui est l'adresse IP du serveur Web dans cette configuration réseau.

• MAC: adresse MAC du saut suivant pour la destination des paquets, qui est l'adresse MAC du serveur Web dans cette configuration réseau.

• <- paquets: 4 octets: 465: statistiques des paquets dans le sens inverse de la session, ou le nombre de paquets et d'octets envoyés par le serveur Web au PC.

• <- paquets: 7 octets: 455: statistiques de paquets dans le sens de la session de transfert, ou le nombre de paquets et d'octets envoyés par le PC au serveur Web.

Parmi les éléments précédents, deux méritent plus d'attention. L'un est le temps de vieillissement de la session. Une session est générée dynamiquement et n'existera pas pour toujours. Si une session ne correspond pas aux paquets depuis longtemps, les homologues de communication peuvent avoir été déconnectés et cette session n'est plus requise. Pour économiser les ressources système, le pare-feu supprimera la session après un certain laps de temps, appelé temps de vieillissement de la session.

Le temps de vieillissement de la session doit être réglé correctement. Si une session est vieillie sur une période trop longue, les ressources système seront inutilement occupées, ce qui affectera l'établissement d'autres sessions; si une session est vieillie sur une période trop courte, le pare-feu peut forcer la connexion au service. Pour différents types de protocoles, le pare-feu Huawei définit le temps de vieillissement par défaut approprié, par exemple, 20 s pour les sessions ICMP et 30 s pour les sessions DNS. Généralement, le temps de vieillissement par défaut garantit le bon fonctionnement des protocoles. S'il est nécessaire de modifier la durée de vieillissement par défaut, utilisez la commande firewall session aging-time. Par exemple, vous pouvez exécuter la commande suivante pour modifier le temps de vieillissement de la session DNS à 10 s.

[FW] firewall session aging-time dns 10

Pour un type de services en direct sur des réseaux, tels que les services de base de données SQL, les deux paquets consécutifs sur une connexion peuvent avoir un intervalle de temps étendu. Lorsqu'un utilisateur récupère des données sur un serveur de base de données SQL, l'intervalle de temps entre les récupérations peut dépasser de loin le temps de vieillissement de session du service de base de données SQL. Une fois que le pare-feu a vieilli la session pour ce service, l'utilisateur peut rencontrer un accès lent ou même un échec à la base de données SQL.

Une façon de résoudre le problème consiste à prolonger le temps de vieillissement de la session pour ces services, mais certaines autres sessions peuvent ne pas nécessiter un temps de vieillissement prolongé et doivent occuper inutilement les ressources système.

Pour résoudre complètement ce problème, le pare-feu Huawei fournit la fonction de connexion longue, qui prolonge le temps de vieillissement de session uniquement pour les paquets spécifiés qui correspondent à certaines règles ACL. Contrairement à la façon d'étendre le temps de vieillissement de session spécifique au protocole, la fonction de connexion longue prolonge le temps de vieillissement de session plus précisément. Par défaut, le temps de vieillissement de session pour les paquets avec la fonction de connexion longue appliquée est de 168 heures (assez long), qui peut également être modifié manuellement.

REMARQUE

Actuellement, la fonction de connexion longue s'applique uniquement aux paquets de protocole TCP.

La fonction de connexion longue peut être configurée pour s'appliquer à l'intérieur ou entre les zones de sécurité. Ce qui suit fournit un exemple de configuration de la fonction de connexion longue qui s'appliquera entre les zones de sécurité d'approbation et non d'approbation. Il est spécifique aux paquets de base de données SQL de l'adresse IP 192.168.0.1 (source) à l'adresse IP 172.16.0.2 (destination).

[FW] acl 3000
[FW-acl-adv-3000] rule permit tcp source 192.168.0.1 0 destination 172.16.0.2 0 destination-port eq sqlnet
[FW-acl-adv-3000] quit
[FW] firewall interzone trust untrust
[FW-interzone-trust-untrust] long-link 3000 outbound
WARNING: Too large range of ACL maybe affect the performance of firewall, please use this command carefully!
Are you sure?[Y/N]y

L'autre est les statistiques de paquets. Les statistiques des paquets dans les deux sens (identifiées par les symboles <- et ->) sont importantes pour localiser les défauts du réseau. S'il n'y a des statistiques de paquets que dans le sens "->" mais pas dans le sens "<-", les paquets du serveur PC vers Web ont passé le pare-feu mais pas les paquets serveur Web vers PC, ce qui signifie une communication anomalie. En ce qui concerne les causes possibles d'anomalie, le pare-feu peut avoir rejeté les paquets du serveur Web au PC, le pare-feu et le serveur Web peuvent avoir échoué la communication ou le serveur Web peut ne pas fonctionner correctement. La portée des défauts peut alors être réduite pour un dépannage plus facile. Il peut sûrement y avoir des exceptions. Dans un environnement réseau spécial, la communication peut être fonctionnelle même s'il n'y a pas de statistiques de paquets dans une direction.L'environnement réseau est-il spécial? Cela reste à voir dans les sections ultérieures.

2 Inspection avec état et établissement de la session

La fonction d'inspection dynamique du pare-feu prend les paquets sur une connexion en tant que flux de données complet. Comment exprimer une connexion en session? Cela nécessite la *** ysis du pare-feu des modes d'échange spécifiques au protocole. Ce qui suit utilise TCP comme exemple. Pour une connexion TCP, les homologues de communication doivent avoir une négociation à trois voies, comme le montre la figure 1-2.

Figure 1-2 Négociations à trois voies de TCP

Comme un paquet SYN identifie une connexion TCP, le paquet SYN est généralement appelé le paquet principal. Pour une connexion TCP, le pare-feu établit une session uniquement après avoir reçu les paquets SYN et la règle appliquée leur permet de passer. Ensuite, les paquets TCP qui correspondent à la session seront directement transmis. Si le pare-feu ne reçoit aucun paquet SYN, mais les paquets SYN + ACK ou ACK suivants, il n'établit pas de session et rejette directement ces paquets.

Ce processus est correct, sauf dans des environnements réseau spéciaux. Comme le montre la figure 1-3, les paquets de demande du réseau interne vont directement au réseau externe via le routeur, et les paquets de réponse du réseau externe sont transmis par le routeur au pare-feu, qui les retransmet ensuite au routeur. après les avoir traités. Enfin, le routeur transmet les paquets de réponse au réseau interne. En d'autres termes, le pare-feu ne reçoit aucun paquet SYN mais uniquement des paquets SYN + ACK. Dans cet exemple, les paquets de demande et de réponse sont transmis sur différents chemins.

Figure 1-3 Paquets de demande et de réponse transmis sur différents chemins

Dans cet environnement réseau, le pare-feu rejette les paquets SYN + ACK reçus car il n'y a pas de session pour eux. Par conséquent, les réseaux internes et externes ont interrompu la communication. Que faire ensuite?

Le pare-feu fournit une solution pour désactiver l'inspection dynamique. Une fois l'inspection avec état désactivée, le pare-feu ne *** *** pas l'état de la connexion comme le fait un pare-feu de filtrage de paquets. Ensuite, le pare-feu établit une session pour les paquets suivants si les règles (politiques de sécurité) leur permettent de passer, ce qui garantit une communication ininterrompue.

MISE EN GARDE

La désactivation de l'inspection avec état changera le mode de fonctionnement du pare-feu. Sur les réseaux en direct, ne désactivez pas l'inspection avec état, sauf indication contraire.

L'exemple suivant utilise une configuration réseau où les paquets de demande et de réponse sont transmis sur différents chemins comme exemple pour montrer comment le pare-feu traite les paquets de protocole TCP, UDP et ICMP, lorsque son inspection avec état est activée et désactivée.

TCP

Commençons par le protocole TCP. La configuration du réseau est simulée à l'aide de l'eNSP. Les paquets de demande du PC atteignent le serveur Web via le routeur et les paquets de réponse du serveur Web sont transmis au pare-feu, puis de nouveau au routeur et enfin au PC. La figure 1-4 montre la topologie du réseau.

REMARQUE

Pour simuler la configuration du réseau, le routage basé sur des règles (PBR) doit être configuré sur le routeur afin que les paquets de réponse du serveur Web soient redirigés vers le pare-feu. Pour plus de détails sur la configuration de PBR, consultez les guides de configuration associés au routeur. De plus, une route vers le PC doit être configurée sur le pare-feu et le prochain saut de la route doit être le port du routeur (adresse IP supposée: 10.1.2.2) connecté au port GE0 / 0/1 du pare-feu.

Figure 1-4 Requête TCP et paquets de réponse transmis sur différents chemins

Une règle répertoriée dans le tableau 1-1 est configurée sur le pare-feu pour autoriser le passage des paquets de réponse du serveur Web.

Tableau 1-1 Règle pour autoriser le passage des paquets de réponse du serveur Web

Lorsque l'inspection avec état est activée sur le pare-feu, une tentative d'accès du PC au serveur Web échoue, comme le montre la figure 1-5.

Figure 1-5 Échec du PC à accéder au serveur Web

Sur le pare-feu, aucune information de session ne peut être trouvée.

[FW] display firewall session table
Current Total Sessions : 0

Lorsque vous exécutez la commande display firewall statistic system discard pour vérifier la perte de paquets sur le pare-feu, vous constaterez que les paquets de session manqués sont rejetés .

[FW] display firewall statistic system discard
Packets discarded statistic
                            Total packets discarded:   8
                    Session miss packets discarded:   8

Ces informations indiquent que le pare-feu doit rejeter les paquets pour lesquels aucune session ne peut être trouvée. Comme le pare-feu reçoit les paquets SYN + ACK de réponse mais pas les paquets SYN, il n'y a pas de session et le pare-feu doit rejeter les paquets SYN + ACK.

Ensuite, vous utilisez la commande undo firewall session link-state check pour désactiver l'inspection avec état.

[FW] undo firewall session link-state check

Ensuite, une tentative d'accès du PC au serveur Web réussit et les informations de session peuvent être trouvées sur le pare-feu.

[FW] display firewall session table verbose
Current Total Sessions : 1
  tcp  VPN:public --> public
  Zone: untrust--> trust  TTL: 00:00:10  Left: 00:00:10
  Interface: GigabitEthernet0/0/1  NextHop: 10.1.2.2  MAC: 54-89-98-e4-79-d5
  <--packets:0 bytes:0   -->packets:5 bytes:509
  172.16.0.1:80-->192.168.0.1:2051

Dans les informations de session, il y a des statistiques de paquets dans le sens "->" mais aucune dans le sens "<-", ce qui signifie que seuls les paquets de réponse du serveur passent le pare-feu. Ensuite, nous pouvons conclure qu'après une inspection avec état désactivée, le pare-feu établit une session pour les paquets SYN + ACK reçus, maintenant la communication entre le PC et le serveur Web.

Sur un réseau où les paquets de demande et de réponse sont transmis sur différents chemins et où l'inspection avec état est désactivée sur le pare-feu, il n'y a pas de statistiques de paquets dans une direction de session mais la communication est normale. C'est ainsi que nous disons «spécial» dans les sections précédentes. Pour les réseaux en direct, aucune règle ne s'applique toujours.

UDP

Voyons ensuite le protocole UDP. Contrairement à TCP, UDP est un protocole sans connexion. Le pare-feu établit une session pour les paquets UDP reçus si la règle les autorise à passer, que l'inspection avec état soit activée ou non.

ICMP

Voyons enfin le protocole ICMP. ICMP est un rappel des tests ping. Les tests Ping sont généralement utilisés dans la maintenance de routine pour vérifier si un périphérique est accessible sur un réseau. Le périphérique sur lequel un test ping est effectué envoie une demande d'écho et le périphérique de destination répond par une réponse d'écho.

Lorsque l'inspection avec état est activée, le pare-feu établit une session pour la demande d'écho reçue uniquement si la règle de pare-feu l'autorise à passer, et n'établit aucune session pour la réponse d'écho reçue s'il ne reçoit pas la demande d'écho et rejette la réponse d'écho. Lorsque l'inspection avec état est désactivée, le pare-feu établit une session pour la demande ou la réponse d'écho.

Ce qui suit fournit un exemple d'informations de session pour un réseau où les paquets de demande et de réponse sont transmis sur différents chemins, et l'inspection avec état est désactivée sur le pare-feu.

[FW] display firewall session table verbose
Current Total Sessions : 1
  icmp  VPN:public --> public
  Zone: untrust--> trust  TTL: 00:00:20  Left: 00:00:11
  Interface: GigabitEthernet0/0/1  NextHop: 10.1.2.2  MAC: 54-89-98-e4-79-d5
  <--packets:0 bytes:0   -->packets:1 bytes:60
  172.16.0.1:2048-->192.168.0.1:45117

Pour les autres types de paquets ICMP, le pare-feu établit une session pour les paquets reçus si la règle les autorise à passer, que l'inspection avec état soit activée ou non.

Le tableau 1-2 conclut comment le pare-feu traite les paquets TCP, UDP et ICMP lorsque l'inspection avec état est activée ou désactivée, étant donné que la règle de pare-feu autorise le passage des paquets.

Tableau 1-2 Établissement de session pour les paquets TCP, UDP et ICMP

Les sections précédentes expliquent comment le pare-feu traite les paquets TCP, UDP et ICMP lorsque l'inspection avec état est activée ou désactivée, pour vous permettre de mieux comprendre le mécanisme d'inspection et de session avec état. La section suivante décrira les précautions essentielles pour configurer les zones de sécurité et le mécanisme d'inspection et de session avec état, et fournira également des directives de dépannage.

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