Action de refus configurable

Les stratégies de sécurité permettent aux administrateurs de permettre aux applications souhaitables de passer par le pare-feu et de bloquer les applications non désirées de se connecter à l'extérieur ou entre les réseaux.

L'action «autoriser» affectée à une stratégie de sécurité est assez simple, mais lorsqu'il s'agit de bloquer le trafic, plusieurs options sont disponibles pour un administrateur pour modifier le comportement du pare-feu, en fonction de l'application ou de la situation.

À partir de Pan-OS 7,0, un administrateur peut choisir l'action à appliquer aux sessions indésirables: Drop, Deny ou Reset:

L'action Drop est principalement utilisé comme une façon furtive de jeter le trafic. Le pare-feu va tout simplement jeter tous les paquets associés à une connexion indésirable, ne pas laisser le client ou le serveur savent que les paquets sont rejetés. C'est une bonne pratique courante pour réduire l'exposition au monde extérieur pendant que les balayages de port prendront plus longtemps pour terminer et se traduiront en criminalistique moins utilisable. S'il est souhaitable de faire savoir au client que la session n'est pas autorisée, un message ICMP inaccessible (ICMPv4 Type3 entreprise13, ICMPv6 Code1) peut être envoyé pour rendre le client conscient que l'hôte distant n'est pas disponible pour cette connexion. Cela peut aider la source gracieusement fermer ou effacer la session et empêcher les applications de rompre, le cas échéant.

L'action Deny détruira la session à l'aide de la méthode recommandée par application.

La description de l'application-ID contient une description d'action Deny de l'action entreprise si une stratégie de sécurité bloque l'application et a le jeu d'actions Deny. Si aucune action Deny n'est répertoriée, les paquets seront ignorés silencieusement. Drop-Reset va ignorer les paquets de la session et envoyer un paquet TCP RST pour que le client sache que la session a été terminée afin qu'elle puisse fermer la session localement.

Un administrateur peut également opter pour toujours envoyer un paquet de réinitialisation soit au client, soit au serveur, soit aux deux. Si la session est basée sur TCP, un paquet RST sera envoyé. Si la session est basée sur UDP ou ICMP, un ICMP inaccessible sera envoyé.

• L'envoi d'une réinitialisation uniquement au client garantit, par exemple, que les hôtes internes reçoivent une notification que la session a été réinitialisée et que le navigateur ne tourne pas à gauche ou que l'application peut fermer la session établie pendant que le serveur distant n'est pas au courant.
• Reset Server peut être utilisé pour s'assurer qu'un serveur interne est en mesure d'effacer un socket alors qu'un client externe n'est pas au courant.
• L'envoi d'une réinitialisation aux deux va permettre aux deux parties de savoir que la session a été bloquée.

Pour éviter d'envoyer trop de paquets ICMP inaccessibles, vous pouvez basculer le taux par seconde via les paramètres de session

Cette information vous a-t-elle été utile?

Sinceres salutations

Reaper