Comment identifier les utilisateurs se connectant par proxy et restreindre l'accès par la stratégie de sécurité

45957

Created On 09/25/18 19:49 PM - Last Modified 01/28/24 04:44 AM

Symptom

Symptômes

Considérez un serveur proxy déployé entre les utilisateurs sur un réseau et un pare-feu. Dans un tel cas, le pare-feu affiche l'adresse IP du serveur proxy comme adresse IP source dans les journaux de trafic. Par conséquent, restreindre l'accès en fonction de l'utilisateur réel et de déterminer l'utilisateur réel à partir des journaux de trafic n'est pas possible.

Cet article vise à fournir une solution à ce problème.

Note: Ceci s'applique à Pan-OS 7,0 et ultérieur.

Diagnostic

Conditions préalables :

Le serveur proxy doit ajouter L'en-tête X-Forwarded-For (xff) contenant l'adresse IP réelle du client lors de la transmission au pare-feu
Configurer l'Identification de l'Utilisateur sur le pare-feu pour collecter le mappage IP-utilisateur
Activer l'identification XFF pour l'ID utilisateur. Pour en savoir plus, veuillez Cliquer ici.

Resolution

Configuration:

Serveur proxy (192.168.30.103)----pare-feu PA-----Internet

Configurer les stratégies de sécurité sur le pare-feu comme indiqué dans l'ordre:

Security Policies. png

Détails:

Autoriser DNS- requis pour autoriser les requêtes DNS avant la connexion réelle

Autoriser la poignée de main- nécessaire pour permettre à TCP 3-Way Handshake parce que xff serait dans http Get Packet, qui suivra la poignée de main 3-Way. Par conséquent, la cartographie utilisateur ne peut être déterminée qu'après la poignée de main initiale. Voici les journaux de trafic pour la poignée de main initiale à 3 voies:

Première poignée de main. png

Remarque Cette stratégie comporte un profil de filtrage d'URL appliqué pour ne permettre qu'une première poignée de main à 3 voies et aucune navigation sur le Web. Après la poignée de main à 3 voies, une action supplémentaire est déterminée par des stratégies spécifiques à l'utilisateur:

Handshake URL Filtering. png

XFF- requis pour restreindre l'accès basé sur l'utilisateur (l'application peut être changée en navigation Web spécifique [puisque xff est dans http] ou combinée avec d'autres stratégies basées sur l'utilisateur, au besoin. En outre, un profil de filtrage d'URL pourrait être appliqué pour plus de restrictions sur le trafic.

Une fois que les paquets http Get sont sur le pare-feu à partir d'un serveur proxy, le pare-feu vérifie la table de mappage utilisateur IP pour rechercher et appliquer des stratégies basées sur l'utilisateur source.

GET Packet:

XFF Packet-1. png Mappage utilisateur:

Mapping. png utilisateur

Changement de politique:

Policy Maj. png

Notes supplémentaires:

-Pour HTTPS, la poignée de main SSL complète doit être autorisée (comme permettre la poignée de main, mais pas de filtrage d'URL) et le décryptage SSL doit être activé pour lire L'en-tête xff et vérifier l'utilisateur-mappage

-S'il n'y a pas de mappage utilisateur pour l'IP dans xff, l'utilisateur source serait vide dans les journaux de trafic et les stratégies basées sur l'utilisateur n'entreront pas en action

-Si vous activez xff pour User-ID, les journaux de filtrage d'URL indiqueront username dans l'utilisateur source au lieu de xff IP. Pour voir comment activer XFF dans les journaux de filtrage d'URL, veuillez Cliquer ici

-XFF peut être activé pour les journaux de filtrage d'URL, même S'il n'y a pas de licence de filtrage d'URL. Pour plus de détails, veuillez Cliquer ici

Comment identifier les utilisateurs se connectant par proxy et restreindre l&#39;accès par la stratégie de sécurité

Symptom

Symptômes

Diagnostic

Resolution

Other users also viewed:

Comment identifier les utilisateurs se connectant par proxy et restreindre l'accès par la stratégie de sécurité