Realização de tarefas avançadas do firewall virtual vSRX na nuvem da IBM
Trabalhando com firewalls
O firewall virtual vSRX da IBM Cloud™ Juniper usa o conceito de zonas de segurança, onde cada interface de firewall virtual vSRX é mapeada em uma "zona" para o manuseio de firewalls stateful. Os firewalls stateless são controlados por filtros de firewall.
As políticas são usadas para permitir e bloquear o tráfego entre essas zonas definidas, e as regras definidas aqui são stateful.
Na nuvem da IBM, um firewall virtual vSRX foi projetado para ter quatro zonas de segurança diferentes:
| Zona |
Interface autônoma |
HA Interface |
|---|---|---|
| SL-Private (sem registro) |
ge-0/0/0,0 ou ae0.0 |
reth0.0 |
| SL-Public (não registrado) |
ge-0/0/1,0 ou ae1,0 |
reth1.1 |
| Cliente privado (tags) |
ge-0/0/0,1 ou ae0.1 |
reth2.1 |
| Público do cliente (tags) |
ge-0/0/1,1 ou ae1.1 |
reth3.1 |
Políticas de zona
A seguir, alguns dos atributos que podem ser definidos em suas políticas:
-
Endereços de origem
-
Endereços de destino
-
Aplicativos
-
Ação (permissão/negação/rejeição/contagem/log)
Como esta é uma operação stateful, não há necessidade de permitir a devolução de pacotes (neste caso, o eco responde).
Para configurar um firewall stateful, siga essas etapas:
-
Crie zonas de segurança e atribua as respectivas interfaces:
Cenário autônomo:
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.1set security zones security-zone CUSTOMER-PUBLIC interfaces ge-0/0/1.1Cenário de alta disponibilidade:
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.1set security zones security-zone CUSTOMER-PUBLIC interfaces reth2.1 -
Definir a política e as regras entre duas zonas diferentes.
O exemplo a seguir ilustra o ping de tráfego da zona cliente-privado para o cliente público:
set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policyset security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy -
Use os seguintes comandos para permitir o tráfego direcionado ao firewall virtual vSRX:
-
Cenário autônomo:
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.0 host-inbound-traffic system-services all -
Cenário de alta disponibilidade:
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.0 host-inbound-traffic system-services all
-
-
Para permitir protocolos, como OSPF ou BGP, use o seguinte comando:
-
Cenário autônomo:
set security zones security-zone trust interfaces ge-0/0/0.0 host-inbound-traffic protocols all -
Cenário de alta disponibilidade:
set security zones security-zone trust interfaces reth2.0 host-inbound-traffic protocols all
-
Filtros de firewall
Por padrão, o firewall virtual vSRX da IBM Cloud™ Juniper permite que ping, SSH e HTTPS se apliquem a todos os outros tráfegos aplicando o filtro PROTECT-IN na interface lo.
Para configurar um novo firewall sem estado, siga essas etapas:
-
Crie o filtro e o termo do firewall (o filtro a seguir permite apenas ICMP e derruba todos os outros tráfegos)
set firewall filter ALLOW-PING term ICMP from protocol icmpset firewall filter ALLOW-PING term ICMP then accept -
Aplique a regra do filtro na interface (o comando a seguir aplica o filtro a todo o tráfego de rede privada)
set interfaces ge-0/0/0 unit 0 family inet filter input ALLOW-PING
Trabalhando com sNAT
Você pode consultar uma configuração de amostra para sNAT em um dispositivo de firewall virtual vSRX, onde um nó privado roteado atrás do gateway pode se comunicar com o mundo exterior trabalhando com sNAT
Para configurar o NAT para o firewall virtual vSRX da IBM Cloud™, consulte o Guia do usuário de tradução de endereços de rede no site da Juniper.
Trabalhando com Failover
Você pode iniciar o failover do seu firewall virtual vSRX da IBM™ principal para um dispositivo de backup, para que todo o tráfego de planos de controle e dados seja roteado pelo dispositivo de gateway secundário após o failover.
Esta seção só é aplicável se seus dispositivos de gateway de firewall virtual vSRX da Juniper forem provisionados no modo de alta disponibilidade.
Realize o seguinte procedimento:
-
Faça login no seu principal dispositivo de gateway de firewall virtual vSRX.
-
Insira o modo CLI executando a cli de comando no prompt do console. Quando você entra no modo CLI, o console exibe a função de nó, seja primária ou secundária.
-
No principal dispositivo de gateway de firewall virtual vSRX, execute o comando:
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}Garanta que, para ambos os grupos de redundância, o mesmo nó seja definido como primário. É possível que diferentes nós sejam definidos como o papel principal em diferentes grupos de redundância.
Nota:O firewall virtual vSRX, por padrão, define Preempt para sim para redundância do grupo 1 e não para redundância do grupo 0. Consulte este link para saber mais sobre o comportamento de prevenção e failover.
-
Inicie o failover executando o seguinte comando no prompt do console:
request chassis cluster failover redundancy-group <redundancy group number> node <node number>Selecione o número do grupo de redundância e o número de nó apropriados da saída do comando na segunda etapa. Para falhar em ambos os grupos de redundância, execute o comando anterior duas vezes, uma para cada grupo.
-
Após o failover ser concluído, verifique a saída do console. Agora deve ser listado como secundário.
-
Faça login no outro gateway de firewall virtual vSRX do seu par. Entre no modo CLI executando novamente a cli de comando e, em seguida, verifique se a saída do console mostra como principal.
Ponta:Quando você entra no modo CLI em seu dispositivo de gateway de firewall virtual vSRX da Juniper, a saída será exibida como primária da perspectiva do plano de controle. Verifique sempre a saída de status do cluster do chassi para determinar qual dispositivo de gateway é primário da perspectiva do plano de dados. Consulte a configuração padrão do firewall virtual vSRX para saber mais sobre grupos de redundância, bem como os planos de controle e dados.
Trabalhando com o roteamento
O firewall virtual vSRX da IBM Cloud™ Juniper é baseado no JunOS, oferecendo a você acesso a toda a pilha de roteamento da Juniper.
-
Static routing— Para configurar rotas estáticas, execute os seguintes comandos:
Definir uma rota padrão—
set routing-options static route 0/0 next-hop <Gateway IP> -
Creating a static route— Execute o
set routing-options static route <PREFIX/MASK> next-hop <Gateway IP> -
Basic OSPF routing— Para configurar o roteamento básico de OSPF, usando apenas a área 0, execute os seguintes comandos usando a autenticação md5 usando o
set protocols ospf area 0 interface ge-0/0/1.0 authentication md5 0 key <key>comando. -
Basic BGP routing
-
Para configurar o roteamento BGP básico, primeiro defina o AS local executando o
set routing-options autonomous-system 65001comando. -
Em seguida, configure o vizinho BGP e seus atributos de sessão:
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.2Neste exemplo, o BGP está configurado para o seguinte:
-
Usar o endereço IP de origem de 10.1.1.1 para estabelecer a sessão
-
Para negociar famílias unicast ipv4 e ipv6
-
Para peer com um vizinho que pertence ao AS 65002
-
Vizinho de peer IP 10.2.2.2
-
-
Para obter mais configurações, veja Documentação do Junos OS
Trabalhando com VPN
Este tópico detalha uma configuração de amostra para uma VPN baseada em rota entre dois sites. Nesta configuração de amostra, o Servidor 1 (Site A) pode se comunicar com o Servidor 2 (Site B), e cada site utiliza duas fases de autenticação IPSEC. Para obter mais informações, veja Trabalhar com VPN e
- Configuração de amostra para o Site A (Dallas):
- Configuração de amostra para o Site B (Londres):
- Consideração de desempenho
Configuração de amostra para o 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;
}
}
Configuração de amostra para o 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;
}
}
Consideração de desempenho
Para obter o melhor desempenho de VPN IPSEC, use o AES-GCM como algoritmo de criptografia para propostas de IKE e IPSEC.
Por exemplo:
set security ike proposal IKE-PROP encryption-algorithm aes-128-gcm
set security ipsec proposal IPSEC-PROP encryption-algorithm aes-128-gcm
Com o AES-GCM como algoritmo de criptografia, você não precisa especificar o algoritmo de autenticação na mesma proposta. A AES-GCM oferece criptografia e autenticação.
Para obter mais informações sobre as configurações de VPN, consulte o guia de usuário de VPN IPsec para dispositivos de segurança e exemplo: configuração de uma VPN baseada em rota
Proteção do sistema operacional host
O firewall virtual vSRX da IBM Cloud™ Juniper funciona como uma máquina virtual em um servidor bare-metal instalado com Ubuntu e KVM. Para proteger o sistema operacional de host, você deve garantir que nenhum outro serviço crítico esteja hospedado no mesmo SO.
Acesso SSH
O firewall virtual vSRX da IBM Cloud™ Juniper pode ser implantado com acesso à rede pública e privada ou apenas acesso à rede privada. Por padrão, o acesso SSH baseado em senha ao IP público do sistema operacional host será desativado em novas disposições e recargas de OS. O acesso ao host pode ser alcançado por meio do endereço IP privado. Como alternativa, a autenticação baseada em chave pode ser usada para acessar o IP público. Para isso, especifique a chave SSH pública ao colocar uma nova ordem de Gateway.
Algumas implantações existentes do firewall virtual vSRX da IBM Cloud™ Juniper podem permitir acesso SSH baseado em senha ao IP público do sistema operacional host. Para essas implantações, você pode desabilitar manualmente o acesso SSH baseado em senha ao IP público do OS seguindo estas etapas:
-
Modificar /etc/ssh/sshd_config
-
Garanta que os valores a seguir sejam definidos.
ChallengeResponseAuthentication no PasswordAuthentication no
-
Adicione as seguintes regras de filtro ao final do arquivo.
Match Address 10.0.0.0/8 Password Authentication yes
-
-
Reinicie o serviço SSH usando o comando /usr/sbin/service ssh restart.
O procedimento acima garante que os endereços da rede de infraestrutura privada 10.0.0.0/8 tenham acesso SSH. Esse acesso é necessário para ações como: recargas de SO, reconstrução de clusters, atualizações de versão.
Firewalls
A implementação de um firewall Ubuntu (UFW, Iptables e assim por diante) sem as regras necessárias pode fazer com que o cluster HA do firewall virtual vSRX seja desativado. A solução de firewall virtual vSRX depende da comunicação entre os nós primários e secundários. Se as regras do firewall não permitirem a comunicação entre os nós, a comunicação do cluster será perdida.
A arquitetura de firewall virtual vSRX influencia as regras de firewall discutidas abaixo. Detalhes sobre as duas arquiteturas podem ser encontrados na configuração padrão do vSRX.
Para implantações vSRX Virtual Firewall versão 18.4 HA em execução com a arquitetura legada, as seguintes regras são necessárias para permitir a comunicação de clusters para UFW:
-
Para permitir o protocolo 47 (usado para comunicação de pulsação) em /etc/ufw/before.rules:
-A ufw-before-input -p 47 -j ACCEPT
-
Para permitir a comunicação de rede privada:
ufw allow in from 10.0.0.0/8 to 10.0.0.0/8
-
Para habilitar a UFW:
ufw enable
Para versões de firewall virtual vSRX em execução com a arquitetura mais recente, as regras do firewall devem permitir a comunicação multicast.
Em alguns casos, a solução de problemas das operações pode exigir a desativação do firewall para acesso a repositórios públicos. Nesses casos, você deve trabalhar com o IBM Support para entender como proceder.
A maioria das ações de gateway exige acesso SSH à sub-rede privada 10.0.0.0/8 para o sistema operacional host e o firewall virtual vSRX. Bloquear esse acesso com um firewall pode fazer com que as seguintes ações sejam reprovadas: recargas de SO, reconstrução de clusters e atualizações de versão
Como resultado, se o acesso SSH for desativado para a sub-rede 10.0.0.0/8, você deve reabilitá-lo antes de executar qualquer uma dessas ações.
Configuração das interfaces de gerenciamento
Os nós de firewall virtual vSRX da IBM Cloud™ Juniper oferecem interfaces de gerenciamento integradas ("fxp0") que não são configuradas por padrão. Quando configuradas, essas interfaces privadas podem ser usadas para se comunicar com o nó individual, o que pode ser útil em um cluster de alta disponibilidade para monitorar o status do nó secundário sobre SSH, ping, SNMP e assim por diante. Como o IP privado para o firewall virtual vSRX flutua para o nó principal, não é possível acessar diretamente o nó secundário.
A configuração da interface fxp0 requer IPs em uma sub-rede que é anexada à VLAN de trânsito privado para o gateway. Embora a sub-rede primária que vem com o gateway tenha IPs que podem estar disponíveis, ele não é recomendado para este uso. Isso ocorre porque a sub-rede primária está reservada para a infraestrutura de provisionamento de gateway, e colisões de IP podem ocorrer se gateways adicionais forem implantados no mesmo pod.
Você pode alocar uma sub-rede secundária para o VLAN de trânsito privado, e usar IPs a partir desta sub-rede para configurar o fxp0 e a interface de ponte de host para acesso PING e SSH. Para isso, realize o seguinte procedimento: