Exemplo: Controle de acesso ao gerenciamento em dispositivos de rede da Juniper
Nossa equipe de testes de conteúdo validou e atualizou este exemplo.
Este exemplo mostra como limitar o acesso de gerenciamento a dispositivos juniper networking com base em um conjunto específico de endereços IP permitidos. Esse tipo de funcionalidade é frequentemente referida como uma lista de controle de acesso (ACL), e é implementada como um filtro de firewall stateless no Junos OS.
Requisitos
Um dispositivo de rede da Juniper conectado a uma rede de gerenciamento. Para ajudar a validar a configuração, deve haver pelo menos um outro dispositivo com acesso à rede de gerenciamento que possa iniciar conexões SSH ou Telnet ao dispositivo em teste (DUT). Nenhuma configuração especial além da inicialização básica de dispositivos (interface de gerenciamento e rota estática relacionada, serviços de sistema, contas de login de usuários e assim por diante), é necessária antes de configurar este exemplo.
Visão geral
Você pode configurar um filtro de firewall para limitar os endereços IP que podem gerenciar um dispositivo. Este filtro de firewall deve incluir um termo para negar todo o tráfego, exceto os endereços IP que podem gerenciar o dispositivo. Você deve aplicar o filtro de firewall na interface de loopback (lo0) para garantir que apenas o tráfego de gerenciamento, ou seja, o tráfego enviado para o próprio dispositivo seja filtrado.
Topologia de exemplo
Figura 1 mostra a topologia para este exemplo. O dispositivo R1 serve como o gateway padrão para a rede de gerenciamento que é atribuída à sub-rede 172.16.0.0/24. Você aplica o filtro que limita o acesso de gerenciamento ao dispositivo R2, tornando-o o DUT neste exemplo. A estação de trabalho remota está autorizada a gerenciar o DUT e recebeu o endereço 10.0.0.1/32.
Neste exemplo, você:
Configure uma lista de prefixo chamada manager-ip. Esta lista define o conjunto de endereços IP que podem gerenciar o dispositivo. Neste exemplo, a lista inclui a própria sub-rede de gerenciamento (172.16.0.0/24) e o endereço IP de um usuário remoto autorizado (10.0.0.1/32).
Configure um filtro limit-mgmt-access de firewall que rejeita todos os endereços de origem , exceto o conjunto específico de endereços definidos manager-ip na lista de prefixo. Isso garante que apenas os endereços IP listados na lista de prefixo podem gerenciar o dispositivo.
Aplique o limit-mgmt-access filtro na interface de loopback. Sempre que um pacote endereçado ao dispositivo local chega em qualquer interface, a interface de loopback aplica o filtro limit-mgmt-access para limitar o acesso de gerenciamento a endereços permitidos apenas.
Configure uma lista de endereços IP para restringir o acesso de gerenciamento a um dispositivo
Procedimento
Configuração rápida da CLI
Para configurar rapidamente este exemplo, edite os seguintes comandos conforme necessário e cole-os na CLI do dispositivo R2 no nível hierárquicos [edit] . Para integridade, a configuração inclui comandos para configurar SSH (para não usuários) e os serviços do sistema Telnet. Ele também fornece a configuração da interface de gerenciamento e rota estática relacionada. Esses comandos não são necessários se o seu dispositivo já tiver essa funcionalidade configurada.
A Telnet não oferece suporte ao login raiz em dispositivos da Juniper Networks. O login SSH para o usuário raiz não está configurado neste exemplo. Seu dispositivo deve ter um usuário não-raiz configurado para permitir o login remoto. Como alternativa, você pode adicionar o root-login allow argumento à declaração para permitir o system services ssh login do usuário raiz usando SSH.
Certifique-se de emitir um commit modo de configuração para ativar as mudanças.
Ao aplicar um filtro que restrinja o acesso ao dispositivo, considere usar commit confirmed. Essa opção reverte automaticamente a configuração se você não conseguir emitir outro compromisso no tempo especificado.
set system services ssh set system services telnet set interfaces fxp0 unit 0 family inet address 172.16.0.253/24 set interfaces lo0 unit 0 family inet address 192.168.255.2/32 set routing-options static route 0.0.0.0/0 next-hop 172.16.0.254 no-readvertise set policy-options prefix-list manager-ip 172.16.0.0/24 set policy-options prefix-list manager-ip 10.0.0.1/32 set firewall filter limit-mgmt-access term block_non_manager from source-address 0.0.0.0/0 set firewall filter limit-mgmt-access term block_non_manager from source-prefix-list manager-ip except set firewall filter limit-mgmt-access term block_non_manager from protocol tcp set firewall filter limit-mgmt-access term block_non_manager from destination-port ssh set firewall filter limit-mgmt-access term block_non_manager from destination-port telnet set firewall filter limit-mgmt-access term block_non_manager then log set firewall filter limit-mgmt-access term block_non_manager then discard set firewall filter limit-mgmt-access term accept_everything_else then accept set interfaces lo0 unit 0 family inet filter input limit-mgmt-access
Procedimento passo a passo
As etapas a seguir exigem que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, veja Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.
Configure as interfaces de gerenciamento e loopback e garanta que os serviços do sistema Telnet e SSH estejam habilitados.
[edit] user@R2# set interfaces fxp0 unit 0 family inet address 172.16.0.253/24 user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32 user@R2# set routing-options static route 0.0.0.0/0 next-hop 172.16.0.254 no-readvertise user@R2# set system services ssh user@R2# set system services telnet
Defina o conjunto de endereços de host permitidos na lista de prefixo. Esta lista inclui prefixos para a sub-rede de gerenciamento e para uma única estação de gerenciamento remoto autorizada.
[edit policy-options] user@R2# set prefix-list manager-ip 172.16.0.0/24 user@R2# set prefix-list manager-ip 10.0.0.1/32
A lista de prefixo é mencionada no filtro de firewall. O uso de uma lista de prefixo facilita a atualização dos endereços que podem acessar o dispositivo. Isso porque apenas a lista de prefixo precisa ser atualizada. Nenhuma edição é necessária para o próprio filtro de firewall ao adicionar ou remover prefixos permitidos.
Configure um filtro de firewall para negar o tráfego de Telnet e SSH de todos os endereços IP , exceto aqueles definidos na lista de prefixo.
[edit firewall filter limit-mgmt-access] user@R2# set term block_non_manager from source-address 0.0.0.0/0 user@R2# set term block_non_manager from source-prefix-list manager-ip except user@R2# set term block_non_manager from protocol tcp user@R2# set term block_non_manager from destination-port ssh user@R2# set term block_non_manager from destination-port telnet user@R2# set term block_non_manager then discard
Observe o uso do modificador de ação
except. O primeiro termo combina com todos os endereços de origem possíveis. O próximo termo inverte a correspondência para esses endereços de origem na lista de prefixo especificada. O resultado é que o tráfego de gerenciamento destinado ao protocolo especificado e às portas só é aceito quando o tráfego vem de um endereço da lista. O tráfego de todos os outros prefixos de origem à mesma combinação de protocolo e portas é descartado. Neste exemplo, uma ação de registro é adicionada para ajudar na depuração e verificação do filtro.Configure um termo padrão para aceitar todos os outros tráfegos. Isso garante que outros serviços e protocolos, por exemplo, pings, BGP ou OSPF, não sejam afetados pelo filtro.
Dica:O filtro de exemplo é permissivo por design. Ele pode representar uma ameaça à segurança, uma vez que aceita explicitamente todo o tráfego que não foi rejeitado ou descartado por termos de filtro anteriores. Você pode configurar um filtro de segurança mais forte listando explicitamente todos os protocolos e serviços que devem ser aceitos terminando o filtro com uma negação de todo o termo, seja implícito ou explicitamente, para filtrar todo o outro tráfego. A desvantagem de um filtro restritivo é que ele deve ser editado cada vez que um serviço suportado é adicionado ou removido.
[edit firewall filter imit-mgmt-access] user@R2# set term accept_everything_else then accept
Aplique o filtro de firewall sem estado na interface de loopback como um filtro de entrada. O tráfego enviado do dispositivo local não é filtrado neste exemplo.
[edit interfaces lo0 unit 0 ] user@R2# set family inet filter input limit-mgmt-access
Resultados
Confirme seu trabalho inserindo os seguintes show configuration comandos do modo de configuração. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.
user@R2# show policy-options
prefix-list manager-ip {
172.16.0.0/24;
10.0.0.1/32;
}
user@R2# show firewall
filter limit-mgmt-access {
term block_non_manager {
from {
source-address {
0.0.0.0/0;
}
source-prefix-list {
manager-ip except;
}
protocol tcp;
destination-port [ ssh telnet ];
}
then {
log;
discard;
}
}
term accept_everything_else {
then accept;
}
}
user@R2# show interfaces
fxp0 {
unit 0 {
family inet {
address 172.16.0.253/24;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
input limit-mgmt-access;
}
address 192.168.255.2/32;
}
}
}
user@R2# show routing-options
static {
route 0.0.0.0/0 {
next-hop 172.16.0.254;
no-readvertise;
}
}
user@R2# show system services ssh; telnet;
Quando satisfeito com seu trabalho, entre no commit modo de configuração.
Ao aplicar um filtro que restrinja o acesso ao dispositivo, considere usar commit confirmed. Essa opção reverte automaticamente a configuração se você não conseguir emitir outro compromisso no tempo especificado.
Verifique o filtro de firewall sem estado
Confirme que o filtro de firewall para limitar o acesso ao gerenciamento está funcionando corretamente.
Verificar pacotes aceitos
Propósito
Verifique se o filtro de firewall permite a SSH e a Telnet corretamente quando o tráfego é originado da sub-rede 172.16.0.0/24 ou do prefixo de host 10.0.1 associado à estação de gerenciamento remoto.
Ação
Libere o log de firewall em seu roteador ou switch.
user@R2> clear firewall log
De um host anexado à sub-rede 172.16.0.0/24, como o dispositivo R1, use o
ssh 172.16.0.253comando para iniciar uma conexão com o DUT. Por padrão, o dispositivo R1 fornece tráfego da interface de saída usada para chegar ao destino. Como resultado, o tráfego de teste é proveniente do endereço 172.16.0.254 da R1. Esse tráfego não corresponde ao block_non_manager termo filtro por causa do modificador deexceptação para endereços compatíveis com a lista de prefixo mencionado. Esse tráfego combina com o accept_everything_else termo filtro, fazendo com que ele seja aceitoNota:Você será solicitado a salvar a chave de host SSH se este for o primeiro login SSH como user entre esses dispositivos.
user@R1>ssh user@172.16.0.253 Password: Last login: Tue Sep 8 09:46:58 2020 from 10.107.199.39 --- JUNOS 20.2R1.10 Kernel 64-bit XEN JNPR-11.0-20200608.0016468_buil user@R2>
Saia do CLI no dispositivo R2 para fechar a sessão de SSH.
user@R2> exit logout Connection to 172.16.0.253 closed. user@R1>
Nota:Repita esta etapa usando o
telnetcomando. A conexão Telnet deve ter sucesso.Use o
show firewall logcomando no dispositivo R2 para verificar se o buffer de log de firewall no dispositivo R2 não contém entradas com endereço fonte na sub-rede 172.16.0.0/24. Isso significa que as informações de cabeçalho de pacotes para este tráfego não estão registradas no log do filtro de firewall. Somente o tráfego que corresponde ao block_non_manager termo está logado neste exemplo.user@R2> show firewall log user@R2>
Significado
A saída confirma que as conexões SSH (e Telnet) são aceitas quando originadas da rede de gerenciamento. Ele também mostra que os pacotes que não correspondem ao block_non_manager termo não estão logados. Os mesmos resultados são esperados se o tráfego SSH ou Telnet for gerado pela estação de gerenciamento remoto que recebe o endereço 10.0.0.1.
Verificar pacotes logados e rejeitados
Propósito
Verifique se o filtro de firewall descarta corretamente o tráfego SSH e Telnet que não se origina de um dos prefixos da lista de manager-ip prefixos.
Ação
Gere tráfego SSH proveniente de um endereço que não está especificado na lista de manager-ip prefixo. Você pode obter a sessão a partir do endereço loopback do dispositivo R1 para simular um IP não autorizado. Como alternativa, inicie a conexão a partir de qualquer dispositivo remoto que não esteja conectado à sub-rede de gerenciamento e que não tenha sido atribuído um endereço IP de 10.0.0.1. Os pacotes para esta sessão de SSH devem ser descartados, e as informações de cabeçalho de pacote devem ser registradas no buffer de log do filtro de firewall.
Nota:Você não deve esperar nenhuma mensagem ou resposta de erro. A tentativa de conexão será demorada. Isso porque o filtro de amostra usa uma ação e não uma
discardrejectação.user@unauthorized-remote-host ssh user@172.16.0.253 ssh: connect to host 172.16.0.253 port 22: Connection timed out
A saída mostra que a conexão SSH não tem sucesso. Isso confirma que o filtro bloqueia corretamente o tráfego SSH quando enviado de um endereço de origem não permitido. O mesmo resultado é esperado para as sessões da Telnet iniciadas por qualquer endereço de origem IP não autorizado.
Use o
show firewall logcomando para verificar se o buffer de log de firewall no dispositivo R2 agora contém entradas para pacotes com um endereço de origem não autorizado.user@R2> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 11:35:46 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253 11:35:14 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253 11:34:58 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253
Significado
A saída confirma que o tráfego do endereço de origem 10.0.119 correspondia a um termo de registro no limit-mgmt-access filtro. Lembre-se que apenas o block_non_manager termo tem uma ação de log neste exemplo. A Action coluna exibe um D para indicar que os pacotes foram descartados. A interface de entrada para o tráfego filtrado está confirmada como a porta fxp0.0 de gerenciamento do dispositivo. O protocolo TCP de transporte e os endereços IP dos pacotes filtrados também são mostrados. Observe que o endereço 10.0.0.119 fonte para este tráfego não está listado na lista de manager-ip prefixo.
Esses resultados confirmam que o filtro de firewall está funcionando corretamente para este exemplo.