Nesta página
Configure o serviço Telnet para acesso remoto a um roteador ou switch
Configure o serviço FTP para acesso remoto ao roteador ou switch
Configure o serviço SSH para acesso remoto ao roteador ou switch
Configure as chaves de host conhecidas do SSH para uma cópia segura dos dados
Configure o serviço SSH para oferecer suporte a criptografia legado
Configure conexões NETCONF-Over-SSH em uma porta TCP especificada
Configure limites de tentativa de senha para acesso à Telnet e SSH
Exemplo: Configure um filtro para bloquear o acesso à Telnet e SSH
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.
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 telnet
declaração no nível de [edit system services]
hierarquia:
[edit system services] telnet { connection-limit limit; rate-limit limit; }
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 telnet
declaração em dispositivos que executam o software Junos-FIPS. 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 ftp
declaração no [edit system services]
nível de hierarquia:
[edit system services] ftp { connection-limit limit; rate-limit limit; }
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 ftp
declaração no nível de [edit system services]
hierarquia para usar FTP ativo ou FTP passivo.
Para iniciar uma sessão de FTP passiva, use pasvftp
(em vez de ftp
) no formato FTP padrão (ftp://destination). Por exemplo:
request system software add pasvftp://name.com/jinstall.tgz
Você não pode incluir a ftp
declaração em roteadores ou switches que executam o software Junos-FIPS. 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 finger
declaração no [edit system services]
nível de hierarquia:
[edit system services] finger { connection-limit limit; rate-limit limit; }
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 finger
declaração em roteadores que executam o software Junos-FIPS. 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 ssh
declaração no nível de [edit system services]
hierarquia:
[edit system services] ssh { authentication-order [method 1 method2...]; authorized-keys-command authorized-keys-command; authorized-keys-command-user authorized-keys-command-user; authorized-principals-file filename authorized-principals-command program-path ciphers [ cipher-1 cipher-2 cipher-3 ...]; client-alive-count-max number; client-alive-interval seconds; connection-limit limit; fingerprint-hash (md5 | sha2-256); host-certificate-file filename hostkey-algorithm (algorithm | no-algorithm); key-exchange [algorithm1 algorithm2...]; log-key-changes log-key-changes; macs [algorithm1 algorithm2...]; max-pre-authentication-packets number; max-sessions-per-connection number; no-challenge-response; no-password-authentication; no-passwords; no-public-keys; no-tcp-forwarding; port port-number; protocol-version [v2]; rate-limit number; rekey { data-limit bytes; time-limit minutes; } root-login (allow | deny | deny-password); sftp-server; tcp-forwarding; trusted-user-ca-key-file filename }
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 no-password-authentication
nível de hierarquia e no-challenge-response
opçõesedit 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 no-tcp-forwarding
para impedir que um usuário crie um túnel SSH para um roteador via SSH.
Para obter informações sobre outras configurações de configuração, veja os seguintes tópicos:
- Configure o login raiz através do SSH
- Configure as próximas conexões SFTP
- Configure a versão do protocolo SSH
- Configure o mecanismo Client Alive
- Configure o algoritmo de hash de impressão digital SSH
Configure o login raiz através do SSH
Por padrão, os usuários podem fazer login no roteador ou switch como root
por SSH quando o método de autenticação não exigir uma senha. Para controlar o acesso do usuário através do SSH, inclua a root-login
declaração no nível de [edit systems services ssh]
hierarquia:
[edit system services ssh] root-login (allow | deny | deny-password);
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.
deny
-password
— 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.
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 sftp-server
no nível hierárquica [edit system services ssh]
. Antes do Junos OS Release 19.1R1, as conexões SFTP de entrada eram habilitadas globalmente por padrão.
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 sftp-server
no dispositivo A.
As conexões SFTP de entrada são desativadas por padrão. Para permitir conexões SFTP de entrada:
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 protocol-version
declaração e especifique v2
no nível de [edit system services ssh]
hierarquia:
[edit system services ssh] protocol-version [ v2 ];
Os sistemas no modo FIPS usam sempre a versão v2
de protocolo SSH.
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 client-alive-interval
as client-alive-count-max
declarações. 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):
[edit system ssh] client-alive-count-max 5; client-alive-interval 20;
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 fingerprint-hash
declaração e especifique md5
ou sha2-256
no nível de [edit system services ssh]
hierarquia:
[edit system services ssh] fingerprint-hash (md5 | sha2-256);
O md5
algoritmo de hash não está disponível em sistemas no modo FIPS.
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:
Execute o comando:
ssh-keygen -f <filename_ca>
. Isso criará uma chave privada nomeada<filename_ca>
e uma chave pública correspondente nomeada<filename_ca.pub>
.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.Cada usuário pode gerar suas próprias chaves de usuário usando o seguinte comando CLI:
ssh-keygen -t <rsa|ecdsa|ed25519>
.Copie a chave pública criada pelo usuário na máquina que tem os certificados
<filename_ca>
de usuário e<filename_ca.pub>
.Assine a chave pública do usuário no
<filename_ca.pub>
arquivo.
Configuração
Para configurar a autenticação baseada em certificado SSH, use as seguintes declarações de configuração de CLI:
-
[system services ssh trusted-user-ca-key-file filename]
— Configure oTrustedUserCAKey
arquivo em /etc/ssh/sshd_config, que contém as chaves públicas de um certificado SSH. -
[system services ssh host-certificate-file filename]
— Configure oHostCertificate
arquivo em /etc/ssh/sshd_config, que contém o certificado de host assinado. -
[system services ssh authorized-principals-file filename]
— Configure oAuthorizedPrincipals
arquivo em /var/etc, 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-command program-path]
— Especifique um programa a ser usado para gerar a lista de diretores de certificados permitidos encontrados noAuthorizedPrincipals
arquivo.
O comando telnet
Você pode usar o comando CLI telnet
para abrir uma sessão de Telnet a um dispositivo remoto:
user@host> telnet host <8bit> <bypass-routing> <inet> <interface interface-name> <no-resolve> <port port> <routing-instance routing-instance-name> <source address>
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
.
Opção |
Descrição |
---|---|
|
Use um caminho de dados de 8 bits. |
|
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. |
|
Abra uma sessão da Telnet para o nome de host ou endereço IP especificado. |
|
Force a sessão da Telnet a um destino IPv4. |
|
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. |
|
Suprime a exibição de nomes simbólicos. |
|
Especifique o número de porta ou o nome do serviço no host. |
|
Use a instância de roteamento especificada para a sessão da Telnet. |
|
Use o endereço fonte especificado para a sessão da Telnet. |
O comando ssh
Você pode usar o comando CLI ssh
para usar o programa secure shell (SSH) para abrir uma conexão a um dispositivo remoto:
user@host> ssh host <bypass-routing> <inet> <interface interface-name> <routing-instance routing-instance-name> <source address> <v1> <v2>
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 ssh
opções de comando.
Opção |
Descrição |
---|---|
|
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. |
|
Abra uma conexão SSH com o nome de host ou endereço IP especificado. |
|
Force a conexão SSH a um destino IPv4. |
|
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. |
|
Use a instância de roteamento especificada para a conexão SSH. |
|
Use o endereço de origem especificado para a conexão SSH. |
|
Force o SSH a usar a versão 1 para a conexão. |
|
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
- Configure o suporte para transferência de arquivos SCP
- Atualizar as informações principais do host SSH
Configure hosts conhecidos de SSH
Para configurar hosts conhecidos de SSH, inclua a host
declaração e especifique opções de nome de host e host para servidores confiáveis no nível de [edit security ssh-known-hosts]
hierarquia:
[edit security ssh-known-hosts] host corporate-archive-server { dsa-key key; } host archive-server-url { rsa-key key; } host server-with-ssh-version-1 { rsa1-key key; }
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 de NIST256 ECDSA-SHA2 codificada pela Base64. -
ecdsa-sha2-nistp384-key
key— Chave de NIST384 ECDSA-SHA2 codificada para a Base64. -
ecdsa-sha2-nistp521-key
key— Chave de NIST521 ECDSA-SHA2 codificada para 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 archive-sites
declaração no nível de [edit system archival configuration]
hierarquia.
[edit system archival configuration] archive-sites { scp://username<:password>@host<:port>/url-path; }
Ao especificar uma URL em uma Junos OS declaração usando um endereço de host IPv6, você deve incluir toda a URL entre aspas (" ") e desativar o endereço de host IPv6 em parênteses ([]). Por exemplo “scp://username<:password>@[host]<:port>/url-path”;
Definir a archive-sites
declaração para apontar para uma URL SCP aciona a recuperação automática da chave do host. Neste ponto, Junos OS 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.
user@host# set system archival configuration archive-sites “<scp-url-path>” The authenticity of host <my-archive-server (<server-ip-address>)> can’t be established. RSA key fingerprint is <ascii-text key>. Are you sure you want to continue connecting (yes/no)?
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 yes no prompt. 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 archival configuration archive-sites
declaração no nível de [edit system]
hierarquia. 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
- Importar informações chave do host de um arquivo
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 fetch-from-server
no nível de [edit security ssh-known-hosts]
hierarquia. Você deve especificar o host a partir do qual recuperar a chave pública SSH.
user@host# set security ssh-known-hosts fetch-from-server <hostname>
Importar informações chave do host de um arquivo
Para importar manualmente as informações chave do host SSH de um known_hosts arquivo, inclua a opção load-key-file
no nível de [edit security ssh-known-hosts]
hierarquia. Você deve especificar o caminho até o arquivo a partir do qual importar informações chave do host.
user@host# set security ssh-known-hosts load-key-file /var/tmp/known-hosts
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.
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 à 3des-cbc
cifra, blowfish-cbc
ou ambos, e ao dh-group1-sha1
método de troca de chaves. Esse problema não afeta dispositivos que executam o Junos OS com FreeBSD atualizado.
Consulte a documentação do OpenSSH 7 em https://www.openssh.com/ para obter mais informações sobre essas extensões.
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 Junos OS, as cifras a seguir não são suportadas por padrão, mas você pode configurar o seu dispositivo para dar suporte a eles. Eles estão listados dos mais seguros aos menos seguros:
-
aes256-cbc
-
aes192-cbc
-
aes128-cbc
-
3des-cbc
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 Junos OS, 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:
-
group-exchange-sha1
-
dh-group1-sha1
Para configurar o serviço SSH para oferecer suporte a criptografia legadas:
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 file copy
comando quando você usa o Secure Copy Protocol (SCP).
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, outbound-ssh
pode ser configurado no dispositivo da Juniper Networks. Uma outbound-ssh
configuração inicia uma conexão SSH reversa do servidor ao cliente até o aplicativo de gerenciamento. Essa conexão SSH de saída só é fechada após a configuração ser removida do dispositivo.
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 outbound-ssh
declaração no nível de [edit system services]
hierarquia:
[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
- Configure mensagens keepalive para conexões SSH de saída
- Configure uma nova conexão SSH de saída
- Configure o cliente SSH de saída para aceitar o NETCONF como um serviço disponível
- Configure clientes SSH de saída
- Configure instâncias de roteamento para clientes 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 device-id
declaração no [edit system services outbound-ssh client client-id]
nível hierárquico:
[edit system services outbound-ssh client client-id] device-id device-id;
A sequência de iniciação quando secret
não está configurada:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n
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 secret
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.
Quando a secret
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 secret
declaração. O valor da secret
declaração é compartilhado entre o dispositivo e o cliente de gerenciamento. 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 device-id
declaração.
Usar a secret
declaração para transportar a chave de host SSH pública é opcional. Você pode transportar e instalar manualmente a chave pública no sistema do cliente.
Incluir a secret
declaração significa que o dispositivo envia a chave de host SSH pública toda vez que estabelece uma conexão com o cliente. 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 secret
declaração no [edit system services outbound-ssh client client-id]
nível hierárquico:
[edit system services outbound-ssh client client-id] secret password;
A mensagem a seguir é enviada pelo dispositivo quando o secret
atributo está configurado:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n HOST-KEY: <public-host-key>\r\n HMAC:<HMAC(pub-SSH-host-key, <secret>>)>\r\n
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 Junos OS (autenticação pública de string ou senha RSA/DSA).
Para permitir que o dispositivo envie mensagens keepalives de protocolo SSH ao aplicativo do cliente, configure a keep-alive
declaração no [edit system services outbound-ssh client client-id]
nível hierárquica:
[edit system services outbound-ssh client client-id] keep-alive { retry number; timeout seconds; }
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 reconnect-strategy
declaração no nível de [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client-id] reconnect-strategy (sticky | in-order);
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 services netconf
declaração no nível de [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client client-id] services { netconf; }
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 [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client client-id] address address { retry number; timeout seconds; port port-number; }
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 mgmt_junos
instância de roteamento usando o set system management-instance
comando.
Para usar qualquer outra instância de roteamento, configure primeiro a instância de roteamento na [edit routing-instances]
hierarquia.
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 port
declaração no nível de [edit system services netconf ssh]
hierarquia. 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.
-
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:
Exemplo: Configure um filtro para bloquear o acesso à Telnet e SSH
Requisitos
Você precisa de dois dispositivos em execução Junos 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.
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
source-address
condição de correspondência IPv4 aplicada na direção de entrada. -
Para combinar pacotes destinados à porta Telnet e portas SSH, você usa a condição de
protocol tcp
correspondência combinada comport telnet
condições de correspondência IPv4 eport ssh
aplicadas na direção de entrada.
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.
![Topologia de exemplo](../../routing-policy/topics/example/../../images/g301199.png)
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.
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
- Configure o dispositivo R1
- Verifique e confirme a configuração no dispositivo R1
- Configure o dispositivo R2
- Verifique e confirme a configuração no dispositivo R2
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 [edit]
nível de hierarquia. Certifique-se de emitir um commit
modo de configuração para ativar as mudanças.
set system host-name R1 set system services ssh root-login allow set interfaces ge-0/0/0 description "Link from R1 to R2" set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30 set interfaces lo0 unit 0 family inet address 192.168.255.1/32 set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
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 [edit]
hierarquia. Certifique-se de emitir um commit
modo de configuração para ativar as mudanças.
Considere usar commit-confirmed
ao fazer alterações que possam afetar o acesso remoto ao seu dispositivo. Ativando uma configuração do Junos OS, mas exigindo confirmação
set system host-name R2 set system services ssh root-login allow set system services telnet set interfaces ge-0/0/0 description "Link from R2 to R1" set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30 set interfaces lo0 unit 0 family inet filter input local_acl set interfaces lo0 unit 0 family inet address 192.168.255.2/32 set firewall family inet filter local_acl term terminal_access from source-address 192.168.1.0/30 set firewall family inet filter local_acl term terminal_access from protocol tcp set firewall family inet filter local_acl term terminal_access from port ssh set firewall family inet filter local_acl term terminal_access from port telnet set firewall family inet filter local_acl term terminal_access then accept set firewall family inet filter local_acl term terminal_access_denied from protocol tcp set firewall family inet filter local_acl term tcp-estab from protocol tcp set firewall family inet filter local_acl term tcp-estab from tcp-established set firewall family inet filter local_acl term tcp-estab then accept set firewall family inet filter local_acl term terminal_access_denied from port ssh set firewall family inet filter local_acl term terminal_access_denied from port telnet set firewall family inet filter local_acl term terminal_access_denied then log set firewall family inet filter local_acl term terminal_access_denied then reject set firewall family inet filter local_acl term default-term then accept set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Configure o dispositivo R1
Procedimento passo a passo
Siga essas etapas para configurar o dispositivo R1:
-
Configure as interfaces:
[edit] user@R1# set interfaces ge-0/0/0 description "Link from R1 to R2" user@R1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30 user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
-
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:
[edit] user@R1# set system host-name R1 user@R1# set system services ssh root-login allow user@R1# set system services telnet user@R1# set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
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:
-
Confirme a configuração da interface com o comando do
show interfaces
modo de configuração. Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.[edit] user@R1# show interfaces ge-0/0/0 { description "Link from R1 to R2"; unit 0 { family inet { address 192.168.1.1/30; } } } lo0 { unit 0 { family inet { address 192.168.255.1/32; } } }
-
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
show routing-options
modo eshow system services
configuração. Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.[edit] user@R1# show routing-options static { route 192.168.255.2/32 next-hop 192.168.1.2; } user@R1# show system services ssh { root-login allow; } telnet;
-
Quando satisfeito com a configuração no dispositivo R1, comprometa a configuração do seu candidato.
[edit] user@R1# commit
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:
-
Posicione-se na
edit firewall family inet filter
local_acl hierarquia:[edit] user@R2# edit firewall family inet filter local_acl
-
Definir o termo terminal_accessfiltro. Este termo permite que a Telnet e a SSH a partir do(s) prefixo(s) de origem especificado:
[edit firewall family inet filter local_acl] user@R2# set term terminal_access from source-address 192.168.1.0/30 user@R2# set term terminal_access from protocol tcp user@R2# set term terminal_access from port ssh user@R2# set term terminal_access from port telnet user@R2# set term terminal_access then accept
-
Definir o termo terminal_access_deniedfiltro. 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.
Dica:Você pode usar a ação
discard
para suprimir a geração de mensagens de erro do ICMP de volta à fonte. Consulte ações de terminação do filtro de firewall para obter mais detalhes.[edit firewall family inet filter local_acl] user@R2# set term terminal_access_denied from protocol tcp user@R2# set term terminal_access_denied from port ssh user@R2# set term terminal_access_denied from port telnet user@R2# set term terminal_access_denied then log user@R2# set term terminal_access_denied then reject user@R2# set term default-term then accept
- Opcional.
Definir o termo tcp-estabfiltro. Este termo permite o acesso de saída à Internet para oferecer suporte a conexões à nuvem Juniper Mist (tcp-established é uma condição de jogo de campo pequeno, tcp-flags "(ack | rst)"que indica uma sessão TCP estabelecida, mas não o primeiro pacote de uma conexão TCP):
[edit firewall family inet filter local_acl] user@R2# set term tcp-estab from protocol tcp user@R2# set term tcp-estab from tcp-established user@R2# set term tcp-estab then accept
-
Definir o termo default-termfiltro. Este termo aceita todos os outros tráfegos. Lembre-se que Junos OS os filtros sem estado têm um termo de negação implícito no final. A default-term substituição desse comportamento ao encerrar o filtro com uma ação de aceitação explícita. 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.
[edit firewall family inet filter local_acl] user@R2# set term default-term then accept
-
Configure a interface de loopback e aplique o filtro na direção de entrada:
[edit] user@R2# set interfaces lo0 unit 0 family inet filter input local_acl user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32
-
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:
[edit] user@R2# set system host-name R2 user@R2# set system services ssh root-login allow user@R2# set system services telnet user@R2# set interfaces ge-0/0/0 description "Link from R2 to R1" user@R2# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30 user@R2# set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
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:
-
Confirme a configuração do filtro de firewall sem estado com o comando do
show firewall
modo de configuração. Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.[edit] user@R2# show firewall family inet { filter local_acl { term terminal_access { from { source-address { 192.168.1.0/30; } protocol tcp; port [ssh telnet]; } then accept; } term terminal_access_denied { from { protocol tcp; port [ssh telnet]; } then { log; reject; } } term default-term { then accept; } } }
-
Confirme a configuração da interface e filtre o aplicativo com o comando do
show interfaces
modo de configuração. Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.[edit] user@R2# show interfaces ge-0/0/0 { description "Link from R2 to R1"; unit 0 { family inet { address 192.168.1.2/30; } } } lo0 { unit 0 { family inet { filter { input local_acl; } address 192.168.255.2/32; } } }
-
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
show routing-options
modo eshow system services
configuração. Se a saída de comando não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.[edit] user@R2# show routing-options static { route 192.168.255.1/32 next-hop 192.168.1.1; } user@R2# show system services ssh { root-login allow; } telnet;
-
Quando satisfeito com a configuração no dispositivo R2, comprometa a configuração do seu candidato.
Dica:Considere usar
commit-confirmed
ao fazer alterações que possam afetar o acesso remoto ao seu dispositivo.[edit] user@R2# commit
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
-
Libere o log de firewall em seu roteador ou switch.
user@R2> clear firewall log
-
De um host em um endereço IP dentro da sub-rede 192.168.1.0/30 , use um
ssh 192.168.255.2
comando para verificar se você pode fazer login no dispositivo usando SSH a partir de um endereço de origem permitido. 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 user entre esses dispositivos.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.
user@R1>ssh 192.168.255.2 Password: Last login: Wed Aug 19 09:23:58 2020 from 192.168.1.1 --- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil user@R2>
-
Faça o login da CLI no dispositivo R2 para fechar a sessão de SSH.
user@R2> exit logout Connection to 192.168.255.2 closed. user@R1>
-
De um host em um endereço IP dentro da sub-rede 192.168.1.0/30 , use o
telnet 192.168.255.2
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. 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.user@host-A> telnet 192.168.255.2 Trying 192.168.255.2... Connected to 192.168.255.2. Escape character is '^]'. login: user Password: --- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil user@R2>
-
Faça login na CLI para fechar a sessão da Telnet ao dispositivo R2.
user@R2:~ # exit Connection closed by foreign host. root@R1>
-
Use o
show firewall log
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 .user@R2> 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
-
Libere o log de firewall em seu roteador ou switch.
user@R2> clear firewall log
-
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
ssh 192.168.255.2 source 192.168.255.1
comando para verificar se você não pode fazer login no dispositivo usando SSH a partir deste endereço de origem. 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.user@R1 ssh 192.168.255.2 source 192.168.255.1 ssh: connect to host 192.168.255.2 port 22: Connection refused root@R1>
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.
-
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
telnet 192.168.255.2 source 192.168.255.1
comando para verificar se você não pode fazer login no dispositivo usando a Telnet a partir deste endereço fonte. 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.user@R1> telnet 192.168.255.2 source 192.168.255.1 Trying 192.168.255.2... telnet: connect to address 192.168.255.2: Connection refused telnet: Unable to connect to remote host
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.
-
Use o
show firewall log
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 .user@R2> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 15:17:11 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2 15:12:04 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2
A saída confirma que o tráfego do endereço fonte 192.168.255.1 correspondia ao termo do terminal_access_denied filtro. A
Action
coluna exibe uma indicaçãoR
de que esses pacotes foram rejeitados. 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.
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.
no-password-authentication
nível de hierarquia e no-challenge-response
opçõesedit system services ssh
.sftp-server
no nível de [edit system services ssh]
hierarquiassh-dss
algoritmos e ssh-dsa
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.routing-instance
declaração no [edit system services outbound-ssh]
nível hierárquicos: