Olá, Telnet! E por enquanto. Comando OpenSSL s_client para conexões criptografadas



Imagem : JanBaby, via Pixabay CC0



O utilitário de rede telnet é uma palavra da moda . Em certo momento, ele foi usado de forma muito ativa pela maioria esmagadora dos administradores de sistema e outros fãs da administração de servidores remotos. O utilitário permite que você acesse as portas de um host remoto, execute o procedimento de autorização e execute comandos nesta máquina.



Mas o protocolo telnet não usa criptografia. Na realidade de hoje, sacrificar a segurança é um luxo inacessível. No entanto, há uma série de tarefas que o telnet pode executar com vários graus de sucesso: teste de rede, verificação de porta e interação com roteadores e dispositivos IoT. 



Parece que o utilitário pode ser facilmente usado como uma versão avançada do ping. Por si só, o comando ping, na melhor das hipóteses, verifica apenas a disponibilidade do host (às vezes esse comando não funciona, por exemplo, devido a restrições de política de acesso). Mas o comando telnet não apenas verifica se a porta está aberta, mas também pode se comunicar com os serviços de rede por meio dessa porta. Mas, com o tempo, enfrentaremos cada vez mais a necessidade de usar uma conexão criptografada, na qual o telnet ficará novamente impotente.



OpenSSL e o comando s_client



Portanto, na maioria dos casos, uso o comando s_client da biblioteca OpenSSL em vez do telnet . O comando s_client executa as funções de um cliente SSL / TLS para se conectar a um host remoto com várias configurações - chave de criptografia, tipo de handshake, protocolo e assim por diante. O comando também permite que você verifique se a sessão está sendo retomada.



Instalando OpenSSL



Se a biblioteca OpenSSL ainda não estiver instalada em seu sistema operacional, ela pode ser instalada usando o gerenciador de pacotes:



$ sudo dnf install openssl

 Debian        :

$ sudo apt install openssl

       :

$ openssl version

OpenSSL x.y.z FIPS

      
      





Verificação de acesso à porta



É assim que o comando telnet funciona para verificar o acesso à porta 25:



$ telnet mail.example.com 25

Trying 98.76.54.32...

Connected to example.com.

Escape character is '^]'.
      
      





No exemplo acima, abrimos uma sessão interativa com um determinado servidor de e-mail ouvindo na porta 25. Se tivermos acesso a ele, podemos trocar mensagens com ele. Se a porta 25 não estiver disponível, a conexão não será estabelecida. 



Agora vamos ver como funciona um comando semelhante do OpenSSL: 



$ openssl s_client -connect example.com:80

CONNECTED(00000003)

140306897352512:error:1408F10B:SSL [...]

no peer certificate available

No client certificate CA names sent

SSL handshake has read 5 bytes and written 309 bytes

Verification: OK

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

Early data was not sent

Verify return code: 0 (ok)

      
      





Como você pode ver, não houve envio de dados sobre o certificado SSL, então a conexão foi interrompida, não foi possível abrir uma sessão. Para estabelecer uma conexão criptografada segura usando o protocolo HTTPS, você precisa acessar uma porta especial.



Abrindo uma sessão interativa com uma conexão criptografada



Nesse caso, navegadores e servidores da web se comunicam de forma que o tráfego direcionado à porta 80 seja realmente redirecionado para a porta 443, que é reservada para o tráfego HTTPS. Sabendo disso, você pode fazer isso com qualquer serviço da web que escuta na porta 443.



Primeiro, vamos nos conectar à porta usando SSL. Usamos a opção -showcerts e o certificado SSL será impresso em seu terminal:



$ openssl s_client -connect example.com:443 -showcerts

[...]

    0080 — 52 cd bd 95 3d 8a 1e 2d-3f 84 a0 e3 7a c0 8d 87   R...=..-?...z...

    0090 — 62 d0 ae d5 95 8d 82 11-01 bc 97 97 cd 8a 30 c1   b.............0.

    00a0 — 54 78 5c ad 62 5b 77 b9-a6 35 97 67 65 f5 9b 22   Tx\.b[w..5.ge..»

    00b0 — 18 8a 6a 94 a4 d9 7e 2f-f5 33 e8 8a b7 82 bd 94   ..j...~/.3......

    Start Time: 1619661100

    Timeout   : 7200 (sec)

    Verify return code: 0 (ok)

    Extended master secret: no

    Max Early Data: 0

-

read R BLOCK
      
      





Conseguimos abrir uma sessão interativa. Até que feche, podemos enviar mensagens HTTP para o servidor:



[...]

GET / HTTP/1.1

HOST: example.com

      
      





Pressione a tecla Return (para MacOS) ou ENTER (para Windows) duas vezes, e receberemos uma resposta do servidor no formato example.com/index.html:



[...]

<body>

<div>

    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this

    domain in literature without prior coordination or asking for permission.</p>

    <p><a href="https://www.iana.org/domains/example">More information...</a></p>

</div>

</body>

</html>
      
      





Servidor de e-mail



O comando s_client pode ser usado para testar uma conexão criptografada com um servidor de e-mail. Para que isso funcione, precisamos de um nome de usuário e senha (no meu caso, para um usuário de teste) codificados em Base64.



Você pode codificá-los, por exemplo, assim:



$ perl -MMIME::Base64 -e 'print encode_base64(«username»);'

$ perl -MMIME::Base64 -e 'print encode_base64(«password»);'

      
      





Se tudo correr bem, você pode prosseguir para a próxima etapa - conectar-se ao servidor de e-mail via SSL. A porta 587 é comumente usada:



$ openssl s_client -starttls smtp \

-connect email.example.com:587

> ehlo example.com

> auth login

##paste your user base64 string here##

##paste your password base64 string here##

> mail from: noreply@example.com

> rcpt to: admin@example.com

> data

> Subject: Test 001

This is a test email.

.

> quit

      
      





Eu inseri o endereço de e-mail admin@example.com, e espero receber uma mensagem de teste do servidor de e-mail.



Risco injustificado



Algumas pessoas ainda usam o telnet, mas ele não é mais a ferramenta indispensável de antes. Agora é classificado como um pacote "legado" em muitos sistemas. Alguns administradores de sistema se perguntam por que ele foi excluído da instalação padrão. O Telnet está gradualmente perdendo sua relevância. Este é um processo objetivo. 



A segurança da rede é vital para a maioria dos sistemas, portanto, vale a pena familiarizar-se com as ferramentas adequadas. É importante que eles sejam capazes de trabalhar com conexões seguras. Portanto, ao testar ou solucionar problemas, você não precisa desabilitar a proteção do sistema e arriscar a segurança.






Os servidores em nuvem da Macleod são rápidos e seguros.



Cadastre-se pelo link acima ou clicando no banner e ganhe 10% de desconto no primeiro mês de aluguel de um servidor de qualquer configuração!






All Articles