Gestion des pare-feux

IBM Cloud® Virtual Router Appliance (VRA) a la capacité de traiter des règles de pare-feu pour protéger les réseaux locaux virtuels (VLAN) routés via l'unité.

Les pare-feux sur le dispositif VRA peuvent être divisés en deux étapes :

Définition d'un ou de plusieurs jeux de règles.
Application d'un ensemble de règles à une interface ou à une politique de zone. Une zone consiste en une ou plusieurs interfaces réseau. Une règle de zone est définie pour le trafic traversant d'une zone à une autre.

Il est important de tester les règles de pare-feu après leur création pour s'assurer qu'elles fonctionnent comme prévu et que les nouvelles règles n'empêchent pas l'accès des administrateurs à l'unité.

Lors de la manipulation des règles sur l'interface dp0bond1, il est conseillé de se connecter à l'unité à l'aide de dp0bond0. La connexion à la console à l'aide de l'interface IMPI (Intelligent Platform Management Interface) est également possible.

Sans état et avec état

Par défaut, le pare-feu est configuré sans état, mais il peut être configuré avec état si nécessaire. Un pare-feu sans état nécessitera des règles pour le trafic bidirectionnel, alors que les pare-feux avec état contrôlent les connexions et autorisent automatiquement le trafic en retour des flux acceptés. Pour configurer un pare-feu avec état, vous devez indiquer les règles qui doivent fonctionner avec état.

Pour activer un suivi 'avec état' du trafic tcp, udp ou icmp, exécutez les commandes suivantes :

set security firewall global-state-policy icmp
set security firewall global-state-policy tcp
set security firewall global-state-policy udp

Notez que les commandes global-state-policy suivront uniquement l'état du trafic ayant été mis en correspondance avec une règle de pare-feu qui définit explicitement le protocole correspondant. Exemple :

set security firewall name GLOBAL_STATELESS rule 1 action accept

Dans la mesure où GLOBAL_STATELESS ne spécifie pas protocol tcp, la commande global-state-policy tcp ne s'applique pas à cette règle.

set security firewall name GLOBAL_STATEFUL_TCP rule 1 action accept
set security firewall name GLOBAL_STATEFUL_TCP rule 1 protocol tcp

Dans ce cas, protocol tcp est défini explicitement. La commande global-state-policy tcp active le suivi avec état du trafic correspondant à la règle 1 de GLOBAL_STATEFUL_TCP

Pour que les règles de pare-feu individuelles soient "avec état" :

set security firewall name TEST rule 1 allow
set security firewall name TEST rule 1 state enable

Cela permet d'activer le suivi avec état de tout le trafic qui peut être suivi avec état et qui correspond à la règle 1 de TEST, que les commandes global-state-policy existent ou non.

ALG pour le suivi avec état assisté

Une poignée de protocoles, tels que FTP, utilisent des sessions plus complexes que celles qui peuvent être suivies par l'opération de pare-feu avec état normale. Il existe des modules préconfigurés qui permettent d'effectuer des opérations de gestion avec état de ces protocoles.

Il est recommandé de désactiver ces modules ALG, sauf s'ils sont requis pour l'utilisation réussie des protocoles respectifs.

set system alg ftp 'disable'
set system alg icmp 'disable'
set system alg pptp 'disable'
set system alg rpc 'disable'
set system alg rsh 'disable'
set system alg sip 'disable'
set system alg tftp 'disable'

Jeux de règles de pare-feu

Les règles de pare-feu sont regroupées dans des ensembles nommés pour faciliter leur application à plusieurs interfaces. Chaque jeu de règles comporte une action par défaut qui lui est associée. Prenons l'exemple suivant :

set security firewall name ALLOW_LEGACY default-action accept
set security firewall name ALLOW_LEGACY rule 1 action drop
set security firewall name ALLOW_LEGACY rule 1 source address network-group1
set security firewall name ALLOW_LEGACY rule 2 action drop
set security firewall name ALLOW_LEGACY rule 2 destination port 23
set security firewall name ALLOW_LEGACY rule 2 log
set security firewall name ALLOW_LEGACY rule 2 protocol tcp
set security firewall name ALLOW_LEGACY rule 2 source address network-group2

Dans l'ensemble de règles ALLOW_LEGACY, deux règles sont définies. La première règle supprime le trafic en provenance d'un groupe d'adresses nommé network-group1. Le second écarte et enregistre tout trafic destiné au port telnet (tcp/23) à partir du groupe d'adresses nommé network-group2. L'action par défaut indique que toute autre action est acceptée. Une bonne pratique consiste à autoriser uniquement le trafic nécessaire, puis à bloquer le reste à l'aide de l'action par défaut de l'ensemble de règles.

Autorisation d'accès au centre de données

IBM Cloud héberge de nombreux sous-réseaux (réseaux de services privés) qui fournissent des services et un support aux serveurs client s'exécutant dans ses centres de données. Par exemple, les services de résolution DNS s'exécutent sous 10.0.80.11 et 10.0.80.12, et le serveur NTP par défaut s'exécute sous 10.0.77.54. Ces trois éléments se trouvent dans le réseau de service 10.0.64.0/29. D'autres sous-réseaux sont utilisés lors de la mise à disposition et du support. Vous trouverez les réseaux de services privés utilisés dans les centres de données dans cette rubrique.

Vous pouvez autoriser l'accès au centre de données en mettant les règles SERVICE-ALLOW adéquates au début des jeux de règles de pare-feu avec l'action accept. L'emplacement d'application du jeu de règles dépend de la conception de routage et de pare-feu implémentée.

Il est recommandé de placer les règles de pare-feu à l'emplacement qui entraînera le moins de double-emploi. Par exemple, autoriser les réseaux de back-end entrants sur dp0bond0 est moins contraignant qu'autoriser des sous-réseaux de back-end sortants vers chaque interface virtuelle de VLAN.

Configuration de pare-feu par interface

Une méthode de configuration de pare-feu sur un dispositif VRA consiste à appliquer des jeux de règles de pare-feu à chaque interface. Dans ce cas, une interface peut être une interface de réseau local virtuel interne (VIF) (par exemple, dp0bond0.1303), l'une des interfaces externes (dp0bond0 (privé) ou dp0bond1 (public)) ou des interfaces de tunnel (par exemple, tun0 ou vti0). Chaque interface comporte trois possibilités d'affectation de pare-feu :

in- Le pare-feu filtre les paquets entrant dans l'interface. Ces paquets peuvent transiter par l'ARV ou lui être destinés.

out- Le pare-feu filtre les paquets qui quittent l'interface. Ces paquets peuvent transiter par l'ARV ou lui être destinés.

local- Le pare-feu est contrôlé par rapport aux paquets destinés à l'ARV. L'interface de bouclage, lo, peut être utilisée pour filtrer le trafic entrant local sur n'importe quelle interface. Les filtres de pare-feu et les ensembles de règles appliqués à local sont traités après tous les ensembles de règles de pare-feu appliqués en tant que in à n'importe quelle interface.

Une interface peut avoir plusieurs jeux de règles appliqués dans chaque direction. Ils sont appliqués dans l'ordre où ils ont été configurés. Notez qu'il n'est pas possible de créer un pare-feu pour le trafic en provenance du dispositif VRA en utilisant des pare-feux par interface.

Par exemple, pour affecter l'ensemble de règles ALLOW_LEGACY à l'option in pour l'interface dp0bond1, vous devez utiliser la commande de configuration :

set interfaces bonding dp0bond1 firewall in ALLOW_LEGACY

Control Plane Policing (CPP)

Control Plane Policing (CPP) fournit une protection contre les attaques sur le dispositif IBM Cloud® Virtual Router Appliance en vous autorisant à configurer des règles d'administration de pare-feu affectées aux interfaces désirées et en appliquant ces règles aux paquets entrant sur le dispositif VRA.

CPP est implémenté lorsque le mot-clé local est utilisé dans les règles d'administration de pare-feu affectées à n'importe quel type d'interface VRA, que ce soit des interfaces de plan de données ou de bouclage. Contrairement aux règles de pare-feu appliquées aux paquets qui transitent via le dispositif VRA, l'action par défaut des règles de pare-feu pour le trafic entrant ou sortant du plan de contrôle est Allow. Les utilisateurs doivent ajouter des règles de suppression explicites si le comportement par défaut n'est pas souhaité.

Le dispositif VRA fournit une règle CPP de base comme modèle. Vous pouvez la fusionner dans votre configuration en exécutant la commande suivante :

vyatta@vrouter# merge /opt/vyatta/etc/cpp.conf

Une fois ce jeu de règles fusionné, un nouveau jeu de règles de pare-feu nommé CPP est ajouté et appliqué à l'interface de bouclage. Il est recommandé de modifier ce jeu de règles pour l'adapter à votre environnement.

Notez que les règles CPP ne peuvent pas être avec état et s’appliqueront uniquement au trafic entrant.

Configuration de pare-feu basée sur les zones

Dans les configurations de pare-feu basées sur des zones, une ou plusieurs interfaces sont affectées à une zone (bien qu'une interface ne puisse pas être affectée à plusieurs zones) et les jeux de règles de pare-feu sont appliqués d'une zone à une autre. Pour une stratégie de zone unique, le trafic est filtré lorsqu'il passe de la première zone à la seconde, et le filtrage n'est effectué que sur l'interface sortante / sortante. Les zones suppriment tout trafic entrant dans leur périmètre qui n'est pas explicitement autorisé.

Une interface peut soit appartenir à une zone, soit avoir une configuration de pare-feu par interface; elle ne peut pas faire les deux.

Considérons le scénario de bureau suivant avec trois départements, chaque département ayant son propre VLAN :

Département A - VLANs 10 et 20 (interfaces dp0bond1.10 et dp0bond1.20)
Département B - VLANs 30 et 40 (interfaces dp0bond1.30 et dp0bond1.40)
Département C - VLAN 50 (interface dp0bond1.50)

Une zone peut être créée pour chaque service et les interfaces de ces services peuvent être ajoutées à la zone. L'exemple suivant illustre ce cas :

set security zone-policy zone DEPARTMENTA interface dp0bond1.10
set security zone-policy zone DEPARTMENTA interface dp0bond1.20
set security zone-policy zone DEPARTMENTB interface dp0bond1.30
set security zone-policy zone DEPARTMENTB interface dp0bond1.40
set security zone-policy zone DEPARTMENTC interface dp0bond1.50

La commande commit remplit chaque zone en tant qu'interface et les règles de suppression par défaut suppriment tout trafic provenant de l'extérieur d'entrer dans la zone. Dans cet exemple, les VLAN 10 et 20 peuvent autoriser leur trafic car ils sont dans la même zone (DEPARTMENTA) mais le VLAN 10 et le VLAN 30 ne le peuvent pas car le VLAN 30 se trouve dans une autre zone (DEPARTMENTB).

Les interfaces au sein de chaque zone peuvent autoriser le trafic librement et des règles peuvent être définies pour les interactions entre les zones. Un jeu de règles est configuré pour sortir d'une zone et entrer dans une autre.

La commande suivante montre un exemple de configuration de règle :

set security zone-policy zone DEPARTMENTC to DEPARTMENTB firewall ALLOW_PING

Cette commande associe la transition de DEPARTMENTC à DEPARTMENTB à l'ensemble de règles nommé ALLOW_PING. Le trafic entrant dans la zone DEPARTMENTB à partir de la zone DEPARTMENTC serait contrôlé par rapport à cet ensemble de règles.

Il est important de comprendre que cette affectation de la zone DEPARTMENTC vers la zone DEPARTMENTB ne fait aucune déclaration sur l'inverse. Si aucune règle n'autorise le trafic de la zone DEPARTMENTB vers la zone DEPARTMENTC, le trafic (réponses ICMP) ne reviendra pas vers les hôtes de DEPARTMENTC.

ALLOW_PING serait appliqué en tant que pare-feu out sur les interfaces de la zone DEPARTMENTB (dp0bond1.30 et dp0bond1.40). Comme il est installé par la politique de zone, seul le trafic provenant des interfaces de la zone source (dp0bond1.50) sera vérifié par rapport à l'ensemble de règles.

Exemple de pare-feu basé sur des zones

L'exemple suivant détaille un environnement de pare-feu qui surveille et débogue tout le trafic sortant et entrant un dispositif VRA.

L'ajout de "log" à la règle 1 aura un impact grave sur les performances et ne doit être utilisé qu'à des fins de débogage.

Ne laissez jamais vos interfaces publiques ouvertes, comme dans cet exemple.

set security zone-policy zone Public-and-VTI interface dp0bond1
set security zone-policy zone Public-and-VTI interface vti2
set security zone-policy zone Public-Inside interface dp0bond1.807
set security zone-policy zone Private-Outside interface dp0bond0
set security zone-policy zone Private-Inside interface dp0bond0.829

#ruleset to allow all statefully and log every packet
set security firewall name AllowAllLogALL rule 1 action accept
set security firewall name AllowAllLogALL rule 1 log
set security firewall name AllowAllLogALL rule 1 state enable

#security policy pair between public/IPSec and private network servers
set security zone-policy zone Public-and-VTI to Private-Inside firewall AllowAllLogALL
set security zone-policy zone Private-Inside to Public-and-VTI firewall AllowAllLogALL

#security policy pair between public/IPSec and public network servers
set security zone-policy zone Public-and-VTI to Public-Inside firewall AllowAllLogALL
set security zone-policy zone Public-Inside to Public-and-VTI firewall AllowAllLogALL

#security policy pair between service networks/private outside and private network customer servers
set security zone-policy zone Private-Outside to Private-Inside firewall AllowAllLogALL
set security zone-policy zone Private-Inside to Private-Outside firewall AllowAllLogALL

Traitement des incidents liés aux règles de

Vous pouvez identifier et résoudre les problèmes liés aux configurations de pare-feu interace et de zone.

Traitement des incidents liés aux configurations de pare-feu basées sur l'interface

Pour commencer la vérification et le traitement des incidents, exécutez les commandes suivantes pour comprendre comment les règles sont configurées:

Pour collecter les ensembles de règles de pare-feu qui sont appliqués à chaque interface et dans quelle direction, exécutez show configuration commands | grep firewall | grep interface.
A l'aide de la sortie de l'étape 1, vous pouvez trouver toutes les règles appliquées aux interfaces dans le flux que vous essayez de vérifier en exécutant show configuration commands | grep -iE '<name of firewall ruleset>'.
Examinez les règles pour vous assurer que les sous-réseaux, les ports et les protocoles appropriés sont autorisés:
- Si vous traitez les incidents liés à la connectivité entre le réseau de service et le serveur privé et que l'ensemble de règles est appliqué in aux VIF (dp0bond0.XXX), vous devez définir les réseaux de service comme destinations. En effet, lorsque le trafic est acheminé vers le VIF, c'est-à-dire lorsque le serveur client envoie le trafic sortant.
- Si vous traitez les incidents liés à la connectivité du réseau de service à un serveur privé et que l'ensemble de règles est appliqué out aux VIF (dp0bond0.XXX), vous devez définir les réseaux de service comme sources. En effet, lorsque le trafic sort du VIF, il le fait vers les serveurs client.
- Si vous dépannez la connectivité entre le réseau de service et le serveur privé, et que le jeu de règles est appliqué à l'interfac in ement à l' dp0bond0, vous devez alors définir les réseaux de service comme sources. En effet, le trafic entrant dans l'interface d' dp0bond0 s est généralement destiné aux serveurs situés derrière le Vyatta.
- Si vous traitez les incidents liés à la connectivité du réseau de service à un serveur privé et que l'ensemble de règles est appliqué out à l'interface dp0bond0, vous devez définir les réseaux de service comme destinations. Cela est dû au fait que le trafic sortant de dp0bond0 est en direction des serveurs client qui se trouvent derrière Vyatta.

Traitement des incidents liés aux configurations de pare-feu basées sur les zones

Pour commencer la vérification et le traitement des incidents, exécutez les commandes suivantes pour comprendre comment les règles sont configurées:

Pour afficher les interfaces dans lesquelles se trouvent les zones, exécutez show configuration commands | grep zone | grep interface.
A l'aide de la sortie de l'étape 1, vous pouvez trouver l'ensemble de règles de pare-feu appliqué dans chaque politique de zone en exécutant show configuration commands | grep <name of zone> | grep <name of other zone>.
A l'aide de la sortie de l'étape 2, vous pouvez trouver toutes les règles appliquées aux interfaces dans le flux que vous essayez de vérifier en exécutant show configuration commands | grep -iE '<name of firewall ruleset>|<name of other firewall ruleset>'.
Examinez les règles pour vous assurer que les sous-réseaux, les ports et les protocoles appropriés sont autorisés:
- Si vous traitez les incidents liés à la connectivité du réseau de service à un serveur privé et que la règle provient des VIF (dp0bond0.XXX) vers dp0bond0, vous devez définir les réseaux de service comme destination.
- Pour les règles provenant de dp0bond0 vers les VIF (dp0bond0.XXX), vous devez définir les réseaux de service en tant que sources.

L'exemple suivant détaille les commandes que vous pouvez utiliser pour extraire les informations nécessaires pour déterminer si le pare-feu doit autoriser les réseaux de service.

vyatta@gateway02:~$ show configuration commands | grep zone | grep interface
set security zone-policy zone SL-Private-Servers interface 'dp0bond0.1750'
set security zone-policy zone SL-Private-Servers interface 'dp0bond0.1623'
set security zone-policy zone SL-Service interface 'dp0bond0'

vyatta@gateway02:~$ show configuration commands | grep SL-Private-Servers | grep SL-Service
set security zone-policy zone SL-Private-Servers to SL-Service firewall 'To-Private-Service-Network'
set security zone-policy zone SL-Service to SL-Private-Servers firewall 'To-Private-Servers'

vyatta@gateway02:~$ show configuration commands | grep -iE 'To-Private-Service-Network|To-Private-Servers'
set security firewall name To-Private-Servers rule 1 action 'accept'
set security firewall name To-Private-Servers rule 1 source address 'ServiceNetwork'
set security firewall name To-Private-Service-Network rule 1 action 'accept'
set security firewall name To-Private-Service-Network rule 1 destination address 'ServiceNetwork'
set security zone-policy zone SL-Private-Servers to SL-Service firewall 'To-Private-Service-Network'
set security zone-policy zone SL-Service to SL-Private-Servers firewall 'To-Private-Servers'

#Pull the actual subnets that I'm allowing via the defined ServiceNetwork addresses:
vyatta@gateway02:~$ show configuration commands | grep ServiceNetwork
set resources group address-group ServiceNetwork address '10.0.86.0/24'
set resources group address-group ServiceNetwork address '10.2.128.0/20'
set resources group address-group ServiceNetwork address '10.1.176.0/20'
set resources group address-group ServiceNetwork address '10.1.64.0/19'
set resources group address-group ServiceNetwork address '10.1.96.0/19'
set resources group address-group ServiceNetwork address '10.1.192.0/20'
set resources group address-group ServiceNetwork address '10.1.160.0/20'
set resources group address-group ServiceNetwork address '10.2.32.0/20'
set resources group address-group ServiceNetwork address '10.2.64.0/20'
set resources group address-group ServiceNetwork address '10.2.112.0/20'
set resources group address-group ServiceNetwork address '10.2.160.0/20'
set resources group address-group ServiceNetwork address '10.1.208.0/20'
set resources group address-group ServiceNetwork address '10.2.80.0/20'
set resources group address-group ServiceNetwork address '10.2.144.0/20'
set resources group address-group ServiceNetwork address '10.2.48.0/20'
set resources group address-group ServiceNetwork address '10.2.176.0/20'
set resources group address-group ServiceNetwork address '10.3.64.0/20'
set resources group address-group ServiceNetwork address '10.0.64.0/19'
set resources group address-group ServiceNetwork address '10.0.80.11'
set resources group address-group ServiceNetwork address '10.0.80.12'
set resources group address-group ServiceNetwork address '10.200.80.0/20'
set resources group address-group ServiceNetwork address '10.3.160.0/20'
set resources group address-group ServiceNetwork address '10.201.0.0/20'
set resources group address-group ServiceNetwork address '10.3.80.0/20'
set security firewall name To-Private-Servers rule 1 source address 'ServiceNetwork'
set security firewall name To-Private-Service-Network rule 1 destination address 'ServiceNetwork'

Journalisation de session et par paquet

Le dispositif VRA prend en charge deux types de consignation, session et par paquet.

Consignation de session

Utilisez la commande security firewall session-log pour configurer la journalisation de session de pare-feu.

Pour UDP, ICMP et tous les flux autres que TCP, une session passe par quatre états sur la durée de vie du flux. Vous pouvez configurer le dispositif VRA pour consigner un message à chaque transition. TCP a un nombre plus important de transitions d'état, chacune pouvant être configurée pour figurer dans le journal. L'exemple suivant détaille la configuration de session-log pour votre pare-feu:

set security firewall session-log icmp established
set security firewall session-log tcp established
set security firewall session-log udp established

Consignation par paquet

Pour la consignation par paquet, veillez à inclure le mot clé log dans le pare-feu ou la règle NAT. Cette opération consigne tous les paquets réseau qui correspondent à la règle.

La journalisation par paquet intervient dans les chemins de transfert de paquet et génère de grandes quantités de données en sortie. La journalisation par paquet peut réduire considérablement le débit de l'ERV, causer des problèmes de performance et augmenter considérablement l'espace disque utilisé pour les fichiers de journalisation. Il est recommandé d'utiliser la consignation par paquet uniquement à des fins de débogage. À toutes fins utiles, il convient d'utiliser plutôt la journalisation de session avec état.

Traitement des incidents liés à l'utilisation des journaux

A des fins de débogage, vous pouvez configurer le journal par défaut et la consignation par paquet. La consignation par paquet peut être ajoutée à chaque règle individuelle pour afficher dans les journaux le moment où les paquets sont supprimés ou acceptés (en fonction de l'action définie pour la règle). Le journal par défaut enregistre une suppression "implicite" lorsqu'elle se produit. Pour la configuration de pare-feu basée sur la politique de zone suivante, le paramètre default-log est consigné chaque fois que le trafic ne correspond pas à la règle 1. Il s'agit de la seule règle configurée.

set security firewall name To-Private-Servers rule 1 action drop
set security firewall name To-Private-Servers rule 1 source address ServiceNetwork
set security firewall name To-Private-Servers rule 1 log
set security firewall name To-Private-Servers default-log

Pour afficher le journal, il existe deux commandes et la sortie suivante illustre un bloc consigné de trafic spécifique:

journalctl -u vyatta-dataplane | grep <IP Address>
show log firewall name To-Private-Servers | grep <IP Address>

vyatta@gateway02# journalctl -f -u vyatta-dataplane | grep 10.3.84.106
Feb 18 05:47:09 gateway02 vyatta-dataplane.service dataplane[4313]: fw rule To-Private-Servers:10000 block icmp(1) src=//10.3.84.106 dst=dp0bond0.1750//10.126.19.174 len=84 ttl=55 type=8 code=0
Feb 18 05:47:10 gateway02 vyatta-dataplane.service dataplane[4313]: fw rule To-Private-Servers:10000 block icmp(1) src=//10.3.84.106 dst=dp0bond0.1750//10.126.19.174 len=84 ttl=55 type=8 code=0
^C
[edit]