Realización de tareas avanzadas del firewall virtual vSRX en la nube de IBM
Trabajar con firewalls
El firewall virtual vSRX de IBM Cloud™ Juniper utiliza el concepto de zonas de seguridad, donde cada interfaz del firewall virtual vSRX se asigna a una "zona" para el manejo de firewalls de estado. Los firewalls sin estado se controlan mediante filtros de firewall.
Las políticas se utilizan para permitir y bloquear el tráfico entre estas zonas definidas, y las reglas definidas aquí tienen estado.
En la nube de IBM, un firewall virtual vSRX está diseñado para tener cuatro zonas de seguridad diferentes:
Zona |
Interfaz independiente |
Interfaz de AD |
---|---|---|
SL-Privado (sin etiquetar) |
ge-0/0/0.0 o ae0.0 |
reth0.0 |
SL-Public (sin etiquetar) |
ge-0/0/1.0 o ae1.0 |
reth1.1 |
Privado del cliente (etiquetado) |
ge-0/0/0.1 o ae0.1 |
reth2.1 |
Público del cliente (etiquetado) |
ge-0/0/1.1 o ae1.1 |
reth3.1 |
Políticas de zona
A continuación, se presentan algunos de los atributos que se pueden definir en sus políticas:
-
Direcciones de origen
-
Direcciones de destino
-
Aplicaciones
-
Acción (permitir/negar/rechazar/contar/registrar)
Dado que se trata de una operación con estado, no es necesario permitir la devolución de paquetes (en este caso, el eco responde).
Para configurar un firewall con estado, siga estos pasos:
-
Cree zonas de seguridad y asigne las interfaces respectivas:
Escenario independiente:
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.1
set security zones security-zone CUSTOMER-PUBLIC interfaces ge-0/0/1.1
Escenario de alta disponibilidad:
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.1
set security zones security-zone CUSTOMER-PUBLIC interfaces reth2.1
-
Defina la política y las reglas entre dos zonas diferentes.
En el siguiente ejemplo, se muestra el tráfico de ping desde la zona Customer-Private a Customer-Public:
set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy
set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy
-
Utilice los siguientes comandos para permitir el tráfico que se dirige al firewall virtual vSRX:
-
Escenario independiente:
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.0 host-inbound-traffic system-services all
-
Escenario de alta disponibilidad:
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.0 host-inbound-traffic system-services all
-
-
Para permitir protocolos, como OSPF o BGP, utilice el siguiente comando:
-
Escenario independiente:
set security zones security-zone trust interfaces ge-0/0/0.0 host-inbound-traffic protocols all
-
Escenario de alta disponibilidad:
set security zones security-zone trust interfaces reth2.0 host-inbound-traffic protocols all
-
Filtros de firewall
De forma predeterminada, el firewall virtual vSRX de IBM Cloud™ Juniper permite ping, SSH y HTTPS a sí mismo, y elimina todo el resto del tráfico mediante la aplicación del filtro PROTECT-IN a la interfaz lo.
Para configurar un nuevo firewall sin estado, siga estos pasos:
-
Cree el filtro y el término del firewall (el siguiente filtro solo permite ICMP y elimina todo el resto del tráfico)
set firewall filter ALLOW-PING term ICMP from protocol icmp
set firewall filter ALLOW-PING term ICMP then accept
-
Aplique la regla de filtro a la interfaz (el siguiente comando aplica el filtro a todo el tráfico de red privada)
set interfaces ge-0/0/0 unit 0 family inet filter input ALLOW-PING
Trabajar con sNAT
Puede referirse a una configuración de ejemplo para sNAT en un dispositivo de firewall virtual vSRX, donde un nodo privado enrutado detrás de la puerta de enlace puede comunicarse con el mundo exterior al trabajar con sNAT
Para configurar TDR para el firewall virtual vSRX de IBM Cloud™ Juniper, consulte la Guía del usuario de traducción de direcciones de red en el sitio web de Juniper.
Trabajar con conmutación por error
Puede iniciar la conmutación por error desde su firewall virtual vSRX de IBM Cloud™ principal de Juniper a un dispositivo de respaldo, de modo que todo el tráfico de plano de control y datos se enruta a través del dispositivo de puerta de enlace secundario después de la conmutación por error.
Esta sección solo se aplica si sus dispositivos de puerta de enlace de firewall virtual vSRX de Juniper se aprovisionan en el modo de alta disponibilidad.
Realice el siguiente procedimiento:
-
Inicie sesión en su dispositivo principal de puerta de enlace de firewall virtual vSRX.
-
Para entrar en el modo CLI, ejecute la cli de comandos en el símbolo de la consola. Cuando se entra en el modo de CLI, la consola muestra el rol del nodo, ya sea principal o secundario.
-
En el dispositivo principal de puerta de enlace de firewall virtual vSRX, ejecute el comando:
show chassis cluster status
Monitor 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}
Asegúrese de que, para ambos grupos de redundancia, el mismo nodo se establezca como principal. Es posible establecer diferentes nodos como la función principal en diferentes grupos de redundancia.
Nota:El firewall virtual vSRX, de forma predeterminada, establece Preempt para el grupo de redundancia 1 y no para el grupo de redundancia 0. Consulte este vínculo para obtener más información sobre el comportamiento de la conmutación por error y la anticipación.
-
Inicie la conmutación por error ejecutando el siguiente comando en el símbolo de la consola:
request chassis cluster failover redundancy-group <redundancy group number> node <node number>
Seleccione el número de grupo de redundancia y el número de nodo adecuados en la salida del comando en el paso dos. Para la conmutación por error de ambos grupos de redundancia, ejecute el comando anterior dos veces, uno para cada grupo.
-
Después de completar la conmutación por error, compruebe el resultado de la consola. Ahora debería figurar como secundario.
-
Inicie sesión en la otra puerta de enlace del firewall virtual vSRX de su par. Ingrese al modo de CLI ejecutando de nuevo la cli de comando y, luego, compruebe que la salida de la consola se muestra como principal.
Propina:Cuando ingresa al modo CLI en su dispositivo de puerta de enlace de firewall virtual vSRX de Juniper, la salida se mostrará como principal desde la perspectiva del plano de control. Siempre compruebe la salida de mostrar el estado del clúster de chasis para determinar qué dispositivo de puerta de enlace es principal desde la perspectiva del plano de datos. Consulte configuración predeterminada del firewall virtual vSRX para obtener más información sobre los grupos de redundancia, así como sobre los planos de control y datos.
Trabajar con enrutamiento
El firewall virtual vSRX de IBM Cloud™ de Juniper está basado en JunOS, lo que le da acceso a la pila de enrutamiento completa de Juniper.
-
Static routing—Para configurar rutas estáticas, ejecute los siguientes comandos:
Establecer una ruta predeterminada:
set routing-options static route 0/0 next-hop <Gateway IP>
-
Creating a static route—Ejecute el
set routing-options static route <PREFIX/MASK> next-hop <Gateway IP>
-
Basic OSPF routing—Para configurar el enrutamiento básico de OSPF, solo con el área 0, ejecute los siguientes comandos mediante la autenticación md5 mediante el
set protocols ospf area 0 interface ge-0/0/1.0 authentication md5 0 key <key>
comando. -
Basic BGP routing
-
Para configurar el enrutamiento BGP básico, primero defina el AS local ejecutando el
set routing-options autonomous-system 65001
comando. -
A continuación, configure el vecino del BGP y sus atributos de sesión:
set protocols bgp group CUSTOMER local-address 10.1.1.1
set protocols bgp group CUSTOMER family inet unicast
set protocols bgp group CUSTOMER family inet6 unicast
set protocols bgp group CUSTOMER peer-as 65002
set protocols bgp group CUSTOMER neighbor 2.2.2.2
En este ejemplo, BGP se configura para lo siguiente:
-
Para usar la dirección IP de origen de 10.1.1.1 para establecer la sesión
-
Para negociar familias de unidifusión ipv4 e ipv6
-
Para emparejar con un vecino que pertenece al AS 65002
-
IP de vecino par 10.2.2.2
-
-
Para obtener más configuraciones, consulte documentación de Junos OS
Trabajar con VPN
En este tema se detalla una configuración de ejemplo para una VPN basada en ruta entre dos sitios. En esta configuración de ejemplo, el servidor 1 (sitio A) puede comunicarse con el servidor 2 (sitio B), y cada sitio utiliza autenticación IPSEC de dos fases. Para obtener más información, consulte Trabajar con VPN y
- Configuración de ejemplo para el sitio A (Dallas):
- Configuración de ejemplo para el sitio B (Londres):
- Consideración del rendimiento
Configuración de ejemplo para el sitio 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; } }
Configuración de ejemplo para el sitio 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; } }
Consideración del rendimiento
Para lograr el mejor rendimiento de VPN IPSEC, utilice AES-GCM como algoritmo de cifrado para propuestas de IKE e IPSEC.
Por ejemplo:
set security ike proposal IKE-PROP encryption-algorithm aes-128-gcm
set security ipsec proposal IPSEC-PROP encryption-algorithm aes-128-gcm
Con AES-GCM como algoritmo de cifrado, no es necesario especificar el algoritmo de autenticación en la misma propuesta. AES-GCM proporciona cifrado y autenticación.
Para obtener más información sobre las configuraciones de VPN, consulte Guía del usuario de VPN IPsec para dispositivos de seguridad y ejemplo: Configuración de una VPN basada en rutas
Proteger el sistema operativo del host
El firewall virtual vSRX de IBM Cloud™ Juniper se ejecuta como una máquina virtual en un servidor sin sistema operativo instalado con Ubuntu y KVM. Para proteger el SO del host, debe asegurarse de que ningún otro servicio crítico se hospede en el mismo OS.
Acceso SSH
El firewall virtual vSRX de IBM Cloud™ Juniper se puede implementar con acceso de red público y privado o solo con acceso de red privado. De forma predeterminada, el acceso SSH basado en contraseña a la IP pública del sistema operativo host se deshabilitará en las nuevas disposiciones y en las recargas del SISTEMA operativo. El acceso al host se puede lograr a través de la dirección IP privada. Alternativamente, se puede usar la autenticación basada en claves para acceder a la IP pública. Para ello, especifique la clave SSH pública al realizar un nuevo pedido de puerta de enlace.
Algunos despliegues existentes del firewall virtual vSRX de IBM Cloud™ Juniper pueden permitir el acceso SSH basado en contraseñas a la IP pública del OS de host. Para estas implementaciones, puede deshabilitar manualmente el acceso SSH basado en contraseña a la IP pública del SO siguiendo estos pasos:
-
Modificar /etc/ssh/sshd_config
-
Asegúrese de que se establezcan los siguientes valores.
ChallengeResponseAuthentication no PasswordAuthentication no
-
Agregue las siguientes reglas de filtro al final del archivo.
Match Address 10.0.0.0/8 Password Authentication yes
-
-
Reinicie el servicio SSH mediante el comando /usr/sbin/service ssh restart.
El procedimiento anterior garantiza que las direcciones de la red de infraestructura privada 10.0.0.0/8 subred tengan acceso SSH. Este acceso es necesario para acciones como: recargas del sistema operativo, reconstrucción de clústeres, actualizaciones de versiones.
Cortafuegos
La implementación de un firewall de Ubuntu (UFW, Iptables, etc.) sin reglas requeridas puede hacer que el clúster de HA del firewall virtual vSRX se desactive. La solución de firewall virtual vSRX depende de la comunicación de latidos entre los nodos principal y secundario. Si las reglas del firewall no permiten la comunicación entre los nodos, se perderá la comunicación del clúster.
La arquitectura del firewall virtual vSRX influye en las reglas de firewall que se analizan a continuación. Los detalles de las dos arquitecturas se pueden encontrar en la configuración predeterminada de vSRX.
Para las implementaciones de HA de la versión 18.4 del firewall virtual vSRX que se ejecutan con la arquitectura heredada, se requieren las siguientes reglas para permitir la comunicación de clúster para UFW:
-
Para permitir el protocolo 47 (utilizado para la comunicación de latidos) en /etc/ufw/before.rules:
-A ufw-before-input -p 47 -j ACCEPT
-
Para permitir la comunicación de red privada:
ufw allow in from 10.0.0.0/8 to 10.0.0.0/8
-
Para habilitar la UFW:
ufw enable
Para las versiones del firewall virtual vSRX que se ejecutan con la arquitectura más reciente, las reglas del firewall deben permitir la comunicación de multidifusión.
En algunos casos, es posible que las operaciones de solución de problemas requieran deshabilitar el firewall para el acceso a los repositorios públicos. En estos casos, debe trabajar con soporte de IBM para comprender cómo proceder.
La mayoría de las acciones de puerta de enlace requieren acceso SSH a la subred privada 10.0.0.0/8 para el sistema operativo host y el firewall virtual vSRX. Bloquear este acceso con un firewall puede causar que se produzcan errores en las siguientes acciones: recargas del sistema operativo, reconstrucción de clústeres y actualizaciones de versiones
Como resultado, si el acceso SSH está deshabilitado para la subred 10.0.0.0/8, debe volver a habilitarla antes de ejecutar cualquiera de estas acciones.
Configuración de las interfaces de administración
Los nodos del firewall virtual vSRX de IBM Cloud™ Juniper ofrecen interfaces de administración integradas ("fxp0") que no están configuradas de forma predeterminada. Cuando se configuran, estas interfaces privadas se pueden usar para comunicarse con el nodo individual, lo que podría ser útil en un clúster de alta disponibilidad para supervisar el estado del nodo secundario a través de SSH, ping, SNMP, etc. Dado que la IP privada del firewall virtual vSRX flota en el nodo principal, no es posible acceder directamente al nodo secundario.
La configuración de la interfaz fxp0 requiere ip en una subred conectada a la VLAN de tránsito privado para la puerta de enlace. Aunque la subred principal que viene con la puerta de enlace tiene IP que podrían estar disponibles, no se recomienda para este uso. Esto se debe a que la subred principal está reservada para la infraestructura de aprovisionamiento de puerta de enlace y podrían producirse colisiones de IP si se implementan puertas de enlace adicionales en el mismo pod.
Puede asignar una subred secundaria para la VLAN de tránsito privado y usar IP desde esta subred para configurar fxp0 y la interfaz de puente de host para ping y acceso SSH. Para ello, realice el siguiente procedimiento: