SSH - Secure Shell
O capítulo presente retrata o software SSH. Aqui será apresentado medidas para administração e manutenção de sistemas remotos. O SSH é um serviço seguro e alternativo a serviços como TELNET e FTP que não utilizam de criptografia.
O SSH, assim como o TELNET, é um ferramenta cuja a finalidade é permitir a administração remota. Ao contrário do TELNET, o SSH utiliza de criptografia em toda a transação entre cliente e servidor. Isto evita que pessoas mal-intencionadas capturem informações importantes de sua rede através de sniffers – farejadores. Na verdade, os dados serão capturados, mas não serão entendidos, devido a criptografia forte que o SSH utiliza.
O SSH, além de sua principal característica que é o acesso remoto, possui ferramentas para transferir arquivos na rede. Mais precisamente, o SSH possui o aplicativo scp – Secure Copy - e ftps – FTP Secure – que são duas ferramentas que podem ser utilizadas em alternativa ao tradicional FTP que não é seguro.
Nota: TELNET e FTP são dois serviços que devem ser evitados. TELNET e FTP não garantem sigilo de dados e pode comprometer toda a segurança de sua rede ou sistema. No capítulo sobre sniffers foi mostrado como capturar por exemplo logins e senhas destes dois serviços.
O SSH é uma implementação comercial e não pode ser utilizado em serviços renumerados. O OpenSSH é a variante do SSH portada para o OpenBSD que posteriormente tornou suportada pela grande maioria dos sistemas da família UNIX incluindo o Linux. O OpenSSH não possui limitações de uso e pode ser utilizado sem restrições. Portanto, em nosso material, será utilizado o OpenSSH.
O desenvolvimento do SSH está relacionado a utilização de determinados tipos de algoritmos de criptografia. Os tipos de criptografia implementado pelo SSH é determinado por aquilo que chamamos de protocolos 1 e 2.
Protocolo 1: O protocolo 1 do SSH diz respeito às versões 1.3 e 1.5 do SSH. Nestas versões é utilizado o algoritmo de criptografia RSA1 para a troca de chaves – criptografia assimétrica. Para criptografia de sessão é utilizado os algoritmos de criptografia simétrica DES ou Blowfish. O OpenSSH suporta o protocolo 1, sendo que a única restrição é a utilização do algoritmo RSA1. Porém, este algoritmo expirou no final do ano de 2000 e somente é válido nos Estados Unidos.
Protocolo 2: Neste protocolo o algoritmo RSA foi substituído pelo DSA e DH2. Portanto, neste protocolo, não há problemas de patentes relacionado ao OpenSSH.
Nota: O OpenSSH mesmo no protocolo 2 continua suportando o protocolo 1. Isto permite que cliente no protocolo 1 conecte em servidores que utilizam o OpenSSH com versões superiores a 2.0.
O daemon SSH é um serviço que utiliza o TCP e escuta a porta 22. Toda a segurança de conexão SSH é baseado na troca de chaves entre cliente e servidor e a criação de tunel criptografado entre o cliente e o servidor.
Ao instalar o OpenSSH, é gerado um par de chaves – chave pública e privada - que será utilizado em toda conexão SSH – Este par de chaves é conhecido como chaves do host: pubhost e privhost. Ao iniciar a conexão SSH, um novo par de chaves é gerado. Este novo par de chaves nunca é armazenado em disco, sendo regerado periodicamente – Este par de chaves é chamado de chaves do servidor – pubserver e privserver.
Quando o cliente conecta a primeira vez no servidor SSH, ele irá receber e armazenar a chave pública pubhost que será utilizado em conexões posteriores para garantir que o servidor da nova conexão é o mesmo servidor da primeira conexão. O cliente também irá receber a chave pubserver que em conjunto com a chave pubhost serão utilizadas para criptografar um número aleatório de 256 bits gerado pelo cliente SSH. Este número será enviado para o servidor e será usado como chave simétrica para estabelecer o túnel criptografado pelo qual toda a informação será transmitida entre servidor e cliente. Este procedimento garante a segurança dos clientes SSH, uma vez que eles possuem a certeza que a máquina remota realmente é o servidor autentico. Também garante o sigilo dos dados, uma vez que somente o servidor será capaz de descriptografar a chave simétrica enviada pelo cliente, pois apenas o servidor possue as devidas chaves privadas – chaves privhost e privserver.
CLIENTE SERVIDOR 1. pedido de conexão ------------------------------> 2. envio das chaves pubhost e pubserver <------------------------------ 3. pubhost = chave no arquivo known_hosts 4. geração e criptografia do número 256 bits 5. envio da chave simétrica criptografada ------------------------------> 6. túnel criptografado estabelecido <----------------------------->
fig 1. Análise da conexão SSH.
Em seguida está explicado as etapas da conexão SSH.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is bc:29:3d:76:69:8a:2d:d1:47:69:a3:15:d5:c0:4e:88. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:1 RSA1 host key for intranet.sistemasabertos.com.br has changed and you have requested strict checking. Host key verification failed.
Para que não haja compatibilidade da chave enviada pelo servidor e a chave armazenada, há três casos possíveis: O serviço SSH do servidor foi reinstalado e uma nova chave consequentemente foi criada, o arquivo known_hosts por algum motivo foi alterado manualmente ou alguém mal-intencionado está tentando se passar pelo servidor autentico. Para o último caso, um possível ataque é o man-in-the-middle attack. Ataque onde uma máquina entre o cliente e o servidor simula um proxy SSH e captura a sessão SSH. Neste ataque o invasor simula um servidor para o cliente SSH e um cliente para o servidor SSH. Assim, os dados antes de chegar ao servidor passa pelo invasor que tem acesso ao dados transferidos entre o cliente e o servidor.
Nota: O arquivo known_hosts é criado dentro do diretório .ssh que fica dentro do diretório pessoal de cada usuário.
Este tipo de utilização do cliente SSH é o mais utilizado, pois o usuário remotamente tem controle total sobre a máquina. Esta forma de uso é muito utilizado para administrar e dar manutenção remotamente no servidor.
Para acessar o servidor OpenSSH remotamente, execute o seguite comando:
#ssh -l andre 10.1.0.10
Um mesmo resultado pode ser obtido executando o ssh com da seguinte forma:
#ssh andre@10.1.0.10
Nos dois exemplos, o usuário de conexão é o jpaulo, e o servidor que deseja-se conectar é a máquina de IP 10.1.0.10.
Nota: A configuração padrão de instalação do OpenSSH permite que todos usuários do sistema possa efetuar logon via SSH.
Se for a primeira vez que você estiver acessando o servidor sshd, a seguinte mensagem será apresentada:
#ssh jpaulo@10.1.0.10 The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 56:b0:44:fa:ca:49:36:54:ff:ec:c1:5a:d3:65:7d:cd. Are you sure you want to continue connecting (yes/no)?yes
Esta é a identificação do servidor SSH que será utilizada em conexões futuras para garantir que as conexões estão sendo direcionadas corretamente ao servidor autentico. Esta identificação também chamada fingerprint - impressão digital – é composta pela chave pública – pubhost – e será armazenada no diretório ~/.ssh/known_hosts, ou seja, cada usuário terá seu próprio arquivo para armazenar a identificação de seus servidores SSH.
O OpenSSH permite o envio de comandos através de seus clientes para que sejam processados no servidor. A sintaxe para está função do SSH está demonstrada abaixo:
#ssh <usuário>@<servidor_SSH> <comandos>
Obviamente, a execução destes comandos remotamente exige autenticação. O exemplo que se segue é baseado em um usuário que deseja ler o arquivo /etc/passwd do servidor SSH.
#ssh fulano@intranet.sistemasabertos.com.br cat /etc/passwd fulano@intranet's password: root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm:
Neste exemplo, o usuário fulano utiliza o SSH para ler o arquivo /etc/passwd do servidor intranet. A conexão será encerrada assim que a execução do comando for terminada.
A instalação e configuração padrão do OpenSSH utiliza de 8 arquivos. Estes arquivos são encontrados no diretório /etc/ssh definido na instalação. Abaixo está a descrição de cada um:
Importante: Todos os arquivos que guardam as chaves privadas deve ter permissões 600 e dono root. Os arquivos que guardam as chaves públicas deverá ter permissões 644 e dono root.
A configuração do daemon sshd, como explicado anteriormente, é feita através do arquivo sshd_config. Eis aqui um exemplo de configuração:
#Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 #LoginGraceTime 120 #PermitRootLogin yes
Os parâmetros apresentados fazem parte de apenas um trecho do arquivo de configuração do sshd. A configuração apresentada é a padrão de instalação. Só é necessário descomentar os parâmetros se for alterar a configuração de determinado parâmetro.
Nota: RSA1 é utilizada no protocolo 1. DSA e RSA são utilizadas no protocolo versão 2.
Nota: maiores detalhes sobre este arquivo pode ser encontrada através das páginas de manual, para isto execute: man 5 sshd_config.
O daemon sshd suporta configurações de acesso baseado em usuário e grupo de usuários. A configuração destas restrinções são feitas através do arquivo sshd_config. Toda alteração deste arquivo exige que o serviço sshd seja reiniciado.
Configuração baseada em usuários
Os parâmetros utilizados são:
AllowUsers jpaulo akira maria leandro carolina silva*
Por padrão todos os usuários estão habilitados para acessar o servidor OpenSSH.
DenyUsers revalino robson patricia marcelo?
Este exemplo nega o acesso aos usuários: revalino, robson, patrícia e marcelo?. O caractere curinga ? substitui um único caractere após o nome marcelo. Portanto, usuários como: marcelo1, marcelo2, marceloS serão negados também.
Configuração baseada em grupos de usuários
Para esta configuração existem os parâmetros: AllowGroups e DenyGroups. Abaixo está a descrição deste parâmetros.
AllowGroups admrede suporte DenyGroups – Os usuários pertencentes aos grupos definidos por este parâmetro terão acesso negado. DenyGroups alunos professores
O exemplo acima determina que qualquer usuário que pertença ao grupos alunos e professores não poderão acessar o servidor.
O OpenSSH além de permitir acesso remoto, possui ferramentas que permitem a transferência de arquivos em rede. As ferramentas que possuem tal finalidade são: o scp e o ftps.
O scp – Secure Copy – é um programa de sintaxe muito parecida com o ssh. Já o ftps simula o tradicional FTP. Estes programas utilizam a mesma porta que o SSH – porta 22 - e transferem toda informação de forma segura, ou seja, criptografada.
Nota: Estes dois programas é uma ótima alternativa para substituição do FTP tradicional. Lembrando que a utilização do FTP deve ser evitada devido aos graves problemas de segurança que este serviço possui.
Uma vez instalado o OpenSSH, o scp também já será instalado e estará apto a ser utilizado assim que o daemon sshd estiver inicializado.
Enviando arquivos - upload:
A sintaxe de envio de arquivos do scp está apresentada abaixo:
#scp <arquivo> <usuário>@<servidor_SSH>:<diretório_de_destino>
Abaixo está apresentado um exemplo:
#scp teste.txt jpaulo@intranet.sistemasabertos.com.br:/home/nova_versao jpaulo@intranet.sistemasabertos.com.br's password: teste.txt 100% 25KB 946.7KB/s 00:00
Este exemplo simula o envio do arquivo teste.txt, sendo que o usuário utilizado no servidor intranet.sistemasabertos.com.br é o jpaulo. Neste exemplo o arquivo será enviado para o diretório /home/nova_versao.
Baixar arquivos – download:
A sintaxe para download de arquivo do scp está apresentada abaixo:
#scp jpaulo@intranet.sistemasabertos.com.br:/home/nova_versao/teste.txt /tmp
O exemplo acima simula o download do arquivo teste.txt que está no servidor intranet. Neste exemplo, o arquivo será gravado no diretório /tmp.
Para utilizar o FTPS é necessário configurar o sshd. A configuração é baseada simplesmente em habilitar uma linha no arquivo sshd_config.
Subsystem sftp /usr/local/openssh/libexec/sftp-server
Depois de habilitar a linha acima, reinicialize o servidor sshd.
Utilizando o cliente ftps:
Para conectar ao servidor, execute:
#sftp jpaulo@10.1.0.10 Connecting to localhost... jpaulo@10.1.0.10's password: sftp>
Neste exemplo o usuário de conexão é o jpaulo e o servidor sshd é a máquina de IP 10.1.0.10. Depois de “logado” no sistema, os mesmos comandos do FTP tradicional é válido, ou seja, você poderá utilizar o mget e mput para baixar e enviar arquivos respectivamente.
Para verificar quais comandos são suportados, execute HELP no prompt do FTPS.
Assim como qualquer software, o SSH e o OpenSSH já apresentou vunerabilidades que veio a comprometer a segurança do sistema. Isto acontece em versões mais antigas do OpenSSH e a história permite afirmar que acontecerá com as versões recentes e futuras. Entretanto, o papel do administrador é conhecer estes problemas e de acordo com a necessidade fazer as correções necessária. Assim como qualquer sistema necessita de atualização o OpenSSH segue os mesmos conceitos. Os problemas de segurança recentes e antigos podem ser encontrados no endereço http://www.openssh.org/security.html.