Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Visão geral do acesso remoto

Você (o administrador de rede) pode acessar um roteador, switch ou dispositivo de segurança remotamente usando serviços como DHCP, Finger, FTP, rlogin, SSH e serviços Telnet. Este tópico mostra como configurar o acesso remoto usando os serviços Telnet, SSH, FTP e Finger.

Visão geral dos serviços de sistema

Por motivos de segurança, o acesso remoto ao roteador é desativado por padrão. Você deve configurar o roteador explicitamente para que os usuários em sistemas remotos possam acessá-lo. Os usuários podem acessar o roteador a partir de um sistema remoto por meio dos serviços DHCP, finger, FTP, rlogin, SSH e Telnet. Além disso, os aplicativos de cliente de protocolo Junos XML podem usar o Secure Sockets Layer (SSL) ou o serviço de texto claro específico para protocolo Junos XML, entre outros serviços.

Nota:

Para proteger os recursos do sistema, você pode limitar o número de conexões simultâneas que um serviço aceita e o número de processos de propriedade de um único usuário. Se qualquer limite for excedido, as tentativas de conexão falharão.

Configure o serviço Telnet para acesso remoto a um roteador ou switch

Para configurar o roteador ou switch para aceitar a Telnet como um serviço de acesso, inclua a declaração no nível de hierarquia:telnet[edit system services]

Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões de Telnet simultâneas e tentativas de conexão por minuto.

Opcionalmente, você pode incluir as duas declarações a seguir para alterar os padrões:

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPV4 e IPv6). A faixa é de 1 a 250. O padrão é 75. Quando você configura um limite de conexão, o limite é aplicável ao número de sessões de telnet por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões de telnet IPv6 e 10 sessões de telnet IPv4.

  • rate-limit limit— Número máximo de tentativas de conexão aceitas por minuto (de 1 a 250). O padrão é 150. Quando você configura um limite de taxa, o limite é aplicável ao número de tentativas de conexão por protocolo (IPv4 e IPv6). Por exemplo, um limite de taxa de 10 permite 10 tentativas de conexão de sessão de telnet IPv6 por minuto e 10 tentativas de conexão de sessão de telnet IPv4 por minuto.

Você não pode incluir a declaração em dispositivos que executam o software Junos-FIPS.telnet Recomendamos que você não use a Telnet em um ambiente de critérios comuns.

Configure o serviço FTP para acesso remoto ao roteador ou switch

Para configurar o dispositivo para aceitar o FTP como um serviço de acesso, inclua a declaração no nível de hierarquia:ftp[edit system services]

Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões simultâneas de FTP e tentativas de conexão por minuto. Você pode incluir ou ambas as seguintes declarações para alterar os padrões:

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPV4 e IPv6). A faixa é um valor de 1 a 250. O padrão é 75. Quando você configura um limite de conexão, o limite é aplicável ao número de sessões por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões de FTP IPv6 e 10 sessões de FTP IPv4.

  • rate-limit limit— Número máximo de tentativas de conexão aceitas por minuto (um valor de 1 a 250). O padrão é 150. Quando você configura um limite de taxa, o limite é aplicável ao número de tentativas de conexão por protocolo (IPv4 e IPv6). Por exemplo, um limite de taxa de 10 permite 10 tentativas de conexão de sessão DE FTP IPv6 e 10 tentativas de conexão de sessão FTP IPv4.

Você pode usar FTP passivo para acessar dispositivos que aceitam apenas serviços FTP passivos. Todos os comandos e declarações que usam FTP também aceitam FTP passivo. Inclua a declaração no nível de hierarquia para usar FTP ativo ou FTP passivo.ftp[edit system services]

Para iniciar uma sessão de FTP passiva, use (em vez de ) no formato FTP padrão ().pasvftpftpftp://destination Por exemplo:

Você não pode incluir a declaração em roteadores ou switches que executam o software Junos-FIPS.ftp Recomendamos que você não use o serviço FTP em um ambiente de critérios comuns.

Configure o serviço Finger para acesso remoto ao roteador

Para configurar o roteador para aceitar o dedo como um serviço de acesso, inclua a declaração no nível de hierarquia:finger[edit system services]

Por padrão, o roteador oferece suporte a um número limitado de sessões simultâneas de dedos e tentativas de conexão por minuto. Opcionalmente, você pode incluir as duas declarações a seguir para alterar os padrões:

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPv4 e IPv6). A faixa é um valor de 1 a 250. O padrão é 75. Quando você configura um limite de conexão, o limite é aplicável ao número de sessões por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões de serviço de texto claro IPv6 e 10 sessões de serviço de texto claro IPv4

  • rate-limit limit— Número máximo de tentativas de conexão aceitas por minuto (um valor de 1 a 250). O padrão é 150. Quando você configura um limite de taxa, o limite é aplicável ao número de tentativas de conexão por protocolo (IPv4 e IPv6). Por exemplo, um limite de taxa de 10 permite 10 tentativas de conexão de sessão IPv6 por minuto e 10 tentativas de conexão de sessão IPv4 por minuto.

Você não pode incluir a declaração em roteadores que executam o software Junos-FIPS.finger Recomendamos que você não use o serviço de dedos em um ambiente de critérios comuns.

Configure o serviço SSH para acesso remoto ao roteador ou switch

