Guia da porta Telnet: acesso remoto legado na porta 23

Telnet abre uma conexão TCP e apresenta uma sessão de terminal baseada em texto. Depois que o servidor aceita a conexão, o cliente e o servidor podem negociar as opções do terminal, então o usuário envia comandos e recebe a saída como texto simples.

Essa simplicidade é a razão pela qual o Telnet sobreviveu no gerenciamento de dispositivos, laboratórios, equipamentos de fabricação e dispositivos antigos. É também por isso que é arriscado: sem um túnel criptografado separado, qualquer pessoa que consiga capturar o tráfego entre o cliente e o servidor poderá ler credenciais e comandos.

O SSH substituiu o Telnet na maior parte da administração remota porque o SSH criptografa a sessão, verifica a chave do host do servidor e suporta autenticação mais forte. O SSH normalmente usa a porta TCP 22, enquanto o Telnet normalmente usa a porta TCP 23.

Se o dispositivo suportar SSH, use SSH em vez de Telnet. Mantenha o Telnet apenas para sistemas que não podem ser atualizados, para acesso isolado a laboratórios ou para fluxos de trabalho de emergência curtos onde já existem controles de compensação.

O Telnet ainda aparece em roteadores e switches mais antigos, sistemas PBX, servidores de console fora de banda, controles prediais, controladores industriais, matrizes de armazenamento, impressoras e dispositivos de fornecedores que foram projetados antes do SSH se tornar padrão.

Ele também é usado como um cliente de diagnóstico simples para serviços TCP brutos, embora ferramentas modernas como nc, ncat, curl, openssl s_client e clientes de protocolo específicos geralmente forneçam melhor visibilidade e menos surpresas.

A porta 23 quase nunca deve ser aberta à Internet pública. O Telnet público atrai varredura automatizada, ataques de senha padrão, atividade de botnet e controle oportunista de dispositivos. Se um serviço Telnet puder ser acessado de fora de uma rede confiável, trate-o como uma exposição urgente para revisão.

Se o Telnet for inevitável, restrinja-o a uma VLAN de gerenciamento, VPN, host bastião, caixa de salto, rede de console serial ou lista de permissões de IP de origem. O objetivo é tornar o Telnet acessível apenas às pessoas e à automação que realmente precisam dele.

Antes de permitir o TCP 23, confirme por que o Telnet ainda é necessário e se o SSH, o gerenciamento de HTTPS, uma API do fornecedor ou um console serial podem substituí-lo. Em seguida, identifique quem deve se conectar, de qual rede, por quanto tempo e quais registros estão disponíveis.

Um verificador de porta pode informar se o TCP 23 pode ser acessado externamente, mas não pode informar se as credenciais são seguras ou se o dispositivo suporta controles de acesso modernos. Teste o caminho de login real apenas em uma rede confiável e evite enviar senhas reais por meio de links não confiáveis.

No Windows, o Cliente Telnet pode ser ativado para testes, mas o Servidor Telnet não deve ser usado para administração normal. Se um sistema Windows precisar de acesso de comando remoto, use PowerShell Remoting, SSH, RDP por meio de um gateway ou outro caminho de gerenciamento criptografado.

No Linux, os pacotes do servidor Telnet geralmente são desnecessários e devem permanecer desativados. Se um daemon legado precisar ser executado, vincule-o a uma interface privada e restrinja o acesso com firewalld, ufw, nftables, iptables ou uma lista de permissões baseada em host.

Em dispositivos e dispositivos de rede, desative o Telnet quando o gerenciamento SSH ou HTTPS estiver disponível. Se as limitações do fornecedor forçarem o Telnet, coloque o dispositivo em uma rede de gerenciamento restrita e documente a exceção para que ela possa ser removida durante o próximo ciclo de atualização.

Comece com uma verificação de porta externa em relação ao nome do host ou endereço IP e porta 23. Se o resultado for aberto, um cliente remoto poderá estabelecer uma conexão TCP com o ouvinte Telnet. Isso não significa que seja seguro fazer login na Internet pública.

Em uma rede confiável, você pode testar o banner com telnet host 23, nc -vz host 23 ou ncat. No servidor ou dispositivo, inspecione o status do serviço e as regras de firewall. Para dispositivos, verifique as configurações de gerenciamento porque o Telnet pode ser habilitado separadamente do SSH ou da administração web.

Se a porta 23 estiver fechada, o Telnet poderá estar desativado, o dispositivo poderá suportar apenas SSH, o serviço poderá estar vinculado a uma interface de gerenciamento ou um firewall poderá estar bloqueando o caminho. Se o tempo expirar, um roteador, uma ACL, uma política de VPN, um firewall na nuvem ou uma restrição de IP de origem poderão estar interrompendo o tráfego.

Se a porta estiver aberta, mas o login falhar, inspecione o formato do nome de usuário, o estado da senha, as regras de classe de acesso do dispositivo, a autenticação local versus diretório, a configuração da linha e as configurações de bloqueio. Em equipamentos de rede, a política de linha VTY ou as ACLs do plano de gerenciamento geralmente explicam a falha.

Desative o Telnet sempre que possível. Substitua-o por SSH, gerenciamento HTTPS, acesso somente VPN, console serial ou ferramentas de fornecedor. Remova contas padrão, alterne senhas compartilhadas e mantenha o firmware do dispositivo atualizado até que a dependência do Telnet desapareça.

Se o Telnet precisar permanecer, isole-o das redes de usuários e da Internet, registre tentativas de acesso, monitore endereços de origem inesperados e documente a propriedade. Trate todas as exceções do Telnet como uma dívida operacional temporária e não como um padrão de gerenciamento normal.