O aumento na demanda de acesso remoto, originados no trabalho remoto, computação em nuvem, computação móvel, dentre outros, passa a ser um fator relevante para as organizações nos dias atuais. Entretanto, as características intrínsecas ao acesso remoto pode acarretar em graves problemas de segurança, afinal, alguém em qualquer lugar da Internet estará acessando a rede de determinada organização. Portanto, ferramentas e técnicas adequadas são necessárias, inclusive, às políticas de segurança organizacionais.

Para atender essa demanda, ferramentas denominadas Secure Shell - SSH, permitem fazer comunicações interessantes entre cliente e servidor. Dentre o conjunto de aplicativos, as ferramentas incluem o SSH, SCP, SFTP, dentre outras.

O interessante se deve ao fato de que essas ferramentas são mais seguras que ferramentas similares mais antigas, em função da utilização de criptografia para realizar as respectivas funções. O antigo Telnet, por exemplo, é substituído pelo SSH; que substitui também comandos antigos de execução remota como RSH e rLogin. Para copiar/transferir arquivos, o antigo RCP pode ser substituído por comandos seguros, tais como scp e rsync.

Os antigos protocolos de comunicação, expõe senhas e todos os dados para atacantes em potencial realizarem análise dos pacotes (sniffing) na rede. O Telnet, por exemplo, deve ser utilizado somente para testes em pequena escala e quando dados privados não forem expostos.

A maioria dos sistemas Linux possuem, nativamente, clientes e servidores Secure Shell. Em distribuições RHEL (e descendentes) os pacotes são openssh, openssh-clients e openssh-server. Digite o comando abaixo, para verificar se os pacotes necessários estão instalados:

yum list installed | grep ssh

Esse artigo, portanto, descreverá métodos para a boa (segura) utilização das principais ferramentas de acesso remoto com foco em sistemas Linux RHEL, mais especificamente para CentOS, e está dividido nos seguintes tópicos:

• Inicialização do openssh-server;
• SSH em login remoto;
• SSH em execução remota;
• Transferência de arquivos;
• Autenticação baseada em chave (sem senha);
• Aplicação do SSH com Fail2Ban.

Para fins de entendimento, poderemos usar os termos host local, que equivale ao cliente e host remoto, que equivale ao servidor.

Inicialização do openssh-server

Mesmo quando o openssh-server está instalado, muitas vezes ele não está configurado para inicializar automaticamente. O gerenciamento dos serviços no Linux fogem do escopo deste artigo e são tratados de maneiras diferentes pelas distribuições. No CentOS, para visualizar o status do daemon de servidor ssh, o sshd, deve-se utilizar o comando:

# systemctl status sshd.service

Caso o sshd não estiver sendo executado, sua inicialização (como root) se dá com o comando:

# systemctl start sshd.service

E para que o sshd inicialize junto com o sistema, utilize o comando:

# systemctl enable sshd.service

Para permitir que o openssh-client acesse o servidor, através da porta 22 (por padrão), o Firewall (caso tenha algum para acessar o servidor) deve ser configurado. Os três últimos comandos apenas inicializam o SSH, não o configura. Para tal, o daemon sshd pode ser configurado no arquivo /etc/ssh/sshd_config. Uma configuração mínima recomendável, é modificar a linha PermitRootLogin deste arquivo de "yes" para "no", impedindo logins remotos como root. Várias tentativas de invasão a servidores por meio do SSH ocorre utilizando usuário root.

SSH em login remoto

A ferramenta mais utilizada para acessar sistemas Linux remotamente é o SSH, com possibilidade de realizar login remoto, execução remota, dentre outras utilidades. Com o scp e rsync é possível transferir arquivos entre clientes e servidores SSH.

O sftp, por sua vez, fornece uma interface FTP para navegar em um sistema de arquivos remoto, copiar e transferir arquivos de forma interativa entre os sistemas. Todas as ferramentas pertencentes ao SSH autenticam usando as contas de usuários (e suas respectivas senhas) em conexões criptografadas.

Dessa forma, a sintaxe básica de conexão com o SSH acontece com o seguinte comando:

ssh mauHumb@10.0.2.15

Onde:

• "ssh" é o comando;
• "mauHumb" e 10.0.2.15 são, respectivamente, o usuário e o IP do servidor que deseja-se acessar.

Se for a primeira tentativa de acesso, o sistema solicitará confirmação com um "yes". Em seguida, será solicitada a senha do usuário (mauHumb, neste caso). Neste momento, uma chave pública do computador remoto, usando o algoritmo de criptografia RSA, é baixada no ~/.ssh/know_hosts do cliente.

Depois de conectado, o cliente (quem está fazendo a conexão) obtém o shell como se estivesse na máquina localmente. Tudo que é digitado a partir deste momento nesse prompt, é criptografado pelos meios de transmissão e pela(s) rede(s) entre origem e destino.

Para sair e retornar ao shell local, basta digitar: exit

Caso a chave do servidor mudar por qualquer motivo, você terá de remover a chave do host do arquivo "know_hosts" e tentar nova conexão para baixar nova chave. Caso isso não seja feito, não será possível realizar nova conexão.

SSH em execução remota

O SSH também pode ser utilizado para executar comandos remotamente com a saída do comando no host local, como no exemplo:

ssh mauHumb@10.0.2.15 hostname

Neste caso, o nome do servidor aparecerá como resultado. Antes de gerar o resultado, deve-se digitar a senha de acesso, neste caso, do usuário "mauHumb". Comandos que necessitem de argumentos deve-se utilizar aspas como a seguir:

ssh mauHumb@10.0.2.15 cat "umArquivoQualquer"

É pertinente observar que caminhos e diretórios relativos serão entendidos como o diretório inicial do usuário que está sendo usado. Aplicativos gráficos também podem ser utilizados através do SSH, caso o X11 esteja habilitado no servidor. Neste comando:

ssh -X mauHumb@10.0.2.15 system-config-date

...a senha de root será solicitada e, em seguida, a janela Date/Time Proprerties aparece para que a data e horário locais possam ser atualizados.

Outra opção do arquivo de configuração do SSH (/etc/ssh/sshd_config) é modificar, por segurança a porta padrão de acesso do serviço, a linha Port do arquivo. Por exemplo, se esta linha é modificada para uma porta alta como 56789 (Port 56789 no arquivo), o acesso se dará da seguinte forma:

ssh -p 56789 mauHumb@10.0.2.15

Onde "-p" é a sintaxe do SSH para especificar a porta de acesso configurada no servidor (host remoto).

Transferência de arquivos

Com o SSH, arquivos podem ser copiados tanto do cliente para o servidor, como vice-versa, com os comandos scp e rsync. Veja um exemplo genérico:

scp /home/astolfo/memorando mauHumb@10.0.2.15:/tmp

Como de praxe, a senha de "mauHumb" será solicitada. Em seguida, o arquivo memorando localizado no diretório /home/astolfo será copiado para o /tmp do host remoto. Assim, podemos observar que a sintaxe do scp é . Dessa forma, fica intuitivo entender que, para copiar um arquivo do host remoto para o host local, a origem trata-se do host remoto e o destino, o host local como no comando:

scp mauHumb@10.0.2.15:/root/Docs/ /tmp/

Só que, neste caso, será copiado para /tmp local todo o conteúdo em /root/Docs/ do host remoto.
Com tantas facilidades contidas no scp, ele pode se tornar inviável em operações de transferências mais sofisticadas, tais como backups. Isso porque ele possui algumas limitações. Permissões e atributos como data e hora são modificadas, links simbólicos são perdidos e, na realidade, o scp não cria links, ele copia o arquivo literalmente. Além disso, cópias são repetidas desnecessariamente.

Ao realizar backups, essas características do scp pode não ser interessante. Para suprir estas carências, o rsync torna-se bastante útil. Com o comando:

rsync -avl mauHumb@10.0.2.15:/root/Docs/ /tmp/

Onde:

• "a" significa arquivo recursivo;
• "v" modo verbose;
• "l" copia links simbólicos, ou seja, os links simbólicos são preservados, as permissões e atributos são preservados.

Quando é necessário fazer uma restauração, portanto, os arquivos continuam sendo exatamente como eram anteriormente.

Tudo isso pode ser confirmado ao executar este último comando novamente e digitar "ls -l". Você observará que a cópia não será feita novamente e as permissões dos arquivos copiados não serão alteradas. O rsync torna-se, então, uma ferramenta bastante útil para os administradores de redes, inclusive para tarefas remotas.

Autenticação baseada em chave (sem senha)

Esta opção é útil quando o administrador precisa se conectar remotamente várias vezes ao dia, afinal, não será necessário digitar a senha todas as vezes. Este procedimento cria uma chave pública e uma privada. A primeira é copiada para o host remoto. Com o comando:

ssh-keygen

Será criado um par de chaves RSA após confirmação do diretório (usuário local) de criação das chaves (~/.ssh/id_rsa e ~/.ssh/id_rsa.pub) e a senha. O próximo passo é copiar a chave para o usuário remoto:

ssh-copy-id -i ~/.ssh/id_rsa.pub mauHumb@10.0.2.15

Dessa forma, toda vez que o usuário local tentar se conectar, uma autenticação automática será realizada sem a necessidade de digitar a senha. A senha solicitada é a do usuário remoto. A chave pública do usuário local foi copiada para o arquivo "authorized_keys" do diretório ".ssh" do usuário remoto.

Aplicação do SSH com Fail2Ban

A autenticação baseada em chaves (tópico anterior) é interessante até certo ponto. À medida que o número de chaves (usuários) cresce, a complexidade para gerenciar as mesmas também aumenta. Além disso, a grande utilização de bots atualmente combinado ao grande número de senhas fáceis, pode culminar em um ataque efetivo de força bruta que descobre as senhas na base da tentativa e erro.

Para evitar esse transtorno, a ferramenta Fail2ban torna-se uma solução com simples implementação, com monitoramento de arquivos de log e bloqueio de endereços de atacantes em potencial. Abaixo, segue um passo a passo simples para instalar e configurar o Fail2ban.

Instalação:

yum install fail2ban

Configuração no arquivo /etc/fail2ban/jail.conf:

bantime = 600        #Este parâmetro é o tempo em segundos (600 é o padrão) de banimento dos IPs que fizerem 5 tentativas falhas de acesso.

maxretry = 6        #Quantidade de tentativas permitidas. Cada serviço tem uma seção com alguns parâmetros, maxretry é um deles.

ignoreip = 200.18.56.46    #Espécie de lista branca de IPs que não serão bloqueados. Útil para servidores que são acessados a partir de um IP fixo. Para colocar vários IPs é só colocá-los separados por um espaço.

Depois, é só reiniciar o serviço:

# systemctl restart fail2ban

Conclusão

Neste artigo tentamos demonstrar as várias possibilidades de trabalho seguro com acesso remoto. O SSH é uma ferramenta extremamente útil para os administradores de rede atualmente. Mas não significa sinônimo de segurança.

Mesmo com a criptografia do RSA, o fator humano é decisivo na garantia de uma segurança mínima criando, por exemplo, senhas robustas (ou não). Espero que este artigo contribua com a comunidade em geral, desde os iniciantes até os profissionais mais experientes. Mais detalhes sobre o SSH pode ser encontrado nas referências deste artigo.

Referências

• Linux, a Bíblia. Christopher Negus e Christine Bresnahan.
• Servidores Linux, Guia Prático. Carlos E. Morimoto.
• Segurança de Redes em Ambientes Corporativos. Emílio Tissato Nakamura e Paulo Lício de Geus.
• How To Protect SSH With Fail2Ban on CentOS 7 | DigitalOcean Brennen Bearnes. Acessado em 9 de dezembro de 2019.
• How to Install and Configure Fail2Ban to Secure Linux Server. Secure Your Linux Server With Fail2Ban [Beginner's Guide]. About Abhishek - Acessado em 9 de dezembro de 2019.