Pare-feu dynamiques
Présentation de Junos Network Secure
Les routeurs utilisent des pare-feu pour suivre et contrôler le flux du trafic. Les PIC de services adaptatifs et multiservices utilisent un type de pare-feu appelé . Contrairement à un pare-feu qui inspecte les paquets de manière isolée, un pare-feu dynamique fournit une couche de sécurité supplémentaire en utilisant des informations d’état dérivées de communications passées et d’autres applications pour prendre des décisions de contrôle dynamiques pour les nouvelles tentatives de communication.
Sur les routeurs ACX Series, la configuration de pare-feu dynamique est prise en charge uniquement sur les routeurs intérieurs ACX500.
Groupe de pare-feu dynamiques pertinent dans . Un flux est identifié par les cinq propriétés suivantes :
Adresse source
Port source
Adresse de destination
Port de destination
Protocole
Une conversation typique avec le protocole TCP (Transmission Control Protocol) ou le protocole UDP (User Datagram Protocol) se compose de deux flux : le flux d’initiation et le flux de répondeur. Toutefois, certaines conversations, telles qu’une conversation FTP, peuvent être composées de deux flux de contrôle et de nombreux flux de données.
Les règles du pare-feu déterminent si la conversation est autorisée à être établie. Si une conversation est autorisée, tous les flux de la conversation sont autorisés, y compris les flux créés pendant le cycle de vie de la conversation.
Vous configurez des pare-feu dynamiques à l’aide d’un puissant chemin de gestion des conversations basé sur des règles. A se compose de la direction, de l’adresse source, du port source, de l’adresse de destination, du port de destination, de la valeur du protocole IP et du protocole ou service de l’application. Outre les valeurs spécifiques que vous configurez, vous pouvez affecter la valeur any à des objets de règle, des adresses ou des ports, ce qui leur permet de correspondre à n’importe quelle valeur d’entrée. Enfin, vous pouvez éventuellement annuler les objets de règle, ce qui annule le résultat de la correspondance spécifique au type.
Les règles de pare-feu sont directionnelles. Pour chaque nouvelle conversation, le logiciel du routeur vérifie le flux d’initiation correspondant à la direction spécifiée par la règle.
Les règles de pare-feu sont ordonnées. Le logiciel vérifie les règles dans l’ordre dans lequel vous les incluez dans la configuration. La première fois que le pare-feu découvre une correspondance, le routeur implémente l’action spécifiée par cette règle. Les règles encore non cochées sont ignorées.
À partir de la version 14.2 de Junos OS, les cartes d’interface MS-MPC et MS-MIC prennent en charge le trafic IPv6 pour le pare-feu dynamique Junos Network Secure.
Pour plus d’informations, consultez Configuration de règles de pare-feu dynamique.
- Prise en charge du pare-feu dynamique pour les protocoles d’application
- Vérification des anomalies du pare-feu dynamique
Prise en charge du pare-feu dynamique pour les protocoles d’application
En inspectant les données de protocole de l’application, le pare-feu PIC AS ou MultiServices peut appliquer intelligemment les politiques de sécurité et ne laisser passer que le trafic de paquets minimal requis.
Les règles de pare-feu sont configurées par rapport à une interface. Par défaut, le pare-feu dynamique permet à toutes les sessions initiées à partir des hôtes derrière l’interface de passer par le routeur.
Les ALG de pare-feu dynamiques ne sont pas pris en charge sur les routeurs ACX500.
Vérification des anomalies du pare-feu dynamique
Le pare-feu dynamique reconnaît les événements suivants comme des anomalies et les envoie au logiciel IDS pour traitement :
Anomalies IP :
La version IP n’est pas correcte.
Le champ Longueur de l’en-tête IP est trop petit.
La longueur de l’en-tête IP est définie sur l’ensemble du paquet.
Mauvaise somme de contrôle d’en-tête.
Le champ Longueur totale de l’IP est plus court que la longueur de l’en-tête.
Le paquet a des options IP incorrectes.
Erreur de longueur de paquet ICMP (Internet Control Message Protocol).
La durée de vie (TTL) est égale à 0.
Anomalies d’adresse IP :
La source de paquets IP est une diffusion ou un multicast.
Attaque terrestre (IP source égale IP de destination).
Anomalies de fragmentation IP :
Chevauchement de fragments IP.
Fragment IP manqué.
Erreur de longueur de fragment IP.
La longueur des paquets IP est supérieure à 64 kilo-octets (Ko).
Attaque de minuscules fragments.
Anomalies TCP :
Port TCP 0.
Numéro de séquence TCP 0 et indicateur 0.
Numéro de séquence TCP 0 et drapeaux FIN/PSH/RST définis.
Indicateurs TCP avec une combinaison incorrecte (TCP FIN/RST ou SYN/(URG|FIN|RST).
Somme de contrôle TCP incorrecte.
Anomalies UDP :
Port source ou de destination UDP 0.
La vérification de la longueur de l’en-tête UDP a échoué.
Mauvaise somme de contrôle UDP.
Anomalies détectées lors de vérifications TCP ou UDP dynamiques :
SYN suivi de paquets SYN-ACK sans accusé de réception de l’initiateur.
SYN suivi de paquets RST.
SYN sans SYN-ACK.
Premier paquet de flux non-SYN.
Erreurs ICMP inaccessibles pour les paquets SYN.
Erreurs ICMP inaccessibles pour les paquets UDP.
Paquets abandonnés conformément aux règles de pare-feu dynamiques.
Les routeurs ACX500 ne prennent pas en charge les anomalies de fragmentation IP.
Si vous utilisez la détection des anomalies avec état conjointement avec la détection sans état, l’IDS peut fournir une alerte précoce contre un large éventail d’attaques, y compris celles-ci :
Sondes réseau TCP ou UDP et analyse des ports
Attaques par flood SYN
Attaques basées sur la fragmentation IP telles que teardrop, bonk et boink
Configuration de règles de pare-feu dynamique
Pour configurer une règle de pare-feu dynamique, incluez l’instruction rule rule-name au niveau de la [edit services stateful-firewall] hiérarchie :
[edit services stateful-firewall] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; } then { (accept <skip-ids>| discard | reject); allow-ip-options [ values ]; syslog; } } }
Les routeurs ACX500 ne prennent pas en charge les applications et les ensembles d’applications au niveau de la hiérarchie [edit services stateful-firewall rule rule-name term term-name from].
Sur les routeurs ACX500, pour activer syslog, incluez l’instruction stateful-firewall-logs CLI au niveau de la hiérarchie [edit services service-set service-set-name syslog host local class].
edit services stateful-firewall n’est pas prise en charge sur les SRX Series.
Chaque règle de pare-feu dynamique se compose d’un ensemble de termes, semblable à un filtre configuré au niveau de la [edit firewall] hiérarchie. Un terme se compose des éléments suivants :
fromstatement : spécifie les conditions de correspondance et les applications incluses et exclues. Cettefrominstruction est facultative dans les règles de pare-feu dynamiques.thenstatement : spécifie les actions et les modificateurs d’action à effectuer par le logiciel du routeur. Cettethendéclaration est obligatoire dans les règles de pare-feu dynamiques.
Les routeurs ACX500 Series ne prennent pas en charge les éléments suivants lors de la configuration de règles de pare-feu dynamiques :
match-direction(output | input-output)post-service-filterau niveau de la hiérarchie d’entrée du service d’interface.Adresse source IPv6 et adresse de destination.
application-sets,application,allow-ip-optionsau niveau de la hiérarchie [edit services stateful-firewall].Passerelles de couche applicative (ALG).
Chaînage de services au sein de la carte d’interfaces modulaires multiservices (MS-MIC) et avec des services en ligne (-si).
Classe de service.
Les commandes CLI suivantes
show services stateful-firewallne sont pas prises en charge :show services stateful-firewall conversations: afficher les conversationsshow services stateful-firewall flow-analysis: affiche les entrées de la table de fluxshow services stateful-firewall redundancy-statistics—Afficher les statistiques de redondanceshow services stateful-firewall sip-call: affiche les informations d’appel SIPshow services stateful-firewall sip-register: affiche les informations du registre SIPshow services stateful-firewall subscriber-analysis: affiche les entrées de table des abonnés
Les sections suivantes expliquent comment configurer les composants des règles de pare-feu dynamiques :
- Configuration de la direction de correspondance pour les règles de pare-feu dynamique
- Configuration des conditions de correspondance dans les règles de pare-feu dynamique
- Configuration des actions dans les règles de pare-feu dynamique
Configuration de la direction de correspondance pour les règles de pare-feu dynamique
Chaque règle doit inclure une match-direction instruction qui spécifie la direction dans laquelle la correspondance de règle est appliquée. Pour configurer l’emplacement d’application de la correspondance, incluez l’instruction match-direction au niveau de la [edit services stateful-firewall rule rule-name] hiérarchie :
[edit services stateful-firewall rule rule-name] match-direction (input | output | input-output);
Les routeurs de la série ACX500 ne prennent pas en charge match-direction (output | input-output).
Si vous configurez match-direction input-output, les sessions initiées à partir des deux directions peuvent correspondre à cette règle.
La direction d’appariement est utilisée en fonction du flux de trafic à travers l’AS ou le PIC multiservices. Lorsqu’un paquet est envoyé au PIC, des informations de direction sont transportées avec lui.
Dans un ensemble de services d’interface, la direction des paquets est déterminée par le fait qu’un paquet entre ou quitte l’interface sur laquelle il est appliqué.
Avec un ensemble de services de saut suivant, la direction du paquet est déterminée par l’interface utilisée pour acheminer le paquet vers l’AS ou le PIC multiservices. Si l’interface interne est utilisée pour acheminer le paquet, la direction du paquet est saisie. Si l’interface externe est utilisée pour diriger le paquet vers le PIC, la direction du paquet est générée. Pour plus d’informations sur les interfaces internes et externes, consultez Configuration des ensembles de services à appliquer aux interfaces de services.
Sur le PIC, une recherche de flux est effectuée. Si aucun flux n’est trouvé, le traitement des règles est effectué. Les règles de cet ensemble de services sont examinées dans l’ordre jusqu’à ce qu’une correspondance soit trouvée. Lors du traitement des règles, la direction des paquets est comparée à celle des règles. Seules les règles dont les informations de direction correspondent à la direction du paquet sont prises en compte. La plupart des paquets entraînent la création de flux bidirectionnels.
Configuration des conditions de correspondance dans les règles de pare-feu dynamique
Pour configurer les conditions de correspondance du pare-feu dynamique, incluez l’instruction from au niveau de la [edit services stateful-firewall rule rule-name term term-name] hiérarchie :
[edit services stateful-firewall rule rule-name term term-name] from { application-sets set-name; applications [ application-names ]; destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; }
Les routeurs ACX500 ne prennent pas en charge les applications et les ensembles d’applications au niveau de la hiérarchie [edit services stateful-firewall rule rule-name term term-name from].
L’adresse source et l’adresse de destination peuvent être IPv4 ou IPv6.
Vous pouvez utiliser l’adresse source ou l’adresse de destination comme condition de correspondance, de la même manière que vous configureriez un filtre de pare-feu ; pour plus d’informations, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic. Vous pouvez utiliser les valeurs any-unicastgénériques , qui indique la correspondance de toutes les adresses unicast, any-ipv4, qui indique la correspondance de toutes les adresses IPv4 ou any-ipv6, qui indique la correspondance de toutes les adresses IPv6.
Vous pouvez également spécifier une liste de préfixes source ou de destination en configurant l’instruction prefix-list au niveau de la [edit policy-options] hiérarchie, puis en incluant l’instruction ou destination-prefix-list dans la source-prefix-list règle de pare-feu dynamique. Pour obtenir un exemple, voir Exemples : configuration de règles de pare-feu dynamique.
Si vous omettez le from terme, le pare-feu dynamique accepte tout le trafic et les gestionnaires de protocole par défaut prennent effet :
Les protocoles UDP (User Datagram Protocol), TCP (Transmission Control Protocol) et ICMP (Internet Control Message Protocol) créent un flux bidirectionnel avec un flux inverse prévu.
L’IP crée un flux unidirectionnel.
Vous pouvez également inclure les définitions de protocole d’application que vous avez configurées au niveau de la hiérarchie. Pour plus d’informations, consultez Configuration des propriétés de l’application[edit applications].
Pour appliquer une ou plusieurs définitions de protocole d’application spécifiques, incluez l’instruction
applicationsau niveau de la[edit services stateful-firewall rule rule-name term term-name from]hiérarchie.Pour appliquer un ou plusieurs ensembles de définitions de protocole d’application que vous avez définis, incluez l’instruction
application-setsau niveau de la[edit services stateful-firewall rule rule-name term term-name from]hiérarchie.Remarque :Si vous incluez l’une des instructions qui spécifie les protocoles d’application, le routeur dérive les informations de port et de protocole de la configuration correspondante au niveau de la
[edit applications]hiérarchie ; vous ne pouvez pas spécifier ces propriétés en tant que conditions de correspondance.
Configuration des actions dans les règles de pare-feu dynamique
Pour configurer des actions de pare-feu dynamiques, incluez l’instruction then au niveau de la [edit services stateful-firewall rule rule-name term term-name] hiérarchie :
[edit services stateful-firewall rule rule-name term term-name] then { (accept | discard | reject); allow-ip-options [ values ]; syslog; }
Vous devez inclure l’une des actions suivantes :
accept: le paquet est accepté et envoyé à sa destination.accept skip-ids: le paquet est accepté et envoyé à sa destination, mais le traitement des règles IDS configuré sur un MS-MPC est ignoré.discard: le paquet n’est pas accepté et n’est pas traité ultérieurement.reject—Le paquet n’est pas accepté et un message de rejet est renvoyé ; UDP envoie un code ICMP inaccessible et TCP envoie RST. Les paquets rejetés peuvent être enregistrés ou échantillonnés.
Les routeurs d’intérieur ACX500 ne prennent pas en charge l’action accept skip-ids.
Vous pouvez éventuellement configurer le pare-feu pour enregistrer des informations dans la fonction de journalisation du système en incluant l’instruction syslog au niveau de la [edit services stateful-firewall rule rule-name term term-name then] hiérarchie. Cette instruction remplace tout syslog paramètre inclus dans la configuration par défaut de l’ensemble de services ou de l’interface.
Configuration de la gestion des options IP
Vous pouvez éventuellement configurer le pare-feu pour inspecter les informations d’en-tête IP en incluant l’instruction allow-ip-options au niveau de la [edit services stateful-firewall rule rule-name term term-name then] hiérarchie. Lorsque vous configurez cette instruction, tous les paquets qui correspondent aux critères spécifiés dans l’instruction from sont soumis à des critères de correspondance supplémentaires. Un paquet n’est accepté que lorsque tous ses types d’options IP sont configurés en tant que valeurs dans l’instruction allow-ip-options . Si vous ne configurez allow-ip-optionspas, seuls les paquets sans options d’en-tête IP sont acceptés.
Les routeurs d’intérieur ACX500 ne prennent pas en charge la configuration de l’instruction allow-ip-options .
L’inspection de l’option d’en-tête IP supplémentaire s’applique uniquement aux actions de accept pare-feu dynamiques et reject dynamiques. Cette configuration n’a aucun effet sur l’action discard . Lorsque l’inspection des en-têtes IP échoue, les trames de rejet ne sont pas envoyées ; Dans ce cas, l’action reject a le même effet que discard.
Si un paquet d’option IP est accepté par le pare-feu dynamique, la traduction d’adresses réseau (NAT) et le service de détection d’intrusion (IDS) sont appliqués de la même manière qu’aux paquets sans en-tête d’option IP. La configuration de l’option IP apparaît uniquement dans les règles de pare-feu dynamiques ; Le NAT s’applique aux paquets avec ou sans options IP.
Lorsqu’un paquet est abandonné parce qu’il échoue à l’inspection de l’option IP, cet événement d’exception génère à la fois des messages d’événement IDS et de journal système. Le type d’événement dépend du premier champ d’option IP rejeté.
Le Tableau 1 répertorie les valeurs possibles pour l’instruction allow-ip-options . Vous pouvez inclure une plage ou un ensemble de valeurs numériques, ou un ou plusieurs des paramètres d’option IP prédéfinis. Vous pouvez entrer le nom de l’option ou son équivalent numérique. Pour plus d’informations, reportez-vous à http://www.iana.org/assignments/ip-parameters.
Nom de l’option IP |
Valeur numérique |
Commentaire |
|---|---|---|
|
|
Toutes les options IP |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
Voir aussi
Configuration d’ensembles de règles de pare-feu dynamique
L’instruction rule-set définit un ensemble de règles de pare-feu dynamiques qui déterminent les actions que le logiciel du routeur effectue sur les paquets du flux de données. Vous définissez chaque règle en spécifiant un nom de règle et en configurant les termes. Ensuite, vous spécifiez l’ordre des règles en incluant l’instruction rule-set au niveau de la [edit services stateful-firewall] hiérarchie avec une rule instruction pour chaque règle :
[edit services stateful-firewall] rule-set rule-set-name { rule rule-name; }
Le logiciel du routeur traite les règles dans l’ordre dans lequel vous les spécifiez dans la configuration. Si un terme d’une règle correspond au paquet, le routeur exécute l’action correspondante et le traitement de la règle s’arrête. Si aucun terme d’une règle ne correspond au paquet, le traitement se poursuit jusqu’à la règle suivante de l’ensemble de règles. Si aucune des règles ne correspond au paquet, le paquet est abandonné par défaut.
Exemples : configuration de règles de pare-feu dynamique
L’exemple suivant illustre une configuration de pare-feu dynamique contenant deux règles, l’une pour la correspondance d’entrée sur un ensemble d’applications spécifié et l’autre pour la correspondance de sortie sur une adresse source spécifiée :
[edit services]
stateful-firewall {
rule Rule1 {
match-direction input;
term 1 {
from {
application-sets Applications;
}
then {
accept;
}
}
term accept {
then {
accept;
}
}
}
rule Rule2 {
match-direction output;
term Local {
from {
source-address {
10.1.3.2/32;
}
}
then {
accept;
}
}
}
}
L’exemple suivant comporte une seule règle avec deux termes. Le premier terme rejette tout le trafic provenant my-application-group de l’adresse source spécifiée et fournit un enregistrement détaillé du journal système des paquets rejetés. Le second terme accepte le trafic HTTP (Hypertext Transfer Protocol) de n’importe qui vers l’adresse de destination spécifiée.
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.1.3.2/32;
application-sets my-application-group;
}
then {
reject;
syslog;
}
}
term term2 {
from {
destination-address 10.2.3.2/32;
applications http;
}
then {
accept;
}
}
}
L’exemple suivant montre l’utilisation de listes de préfixes source et de destination. Cela nécessite deux éléments de configuration distincts.
Vous configurez la liste de préfixes au niveau de la [edit policy-options] hiérarchie :
[edit]
policy-options {
prefix-list p1 {
10.1.1.1/32;
10.2.2.0/24;
}
prefix-list p2 {
10.3.3.3/32;
10.4.4.0/24;
}
}
Vous référencez la liste de préfixes configurés dans la règle de pare-feu dynamique :
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2;
}
}
then {
accept;
}
}
}
}
}
Cela équivaut à la configuration suivante :
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-address {
10.1.1.1/32;
10.2.2.0/24;
}
destination-address {
10.3.3.3/32;
10.4.4.0/24;
}
}
then {
accept;
}
}
}
}
}
Vous pouvez utiliser le except qualificateur avec les listes de préfixes, comme dans l’exemple suivant. Dans ce cas, le qualificatif s’applique except à tous les préfixes inclus dans la liste de p2préfixes .
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2 except;
}
}
then {
accept;
}
}
}
}
}
Pour obtenir d’autres exemples de combinaison de la configuration d’un pare-feu dynamique avec d’autres services et avec des tables VRF (Virtual Private Network) de routage et de transfert, consultez les exemples de configuration.
Vous pouvez définir l’ensemble de services et l’affecter en tant que style d’interface ou style de saut suivant.
Voir aussi
Exemple : adresses BOOTP et de diffusion
L’exemple suivant prend en charge le protocole bootstrap (BOOTP) et les adresses de diffusion :
[edit applications]
application bootp {
application-protocol bootp;
protocol udp;
destination-port 67;
}
[edit services]
stateful-firewall bootp-support {
rule bootp-allow {
direction input;
term bootp-allow {
from {
destination-address {
any-unicast;
255.255.255.255;
}
application bootp;
}
then {
accept;
}
}
}
}
Exemple : Configuration des services de couche 3 et de la SDK Services sur deux PIC
Vous pouvez configurer le package de services de couche 3 et les services SDK sur deux PIC. Pour cet exemple, vous devez configurer un client FTP ou HTTP et un serveur. Dans cette configuration, le côté client de l’interface du routeur est ge-1/2/2.1 et le côté serveur de l’interface du routeur est ge-1/1/0.48. Cette configuration active la traduction d’adresses réseau (NAT) avec un pare-feu dynamique (SFW) sur le PIC uKernel, l’identification des applications (APPID), la liste d’accès sensible aux applications (AACL) et la détection et prévention d’intrusion (IDP) sur le PIC SDK services pour le trafic FTP ou HTTP.
Le SDK Services ne prend pas encore en charge NAT. Lorsque NAT est nécessaire, vous pouvez configurer le package de services de couche 3 pour déployer NAT avec les SDK de services tels que APPID, AACL ou IDP.
La fonctionnalité IDP est obsolète pour les versions 17.1R1 et ultérieures de MX Series pour Junos OS.
Déployer l’ensemble de services de couche 3 et l’SDK de services sur deux PIC :
Exemple : VRF (Virtual Routing and Forwarding) et configuration de service
L’exemple suivant combine VRF (Virtual Routing and Forwarding) et la configuration des services :
[edit policy-options]
policy-statement test-policy {
term t1 {
then reject;
}
}
[edit routing-instances]
test {
interface ge-0/2/0.0;
interface sp-1/3/0.20;
instance-type vrf;
route-distinguisher 10.58.255.1:37;
vrf-import test-policy;
vrf-export test-policy;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
[edit interfaces]
ge-0/2/0 {
unit 0 {
family inet {
service {
input service-set nat-me;
output service-set nat-me;
}
}
}
}
sp-1/3/0 {
unit 0 {
family inet;
}
unit 20 {
family inet;
service-domain inside;
}
unit 21 {
family inet;
service-domain outside;
}
[edit services]
stateful-firewall {
rule allow-any-input {
match-direction input;
term t1 {
then accept;
}
}
}
nat {
pool hide-pool {
address 10.58.16.100;
port automatic;
}
rule hide-all-input {
match-direction input;
term t1 {
then {
translated {
source-pool hide-pool;
translation-type source napt-44;
}
}
}
}
}
service-set nat-me {
stateful-firewall-rules allow-any-input;
nat-rules hide-all-input;
interface-service {
service-interface sp-1/3/0.20;
}
}
}
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
accept skip-ids: le paquet est accepté et envoyé à sa destination, mais le traitement des règles IDS configuré sur un MS-MPC est ignoré.