Gerenciando firewalls

O IBM Cloud® Virtual Router Appliance (VRA) tem a capacidade de processar regras de firewall para proteger as VLANs roteadas por meio do dispositivo.

Os firewalls no VRA podem ser divididos em duas etapas:

Definindo um ou mais conjuntos de regras.
Aplicação de um conjunto de regras a uma interface ou a uma política de zona. Uma zona consiste em uma ou mais interfaces de rede. Uma política de zona é definida para tráfego que atravessa de uma zona para outra.

É importante testar regras de firewall após a criação para assegurar que as regras funcionem conforme desejado e que as novas regras não restrinjam o acesso administrativo ao dispositivo.

Ao manipular as regras na interface dp0bond1, é aconselhável se conectar ao dispositivo usando o dp0bond0. Conectar-se ao console usando o Intelligent Platform Management Interface (IPMI) também é uma opção.

Stateless versus stateful

Por padrão, o firewall é stateless, mas pode ser configurado como stateful se necessário. Um firewall stateless precisará de regras para o tráfego em ambas as direções, enquanto firewalls stateful rastrearão conexões e permitirão automaticamente o tráfego de retorno de fluxos aceitos. Para configurar um firewall stateful, deve-se determinar quais regras você deseja operar nesse estado.

Para ativar o rastreamento 'stateful' do tráfego tcp, udp ou icmp, execute os comandos a seguir:

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

Observe que os comandos global-state-policy só rastrearão o estado do tráfego que tenha correspondido a uma regra de firewall que configure explicitamente o protocolo correspondente. Por exemplo:

set security firewall name GLOBAL_STATELESS rule 1 action accept

Como GLOBAL_STATELESS não especifica protocol tcp, o comando global-state-policy tcp não seria aplicado a essa regra.

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

Neste caso, protocol tcp é definido explicitamente. O comando global-state-policy tcp ativaria o rastreamento stateful do tráfego que correspondesse à regra 1 do GLOBAL_STATEFUL_TCP

Para tornar 'stateful' as regras de firewall individuais:

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

Isso ativaria o rastreamento stateful de todo o tráfego que pudesse ser rastreado como stateful e que correspondesse à regra 1 de TEST, independentemente da existência de comandos global-state-policy.

ALG para rastreamento stateful assistido

Alguns protocolos, como o FTP, usam sessões mais complexas do que a operação de firewall stateful normal pode rastrear. Há módulos pré-configurados que permitem que esses protocolos sejam gerenciados de forma stateful.

Sugere-se desativar esses módulos ALG, a menos que eles sejam necessários para o uso bem-sucedido dos 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'

Conjuntos de regras de firewall

As regras de firewall são agrupadas em conjuntos nomeados para tornar a aplicação de regras para várias interfaces mais fácil. Cada conjunto de regras tem uma ação padrão associada a ele. Considere o exemplo a seguir:

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

No conjunto de regras ALLOW_LEGACY, há duas regras definidas. A primeira regra elimina qualquer tráfego originado de um grupo de endereços denominado network-group1. O segundo descarta e registra qualquer tráfego destinado à porta telnet (tcp/23) do grupo de endereços denominado network-group2. A ação padrão indica que qualquer outra coisa é aceita. Uma boa prática é permitir apenas o tráfego necessário e, em seguida, bloquear o restante usando a ação padrão do conjunto de regras

Permitindo o acesso ao data center

O IBM Cloud hospeda muitas sub-redes (redes de serviço privadas) que fornecem serviços e suporte para servidores clientes em execução em seus datacenters. Por exemplo, os serviços do resolvedor DNS são executados em 10.0.80.11 e 10.0.80.12 e o servidor NTP padrão é executado em 10.0.77.54. Todos os três estão dentro da rede de serviço do 10.0.64.0/29 Outras sub-redes são usadas durante o fornecimento e o suporte. É possível localizar as redes de serviços privados usadas nos data centers em este tópico

É possível permitir acesso ao data center colocando as regras SERVICE-ALLOW adequadas no início dos conjuntos de regras de firewall com uma ação igual a accept. Onde o conjunto de regras deve ser aplicado depende do roteamento e do design de firewall que estão sendo implementados.

É recomendado que você coloque as regras de firewall no local que causa menos duplicação de trabalho. Por exemplo, permitir a entrada de sub-redes de backend em dp0bond0 seria menos trabalhoso do que permitir a saída de sub-redes de backend em direção a cada interface virtual de VLAN.

Configuração de firewall por interface

Um método para configurar o firewall em um VRA é aplicar conjuntos de regras de firewall em cada interface. Nesse caso, uma interface pode ser uma interface VLAN (VIF) interna (como dp0bond0.1303), uma das interfaces externas (dp0bond0 (privada) ou dp0bond1 (pública)) ou interfaces de túnel (como tun0 ou vti0). Cada interface possui três designações de firewall possíveis:

in- O firewall filtra os pacotes que entram na interface. Esses pacotes podem passar pelo VRA ou ser destinados a ele.

out- O firewall filtra os pacotes que saem da interface. Esses pacotes podem passar pelo VRA ou ser destinados a ele.

local- O firewall é verificado em relação aos pacotes destinados ao VRA. A interface de loopback, lo, pode ser usada para filtrar tráfego de entrada local em qualquer interface. Filtros de firewall e conjuntos de regras aplicados ao local são processados após quaisquer conjuntos de regras de firewall que são aplicados como in a qualquer interface.

Uma interface pode ter múltiplos conjuntos de regras aplicados em cada direção. Eles são aplicados na ordem de configuração. Observe que não é possível para o tráfego de firewall se originar no dispositivo VRA usando firewalls por interface.

Por exemplo, para atribuir o conjunto de regras ALLOW_LEGACY à opção in da interface dp0bond1, você usaria o comando de configuração:

set interfaces bonding dp0bond1 firewall in ALLOW_LEGACY

Policiamento de Plano de Controle (CPP)

O policiamento do plano de controle (CPP) fornece proteção contra ataques no IBM Cloud® Virtual Router Appliance, permitindo configurar políticas de firewall designadas às interfaces desejadas e aplicando essas políticas aos pacotes que entram no VRA.

O CPP é implementado quando a palavra-chave local é usada em políticas de firewall que são designadas a qualquer tipo de interface de VRA, tais como interfaces de plano de dados ou loopback. Ao contrário das regras de firewall aplicadas para pacotes que atravessam o VRA, a ação padrão de regras de firewall para o tráfego que entra ou sai do plano de controle é Allow. Os usuários deverão incluir regras de descarte explícitas se o comportamento padrão não será desejado.

O VRA fornece um conjunto de regras de CPP básicas como modelo. É possível mesclá-lo em sua configuração, executando:

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

Depois que esse conjunto de regras é mesclado, um novo conjunto de regras de firewall chamado CPP é incluído e aplicado à interface de loopback. É recomendado que você modifique esse conjunto de regras para adequar seu ambiente.

Observe que as regras de CPP não poderão ser stateful e só se aplicarão a tráfego de ingresso.

Configuração de firewall baseada em zona

Nas configurações de firewall baseadas em zona, uma ou mais interfaces são designadas a uma zona (embora uma interface não possa ser designada a várias zonas) e conjuntos de regras de firewall são aplicados de uma zona para outra. Para uma única política de zona, o tráfego é filtrado quando está passando da primeira zona para a segunda e a filtragem ocorre apenas na interface de saída / egresso. As zonas descartam qualquer tráfego que entre nelas que não seja explicitamente permitido.

Uma interface pode pertencer a uma zona ou ter uma configuração de firewall por interface; não é possível fazer as duas coisas.

Considere o seguinte cenário de escritório com três departamentos, cada departamento com sua própria VLAN:

Departamento A - VLANs 10 e 20 (interfaces dp0bond1.10 e dp0bond1.20)
Departamento B - VLANs 30 e 40 (interfaces dp0bond1.30 e dp0bond1.40)
Departamento C - VLAN 50 (interface dp0bond1.50)

Uma zona pode ser criada para cada departamento e as interfaces para esse departamento podem ser incluídas na zona. O exemplo a seguir ilustra isso:

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

O comando commit preenche cada zona como uma interface e as regras de descarte padrão descartam qualquer tráfego que tente entrar na zona a partir de fora. No exemplo, VLAN 10 e 20 podem transmitir o tráfego, pois estão na mesma zona (DEPARTMENTA), mas VLAN 10 e VLAN 30 não podem transmitir o tráfego porque a VLAN 30 está em uma zona diferente (DEPARTMENTB).

As interfaces dentro de cada zona podem transmitir o tráfego livremente e as regras podem ser definidas para interação entre as zonas. Um conjunto de regras é configurado do ponto de vista de sair de uma zona para outra zona.

O comando a seguir mostra um exemplo de como configurar uma regra:

set security zone-policy zone DEPARTMENTC to DEPARTMENTB firewall ALLOW_PING

Esse comando associa a transição de DEPARTMENTC para DEPARTMENTB com o conjunto de regras denominado ALLOW_PING. O tráfego que entra na zona DEPARTMENTB a partir da zona DEPARTMENTC seria verificado em relação a esse conjunto de regras.

É importante entender que essa atribuição da zona DEPARTMENTC para a zona DEPARTMENTB não faz nenhuma declaração sobre o inverso. Se não houver regras que permitam o tráfego da zona DEPARTMENTB para a zona DEPARTMENTC, o tráfego (respostas ICMP) não retornará aos hosts em DEPARTMENTC.

ALLOW_PING seria aplicado como um firewall out nas interfaces da zona DEPARTMENTB (dp0bond1.30 e dp0bond1.40). Como isso é instalado pela política de zona, somente o tráfego originado das interfaces da zona de origem (dp0bond1.50) seria verificado em relação ao conjunto de regras.

Exemplo de firewall baseado em zona

O exemplo a seguir detalha um ambiente de firewall que monitora e depura todo o egresso de tráfego e ingresso de um VRA

A inclusão de "log" na regra 1 impactará o desempenho e deverá ser usada apenas para depuração.

Nunca deixe suas interfaces públicas abertas, como neste exemplo.

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

Resolução de problemas de regras de firewall

É possível solucionar problemas de configurações de firewall baseadas em interface e baseadas em zona.

Resolução de problemas de configurações de firewall baseadas em interface

Para iniciar a verificação e resolução de problemas, execute estes comandos para entender como as políticas são configuradas:

Para reunir quais conjuntos de regras de firewall são aplicados a cada interface em qual direção, execute show configuration commands | grep firewall | grep interface.
Usando a saída da etapa 1, é possível localizar todas as regras aplicadas às interfaces no fluxo que você está tentando verificar executando show configuration commands | grep -iE '<name of firewall ruleset>'.
Examine as regras para certificar-se de que as sub-redes, portas e protocolos adequados sejam permitidos:
- Se você estiver resolvendo problemas de rede de serviço para conectividade de servidor privado e o conjunto de regras for aplicado in aos VIFs (dp0bond0.XXX), deverá definir as redes de serviço como os destinos. Isso ocorre porque quando o tráfego flui para o VIF, ou seja, quando o servidor cliente envia a saída de tráfego
- Se você estiver resolvendo problemas de rede de serviço para conectividade de servidor privado e o conjunto de regras for aplicado out dos VIFs (dp0bond0.XXX), deverá definir as redes de serviço como as origens. Isso ocorre porque quando o tráfego flui para fora do VIF ele faz isso para os servidores clientes.
- Se estiver solucionando problemas de conectividade entre a rede de serviços e o servidor privado, e o conjunto de regras for aplicado in à interface dp0bond0, você deverá definir as redes de serviços como origens. Isso ocorre porque o tráfego que flui para a interface dp0bond0 é geralmente destinado aos servidores por trás do Vyatta.
- Se você estiver resolvendo problemas de rede de serviço para conectividade do servidor privado e o conjunto de regras for aplicado out da interface dp0bond0, deverá definir as redes de serviço como os destinos. Isso ocorre porque o tráfego que flui do dp0bond0 está na direção de distância dos servidores clientes que estão atrás do Vyatta.

Resolução de problemas de configurações de firewall baseadas em zona

Para iniciar a verificação e resolução de problemas, execute estes comandos para entender como as políticas são configuradas:

Para mostrar quais interfaces estão em quais zonas, execute show configuration commands | grep zone | grep interface
Usando a saída da etapa 1, é possível localizar o conjunto de regras de firewall aplicado em cada política de zona executando show configuration commands | grep <name of zone> | grep <name of other zone>..
Usando a saída da etapa 2 é possível localizar todas as regras aplicadas às interfaces no fluxo que você está tentando verificar executando show configuration commands | grep -iE '<name of firewall ruleset>|<name of other firewall ruleset>'.
Examine as regras para certificar-se de que as sub-redes, portas e protocolos adequados sejam permitidos:
- Se você estiver resolvendo problemas de rede de serviço para conectividade de servidor privado e a política for dos VIF (dp0bond0.XXX) para dp0bond0, deve-se definir as redes de serviço como o destino.
- Para políticas que são do dp0bond0 para os VIF (dp0bond0.XXX), você deve definir as redes de serviço como as origens.

O exemplo a seguir detalha os comandos que podem ser usados para extrair as informações necessárias para determinar se o firewall deve permitir as redes de serviço

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'

Criação de log de sessão e de pacote

O VRA suporta dois tipos de log, sessão e por pacote.

Criação de log de sessão

Use o comando security firewall session-log para configurar a criação de log de sessões de firewall

Para o UDP, o ICMP e todos os fluxos não TCP, sua sessão fará a transição para quatro estados durante o tempo de vida do fluxo. Para cada transição, é possível configurar o VRA para registrar uma mensagem. O TCP tem um número maior de transições de estado, cada uma das quais pode ser configurada para log. O exemplo a seguir detalha a configuração de session-log para seu firewall:

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

Criação de log por pacote

Para criação de log por pacote, assegure-se de incluir a palavra-chave log na regra de firewall ou NAT. Isso registrará cada pacote de rede correspondente à regra.

A criação de log por pacote ocorre nos caminhos de encaminhamento do pacote e gera grandes quantidades de saída. O registro por pacote pode reduzir muito a taxa de transferência do VRA, causar problemas de desempenho e aumentar drasticamente o espaço em disco usado para os arquivos de registro. É recomendado que você use a criação de log por pacote apenas para propósitos de depuração Para todos os fins operacionais, o registro de sessão com estado deve ser usado em seu lugar.

Resolução de problemas usando logs de firewall

Para propósitos de depuração, é possível configurar o log padrão e a criação de log por pacotes A criação de log por pacote pode ser incluída em cada regra individual para mostrar nos logs quando pacotes são descartados ou aceitos (dependendo da ação configurada para a regra). O log padrão registra um descarte "implícito" quando ele acontece. Para a configuração de firewall baseada em política de zona a seguir, a configuração de log padrão registrará toda vez que o tráfego não corresponder à regra 1. Esta é a única regra 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 visualizar o log, há dois comandos e a saída a seguir demonstra um bloco registrado de tráfego 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]