Protegendo o sistema operacional do host

O IBM Cloud® Juniper vSRX é executado como uma Máquina virtual em um servidor bare metal instalado com Ubuntu e KVM. Para proteger o S.O. do host, é necessário assegurar-se de que nenhum outro serviço crítico esteja hospedado no mesmo S.O.

Acesso SSH

O IBM Cloud® Juniper vSRX pode ser implementado com acesso à rede pública e privada ou somente acesso à rede privada. Por padrão, o acesso do SSH baseado em senha para o IP público do S.O. do host será desativado em novas provisões e recarregamentos do S.O. O acesso ao host pode ser alcançado através do endereço IP privado. Alternativamente, a autenticação baseada em chave pode ser usada para acessar o IP público. Para fazer isso, especifique a chave SSH pública ao realizar um novo pedido de Gateway.

Algumas implementações existentes do IBM Cloud® Juniper vSRX podem permitir o acesso SSH baseado em senha ao IP público do S.O. do host. Para essas implementações, é possível desativar manualmente o acesso do SSH baseado em senha para o IP público do S.O. seguindo estas etapas:

  1. Modificar /etc/ssh/sshd_config

    • Assegure-se de que os valores a seguir estejam configurados.

      ChallengeResponseAuthentication no
PasswordAuthentication no

    • Inclua as regras de filtragem a seguir no término do arquivo.

      Match Address 10.0.0.0/8
    Password Authentication yes

  2. Reinicie o serviço do SSH usando o comando /usr/sbin/service ssh restart.

O procedimento acima assegura que os endereços na sub-rede da rede de infraestrutura privada 10.0.0.0/8 têm permissão de acesso do SSH. Esse acesso é necessário para ações como:

  • Recarregamentos do S.O.
  • Reconstrução de cluster
  • Upgrades de versão

Firewalls

Implementar um firewall do Ubuntu (UFW, Iptables e assim por diante) sem as regras necessárias pode fazer com que o cluster de alta disponibilidade do vSRX seja desativado. A solução do vSRX depende da comunicação de pulsação entre os nós primário e secundário. Se as regras de firewall não permitem a comunicação entre os nós, então, a comunicação de cluster será perdida.

A arquitetura do vSRX influencia as regras de firewall discutidas abaixo. Detalhes sobre as duas arquiteturas podem ser localizados em Configuração padrão do vSRX.

Para implementações de alta disponibilidade do vSRX versão 18.4 emexecução com a arquitetura anterior, as regras a seguir são necessárias para permitir a comunicação do cluster para o 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 ativar o UFW:

    ufw enable

Para versões do vSRX em execução com a arquitetura mais recente, as regras de firewall devem permitir a comunicação multicast.

Em alguns casos, as operações de resolução de problemas podem requerer a desativação do firewall para acesso a repositórios públicos. Nesses casos, é necessário trabalhar com o Suporte IBM para entender como continuar.

A maioria das ações do Gateway requer acesso do SSH à sub-rede privada 10.0.0.0/8 para o S.O. do host e o vSRX. Bloquear esse acesso com um firewall pode fazer com que as ações a seguir falhem:

  • Recarregamentos do S.O.
  • Reconstrução de cluster
  • Upgrades de versão

Como resultado, se o acesso do SSH estiver desativado para a sub-rede 10.0.0.0/8, você deverá ativá-lo novamente antes de executar qualquer uma dessas ações.