Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Pare-feu d’application

Le pare-feu d’application (AppFW) assure une mise en application basée sur des stratégies et un contrôle du trafic basé sur les signatures d’application. AppFW vous permet de bloquer tout trafic applicatif non autorisé par l’entreprise. Pour plus d’informations, consultez les rubriques suivantes :

Présentation du pare-feu d’application

Cette rubrique comprend les sections suivantes :

Limites des pare-feu dynamiques

Traditionnellement, les pare-feu dynamiques servaient à contrôler des applications telles que HTTP, SMTP et DNS, car ces applications utilisaient uniquement des ports standard connus. Toutefois, il est désormais possible d’exécuter ces applications sur n’importe quel port tant que le client et le serveur utilisent le même protocole et les mêmes ports. En raison de ces pare-feu dynamiques standard ne sont pas en mesure de détecter les applications furtives. De plus, avec la popularité croissante des applications Web et le passage des applications client complètes traditionnelles au Web, de plus en plus de trafic est transmis via HTTP.

Cette limitation des pare-feu dynamiques, dans lesquels les pare-feu inspectent le trafic en fonction des couches 3 et 4, est restée ouverte pour permettre les failles de la couche applicative.

Pare-feu d’application

Le pare-feu applicatif (AppFW) de Juniper Networks exploite les résultats de l’identification des applications pour prendre une décision éclairée de autoriser, refuser, rejeter ou rediriger le trafic en fonction des applications. AppFW vous permet d’appliquer le contrôle des stratégies sur le trafic de couche 7.

Une base de données de signatures prédéfinie est disponible sur le site Web d’ingénierie de sécurité de Juniper Networks. Cette base de données comprend une bibliothèque de signatures d’applications. Voir Signatures d’application pour plus de détails. Ces pages de signatures vous offrent une visibilité sur la catégorie d’application, le groupe, le niveau de risque, les ports, etc.

AppFW vous permet de bloquer les applications en fonction de leurs signatures d’application, tout en autorisant la transmission du trafic HTTP par le pare-feu. Par exemple, une règle de pare-feu d’application peut bloquer le trafic HTTP depuis Facebook, mais autoriser l’accès Web au trafic HTTP depuis MS Outlook.

Avantages du pare-feu d’application

  • Contrôle granulaire de la sécurité des applications à haut risque en fonction de stratégies définies par l’utilisateur.

  • Offre une plus grande flexibilité en assurant un contrôle des stratégies sur l’accès aux applications en fonction des exigences.

Pare-feu d’application avec stratégies unifiées

À partir de Junos OS version 18.2R1, vous pouvez utiliser des stratégies unifiées pour bénéficier des mêmes fonctionnalités qu’une configuration AppFW. Les stratégies unifiées exploitent les informations d’identité de l’application issues du service d’identification des applications (AppID) pour autoriser, refuser, rejeter ou rediriger le trafic. Une configuration de stratégie unifiée gère toutes les fonctionnalités de pare-feu des applications et simplifie la tâche de configuration d’une stratégie de pare-feu.

Lisez l’un des sujets suivants pour configurer AppFW :

Prise en charge du pare-feu d’application avec des stratégies unifiées

À partir de Junos OS version 18.2R1, les équipements SRX Series et les instances vSRX prennent en charge des stratégies unifiées, ce qui permet un contrôle granulaire et une application des applications dynamiques de couche 7 au sein de la stratégie de sécurité traditionnelle.

Les stratégies unifiées sont des stratégies de sécurité qui vous permettent d’utiliser des applications dynamiques en tant que conditions de correspondance dans le cadre des conditions de correspondance 5 ou 6 tople (5-tuple avec le pare-feu utilisateur) existantes afin de détecter les changements d’application au fil du temps.

  • Si vous prévoyez de mettre à niveau Junos OS version 18.2R1 et versions ultérieures, notez les points suivants concernant l’utilisation de la fonctionnalité APPFW :

    • Toutes les instructions et commandes CLI associées à AppFW existantes sont obsolètes. C’est-à-dire...

      À partir de la version 18.2R1 du système d’exploitation Junos, la fonctionnalité de pare-feu d’application (AppFW) est obsolète, au lieu d’être immédiatement supprimée, afin de fournir une rétrocompatibilité et de mettre votre configuration en conformité avec la nouvelle configuration. Dans le cadre de ce changement, la [edit security application-firewall] hiérarchie et toutes les options de configuration sous cette hiérarchie sont obsolètes.

    • La fonctionnalité AppFW fonctionne si vous continuez à configurer dans la hiérarchie obsolète. Vous pouvez configurer AppFW dans la hiérarchie dépréciée dans l’interface de ligne de commande uniquement en entrée manuelle.

    • La configuration d’une stratégie AppFW traditionnelle et d’une stratégie unifiée dans la même stratégie de sécurité n’est pas prise en charge. Si vous tentez de le faire, le système affiche le message d’erreur suivant :

  • Si vous faites une mise à niveau de Junos OS version 18.2R1 vers des versions antérieures de Junos OS :

    • Vous devez supprimer toutes les stratégies unifiées pour éviter une défaillance de vérification de validation après une mise à niveau inférieure.

Par exemple, pour configurer des stratégies unifiées, reportez-vous à La configuration de stratégies de sécurité unifiées.

Exemple : configurer le pare-feu des applications avec une stratégie unifiée

Cet exemple décrit comment configurer une stratégie unifiée afin d’autoriser ou de bloquer le trafic en fonction des applications.

Configuration système requise

Configuration système requise

Cet exemple utilise les composants matériels et logiciels suivants :

  • Équipement SRX Series exécutant Junos OS version 18.2R1. Cet exemple de configuration est testé avec Junos OS version 19.1R1.

Avant de commencer

Aperçu

Dans cet exemple, vous créez un scénario très courant pour bloquer certaines applications et groupes d’applications comme Yahoo-Mail et Facebook-Access.

Topologie

Cet exemple utilise la topologie comme illustré sur la figure 1.

Figure 1 : Exemple de topologie pour les stratégies unifiées Topology For Unified Policies Example

Cet exemple utilise la configuration des zones et interfaces suivantes.

  • Le système client est connecté à l’interface ge-0/0/0.0 avec l’adresse IP 4.0.0.254/24. Elle fait partie de la zone de confiance.

  • Le système du serveur est connecté à l’interface ge-0/0/1.0 avec l’adresse IP 5.0.0.254/24. Il fait partie de la zone non fiable.

Créez une configuration de stratégie de sécurité pour bloquer certaines applications en suivant les étapes suivantes :

  • Créez une stratégie de sécurité pour le trafic depuis la zone trust pour ne pas établir de sécurité afin de bloquer l’accès aux applications Yahoo-Mail ou Facebook-Access.

  • Créez un message de redirection pour le trafic refusé ou rejeté pour informer l’utilisateur de l’état de sa demande.

  • Créez une stratégie par défaut pour autoriser le reste du trafic.

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure

Procédure étape par étape

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette méthode, reportez-vous à Using the CLI Editor in Configuration Mode (Utilisation de l’éditeur de cli en mode configuration ) dans le guide de l’utilisateur cli.

Pour configurer une stratégie unifiée à l’aide d’applications dynamiques :

  1. Configurez les zones et interfaces de sécurité.

  2. Créez un profil de redirection.

  3. Créez une stratégie de sécurité avec une application dynamique comme critère de correspondance.

  4. Créez une stratégie par défaut pour autoriser le trafic restant.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Utilisez les procédures suivantes pour vérifier si la configuration de la stratégie.

Vérification de l’action des stratégies

But

Vérifiez que la stratégie unifiée a bloqué les applications configurées.

Action

Depuis votre navigateur Web, essayez d’accéder à l’application. Par exemple, Yahoo-Mail. Le système affiche le message de redirection comme illustré dans l’image suivante.

Sens

Chaque fois que la stratégie de sécurité rejette le trafic en fonction de l’application dynamique, la sortie affiche le message de redirection tel que configuré par vous dans le profil d’application dynamique.

Vérification de la configuration des stratégies unifiées

But

Vérifiez que la configuration de la stratégie unifiée est correcte.

Action

Depuis le mode opérationnel, saisissez la show security policies detail commande pour afficher un résumé détaillé de toutes les stratégies de sécurité sur l’équipement.

Sens

Le résultat affiche des informations sur la stratégie de sécurité. Vérifiez les informations suivantes :

  • Configuration du nom de la stratégie policy-1 et rejet de l’action de la stratégie.

  • Applications dynamiques configurées junos:FACEBOOK-ACCESS et junos:YAHOO-MAIL.

  • Redirection du profil1.

Pare-feu d’application traditionnel

Cette rubrique comprend les sections suivantes :

Comprendre le fonctionnement du pare-feu d’application

Comme vous pouvez utiliser la stratégie de sécurité existante pour appliquer les contrôles traditionnels de pare-feu sur le trafic, vous pouvez utiliser le module AppFW pour bloquer certains trafics d’application, en fonction de leurs signatures d’application, tout en autorisant le passage d’autres trafics HTTP par le pare-feu.

L’équipement de sécurité traite le trafic dans l’ordre suivant lorsque vous avez configuré un AppFW :

  1. La stratégie de sécurité correspond à la paire de zones spécifiée dans la stratégie.

  2. La stratégie de sécurité correspond aux conditions de correspondance des paquets (adresses IP source et de destination, ports source et de destination, et type d’application)

  3. La stratégie de sécurité applique l’une des actions suivantes au trafic correspondant.

    • Refuser : notifie le client, rejette le trafic et enregistre l’événement.

    • Refuser : rejette le trafic et enregistre l’événement.

    • Autoriser : ouvre une session, enregistre l’événement et applique les services comme spécifié.

      • Appeler les services d’application pour récupérer l’ID de l’application pour le trafic.

      • Appliquez l’ensemble de règles de pare-feu d’application spécifiées.

    Note:

    Si vous utilisez Junos OS version 20.1 ou versions ultérieures et que vous avez configuré la signature d’application personnalisée basée sur HTTP, l’action de redirection de pare-feu d’application héritée peut ne pas fonctionner pour le trafic HTTPS. Au lieu de rediriger le trafic HTTPS, l’équipement de sécurité refuse ou rejette le trafic.

    Note:

    Tous les paquets IP fragmentés reçus sur l’équipement de sécurité doivent être réassemblés avant d’être transféré.

Ensembles et règles de règles de pare-feu d’application

Lors de la configuration du pare-feu d’application, envisagez de :

  • Vous pouvez appliquer une règle AppFW à plusieurs stratégies de sécurité différentes.

  • Vous pouvez configurer une AppFW à l’intérieur d’un système logique.

  • Vous pouvez configurer plusieurs applications dynamiques dans une règle et plusieurs règles dans un ensemble de règles. Toutefois, le nombre global d’ensembles de règles et de règles est limité.

  • Vous pouvez configurer un groupe d’applications dynamique comme critère de correspondance dans une règle. Un groupe d’applications comprend plusieurs applications associées. Pour plus d’informations, consultez Groupes d’applications prédéfinis et personnalisés pour l’identification des applications.

  • La règle par défaut définit l’action requise pour tout trafic qui ne correspond à aucune règle. Un jeu de règles AppFW doit donc contenir une règle par défaut.

Pare-feu d’application avec ALG

Sur vos équipements de sécurité, lorsque vous activez ALG, l’identification des applications inclut les résultats ALG pour identifier les applications dans la session de contrôle. AppFW autorise les sessions de données ALG chaque fois que les sessions de contrôle sont autorisées. Si la session de contrôle est refusée, aucune session de données n’est en cours. Si vous désactivez ALG, l’identification de l’application s’appuie sur les signatures pour identifier l’application dans les sessions de contrôle et de données. Si aucune correspondance de signature n’est trouvée, l’application est considérée comme inconnue. AppFW gère les applications en fonction du résultat d’identification des applications.

Applications inconnues

L’identification des applications classifie les applications dynamiques inconnues avec ID junos:UNKNOWN. AppID utilise le mot-clé réservé junos:UNKNOWN dans les cas suivants

  • Le trafic ne correspond pas à une signature d’application dans la base de données.

  • Le système rencontre une erreur lors de l’identification de l’application.

  • La session échoue sur un autre équipement.

Le trafic avec un ID d’application de junos:UNKNOWN associe une règle à une application dynamique de junos:UNKNOWN. Si aucune règle n’est définie pour junos:UNKNOWN, la règle par défaut est appliquée.

Journalisation des sessions pour les pare-feu d’applications

Vous pouvez consigner le trafic en activant l’option de journalisation dans le cadre d’une stratégie de sécurité. Remarque : lors de l’inspection d’un message journal lorsque AppFW est configuré comme étant donné dans le tableau 1 :

Tableau 1 : Journalisation des sessions pour la configuration du pare-feu d’application

Mesures de stratégie de sécurité

Création de journaux

Plus de détails

Permis

Crée une session et consigne un message de création de session

Lorsque la stratégie de sécurité autorise l’action crée une session avant même que les règles AppFW ne soient appliquées, le message de journalisation inclut l’une des mises à jour suivantes :

  • Si l’application est déjà identifiée, ses informations sont ajoutées au message de création de session.

  • Si l’application est en cours d’identification, le champ d’application dynamique est mis à jour comme INCONNU.

Rejet/refus

Les journaux rejettent ou refusent le message, mais ne créent pas de session.

Lorsqu’une règle AppFW refuse ou rejette le trafic, le message du journal inclut l’une des expressions suivantes dans le champ motif :

  • appfw deny Ou appfw deny redirect

  • appfw reject Ou appfw reject redirect

  • policy deny

  • policy reject

Prise en charge du pare-feu d’applications dans le cluster de châssis

Lorsque votre équipement de sécurité est en mode cluster de châssis, l’action AppFW avant et après le basculement dépend de l’état d’identification des applications, comme illustré dans le tableau 2.

Tableau 2 : Actions du pare-feu d’application

Avant basculement

Après basculement

État de l’ID de l’application Action du pare-feu d’application État de l’ID de l’application Action du pare-feu d’application

Succès

Nier

Succès

Nier

Succès

Permis

Succès

Permis

Attente

INCONNU

Action basée sur la règle définie pour l’application inconnue

Si aucune règle n’est définie pour l’inconnu, la règle par défaut est appliquée.

Remarque : lorsque votre équipement de sécurité est en mode cluster de châssis :

  • Lorsque vous activez l’identification de l’application, les ID d’application à l’état antérieur ne sont pas synchronisés avec d’autres nœuds. S’il y a des sessions de basculement, qui étaient encore en cours de classification, aucun ID d’application ne sera affecté. Cela pourrait entraîner des statistiques sur les applications et des incompatibilités.

  • La mise à niveau logicielle en cours d’utilisation (ISSU unifiée) n’est pas prise en charge en raison de l’absence de prise en charge de l’infrastructure de cluster de châssis . Par conséquent, l’événement de basculement est contrôlé via la stratégie de pare-feu de l’application en autorisant ou en refusant les applications dynamiques inconnues.

Création de redirections dans le pare-feu d’application

Lorsqu’AppFW nie ou rejette le trafic, elle n’avertit pas les clients qu’une telle mesure est effectuée. Les clients qui ignorent que leur demande est rejetée peuvent continuer à essayer d’accéder à la page Web. Pour atténuer cette gêne, Junos OS vous permet de fournir une explication de l’action ou de rediriger le client vers une page Web informative. Les exemples suivants vous montrent comment créer un message de redirection.

Redirection avec message de blocage

Utilisez l’option block-message avec la reject règle AppFW ou deny l’action.

Lorsque AppFW rejette le trafic, un écran d’éclaboussures affiche le message par défaut suivant à l’utilisateur :

Personnaliser le message de redirection

Vous pouvez personnaliser l’action de redirection en incluant du texte supplémentaire sur l’écran de démarrage ou en spécifiant une URL à laquelle vous pouvez rediriger un utilisateur. Pour personnaliser le message de bloc, vous devez créer un profil de message de bloc au [edit security application-firewall] niveau de la hiérarchie et définir le type et le contenu comme illustré dans l’exemple suivant.

Ensuite, vous renvoiez le profil de message de bloc dans le jeu de règles AppFW et l’appliquez à une ou plusieurs règles à l’aide de l’option block-message ;

Dans ce cas, AppFW affiche le message de bloc configuré chaque fois qu’il rejette le trafic en fonction de la règle configurée.

Personnaliser le message de redirection avec l’URL

Lorsque AppFW rejette ou redirige le trafic, vous pouvez rediriger le client vers la page Web spécifiée pour une action ultérieure. L’URL peut être hébergée sur l’équipement SRX Series ou sur un serveur externe.

Vous pouvez définir les redirections vers l’autre serveur en configurant le type de message de bloc comme url de redirection personnalisée, comme illustré dans l’exemple ci-dessous :

Ensuite, vous vous référez au profil de message de bloc dans le jeu de règles AppFW et vous appliquez à une ou plusieurs des règles en utilisant l’option block-message comme illustré dans l’exemple suivant :

Dans ce cas, AppFW redirige l’utilisation vers l’URL http://abc.company.com/information chaque fois qu’elle rejette le trafic en fonction de la règle configurée.

Exemple : Configuration du pare-feu d’application

Cet exemple montre comment configurer des ensembles de règles de pare-feu d’application dans la stratégie de sécurité.

Avant de commencer

Configuration système requise

  • Équipement SRX Series avec Junos OS version 15.1X49-D60 ou ultérieure. Cet exemple de configuration est testé pour Junos OS Version 15.1X49-D60.

Aperçu

Dans cet exemple, vous créez un pare-feu d’application pour les deux scénarios courants suivants décrits dans le tableau 3.

Tableau 3 : Configuration du pare-feu d’application pour autoriser ou refuser le trafic

Objectifs

Étapes à suivre

Résultats

Bloquer une application et autoriser d’autres applications

Configurez une stratégie de sécurité pour autoriser le trafic HTTP.

La stratégie de sécurité autorise ou supprime le trafic en fonction des critères de couche 3 ou 4 spécifiés correspondant.

Configurez un ensemble de règles AppFW avec les options suivantes :

  • Règles avec des applications dynamiques que vous souhaitez bloquer

  • Action pour refuser le trafic dynamique des applications.

  • Règle par défaut pour autoriser d’autres trafics

AppFW évalue le trafic autorisé au niveau de la couche 7 en fonction de son ID d’application.

Reportez-vous aux règles AppFW définies dans la stratégie de sécurité.

  • AppFW bloque le trafic correspondant aux applications dynamiques configurées.

  • La stratégie par défaut autorise d’autres trafics.

Autoriser une application et bloquer d’autres applications

Configurez une stratégie de sécurité pour autoriser le trafic HTTP.

La stratégie de sécurité autorise ou supprime le trafic en fonction des critères de couche 3 ou 4 spécifiés correspondant.

Configurez un ensemble de règles AppFW avec les options suivantes :

  • Règles avec les applications dynamiques que vous souhaitez autoriser

  • Action pour autoriser le trafic dynamique des applications.

  • Règle par défaut pour bloquer l’autre trafic.

AppFW évalue le trafic autorisé au niveau de la couche 7 en fonction de son ID d’application.

Reportez-vous aux règles AppFW définies dans la stratégie de sécurité.

  • AppFW autorise le trafic correspondant aux applications dynamiques configurées.

  • La stratégie par défaut bloque d’autres trafics.

Note:

Sur tous les équipements SRX Series, les pages J-Web pour les services AppSecure sont préliminaires. Nous vous recommandons d’utiliser l’interface CLI pour configurer les fonctionnalités AppSecure.

Configuration

Règle de pare-feu d’application pour refuser explicitement certaines applications et autoriser tout le reste

Dans cet exemple, vous bloquez les applications dynamiques junos:FACEBOOK-CHAT junos:FACEBOOK-FARMVILLE et autorisez le trafic restant.

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette méthode, consultez le Guide de l’utilisateur CLI.

Pour configurer deux stratégies de sécurité avec des ensembles de règles de pare-feu d’application permettant ou refusant le trafic provenant de différentes applications dynamiques :

  1. Définissez un ensemble de règles de pare-feu d’application pour refuser le trafic provenant d’applications dynamiques sélectionnées.

  2. Configurez la stratégie de sécurité pour autoriser le trafic HTTP et appeler la règle de pare-feu d’application définie rs1.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show security policies show security application-firewall commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Règle de pare-feu d’application pour autoriser explicitement certaines applications et refuser tout le reste

Dans cet exemple, vous autorisez junos-applications dynamiques :FACEBOOK-ACCESS et bloquez le trafic restant.

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette méthode, consultez le Guide de l’utilisateur CLI.

