Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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:

  1. 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

  2. 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

  3. 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

  4. 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:

  1. 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

  2. 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.

Nota:

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:

  1. Inicie sesión en su dispositivo principal de puerta de enlace de firewall virtual vSRX.

  2. 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.

  3. En el dispositivo principal de puerta de enlace de firewall virtual vSRX, ejecute el comando:

    show chassis cluster status

    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.

  4. 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.

  5. Después de completar la conmutación por error, compruebe el resultado de la consola. Ahora debería figurar como secundario.

  6. 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

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:

  1. Modificar /etc/ssh/sshd_config

    • Asegúrese de que se establezcan los siguientes valores.

    • Agregue las siguientes reglas de filtro al final del archivo.

  2. 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:

  1. 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

  2. Para permitir la comunicación de red privada:

    ufw allow in from 10.0.0.0/8 to 10.0.0.0/8

  3. 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.

Nota:

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:

  1. Solicite una subred privada portátil y asígnela a la VLAN de tránsito privado de firewall virtual vSRX. Puede encontrar la VLAN de tránsito privado en la página de detalles de la puerta de enlace.
    Nota:

    Asegúrese de que la subred incluye al menos 8 direcciones para admitir 2 IP para las interfaces de puente del host y 2 IP para las interfaces fxp0 del firewall virtual vSRX.

  2. Configurar el host br0:0 interfaces de puente mediante 2 IP de la nueva subred. Por ejemplo:

    En el host de Ubuntu 0: ifconfig br0:0 10.177.75.140 máscara de red 255.255.255.248

    En el host 1 de Ubuntu: ifconfig br0:0 10.177.75.141 máscaras netas 255.255.255.248

  3. Persista las configuraciones de interfaz de puente en los reinicios modificando /etc/network/interfaces en cada host de Ubuntu. Por ejemplo:
  4. Asigne las 2 IP a la interfaz fxp0 del firewall virtual vSRX y cree configuraciones de enrutador de respaldo para acceder a la interfaz fxp0 del nodo secundario:
    Nota:

    Puede encontrar más información sobre la configuración del enrutador de respaldo en este artículo de Juniper en: KB17161.

  5. Cree una ruta estática a la subred. Por ejemplo:

    set routing-options static route 10.177.75.136/29 next-hop 10.177.75.137

  6. Cree filtros de firewall para permitir PING y SSH a las interfaces de administración fxp0:

    set firewall filter PROTECT-IN term PING from destination-address 10.177.75.136/29

    set firewall filter PROTECT-IN term SSH from destination-address 10.177.75.136/29