DotW : Problèmes avec le routage asymétrique

Ce qui est asymétrique routage, comment peut il être identifié, et quelles mesures doivent être prises pour minimiser votre exposition ? Apprendre comment le pare-feu de Palo Alto Networks, dans la détection de routage asymétrique, offre non seulement une protection, mais permet une certaine flexibilité avec le dépannage et l’intégration.

Discussion de cette semaine de la semaine (DotW) met l’accent sur une question posée par l’utilisateur Apadilla sur le routage asymétrique.

Le routage asymétrique est une situation où les paquets suivent un itinéraire différent dans une direction sortante qu’ils suivent lors du retour dans la direction entrante.

En général, une configuration asymétrique est assez normale dans de nombreux environnements réseau. Il peut être créé à l’aide de protocoles de routage dynamique, mais peut aussi être causée par une mauvaise configuration. Dans les réseaux plus élémentaires, routage asymétrique n’est pas un problème, comme TCP ne soucie pas quel chemin un paquet traverse, tant que les paquets sont reçus par les deux parties dans un délai raisonnable.

Routage asymétrique devient un problème lorsqu’un pare-feu est ajouté au réseau, et l’asymétrie empêche le pare-feu de voir les deux sens de l’écoulement. Le pare-feu de Palo Alto Networks n’inspecte les sessions à la couche 7 mais inspecte également au niveau des couches inférieures pour vérifier les sessions sont fluides comme prévu et n’ont pas été trafiquées. Quelques vérifications qui entrent en jeu lorsqu’un routage asymétrique est introduit comprennent des contrôles pour vérifier les paquets sont reçus dans l’ordre de la séquence correcte.  Si les paquets sont reçus à l’intérieur de la fenêtre coulissante, et si la connexion TCP suit le bon ordre, c'est-à-dire, un paquet d’accusé de réception ne peut être reçu avant un paquet SYN est vu.

Pour indiquer les paquets sont être jetés parce qu’une des conditions ci-dessus est respectée, plusieurs compteurs peuvent incrémenter :

tcp_drop_out_of_wnd out-of-Window paquets supprimés
tcp_out_of_sync ne peut pas continuer le remontage TCP, car il est hors de synchronisation
flow_tcp_non_syn paquets TCP non-syn sans session match
flow_tcp_non_syn_drop paquets supprimés: non-SYN TCP sans match de session  

Le pare-feu de Palo Alto Networks, basé sur le type de trafic, crée une fenêtre coulissante de la séquence, commençant par la dernière ack qu'il a reçu dans un flux.

• Compteurs d’incrément de tcp_drop_out_of_wnd et tcp_out_of_sync lorsque des paquets sont reçus qui ne relèvent pas de la fenêtre coulissante.
• Si ack paquets sont reçus qui ne correspondent pas à une session existante qui a été correctement mises en place via une négociation à trois voies TCP, flow_tcp_non_syn et incrémentent les compteurs flow_tcp_non_syn_drop.

Dans les deux cas peuvent se produire, soit simultanément, soit à des moments différents, si le pare-feu ne voit qu’une seule direction de la session.

Dans certains cas, vous pouvez désactiver ces contrôles TCP pour permettre plus facilement de dépannage ou d’intégration. Par exemple, lorsqu’un nouveau pare-feu est déployé dans un réseau existant, il suffit d’insérer le pare-feu peut provoquer les compteurs à incrémentation et des paquets à supprimer, à cause du pare-feu étant inséré dans une session après la négociation à trois voies TCP et le pare-feu n’étant ne pas au courant qu'il s’agit d’une session valide.

Si la zone source des flux asymétriques est inconnue ou couvre tous les réseaux, ces commandes CLI peuvent être définies pour désactiver les contrôles de santé mentale TCP :

> configurer 
entrée en mode configuration
[Edit] 
# Set deviceconfig Setting TCP asymétrique-Path Bypass
# Set deviceconfig Setting session TCP-Reject-non-syn no
# Commit    

Si la zone source de l’écoulement asymétrique est connue, telle qu’une connexion WAN MPLS nouvellement ajoutée, un profil de protection de zone peut être configuré pour autoriser ce genre de trafic mal formé d’une ou plusieurs zones spécifiques encore exécution santé mentale TCP de contrôles pour toutes les autres zones connectés au firewall.

Ceci peut être réalisé en créant un profil de protection de zone dans les réseaux > profils réseau > Zone Protection > <profile>> paquet base contre les attaques > TCP Drop > rejeter Non-SYN TCP & asymétrique Path :</profile>

Ce profil peut ensuite être assigné à une zone de désactiver ces contrôles pour cette zone spécifique :

Une fois les paramètres systemwide sont désactivées ou le profil de Protection de Zone est ajouté à une zone, le seul compteur qui devrait encore augmenter est

flow_tcp_non_syn

 comme il s’agit d’un compteur indicateur que l’acheminement asymétrique a été détectée, mais aucune mesure prise.

Sachez que la désactivation de ces sanity TCP vérifie peuvent ont des implications de sécurité sévères comme un attaquant pourrait injecter des paquets qui serait normalement être mis au rebut. Il est recommandé de définir uniquement ces commandes afin de dépanner la cause de la zone de routage asymétrique ou temporairement contourner les contrôles tout en tenant compte de l’asymétrie, mais pas comme une solution permanente.

Pour une solution plus permanente, s’il vous plaît restez à l’écoute pour les prochains articles de l’équipe de la Communauté, ou jetez un oeil ici :

PAN-OS actif/actif haute disponibilité

Pour visionner la discussion originale, veuillez suivre ce lien: problèmes avec routage asymétrique

Tous commentaires ou suggestions sont encouragées.

Merci pour la lecture!

Tom Piens