Pour configurer deux stratégies de sécurité avec des ensembles de règles de pare-feu d’application permettant ou refusant le trafic provenant de différentes applications dynamiques :

  1. Configurez une stratégie de sécurité pour traiter tout trafic qui ne va pas vers les ports statiques HTTP avec le jeu de règles de pare-feu d’application rs2.

  2. Définissez la règle de pare-feu d’application définie pour autoriser le trafic à partir d’applications dynamiques sélectionnées.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show security policies show security application-firewall commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les tâches suivantes :

Vérification de la configuration du pare-feu d’application

But

Vérifiez les informations relatives à la prise en charge du pare-feu des applications dans le cadre de la stratégie de sécurité.

Action

Pour vérifier la configuration de la stratégie de sécurité activée avec le pare-feu de l’application, saisissez les show security policies commandes. show security policies detail Pour vérifier tous les jeux de règles de pare-feu d’application configurés sur l’équipement, saisissez la show security application-firewall rule-set all commande.

Sens

La sortie affiche des informations sur les stratégies de pare-feu d’application configurées sur le système. Vérifiez les informations suivantes.

  • Ensemble de règles

  • Règles

  • Critères de correspondance

Exemple : Configuration du pare-feu d’application avec les groupes d’applications

Le module d’identification des applications (AppID) gère les groupes d’applications prédéfinis. Un groupe d’applications inclut des applications apparentées sous un seul nom pour une réutilisation simplifiée et cohérente lorsqu’elles sont utilisées dans n’importe quel service d’application. Un groupe d’applications peut contenir plusieurs applications et groupes d’applications simultanément. Il est possible d’attribuer une application à plusieurs groupes.

Vous pouvez configurer une règle AppFW pour autoriser ou refuser le trafic en spécifiant un groupe d’applications prédéfini et des applications comme critères de correspondance.

L’avantage de l’utilisation de groupes d’applications prédéfinis est : lorsque la base de données de signatures d’application change, le groupe d’applications prédéfini est automatiquement modifié pour inclure de nouvelles signatures. Dans ce cas, si vous disposez déjà d’une règle AppFW avec un groupe d’applications prédéfini, l’inclusion de nouvelles signatures dans le groupe d’applications n’affecte pas la règle AppFW existante.

Cet exemple montre comment configurer des groupes d’applications dans un ensemble de règles AppFW.

Avant de commencer

Configuration système requise

  • Équipement SRX Series avec Junos OS version 15.1X49-D60 ou ultérieure. Cet exemple de configuration est testé pour Junos OS Version 15.1X49-D60.

Aperçu

Dans cet exemple, vous configurez une stratégie de sécurité pour contrôler le trafic sortant de la zone de confiance vers la zone non sécurisée. Ensuite, vous créez une règle AppFW pour autoriser le trafic spécifique des applications (junos:GOOGLETALK), mais refuser tout autre trafic d’application similaire connu (trafic des réseaux sociaux) en utilisant le groupe d’applications.

Il est très important de noter l’ordre des règles AppFW car, le groupe prédéfini junos:social-networking inclut l’application junos:GOOGLETALK. Pour autoriser le trafic junos:GOOGLETALK et refuser le reste du groupe, vous devez placer la règle autorisant le trafic junos:GOOGLETALK avant que la règle refuse le trafic du reste des applications du groupe.

Configuration

Procédure

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la procédure à suivre, consultez Utilisation de l’éditeur de cli en mode configuration.

Pour configurer les ensembles de règles de pare-feu des applications et les stratégies de sécurité pour le trafic sortant :

  1. Créez le réseau social défini par des règles.

  2. Définissez une règle permettant le trafic Google-Talk.

  3. Définissez une seconde règle qui refuse tout autre trafic de réseaux sociaux et de trafic provenant d’une application inconnue.

    Notez que la séquence de règles est très importante. Vous devez placer la règle avec junos:GOOGLETALK avant la règle avec junos:social-networking. Sinon, la règle AppFW nie même le trafic GOOGLETALK sur junos:social-networking.

  4. Définissez la règle par défaut qui autorise tous les autres trafics.

  5. Configurez la stratégie de trafic sortant pour appliquer les règles de réseau social à l’ensemble du trafic sortant.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show security application-firewall show security policies commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Vérification de la configuration du pare-feu d’application

But

Vérifiez les informations relatives à la prise en charge du regroupement d’applications dans le cadre de la stratégie de pare-feu de l’application.

Action
  • Pour vérifier la configuration de la stratégie de pare-feu de l’application activée avec le regroupement d’applications, depuis le mode opérationnel, saisissez les show security policies et show security policies detail les commandes.

  • Pour vérifier tous les jeux de règles de pare-feu d’application configurés sur l’équipement, à partir du mode opérationnel, saisissez la show security application-firewall rule-set all commande.

  • Pour vérifier la liste des applications définies dans le groupe d’applications, depuis le mode opérationnel, saisissez la show services application-identification application-group application-group-name commande.

Exemple : configuration du pare-feu d’application lorsque le proxy SSL est activé

Cet exemple décrit comment configurer une appFW lorsque vous avez activé le proxy SSL.

Pour application junos-https, le proxy SSL détecte une session SSL en fonction de l’application dynamique identifiée pour cette session. Si des serveurs Web connus exécutent des ports non standard, vous pouvez utiliser une application Junos OS personnalisée pour identifier l’application. Toutefois, si les serveurs Web ne sont pas connus, par exemple sur Internet, vous pouvez utiliser application any. Les sessions non SSL qui passent par la règle de stratégie sont ignorées par le proxy SSL. Un SSL_PROXY_SESSION_IGNORE syslog est envoyé pour ces sessions. Juniper Networks recommande d’utiliser les applications « n’importe quel » avec précaution, car cela peut entraîner une grande quantité de trafic, ce qui entraîne un traitement initial du proxy SSL, ce qui a un impact sur les performances.

L’équipement de sécurité contourne les services de proxy SSL si, lorsqu’un profil de proxy SSL est associé à la règle de sécurité, lorsqu’aucun des services (AppFW, IDP ou AppTrack) n’est configuré

Exigences

Avant de commencer :

Configuration système requise

  • Équipement SRX Series avec Junos OS version 15.1X49-D60 ou ultérieure. Cet exemple de configuration est testé pour Junos OS Version 15.1X49-D60.

Aperçu

Dans cet exemple, vous configurez deux stratégies de sécurité avec des ensembles de règles AppFW pour autoriser ou refuser le trafic en texte clair ou chiffré :

  • Autorisez la version chiffrée d’Oracle et refusez tout autre trafic chiffré.

  • Autorise tout le trafic HTTP, sauf Hulu.

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette méthode, consultez le Guide de l’utilisateur CLI.

  1. Configurez une stratégie de sécurité pour traiter le trafic avec un ensemble de règles AppFW et un profil de proxy SSL.

  2. Configurez une autre stratégie de sécurité avec un ensemble de règles AppFW.

  3. Définissez le jeu de règles AppFW afin de permettre une version chiffrée du trafic Oracle et de refuser tout autre trafic chiffré.

  4. Définissez une autre règle AppFW pour autoriser tout le trafic en texte clair, à l’exception de Hulu.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant les show security policies show security application-firewall commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Note:

Vérification du pare-feu d’application dans une stratégie de proxy SSL

But

Vérifiez que l’application est configurée correctement lorsque le proxy SSL est activé dans une stratégie.

Action

Dans le mode opérationnel, saisissez la show security policies commande.

Le résultat suivant affiche les options de la show security flow session commande.

Pour afficher les sessions SSL encrypted UNKNOWN, utilisez la show security flow session application-firewall dynamic-application junos:SSL extensive commande.

Pour afficher toutes les sessions HTTPS, utilisez la show security flow session application-firewall dynamic-application junos:HTTP encrypted extensive commande.

Tableau Historique des versions
Libération
Description
18.2R1
À partir de la version 18.2R1 du système d’exploitation Junos, la fonctionnalité de pare-feu d’application (AppFW) est obsolète, au lieu d’être immédiatement supprimée, afin de fournir une rétrocompatibilité et de mettre votre configuration en conformité avec la nouvelle configuration. Dans le cadre de ce changement, la [edit security application-firewall] hiérarchie et toutes les options de configuration sous cette hiérarchie sont obsolètes.