Gestión de cortafuegos
IBM Cloud® Virtual Router Appliance (VRA) tiene la capacidad de procesar reglas de cortafuegos para proteger las VLAN direccionadas a través del dispositivo.
Los cortafuegos de VRA pueden dividirse en dos pasos:
- Definición de uno o varios conjuntos de reglas.
- Aplicación de un conjunto de reglas a una interfaz o a una política de zona. Una zona consiste en una o más interfaces de red. Se define una política de zona para el tráfico que pasa de una zona a otra.
Es importante probar las reglas de cortafuegos después de la creación para garantizar que las reglas funcionan según lo previsto y que las nuevas reglas no restringen el acceso administrativo al dispositivo.
Durante la manipulación de reglas en la interfaz dp0bond1
, se recomienda conectar con el dispositivo utilizando dp0bond0
. La conexión a la consola mediante Intelligent Platform Management Interface (IPMI) también es una
opción.
Sin estado vs con estado
De forma predeterminada, el cortafuegos es sin estado, pero puede configurarse como con estado en caso de que sea necesario. Un cortafuegos sin estado necesitará reglas para el tráfico en ambas direcciones, mientras que los cortafuegos con estado realizan el seguimiento de las conexiones y permiten automáticamente el tráfico de retorno de los flujos aceptados. Para configurar un cortafuegos con estado, debe dictar qué reglas desea que funcionen con estado.
Para habilitar el seguimiento "con estado" del tráfico tcp
, udp
o icmp
, ejecute los mandatos siguientes:
set security firewall global-state-policy icmp
set security firewall global-state-policy tcp
set security firewall global-state-policy udp
Tenga en cuenta que los mandatos global-state-policy
sólo realizarán el seguimiento del estado del tráfico que haya coincidido con una regla de cortafuegos que establezca explícitamente el protocolo correspondiente. Por ejemplo:
set security firewall name GLOBAL_STATELESS rule 1 action accept
Puesto que GLOBAL_STATELESS
no especifica protocol tcp
, el mandato global-state-policy tcp
no se aplica a esta regla.
set security firewall name GLOBAL_STATEFUL_TCP rule 1 action accept
set security firewall name GLOBAL_STATEFUL_TCP rule 1 protocol tcp
En este caso, protocol tcp
se define explícitamente. El mandato global-state-policy tcp
permitirá el seguimiento con estado del tráfico que coincida con la regla 1 de GLOBAL_STATEFUL_TCP
Para que las reglas de cortafuegos individuales sean "con estado":
set security firewall name TEST rule 1 allow
set security firewall name TEST rule 1 state enable
De esta forma, se habilitará el seguimiento con estado de todo el tráfico del que se puede realizar el seguimiento con estado y que coincida con la regla 1 de TEST
, independientemente de que existan mandatos global-state-policy
.
ALG para seguimiento con estado asistido
Algunos protocolos, como FTP, utilizan sesiones más complejas que la operación normal del cortafuegos no puede rastrear. Existen módulos preconfigurados que permiten que estos protocolos se puedan gestionar con estado.
Se sugiere inhabilitar estos módulos ALG, a menos que sean necesarios para la correcta utilización de los respectivos protocolos.
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'
Conjunto de reglas de cortafuegos
Las reglas de cortafuegos se agrupan en conjuntos con nombre para facilitar la aplicación de regla en varias interfaces. Cada conjunto de reglas tiene una acción predeterminada asociada. Consulte el ejemplo siguiente:
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
En el conjunto de reglas ALLOW_LEGACY
, hay dos reglas definidas. La primera regla descarta cualquier tráfico que proviene de un grupo de dirección denominado network-group1
. El segundo descarta y registra cualquier
tráfico destinado al puerto telnet (tcp/23
) desde el grupo de direcciones denominado network-group2
. La acción por defecto indica que se acepta cualquier otra cosa. Una buena práctica es permitir sólo el tráfico necesario
y, a continuación, bloquear el resto utilizando la acción predeterminada del conjunto de reglas.
Permitir el acceso al centro de datos
IBM Cloud aloja muchas subredes (redes de servicio privadas) que proporcionan servicios y soporte a los servidores de cliente que se ejecutan en sus centros de datos. Por ejemplo, los servicios de resolución de DNS se ejecutan en 10.0.80.11
y 10.0.80.12
, y el servidor NTP predeterminado se ejecuta en 10.0.77.54
. Los tres están dentro de la red de servicio de 10.0.64.0/29
. Otras subredes se utilizan durante el suministro y soporte. Puede
encontrar las redes de servicio privadas utilizadas en los centros de datos en este tema.
Puede permitir el acceso de centro de datos colocando las reglas SERVICE-ALLOW
adecuadas al principio de los conjuntos de reglas de cortafuegos con la acción accept
. El lugar en el que el conjunto de reglas debe aplicarse
depende del diseño de cortafuegos y direccionamiento implementado.
Se recomienda colocar reglas de cortafuegos en la ubicación que causa la duplicación de trabajo. Por ejemplo, permitir la entrada de subredes de fondo en dp0bond0
será menos trabajo que permitir la salida de subredes de fondo en
cada interfaz virtual de VLAN.
Configuración de cortafuegos por interfaz
Un método para configurar el cortafuegos en VRA es aplicar conjuntos de reglas de cortafuegos en cada interfaz. En este caso, una interfaz puede ser una interfaz VLAN interna (VIF) (por ejemplo, dp0bond0.1303
), una de las interfaces
externas (dp0bond0
(privada) o dp0bond1
(pública)) o interfaces de túnel (por ejemplo, tun0
o vti0
). Cada interfaz tiene tres asignaciones de cortafuegos posibles:
in
- El cortafuegos filtra los paquetes que entran en la interfaz. Estos paquetes pueden atravesar o tener como destino la VRA.
out
- El cortafuegos filtra los paquetes que salen de la interfaz. Estos paquetes pueden atravesar o tener como destino la VRA.
local
- El cortafuegos se comprueba con los paquetes destinados a la VRA. La interfaz de bucle de retorno, lo
, se puede utilizar para filtrar el tráfico de entrada local en cualquier interfaz. Los filtros de cortafuegos
y los conjuntos de reglas aplicados a local
se procesan después de cualquier conjunto de reglas de cortafuegos que se aplique como in
a cualquier interfaz.
Una interfaz puede tener varios conjuntos de reglas aplicados en cada dirección. Se aplican por orden de configuración. Tenga en cuenta que esto no es posible en el tráfico de cortafuegos que proviene de un dispositivo VRA que utiliza cortafuegos por interfaz.
Por ejemplo, para asignar el conjunto de reglas ALLOW_LEGACY
a la opción in
para la interfaz dp0bond1
, se utilizaría el comando de configuración:
set interfaces bonding dp0bond1 firewall in ALLOW_LEGACY
Control Plane Policing (CPP)
Control plane policing (CPP) proporciona protección contra los ataques en IBM Cloud® Virtual Router Appliance y le permite configurar políticas de cortafuegos asignadas a las interfaces deseadas y aplicar dichas políticas a los paquetes que entran y salen de VRA.
CPP se implementa cuando la palabra clave local
se utiliza en las políticas de cortafuegos que se asignan a cualquier tipo de interfaz VRA, como las interfaces de plano de datos o bucle de retorno. A diferencia de las reglas de
cortafuegos aplicadas a los paquetes que atraviesan VRA, la acción predeterminada de las reglas de cortafuegos para el tráfico de entrada y salida del plano de control es Allow
. Los usuarios deben añadir reglas de descarte explícitas
si el comportamiento predeterminado no es el deseado.
VRA proporciona un conjunto de regla CPP básica como plantilla. Puede fusionarlo con su configuración ejecutando:
vyatta@vrouter# merge /opt/vyatta/etc/cpp.conf
Después de fusionar este conjunto de regla, se añade y se aplica un nuevo conjunto de reglas de cortafuegos denominado CPP
en la interfaz de bucle de retorno. Se recomienda modificar este conjunto de reglas para que se adapte a
su entorno.
Tenga en cuenta que las reglas de CPP no pueden ser con estado, y solo se aplicarán al tráfico entrante.
Configuración de cortafuegos basado en zona
En configuraciones de cortafuegos basadas en zonas, una o más interfaces se asignan a una zona (aunque una interfaz no se puede asignar a varias zonas) y los conjuntos de reglas de cortafuegos se aplican de una zona a otra. Para una política de zona única, el tráfico se filtra cuando pasa de la primera zona a la segunda, y el filtrado sólo se produce en la interfaz de salida/salida. Las zonas descartan cualquier tráfico que llega que no esté permitido de manera explícita.
Una interfaz puede pertenecer a una zona o tener una configuración de cortafuegos por interfaz; no puede hacer ambas cosas.
Considere el siguiente escenario de oficina con tres departamentos, cada departamento con su propia VLAN:
- Departamento A - VLANs 10 y 20 (interfaces
dp0bond1.10
ydp0bond1.20
) - Departamento B - VLANs 30 y 40 (interfaces
dp0bond1.30
ydp0bond1.40
) - Departamento C - VLAN 50 (interfaz
dp0bond1.50
)
Se puede crear una zona para cada departamento y las interfaces de dicho departamento pueden añadirse a la zona. El ejemplo siguiente ilustra esto:
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
El mandato commit
rellena cada zona como una interfaz y las reglas de descarte predeterminadas descartan el tráfico que intenta entrar en la zona desde el exterior. En el ejemplo, VLAN 10 y 20 pueden pasar tráfico porque están en
la misma zona (DEPARTMENTA
), pero VLAN 10 y VLAN 30 no pueden pasar el tráfico porque VLAN 30 está en una zona distinta (DEPARTMENTB
).
Las interfaces de cada zona pueden pasar el tráfico libremente y las reglas pueden definirse para la interacción entre zonas. Un conjunto de reglas se configura desde el punto de vista de dejar una zona a otra.
El mandato siguiente muestra un ejemplo de cómo configurar una regla:
set security zone-policy zone DEPARTMENTC to DEPARTMENTB firewall ALLOW_PING
Este comando asocia la transición de DEPARTMENTC
a DEPARTMENTB
con el conjunto de reglas denominado ALLOW_PING
. El tráfico que entra en la zona DEPARTMENTB
desde la zona DEPARTMENTC
se comprobaría con este conjunto de reglas.
Es importante entender que esta asignación de la zona DEPARTMENTC
que va a la zona DEPARTMENTB
no hace ninguna declaración sobre la inversa. Si no hay reglas que permitan el tráfico de la zona DEPARTMENTB
a la zona DEPARTMENTC
, entonces el tráfico (respuestas ICMP) no volverá a los hosts en DEPARTMENTC
.
ALLOW_PING
se aplicaría como cortafuegos out
en las interfaces de la zona DEPARTMENTB
(dp0bond1.30
y dp0bond1.40
). Como esto es instalado por la política de zona, sólo el tráfico
originado en las interfaces de la zona de origen (dp0bond1.50
) sería comprobado con el conjunto de reglas.
Ejemplo de cortafuegos basado en zona
El ejemplo siguiente detalla un entorno de cortafuegos que supervisa y depura todo el tráfico de egreso e ingreso de un VRA.
La adición de "log" a la regla 1 afectará severamente al rendimiento y sólo se debe utilizar para la depuración.
Nunca deje abiertas las interfaces públicas, como en este ejemplo.
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
Resolución de problemas de reglas de cortafuegos
Puede resolver los problemas de las configuraciones de cortafuegos basadas en zonas y basadas en interconexiones.
Resolución de problemas de configuraciones de cortafuegos basadas en interfaz
Para empezar a comprobar y resolver problemas, ejecute estos mandatos para comprender cómo se configuran las políticas:
- Para recopilar qué conjuntos de reglas de cortafuegos se aplican a cada interfaz y en qué dirección, ejecute
show configuration commands | grep firewall | grep interface
. - Utilizando la salida del paso 1 puede encontrar todas las reglas aplicadas a las interfaces en el flujo que está intentando comprobar ejecutando
show configuration commands | grep -iE '<name of firewall ruleset>'.
- Examine las reglas para asegurarse de que se permiten las subredes, puertos y protocolos adecuados:
- Si está resolviendo problemas de red de servicio con conectividad de servidor privado y el conjunto de reglas se aplica
in
a los VIF (dp0bond0.XXX
), debe definir las redes de servicio como los destinos. Esto se debe a que cuando el tráfico fluye en VIF, es decir, cuando el servidor cliente envía el tráfico de salida. - Si está resolviendo problemas de la red de servicio a la conectividad de servidor privado, y el conjunto de reglas se aplica
out
de los VIF (dp0bond0.XXX
), debe definir las redes de servicio como los orígenes. Esto se debe a que cuando el tráfico fluye fuera del VIF lo hace hacia los servidores cliente. - Si está solucionando problemas de conectividad de la red de servicio al servidor privado y el conjunto de reglas se aplica a la interfaz
dp0bond0
(in
), entonces debe definir las redes de servicio como las fuentes. Esto se debe a que el tráfico que fluye hacia la interfazdp0bond0
generalmente está destinado a los servidores detrás de Vyatta. - Si está resolviendo problemas de red de servicio con conectividad de servidor privado y el conjunto de reglas se aplica
out
de la interfazdp0bond0
, debe definir las redes de servicio como los destinos. Esto se debe a que el tráfico que sale dedp0bond0
está en la dirección alejada de los servidores de cliente que están detrás de Vyatta.
- Si está resolviendo problemas de red de servicio con conectividad de servidor privado y el conjunto de reglas se aplica
Resolución de problemas de configuraciones de cortafuegos basadas en zonas
Para empezar a comprobar y resolver problemas, ejecute estos mandatos para comprender cómo se configuran las políticas:
- Para mostrar qué interfaces están en qué zonas, ejecute
show configuration commands | grep zone | grep interface
. - Utilizando la salida del paso 1, puede encontrar el conjunto de reglas de cortafuegos aplicado en cada política de zona ejecutando
show configuration commands | grep <name of zone> | grep <name of other zone>
. - Utilizando la salida del paso 2 puede encontrar todas las reglas aplicadas a las interfaces en el flujo que está intentando comprobar ejecutando
show configuration commands | grep -iE '<name of firewall ruleset>|<name of other firewall ruleset>'
. - Examine las reglas para asegurarse de que se permiten las subredes, puertos y protocolos adecuados:
- Si está resolviendo problemas de red de servicio a conectividad de servidor privado, y la política es de las VIF (
dp0bond0.XXX
) adp0bond0
, debe definir las redes de servicio como destino. - Para las políticas que van de
dp0bond0
a los VIF (dp0bond0.XXX
), debe definir las redes de servicio como los orígenes.
- Si está resolviendo problemas de red de servicio a conectividad de servidor privado, y la política es de las VIF (
El ejemplo siguiente detalla los mandatos que puede utilizar para extraer la información necesaria para determinar si el cortafuegos debe permitir las redes de servicio.
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'
Registro de sesiones y paquetes
El VRA da soporte a dos tipos de registro, sesión y por paquete.
Registro de sesión
Utilice el mandato security firewall session-log
para configurar el registro de sesión de cortafuegos.
En UDP, ICMP, y todos los flujos que no sean de TCP, la sesión realizará una transición a cuatro estados durante el tiempo de vida del flujo. Para cada transición, puede configurar VRA para que registre un mensaje. TCP tiene un mayor número
de transiciones de estado y cada una puede configurarse para realizar un registro. El ejemplo siguiente detalla la configuración de session-log
para el cortafuegos:
set security firewall session-log icmp established
set security firewall session-log tcp established
set security firewall session-log udp established
Registro por paquete
Para el registro por paquete, asegúrese de incluir la palabra clave log
en la regla de cortafuegos o NAT. Esto registrará cada paquete de red que coincida con la regla.
El registro por paquete se produce en las vías de acceso de reenvío de paquetes y genera grandes cantidades de salidas. El registro por paquetes puede reducir en gran medida el rendimiento del VRA, causar problemas de rendimiento y aumentar drásticamente el espacio de disco utilizado para los archivos de registro. Se recomienda utilizar el registro por paquete sólo para fines de depuración. Para todos los propósitos operativos, se debe utilizar el registro de sesión con estado.
Resolución de problemas utilizando registros de cortafuegos
Para fines de depuración, puede configurar el registro predeterminado y el registro por paquete. El registro por paquete se puede añadir a cada regla individual para mostrar en los registros cuándo se descartan o aceptan los paquetes (en función de la acción establecida para la regla). El registro predeterminado registra un descarte "implícito" cuando se produce. Para la siguiente configuración de cortafuegos basada en políticas de zona, el valor de registro predeterminado registrará cada vez que el tráfico no coincida con la regla 1. Esta es la única regla configurada.
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
Para ver el registro, hay dos mandatos y la salida siguiente muestra un bloque registrado de tráfico específico:
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]