Para configurar o roteador ou switch para aceitar o SSH como um serviço de acesso, inclua a declaração no nível de hierarquia:ssh[edit system services]

Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões de SSH simultâneas e tentativas de conexão por minuto. Use as seguintes declarações para alterar os padrões:

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPv4 e IPv6). A faixa é um valor de 1 a 250. O padrão é 75. Quando você configura um limite de conexão, o limite é aplicável ao número de sessões de SSH por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões de SSH IPv6 e 10 sessões de SSH IPv4.

  • max-sessions-per-connection number— Inclua esta declaração para especificar o número máximo de sessões de SSH permitidas por uma única conexão SSH. Isso permite limitar o número de sessões clonadas em tunelamento em uma única conexão SSH. O valor padrão é de 10.

  • rate-limit limit— Número máximo de tentativas de conexão aceitas por minuto (um valor de 1 a 250). O padrão é 150. Quando você configura um limite de taxa, o limite é aplicável ao número de tentativas de conexão por protocolo (IPv4 e IPv6). Por exemplo, um limite de taxa de 10 permite 10 tentativas de conexão de sessão SSH IPv6 por minuto e 10 tentativas de conexão de sessão SSH IPv4 por minuto.

  • data-limit— Limite de dados antes de renegociar chaves de sessão (bytes)

  • time-limit— Limite de tempo antes de renegociar chaves de sessão (minutos)

A partir do Junos OS Release 19.4R1 e Junos OS Release 17.4R3, você pode desabilitar a senha de login SSH ou a autenticação de resposta ao desafio usando o nível de hierarquia e opções.no-password-authenticationno-challenge-responseedit system services ssh

Por padrão, um usuário pode criar um túnel SSH em uma sessão de CLI para um roteador que executa o Junos OS via SSH. Esse tipo de túnel pode ser usado para encaminhar o tráfego TCP, ignorando quaisquer filtros de firewall ou listas de controle de acesso. Ao ignorar filtros de firewall ou listas de controle de acesso, esse tipo de túnel permite o acesso a recursos além do roteador. Use a opção para impedir que um usuário crie um túnel SSH para um roteador via SSH.no-tcp-forwarding

Para obter informações sobre outras configurações de configuração, veja os seguintes tópicos:

Configure o login raiz através do SSH

Por padrão, os usuários podem fazer login no roteador ou switch como por SSH quando o método de autenticação não exigir uma senha.root Para controlar o acesso do usuário através do SSH, inclua a declaração no nível de hierarquia:root-login[edit systems services ssh]

allow— permite que os usuários façam login no roteador ou switch como raiz através do SSH.

deny— Desativa os usuários de fazer login no roteador ou switch como raiz através do SSH.

-— permite que os usuários façam login no roteador ou switch como raiz através do SSH quando o método de autenticação (por exemplo, RSA) não requer uma senha.denypassword

O padrão é .deny-password

Configure as próximas conexões SFTP

O SSH File Transfer Protocol (SFTP) é um protocolo de rede que fornece acesso a arquivos, transferência de arquivos e gerenciamento de arquivos em qualquer fluxo de dados confiável. A partir do Junos OS Release 19.1R1, desabilitamos globalmente as conexões SFTP de entrada por padrão. Se desejado, você pode habilitar globalmente as próximas conexões SFTP configurando a declaração no nível hierárquica .sftp-server[edit system services ssh] Antes do Junos OS Release 19.1R1, as conexões SFTP de entrada eram habilitadas globalmente por padrão.

Nota:

Apenas as conexões SFTP de entrada são desabilitadas por padrão. Por exemplo, dado os dispositivos A e B (onde o dispositivo A está sendo executado 19.1R1), você não pode se conectar através do SFTP de B a A por padrão. No entanto, você pode se conectar através do SFTP do dispositivo B ao dispositivo A se você configurar no dispositivo A. sftp-server

As conexões SFTP de entrada são desativadas por padrão. Para permitir conexões SFTP de entrada:

  1. Configure a declaração no nível de hierarquia:sftp-server[edit system services ssh]
  2. Confirmar a configuração.

    A declaração agora está ativa.sftp-server Portanto, as conexões SFTP de entrada estão habilitadas.

Configure a versão do protocolo SSH

Por padrão, apenas a versão 2 do protocolo SSH está habilitada.

Para configurar o roteador ou switch para usar a versão 2 do protocolo SSH, inclua a declaração e especifique no nível de hierarquia:protocol-versionv2[edit system services ssh]

Os sistemas no modo FIPS usam sempre a versão de protocolo SSH.v2

Configure o mecanismo Client Alive

O mecanismo de vida do cliente é valioso quando o cliente ou servidor depende de saber quando uma conexão se tornou inativa. Ela difere do mecanismo keepalive padrão porque as mensagens vivas do cliente são enviadas pelo canal criptografado. O mecanismo de vida do cliente não é habilitado por padrão. Para habilitá-la, configure as declarações e as declarações.client-alive-count-maxclient-alive-interval Essa opção se aplica apenas ao protocolo SSH versão 2.

No exemplo a seguir, os clientes SSH sem resposta serão desconectados após aproximadamente 100 segundos (20 x 5):

Configure o algoritmo de hash de impressão digital SSH

Para configurar o algoritmo de hash usado pelo servidor SSH quando ele exibe as principais impressões digitais, inclua a declaração e especifique ou no nível de hierarquia:fingerprint-hashmd5sha2-256[edit system services ssh]

O algoritmo de hash não está disponível em sistemas no modo FIPS.md5

Visão geral da autenticação baseada em certificadoSH

A partir do Junos OS e junos OS Evolved Release 22.4R1, você pode configurar a autenticação baseada em certificadoS SSH para usuários e hosts. Esse recurso permite estabelecer acesso SSH sem senha para usuários e hosts de confiança sem verificar as principais impressões digitais.

Benefícios da autenticação baseada em certificados SSH

  • A autenticação baseada em certificadoSH elimina a necessidade de os usuários lembrarem e inserirem senhas, agilizando o processo de login.

  • Em comparação com as abordagens tradicionais baseadas em senha, os certificados SSH oferecem uma segurança mais forte. Eles são mais difíceis de violar sem senha para adivinhar ou quebrar.

  • Os certificados SSH simplificam o gerenciamento das chaves de autenticação. Em vez de gerenciar as chaves individuais para cada usuário e host, os administradores podem emitir e revogar certificados de uma autoridade de certificado centralizada.

Gerando chaves de assinatura

As chaves de assinatura são chaves criptográficas especializadas usadas na autenticação baseada em certificados SSH. O primeiro passo para configurar a autenticação baseada em certificados SSH é gerar chaves de assinatura. Você pode gerar chaves de assinatura em qualquer sistema Linux/FreeBSD. Siga essas etapas para gerar chaves de assinatura para autenticação baseada em certificado SSH:

  1. Execute o comando: ssh-keygen -f <filename_ca>. Isso criará uma chave privada nomeada e uma chave pública correspondente nomeada .<filename_ca><filename_ca.pub>

  2. Faça login no seu dispositivo Juniper e configure o arquivo-chave SSH Trusted User Certificate Authority (CA), executando o comando: set system services ssh trusted-user-ca-key-file <path-to-public-key> e então confirmar a configuração.

  3. Cada usuário pode gerar suas próprias chaves de usuário usando o seguinte comando CLI: ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. Copie a chave pública criada pelo usuário na máquina que tem os certificados de usuário e .<filename_ca><filename_ca.pub>

  5. Assine a chave pública do usuário no arquivo.<filename_ca.pub>

Configuração

Para configurar a autenticação baseada em certificado SSH, use as seguintes declarações de configuração de CLI:

  • — Configure o arquivo em , que contém as chaves públicas de um certificado SSH.[system services ssh trusted-user-ca-key-file filename]TrustedUserCAKey/etc/ssh/sshd_config

  • — Configure o arquivo em , que contém o certificado de host assinado.[system services ssh host-certificate-file filename]HostCertificate/etc/ssh/sshd_config

  • — Configure o arquivo em , que contém uma lista de nomes, um dos quais deve aparecer no certificado para que ele seja aceito para autenticação.[system services ssh authorized-principals-file filename]AuthorizedPrincipals/var/etc

  • — Especifique um programa a ser usado para gerar a lista de diretores de certificados permitidos encontrados no arquivo.[system services ssh authorized-principals-command program-path]AuthorizedPrincipals

O comando telnet

Você pode usar o comando CLI para abrir uma sessão de Telnet a um dispositivo remoto:telnet

Nota:

Nos dispositivos SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 e SRX1500, o número máximo de sessões simultâneas da Telnet é indicado na tabela a seguir. O suporte da plataforma depende da versão do Junos OS em sua instalação.

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Para sair da sessão da Telnet e retornar ao prompt de comando telnet, pressione Ctrl-].

Para sair da sessão da Telnet e retornar ao prompt de comando CLI, entre .quit

Tabela 1: Opções de comando de telnet CLI

Option

Descrição

8bit

Use um caminho de dados de 8 bits.

bypass-routing

Contorne as tabelas de roteamento e abra uma sessão da Telnet apenas para hosts em interfaces diretamente anexadas. Se o host não estiver em uma interface diretamente anexada, uma mensagem de erro será devolvida.

host

Abra uma sessão da Telnet para o nome de host ou endereço IP especificado.

inet

Force a sessão da Telnet a um destino IPv4.

interface source-interface

Abra uma sessão da Telnet para um host na interface especificada. Se você não incluir essa opção, todas as interfaces serão usadas.

no-resolve

Suprime a exibição de nomes simbólicos.

port port

Especifique o número de porta ou o nome do serviço no host.

routing-instance routing-instance-name

Use a instância de roteamento especificada para a sessão da Telnet.

source address

Use o endereço fonte especificado para a sessão da Telnet.

O comando ssh

Você pode usar o comando CLI para usar o programa secure shell (SSH) para abrir uma conexão a um dispositivo remoto:ssh

Nota:

Nos dispositivos SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 e SRX1500, o número máximo de sessões de SSH simultâneas é indicado na tabela a seguir. O suporte da plataforma depende da versão do Junos OS em sua instalação.

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Tabela 2 descreve as opções de comando.ssh

Tabela 2: Opções de comando ssh CLI

Option

Descrição

bypass-routing

Contorne as tabelas de roteamento e abra uma conexão SSH apenas para hosts em interfaces diretamente anexadas. Se o host não estiver em uma interface diretamente anexada, uma mensagem de erro será devolvida.

host

Abra uma conexão SSH com o nome de host ou endereço IP especificado.

inet

Force a conexão SSH a um destino IPv4.

interface source-interface

Abra uma conexão SSH a um host na interface especificada. Se você não incluir essa opção, todas as interfaces serão usadas.

routing-instance routing-instance-name

Use a instância de roteamento especificada para a conexão SSH.

source address

Use o endereço de origem especificado para a conexão SSH.

v1

Force o SSH a usar a versão 1 para a conexão.

v2

Force o SSH a usar a versão 2 para a conexão.

Configure as chaves de host conhecidas do SSH para uma cópia segura dos dados

O Secure Shell (SSH) usa algoritmos de criptografia para gerar um sistema de host, servidor e chave de sessão que garante uma transferência segura de dados. Você pode configurar as chaves de host SSH para oferecer suporte a cópia segura (SCP) como uma alternativa ao FTP para a transferência de dados em segundo plano, como arquivos de configuração e logs de eventos. Para configurar o suporte de SSH para SCP, você deve concluir as seguintes tarefas:

  • Especifique hosts conhecidos do SSH, incluindo nomes de host e informações chave do host na hierarquia de configuração do Mecanismo de Roteamento.

  • Configure uma URL SCP para especificar o host a partir do qual receber dados. Definir esse atributo recupera automaticamente as informações chave do host SSH do servidor SCP.

  • Verifique se a chave do host é autentica.

  • Aceite a conexão segura. Aceitar essa conexão armazena automaticamente as principais informações de host no banco de dados da chave do host local. Armazenar informações chave do host na hierarquia de configuração automatiza o uso seguro e permite a transferência de dados em segundo plano usando SCP.

As tarefas para configurar as chaves do host SSH para uma cópia segura dos dados são:

Configure hosts conhecidos de SSH

Para configurar hosts conhecidos de SSH, inclua a declaração e especifique opções de nome de host e host para servidores confiáveis no nível de hierarquia:host[edit security ssh-known-hosts]

As chaves do host são uma das seguintes:

  • dsa-key key— Algoritmo de assinatura digital codificado (DSA) base64 para SSH versão 2.

  • ecdsa-sha2-nistp256-key key— Chave da ECDSA-SHA2-NIST256 codificada base64.

  • ecdsa-sha2-nistp384-key key— Chave da ECDSA-SHA2-NIST384 codificada base64.

  • ecdsa-sha2-nistp521-key key— Chave da ECDSA-SHA2-NIST521 codificada base64.

  • ed25519-key key— Chave de ED25519 codificada base64.

  • rsa-key key— Algoritmo de chave pública codificado base64 que oferece suporte a criptografia e assinaturas digitais para SSH versão 1 e SSH versão 2.

  • rsa1-key key— Algoritmo de chave pública RSA codificado pela Base64, que oferece suporte a criptografia e assinaturas digitais para SSH versão 1.

Configure o suporte para transferência de arquivos SCP

Para configurar um host conhecido para oferecer suporte a transferências de arquivos SCP de fundo, inclua a declaração no nível de hierarquia.archive-sites[edit system archival configuration]

Nota:

Ao especificar uma URL em uma declaração usando um endereço de host IPv6, você deve incluir toda a URL entre aspas (&quot; &quot;) e desativar o endereço de host IPv6 em parênteses ([]).Junos OS Por exemplo, “scp://username<:password>@[host]<:port>/url-path”;

Definir a declaração para apontar para uma URL SCP aciona a recuperação automática da chave do host.archive-sites Neste ponto, conecta-se ao host SCP para buscar a chave pública SSH, exibe a digestão da mensagem chave do host ou a impressão digital como saída para o console e encerra a conexão com o servidor.Junos OS

Para verificar se a chave do host é autentica, compare esta impressão digital com uma impressão digital que você obtém do mesmo host usando uma fonte confiável. Se as impressões digitais forem idênticas, aceite a chave do host entrando no prompt.yes As informações chave do host são então armazenadas na configuração do Mecanismo de Roteamento e suportam transferências de dados em segundo plano usando SCP.

Atualizar as informações principais do host SSH

Normalmente, as informações chave do host SSH são recuperadas automaticamente quando você define um atributo de URL para SCP usando a declaração no nível de hierarquia.archival configuration archive-sites[edit system] No entanto, se você precisar atualizar manualmente o banco de dados da chave do host, use um dos seguintes métodos.

Recuperar as informações da chave do host manualmente

Para recuperar manualmente as informações de chave do host público SSH, configure a opção no nível de hierarquia.fetch-from-server[edit security ssh-known-hosts] Você deve especificar o host a partir do qual recuperar a chave pública SSH.

Importar informações chave do host de um arquivo

Para importar manualmente as informações chave do host SSH de um arquivo, inclua a opção no nível de hierarquia.known_hostsload-key-file[edit security ssh-known-hosts] Você deve especificar o caminho até o arquivo a partir do qual importar informações chave do host.

Configure o serviço SSH para oferecer suporte a criptografia legado

O servidor SSH é baseado no Junos OS OpenSSH 7 e é padrão para um conjunto mais seguro de cifras e algoritmos de troca de chaves. O OpenSSH 7 omite algumas criptografias legadas.

Nota:

A falta de suporte para criptografia legadas em dispositivos faz com que a descoberta do dispositivo Junos Space seja reprovada. Para resolver esse problema, configure o dispositivo para oferecer suporte à cifra, ou ambos, e ao método de troca de chaves.3des-cbcblowfish-cbcdh-group1-sha1 Esse problema não afeta dispositivos que executam o Junos OS com FreeBSD atualizado.

Nota:

Consulte a documentação do OpenSSH 7 em https://www.openssh.com/ para obter mais informações sobre essas extensões.https://www.openssh.com/

Junos OS oferece suporte ao seguinte conjunto de cifras por padrão:

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

Em , as cifras a seguir não são suportadas por padrão, mas você pode configurar o seu dispositivo para dar suporte a eles.Junos OS Eles estão listados dos mais seguros aos menos seguros:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

  • 3des-cbc

  • blowfish-cbc

  • cast128-cbc

  • arcfour256

  • arcfour128

  • arcfour

Junos OS oferece suporte ao seguinte conjunto de métodos de troca de chaves por padrão:

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

Em , os seguintes métodos de troca de chave não são suportados por padrão, mas você pode configurar o seu dispositivo para dar suporte a eles:Junos OS

  • group-exchange-sha1

  • dh-group1-sha1

Para configurar o serviço SSH para oferecer suporte a criptografia legadas:

Nota:

Ao configurar um conjunto ordenado de cifras, métodos de troca de chaves ou códigos de autenticação de mensagens (MACs), o conjunto recém-definido é aplicado a comandos de servidor e cliente. Alterações nos padrões afetam o comando quando você usa o Secure Copy Protocol (SCP).file copy

  1. Adicione suporte para cifras usando o comando.set system services ssh ciphers [ cipher 1 cipher 2 ... ] Recomendamos que você adicione as cifras ao final da lista de configuração para que elas estejam entre as últimas opções usadas. No exemplo a seguir, as cifras e as cifras são adicionadas ao conjunto padrão:arcfourblowfish-cbc
  2. Adicione suporte aos métodos de troca de chaves usando o comando.set system services ssh key-exchange [ method 1 method 2 ... ] Recomendamos que você adicione os métodos de troca de chaves ao fim da lista de configuração para que eles estejam entre as últimas opções usadas. No exemplo a seguir, o método de troca de chaves é adicionado ao conjunto padrão:dh-group1-sha1
  3. Confirmar a configuração:

Consulte também

Configure o serviço SSH de saída

Você pode configurar um dispositivo em execução Junos OS para iniciar uma conexão TCP/IP com um aplicativo de gerenciamento de clientes. Se o aplicativo de gerenciamento não alcançar um dispositivo da Juniper Networks, por exemplo, o dispositivo será um firewall. Nesses casos, pode ser configurado no dispositivo da Juniper Networks.outbound-ssh Uma configuração inicia uma conexão SSH reversa do servidor ao cliente até o aplicativo de gerenciamento.outbound-ssh Essa conexão SSH de saída só é fechada após a configuração ser removida do dispositivo.

Nota:

Não há comando de iniciação com SSH de saída. Depois de configurar e confirmar SSH de saída, o dispositivo começa a iniciar uma conexão SSH de saída com base na configuração comprometida. O dispositivo tenta repetidamente criar essa conexão até ser bem sucedido. Se a conexão entre o dispositivo e o aplicativo de gerenciamento do cliente for perdida, o dispositivo novamente tenta criar uma nova conexão SSH de saída até ser bem-sucedido. Essa conexão é mantida até que a estrofe SSH de saída seja removida da configuração.

Para configurar o dispositivo para conexões SSH de saída, inclua a declaração no nível de hierarquia:outbound-ssh[edit system services]

[]edit system services outbound-ssh

Os tópicos a seguir descrevem as tarefas para configurar o serviço SSH de saída.

Envie a chave de host SSH pública para o cliente SSH de saída

Cada vez que o roteador ou switch estabelece uma conexão SSH de saída, ele primeiro envia uma sequência de iniciação para o cliente de gerenciamento. Essa sequência identifica o roteador ou o switch para o cliente de gerenciamento. Nesta transmissão há o valor de .device-id

Para configurar o identificador de dispositivo do roteador ou switch, inclua a declaração no nível hierárquico:device-id[edit system services outbound-ssh client client-id]

A sequência de iniciação quando não está configurada:secret

Durante a inicialização de uma conexão SSH, o cliente autentica a identidade do dispositivo usando a chave de host SSH pública do dispositivo. Portanto, antes que o cliente possa iniciar a sequência de SSH, o cliente precisa da chave SSH pública do dispositivo. Ao configurar a declaração, o dispositivo passa sua chave SSH pública como parte da sequência de iniciação da conexão SSH de saída.secret

Quando a declaração é definida e o dispositivo estabelece uma conexão SSH de saída, o dispositivo comunica seu ID de dispositivo, sua chave SSH pública e um hash SHA1 derivado em parte da declaração.secretsecret O valor da declaração é compartilhado entre o dispositivo e o cliente de gerenciamento.secret O cliente usa o segredo compartilhado para autenticar a chave pública do host SSH que está recebendo para determinar se a chave pública é do dispositivo identificado pela declaração.device-id

Usar a declaração para transportar a chave de host SSH pública é opcional.secret Você pode transportar e instalar manualmente a chave pública no sistema do cliente.

Nota:

Incluir a declaração significa que o dispositivo envia a chave de host SSH pública toda vez que estabelece uma conexão com o cliente.secret Cabe então ao cliente decidir o que fazer com a chave de host SSH se o cliente já tiver uma chave SSH para esse dispositivo. Recomendamos que você substitua a cópia do cliente da chave de host SSH pela nova chave. As chaves do host podem mudar por vários motivos. Substituindo a chave cada vez que uma conexão for estabelecida, você garante que o cliente tenha a chave mais recente.

Para enviar a chave de host SSH pública do roteador ou switch quando o dispositivo se conectar ao cliente, inclua a declaração no nível hierárquico:secret[edit system services outbound-ssh client client-id]

A mensagem a seguir é enviada pelo dispositivo quando o atributo está configurado:secret

Configure mensagens keepalive para conexões SSH de saída

Depois que o aplicativo cliente tiver a chave de host SSH pública do roteador ou switch, ele pode iniciar a sequência de SSH como se tivesse criado a conexão TCP/IP. O cliente pode então autenticar o dispositivo usando sua cópia da chave SSH de host público do roteador ou switch como parte dessa sequência. O dispositivo autentica o usuário cliente através dos mecanismos suportados (autenticação pública de string ou senha RSA/DSA).Junos OS

Para permitir que o dispositivo envie mensagens keepalives de protocolo SSH ao aplicativo do cliente, configure a declaração no nível hierárquica:keep-alive[edit system services outbound-ssh client client-id]

Configure uma nova conexão SSH de saída

Quando desconectado, o dispositivo começa a iniciar uma nova conexão SSH de saída. Para especificar como o dispositivo se reconecta ao servidor após a queda de uma conexão, inclua a declaração no nível de hierarquia:reconnect-strategy[edit system services outbound-ssh client client-id]

Você também pode especificar o número de tentativas de tentativas de nova tentativa e definir a quantidade de tempo antes que as tentativas de reconexão parem. Veja .Configure mensagens keepalive para conexões SSH de saída

Configure o cliente SSH de saída para aceitar o NETCONF como um serviço disponível

Para configurar o aplicativo para aceitar o NETCONF como um serviço disponível, inclua a declaração no nível de hierarquia:services netconf[edit system services outbound-ssh client client-id]

Configure clientes SSH de saída

Para configurar os clientes disponíveis para essa conexão SSH de saída, liste cada cliente com uma declaração de endereço separada no nível de hierarquia:[edit system services outbound-ssh client client-id]

Nota:

As conexões SSH de saída oferecem suporte a formatos de endereço IPv4 e IPv6.

Configure instâncias de roteamento para clientes SSH de saída

Para usar a instância de roteamento de gerenciamento, primeiro habilite a instância de roteamento usando o comando.mgmt_junosset system management-instance

Para usar qualquer outra instância de roteamento, configure primeiro a instância de roteamento na hierarquia.[edit routing-instances]

Se você não especificar uma instância de roteamento, seu dispositivo estabelecerá a conexão SSH de saída usando a tabela de roteamento padrão.

Configure conexões NETCONF-Over-SSH em uma porta TCP especificada

Junos OS permite restringir as conexões NETCONF de entrada a uma porta TCP especificada sem configurar um firewall. Para configurar a porta TCP usada para conexões NETCONF-over-SSH, inclua a declaração no nível de hierarquia.port[edit system services netconf ssh] A porta configurada aceita apenas sessões NETCONF-over-SSH. As solicitações regulares de sessão de SSH para esta porta são indeferidas.

Você pode configurar a porta padrão 830 para conexões NETCONF em SSH, conforme especificado no RFC 4742, usando o protocolo de configuração NETCONF sobre Secure Shell (SSH)ou configurar qualquer porta de 1 a 65535.

Nota:

  • A porta SSH padrão (22) continua a aceitar sessões de NETCONF mesmo com uma porta de servidor NETCONF configurada. Para desabilitar a porta SSH de aceitar sessões netconf, especifique isso no script de eventos de login.

  • Não recomendamos configurar as portas padrão para serviços FTP (21) e Telnet (23) para configurar conexões NETCONF-over-SSH.

Configure limites de tentativa de senha para acesso à Telnet e SSH

Para evitar ataques de força bruta e de sinuosos, um dispositivo executa as seguintes ações para sessões de Telnet ou SSH por padrão:

  • Desconecta uma sessão após um máximo de 10 retries de senha consecutivas.

  • Após a nova tentativa da segunda senha, introduz um atraso em vários de 5 segundos entre as retries de senha subseqüentes.

    Por exemplo, o dispositivo introduz um atraso de 5 segundos entre a terceira e a quarta tentativa de senha, um atraso de 10 segundos entre a quarta e a quinta tentativa de senha e assim por diante.

  • Impõe um tempo mínimo de sessão de 20 segundos, durante o qual uma sessão não pode ser desconectada. A configuração do tempo mínimo de sessão impede que usuários mal-intencionados desconectem sessões antes que o atraso na nova tentativa de senha entre em vigor. A configuração do tempo mínimo de sessão também os impede de tentar ataques de força bruta e de cookies com vários logins.

Você pode configurar os limites de tentativa de nova senha para acesso à Telnet e SSH. Neste exemplo, você configura o dispositivo para tomar as seguintes ações para sessões de Telnet e SSH:

  • Permita um máximo de quatro tentativas de senha consecutivas antes de desconectar uma sessão.

  • Introduza um atraso em vários de 5 segundos entre as retries de senha que ocorrem após a nova tentativa da segunda senha.

  • Aplique um tempo mínimo de sessão de 40 segundos, durante o qual uma sessão não pode ser desconectada.

Para configurar limites de tentativa de nova senha para acesso à Telnet e SSH:

  1. Defina o número máximo de retries de senha consecutivas antes que uma sessão de Telnet ou SSH ou telnet seja desconectada. O número padrão é , mas você pode definir um número de até .10110
  2. Definir o número limite de retries de senha após o qual um atraso é introduzido entre duas retries de senha consecutivas. O número padrão é , mas você pode especificar um valor de até .213
  3. Defina o atraso (em segundos) entre as repetições consecutivas de senha após o número limite de retries de senha. O atraso padrão é em vários segundos , mas você pode especificar um valor de segundos a segundos.5510
  4. Defina o tempo mínimo (em segundos) durante o qual uma sessão de Telnet ou SSH não pode ser desconectada. O padrão é segundos, mas você pode especificar um intervalo de segundos a segundos.202060
  5. Depois de configurar o dispositivo, entre no modo de configuração.commit

Exemplo: Configure um filtro para bloquear o acesso à Telnet e SSH

Requisitos

Você precisa de dois dispositivos em execuçãoJunos OS com um link de rede compartilhado. Nenhuma configuração especial além da inicialização básica de dispositivos (interface de gerenciamento, acesso remoto, contas de login do usuário etc.) é necessário antes de configurar este exemplo. Embora não seja um requisito rigoroso, o acesso ao console ao dispositivo R2 é recomendado.

Nota:

Nossa equipe de testes de conteúdo validou e atualizou este exemplo.

Visão geral e topologia

Neste exemplo, você cria um filtro de firewall stateless IPv4 que registra e rejeita pacotes Telnet ou SSH enviados ao mecanismo de roteamento local, a menos que o pacote se o origine da sub-rede 192.168.1.0/30 . O filtro é aplicado à interface de loopback para garantir que apenas o tráfego destinado ao dispositivo local seja afetado. Você aplica o filtro na direção de entrada. Um filtro de saída não é usado. Como resultado, todo o tráfego gerado localmente é permitido.

  • Para combinar pacotes originados de uma sub-rede específica ou prefixo IP, você usa a condição de correspondência IPv4 aplicada na direção de entrada.source-address

  • Para combinar pacotes destinados à porta Telnet e portas SSH, você usa a condição de correspondência combinada com condições de correspondência IPv4 e aplicadas na direção de entrada.protocol tcpport telnetport ssh

Topologia de exemplo

Figura 1 mostra a topologia de teste para este exemplo. O filtro de firewall é aplicado ao dispositivo R2, tornando-o o dispositivo em teste (DUT). O R1 e os dispositivos R2 compartilham um link que é atribuído a uma sub-rede de 192.168.1.0/30. Ambos os dispositivos têm endereços de loopback atribuídos a partir do prefixo 192.168.255.0/30 usando uma máscara de sub-rede /32. Rotas estáticas oferecem acessibilidade entre endereços de loopback porque um protocolo de gateway interior não está configurado neste exemplo básico.

Figura 1: Topologia de exemploTopologia de exemplo

Configuração

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração.Use o editor de CLI no modo de configuração

CUIDADO:

Ao projetar o filtro de amostra, o acesso de Telnet e SSH ao R2, a menos que se origine da sub-rede compartilhada na R1. Se você usar SSH ou Telnet para acessar diretamente o dispositivo R2, você perderá a conectividade quando o filtro for aplicado. Recomendamos que você tenha acesso ao console ao configurar este exemplo. Se necessário, você pode usar o dispositivo R1 como um host de salto para lançar uma sessão de SSH ao R2 após a aplicação do filtro. Alternativamente, considere modificar o filtro de amostra para também permitir que a sub-rede IP atribuída à máquina que você usa acesse o dispositivo R2.

Execute as seguintes tarefas para configurar este exemplo:

Configuração rápida da CLI

Configuração rápida para o dispositivo R1

Para configurar rapidamente o dispositivo R1, edite os seguintes comandos conforme necessário e cole-os no CLI no nível de hierarquia.[edit] Certifique-se de emitir um modo de configuração para ativar as mudanças.commit

Configuração rápida para o dispositivo R2

Para configurar rapidamente o dispositivo R2, edite os seguintes comandos conforme necessário e cole-os no CLI no nível de hierarquia.[edit] Certifique-se de emitir um modo de configuração para ativar as mudanças.commit

Dica:

Considere usar ao fazer alterações que possam afetar o acesso remoto ao seu dispositivo.commit-confirmed Ativando uma configuração do Junos OS, mas exigindo confirmação

Configure o dispositivo R1

Procedimento passo a passo

Siga essas etapas para configurar o dispositivo R1:

  1. Configure as interfaces:

  2. Configure o nome do host e a rota estática para o endereço loopback do dispositivo R2. Você também configura o acesso à Telnet e SSH:

Verifique e confirme a configuração no dispositivo R1

Procedimento passo a passo

Preencha as seguintes etapas para verificar e comprometer a configuração do candidato no dispositivo R1:

  1. Confirme a configuração da interface com o comando do modo de configuração.show interfaces Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

  2. Verifique a rota estática usada para alcançar o endereço loopback do dispositivo R2 e se o acesso SSH e Telnet está habilitado. Use os comandos do modo e configuração.show routing-optionsshow system services Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

  3. Quando satisfeito com a configuração no dispositivo R1, comprometa a configuração do seu candidato.

Configure o dispositivo R2

Procedimento passo a passo

Preencha as seguintes etapas para configurar o dispositivo R2. Você começa definindo o filtro de firewall sem estado que bloqueia seletivamente o acesso à Telnet e ao SSH:

  1. Posicione-se na hierarquia:edit firewall family inet filter local_acl

  2. Definir o termo filtro.terminal_access Este termo permite que a Telnet e a SSH a partir do(s) prefixo(s) de origem especificado:

  3. Definir o termo filtro.terminal_access_denied Este termo rejeita SSH e Telnet de todos os outros endereços de origem. Este termo é configurado para registrar correspondências ao termo e gerar uma resposta explícita do Protocolo de Mensagem de Controle de Internet (ICMP) de volta à fonte do pacote. Veja ações de registro de filtros de firewall para obter detalhes sobre opções de registro de filtros.Firewall Filter Logging Actions

    Dica:

    Você pode usar a ação para suprimir a geração de mensagens de erro do ICMP de volta à fonte.discard Consulte ações de terminação do filtro de firewall para obter mais detalhes.Firewall Filter Terminating Actions
  4. Opcional.

    Definir o termo filtro.tcp-estab Este termo permite o acesso de saída à Internet para oferecer suporte a conexões à nuvem Juniper Mist ( é uma condição de jogo de campo pequeno, que indica uma sessão TCP estabelecida, mas não o primeiro pacote de uma conexão TCP):tcp-establishedtcp-flags "(ack | rst)"

  5. Definir o termo filtro.default-term Este termo aceita todos os outros tráfegos. Lembre-se que os filtros sem estado têm um termo de negação implícito no final.Junos OS A substituição desse comportamento ao encerrar o filtro com uma ação de aceitação explícita.default-term O término do filtro resulta em todos os outros tráfegos sendo aceitos pelo filer.

    Nota:

    Por este exemplo, estamos permitindo todo o outro tráfego, mas para sua rede você pode querer proteger o mecanismo de roteamento. Consulte a proteção do mecanismo de roteamento para obter mais informações.https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/example/routing-stateless-firewall-filter-security-accept-traffic-from-trusted-source-configuring.html

  6. Configure a interface de loopback e aplique o filtro na direção de entrada:

  7. Configure o nome do host, a interface ge-0/0/0, a rota estática para o endereço loopback do dispositivo R1 e habilite o acesso remoto por SSH e Telnet:

Verifique e confirme a configuração no dispositivo R2

Procedimento passo a passo

Preencha as seguintes etapas para verificar e confirmar a configuração do seu candidato no dispositivo R2:

  1. Confirme a configuração do filtro de firewall sem estado com o comando do modo de configuração.show firewall Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

  2. Confirme a configuração da interface e filtre o aplicativo com o comando do modo de configuração.show interfaces Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

  3. Verifique a rota estática usada para alcançar o endereço de loopback do dispositivo R1 e verifique se o acesso Telnet e SSH está habilitado. Use os comandos do modo e configuração.show routing-optionsshow system services Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

  4. Quando satisfeito com a configuração no dispositivo R2, comprometa a configuração do seu candidato.

    Dica:

    Considere usar ao fazer alterações que possam afetar o acesso remoto ao seu dispositivo.commit-confirmed

Verifique o filtro de firewall sem estado

Confirme que o filtro de firewall para limitar o acesso à Telnet e SSH 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 a partir da sub-rede 192.168.1.0/30 .

Ação

  1. Libere o log de firewall em seu roteador ou switch.

  2. De um host em um endereço IP dentro da sub-rede 192.168.1.0/30 , use um comando para verificar se você pode fazer login no dispositivo usando SSH a partir de um endereço de origem permitido.ssh 192.168.255.2 Este pacote deve ser aceito, mas as informações de cabeçalho de pacote para este pacote não devem ser registradas no buffer de log de filtro de firewall no Mecanismo de encaminhamento de pacotes. Você será solicitado a salvar a chave de host SSH se este for o primeiro login SSH como entre esses dispositivos.user

    Nota:

    Por padrão, o dispositivo R1 obterá o tráfego SSH da interface de saída usada para chegar ao destino. Como resultado, esse tráfego é originado do endereço 192.168.1.1 atribuído à interface ge-0/0/0 do dispositivo R1.

  3. Faça o login da CLI no dispositivo R2 para fechar a sessão de SSH.

  4. De um host em um endereço IP dentro da sub-rede 192.168.1.0/30 , use o comando para verificar se você pode fazer login no seu roteador ou switch usando a Telnet a partir de um endereço de origem permitido.telnet 192.168.255.2 Este pacote deve ser aceito, mas as informações de cabeçalho de pacote para este pacote não devem ser registradas no buffer de log de filtro de firewall no Mecanismo de encaminhamento de pacotes.

  5. Faça login na CLI para fechar a sessão da Telnet ao dispositivo R2.

  6. Use o comando para verificar se o buffer de log de firewall no Mecanismo de encaminhamento de pacotes (PFE) do dispositivo R2 não contém nenhuma entrada com um endereço fonte na sub-rede 192.168.1.0/30 .show firewall log

Verificar pacotes logados e rejeitados

Propósito

Verifique se o filtro de firewall rejeita corretamente o tráfego SSH e Telnet que não se origina da sub-rede 192.168.1.0/30 .

Ação

  1. Libere o log de firewall em seu roteador ou switch.

  2. Gere tráfego SSH originado no endereço de loopback do dispositivo R1. O endereço fonte desse tráfego está fora da sub-rede 192.168.1.0/30 permitida. Use o comando para verificar se você não pode fazer login no dispositivo usando SSH a partir deste endereço de origem.ssh 192.168.255.2 source 192.168.255.1 Este pacote deve ser rejeitado, e as informações de cabeçalho de pacote devem ser registradas no buffer de log do filtro de firewall.

    A saída mostra que a conexão SSH é recusada. Essa saída confirma que o filtro está gerando uma mensagem de erro do ICMP e que bloqueia corretamente o tráfego SSH quando enviado de um endereço de origem não permitido.

  3. Gere tráfego Telnet originado no endereço de loopback do dispositivo R1. O endereço fonte desse tráfego está fora da sub-rede 192.168.1.0/30 permitida. Use o comando para verificar se você não pode fazer login no dispositivo usando a Telnet a partir deste endereço fonte.telnet 192.168.255.2 source 192.168.255.1 Este pacote deve ser rejeitado, e as informações de cabeçalho de pacote para este pacote devem ser registradas no buffer de log de filtro de firewall no PFE.

    A saída mostra que a conexão Telnet foi recusada. Essa saída confirma que o filtro está gerando uma mensagem de erro do ICMP e que bloqueia corretamente o tráfego da Telnet quando enviado de um endereço de origem não permitido.

  4. Use o comando para verificar se o buffer de log de firewall no dispositivo R2 contém entradas mostrando que os pacotes com um endereço fonte de 192.168.255.1 foram rejeitados .show firewall log

    A saída confirma que o tráfego do endereço fonte 192.168.255.1 correspondia ao termo do filtro.terminal_access_denied A coluna exibe uma indicação de que esses pacotes foram rejeitados.ActionR A interface, o protocolo de transporte e os endereços de origem e destino também estão listados. Esses resultados confirmam que o filtro de firewall está funcionando corretamente para este exemplo.

Tópicos relacionados

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
19.4R1
A partir do Junos OS Release 19.4R1 e Junos OS Release 17.4R3, você pode desabilitar a senha de login SSH ou a autenticação de resposta ao desafio usando o nível de hierarquia e opções.no-password-authenticationno-challenge-responseedit system services ssh
19.1R1
A partir do Junos OS Release 19.1R1, desabilitamos globalmente as conexões SFTP de entrada por padrão. Se desejado, você pode habilitar globalmente as conexões SFTP de entrada configurando a declaração no nível de hierarquiasftp-server[edit system services ssh]
18.3R1
A partir do Junos OS Release 18.3R1, os algoritmos e hostkey são preteridos, em vez de removidos imediatamente, para fornecer compatibilidade retrógrada e uma chance de colocar sua configuração em conformidade com a nova configuração.ssh-dssssh-dsa
18.3R1
(apenas série SRX e Série MX) A partir do Junos OS Release 19.3R1, você pode especificar o nome da instância de roteamento na qual a conectividade SSH de saída precisa ser estabelecida, incluindo a declaração no nível hierárquicos:routing-instance[edit system services outbound-ssh]