Exécution des tâches avancées du pare-feu virtuel vSRX dans IBM Cloud
Travailler avec les pare-feu
Le pare-feu virtuel vSRX d’IBM Cloud™ Juniper utilise le concept de zones de sécurité, où chaque interface de pare-feu virtuel vSRX est mappée à une « zone » pour gérer les pare-feu à états. Les pare-feu sans état sont contrôlés par des filtres de pare-feu.
Les stratégies permettent d’autoriser et de bloquer le trafic entre ces zones définies, et les règles définies ici sont dynamiques.
Dans IBM Cloud, un pare-feu virtuel vSRX est conçu pour avoir quatre zones de sécurité différentes :
| Zone |
Interface autonome |
HA Interface |
|---|---|---|
| SL-Privé (non marqué) |
ge-0/0/0.0 ou ae0.0 |
reth0.0 |
| SL-Public (non marqué) |
ge-0/0/1.0 ou ae1.0 |
reth1.1 |
| Client-Privé (marqué) |
ge-0/0/0.1 ou ae0.1 |
reth2.1 |
| Client-Public (tagué) |
ge-0/0/1.1 ou ae1.1 |
reth3.1 |
Stratégies de zone
Voici quelques-uns des attributs qui peuvent être définis dans vos stratégies :
-
Adresses source
-
Adresses de destination
-
Applications
-
Action (autoriser/refuser/compter/consigner)
Comme il s’agit d’une opération à états, il n’est pas nécessaire d’autoriser les paquets de retour (dans ce cas, l’écho répond).
Pour configurer un pare-feu à états, procédez comme suit :
-
Créez des zones de sécurité et attribuez les interfaces respectives :
Scénario autonome :
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.1set security zones security-zone CUSTOMER-PUBLIC interfaces ge-0/0/1.1Scénario haute disponibilité :
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.1set security zones security-zone CUSTOMER-PUBLIC interfaces reth2.1 -
Définissez la stratégie et les règles entre deux zones différentes.
L’exemple suivant illustre le trafic ping de la zone Client-Privé vers Client-Public :
set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policyset security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy -
Utilisez les commandes suivantes pour autoriser le trafic qui est dirigé vers le pare-feu virtuel vSRX :
-
Scénario autonome :
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.0 host-inbound-traffic system-services all -
Scénario haute disponibilité :
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.0 host-inbound-traffic system-services all
-
-
Pour autoriser des protocoles tels que OSPF ou BGP, utilisez la commande suivante :
-
Scénario autonome :
set security zones security-zone trust interfaces ge-0/0/0.0 host-inbound-traffic protocols all -
Scénario haute disponibilité :
set security zones security-zone trust interfaces reth2.0 host-inbound-traffic protocols all
-
Filtres de pare-feu
Par défaut, le pare-feu virtuel Juniper vSRX d’IBM Cloud™ permet d’utiliser ping, SSH et HTTPS et abandonne tout le trafic en appliquant le filtre PROTECT-IN à l’interface lo.
Pour configurer un nouveau pare-feu sans état, procédez comme suit :
-
Créez le terme et le filtre de pare-feu (le filtre suivant n’autorise qu’ICMP et abandonne tout le trafic)
set firewall filter ALLOW-PING term ICMP from protocol icmpset firewall filter ALLOW-PING term ICMP then accept -
Appliquez la règle de filtre à l’interface (la commande suivante applique le filtre à tout le trafic réseau privé)
set interfaces ge-0/0/0 unit 0 family inet filter input ALLOW-PING
Travailler avec sNAT
Vous pouvez référer un exemple de configuration pour sNAT sur une appliance de pare-feu virtuel vSRX, où un nœud privé routé derrière la passerelle peut communiquer avec le monde extérieur à l’aide de sNAT
Pour configurer LE NAT pour le pare-feu virtuel Ibm Cloud™ Juniper vSRX, consultez le Guide de l’utilisateur de la traduction des adresses réseau sur le site Web de Juniper.
Travailler avec basculement
Vous pouvez lancer un basculement de votre pare-feu virtuel Juniper vSRX principal d’IBM Cloud™ vers un équipement de secours, afin que tout le trafic du plan de contrôle et de données soit acheminé par l’équipement de passerelle secondaire après le basculement.
Cette section s’applique uniquement si vos équipements de passerelle de pare-feu virtuel Juniper vSRX sont provisionnés en mode haute disponibilité.
Effectuez la procédure suivante :
-
Connectez-vous à votre équipement principal de passerelle de pare-feu virtuel vSRX.
-
Accédez au mode CLI en exécutant la cli de commande à l’invite de la console. Lorsque vous passez en mode CLI, la console affiche le rôle de nœud, principal ou secondaire.
-
Sur l’équipement principal de passerelle de pare-feu virtuel vSRX, exécutez la commande :
show chassis cluster statusMonitor Failure codes: CS Cold Sync monitoring FL Fabric Connection monitoring GR GRES monitoring HW Hardware monitoring IF Interface monitoring IP IP monitoring LB Loopback monitoring MB Mbuf monitoring NH Nexthop monitoring NP NPC monitoring SP SPU monitoring SM Schedule monitoring CF Config Sync monitoring Cluster ID: 2 Node Priority Status Preempt Manual Monitor-failures Redundancy group: 0 , Failover count: 1 node0 100 primary no no None node1 1 secondary no no None Redundancy group: 1 , Failover count: 1 node0 100 primary yes no None node1 1 secondary yes no None {primary:node0}Assurez-vous que, pour les deux groupes de redondance, le même nœud est défini comme principal. Il est possible de définir différents nœuds comme rôle principal dans différents groupes de redondance.
Note:Par défaut, le pare-feu virtuel vSRX définit Preempt sur oui pour le groupe de redondance 1 et non pour le groupe de redondance 0. Reportez-vous à ce lien pour en savoir plus sur les comportements de préemption et de basculement.
-
Pour lancer le basculement, exécutez la commande suivante dans l’invite de la console :
request chassis cluster failover redundancy-group <redundancy group number> node <node number>Sélectionnez le numéro de groupe de redondance et le numéro de nœud appropriés dans la sortie de la commande à l’étape 2. Pour faire basculer les deux groupes de redondance, exécutez la commande précédente deux fois, une pour chaque groupe.
-
Une fois le basculement terminé, vérifiez la sortie de la console. Il devrait maintenant être répertorié comme secondaire.
-
Connectez-vous à l’autre passerelle de pare-feu virtuel vSRX de votre paire. Entrez en mode CLI en exécutant à nouveau la cli de commande, puis vérifiez que la sortie de la console apparaît comme principale.
Pointe:Lorsque vous entrez en mode CLI dans votre équipement de passerelle de pare-feu virtuel Juniper vSRX, le résultat s’affiche comme principal du point de vue du plan de contrôle. Vérifiez toujours l’état du cluster show chassis pour déterminer quel équipement de passerelle est principal du point de vue du plan de données. Reportez-vous à la section Configuration par défaut du pare-feu virtuel vSRX pour en savoir plus sur les groupes de redondance, ainsi que sur les plans de contrôle et de données.
Travailler avec le routage
Le pare-feu virtuel Juniper vSRX d’IBM Cloud™ est basé sur JunOS, ce qui vous donne accès à l’ensemble de la pile de routage Juniper.
-
Static routing— Pour configurer des routes statiques, exécutez les commandes suivantes :
Définition d’un routage par défaut :
set routing-options static route 0/0 next-hop <Gateway IP> -
Creating a static route: exécutez le
set routing-options static route <PREFIX/MASK> next-hop <Gateway IP> -
Basic OSPF routing: pour configurer le routage OSPF de base, uniquement en zone 0, exécutez les commandes suivantes à l’aide de l’authentification md5 à l’aide de la
set protocols ospf area 0 interface ge-0/0/1.0 authentication md5 0 key <key>commande. -
Basic BGP routing
-
Pour configurer le routage BGP de base, commencez par définir l’AS local en exécutant la
set routing-options autonomous-system 65001commande. -
Configurez ensuite le voisin BGP et ses attributs de session :
set protocols bgp group CUSTOMER local-address 10.1.1.1set protocols bgp group CUSTOMER family inet unicastset protocols bgp group CUSTOMER family inet6 unicastset protocols bgp group CUSTOMER peer-as 65002set protocols bgp group CUSTOMER neighbor 2.2.2.2Dans cet exemple, BGP est configuré pour les éléments suivants :
-
Pour utiliser l’adresse IP source 10.1.1.1 pour établir la session
-
Pour négocier les familles unicast ipv4 et ipv6
-
Pour appairer un voisin qui appartient à l’AS 65002
-
Voisin pair IP 10.2.2.2
-
-
Pour plus de configurations, consultez la documentation Junos OS
Utiliser un VPN
Cette rubrique détaille un exemple de configuration d’un VPN basé sur le routage entre deux sites. Dans cet exemple de configuration, le serveur 1 (site A) peut communiquer avec le serveur 2 (site B), et chaque site utilise une authentification IPSEC en deux phases. Pour plus d’informations, voir Utiliser un VPN et
- Exemple de configuration pour le site A (Dallas) :
- Exemple de configuration pour le site B (Londres) :
- Considérations de performances
Exemple de configuration pour le site A (Dallas) :
# show security address-book global address Network-A
10.84.237.200/29;
[edit]
# show security address-book global address Network-B
10.45.53.48/29;
# show security ike
proposal IKE-PROP {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$ewkMLNs2aikPdbkP5Q9CKM8"; ## SECRET-DATA
}
gateway IKE-GW {
ike-policy IKE-POL;
address 10.158.100.100;
external-interface ge-0/0/1.0;
}
#show security ipsec
proposal IPSEC-PROP {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IPSEC-POL {
perfect-forward-secrecy {
keys group5;
}
proposals IPSEC-PROP;
}
vpn IPSEC-VPN {
bind-interface st0.1;
vpn-monitor;
ike {
gateway IKE-GW;
ipsec-policy IPSEC-POL;
}
establish-tunnels immediately;
}
#show interfaces
ge-0/0/0 {
description PRIVATE_VLANs;
flexible-vlan-tagging;
native-vlan-id 1121;
unit 0 {
vlan-id 1121;
family inet {
address 10.184.108.158/26;
}
}
unit 10 {
vlan-id 1811;
family inet {
address 10.184.237.201/29;
}
}
unit 20 {
vlan-id 1812;
family inet {
address 10.185.48.9/29;
}
}
}
st0 {
unit 1 {
family inet {
address 10.169.200.0/31;
}
}
#show security policies
from-zone CUSTOMER-PRIVATE to-zone VPN {
policy Custprivate-to-VPN {
match {
source-address any;
destination-address Network-B;
application any;
}
then {
permit;
}
}
}
from-zone VPN to-zone CUSTOMER-PRIVATE {
policy VPN-to-Custprivate {
match {
source-address Network-B;
destination-address any;
application any;
}
then {
permit;
}
}
Exemple de configuration pour le site B (Londres) :
# show interfaces
ge-0/0/0 {
description PRIVATE_VLANs;
flexible-vlan-tagging;
native-vlan-id 822;
unit 0 {
vlan-id 822;
family inet {
address 10.45.165.140/26;
}
}
unit 10 {
vlan-id 821;
family inet {
address 10.45.53.49/29;
}
}
}
st0 {
unit 1 {
family inet {
address 10.169.200.1/31;
}
}
#show security ike
proposal IKE-PROP {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$H.fz9A0hSe36SevW-dk.P"; ## SECRET-DATA
}
gateway IKE-GW {
ike-policy IKE-POL;
address 10.169.100.100;
external-interface ge-0/0/1.0;
}
# show security ipsec
proposal IPSEC-PROP {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IPSEC-POL {
perfect-forward-secrecy {
keys group5;
}
proposals IPSEC-PROP;
}
vpn IPSEC-VPN {
bind-interface st0.1;
vpn-monitor;
ike {
gateway IKE-GW;
ipsec-policy IPSEC-POL;
}
establish-tunnels immediately;
}
#show security zone security-zone CUSTOMER_PRIVATE
security-zone CUSTOMER-PRIVATE {
interfaces {
ge-0/0/0.10 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
security-zone VPN {
interfaces {
st0.1;
}
}
#show security policies from-zone CUSTOMER-PRIVATE to-zone VPN
policy Custprivate-to-VPN {
match {
source-address any;
destination-address Network-A;
application any;
}
then {
permit;
}
}
#show security zones security-zone VPN
interfaces {
st0.1;
}
#show security policies from-zone VPN to-zone CUSTOMER-PRIVATE
policy VPN-to-Custprivate {
match {
source-address Network-A;
destination-address any;
application any;
}
then {
permit;
}
}
Considérations de performances
Afin d’obtenir les meilleures performances VPN IPsec, utilisez AES-GCM comme algorithme de chiffrement pour les propositions IKE et IPSEC.
Par exemple :
set security ike proposal IKE-PROP encryption-algorithm aes-128-gcm
set security ipsec proposal IPSEC-PROP encryption-algorithm aes-128-gcm
Avec AES-GCM comme algorithme de chiffrement, vous n’avez pas besoin de spécifier l’algorithme d’authentification dans la même proposition. AES-GCM assure à la fois le chiffrement et l’authentification.
Pour plus d’informations sur les configurations VPN, consultez le Guide de l’utilisateur VPN IPsec pour les équipements de sécurité et Exemple : Configuration d’un VPN basé sur les routes
Sécurisation du système d’exploitation hôte
Le pare-feu virtuel vSRX d’IBM Cloud™ Juniper s’exécute comme une machine virtuelle sur un serveur bare metal installé avec Ubuntu et KVM. Pour sécuriser le système d’exploitation hôte, vous devez vous assurer qu’aucun autre service critique n’est hébergé sur le même système d’exploitation.
Accès SSH
Le pare-feu virtuel Juniper vSRX d’IBM Cloud™ peut être déployé avec un accès réseau public et privé ou un accès réseau privé uniquement. Par défaut, l’accès SSH basé sur un mot de passe à l’ADRESSE IP publique du système d’exploitation de l’hôte sera désactivé sur les nouvelles dispositions et les recharges du système d’exploitation. L’accès à l’hôte peut être obtenu via l’adresse IP privée. Vous pouvez également utiliser l’authentification basée sur des clés pour accéder à l’ADRESSE IP publique. Pour ce faire, spécifiez la clé SSH publique lorsque vous placez un nouvel ordre de passerelle.
Certains déploiements existants du pare-feu virtuel IBM Cloud™ Juniper vSRX peuvent autoriser un accès SSH basé sur un mot de passe à l’ADRESSE IP publique du système d’exploitation hôte. Pour ces déploiements, vous pouvez désactiver manuellement l’accès SSH basé sur un mot de passe à l’ADRESSE IP publique du système d’exploitation en suivant les étapes suivantes :
-
Modifier /etc/ssh/sshd_config
-
Assurez-vous que les valeurs suivantes sont définies.
ChallengeResponseAuthentication no PasswordAuthentication no
-
Ajoutez les règles de filtre suivantes à la fin du fichier.
Match Address 10.0.0.0/8 Password Authentication yes
-
-
Redémarrez le service SSH à l’aide de la commande /usr/sbin/service ssh restart.
La procédure ci-dessus garantit que les adresses du sous-réseau d’infrastructure privée 10.0.0.0/8 sont autorisées à accéder à SSH. Cet accès est nécessaire pour des actions telles que : les recharges du système d’exploitation, la reconstruction de cluster, les mises à niveau de versions.
Pare-feu
L’implémentation d’un pare-feu Ubuntu (UFW, Iptables, etc.) sans règles requises peut désactiver le cluster HA du pare-feu virtuel vSRX. La solution de pare-feu virtuel vSRX dépend de la communication pulsation entre les nœuds principaux et secondaires. Si les règles de pare-feu n’autorisent pas la communication entre les nœuds, alors la communication en cluster sera perdue.
L’architecture du pare-feu virtuel vSRX influence les règles de pare-feu décrites ci-dessous. Vous trouverez des détails sur les deux architectures dans la configuration par défaut du vSRX.
Pour les déploiements de pare-feu virtuel vSRX version 18.4 HA s’exécutant avec l’architecture héritée, les règles suivantes sont requises pour permettre la communication en cluster pour l’UFW :
-
Pour autoriser le protocole 47 (utilisé pour la communication de battements de cœur) dans /etc/ufw/before.rules :
-A ufw-before-input -p 47 -j ACCEPT
-
Pour permettre les communications réseau privées :
ufw allow in from 10.0.0.0/8 to 10.0.0.0/8
-
Pour activer l’UFW :
ufw enable
Pour les versions de pare-feu virtuel vSRX s’exécutant avec la nouvelle architecture, les règles de pare-feu doivent permettre la communication multicast.
Dans certains cas, les opérations de dépannage peuvent nécessiter la désactivation du pare-feu pour accéder aux dépôts publics. Dans ces cas, vous devriez travailler avec l’assistance IBM pour comprendre comment procéder.
La plupart des actions de passerelle nécessitent un accès SSH au sous-réseau privé 10.0.0.0/8 pour le système d’exploitation hôte et le pare-feu virtuel vSRX. Le blocage de cet accès à l’aide d’un pare-feu peut entraîner l’échec des actions suivantes : rechargement du système d’exploitation, reconstruction des clusters et mises à niveau des versions
Par conséquent, si l’accès SSH est désactivé pour le sous-réseau 10.0.0.0/8, vous devez le réactiver avant d’exécuter l’une de ces actions.
Configuration des interfaces de gestion
Les nœuds du pare-feu virtuel Juniper vSRX d’IBM Cloud™ fournissent des interfaces de gestion intégrées (« fxp0 ») qui ne sont pas configurées par défaut. Une fois configurées, ces interfaces privées peuvent être utilisées pour communiquer avec le nœud individuel, ce qui peut être utile dans un cluster à haute disponibilité pour surveiller l’état du nœud secondaire sur SSH, ping, SNMP, etc. L’ADRESSE IP privée du pare-feu virtuel vSRX étant flottante vers le nœud principal, il n’est pas possible d’accéder directement au nœud secondaire.
La configuration de l’interface fxp0 nécessite des adresses IP dans un sous-réseau rattaché au VLAN de transit privé de la passerelle. Bien que le sous-réseau principal fourni avec la passerelle dispose d’adresses IP qui peuvent être disponibles, il n’est pas recommandé pour cette utilisation. En effet, le sous-réseau principal est réservé à l’infrastructure de provisionnement de passerelle, et des collisions IP peuvent se produire si d’autres passerelles sont déployées dans le même pod.
Vous pouvez allouer un sous-réseau secondaire pour le VLAN de transit privé et utiliser des adresses IP de ce sous-réseau pour configurer fxp0 et l’interface de pont hôte pour l’accès PING et SSH. Pour ce faire, effectuez la procédure suivante :