Fondements de la politique de sécurité
Resolution
Fondements de la politique de sécurité
Table des matières
- Vue d’ensemble
- Deux types de stratégies de sécurité
- Sessions
- Topologie
- Service « application par défaut »
- L’occultation des règles
- Stratégies de sécurité basées sur les utilisateurs
- Stratégies de sécurité avec des adresses IP utilisant un NAT
- Catégories d’URL dans les politiques de sécurité
- Dépendances d’applications et de la demande de déplacements
- Décryptage et l’Identification de la demande
- Règle de nettoyage
- Conseils de politique de sécurité
- Documents associés
Vue d’ensemble
Ce document décrit les principes fondamentaux des politiques de sécurité sur le pare-feu de Palo Alto Networks.
Tout le trafic qui traversent la dataplane du firewall Palo Alto Networks est comparé à une stratégie de sécurité. Cela n’inclut pas le trafic provenant de l’interface de gestion du pare-feu, car, par défaut, ce trafic ne passe pas par le biais de la dataplane du pare-feu. Stratégies de sécurité du pare-feu peuvent être définies à l’aide de différents critères tels que des zones, des applications, adresses IP, ports, utilisateurs et profils de hanche. Pare-feu administrateurs peuvent définir des stratégies de sécurité pour autoriser ou refuser le trafic, commençant par la zone comme un critère large, puis mise au point de politiques avec des options plus granulaires tels que des ports, des applications et des profils de hanche.
Deux types de sécurité pProtoco
Le firewall a deux sortes de règles de sécurité :
- Stratégies de sécurité explicites sont définies par l’utilisateur et visible dans l’interface CLI et Web-UI.
- Stratégies de sécurité implicites sont des règles qui ne sont pas visibles pour l’utilisateur via l’interface CLI ou interface Web-UI. La section suivante traite des stratégies de sécurité implicites sur Palo Alto Networks firewalls.
Stratégies de sécurité implicites
Par défaut, le pare-feu autorise implicitement le trafic intra-zone (l’origine et destination dans la même zone) et nie implicitement le trafic inter zone (entre différentes zones). Le trafic accordés ou refusés par les politiques implicites ne sont pas connectés le pare-feu par défaut, donc aucun journal ne peut être trouvé pour ce trafic. Pour être enregistré par le pare-feu, le trafic doit correspondre à une politique de sécurité explicitement configuré sur le pare-feu. Toutefois, pour des fins de dépannage, le comportement par défaut peut être modifié. Référez-vous à: Comment voir le trafic des stratégies de sécurité par défaut dans les journaux de trafic.
Sessions
Le pare-feu de Palo Alto Networks est un pare-feu à État, ce qui signifie que tout le trafic passant par le pare-feu est comparé à une session et que chaque session est ensuite comparée à une stratégie de sécurité.
Une séance se compose de deux flux. Le Client à serveur débit (c2s) et le serveur à Client débit (s2c). Le point de terminaison où trafic lance est toujours le Client et le point de terminaison où le trafic est destiné est le serveur. Pour définir les stratégies de sécurité, seulement le c2s flow direction besoins à prendre en considération. Définir des stratégies qui autoriser ou refuser le trafic de la zone d’origine à la zone de destination, c'est-à-dire dans la direction de c2s. Le reflux, s2c, ne nécessite pas une nouvelle règle. L’évaluation de la politique de sécurité sur le pare-feu ne se produit dans l’ordre de haut en bas dans la liste, trafic correspondant à la première règle plus proche dans la liste s’applique à la session.
Voici un exemple de la façon d’identifier les flux dans une session de la CLI :
> Afficher les id de session 107224
Session 107224
C2S Flow:
Source : 172.23.123.5 [Test]
DST : 172.23.123.1
proto : 50
sport : 37018 dport : 37413
Etat : type actif : TUNN
utilisateur de SRC : inconnu
DST utilisateur: inconnu
S2C Flow:
Source : 172.23.123.1 [Test]
DST : 172.23.123.5
proto : 50
sport : 37750 dport : 50073
Etat : type actif : TUNN
utilisateur de SRC : inconnu
DST utilisateur: inconnu
Topologie
Dans ce document, la topologie suivante s’applique aux cas des stratégies de sécurité d’utilisation :
Service « application par défaut »
Dans l’exemple ci-dessous, les stratégies de sécurité allow et deny trafic correspondant aux critères suivants.
- Règle a : toutes les applications initiées à partir de la zone de confiance en IP sous-réseau 192.168.1.0/24 destinés à la zone Untrust doivent être autorisées sur n’importe quel port source et destination.
- Règle b : les applications, DNS, navigation Web, lancée depuis la zone de confiance d’IP 192.168.1.3 destinée à la zone Untrust le trafic FTP doit être accueillie.
- Les demandes doivent être restreints à utiliser uniquement dans les ports de « application par défaut ». Par exemple, la requête DNS, par défaut, utilise le port destination 53. Si la demande DNS puisse seulement sur ce port. À l’aide de cette application sur les autres ports de destination devrait être rejetée.
- Règle c : toutes les autres applications de 192.168.1.3 à la zone Untrust doivent être bloquées.
- Règle d : tout le trafic effectué à partir de la zone Untrust vers toutes les zones doit être bloqué.
La colonne de Service dans les stratégies de sécurité définit les ports source et destination où le trafic devrait être autorisé. Les quatre options sont :
- Application-default: pour autoriser le trafic sur les ports de destination par défaut.
Reportez-vous au document suivant pour plus de détails sur la recherche des ports de destination par défaut utilisés par diverses applications:
voir: comment afficher les ports d'application par défaut d'une application. - Any: pour autoriser le trafic sur les ports source et de destination.
- Services prédéfinis: services déjà définis sur le pare-feu.
- Services personnalisés: les administrateurs peuvent définir des services en fonction de leurs exigences de port d'application.
L’exemple affiche les règles qui sont créés pour correspondre aux critères ci-dessus.
En commettant les modifications de configuration ci-dessus, les avertissements d’ombre suivants sont affichent :
L’impact des avertissements de l’ombre et des conseils pour les éviter on discute ensuite.
L’occultation des règles
Dans l’exemple ci-dessus, l’adresse IP 192.168.1.3 appartient à la zone de confiance et tombe dans le sous-réseau 192.168.1.0/24. Étant donné que le pare-feu est une recherche de politique de sécurité de haut en bas, tout le trafic IP 192.168.1.3 correspond à la règle A et s’appliqueront à la session. Bien que le trafic satisfait également aux critères de la règle B et C de la règle, ces règles ne s’appliqueront à ce trafic parce que la règle A est l’occultation règle B et C. règle
Pour éviter l’impact de l’occultation, règle B et C de la règle doivent précéder l’article A, comme indiqué ci-dessous. Maintenant le trafic correspond à l’encontre des règles de bonne et empêche les « avertissements de l’ombre » au cours de la validation.
Stratégies de sécurité basées sur les utilisateurs
Dans l’exemple ci-dessus, les politiques sont rédigés basée sur les adresses IP. De la même manière, utilisateurs LDAP, LDAP groupes et utilisateurs définis localement sur les pare-feu peuvent également être utilisés dans les stratégies de sécurité. Consulter les documents suivants pour plus de détails sur la façon de configurer l’ID utilisateur et ajoutez les utilisateurs à la politique de sécurité :
Comment ajouter des groupes à la politique de sécurité
Stratégies de sécurité dont l’adresse IP NATed
Cette section explique comment écrire des stratégies de sécurité quand une traduction d’adresses IP est impliqué et aussi comment utiliser les catégories d’URL dans les politiques de sécurité pour contrôler divers sites Web.
Dans l’exemple suivant, les stratégies de sécurité sont définis pour correspondre aux critères suivants :
Adresse IP publique 192.0.2.1 dans la zone Untrust est traduite en adresse IP privée 10.1.1.2 du serveur Web dans la zone DMZ.
- Trafic entrant de la zone Untrust sur le serveur Web 10.1.1.2 dans la Zone DMZ doit être autorisé sur le port 25, 443 et 8080 seulement.
- Tous les utilisateurs dans la zone de confiance doivent se voir refuser l’accès aux sites de catégorie « Adulte et pornographie » dans la zone Untrust.
- Tout autre trafic de la zone de confiance à la zone Untrust doit être autorisé.
Les règles ci-dessous montrent la configuration satisfaisant aux critères ci-dessus.
Tout le trafic destiné au serveur Web de la zone Untrust aura une adresse IP publique de destination de 192.0.2.1, qui appartient à la zone Untrust. Étant donné que le trafic est originaire de la Zone Untrust et destiné à une adresse IP dans la Zone Untrust, ce trafic est autorisé par une règle implicite qui permet le trafic même zone. Après recherche de politique de sécurité, le pare-feu effectue une recherche de politique NAT et détermine que l’adresse IP publique du serveur Web doit se traduit en privé IP 10.1.1.2, situé dans la zone DMZ. À ce stade, le pare-feu est la zone de destination finale (DMZ), mais la traduction réelle de la propriété intellectuelle de 192.0.2.1 à 10.1.1.2 n’arrive pas encore. Après avoir déterminé les informations de la zone de destination finale pour le trafic post-NAT, le pare-feu effectue une deuxième recherche de stratégie de sécurité pour trouver une stratégie qui autorise le trafic destiné à la zone de destination finale, DMZ. Ainsi, X règle ci-dessus est configuré pour autoriser le trafic NAT post. Notez que la règle X a DMZ (zone de Post-NAT) comme la zone de destination et le 192.0.2.1 (pré-NAT IP) que l’adresse IP de destination. Dans l’exemple ci-dessus, un service « Web-server_Ports » est configuré pour permettre le port de destination 25, 443 et 8080. Pour plus d'informations, consultez: Comment configurer une stratégie pour utiliser une plage de ports.
Catégories d’URL dans les politiques de sécurité
Dans l’exemple ci-dessus, règle Y est configuré pour bloquer les sites de catégorie adulte à l’aide de l’option de la catégorie URL présente dans les stratégies de sécurité. Application de navigation Web doit être explicitement mentionnée dans les politiques lorsque vous utilisez l’option URL de la catégorie dans les stratégies de sécurité. Dans le cas contraire, le trafic sans rapport avec correspondre à cette règle. Une autre façon de contrôler les sites Web basés sur les catégories d’URL consiste à utiliser les profils de filtrage d’URL.
Dépendances d’applications et de la demande de déplacements
Cette section traite de « dépendance d’application » et décrit ce qui se passe à la session lorsque l’id d’application change au milieu d’une session.
Dans l’exemple suivant, les stratégies de sécurité sont définis pour autoriser et refuser le trafic correspondant aux critères suivants.
- Les applications Gotomeeting, Youtube de la zone de confiance à la zone Untrust doit être accueilli.
- Les applications Facebook, Gmail-base de la zone de commentaires à la zone Untrust doit être accueilli.
- Demandes SSL et la navigation sur le Web doivent être bloquées pour les utilisateurs de zone de commentaires.
L’exemple affiche les règles qui sont créés pour correspondre aux critères ci-dessus.
Bien que commettant la configuration change, on peuvent considérer les avertissements suivants de dépendance application.
Des applications comme Gotomeeting et YouTube sont initialement identifié comme SSL, navigation sur le web et Citrix. Comme plus de paquets pour ces séances passent à travers le pare-feu, plus d’informations pour identifier l’application sont disponibles pour le pare-feu. Le pare-feu puis déplace l’application aux demandes respectives comme Gotomeeting et Youtube.
Chaque fois qu’un changement d’application se produit, le pare-feu fait une nouvelle recherche de politique de sécurité pour trouver la règle du plus proche correspondant à la nouvelle application. Si dans le cas ci-dessus, SSL et la navigation sur le web sont appelées des applications dépendantes pour Gotomeeting et YouTube, ainsi ces applications devraient également être autorisées dans les stratégies de sécurité. Si l'application du trafic change au milieu de la session, une seconde recherche de stratégie de sécurité recorrespond au trafic par rapport aux stratégies de sécurité pour trouver la nouvelle stratégie de correspondance la plus proche.
Dans l’exemple ci-dessus, une nouvelle politique de sécurité, « Règle de dépendance Apps », est créée pour permettre au SSL et la navigation sur le web. YouTube le trafic au départ correspond à la règle et une fois le changement d’application se produit, une deuxième recherche de politique de sécurité est matchs contre la règle 10.
Depuis Pan-OS 5,0, les applications pour certains protocoles peuvent être autorisées sans avoir à autoriser explicitement leurs dépendances (voir: Comment vérifier si une application doit avoir explicitement autorisé des applications de dépendance). Dans l’exemple ci-dessus, Facebook et gmail-base sont des applications qui dépendent de SSL et la navigation sur le web et leurs applications de dépendance explicitement autorisées n’ont pas besoin.
Décryptage et l’identification de la demande
Certaines applications telles que Vimeo, qui utilise SSL et sont cryptés, peuvent être identifiés par le pare-feu sans décryptage SSL. Toutefois, les applications comme YouTube, qui utilisent SSL, doivent être déchiffrées par le pare-feu pour leur identification. Étant donné que les connexions SSL sont cryptées, le pare-feu n’a aucune visibilité sur ce trafic afin de l’identifier. Le fait de pare-feu utilise le champ nom commun présent dans le certificat pour l’identification de la demande. Il est échangé en texte clair au cours du processus de négociation SSL.
Sites Web tels que Vimeo utilisent le nom de l’URL du site Web comme un nom commun et donc ne nécessite pas de décryptage SSL doit être configuré. Certains sites comme YouTube utilisent un certificat avec le nom générique comme nom commun. Dans le cas de YouTube, c’est *. google.com. Donc, en utilisant ces informations d’identification de la demande n’est pas possible, et le décryptage SSL doit être configuré pour entrer l’URL du site Web de visibilité. Reportez-vous au document suivant sur la façon d'implémenter et de tester le décryptage SSL
Règle de nettoyage
Certains environnements exigent tout le trafic nié et autorisés par le pare-feu. Par défaut, seul le trafic qui est explicitement autorisé par le pare-feu est connecté. Pour enregistrer le trafic qui est autorisé par les règles implicites du pare-feu, reportez-vous à :
Comportement par défaut de sécurité tout/toute/refus règle changements
Conseils de politique de sécurité
Les critères suivants est vérifié par le pare-feu dans le même ordre pour faire correspondre le trafic contre une politique de sécurité.
- Adresse source et destination
- Les ports source et destination
- Applications
- ID utilisateur
- Catégorie d’URL
- Zones source et de destination
Dans l’exemple de configuration ci-dessus, lors de l’application « navigation sur le web » sur le port TCP 80 à partir de la zone de confiance à la zone Untrust passe à travers le pare-feu, une recherche de sécurité est faite de la manière suivante :
- Adresse source/Destination - règle étant donné que A, B et C ai « toute » source et les adresses de destination, le trafic correspond à l’ensemble de ces règles.
- Les ports source et destination - règle étant donné que A, B et C ont « tous » les services, le trafic correspond à l’ensemble de ces règles.
- Applications - étant donné que la règle A et B a des applications « navigation sur le web », le trafic correspond à ces règles.
- User-ID - pas applicable en l’espèce.
- Catégorie de l’URL - pas applicable en l’espèce.
- Les zones source et de destination - puisque le trafic est entre confiance et Untrust, règle A est choisi pour ce trafic.
La meilleure façon de configurer des stratégies de sécurité consiste à réduire au minimum l’utilisation de « tout » et être précis avec les valeurs, lorsque cela est possible. Cela réduit les recherches de politique de sécurité inutiles effectués par le dispositif de Palo Alto Networks.
Documents connexes
Y a-t-il une limite au nombre de profils de sécurité et politiques par le dispositif ?
Comment identifier les politiques non utilisés sur un dispositif de Palo Alto Networks
Comment, à l’essai politique sur la sécurité qui s’appliquent à un flux de trafic.
Pourquoi les règles niant Applications permettant à certains paquets ?
Pourquoi « Non-applicable » apparaît dans les journaux de trafic ?
Comment identifier les politiques non utilisés sur un dispositif de Palo Alto Networks
Comment fonctionne la Session Rematch
Comment planifier des Actions politiques
Gestion des stratégies de sécurité avec Panorama
propriétaire : sdurga